Connexion avec TiEmu - Page 1

Est-ce que quelqu'un à déjà réussit à faire communiquer tiEmu et sa vrai calculette via le port USB. Ca ne fonctionne pas chez moi.
Pourtant les drivers sont OK, lors de sélection du cable tout est ok mais il n'y a pas d'échange entre tiEmu et la calculette

Oui je l'ai déjà fait, utilises tu bien les drivers usb fournis avec tiEmu et non pas ceux de TI?

J'utilise bien le driver adapté pour tiEmu et tilp. Les 2 liaisons sont configuré pour tiEmu, une sur le port 1 et l'autre sur le 2. J'arrive à visualiser le continu de la calculette tiEmu avec tilp, je récupère les fichiers mais ça ne fonctionne pas lorsque je veux en envoyer de tilp vers tiEmu. Sauf, maintenant. Je viens de réessayer en même temps que j'écris le message et ça fonctionne dans les 2 sens.

Mais,c'est quand même capricieux, j'ai changé la liaison pour communiquer entre tilp et le ti (la vrai), liaison usb direct. Pas de problème, ça fonctionne très bien. Ensuite, je reviens à la communication entre tilp et tiEmu et la plus rien. J'ai l'impression que tiEmu perd un peu les pédales.

Voici les logiciel et matériel employé
tiEMu version 2.81b
tiLP2 v1.01
ti89 titanium
cable USB direct

Je me souviens aussi que c'était pas facile

Je me suis rendu compte que j'ai fait une bétise hier. J'ai configuré Tilp pour une ti89 et non pas une ti89 titanium et ça marchait très bien. En changeant la paramètre, plus possible d'échanger des fichiers entre TiEmu et Tilp. Donc si on utilise TiEmu pour une ti89 titanium il faut configurer tilp pour une ti89 simple.

On peut verifier comment qu' ils sont present les drivers pour tiemu ?

en faisant un recherche sur l'ordi?

