25Fermer27
Lionel DebrouxLe 17/09/2008 à 20:55
./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 roll
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.]