240

Quand tu utilises le link virtuel de TiLP, tu le configures comment? Il faut que tu mettes TiLP sur câble TiEmu, port 2 et TiEmu sur câble TiEmu, port 1, ou l'inverse.

Non, le même port pour les deux. Si on utilise #1 et #2 (ce qui ne me paraît pas intuitif), ça fonctionne effectivement... Merci smile
OK, je dois RTFM (c'est effectivement décrit dans le manuel de TIEmu...)... mais quand même, je pense qu'il serait souhaitable, si c'est techniquement faisable, d'ajouter un "anti-con" aux tilibs pour qu'elles préviennent l'utilisateur, quand ce genre de situations se produit ?


Bug: aussi bien TILP que TIEmu crashent quand on essaie d'activer le câble virtual, sur n'importe quel port. Après avoir validé, un premier dialog d'erreur indique "Can't set cable", suivi d'un deuxième qui indique "Code d'erreur introuvable dans la liste. Ceci est un bogue. Veuillez le reporter", puis le KDE Crash Handler m'informe que "The application TIEmu (tiemu) crashed and caused the signal 11 (SIGSEGV)".
Vilains logiciels grin

En tout cas, j'espère que tu comprends maintenant pourquoi il n'y a pas de testsuite automatisée pour TIGCC. grin

J'avais déjà compris, et après avoir passé quelques heures à me battre avec les outils (parce que je n'ai pas lu la doc et parce que les outils ne m'indiquent pas mon erreur), j'ai encore beaucoup mieux compris grin
Mais si on peut en créer une, ce n'est pas un mal...
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

241

J'ai reporté, il y a déjà plusieurs mois, ces bugs sur le tracker de TiLP. Comme tu dis, il manque un anti-con, et malheureusement TiLP crash sans le moindre message d'erreur. A notre génération de logiciel, c'est anormal, il est mal blindé.

242

Ben, Romain et Kevin n'ont pas que nous à penser. Il faudrait probablement qu'on fasse des patches (enfin, toi qui ne connais pas le C, ça va être plus dur grin)... mais ça veut dire, en général, passer des heures à se plonger dans le code de tilibs / TILP / TIEmu, et aussi GLib / GTK+, avant de pouvoir faire un patch utile...


Je ne voudrais pas être méchant, mais j'ai parfois l'impression qu'à côté de TILP / TIEmu, VTI est très stable (que ce soit sous Windows natif ou Wine)...
Actuellement, si j'utilise les versions [de TIEmu] que je compile moi-même, j'ai le choix entre:
* une version sans GDB, à laquelle il est à peu près impossible de rentrer quelque chose (adresse, nom de ROM_CALL) et de valider sans que le programme crashe;
* une version avec GDB qui ne démarre pas, l'émulateur se relançant tout seul en boucle très tôt dans la phase de chargement. Les traces dans la console redémarrent du début.
J'utilise pourtant une distro basée sur Debian stable.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

243

Je sas qu'ils n'ont pas que ça à penser, mais c'set au cas où t'aurais des test cases pour compléter les miens, qui pourtant font crasher systématiquement, voilà. smile

(Quant aux patch by maïsailfe, c'est clair, c'est pas demain la veille grin)

244

Lionel Debroux (./240) :
Bug: aussi bien TILP que TIEmu crashent quand on essaie d'activer le câble virtual, sur n'importe quel port. Après avoir validé, un premier dialog d'erreur indique "Can't set cable", suivi d'un deuxième qui indique "Code d'erreur introuvable dans la liste. Ceci est un bogue. Veuillez le reporter", puis le KDE Crash Handler m'informe que "The application TIEmu (tiemu) crashed and caused the signal 11 (SIGSEGV)".
Vilains logiciels grin

Je ne sais pas à quoi correspond "virtual". Il y a "TiEmu" et "VTI" comme protocoles de link virtuel.

Pour tes problèmes avec TiEmu, ce sont les paquetages de Romain qui foirent, mon paquetage Fedora fonctionne très bien.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

245

Tu as fini de rejeter la faute sur Romain ?
De plus, tu n'as pas bien lu mon message: j'ai aussi des problèmes avec l'exécutable généré par configure --... && make && make install.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

246

Kevin !!! TiLP planet à mort sur Fedora 8 et 10 également !

247

Mais mon paquetage tiemu-gdb fonctionne.

Je n'utilise pas Debian, donc les problèmes qui ne se produisent que sous Debian, c'est Romain qui devrait s'en occuper. Je corrige tous les problèmes qui se produisent en premier sous Fedora (parce que Fedora utilise des versions plus récentes des libs), par exemple http://svn.tilp.info/cgi-bin/viewcvs.cgi?rev=2797&root=tiemu&view=rev (dans du code que Romain a écrit). Et pour l'histoire de tiemu-gdb sous Debian, quand j'ai eu une intuition de ce que pourrait être le problème (le 24 octobre 2008 - et c'est une idée qui m'est venue par hasard en lisant quelque chose sur comment Tcl/Tk est packagé sous les Debian récentes parce que Fedora a fait un changement qui ressemble; je suis sur que si Romain avait débogué ça sur sa Debian, il aurait trouvé plus tôt), je lui ai écrit un mail aussitôt:
* Je pense avoir compris l'histoire de TiEmu+GDB qui ne se lance pas sous
Debian: Depuis lenny, les fichiers Tcl sont sous /usr/share/tcltk plutôt
que /usr/lib. Apparemment, il faut patcher quelque chose dans TiEmu pour
qu'il les trouve là. (Avec l'utilisateur qui a aussi reporté le problème du
paquetage tigcc, on a essayé de mettre les variables d'environnement de type
TCL_LIBRARY, mais on n'a pas réussi à le faire marcher comme ça. Je pense
donc qu'il faudra modifier le code, mais le problème est que je n'ai pas de Debian pour tester ça.)