Essaie aussi avec VTI (l'ancêtre de TI-Emu), je trouve trouve que VTI fonctionne mieux.

artazis (./3) :
cable USB direct

L'émulation de liaison (communication avec la calculatrice réelle) de TiEmu ne peut pas fonctionner avec le câble USB direct.

ProgVal (./11) :
Essaie aussi avec VTI (l'ancêtre de TI-Emu), je trouve trouve que VTI fonctionne mieux.

N'importe quoi, déjà VTI ne gère pas du tout ce qui est USB, donc il ne risque pas de résoudre son problème, et ensuite VTI n'émule pas du tout la TI-89 Titanium.

La seule raison d'utiliser toujours VTI maintenant est l'émulation du son (pas encore gérée par TiEmu 3.00), et la prochaine version de TiEmu (3.01) contiendra une émulation de son nettement meilleure que VTI, par exemple PolySound fonctionnera avec TiEmu 3.01 (le code est déjà dans notre SVN).

Kevin Kofler (./12) :
La seule raison d'utiliser toujours VTI maintenant est l'émulation du son (pas encore gérée par TiEmu 3.00), et la prochaine version de TiEmu (3.01) contiendra une émulation de son nettement meilleure que VTI, par exemple PolySound fonctionnera avec TiEmu 3.01 (le code est déjà dans notre SVN).

Ou alors d'utiliser Windows, puisque TiEmu ne fonctionne qu'après avoir installé GTK, et encore, ça c'est quand on est chanceux ^^

TiEmu fonctionne très bien sous Window$. Oui, il faut installer GTK+, mais ça ne pose pas de problème normalement. À condition bien sûr d'installer une et une seule version de GTK+ sur son système, tous les problèmes reportés, c'est quand l'utilisateur en avait plusieurs (et ça se résoud par un bon nettoyage). (C'est aussi pour ça qu'il faut utiliser un GTK+ partagé et pas installer sa copie privée.)

Tiemu est clairement mieux et il faut pas exagérer c'est pas un exploit que d'installer les runtimes GTK.
Par contre le vrai avantage de VTI, c'est qu'il est quand même bien moins gourmant en puissance, mais si ta machine n'est pas trop ancienne, ça n'a pas vraiment d'importance

@Martial: tu as oublié la portabilité de l'émulateur

A part ça:
> - Interface du déboggueur complètement à revoir (prendre modèle sur VTI)
Assez d'accord. La séparation en fenêtres n'a pas que des atouts, et l'interface du debugger est lente, même sous GNU/Linux et sans le debugger C. Peut-être que ça irait mieux si j'utilisais Gnome et pas KDE, mais l'assez lourd Gnome sux
J'imagine que GTK ne fournit pas un moyen de regrouper plusieurs fenêtres en une (ou que seules des versions de GTK un peu trop récentes le font) ?
> - demande des programmes pas trop buggués pour le débogage, sinon il plante facilement
Je ne peux pas dire: je n'ai plus utilisé TIEmu 2.8*/3.xx (avec debugger intégré) depuis l'été 2005, c'est à dire le moment où la combinaison du support bleeding edge du debugging dans la toolchain, et le support bleeding edge du debugger C dans TIEmu, sous Windows (puisque c'était ça que j'utilisais à l'époque) était totalement inutilisable
> - problèmes réguliers d'interface entre KTIGCC et TiEmu
Jamais utilisé. Il faut dire que je ne programme plus trop, et puis que certains de mes TIGCC Projects ne fonctionnent pas avec KTIGCC...
> - prise en charge bizaroïde du clavier français
Oui.

Tiens, jamais essayé ^^

Uther (./15) :
Tiemu est clairement mieux et il faut pas exagérer c'est pas un exploit que d'installer les runtimes GTK.

Ça dépend, j'ai pas essayé mais visiblement certains ont des surprises en installant GTK; mais dans tous les cas, ce n'est pas tant un exploit qu'une énorme contrainte de devoir installer ce... truc juste pour pouvoir exécuter TiEmu, surtout quand il existe d'autres solutions pour avoir des applis compatibles Unix/Windows sans créer une dépendance avec un truc à intégrer à son système.

> qu'une énorme contrainte de devoir installer ce... truc juste pour pouvoir exécuter TiEmu
Je pense que là aussi, tu exagères
C'est quand même pas dur, même pour un relatif débutant, d'aller chercher un installeur tout prêt sur gladewin32 (de mémoire, est-ce qu'un endroit où télécharger un GTK+ n'est pas mentionné dans le programme d'installation ?), de double-cliquer pour l'installer, et de laisser poursuivre l'installation (de mémoire, les réglages par défaut sont OK).

Bah non j'exagère pas, si je n'ai jamais installé TiEmu c'est pas par difficulté, le problème est bien avant : je refuse d'installer cette bouse de GTK pour faire tourner un soft; l'erreur de conception est pour moi au niveau du choix de cette bibliothèque. Tant qu'un "linkage" statique avec ne sera pas fait pour la version Windows, ça ne changera pas.

> l'erreur de conception est pour moi au niveau du choix de cette bibliothèque.
Ca se défend, mais les librairies _vraiment_ portables ne sont pas si nombreuses que ça. En général, et pas seulement pour les toolkits graphiques, c'est parce que pour des raisons historiques, Windows fait à l'envers des autres - mais il représente +/-90% des machines...
wxWidgets serait peut-être jouable pour un _nouveau_ design à l'heure actuelle, mais quand "GtkTiEmu" a été commencé (ça fait longtemps !), wxWidgets (wxWindows, à l'époque) n'était pas non plus dans l'avancement dans lequel il est actuellement.

> Tant qu'un "linkage" statique avec ne sera pas fait pour la version Windows, ça ne changera pas.
Que ce soit le linking statique, ou le linking dynamique mais les DLL embarqués dans la directory du programme, d'après ./14, tu peux toujours te brosser ^^
Note que Kevin et roms ont a raison de procéder de la sorte. D'un point de vue sécurité / correction des bugs, le linking statique, ou dynamique avec version embarquée dans la directory du programme, est une connerie: comme le taux de mise à jour de la lib et le taux de mise à jour des applications qui les utilisent sont habituellement peu corrélés, tu te retrouves avec plusieurs versions éventuellement incompatibles (réglages, API/ABI, etc.) du même truc, pas les mêmes bugs partout, etc.
Le linking statique est une des raisons importantes qui font qu'Autopackage n'est pas bien.

Martial Demolins (./16) :
VTI -- émule l'int 5 n'importe comment, et certainement d'autres choses.

L'AI5 passe encore, l'AI4 est pire (c'est un timer alors que cet AI devrait signaler une activité du link).

TiEmu -- demande des programmes pas trop buggués pour le débogage, sinon il plante facilement

C'est si tu utilises les fonctionnalités du débogueur niveau source, ça, VTI ne le propose carrément pas. Mais je suis d'accord que le débogueur niveau source a besoin de stabilisation.

- problèmes réguliers d'interface entre KTIGCC et TiEmu

Je ne comprends pas trop, là, j'entends dire qu'il y a des problèmes, mais chez moi ça marche à tous les coups!

- prise en charge bizaroïde du clavier français

La seule chose bizarre, c'est que les lettres ne suivent pas le layout local sous X11 (ça marche sous Window$ bizarrement), c'est un bogue qu'on n'a pas encore eu le temps de corriger. À part ça, ça se comporte comme VTI. (Les touches non-alphabétiques utilisent toujours le même layout, on ne peut pas vraiment faire autrement.)

Lionel Debroux (./17) :
> - Interface du déboggueur complètement à revoir (prendre modèle sur VTI)
Assez d'accord. La séparation en fenêtres n'a pas que des atouts, et l'interface du debugger est lente, même sous GNU/Linux et sans le debugger C. Peut-être que ça irait mieux si j'utilisais Gnome et pas KDE, mais l'assez lourd Gnome sux

Je tourne exclusivement sous KDE, donc TiEmu est très bien testé sous KDE. Je ne trouve pas qu'il soit particulièrement lent sur une machine moderne.

J'imagine que GTK ne fournit pas un moyen de regrouper plusieurs fenêtres en une (ou que seules des versions de GTK un peu trop récentes le font) ?

Je ne sais pas, mais l'intérêt de notre interface est qu'on peut choisir exactement les fenêtres dont on a besoin, ce qui nous permet de proposer plus d'informations que VTI, et de permettre aux utilisateurs qui n'ont pas besoin de toutes ces informations de rendre par exemple la fenêtre de désassemblage plus grande. Si on réunissait tout en une fenêtre, on perdrait cette flexibilité.

> - problèmes réguliers d'interface entre KTIGCC et TiEmuJamais utilisé. Il faut dire que je ne programme plus trop, et puis que certains de mes TIGCC Projects ne fonctionnent pas avec KTIGCC...

Pas normal ça, les .tpr devraient être importables sans problèmes. S'il y a des chemins absolus dedans, il faudra les corriger, mais c'est normal, c'est aussi comme ça si tu passes d'une machine avec TIGCC IDE à une autre. C'est bien pour ça qu'il ne faut pas mettre des fichiers en dehors du répertoire du projet dans ses .tpr.

Zephyr (./22) :
Bah non j'exagère pas, si je n'ai jamais installé TiEmu c'est pas par difficulté, le problème est bien avant : je refuse d'installer cette bouse de GTK pour faire tourner un soft;

Comment peux-tu traîter de "bouse" quelque chose que tu n'as même pas essayé?

l'erreur de conception est pour moi au niveau du choix de cette bibliothèque.

Elle est où l'erreur de conception?

Tant qu'un "linkage" statique avec ne sera pas fait pour la version Windows, ça ne changera pas.

Si tu nous compiles la version statique de GTK+...
Ce n'est distribué que sous forme de DLLs, probablement pour une raison, je n'ai pas envie de me taper une recompilation de tout GTK+ en statique juste pour toi qui ne programmes même plus sur TI.

Quant à wxWidgets, ça ne change pas grand chose à ce problème, c'est aussi une librairie à linker statiquement ou dynamiquement.

Kevin Kofler (./25) :
Comment peux-tu traîter de "bouse" quelque chose que tu n'as même pas essayé?

Il me semble que tu es plutôt mal placé pour faire ce genre de remarques ^^
Mais en l'occurence, ce n'est pas la réalisation que je reproche, mais la conception même de cette bibliothèque; je ne vois pas ce que l'installer m'apprendrait de plus là-dessus...

Elle est où l'erreur de conception?

Introduction d'une dépendance pour un soft sous Windows.

Si tu nous compiles la version statique de GTK+...
Ce n'est distribué que sous forme de DLLs, probablement pour une raison, je n'ai pas envie de me taper une recompilation de tout GTK+ en statique juste pour toi qui ne programmes même plus sur TI.

Effectivement, mais ça ne m'empêche pas de donner mon avis... Après, je ne sais pas quelles options sont disponibles, mais la seule acceptable pour moi c'est de pouvoir faire fonctionner TiEmu simplement en le décompressant dans un dossier, et sans flinguer son système en installant n'importe quoi. Tant que TiEmu ne sera pas capable de fonctionner comme ça, VTI sera mieux.

Zephyr (./26) :

Elle est où l'erreur de conception?

Introduction d'une dépendance pour un soft sous Windows.

L'installeur est lancé automatiquement. (Oui, ça ne marche pas toujours à cause de SourceForge qui change les URLs sans arrêt, mais oui, je vais mettre à jour l'URL une fois de plus.) Il y a plein d'autres logiciels qui font ça avec des dépendances, par exemple je vois (enfin, voyais quand j'utilisais encore Window$) plein de jeux qui lancent l'installeur de DirectX dans leur installeur. Je vois aussi (sur le net) de nombreux logiciels Window$ qui demandent d'installer le framework .NET avant, ce n'est pas une dépendance? Les logiciels avec dépendances sont au moins aussi courants que les logiciels sans dépendances.

