TIGCC, contributions, fork... - Page 1

Je pense que JRAD est tout à fait approprié pour cette "discussion" démarrée par Kevin hier soir dans le FlashChat:

22:49 Kevin Kofler: Voilà pourquoi je ne merge pas les contribs à TIGCCLIB sans vérif: void OO_GetFlashAppSize (HANDLE TaskID) et on est censés lire la taille comment?

22:50 Kevin Kofler: (Trouvé dans les contributions de Lionel encore en attente. Il faut clairement un unsigned long comme valeur de retour là, pas void...)

23:35 Flanker: et l'intérêt de le poster dans le flashchat, ?

23:39 Kevin Kofler: Si je crée un topic, on a encore 36 pages de flamewar.

23:42 Flanker: tu pouvais lui envoyer un mmsg...

23:42 Flanker: donc tu tapes sur Lionel sans qu'il puisse répliquer...

01:46 @Zephyr: et éviter de polluer le fC en t'en servant pour régler tes conflits perso

07:41 Kevin Kofler: C'est vous 2 qui polluez le FlashChat en me tapant dessus au lieu de rigoler devant un tel WTF évident.

07:42 Kevin Kofler: Pour vous, le FlashChat, c'est juste pour les vidéos pourries genre les combats entre chien et serpent? C'est bien triste... Il y a plus intéressant!

08:06 Lionel Debroux: Il est vrai que toi-même ne fais jamais d'erreurs

08:15 Lionel Debroux: Trouvé dans un des fichiers que je t'ai envoyés: "#define OO_GetFlashAppSize _rom_call(unsigned long,(HANDLE),477)"

08:17 Lionel Debroux: Autrement dit, même si le .hsf est effectivement faux, tu as l'info correcte, et tu râles pour le plaisir de taper sur les autres. Comme d'habitude.

08:22 Lionel Debroux: Ajoutons que tu n'as 'que' 5 ans de retard sur les contributions à la doc.

08:23 Lionel Debroux: Au moins. En effet, la section concernant ROM_CALL_477 dans mon fichier était déjà identique le 3 octobre 2003.

08:30 The_CUrE: Kevin : GTFOPLZKTHXBAI

08:31 Lionel Debroux: Le fait que tu te plaignes des contributions semblerait indiquer que tu mets un terme à la trop longue période...

08:31 Lionel Debroux: ... où rien de nouveau ne se passait sur TIGCC. C'est un effet du fork ?

08:35 Lionel Debroux: Si c'est un effet du fork, les gars, on a déjà atteint un des buts

08:42 Ximoon: Franchement Lionel, t'aurais pu répondre (aussi) dans un topic...

[EDIT: correction de smilies et whitespaces]

09:07 Kevin Kofler: J'ai regardé ce fichier pour répondre à une question sur MobiFiles. Cette doc a besoin de mois de relecture, temps que je n'ai pas.

09:09 Kevin Kofler: Et je ne peux pas regarder dans tout le bordel que tu m'as envoyé. J'ai fait plus vite de trouver le bon proto pour répondre à la question moi-même.

09:11 Kevin Kofler: Et c'est plutôt votre fork où "rien ne se passe". Et puis tu pollues le FlashChat.

1) Des mois de relecture, c'est peut-être beaucoup dire
2)

Et je ne peux pas regarder dans tout le bordel que tu m'as envoyé

Suis-je le seul à penser "-peux +veux" ?

3) Naturellement, tu as des preuves qu'il ne se passe rien dans notre fork ?
Ce n'est pas moi qui ai commencé à polluer le FlashChat

09:33 The_CUrE: Kevin l'hôpital se fout de la charité, allez vous engueuler sur IRC ou sur un thread...

09:51 Ethaniel: KK > Si tu voulais juste « rigoler devant un tel WTF », le message de 22:49 suffisait, pas la peine de citer Lionel pour lancer les hostilités

09:55 The_CUrE: Et puis si tu trouves que seuls tes WTF sont drôles, c'est très grave...

Ethaniel: carrément.
Même si j'aurais probablement introduit le fait que ce soit une contrib, au cas où personne ne l'aurait fait avant moi (parce que j'_essaie_ de reconnaître quand j'ai mal fait quelque chose), le ton et le contenu de la discussion aurait été tout à fait différente s'il n'y avait eu que la partie 'WTF' du message de 22h49... Par exemple:

22:49 Kevin Kofler: void OO_GetFlashAppSize (HANDLE TaskID) et on est censés lire la taille comment?
[pas de 22h50]
...
[plus tard] Lionel Debroux: copier/coller/mal modifier
Un fichier de doc (que tu as...) contient la définition correcte, mais le HSF est effectivement faux. Merci pour le report, je vais corriger ça de mon côté.

Ben ouais, mais Kevin ne peut pas se sentir bien s'il ne rabaisse pas les gens...

[sondage=16123]

Les deux, mais OSEF.

Par contre j'ai du manquer une étape. C'est quoi cette histoire de fork?

Si tu as quelques heures à perdre: topics/113677-kdewin-foutage-de-geule , en particulier à partir de #116 et #153.

Lionel Debroux (./3) :
3) Naturellement, tu as des preuves qu'il ne se passe rien dans notre fork ?

Ce que je vois, c'est qu'il n'y a rien de visible, et que tu as refusé de me montrer ce que vous avez, ce qui me laisse présager que vous bluffez et que vous n'avez rien en réalité.


Quant à tes contributions, je reconnais avoir fait une erreur: l'erreur d'avoir accepté les contributions en ce format et d'avoir pensé avoir le temps et la motivation de les mettre en l'ordre moi-même. Comme tu peux le voir, ça n'a pas été le cas pendant ces 5 années et ça ne risque pas d'être le cas maintenant. Bref, j'aurais dû faire ce que font tous les grands projets libres (GCC etc.): refuser la contribution clairement parce qu'elle est inexploitable sous cette forme. Et c'est ce que je fais maintenant.

Lionel, visiblement, tu as plus de temps que moi actuellement, donc je ne vois pas pourquoi ce serait à moi de nettoyer ce que tu n'as soi-disant pas eu le temps de nettoyer. Tes contributions ne pourront être mergées que si tu:
* les relis! J'ai ouvert un seul fichier hier soir et ce fichier était faux (au point d'être inutilisable - d'ailleurs, il y a aussi le nom "TaskId" qui est bizarre dans ton prototype, le handle est un AppId, n'est-ce pas?), ce qui correspond à un taux d'erreur de 100%.
* les testes! Strict minimum, que les définitions proposées pour les headers compilent, ce qui n'a pas été le cas de certaines contributions déjà mergées.
* les rends compilables avec les outils de documentation! Ou si vraiment c'est trop de travail, tu peux aussi faire la refonte des outils de documentation qui est nécessaire (je propose de 1. porter le code existant vers du C/C++ et 2. rajouter les fonctionnalités qu'il nous faut, par exemple une hash table de toutes les fonctions pour qu'on puisse les référencer rapidement sans devoir spécifier le header à chaque fois). et enfin
* les découpes en morceaux les plus indépendants possible et mergeables l'un après l'autre! Notamment, si le patch A contient des références à des fonctions documentées dans le patch B qui vient après A dans la série et si ces fonctions sont dans unknown.h quand le patch B n'a pas encore été appliqué, alors le patch A doit garder les références vers unknown.h et c'est au patch B de mettre à jour la référence! C'est ce problème qui m'a empêché de faire un merge progressif de tes modifications, tout dépend de tout à cause des références. Là encore, une refonte des outils de documentation peut probablement aider.

Si tout ceci n'est pas fait, alors j'ai bien peur que tes contributions ne seront jamais mergées, je n'ai plus la motivation de faire ton travail à ta place (dans des projets comme GCC ou le noyau Linux, ce genre d'aménagements sont inéquivoquablement le boulot du contributeur, pas du mainteneur, je ne vois pas pourquoi TIGCC devrait être différent). Et je retiens qu'une documentation incomplète (et j'inclus les prototypes dans les headers dans "documentation" dans ce contexte) est moins grave qu'une documentation fausse, la qualité est plus importante que la quantité.


