Lionel Debroux (./73) :
> 4. mettre à jour les cross-references dans toute la documentationOui, et ça irait mieux avec un système mieux fait et mieux maintenu.

Je prévois de refaire les outils de documentation, mais je compte de faire ça après le passage à KTIGCC 2, comme ça je n'aurai qu'un seul format de sortie à gérer (Qt Assistant, plus de CHM). Le format ne devrait pas changer radicalement, mais je compte faire en sorte que:
* on ne doive plus préciser le répertoire d'une fonction réferencée, comme ça changer une fonction de header deviendrait beaucoup plus simple (et soit je ferai un outil pour virer globalement les headers des références existantes, soit je ferai que les outils ignorent complètement les spécifications de headers),
* _ROM_CALL_123 puisse référencer BN_powerMod (ROM_CALL nommé d'indice 0x123), comme ça on pourrait documenter un ROM_CALL inconnu sans casser tous les liens.

Pour les cross-references de type callgraph, je pense qu'il n'est pas possible de faire un système de génération automatique qui ne fasse pas d'erreurs, donc je suis pour continuer à corriger les erreurs à la main au fur et à mesure, toute regénération automatique réintroduirait des erreurs déjà corrigées. Quant à noter les corrections manuelles, il y en a eu tellement que ça n'aurait pas changé beaucoup la situation. Il y avait vraiment beaucoup d'erreurs dans le callgraph automatiquement calculé.

Mais comme dit plus haut, les nouveaux outils ne pourront être développés qu'après KTIGCC 2.

Ceci étant dit, ça te va bien de parler de tests de régression, quand tu ne testes même pas ton propre boulot avec des softs pourtant courants, par exemple TI-Chess

TI-Chess est un des programmes que je teste le plus. Mais pas forcément la dernière version (j'ai utilisé la même version pendant longtemps pour pouvoir comparer les tailles), et puis une régression de taille, comme toute autre régression d'optimisation, n'est en général pas un blocker.

Sur le reste de TIGCC(LIB), il y en a, des reports et corrections de bugs

Des reports oui, des corrections, pas vraiment.

mais je crois qu'il n'y a pas tant de bugs que ça, en fait ^^

Effectivement, et heureusement.

Martial, entre autres, t'en a contribué une qui n'a pas été intégrée, je crois.

C'est une optimisation de 2 octets comme les tiennes (ou peut-être 2 fois 2 octets, mais 4 octets ne sont pas non plus ce qui va changer le monde).

Jesse Frey et myself (principalement) avons apporté un certain nombre d'optimisations aux routines de grayscale 2 plans,

Elles ont déjà été mergées.

tu n'es pas très bon en optimisation, et tu fais ch*** les autres pour qu'ils optimisent à fond taille

Je ne vois pas du tout le rapport entre la qualité d'optimisation ("tu n'es pas très bon en optimisation") et le choix de quoi optimiser ("à fond taille" par opposition à "à fond vitesse").

De plus, pour revenir au sujet, si tu veux voir de l'optimisation de vraiment mauvaise qualité, regarde le code sorti par la version VB de ETP. Je n'ai pas encore regardé si ce que sort la version C++ pre-alpha actuelle est mieux, mais vu que je n'ai trouvé rien lié à l'optimisation dans les sources, je ne m'y attends pas à mieux. Le code assembleur de TIGCCLIB est beaucoup meilleur que ce code, et normalement aussi mieux que ce que sort GCC (si ce n'est pas le cas, dis-le moi et je remplace la routine en question par une version C ). La qualité d'optimisation est une mesure relative.

Maintenant, si pour toi c'est de la très mauvaise optimisation de gaspiller 2 octets sur une routine de 1 KO, va développer pour les PICs, ils cherchent des personnes comme toi. Sur les 68k, on n'est pas à 2 octets près!

Pour moi, avec un mainteneur moins tâtillon, plus ouvert à d'autres idées et aux points de vue différents des autres (tu as quand même pas mal d'idées très arrêtées sur certains sujets, ce qui rend difficile la discussion avec toi... cf. entre autres ta vision du MDA/MDE, dans Algorithmie et optimisation), plus sympa avec nombre d'autres membres de la communauté - en d'autres termes quelqu'un avec qui on pourrait avoir _envie_ de bosser, un "benevolent dictator" - TIGCC pourrait avancer plus vite.

Tu le sors d'où ce mainteneur? De ton derrière? S'il y avait d'autres personnes que moi intéressées par la maintenance de TIGCC, ça se saurait! (On va quand-même essayer une fois de plus: Si vous êtes intéressés, contactez-moi, aidez-moi, ou si vraiment vous ne me supportez pas, maintenez votre propre fork (même si j'espère qu'on puisse travailler ensemble plutôt que l'un contre l'autre! Ça serait beaucoup plus productif), mais faites quelque chose!)