Folco (./114) :
naPO
Pour ceux qui n'auraient pas suivi, c'est l'ancien pseudo de Yoshi Noir.
Il s'agit pas de dire "VTI c'est génial TiEmu/TIGCC/* c'est à chier", mais je ne trouve pas juste que tu aies le discours inverse : "VTI est totalement inutilisable TiEmu/TIGCC/* c'est quasi parfait".
* VTI n'accepte pas les matériels récents, donc si un nouveau programmeur essaie d'utiliser un ROM dump de son modèle (que VTI ne peut d'ailleurs même pas faire sur les Titaniums, à ma connaissance) ou un 89u/v2u pour son modèle, ça ne va pas marcher.
* Même quand on contourne les problèmes de matériel (comme ExtendeD l'a fait), certaines fonctionnalités du débogueur (table des handles et surtout les program entry breakpoints) ne fonctionnent pas avec AMS 3.
* Ces mêmes fonctionnalités ne fonctionnent avec AMS 2 que si on utilise la version modifiée par Julien Muchembled, qui est extrèmement boguée:
- plantages aléatoires et très fréquents dans le débogueur,
- éléments de la fenêtre débogueur qui se chevauchent, devenant illisibles, avec un dpi autre que celui par défaut (le fameux réglage "polices larges" du système d'exploitation),
et sans doûte d'autres trucs dont je ne me rappelle plus. Or AMS 1 est pratiquement introuvable de nos jours et, il me semble, n'est plus disponible légalement (à ma connaissance, TI ne répond plus quand on le leur demande comme ils le faisaient à une époque).
* Je sais que ça ne te concerne pas, mais pour une grande partie des développeurs TIGCC, le débogueur de VTI est totalement inutilisable parce qu'il ne peut déboguer qu'au niveau assembleur.
C'est pour ça que je dis que VTI est inutilisable.
Puis j'utilise pas à fond le linker, je fais de l'assembleur, je suis sensé dominer mon binaire de sortie, et pas me reposer sur un linker et des optimisations d'assemblage.
Si tu codes un programme vraiment modulaire, tu utilises forcément le linker. Mais visiblement, les techniques de programmation depuis les années 1960 sont passées à côté de toi.
Bonne chance avec tes gros blocs monolithiques et avec ta "modularisation" par overlays (morceaux de programmes chargés et déchargés en temps d'exécution, technique très vieille vue pour la dernière fois avec DOS, inutile de nos jours même sur une calculatrice).
Tiens, jamais remarqué. Mon Tetrix4LN utilise graphlib et ça marche bien.
Parce que tu sais ce que tu fais et tu n'écris pas sur LCD_MEM en niveaux de gris.
Mais si un nouveau fait cette erreur, il risque de ne pas le remarquer si son émulateur n'émule que les HW1.
Il ne faut pas oublier que TIGCC ne vise pas que les "anciens", et que les anciens et les nouveaux devraient utiliser les mêmes outils, sinon comment veux-tu que les anciens répondent aux questions des nouveaux? Ils vont soit conseiller des outils pas du tout adaptés aux besoins des nouveaux, soit devoir répondre qu'ils n'y connaissent rien aux outils utilisés par les nouveaux. C'est une des raisons pour lesquelles je pense qu'un réglage "Je suis ancien, j'utilise VTI / je suis nouveau, j'utilise TiEmu" dans les EDIs de TIGCC serait une très mauvaise idée. TiEmu est censé être parfaitement utilisable par les anciens, si ce n'est pas le cas, c'est là qu'il faut chercher et corriger le problème, un réglage de continuer à utiliser le vieux VTI (dont les problèmes d'utilisabilité par les nouveaux ne seront sans doûte jamais corrigés) ne ferait que le contourner à court terme. Et même parmi les "anciens", une grande majorité code au moins en partie en C (sinon entièrement) et peut donc profiter du débogueur C (la grande nouveauté de TiEmu): certes, on passe un peu de temps à apprendre à l'utiliser de manière efficace, mais je vous jure qu'on n'a plus envie de revenir en arrière une fois le débogueur maîtrisé, c'est une aide énorme.
Ben partant comme toujours.
Tu prends les RPMs ou tu as déjà viré toutes tes installations de Fedora?
Si c'est oui à la première partie (et non à la deuxième), je compile le RPM pour quelle version de Fedora?
Je t'ai déjà dit que vu ton code, ça semble pas venir de là, mais plus d'une configuration de la machine (installation¶métrage du serveur DCOP ?). J'ai essayé sur deux machines différentes avec deux installations différentes : résultat quasi-aléatoire, avec juste quelques indications qui n'ont pas paru t'aider. Je ne peux pas faire grand chose de plus de mon côté
Je pense que c'est un problème de timing. Avec une version instrumentée de KTIGCC, on pourra probablement en savoir plus (et une fois trouvé l'endroit qui cloche, il faudra probablement instrumenter TiEmu aussi ou utiliser un débogueur, mais on va finir par y arriver
), je vais t'envoyer ça si tu réponds au paragraphe précédent.
(et je vais pas apprendre des langages inconnus juste pour un bug 
).
Pourtant, connaître le C (et un minimum de C++, mais pour rajouter des qDebug au bon endroit, pas besoin de connaître grand chose de la partie "++"
) pourrait t'avancer beaucoup...
(Et je parle de qDebug ici parce qu'utiliser un débogueur va fausser les timings, donc ici c'est la mauvaise solution. Les problèmes de timing sont particulièrement ch**nts à déboguer.)
very (./120) :
En ce qui concerne ce topic: Kevin est un professionnel pour détourner un sujet (genre topic de débutant qui commence à coder => débat nostub/kernel.. )
Forcément, j'explique à un débutant les techniques de programmation actuelles (genre le _nostub), ça fait partie des premières questions qu'il doit se poser (et souvent les débutants posent la question "Nostub ou kernel?" explicitement, d'ailleurs, ignares du bordel que ça va entraîner), ce sont les gens comme toi qui viennent gueuler "le kernel c'est mieux" qui lancent le débat hors sujet. Le fait est, au programmeur TIGCC moyen, le kernel ne sert strictement à rien (parce que TIGCCLIB fonctionne de la même manière avec ou sans kernel), donc si les avantages théoriques que vous revendiquez pour le mode kernel sont réels ou pas n'a aucune importance pour un débutant. Et s'il veut passer au kernel plus tard, il lui suffira d'activer l'option
USE_KERNEL dans les options du projet. Mais ça ne sert à rien d'activer l'option si on n'utilise aucune fonctionnalité du kernel (comme ce sera le cas pour les premiers programmes TIGCC qu'un débutant va coder).
).
Bonne chance avec tes gros blocs monolithiques et avec ta "modularisation" par overlays (morceaux de programmes chargés et déchargés en temps d'exécution, technique très vieille vue pour la dernière fois avec DOS, inutile de nos jours même sur une calculatrice).
).
) pourrait t'avancer beaucoup...
Si c'est oui à la première partie (et non à la deuxième), je compile le RPM pour quelle version de Fedora?
), je vais t'envoyer ça si tu réponds au paragraphe précédent.