Et je voulais justement éviter ce débat inutile, mais il fallait forcément que tu rajoutes ton grain de sel partout. (Et Flanker aussi, alors que lui, on ne l'a carrément pas sonné! )

Ca c'est la meilleure, tu l'agresses, mais c'est pas pour débattre, juste parce que c'est rigolo, et maintenant t'es la victime ?

Tu te serais pas auto-diagnostiqué autiste fonctionnel par hasard ?

Tout ce que j'ai fait, c'est justifier pourquoi cette documentation n'est pas mergée en montrant un exemple qui devrait faire sourire, c'est lui qui prend ça comme une agression.

Ce que je vois, c'est qu'il n'y a rien de visible, et que tu as refusé de me montrer ce que vous avez, ce qui me laisse présager que vous bluffez et que vous n'avez rien en réalité.

Crois ce que tu veux, et ne compte pas sur moi pour te donner une indication du contraire tant qu'on n'a pas au moins une feature distinctive de TIGCC qui soit pleinement codée et qui fonctionne (parce qu'avant, ça n'a pas trop de sens de passer du temps de tout compiler, documenter, pour faire une release...).
Nous non plus n'avons pas tant de temps que ça. Comme plusieurs personnes l'ont fait remarquer, ça aurait été beaucoup plus facile de trouver du manpower il y a trois ans.
Une modif que j'ai commencée nécessite un temps de programmation que je ne suis pas sûr de bien estimer (j'ai pu me rendre compte en d'autres occasions que je ne suis pas très bon pour ça), plus un temps important de test. D'autant plus de temps que je suis très fatigué IRL.


C'est bien que tu reconnaisses que tu as fait une erreur. C'est pas si souvent...
C'est juste dommage qu'il ait fallu cinq ans pour une écriture aussi claire (même si déjà présente dans le topic kdewin, par exemple) du fait que tu refuses mes contributions _dans l'état où elles sont_, pour des raisons qui sont tout à fait valables.
Reconnaissons quand même qu'en pratique, ça n'aurait pas changé grand chose, puisque pendant une bonne partie de ces cinq ans, je n'étais pas dispo pour modifier mes contributions (j'ai déjà tout juste rendu compatibles 89T la plupart des programmes de TICT...).

Lionel, visiblement, tu as plus de temps que moi actuellement, donc je ne vois pas pourquoi ce serait à moi de nettoyer ce que tu n'as soi-disant pas eu le temps de nettoyer. Tes contributions ne pourront être mergées que si tu: [...]

* les deux premiers éléments ne sont que des conséquences de la façon dont j'ai travaillé à l'époque: une double doc, dans les .hsf/.hsh et ailleurs; le fait d'utiliser, en général, les définitions (correctes, sauf exception toujours possible) de mon fichier de tests plutôt que d'utiliser les headers modifiés auto-générés.
Et il faudrait aussi qu'un tiers suffisamment compétent *ayant du temps* vérifie tout avant de l'inclure, que ce soit dans le TIGCC officiel ou le fork...

* on a déjà causé du troisième élément dans le topic de kdewin. Voir la page 9.
Les callgraphs sont probablement faux mais on n'a pas les moyens de les regénérer.
Le fait d'avoir une gestion inconsistente des chemins dans le help system est catastrophique.
Les transformations chemins mixtes -> les chemins avec header, chemins mixtes -> chemins sans header et chemins sans header -> chemins avec header, prennent une centaine de lignes de Perl *lisible* et partagent beaucoup de code. La conversion chemins avec header -> chemins sans header est encore plus simple.
On n'est pas d'accord sur le moyen de résoudre le problème *à court terme* - j'ai passé quelques heures seulement à implémenter mon idée dans le fork de TIGCC, ce qui permet de ne faire la réécriture du système d'aide qu'à plus long terme.
Mais il reste de toute façon le problème de la revue du contenu par quelqu'un d'autre avant une intégration, même dans un fork plus expérimental qu'upstream.

* maintenant, j'ai des idées sur comment on fait une série de patches. Pas à l'époque.

Comme je l'ai écrit dans le topic de kdewin, j'ai progressé depuis que j'ai commencé la programmation. Plus qualitativement: quand j'ai fait le gros de mes contributions à TIGCCLIB, ça ne faisait pas deux ans que je programmais de façon régulière en C - ce que j'ai commencé à faire avec les TI-68k, justement - et je n'avais pas les connaissances de génie logiciel basique.

Tout ce que j'ai fait, c'est justifier pourquoi cette documentation n'est pas mergée en montrant un exemple qui devrait faire sourire, c'est lui qui prend ça comme une agression.