Romain n'a rien fait avec cette information. Il aurait pu faire des tests avec des patches qui circulent, il aurait pu me demander de faire un patch pour qu'il puisse le tester, il aurait même pu tester avec un symlink de /usr/share/tcltk/* vers /usr/lib/* s'il n'avait pas envie de patcher le code pour vérifier mon hypothèse ou il aurait au moins pu me demander des précisions si les informations que je lui ai fournies ne lui suffisaient pas. Il n'a fait rien de tout cela.

Voilà donc pourquoi je rejette la faute sur Romain.

Je ne peux que déconseiller fortement son dépôt et par conséquent l'utilisation de Debian comme plateforme pour les logiciels liés aux TIs, la qualité de ses paquetages est catastrophique. (Cf. aussi les "paquetages TIGCC" qui étaient quasi-totalement vides. Il les a supprimés depuis.)

!call roms
--- Call : roms appelé(e) sur ce topic ...

Voilà, si tu veux répondre.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

248

On s'en bat puissamment et massivement les kooyes avec une pelle à tarte ( grin ), que ça fonctionne avec TON package sur TA machine tournant TA Fedora. Ca fonctionne mal sur la machine de Martial et sur la mienne.
C'est injuste et irrespectueux de réduire, comme tu nous l'as déjà fait plusieurs fois, les problèmes au packaging de Romain. Peut-être que les packages Debian ne sont pas parfaits, mais le gros des problèmes de TIEmu NE VIENT PAS du packaging: le soft dysfonctionne, qu'on utilise Debian Etch, Fedora 8 ou Fedora 10, et même si on n'utilise aucune forme de packaging (compilation depuis SVN ou snapshot).
(Le package fonctionne moins mal que les versions que je compile moi-même !)

Hier, une fois que j'ai fini d'exécuter mes programmes sur TIEmu et de rapatrier les données, je suis passé à VTI sous Wine pour vérifier et améliorer mes contributions à partir des données de primary_tag_list, secondary_tag_list et "command_tag_list". VTI est bien plus que suffisant pour lire la mémoire, et désassembler/exécuter quelques ROM_CALLs du CAS (c'est bien avec VTI qu'ont été faites mes contributions, GtkTiEmu n'étant pas à l'époque une option pour moi). Deux choses dont sont incapables les TIEmu que je compile moi-même.

Il faudrait voir quand ils ont été supprimés, mais je ne suis pas sûr que la suppression des packages TIGCC pour Debian soit liée à une prétendue basse qualité. Ca pourrait aussi bien être, au moins partiellement, une conséquence d'avoir été viré comme un malpropre du projet TIGCC, par un incompétent en management de projet qui aime CVS et n'arrive pas à concevoir que d'autres fassent des erreurs en utilisant le branching et tagging pourtant bien connus comme pourris et générateurs d'erreur (suffisamment, en plus de ses autres défauts, pour que ce soit une des raisons de mettre ce SCM obsolète à la poubelle, ce que font nombre de gens et de projets sérieux) wink


S'il faut faire des tests sur Lenny (64 bits), je peux: si on excepte la période où elle était basée sur Ubuntu, SimplyMEPIS a toujours été une des distros les plus proches de Debian.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

249

Kevin Kofler (./247) :

Romain n'a rien fait avec cette information. Il aurait pu faire des tests avec des patches qui circulent, il aurait pu me demander de faire un patch pour qu'il puisse le tester, il aurait même pu tester avec un symlink de /usr/share/tcltk/* vers /usr/lib/* s'il n'avait pas envie de patcher le code pour vérifier mon hypothèse ou il aurait au moins pu me demander des précisions si les informations que je lui ai fournies ne lui suffisaient pas. Il n'a fait rien de tout cela.
Voilà donc pourquoi je rejette la faute sur Romain.


Kevin a raison, je n'ai rien fait. J'ai encore son mail du 24/10 à ce sujet. Le problème est, que je n'ai pas vraiment le temps de m'en occuper (pas avant mai) et je n'ai plus de PC actuellement.
Je ne peux que déconseiller fortement son dépôt et par conséquent l'utilisation de Debian comme plateforme pour les logiciels liés aux TIs, la qualité de ses paquetages est catastrophique.


Catastrophique, le mot est peut être fort... Je pense que les paquets TI fonctionnent bien. Il est vrai que:
- celui de TiEmu+GDB ne marche pas comme il faut, la faute à l'utilisation d'un Insight externe. Je n'ai pas de solution miracle et Kevin non plus. Mais, Julien (mon ancien packager) pense que cette façon de faire est bourrin et s'appelle "chercher les coups et les emmerdes".
- celui de TIGCC est vide mais ce paquet me pose énormément de problème étant donné que TIGCC ne dispose pas d'un vrai system de build. Cà été la raison d'une prise de bec à ce sujet...

Dans tous les cas, je promet de m'y remettre début mai. D'ici là; ouvrez des bugs requests détaillés.

Lionel, si tes bugs sont bloquants et constituent une urgence, envoie moi un mail, j'essayerais de faire le nécessaire.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

250

Catastrophique, le mot est peut être fort...

C'est Kevin...
C'est d'autant plus stupide de sa part qu'on pourrait appliquer "catastrophique" à plusieurs aspects de ses TIGCC et Fedora chéris. Ne serait-ce que l'absence de système de build dans TIGCC, que tu cites
Dans tous les cas, je promet de m'y remettre début mai. D'ici là; ouvrez des bugs requests détaillés.

Noté.
Lionel, si tes bugs sont bloquants

Si VTI me permet de faire ce que je veux (ce week-end, ça n'a été que partiellement le cas, mais le package Debian tiemu-gdb a suffisamment bien fonctionné pour que faire ce que je voulais), je ne suis pas bloqué smile
VTI et VTI logger fonctionnent très bien sous Wine.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

251

C'est n'importe quoi, cette histoire. TIGCC/*nix propose des build scripts automatiques qui fonctionnent très bien. Ce n'est pas cette pourriture immonde qui se nomme autotools, et heureusement! (C'est déjà assez lourd de souffrir ces merdes pour GCC et Binutils. sick)
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

252

Est-ce que j'ai parlé d'autotools ?
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

253

Il y a quoi qui ne va pas dans les build scripts de TIGCC/*nix? Le fait que ça compile et installe en même temps? Je peux sans doute changer ça.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

254

Le fait que ça s'installe à un endroit non standard ? cheeky

255

Le fait que ça compile et installe en même temps?

Clairement, oui.
Le fait que ça s'installe à un endroit non standard ?

Aussi, même si c'est probablement moins grave.


On est off-topic, donc j'ai créé topics/118907-ticket-29-automate-the-build-system-software-part pour en discuter. Le français est toléré, mais l'utilisation de l'anglais est nettement préférable smile
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

256

/usr/local/tigcc est parfaitement valable comme destination par défaut pour une chaîne d'outils croisée non packagée, et il est facile de changer ça en /usr/tigcc ou si vous préférez /usr/m68k-ti-tigcc (conformément à https://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout, étant donné qu'il s'agit d'une chaîne d'outils croisée) dans les paquetages (ce que je vais faire avec la prochaine mise à jour du paquetage Fedora).
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

257

Ca serait pas possible d'avoir les binaires dans /usr/bin ?

258

Je compte symlinker tigcc et tprbuilder dans /usr/bin, pour éviter de devoir bidouiller le PATH, les autres binaires n'ont pas à être appelés directement, donc ils ne seront plus dans le PATH par défaut (comme c'est déjà le cas dans la version W32). (Mais je ne sais pas encore quand je ferai ce changement.)
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

259

Je compte symlinker tigcc et tprbuilder dans /usr/bin

Il faut également symlinker (ou installer dans /usr/bin, tout simplement) tigccdoc (je ne lance la doc de TIGCC que de cette façon), ttbin2oth et ttpack (ces deux-là étant susceptibles d'être appelés par des scripts). Sans compter ktigcc, dans son propre package, et les autres tt*, si tu as envie de faire encore un package différent.
et il est facile de changer ça en /usr/tigcc ou si vous préférez /usr/m68k-ti-tigcc

Même /usr/local est mieux que /usr, à mon avis sick
Pourquoi pas /usr/share ??

Je pense qu'il faut implémenter un PREFIX configurable: ça permettra à la fois au packager de mettre les outils où il veut, ET aux utilisateurs de compiler et installer où ils veulent.
Sur ma machine, j'installe souvent dans $HOME les outils que je compile moi-même hors d'un système de packaging (Git, par exemple), ce qui permet de ne pas passer en root pour installer les programmes. Ca a pour conséquence que root ne peut pas lancer Git, mais je ne vois pas quel le problème pratique cela poserait.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

260

Kevin -> Il faudrait aussi tigccdoc, que je lance toujours en ligne de commande, comme Lionel.
Lionel Debroux (./259) :
Même /usr/local est mieux que /usr, à mon avis sick.gif Pourquoi pas /usr/share ??

Ben les binaires non-système et non-root, dans ma distrib, sont dans /usr/bin, autant rester cohérents. smile

261

Ben les binaires non-système et non-root, dans ma distrib, sont dans /usr/bin, autant rester cohérents. smile

Nan, mais comme Kevin, je parlais du répertoire "tigcc" qui est actuellement /usr/local/tigcc, pas des binaires qu'il peut - ou pas - contenir wink
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

262

Ah ok ^^

263

Lionel Debroux (./259) :
Il faut également symlinker (ou installer dans /usr/bin, tout simplement) tigccdoc (je ne lance la doc de TIGCC que de cette façon)

C'est clair, ce script est fait pour ça.
ttbin2oth et ttpack (ces deux-là étant susceptibles d'être appelés par des scripts)

Les versions publiques de ces deux-là sont censées être installés par la TI-68k Developer Tools Suite (mon paquetage tigcc-tools-suite installe déjà des copies dans /usr/bin, d'ailleurs), les copies livrées avec TIGCC/*nix ne sont que pour l'usage interne et vont bientôt disparaître (parce que ld-tigcc intègre maintenant la compression pucrunch).
Sans compter ktigcc, dans son propre package,

Déjà dans /usr/bin depuis un certain temps.
et les autres tt*, si tu as envie de faire encore un package différent.

Effectivement, je compte continuer à faire un paquetage séparé avec ces outils et à les installer directement dans /usr/bin (comme c'est déjà le cas), donc pour moi ça n'a rien à voir avec TIGCC. smile
Même /usr/local est mieux que /usr, à mon avis sickPourquoi pas /usr/share ??

Parce que /usr/target est la destination prévue par Fedora pour les chaînes d'outil croisées. Et parce que des binaires n'ont rien à faire dans /usr/share.
Je pense qu'il faut implémenter un PREFIX configurable: ça permettra à la fois au packager de mettre les outils où il veut, ET aux utilisateurs de compiler et installer où ils veulent.

C'est déjà le cas, le préfixe est déjà configurable.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

264

J'ai mis à jour la TODO list avec les item #214 et #220. D'autres remarques/suggestions ?
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

265

Est-ce que tu as mis "un warning quand on utilise un setting de link virtuel inuitif qui ne peut pas fonctionner, alors que le setting qui peut fonctionner n'est pas inuitif" (./240) ?

Est-ce que tu arrives à reproduire le crash systématique (pour moi) à l'activation du link "virtual", décrit également dans ./240 ?
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

266

J'ai rajouté #239. J'ai aussi reçu ton mail.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

267

Sous Windows natif ou virtualisé, TIEmu -> VTI Logger devrait fonctionner. Ou alors, c'est un bug d'au moins un des deux.


VTi, VTI-logger et consorts se basent sur l'enregistrement d'une classe de fenêtre par VTi pour détecter VTi et établir la communication par message. Etant donné que je ne peux faire cet enregistrement de classe, la libticables2 ne peut pas se faire passer pour VTi. Par conséquent, le VTI logger ne peut pas fonctionner avec TiEmu.

Ce problème s'était déjà posé entre TiEmu et TIGCC à l'époque où je voulais faire passer TiEmu pour VTi.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

268

Pollux (./216) :
- je sais pas si c'est compliqué à rajouter, mais si on pouvait sauvegarder/restaurer l'état quand on est dans le debugger ce serait cool


Fait!
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"

269

Continue !

(bon euh... bravo déjà grin)

270

Lionel Debroux (./226) :
J'avais bien démarré le logging du link dans le debugger.

... mais la sortie du link n'est pas correcte sad
"Hello World\x0D\x0A" est réduit à 9 caractères.


Ce bug est maintenant corrigé. Plus aucun octet n'est perdu lorsqu'on envoie des octets sur l'extérieur.

Il s'agissait d'une mauvaise interprétation de l'utilité du bit External Link Activity non documenté mais utilisé à partir d'AMS 208.
Romain Liévin aka 'roms'
"Linux, y'a moins bien mais c'est plus cher !"