Tout d'abord, bon anniversaire Kevin
Ensuite: merci pour ta constructivité et ton objectivité habituelles
Je vais répondre point par point au tissu de conneries que tu nous as une nouvelle fois pondu, pour laisser une trace argumentée, contenant des faits, du fait que tu écris de la merde.
Inutile de chercher à répondre si tu n'as rien d'autre de plus constructif à dire.[quote]
déplacement de la plupart des "pctools" de la TIGCC Tools Suite dans l'environnement de développement, qui est leur place logique
Pas du tout, ces outils n'ont pas grand chose à voir avec la chaîne d'outils[quote]
Ce n'est ni l'avis de Thomas (que j'ai
évidemment consulté avant de faire le changement) ni le mien.
et peuvent être utiles aussi séparément.
Oui, c'est bien pour ça que:
ce qui veut dire que par exemple, ttbin2oth peut être utilisé sans installation supplémentaire de programmes
Et du coup tu te tapes l'installation de tout GCC4TI si tu as juste besoin de ttbin2oth.
Faux. Une précédente discussion que nous avons eue sur le sujet (flemme de retrouver le lien) fait ressortir la nécessité de continuer à fournir une release séparée des TI-68k Developer Utilities (ne serait-ce que pour ceux qui utilisent TIGCC, puisque tu n'as manifestement pas l'intention de répercuter ce changement).
Ca ne changera que quelques lignes dans le processus de build des TI-68k Developer Utilities (en gros, cp des .c depuis le répertoire qui va bien, paramétrable par une variable définie dans le script / Makefile).
deux douzaines de conflits de noms entre exemples
"Conflits" genre "le même nom on-calc"?
Oui.
C'est normal, ces exemples ne sont pas faits pour être envoyés tous en même temps à la calculatrice, ce ne sont que des exemples!
Mais ces conflits de nom font
chier pour les tests de non-régression:
création d'un script qui compile les examples
Ne sert à rien, il y a des .tpr pour chaque exemple, je ne vois pas l'intérêt de compiler tous les exemples en même temps. De toute façon, leur but primaire n'est pas d'être compilés tels quels, mais d'être lus et adaptés. C'est de la documentation, ce ne sont pas des programmes faits pour être utiles tels quels (avec l'exception des 2 jeux de Zeljko Juric).
La compilation de tous les TPR en même temps a trouvé trois bugs dans les outils, une erreur de compilation présente depuis 2005 (ce qui montre que tu n'as pas compilé ces TPR depuis 2005, même pas comme tests de non-régression pour les versions de GCC & binutils que tu as releasées entretemps !) et un warning... en effet, ça ne sert absolument à rien.
TIGCC ne dispose même pas du degré zéro de la qualité du logiciel que sont ce genre de tests de non régression triviaux.
Il faudra du temps et des efforts pour améliorer l'héritage qualité de TIGCC...
SAVE_SCREEN (une des sections du code de démarrage les plus utilisées) : -16 octets. Cette optimisation a été contribuée à TIGCC il y a au moins deux ans, mais elle n'a pas été appliquée dans TIGCC, bien que le code de SAVE_SCREEN soit testé par de nombreux exemples ;
Il faut tester les modifications intensivement parce que ce code va se retrouver dans presque tous les programmes et faire ça pour seulement 16 octets n'était tout simplement pas ma priorité.
1) c'est très difficile de reviewer et tester 8 lignes de code présentes dans la plupart des programmes AMS native
2) tu nous emmerdes depuis des années avec ta défense de l'optimisation taille à fond, mais tu ne l'appliques pas dans tes propres programmes.
Sprite8/16/32. Même si les nouvelles routines supportent un mode de dessin supplémentaire (RePLaCe) par rapport aux anciennes routines, elles sont plus petites et plus rapides. Une version plus ancienne de ces routines a été contribuée à TIGCC en octobre 2005, en même temps qu'un programme de test, mais ces routines améliorées n'ont pas été appliquées dans TIGCC ;
Parce qu'il n'y avait pas de documentation.
Faux (mauvais prétexte). On parle des trois seules routines de sprite de TIGCCLIB, Sprite8, Sprite16 et Sprite32, qui restent encore et toujours les versions non optimisées de 2001 environ, et cela malgré:
[ul][li]des optimisations que je t'ai envoyées en mai 2002 (plus de sept ans !), puis en octobre 2003, c'est à dire à peu près au même moment que ces optimisations étaient appliquées à ExtGraph (donc elles étaient testées !);[/li]
[li]les optimisations supplémentaires et le mode de dessin supplémentaire qui t'ont été contribuées par Joey Adams en octobre 2005. Même au cas où il n'aurait pas documenté SPRT_RPLC,
ça t'aurait pris cinq minutes de le faire, soit
moins que le temps que tu as passé cette nuit à nous pondre le tissu de conneries qu'est ./4...[/li][/ul]
Le programme de test de Joey Adams a trouvé des bugs dans des routines d'ExtGraph, sur des parties autres que les optimisations que j'avais contribuées en 2002 et 2003: ces bugs ont été corrigés dans les jours qui suivaient le report, en octobre 2005 (r11 du SVN).
Si je me rappelle bien, on m'a envoyé la documentation depuis (assez récemment), je n'ai juste pas eu le temps de la merger.
J'espère pour toi que tu as publié ce qui t'a été contribué ? Si ce n'est pas le cas, tu ne peux pas te plaindre qu'on ait attendu maximum 10 jours pour committer des patches, surtout des patches qu'on a testés et re-testés pendant ce temps...
(Et si vous avez refait la documentation au lieu d'utiliser celle qu'on m'a envoyée, tant pis pour vous, fallait attendre...)
Attendre quoi ? Que quelqu'un qui s'assoit sur certaines contributions depuis 7 ans (!!!), qui est super occupé par ailleurs (et qui s'occupe de se donner de l'occupation inutile...), et qui n'a peut-être même pas publié les contributions, fasse quelque chose ?
Le
fait est qu'à la date du 30 juin 2009, dans le repository CVS de TIGCC, il n'y a eu que six commits depuis le 3 janvier 2009 (release de GCC4TI 0.96 Beta 9). Parmi ceux-ci, quatre sont, dans les faits, des backports de GCC4TI; un corrige une typo; et un ajoute deux lignes, certes intéressantes, mais dans la doc des outils de doc, outils qui sont utilisés par environ trois personnes dans le monde... Même des trucs qui t'ont été reportés sur #tigcc (pour autant qu'il me semble, l'endroit que tu préfères pour ce genre de choses), n'ont pas été corrigés !
Ne parlons pas des patches qu'on a contribués il y a 9 mois, avant la première release de GCC4TI.
TIGCC n'est peut-être pas un projet mort, mais en tout cas, il n'est pas très vivant
contournement trivial pour une limitation des outils de documentation spécifiques à TIGCC/GCC4TI
Contournement qui fait exactement le contraire de ce qui est désiré.
Mais qui corrige dans la pratique le plus gros défaut à l'utilisation de ces outils, permettant ainsi d'avancer le boulot, au bénéfice de la communauté.
Le seul use case un peu convaincant pour la réécriture des outils de doc est l'ajout du format de sortie Qt4... et encore, puisqu'il existe d'excellents lecteurs libres de CHM pour les divers *nix. La génération du CHM est un problème pour toi, mais pas pour nous: les packages binaires que
nous avons générés et testés montrent que nous disposons d'un panel important d'OS, Windows compris.
La participation à un projet collaboratif ouvert est tellement plus facile, et plus agréable, quand on peut discuter en groupe, décider en groupe, et partager le boulot
ajout de la capacité de cross-compiler, pour faciliter la production de releases futures
Intéressant, mais certainement pas indispensable... Et gérer cross-MinGW dans ces scripts est totalement inutile, il n'y a pratiquement que la personne qui produit les binaires officiels qui a besoin de compiler avec cross-MinGW et de toute façon ça ne peut pas être entièrement automatisé tant qu'il reste des composants Delphi (qui ne peuvent pas être cross-compilés).
Vrai, mais à nuancer
nettement par le fait que les composants Delphi changent peu
Vous n'allez pas me raconter que vous avez codé toutes les fonctionnalités qui n'étaient pas dans le dépôt la veille (22 commits, et je n'ai pas compté le dernier parce qu'il a visiblement été effectué après le code dump) en 2 minutes. 
En deux minutes, non, on ne va pas le raconter, parce que ce n'est pas crédible
En moins de deux semaines (depuis le 20 juin), avec plusieurs itérations de beta tests et de multiples réécritures d'historiques (scripts de build: pousser les bugfixes au point le plus tôt où ils avaient du sens), oui, on va te le raconter, parce que c'est un fait.
La réécriture itérative des commits donne un historique beaucoup plus clean que le commit-too-early-and-fix-afterwards (on aurait eu une bonne quarantaine de commits si on avait utilisé cette ""méthode"" de travail !). C'est une méthode de travail autre que la tienne, mais sache que plusieurs itérations et réécriture d'historique sont les méthodes de travail utilisées avec grand succès par, entre autres, les gros projets que sont le kernel Linux et Wine: c'est la bonne façon de faire, point à la ligne.
Et puis bon... ça te va bien de te plaindre qu'on n'a pas tout committé absolument tout de suite, toi qui ne prends pas le temps de committer des optimisations et contributions qui attendent, pour certaines, depuis plus de sept ans...
Conrad principalement, et peut-être Joey (qui n'est pas connecté en permanence) pourront te confirmer qu'on a mentionné sur #GCC4TI à la fois les modifs du build system et les optimisations. Tant pis pour toi si tu n'étais pas sur #GCC4TI
Franchement, est-ce que ça fait une grosse différence pour la communauté de retarder de moins d'une semaine (les patches optimisation sont dans la deuxième moitié de la série, ils ont été faits après les patches build system) le commit d'optimisations qui attendent, pour certaines, depuis des années tu t'en occcupes ?
Non, très clairement. Au contraire, cette semaine a justement été utilisée à faire plus de tests (pour certains de ces tests, ça consiste juste à modifier quelques caractères dans un TPR pour qu'une option du code de startup soit testée...) ?
Quant aux histoires de coloration syntaxique: les réglages ne sont pas mis à jour automatiquement parce qu'ils peuvent avoir été modifiés par l'utilisateur, c'est fait exprès.
On en a déjà discuté tous les deux: s'il n'y a aucun moyen de détecter de quelle version l'utilisateur dispose (et c'est le cas, c'est dommage que Sebastian n'ait pas pensé à versionner
), il n'y a aucun moyen simple de proposer un jour,
si nécessaire, un upgrade automatique qui ne détruise pas les modifications de l'utilisateur.
On a donc ajouté un tel moyen de détecter de quelle version l'utilisateur dispose, par la création de la clé de version lors d'un Reset (qui crée un état cohérent et connu des définitions). A partir de là, on a un point de base à partir duquel détecter les différences.
Ces modifications ont clairement été développées ailleurs et transvasées sur le dépôt public juste avant la release. Ce n'est pas ça que j'appelle "développement ouvert". Et après vous m'attaquez parce que je ne committe pas certaines contributions tout de suite, mais compte le faire avant la release... 
), il n'y a aucun moyen simple de proposer un jour, si nécessaire, un upgrade automatique qui ne détruise pas les modifications de l'utilisateur.
