Il est vrai que tu as organisé TIGCC de sorte à ce que tu sois presque tout seul à faire tout, donc il est un fait que c'est d'autant plus lourd pour toi...
c'est très difficile de reviewer et tester 8 lignes de code présentes dans la plupart des programmes AMS nativeC'est parce que ce code est présent presque partout qu'il a besoin d'attention particulière.
1) Prétexte non valable: l'attention particulière de plusieurs personnes, ce code l'a déjà eue.
2) Prétexte non valable: reviewer huit instructions, c'est quand même vraiment pas la mort.
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.Je suis avant tout pour la correction du code, l'optimisation c'est bien, mais pas si on risque d'introduire des erreurs pour gagner pas grand chose au final.
1) Avec la review de plusieurs personnes, et le programme de test ultra-fort que Joey t'a envoyé, qu'est-ce que tu veux de plus ??
2) "pas grand chose"... tu nous as déjà fait tout un plat, à plusieurs reprises, quand on a déroulé des boucles (parfois, pour une perte de place de seulement deux octets - DoubleSpriteDimensions, par exemple !) dans des routines graphiques qui ont besoin d'être rapides... et quand on diminue de 16 octets un code qui est présent dans la quasi-totalité des programmes, c'est "pas grand chose" ??
Tu te fous vraiment de la figure du monde...
La version des routines de Joey dont il m'a causé ce mois-ci, est une version qui comprend les spécifiques AND, OR, XOR et RPLC + la générique qui fait ces quatre modes de dessin. Pas de documentation HSF associée aux fonctions spécifiques, pas de documentation HSF associés aux fonctions génériques.
Joey n'a pas indiqué qu'il était contre un merge de ses routines sans les versions spécialisées, et n'a pas commenté en bien ou en mal l'indication du fait que les routines Sprite8, Sprite16 et Sprite32 étendues par ses soins et optimisées par mes soins (je lui ai envoyé les sources modifiés), passées avec succès à travers le même programme de test ultra-fort, feraient partie de la prochaine release de GCC4TI.
Après tout, il est quand même loin d'être dommage que des routines dont au moins deux personnes se sont occupées, à au moins trois reprises au total, la première fois il y a plus de sept ans (une éternité en informatique !), soient ENFIN proposées à la communauté !
Et je ne vais pas publier les contributions pour que vous les mergiez avant moi. Vous ne le faites pas non plus, tu ne le fais même pas pour tes propres modifications, cf. le patch dump juste avant la release.
Je te retourne la remarque: allons-nous toujours publier sur le champ des contributions de qualité beta, dont nous savons qu'elles nécessiteront certainement des modifs importantes (et ça a été le cas quand on a fait des tests sur OpenSolaris 2009.06, par exemple) et qu'elles seront releasées dans moins de deux semaines ?
La review et les échanges de patches ont été faits principalement, mais pas exclusivement, par mail.
Vrai, mais à nuancer nettement par le fait que les composants Delphi changent peuIls changent peu parce que personne ne veut les maintenir
Faux, tu sais très bien qu'on (GCC4TI) dispose de Delphi.
De plus, il y a trois mois (31 mars), sur #tigcc, je t'ai proposé de compiler les softs Delphi. Ca m'étonnerait que tu me donnes la permission de poster ta courte réponse
Votre manière de fonctionner est contraire à la GPL, parce qu'elle demande d'indiquer la date de tout changement, pas la date du gros dump, avec des modifications séparées mélangées en une seule.
Si c'est vraiment ça que demande la GPL (??!), alors nombreux sont les projets, à commencer par le kernel Linux et ses 30-50K patches par an, qui ne respectent pas la manière de fonctionner GPL, il me semble... et c'est bien mieux ainsi, d'ailleurs, parce que c'est clairement improductif de mentionner chaque changement !
Le truc que tu sembles ne pas comprendre, c'est que le logiciel, ce n'est pas la même chose que l'Histoire... On ne peut évidemment pas réécrire des _faits_ de la vie réelle, mais le logiciel n'est pas un fait de la vie réelle. Le logiciel est TRES différent de la vie réelle.
Et puis tout ça ne change rien au fait que vos modifications n'étaient pas publiques jusqu'au gros patch dump.
Toute cette discussion ne change rien au fait que tu passes BEAUCOUP plus de temps à troller, ici et ailleurs, plutôt qu'à faire ton boulot d'unique mainteneur sur TIGCC.
Et tant pis pour toi si tu n'étais pas sur #tigcc quand on a parlé des routines de sprites de Joey il y a quelques mois.
Je ne me souviens pas d'avoir lu ça...
Si c'était entre le 3 ou 4 janvier et le 31 mars, c'est facile à expliquer: un certain Kevin Kofler, 26 ans aujourd'hui, m'avait banni après après que j'aie mentionné sur ce forum qu'il nous avait insultés (un mot + un timestamp). L'insulte était, outre un manque de respect, venant de la part de quelqu'un qui se plaint avec véhémence quand on l'insulte, une violation des règles du chan. Le fait de révéler l'insulte sans avoir demandé la permission (que je n'aurais pas obtenue, de toute façon...
) était aussi une violation des règles du chan.
Et encore, 'assholes' était carrément gentillet à côté d'un truc que Kevin s'est permis de poster en juin. Penser ce genre de choses, c'est déjà mal, mais se permettre de l'écrire en public (surtout quand on est op, et par là-même censé montrer l'exemple...), c'est complètement inadmissible. Si quelqu'un avait écrit ça à son sujet, il aurait été kb de façon définitive... Je n'ai pas testé, évidemment
Bref, je crois qu'on va laisser "Kevinou partout" à ses trolls et passer à des choses plus constructives...
[EDIT: correction d'une balise mal fermée.]
[EDIT2: Kevin me fait indirectement remarquer que ce n'est pas "ce mois-ci" qu'il a posté cette insanité, c'est en juin]