Je ne suis manifestement pas le seul à avoir pris ta formulation comme une agression... Je t'ai du reste montré dans ce topic même, une façon bien meilleure de signifier ce que tu veux, pour que ça ait nettement plus de chances de faire sourire que d'être pris pour une agression.
J'ai pas trop d'illusion, mais souviens-t'en la prochaine fois, que ce soit envers moi ou envers qui que ce soit d'autre...

Kevin Kofler (./12) :
Ce que je vois, c'est qu'il n'y a rien de visible, et que tu as refusé de me montrer ce que vous avez, ce qui me laisse présager que vous bluffez et que vous n'avez rien en réalité.

Venant de quelqu'un qui fait un patacaisse pour ne pas ouvrir son CVS, ceci pour soit disant des questions de méritocratie (cf l'autre topic cité plus haut) ça laisse songeur...

Kochise

Lionel Debroux (./15) :
D'autant plus de temps que je suis très fatigué IRL.

Pas la peine de te surmener Lionel

Kochise (./16) :

Kevin Kofler (./12) :
Ce que je vois, c'est qu'il n'y a rien de visible, et que tu as refusé de me montrer ce que vous avez, ce qui me laisse présager que vous bluffez et que vous n'avez rien en réalité.

Venant de quelqu'un qui fait un patacaisse pour ne pas ouvrir son CVS, ceci pour soit disant des questions de méritocratie (cf l'autre topic cité plus haut) ça laisse songeur...

J'ai déjà dit que ça ne serait que suite au refus de Lionel et co. de travailler ouvertement. Je ne vois pas pourquoi je devrais leur permettre d'utiliser tout mon travail dès qu'il est produit, un patch à la fois, quand ils ne sont pas disponibles à me permettre de faire la même chose.

J'ai toujours été pour le développement ouvert (c'est aussi pour ça que j'ai horreur des systèmes décentralisés comme git qui encouragent de travailler tout seul dans son coin et dumper un énorme code drop à la fin, mais les systèmes centralisés privés ne sont pas mieux), ce n'est que l'attitude de Lionel et co. qui risque de me faire fermer celui de TIGCC.

Lionel Debroux (./15) :
pour des raisons qui sont tout à fait valables.

Enfin tu le reconnais, il aura juste fallu 5 années!

Dommage qu'après tous les nags que tu m'as envoyés (publiquement et en privé) d'enfin merger tes contributions parce que "c'est facile", cet aveu est peu crédible.

Parce que je n'ai pas eu le temps de la tester, et maintenant de toute façon je l'ai perdue.

Comme expliqué à l'époque, les modifications au code de démarrage ne sont pas à prendre à la légère parce qu'il y a des contraintes très strictes sur les registres qui peuvent être détruits, qu'il faut vérifier (et en plus il faut aussi tester le code, dans le cas où on n'a pas vu quelque chose durant la vérification), or ton amélioration détruisait un registre de plus pour gagner 2 octets quelque part dans le code de démarrage, donc le rapport coût/effet est très fortement du côté "coût".

Kevin : si tu n'as pas temps, pourquoi participer (et provoquer) régulièrement à tous ces trolls sur linux, fedora, gpl et consorts sur yaronet alors que tout le monde connait bien ton point de vue ?

Kochise (./17) :
patacaisse

non, pataquès

Kevin Kofler (./22) :
Parce que je n'ai pas eu le temps de la tester, et maintenant de toute façon je l'ai perdue.

et tu te dis mainteneur?

Ah oui, c'est vrai, il y avait aussi le remplacement de memcpy par un bidouillage dans ce que tu avais proposé...

squalyl (./23) :
et tu te dis mainteneur?

Je préfère utiliser mon temps limité pour corriger des bogues que pour faire (ou tester) des optimisations qui économisent un nombre ridiculement petit d'octets (au point où n'importe quelle petite amélioration des optimisations de GCC pourrait être 10 à 100 fois plus efficace sur le programme moyen) et qui risquent d'introduire des erreurs (c'est pour ça que je ne merge plus d'optimisations (aussi "évidentes" qu'elles soient) sans tester, j'ai fait ça plusieurs fois avec des optimisations de Lionel et ça a déjà causé des bogues au moins 2 fois, maintenant c'est fini).

