Kevin Kofler (./107) :
Non, je joue au "tu l'as dit, maintenant tu dis que ce n'est pas/plus prévu", cf. les 2 dernières phrases de son ./100.

Et lui, il a l'air de jouer au "tout ce que je n'ai pas encore fait / ne compte pas faire (selon le contexte) n'est pas important", c'est de la mauvaise foi, ça. D'autant plus qu'il montre clairement qu'il ne sait pas de quoi il parle.

D'accord. Dans ce cas, ne t'inquiete pas. Qui peut dire définitivement qu'un feature est prévu ou pas? En général, on code ce qu'on peut, on reporte à plus tard ce qui est le plus difficile et/ou moins indispensable à court terme, etc...
N'oublie pas que notre expérience dans le développement collaboratif, à Onur et moi, est très mince. Tu as de la chance d'être impliqué dans le développement de gcc, c'est une expérience que tout le monde ne possède pas (hélas peut être, mais c'est comme ça)

Kevin Kofler (./107) :
C'est faire les choses à l'envers ça, il faut savoir ce qu'on fait avant de commencer à coder. Il y a des moyens de se documenter.

Je connais l'organisation de l'ENSIMAG pour avoir suivi les mêmes cours qu'Onur à très peu de choses près, et, encore hélas, je peux t'affirmer que c'est impossible, car les cours, TD et projets se font quasiment en même temps. Personne n'a matériellement le temps d'accumuler de l'expérience avant de commencer les projets d'école. Que ce soit en compilation ou autre. J'ai moi même dirigé l'organisation de notre projet de compil, et j'ai passé mon temps à expliquer aux autres (on peut les considérer comme des développeurs, donc) ce qu'ils n'avaient pas compris.

Kevin Kofler (./107) :
Le problème est qu'il n'a pas l'air de comprendre ça, ou s'il le comprend, qu'il ne fait pas clairement passer le message à des personnes comme Thibaut ou Yoshi Noir, ni à ses utilisateurs potentiels.

Ha , la la, le problème de la communication Eh oui, c'est dur, et évidemment, quand on code soi même, ce qu'on fait en dernier, c'est écrire la doc mauvaise habitude, je le reconnais, mais hélas encore

Kevin Kofler (./107) :
Si tu écris quelque chose comme: "ATTENTION! CECI EST UN PROJET DE RECHERCHE EN ÉTAT PRÉ-ALPHA. EN SON ÉTAT ACTUEL, IL EST TOTALEMENT INUTILISABLE EN PRATIQUE." (ce qui serait honnête), le feedback obtenu sera différent.

Je comprends parfaitement ce que tu attends, et c'est légitime, mais dans ce processus, c'est aussi la fierté et l'envie de montrer le plus vite possible ce qu'on a réussi qui prime Donc parfois, ça pousse à des choses que les gens très rationnels, comme toi, (je critique pas , d'accord?) trouvent choquantes

Kevin Kofler (./107) :
Tu entends quoi par "gros stubs"?

Ben moi je voyais des bouts de code natifs qui remplacent les fonctions manquantes. Même s'il s'agit de fonctions dont les effets de bord ne sont pas 100,000% identiques à la version 68k. C'est à envisager, n'est ce pas? Cela peut être gratifiant pour certains programmeurs débutants, d'avoir des programmes simples portables nativement entre les calculatrices Je ne pense pas qu'il s'agisse de porter des choses évoluées, mais des fonctions de base. Quitte à signaler à l'utilisateur "portage impossible" etc... si on demande des choses trop compliquées.

Kevin Kofler (./107) :
Je sais bien, j'ai fait un compilateur jouet dans un cours à l'université aussi! Mais je n'ai pas la prétention de considérer un tel compilateur jouet comme utilisable en pratique.

Encore une fois, OK, je vois où tu veux en venir. C'est plutot une histoire de mots que de fonctions j'ai l'impression. Il doit être possible de vous mettre d'accord.

Zephyr > peut être que certaines critiques sont justifiées, j'ai l'impression que c'est plus sur la forme que sur le contenu que ce concentrent les critiques.

onur (./109) :
LIS CE P***** DE FICHIER GEN68K.CPP

onur (./110) :
tu as l'air d'avoir de la m**** dans les yeux

courage, résiste à l'envie de péter les plombs, on va vous mettre d'accord j'en suis certain.