Flanker (./174) :
Parce qu'utiliser un logiciel lourd (surtout vu les dépendances ) à la place d'un logiciel qui fait 2Mo qui ne m'apporte rien de plus (à part une interface que j'abhorre) n'est pas contraire à la raison ?

Ça fait longtemps qu'il y a une interface "une seule grosse fenêtre" style VTI pour le débogueur. (Enfin, il y a aussi la Source Window de Insight, mais les autres fenêtres d'Insight sont cachées par défaut.)

Flanker (./176) :
Mais surtout que les bugs de VTI ne concernent pas ses utilisateurs dans 99,9999% des cas...

Euh si, je t'assure qu'ils concernent beaucoup plus que 0,0001% des utilisateurs. Peut-être pas toi, mais tu n'es pas le centre du monde.

squalyl (./177) :

Kevin Kofler (./173) :
ont autre chose à faire que de débogueur du code C au niveau assembleur, ce qui, je t'assure, est absolument pénible, je l'ai fait quand TiEmu avec GDB n'était pas encore disponible

J'en ai rien a foutre de ton avis, on parle pas de toi kevin kofler centre de l'autriche mais bien de tous les autres.

Ce n'est pas un avis personnel, c'est un fait appuyé entre autre par mon expérience personnelle (qui prouve que je ne parle pas sans savoir).

As-tu déjà essayé de déboguer un programme C avec le débogueur de VTI? Non? Alors comment veux-tu savoir à quel point c'est pénible?

Vas-tu sérieusement nous prétendre que:
1. envoyer le programme à la main (parce que si tu cliques sur Run dans l'IDE de GCC4TI ou une version obsolète de TIGCC IDE qui utilise VTI, il est lancé directement sans breakpoint et tu n'as souvent aucune chance de bloquer VTI avant que ça plante),
2. mettre un Program Entry Breakpoint à la main (en espérant que tu utilises un AMS <= 1.05 pour la version de Rusty ou <= 2.09 pour la version modifiée et boguée de JM, parce que sinon ça ne marche pas),
3. lancer le programme à la main,
4. sauter le code de démarrage à la main, en cherchant péniblement à trouver le saut vers _main, VTI ne te donnant aucune information de quel saut il s'agit (il y a d'autres bsr dans le code de démarrage, par exemple pour les relogements en des formats compressés),
5. faire du single step en, pour chaque instruction C:
5.1. regardant les commentaires dans le fichier .s produit par GCC qui donnent les lignes C correspondantes (commentaires qui d'ailleurs ne sont plus générés par les versions récentes de TIGCC, et GCC4TI ne les a pas réintroduits, donc tu n'as même plus cette information!)
5.2. sautant à la main les instructions assembleur correspondantes à l'instruction C
6. vérifier les valeurs des variables en essayant de comprendre à partir de la source assembleur dans quel registre ou emplacement mémoire elles se trouvent
est plus simple que:
1. cliquer sur Debug / Run et avoir le programme automatiquement lancé et arrêté au début du code de démarrage
2. rien (tout est automatique)
3. rien (tout est automatique)
4. cliquer sur Continue pour sauter le code de démarrage
5. faire du single step en utilisant les boutons Step et Next de Insight (ou les raccourcis s et n)
6. vérifier les valeurs des variables en les lisant directement dans Insight (par exemple en passant la souris au dessus de la variable dans la source)
??? Arrête de raconter n'importe quoi!

1 tu te moques du monde car tu sais très bien que c'est TiEmu (ou bien TiEmu-fork aka Emu-tigcc (ça émule tigcc? ))

Emu-TIGCC = émulateur de (faisant partie de) TIGCC ou émulateur pour (à utiliser avec) TIGCC. Pour moi, l'émulateur et son débogueur niveau sources intégré font partie intégrante de la chaîne d'outils, d'où ce nom.

2 si tu oses dire "en plus de vti" pourquoi n'est il plus supporté?

L'utilisateur peut garder VTI à côté si ça l'amuse, mais TIGCC utilisera TiEmu ou Emu-TIGCC. C'est une dépendance comme une autre. A priori, les fonctionnalités proposées à l'utilisateur, c'est la possibilité de tester et déboguer ses programmes sur son ordinateur, l'émulateur utilisé en interne pour proposer ces fonctionnalités est un choix d'implémentation qui ne regarde que le développeur. Et donc de ce point de vue-là, TiEmu/Emu-TIGCC permet de proposer beaucoup plus de fonctionnalités que VTI (débogueur C!) et aucune fonctionnalité en moins, donc quel intérêt de proposer les deux?

Pourquoi t'obstines-tu à ignorer les arguments solides pour laisser tomber le dinosaure qu'est VTI et à nous ressortir sans arrêt le même FUD? L'utilisateur ne perd aucune fonctionnalité en passant du couple (vieux TIGCC, VTI) au couple (nouveau TIGCC, TiEmu ou Emu-TIGCC).

parce qu'il pourrait etre moins con que TIFS.

Le choix de TIFS n'est pas con, il est logique: pour proposer un débogage convenable, il faut un émulateur conçu pour la chaîne d'outils, l'émulateur en fait donc partie intégrante. D'où l'émulateur livré avec TIFS et d'où Emu-TIGCC (avec "TIGCC" dans le nom). On ne peut pas gérer n'importe quel vieil émulateur que tu nous sors.