Il y a pas mal de corrections de bogues qui ont été effectuées dans le CVS depuis la bêta 8, il faudrait que je fasse enfin une release.

./18: comment peux-tu à la fois nous reprocher de faire du code expérimental non testé / non documenté et nous reprocher de ne pas releaser tout de suite des modifications même pas finies et dont on n'a pas encore testé la correction ??
Comme le public, tu auras les modifs quand elles seront utilisables. C'est pas affreux, quand même !

Git permet effectivement les gros drops de code. Mais ce n'est pas une obligation.
Sur Wine-devel, j'ai vu par plusieurs fois durant le GSoC le conseil donné aux étudiants de ne pas envoyer plus d'une dizaine/douzaine de patches à la fois, parce qu'il y avait souvent quelque chose à changer dans les premiers patches.
Git permet aussi la réécriture d'historique. Ca, c'est carrément bien pour modifier ses séries de patches tant qu'elles ne sont pas prêtes, plutôt que de committer du code pas bien fini et des bugfixes par dessus.


./19: encore une fois - comme je te l'ai d'ailleurs déjà reproché dans l'autre topic à propos d'un autre aspect touchant aux contributions - tu ne racontes que la partie de l'histoire qui t'arrange
Je maintiens qu'il y a un subset des contributions qui est facile à intégrer.


