TIGCC, contributions, fork... - Page 2

Au fait, j'ai oublié de corriger pleinement la grosse connerie de ./19:

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.

Mon aveu est plus crédible que ton post, parce que ton post oublie "juste" les faits. Non, il n'a pas fallu 5 années pour que je reconnaisse que les contribs ne pouvaient pas être mergées telles quelles
Voir le topic de kdewin, où je l'ai de plus mentionné (tu as la mémoire courte et sélective, hmm ?): j'ai commencé à faire de quoi intégrer mes updates il y a plusieurs années, en commençant par des modifs à la doc pour faciliter l'intégration. Pas eu le temps de les finir, et puis j'ai utilisé à l'époque le seul langage que je connaissais, le C, qui est un mauvais choix. Les langages de script "P" (Perl, Python, PHP), ou encore Ruby et certainement d'autres, vont beaucoup mieux.
Si c'est pas une reconnaissance qu'il y avait de bonnes raisons de ne pas merger mes contributions, c'est quoi ?


Dans ./30:

Pourquoi veux-tu à ce point que les forkeurs prouvent qu'ils ne bluffent pas ??
Le fin du fin serait que tu fermes la maintenance de TIGCC (encore plus que ce qu'elle n'est actuellement, je veux dire) avant de nous laisser le temps de pousser, sous forme d'un changeset qui tient debout (donc pas un "commit early, release often" sur un SCM centralisé - notons que tu n'appliques d'ailleurs pas à toi-même au moins la deuxième partie de cette devise que tu viens de nous sortir), des modifs suffisamment visibles pour l'utilisateur par rapport à upstream. Des modifs, il y en a déjà, j'en ai cité une.
Modifs que tu pourrais pourtant, grâce à la GPL et au fait qu'on ne s'amuse pas à changer l'arborescence des fichiers ou faire ce genre de conneries (ben oui, c'est plus de boulot pour nous quand on merge upstream ), réintégrer dans upstream. Exactement comme on peut intégrer les tiennes tant que tu maintiens un repository, avec quelque SCM que ce soit (mais tu n'as manifestement pas envie d'utiliser mieux qu'un des pires SCM, qui ne maintient même pas l'intégrité de ses données...). Ce qu'on te demande, c'est juste de respecter notre façon de faire, dont nous ne sommes pas les seuls défenseurs.
Façon de faire qui changera probablement rapidement, de toute façon: la question n'est pas si on ouvrira l'infrastructure du fork, mais quand... La discussion de 'quand' a été lancée, parce qu'on décide ce genre de choses en groupe.

En cas d'arrêt des commits sur le CVS public de TIGCC, ce serait encore nous qui aurions le mauvais rôle, tu sais si bien y faire. Même si de notre côté, on pourrait expliquer, ce que je fais plus bas, pourquoi on travaille différemment. Sans cette super bouse de CVS, et comme le kernel Linux et Wine, qui sont, avec tout le respect que je te dois, des projets autrement plus complexes que TIGCC.
On sait très bien que tu es parfaitement capable d'arrêter de committer sur le CVS public de TIGCC. Voir l'antécédent d'avoir décidé avec Sebastian, par-derrière, de splitter le forum de TIGCC/TICT si je réagissais comme tu l'attendais, en me faisant remettre les pouvoirs d'admin par Thomas.

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.

Ca s'appelle fausser l'Histoire.

C'est une façon de voir les choses, mais ce n'est pas la nôtre, ni celle du kernel Linux (sous forme de clones de repositories et branches), de Wine (sous forme de séries de patches) et d'autres projets. La réécriture d'historique permet de merger _toutes_ les révisions intermédiaires sur le trunk, et par là-même faciliter les bisections.
Avec SVN, que j'utilise au boulot, on fait:
* commits locaux avec réécriture d'historique au début;
* création d'une branch SVN, à laquelle j'applique les modifs locales;
* revue et éventuellement modification par quelqu'un d'autre, avec éventuellement des merges du trunk s'il est modifié entretemps;
* merge de toute la branch sur le trunk en une seule révision. Ca, c'est nul, parce que si jamais la branch introduit un problème subtil que tu ne détectes que longtemps après - c'est régulièrement le cas sur le kernel Linux, par exemple - tu ne pourras pas savoir laquelle des modifs individuelles de la branch a fait merder un cas qui fonctionnait auparavant. Si tu merges chacune des révisions, tu peux plus facilement savoir quel patch pose problème.