Après, je ne sais pas quelles options sont disponibles, mais la seule acceptable pour moi c'est de pouvoir faire fonctionner TiEmu simplement en le décompressant dans un dossier

Je ne vois vraiment pas pourquoi on devrait permettre ça alors que pratiquement tous les logiciels Window$ de nos jours viennent avec un installeur. Essaie d'installer M$ Office en le décompressant dans un dossier. Les logiciels payants ont pratiquement tous un installeur, et pas mal de logiciels gratuits ou shareware aussi.

et sans flinguer son système en installant n'importe quoi

Tu ne flingues rien du tout en installant GTK+.

> Je ne comprends pas trop, là, j'entends dire qu'il y a des problèmes, mais chez moi ça marche à tous les coups!
C'est normal que ça fonctionne toujours chez toi: tant que ça ne fonctionne pas sur ta machine, tu vas chercher à le corriger pour que ça fonctionne

> Je ne trouve pas qu'il soit particulièrement lent sur une machine moderne.
Mon P4 2.6 GHz ne doit pas être moderne, alors... Plusieurs secondes pour la première ouverture du debugger dans une session TIEmu donnée, puis des centaines de millisecondes pour faire apparaître toutes les fenêtres (puisqu'il est visible qu'elles n'apparaissent pas toutes en même temps).

> > J'imagine que GTK ne fournit pas un moyen de regrouper plusieurs fenêtres en une (ou que seules des versions de GTK un peu trop récentes le font) ?
> Je ne sais pas, mais l'intérêt de notre interface est qu'on peut choisir exactement les fenêtres dont on a besoin, ce qui nous permet de proposer plus d'informations que VTI, et de permettre aux utilisateurs qui n'ont pas besoin de toutes ces informations de rendre par exemple la fenêtre de désassemblage plus grande. Si on réunissait tout en une fenêtre, on perdrait cette flexibilité.
Il me semble qu'on en avait déjà parlé, et j'ai oublié de le préciser cette fois, mais je pensais plutôt à fournir le mode "regroupé" _en plus_ du mode fenêtres éparpillées. On ne sait jamais, il pourrait peut-être y avoir un truc intéressant dans GTK.

> C'est bien pour ça qu'il ne faut pas mettre des fichiers en dehors du répertoire du projet dans ses .tpr.
C'est bien ça le problème dans mes projets... Deux projets frères (tests d'ExtGraph, dans trunk/src/lib), dont l'un est à usage interne, donc je ne peux pas utiliser des symlinks. Si je fais ces projets pour qu'ils fonctionnent dans KTIGCC, ils ne fonctionnent pas avec tprbuilder, et inversement.
Pour qu'ils fonctionnent dans tprbuilder, il faut que je mette dans mes .c
#include "../../lib/extgraph.h"
Pour qu'ils fonctionnent dans KTIGCC, il faut que je mette dans mes .c
#include "extgraph.h"
Je viens de revérifier ce comportement avec le dernier KTIGCC disponible sur repo.calcforge.org. En revanche, je n'ai pas encore mis à jour le package tigcc depuis 0.96 Beta 7 vers 0.96 Beta 8, donc peut-être que tprbuilder a changé depuis.
(Au passage, j'ai vu une boulette de KTIGCC: avec le flag "-v" dans les options du compilateur, tous les messages "verbose" sont interprétés comme des erreurs, ce qui empêche de poursuivre plus loin. tprbuilder s'en moque.)