[EDIT: cross avec ./25.

Bidouillage peut-être, mais code plus petit, évidemment correct, moins consommateur de registres. Un poil plus lent, mais dans le code de SAVE_SCREEN, OSEF carrément.

Je me souviens d'une peephole optimisation des pushes sur la pile - moins efficace que celle implémentée par Pollux dans GTC, d'ailleurs - que tu as mis un certain temps à implémenter après que je te l'aie reportée, alors qu'elle peut gagner des centaines d'octets sur les programmes utilisant beaucoup de __stkparm__ - on est dans le cadre de l'optimisation par GCC que tu décris.
Quand tu l'as enfin fait, tu as codé avec de l'arithmétique sur des nombres signés (ce qui est pourtant une source connue d'embêtements), de telle sorte que le code généré dans ebook crashe une fonction de dialog/menu qui n'apprécie pas qu'on lui passe un argument négatif...
Le test, par sa nature non exhaustive, n'aurait pas forcément sorti ce bug - mais la taille ridicule de ta suite de test n'aidait pas. Tu n'as pas fait mieux que Microsoft, qu'on accuse souvent à raison de fournir des programmes buggés et de les faire debugger par ses utilisateurs après la release.]

la mienne est plus grosse

C'est pas bien de parler ainsi de sa moitié...

Kochise

Kevin Kofler (./12) :
(Et Flanker aussi, alors que lui, on ne l'a carrément pas sonné! )

Bah en même temps, personne ne t'a demandé critiquer gratuitement Lionel dans le flashchat...


Ca donne quand même envie, la vision du libre selon Kevin... Si on l'écoute, on est libre d'utiliser uniquement les logiciels qu'il aime, et rien d'autre. Le fork, c'est bien, mais uniquement s'il y contribue... Bref, aucune liberté...

Lionel Debroux (./26) :
./18: comment peux-tu à la fois nous reprocher de faire du code expérimental non testé / non documenté et nous reprocher de ne pas releaser tout de suite des modifications même pas finies et dont on n'a pas encore testé la correction ??Comme le public, tu auras les modifs quand elles seront utilisables. C'est pas affreux, quand même !

Je n'ai jamais dit que j'allais merger les patches en l'état actuel. Mais 1. ça prouverait que tu ne bluffes pas et 2. tu revendiques le droit non seulement de voir tous mes patches, complets ou incomplets qu'ils soient, mais même de convertir mon dépôt en temps réel en le format de ton choix (au point où tu m'as demandé de changer de système de contrôle de révisions pour te simplifier cette conversion), je ne vois pas pourquoi tu n'es pas prêt à me donner le même accès à tes sources à toi. J'ai toujours été pour le développement ouvert et c'est bien pour ça que TIGCC est actuellement développé dans un CVS public! (Oui, c'est un CVS, mais ça ne m'apporterait rien de changer, ça t'arrangerait juste toi, dans ta quête de tout prendre et rien fournir en retour.)

Git permet effectivement les gros drops de code. Mais ce n'est pas une obligation.Sur Wine-devel, j'ai vu par plusieurs fois durant le GSoC le conseil donné aux étudiants de ne pas envoyer plus d'une dizaine/douzaine de patches à la fois, parce qu'il y avait souvent quelque chose à changer dans les premiers patches.

Mais ce genre d'avertissements ne sont pas nécessaires à ce point avec les systèmes centralisés, où il suffit de rappeler "commit early, commit often" et ça implique automatiquement la publication.

Git permet aussi la réécriture d'historique. Ca, c'est carrément bien pour modifier ses séries de patches tant qu'elles ne sont pas prêtes, plutôt que de committer du code pas bien fini et des bugfixes par dessus.

Ça s'appelle fausser l'Histoire.

./19: encore une fois - comme je te l'ai d'ailleurs déjà reproché dans l'autre topic à propos d'un autre aspect touchant aux contributions - tu ne racontes que la partie de l'histoire qui t'arrange Je maintiens qu'il y a un subset des contributions qui est facile à intégrer.

Le subset en question a déjà été intégré il y a longtemps.

Bidouillage peut-être, mais code plus petit, évidemment correct, moins consommateur de registres. Un poil plus lent, mais dans le code de SAVE_SCREEN, OSEF carrément.

Ça n'empêche pas qu'il faut faire la modification, la tester (les fautes de frappe, ça existe), écrire des entrées dans l'historique etc., tout ça pour combien d'octets? 2? 4? Je ne comprends pas votre obstination à gagner une place aussi minime, alors qu'il y a de quoi gagner beaucoup plus de place, par exemple les améliorations que j'ai faites à -Os, genre les tests séquentiels plutôt qu'en arbre équilibré pour les switches. Ça ne sert à rien de gagner 2 octets sur un programme de plusieurs KO!

Je me souviens d'une peephole optimisation des pushes sur la pile - moins efficace que celle implémentée par Pollux dans GTC, d'ailleurs

Moins efficace comment? Exemples de code généré?

que tu as mis un certain temps à implémenter après que je te l'aie reportée

Parce que ce n'est pas trivial de coder un peephole! D'ailleurs tu as bien remarqué que l'optimisation a posé quelques problèmes, aurais-tu préféré une solution expédiée et encore plus boguée? Et ça a pris un certain temps à développer même avant de pouvoir commencer à tester. Tu fais comme si un peephole se codait comme ça, en claquant les doigts.

alors qu'elle peut gagner des centaines d'octets sur les programmes utilisant beaucoup de __stkparm__ - on est dans le cadre de l'optimisation par GCC que tu décris.

C'est bien pour ça que cette optimisation a été implémentée contrairement aux microoptimisations que Martial (alias Folco) et toi revendiquez actuellement.

Quand tu l'as enfin fait, tu as codé avec de l'arithmétique sur des nombres signés (ce qui est pourtant une source connue d'embêtements), de telle sorte que le code généré dans ebook crashe une fonction de dialog/menu qui n'apprécie pas qu'on lui passe un argument négatif...

Oui, j'ai fait une erreur de programmation. Le codeur infaillible n'existe pas. Et oui, j'ai corrigé l'erreur aussitôt que possible (au moins un des bogues des peepholes a été corrigé moins de 24 heures après avoir été reporté! Je veux voir un tel temps de réaction pour un bogue non-trivial dans un de tes projets) et envoyé le correctif à toutes les personnes concernées dès qu'il était disponible, donc la disruption était minime.

Le test, par sa nature non exhaustive, n'aurait pas forcément sorti ce bug - mais la taille ridicule de ta suite de test n'aidait pas. Tu n'as pas fait mieux que Microsoft, qu'on accuse souvent à raison de fournir des programmes buggés et de les faire debugger par ses utilisateurs après la release.

Effectivement, les utilisateurs sont tenus participer aux tests, c'est bien pour ça que les versions en question sont des bêtas. Pour GCC, j'ai même fait des "bêtas pour les bêtas". Je ne peux pas tout tester moi-même.

Mais une optimisation qui économise des centaines d'octets vaut le coup de risquer une telle régression, une optimisation qui économise 2 octets non.