./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.

A vérifier

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é?

GTC est capable, sous certaines conditions d'alignement, de packer quatre move.b en move.l, ce dont est à ma connaissance incapable GCC.
!call Pollux
--- Call : Pollux appelé(e) sur ce topic ...


Si c'est pas simple de coder un peephole qui transforme
move.w #nn1,-(sp); move.w #nn2,-(sp)
en
move.l #(nn1<<16)|nn2,-(sp) | sur une plate-forme little endian, ça serait nn2 qui serait <<16
ce qui est possible parce que sur 68000, sp sera toujours aligné dans du code correct (= qui ne modifie pas exprès sp pour le rendre impair)
j'aurais tendance à voir ça comme une faiblesse du compilo. Surtout quand le compilo n'est autre que GCC, connu pour sa difficulté à comprendre, à modifier et son besoin de réarchitecturage: http://lwn.net/Articles/259157/

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.

Je suis d'accord que le codeur infaillible n'existe pas
C'était une façon de faire remarquer qu'une nouvelle fois, tu n'appliques pas forcément à toi les mêmes critères que ceux que tu appliques aux autres, c'est tout.


[EDITs pour compléter et corriger une phrase écrite un peu vite qui n'avait pas de sens.]

Comme vince, pour quelqu'un qui prétend ne pas trouver le temps, en cinq ans, de faire ce genre de modification relativement mineure, je trouve que tu passes beaucoup de temps à troller inutilement, Kevin.

Lionel Debroux (./31) :
donc pas un "commit early, release often" sur un SCM centralisé - notons que tu n'appliques d'ailleurs pas à toi-même au moins la deuxième partie de cette devise que tu viens de nous sortir

Je sais que je devrais faire des releases plus souvent. Le problème, c'est que ça prend du temps avec tous les trucs à faire (et en plus le CHM doit être créé sur l'OS propriétaire de destination, je n'ai pas trouvé d'outil qui crée un CHM fonctionnel sous GNU/Linux ou WINE, les outils officiels foirent sous WINE).

Mais moi au moins, je publie toutes mes modifications immédiatement dans le CVS, tu es libre de compiler le CVS HEAD si tu ne veux pas attendre la release.

Le fin du fin serait que tu fermes la maintenance de TIGCC (encore plus que ce qu'elle n'est actuellement, je veux dire) avant de nous laisser le temps de pousser, sous forme d'un changeset qui tient debout (donc pas un "commit early, release often" sur un SCM centralisé [snip, déjà répondu à ça]), des modifs suffisamment visibles pour l'utilisateur par rapport à upstream.

Et qu'apporte cette approche à la communauté, communauté au nom de laquelle vous dites forker TIGCC? Au lieu d'un projet ouvert et communautaire, vous développez en cercle fermé et vous ne publiez que quand vous avez de quoi booster vos égos, c'est l'exact opposé d'un projet communautaire!

Modifs que tu pourrais pourtant, grâce à la GPL et au fait qu'on ne s'amuse pas à changer l'arborescence des fichiers ou faire ce genre de conneries (ben oui, c'est plus de boulot pour nous quand on merge upstream ), réintégrer dans upstream.

Mais visiblement tu as peur que je sorte une release avec ta modif avant toi, c'est pour ça que tu la gardes en cachette. Et tu as bien peur que je fasse la même chose de mon côté, c'est pour ça que tu te bats tellement contre une éventuelle fermeture de mon CVS, alors que ça ne serait que fonctionner de la même manière que vous.