Lionel Debroux (./28) :
Mon P4 2.6 GHz ne doit pas être moderne, alors...

C'est ce que j'ai aussi.

Plusieurs secondes pour la première ouverture du debugger dans une session TIEmu donnée, puis des centaines de millisecondes pour faire apparaître toutes les fenêtres (puisqu'il est visible qu'elles n'apparaissent pas toutes en même temps).

Ce n'est pas ce que j'appelle "particulièrement lent".

(Au passage, j'ai vu une boulette de KTIGCC: avec le flag "-v" dans les options du compilateur, tous les messages "verbose" sont interprétés comme des erreurs, ce qui empêche de poursuivre plus loin. tprbuilder s'en moque.)

Ce n'est pas un bogue, on n'a pas le droit de mettre -v dans les options du compilateur tout simplement.

Pour les chemins include: et si tu mets -I ../../lib dans les options du compilateur?
Sinon, la solution correcte n'est pas un symlink, mais carrément une copie.

Kevin Kofler (./27) :
L'installeur est lancé automatiquement. (Oui, ça ne marche pas toujours à cause de SourceForge qui change les URLs sans arrêt, mais oui, je vais mettre à jour l'URL une fois de plus.) Il y a plein d'autres logiciels qui font ça avec des dépendances, par exemple je vois (enfin, voyais quand j'utilisais encore Window$) plein de jeux qui lancent l'installeur de DirectX dans leur installeur. Je vois aussi (sur le net) de nombreux logiciels Window$ qui demandent d'installer le framework .NET avant, ce n'est pas une dépendance? Les logiciels avec dépendances sont au moins aussi courants que les logiciels sans dépendances.

J'étais résolument contre .NET quand c'était encore une dépendance; ce n'est que depuis l'arrivée de Vista que je considère ce framework comme utilisable. Quand au fait que TiEmu installe GTK automatiquement, encore heureux, il manquerait plus qu'il faille installer tout les composants à la main... mais ça n'en reste pas moins une dépendance.

Je ne vois vraiment pas pourquoi on devrait permettre ça alors que pratiquement tous les logiciels Window$ de nos jours viennent avec un installeur. Essaie d'installer M$ Office en le décompressant dans un dossier. Les logiciels payants ont pratiquement tous un installeur, et pas mal de logiciels gratuits ou shareware aussi.

Qu'il y ait un installeur n'est pas très grave si il ne fait que ce qu'aurait fait une simple copie des fichiers dans leurs dossiers respectifs (i.e si il ne modifie pas le système, ce que fait GTK).

Tu ne flingues rien du tout en installant GTK+.

cf citation précédente, ça modifie le système, ce qui est totalement injustifié pour un composant de ce type. Une application en QT ne requiert pas de modifier son système pour fonctionner. Firefox non plus. Et pourtant, ils fonctionnent très bien sous Mac ou Unix.