Il faut aussi dire que la "stagnation" de la toolchain a commencé quand plusieurs personnes ont commencé à crier au fork (et fini par concrétiser cette menace) suite à l'introduction de la plus grande avancée dans la chaîne d'outils TI-68k depuis le portage initial de GCC:
le débogueur C et son intégration à l'EDI, réclamant leur ancien émulateur (sans débogueur C) qui n'était déjà plus maintenu pendant des années, dont la version la plus récente était boguée (foirait notamment grave avec un dpi autre que la valeur par défaut et avait quelques problèmes de stabilité qui n'étaient pas présents dans la version originale) et sans sources (qui avaient été perdues), et dont l'intégration à l'EDI nécessitait des hacks (envoi d'appuis de touches) bogués (certains caractères ne pouvaient pas être envoyés) et difficilement maintenables. Et évidemment personne n'avait envie de repartir de la dernière version maintenable (avec sources et sans les régressions du fork), encore plus ancienne, de VTI (l'émulateur en question) pour le rendre intégrable proprement à TIGCC IDE; on exigeait de moi de maintenir les vieux hacks pour interagir avec la boîte noire VTI. Le choix entre les 2 émulateurs (comme le propose maintenant le fork) nécessite aussi du code supplémentaire (non seulement les 2 codes de communication totalement différents, mais aussi le code pour permettre le choix) et complique l'interface utilisateurs de l'EDI.
Le débogueur C n'a pas du tout eu l'appréciation qu'il aurait méritée. J'ai débogué des programmes C pour TI-68k avant et après son introduction, il n'y avait pas photo, même pour moi qui connais l'assembleur 68k. Sans connaissances d'assembleur, VTI était totalement inutilisable pour le débogage (à part avec
printf 
). De plus, le débogage niveau assembleur sous VTI nécessitait l'annotation des fichiers .s avec les lignes de code C, qui était aussi un hack compliqué à maintenir et qui a été remplacée par la génération de vraies informations de débogage. (Donc supporter correctement VTI aurait aussi voulu dire réintroduire ce hack; je ne fais pas les choses à moitié, moi! Le fork, lui, ne s'est pas occupé de ce problème. Et donc les 2 interprétations du flag
-g auraient été en conflit.) Cette réaction (absolument inattendue) à la grande avancée qui avait longtemps été fixée comme
le point où TIGCC passerait de 0.9x à 1.0 a été absolument démotivante.
). De plus, le débogage niveau assembleur sous VTI nécessitait l'annotation des fichiers .s avec les lignes de code C, qui était aussi un hack compliqué à maintenir et qui a été remplacée par la génération de vraies informations de débogage. (Donc supporter correctement VTI aurait aussi voulu dire réintroduire ce hack; je ne fais pas les choses à moitié, moi! Le fork, lui, ne s'est pas occupé de ce problème. Et donc les 2 interprétations du flag -g auraient été en conflit.) Cette réaction (absolument inattendue) à la grande avancée qui avait longtemps été fixée comme le point où TIGCC passerait de 0.9x à 1.0 a été absolument démotivante.