Une fois de plus: je ne veux pas fermer le CVS de TIGCC! C'est moi qui l'ai créé! Et je l'ai fait parce que je crois fortement en le développement ouvert plutôt que sous forme de code dumps. Mais si le CVS devient un mécanisme de migration de patches en sens unique (parce que vous n'êtes pas disponibles pour publier vos patches sous la même forme), quel autre choix me laissez-vous?

Exactement comme on peut intégrer les tiennes tant que tu maintiens un repository, avec quelque SCM que ce soit (mais tu n'as manifestement pas envie d'utiliser mieux qu'un des pires SCM, qui ne maintient même pas l'intégrité de ses données...). Ce qu'on te demande, c'est juste de respecter notre façon de faire, dont nous ne sommes pas les seuls défenseurs.

Votre façon de faire, c'est tout piquer et rien rendre. Si vous vouliez vraiment coopérer, vous travaillerez avec l'infrastructure existante et vous vous intègreriez à l'équipe existante au fur et à mesure, exactement comme je l'ai fait. (Je ne suis pas devenu mainteneur en chef de TIGCC du jour au lendemain! J'ai commencé petit, et Sebastian m'a confié de plus en plus de responsabilités au fur et à mesure. C'est comme ça que fonctionne une intégration à une équipe.)

Façon de faire qui changera probablement rapidement, de toute façon: la question n'est pas si on ouvrira l'infrastructure du fork, mais quand... La discussion de 'quand' a été lancée, parce qu'on décide ce genre de choses en groupe.

En attendant, je ne vois toujours rien, j'attends.
Et vu la manière de laquelle tu décris utiliser git (et en présupposant que vous fonctionnez tous comme ça), même si tu ouvres ton dépôt git central au public, on n'aura pas droit aux derniers développements, donc ta promesse est un mensonge.

En cas d'arrêt des commits sur le CVS public de TIGCC, ce serait encore nous qui aurions le mauvais rôle, tu sais si bien y faire. Même si de notre côté, on pourrait expliquer, ce que je fais plus bas, pourquoi on travaille différemment. Sans cette super bouse de CVS, et comme le kernel Linux et Wine, qui sont, avec tout le respect que je te dois, des projets autrement plus complexes que TIGCC.

Je sais que tu détestes CVS, mais ça ne t'empêche pas de développer en public! Si tu adores git tant que ça, ben il faut faire un push après chaque commit, tout simplement.

On sait très bien que tu es parfaitement capable d'arrêter de committer sur le CVS public de TIGCC. Voir l'antécédent d'avoir décidé avec Sebastian, par-derrière, de splitter le forum de TIGCC/TICT si je réagissais comme tu l'attendais, en me faisant remettre les pouvoirs d'admin par Thomas.

Je ne sais pas pourquoi tu nous sors cette histoire, et de toute façon je pense que ça aurait été mieux pour tout le monde, là on se retrouve avec un forum "TICT" qui discute à au moins 90% de TIGCC et où le seul membre actif de la TICT (toi) n'a aucun pouvoir, je pense qu'avoir des forums clairement séparés aurait été plus pratique que le forum commun qui est un accident de l'histoire.

* merge de toute la branch sur le trunk en une seule révision. Ca, c'est nul,

C'est bien pour ça qu'il faut développer directement sur le trunk le maximum possible. Mon développement se situe sur le CVS HEAD, c'est bien pour ça que KTIGCC a KTIGCC 2 dans HEAD et KTIGCC 1 dans ktigcc-1-branch même si KTIGCC 1 est ce qui est actuellement publié.

parce que si jamais la branch introduit un problème subtil que tu ne détectes que longtemps après - c'est régulièrement le cas sur le kernel Linux, par exemple - tu ne pourras pas savoir laquelle des modifs individuelles de la branch a fait merder un cas qui fonctionnait auparavant.

Si, tu peux, en faisant la bissection sur la branche.

Kevin Kofler (./33) :
Je sais que je devrais faire des releases plus souvent. Le problème, c'est que ça prend du temps avec tous les trucs à faire (et en plus le CHM doit être créé sur l'OS propriétaire de destination, je n'ai pas trouvé d'outil qui crée un CHM fonctionnel sous GNU/Linux ou WINE, les outils officiels foirent sous WINE).

