43Fermer45
Kevin KoflerLe 11/12/2008 à 16:00
Flanker (./41) :
Et pourquoi ne pas intégrer TIGCC à XCode plutôt ?

Adam Thayer l'avait fait, mais son code n'a jamais été fini et n'est plus maintenu (et ne fonctionne pas avec ld-tigcc).

Mais de toute façon ça ne serait pas comparable en confort d'utilisation, compatibilité de projets entre plateformes, adaptation au développement sur calculatrice (options du projet, en particulier les options de TIGCCLIB et de ld-tigcc, coloration syntaxique pour l'assembleur 68k, envoi à la calculatrice ou TiEmu etc.) et ressemblance de l'interface entre plateformes (ce qui permet d'utiliser la même documentation et les mêmes tutoriaux partout) avec KTIGCC.

(Raah, faudrait vraiment que je rajoute "Why don't you just adapt existing IDE XYZ?" à la FAQ parce que cette question vient et revient même si elle n'a aucun sens. TIGCC est un environnement complet et intégré, pas un morceau qu'on peut rajouter à n'importe quoi.)
Lionel Debroux (./42) :
Peut-on appeler "patches incomplets" le fait de comitter d'abord une série complète de patches qui concerne >90% des utilisateurs, avant de committer la même série complète de patches pour un outil différent qui concerne le complément d'utilisateurs ? Je ne suis pas convaincu.

Rien ne garantit que la deuxième série de patches arrive.
Deuxième chose: si la première série fonctionne bien, a un bon design mais que la deuxième série pose problème (implémentation, capacités du langage ou du framework), faut-il faire languir tout le monde d'une feature attendue, sous prétexte qu'il y a un problème avec une petite minorité d'utilisateurs ? Je ne suis pas forcément de cet avis-là.

Si j'ai travaillé des années sur la version *nix pour avoir des versions équivalentes entre les plateformes, ce n'est pas pour réintroduire des fonctionnalités non portables! Toutes les plateformes supportées sont égales (et j'ai l'intention d'inclure aussi OS X dans ces plateformes supportées, mais malheureusement je n'ai pas de développeur OS X dans l'équipe, donc ce que je peux faire pour OS X est très limité, en particulier je ne peux pas proposer des binaires, en revanche, GNU/Linux et W32 sont supportées à titre plein, ce dernier grâce surtout à cross-MinGW), il est hors de question de rajouter des fonctionnalités seulement pour une plateforme. (La seule fonctionnalité qui manque sur une plateforme est le linking USB qui n'est géré que dans KTIGCC, mais je n'allais quand-même pas cacher cette fonctionnalité de la libticables2 seulement parce que TIGCC IDE ne gère que les vieux câbles (même si j'avais pensé à le faire, mais j'ai décidé que ça aurait été une limitation artificielle vraiment stupide).)
Faire du code-and-fix (tu sais, l'approche enfantine essai-erreur, la "méthode" de développement qu'on utilisait avant que la notion de génie logiciel existe - c'est bien parce que ça ne fonctionnait pas qu'on a inventé le génie logiciel, il y a plus de 40 ans), à cause de la philosophie "commit early", c'est vraiment bien, oh trioui

Ça dérange qui, tant que le résultat est du code correct?
La nuit du 20061029 au 20061030, dans les 10 commits qui suppriment VTI pour mettre TIEmu à la place, 3 (30 % ) sont des commits du type code-and-fix: "Fix a Cism and a copy&paste bug in SendFiles.", "Fix compilation errors." et "Remove unused variables.".

Je ne pouvais pas faire autrement, je n'ai pas Delphi, donc j'ai été obligé d'envoyer le code à une autre personne pour le compiler. Prends un exemple en C ou C++ si tu veux discuter de ça.
Une approche de qualité aurait été:
* d'une part, de ne pas utiliser cette philosophie "commit early". C'est en effet un moyen bien connu de dégrader la qualité des commits, puisque cela conduit en pratique à "commit too early". Ailleurs que dans TIGCC, je vois cette philosophie avec certaines personnes dans mon boulot, qui font de temps en temps des commits de fonctionnalités, vite suivis de petits commits avec un effet et un message du style "oups fix compilation error".

Ça s'appelle la transparence.
* de refaire ta série de patches, après le feedback du fait que ça ne compilait pas, pour avoir du code qui builde à chaque point de la série de patches. Là, ça n'est pas le cas, et ce genre de séries de patches ne serait accepté ni du kernel Linux (mainline, -mm est un peu différent), ni de Wine, ni du fork de TIGCC (sauf peut-être en branch expérimentale ET de manière temporaire, puisque ça rend plus difficile les bisections...)... ni d'ailleurs de TIGCC (tu veux des patches bien faits, n'est-ce pas).

Ça s'appelle réécrire l'Histoire et c'est impossible avec un SCM centralisé.

Si tu contribuais suffisamment et avec une qualité suffisante, tu aurais accès en commit et tu pourrais aussi travailler comme ça (mais ça ne voudrait pas dire que tu ne devrais pas implémenter les fonctionnalités de l'EDI dans tous les EDIs à peu près en même temps, bien sûr pas forcément dans le même commit, mais en tout cas dans la même release (sinon revert)), mais comme ce n'est pas le cas, ben j'exige des patches adaptés au review.