Passe moins de temps sur yN, tu en auras plus pour bosser sur TIGCC

Et j'ai gardé ça pour un message à part:

Lionel Debroux (./31) :
GTC est capable, sous certaines conditions d'alignement, de packer quatre move.b en move.l, ce dont est à ma connaissance incapable GCC.

Certainement pas pour un push sur la pile, vu qu'on ne peut pas pousser un octet sur la pile (un move.b ...,-(%sp) décrémente %sp de 2 octets).

Si c'est pas simple de coder un peephole qui transforme [...] j'aurais tendance à voir ça comme une faiblesse du compilo.

Et ça change quoi au fait que ce n'est pas simple et que par conséquent il était déraisonnable d'attendre que ce soit implémenté du jour au lendemain et sans fautes?

Kevin Kofler (./33) :
Une fois de plus: je ne veux pas fermer le CVS de TIGCC! C'est moi qui l'ai créé! Et je l'ai fait parce que je crois fortement en le développement ouvert plutôt que sous forme de code dumps. Mais si le CVS devient un mécanisme de migration de patches en sens unique (parce que vous n'êtes pas disponibles pour publier vos patches sous la même forme), quel autre choix me laissez-vous?

Que dirais-tu si un fork de TIGCC existait appliquant certaines politiques différentes des tiennes ? Probablement que les auteurs du fork n'ont pas envie de contribuer à *ton* TIGCC car il ne leur convient pas tel qu'il est. Qu'est-ce que ça t'inspire ? Comment peut-on régler le problème autrement qu'en réalisant un fork "à sens unique", c'est-à-dire où on piquerait toutes tes bonnes contributions (j'entends celles qui correspondent aux objectifs du fork) mais dont les patches ne seraient pas proposés sur ton CVS puisqu'ils y seraient certainement refusés car contraires à tes objectifs.

Ben, moi, je veux voir vos patches et pouvoir choisir vos bonnes contributions (j'entends celles qui correspondent aux objectifs du vrai projet TIGCC) moi aussi. (Bah oui, vous revendiquez ce droit, bah moi aussi!) Maintenant, si vos patches sont vraiment à 100% contre ces objectifs, c'est-à-dire qu'ils se limitent à ce que j'ai refusé, alors quel est l'intérêt de votre fork? Vous ne faites que détruire la qualité de votre code. Si j'ai refusé un patch, c'est toujours pour une bonne raison.

Il faut que tu comprennes que tes objectifs peuvent être différents de ceux des autres.
Là où tu refuserais un patch, d'autres pourraient l'apprécier.

Mais ce que tu dis, en clair, c'est que vous n'avez aucune vraie innovation, juste les patches que j'ai refusés?

Pourquoi un patch que tu refuse ne pourrait justement pas être une innovation ?

Kevin Kofler (./37) :
Ben, moi, je veux voir vos patches et pouvoir choisir vos bonnes contributions (j'entends celles qui correspondent aux objectifs du vrai projet TIGCC) moi aussi.

- aux objectifs du vrai projet TIGCC + à mes objectifs

Mais si le CVS devient un mécanisme de migration de patches en sens unique (parce que vous n'êtes pas disponibles pour publier vos patches sous la même forme), quel autre choix me laissez-vous?

Votre façon de faire, c'est tout piquer et rien rendre.

Non mais sérieux, tu crois à ce que tu écris ??
Ca serait grave que tu croies à ce que tu écris, parce que tu sais pourtant très bien (tu nous pourris suffisamment de topics avec libre/propriétaire...) que c'est juste IMPOSSIBLE qu'on fonctionne comme ça à moyen et long terme. En effet, on part de code GPL/LGPL. Si on partait de code BSD, on pourrait - mais là, même au cas où on voudrait, on ne pourrait pas...

./36 écrit, probablement en plus clair et plus concis, ce que j'avais envie d'écrire.


Pour le moment, même si on approche la vingtaine de personnes au courant de quelques URL, ces URL ne sont pas encore postées sur un forum TI-68k ou un site de news. Mais vu qu'il y a maintenant deux topics en causant - les deux ayant été créés suite à un post de ta part - et que yAronet est bien browsé par les moteurs de recherche, l'existence d'un fork est DEJA officielle.
A titre personnel, comme je l'ai déjà écrit au moins deux fois, dans l'état actuel du fork, je vois moyennement l'intérêt de faire une release (accompagnant, dans mon esprit, l'officialisation du fork), parce que faire une release est du boulot, comme tu l'écris du reste toi-même. Mais d'autres semblent être pour un post plus précoce des URL. Suivant les avis qui seront postés, je me rangerai à l'avis de la majorité. C'est aussi ça, le développement communautaire: discuter à plusieurs, de façon argumentée, sur ce qui nous semble bon à chacun de faire, et décider

Et vu la manière de laquelle tu décris utiliser git (et en présupposant que vous fonctionnez tous comme ça), même si tu ouvres ton dépôt git central au public, on n'aura pas droit aux derniers développements, donc ta promesse est un mensonge.

Non seulement tu ne sais pas comment je bosse et comment je compte bosser... mais de plus, je pense que tu méconnais les possibilités de Git

parce que si jamais la branch introduit un problème subtil que tu ne détectes que longtemps après - c'est régulièrement le cas sur le kernel Linux, par exemple - tu ne pourras pas savoir laquelle des modifs individuelles de la branch a fait merder un cas qui fonctionnait auparavant.

Si, tu peux, en faisant la bissection sur la branche.

OK, je reconnais que j'ai écrit une ânerie. Ce qui est mauvais, quel que soit le SCM, c'est de réduire plusieurs commits à un seul.
Mais en utilisant uniquement CVS, dont le branching a toujours été affreux (comme le reste), je t'en prie, essaie rien qu'une fois, pour voir à quel point c'est amusant de faire une bisection sur une branch
Avec SVN, c'est déjà beaucoup plus facile, même si ça reste (à l'heure actuelle) non automatique.


[EDIT: cross.

+1 ./38, ./40, ./41 .
A titre personnel, je n'ai pas l'intention de continuer encore longtemps cette discussion, vu comment il semble difficile pour Kevin de comprendre ce qu'on essaie de faire. En revanche, il lui est facile de nous critiquer... Je pense que je la fermerai quand Pollux sera venu causer du packing des moves de GTC, dont il me semble me souvenir.

Mais ce que tu dis, en clair, c'est que vous n'avez aucune vraie innovation, juste les patches que j'ai refusés?

Non, c'est toi qui interprètes ses messages comme ça
Mais si ça t'amuse de croire ça, fais donc: ça ne fera qu'un peu plus ou un peu moins de flou dans ta tête sur nos intentions, nos méthodes, notre organisation et nos conceptions. Ce flou n'étant, pour la dernière fois, que très temporaire, parce qu'il disparaîtra quand les URL seront publiques et que tu pourras, enfin, savoir ce qu'on trafique...]

Ceci dit, rien que pouvoir utiliser VTI et a68k justifie pleinement un fork de TIGCC

Bah, pour A68k, je sais bien que beaucoup d'anciens programmes l'utilisent et pour ça je ne compte pas le virer entièrement, le problème, c'est que certains l'utilisent pour les nouveaux développements. Et je ne sais pas trop comment résoudre ce problème sans casser la compatibilité antérieure (ce que voudrait dire retirer le support pour A68k entièrement et ce qui est contraire aux principes de TIGCC). Si tu as des suggestions, je suis preneur. Mon plan actuel est de distribuer A68k à part (comme ça TIGCC lui-même sera 100% libre), mais je ne suis pas sûr que ce sera suffisant pour décourager son utilisation.

(Désolé, pas le temps / l'envie de répondre aux provocations ni au pavé de Lionel maintenant, peut-être plus tard...)

N'empeche qu'a cause de tes convictions libres toussa, tu sors qqch d'une qualite moindre, et tu te soucis clairement moins de l'utilisateur que tu ne devrais.

Kevin Kofler (./44) :
Bah, pour A68k, je sais bien que beaucoup d'anciens programmes l'utilisent et pour ça je ne compte pas le virer entièrement, le problème, c'est que certains l'utilisent pour les nouveaux développements. Et je ne sais pas trop comment résoudre ce problème sans casser la compatibilité antérieure (ce que voudrait dire retirer le support pour A68k entièrement et ce qui est contraire aux principes de TIGCC). Si tu as des suggestions, je suis preneur. Mon plan actuel est de distribuer A68k à part (comme ça TIGCC lui-même sera 100% libre), mais je ne suis pas sûr que ce sera suffisant pour décourager son utilisation.

Et que fais-tu des envies des utilisateurs ?

@nEUrOO: Euh, je te signale que rien n'a été supprimé de TIGCC pour des raisons de licence actuellement. Pour VTI, le problème de licence était loin d'être le problème principal. Faut-il que je rappelle les raisons?
* VTI plus mis à jour depuis des années et incapable d'émuler le matériel et logiciel récent
* code d'envoi à VTI à vomir car interface de communication entre processus inexistante
* disponibilité de TiEmu qui résout tout ça, est portable et propose un débogueur C
* difficulté de maintenir le code d'envoi vers les 2 émulateurs en même temps, et inutilité de ceci à cause des raisons ci-dessus
Le code d'envoi à VTI dans TIGCC n'était pas encombré, il n'a pas été retiré de TIGCC pour des raisons de licence!

Bref, il n'y a que A68k qui pose problème à ce niveau.

Flanker (./46) :
Et que fais-tu des envies des utilisateurs ?

Je ne les comprends pas! C'est bien ça le problème. Qu'est-ce qui vous pousse à vouloir utiliser à tout prix un assembleur qui n'est pas du tout à jour, est difficilement maintenable, n'a pas les fonctionnalités de GNU as (genre les pseudo-instructions jb??), n'est pas libre, a une syntaxe pénible (indentation etc.), a une gestion d'erreurs lamentable (messages d'erreur vagues, pas de distinction warning/erreur, donc aussi absence de warnings pour des situations qui en mériteraient, non-détection d'erreurs comme l'utilisation de moveq.w, ...), n'est pas celui utilisé par GCC (et donc l'assembleur inline en C) et est déprécié dans TIGCC depuis pas mal de temps (voire depuis toujours, c'est moi qui ai fait en sorte qu'il soit supporté parce que je le préférais à l'époque, mais ça fait longtemps que j'ai compris que GNU as est mieux, et les défauts que je trouvais à GNU as à l'époque n'existent plus (.incbin existe maintenant) ou étaient juste dus à un manque d'information (--register-prefix-optional - as-tu essayé cette option avant de dire que GNU as sux?))?

Peut-être que tu devrais essayer de maintenir A68k? Parce que c'est comme ça que je me suis rendu compte à quel point il sux.

Ximoon (./40) :
Pourquoi un patch que tu refuse ne pourrait justement pas être une innovation ?

Tu sais très bien ce que je veux dire par "innovation", ne fais pas semblant de ne pas comprendre.

Flanker (./41) :
- aux objectifs du vrai projet TIGCC + à mes objectifs

Ça revient au même, étant donné que mon projet est le vrai projet TIGCC. Je n'y peux rien si tous les autres membres de l'équipe sont partis (pour des raisons qui n'ont rien à voir avec moi).

Lionel Debroux (./42) :

Mais ce que tu dis, en clair, c'est que vous n'avez aucune vraie innovation, juste les patches que j'ai refusés?

Non, c'est toi qui interprètes ses messages comme ça Mais si ça t'amuse de croire ça, fais donc: ça ne fera qu'un peu plus ou un peu moins de flou dans ta tête sur nos intentions, nos méthodes, notre organisation et nos conceptions. Ce flou n'étant, pour la dernière fois, que très temporaire, parce qu'il disparaîtra quand les URL seront publiques et que tu pourras, enfin, savoir ce qu'on trafique...]

Vous vous contredisez les uns les autres, Sasume me dit que vous ne me montrez pas les patches parce qu'il n'y a rien d'intéressant pour moi, toi, tu dis le contraire, faut savoir.

[EDIT: faute de français]

pas à jour : l'utilisateur s'en fout tant que ça marche
pas libre : l'utilisateur s'en fout tant que ça marche
pas de fonctionnalités gnu : l'utilisateur s'en fout tant que ça marche
gestion d'erreurs : l'utilisateur s'en fout tant que ça marche
utilisé par gcc : l'utilisateur s'en fout tant que ça marche
déprécié dans tigcc : l'utilisateur s'en fout tant que ça marche
tu penses que gnu as est mieux : l'utilisateur s'en fout tant que ça marche

A68k utilise la syntaxe officielle et standard de l'assembleur 68000, telle qu'on la retrouve dans toutes les docs et tous les tutos : ça, l'utilisateur ne s'en fout pas.

Xi > je crois que tu as bien résumé

Et non, je ne sais pas ce que tu veux dire par innovation. Si c'est "passer d'un truc propriétaire qui ne te plait pas à un truc libre qui te plait", tu as intérêt à changer très vite ta définition.
Par exemple, en ce qui me concerne, le retrait du support de VTI est une régression majeure, de même que la future liaison avec KDE.
Des innovations que tu refuses par exemple : fenêtres MDI, gestion multi-projets, make intelligent.

Kevin Kofler (./37) :
Ben, moi, je veux voir vos patches et pouvoir choisir vos bonnes contributions (j'entends celles qui correspondent aux objectifs du vrai projet TIGCC) moi aussi. (Bah oui, vous revendiquez ce droit, bah moi aussi!)

Un peu de patience, d'après ce qu'on peut lire ici, tu ne les intégreras pas avant 5 ans de toutes manières vu que t'as pas le temps...

(bob > tu noteras que j'ai pensé à toi )

Ximoon (./50) :
pas à jour : l'utilisateur s'en fout tant que ça marche

Mais ça (et le point "difficilement maintenable" que tu as sauté) implique d'être moins fonctionnel, cf. plus bas.

pas libre : l'utilisateur s'en fout tant que ça marche

C'est très dommage ça, et c'est une partie du problème.

pas de fonctionnalités gnu : l'utilisateur s'en fout tant que ça marche

Pourquoi? Parce qu'il ne connaît pas les nouvelles fonctionnalités? Parce qu'il ne comprend pas leur intérêt? Par exemple, pouvoir écrire jbsr et avoir un bsr.s, un bsr.w ou un jsr au choix selon la distance du label, c'est très pratique. Il y a aussi des fonctionnalités de ld-tigcc qui ne sont accessibles qu'avec GNU as, par exemple les sections de taille impaire (donc on peut économiser un octet si le programme se termine sur des données) et les sections mergeables (bon OK, c'est utile surtout en C, mais ça peut être pratique pour un programme mixte C/ASM - cela dit, cette fonctionnalité est mal documentée, je le reconnais). Et il y a aussi par exemple la pseudo-instruction .rept qui est pratique pour les boucles déroulées (je suis sûr qu'il y a des adeptes de l'optimisation vitesse parmi vous, vu comment je me fais gueuler dessus quand je dis qu'il faut toujours optimiser taille ).

gestion d'erreurs : l'utilisateur s'en fout tant que ça marche

Seulement s'il ne fait pas d'erreurs.
Mais normalement, une gestion d'erreurs efficace est très pratique pour un développeur!

utilisé par gcc : l'utilisateur s'en fout tant que ça marche

Non, parce que s'il veut coder de l'assembleur inline en C, il est obligé d'apprendre une deuxième syntaxe alors qu'il ne devrait être obligé de connaître qu'une seule.

déprécié dans tigcc : l'utilisateur s'en fout tant que ça marche

Et c'est pour ça que je me demande s'il ne faudrait pas faire en sorte que ça ne marche plus, justement, pour leur faire comprendre que c'est déprécié!

tu penses que gnu as est mieux : l'utilisateur s'en fout tant que ça marche

Évidemment que l'utilisateur s'en fout de ce que je pense, l'important est pourquoi je le pense, et si j'ai cité mon cas, c'est parce que j'ai été aussi pour A68k à une époque et que j'ai compris m'être trompé.

A68k utilise la syntaxe officielle et standard de l'assembleur 68000

C'est ridicule, il n'y a pas de syntaxe "officielle et standard" en assembleur, chaque assembleur a une syntaxe à sa sauce, la syntaxe de A68k est subtilement différente de celle de n'importe quel autre assembleur XYZ pour 68000, elle est plus proche peut-être, mais certainement pas identique!

telle qu'on la retrouve dans toutes les docs et tous les tutos : ça, l'utilisateur ne s'en fout pas.

Donc le problème, c'est que les docs et les tutos ne sont pas à jour? Donc il faudrait faire un effort pour produire des tutos utilisant GNU as? Il faudrait effectivement que je mette à jour le mien qui est totalement dépassé, pas seulement à cause de l'utilisation de A68k.

Mais ce que tu dis, en clair, c'est que vous n'avez aucune vraie innovation, juste les patches que j'ai refusés?

Non, c'est toi qui interprètes ses messages comme ça Mais si ça t'amuse de croire ça, fais donc: ça ne fera qu'un peu plus ou un peu moins de flou dans ta tête sur nos intentions, nos méthodes, notre organisation et nos conceptions. Ce flou n'étant, pour la dernière fois, que très temporaire, parce qu'il disparaîtra quand les URL seront publiques et que tu pourras, enfin, savoir ce qu'on trafique...

Vous vous contredisez les uns les autres, Sasume me dit que vous ne me montrez pas les patches parce qu'il n'y a rien d'intéressant pour moi, toi, tu dis le contraire, faut savoir.

Comme tout le monde, j'interprète parfois les posts d'une manière différente de la signification que voudrait faire passer l'auteur du post... mais là, dans ./36 et ./38, je ne vois pas où Sasume indique que le fork ne contient actuellement *QUE* des modifs que tu as explicitement refusées. Il essaie de te faire comprendre pourquoi d'autres personnes pourraient avoir envie de faire un fork, ça oui, mais tu n'as pas l'air de comprendre.
Si ta question est une tentative de savoir si c'est le cas ou pas, avant qu'on rende le fork encore plus public que ce qu'il n'est déjà... ce n'est pas sur moi qu'il faut compter pour te donner la réponse. Réponse que tu auras de toute façon.

Encore une fois, tu gardes tes informations secrètes, vous êtes franchement gonflés de faire passer votre développement secrétif en petite secte pour un projet communautaire!

Pourquoi, une secte n'est pas une communauté ? (puis c'est toujours mieux qu'un développement communautaire tout seul )

Je développe dans un dépôt public, pas derrière une porte fermée, et c'est vous qui refusez de travailler avec moi, ce n'est pas mon choix de travailler tout seul!

Kevin Kofler (./48) :

Flanker (./46) :
Et que fais-tu des envies des utilisateurs ?

Je ne les comprends pas! C'est bien ça le problème.

Mais même si tu ne les comprends pas, tu pourrais les tolérer et les respecter, non ?