Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
Utilisateurs actifs : Aucun membre + 1 visiteur

Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.

:: Index » Forum Ti68K » Programmes et tests... » Beta-tests de programmes de TICT... (117 réponse(s))

./REPRISE DU POST PRECEDENT (post n°19) Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 10 juin 2005 à 14:43

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Martial Demolins :
A force de jouer à ce jeu là Kevin, tu vas finir par te faire forker TIGCC en grand par quelques personne beaucoup plus ouvertes d'eprit, et tu n'auras plus le monopole toussa, ...

Ben, ça fera déjà qu'il y aura des personnes qui travaillent sur TIGCC, ce qui n'est visiblement pas le cas actuellement (chose qui me fait aussi penser qu'un tel scénario est peu probable), donc ce n'est pas forcément une mauvaise chose. Et s'ils font de vraies améliorations, je peux les merger, aussi.

Franchement, je pense plutôt que si des gens "forkent" TIGCC, ils vont distribuer des versions patchées avec 99% du travail fait par moi, donc ils seront dépendants de ce que je fais, et ils auront vite marre de maintenir leur fork.

Ta confiance 0 en Lionel est marrante, personne ne te retirait sa confiance en grand quand tu sortais des bêtas bugguées, non?

Justement, je ne veux pas sortir une bêta boguée, donc je relis le code de Lionel avant de le merger!

Et quand à la diversité des libs graphiques, où est le problème si elles sont mieux que celles de TIGCCLIB?

Le problème est qu'elles ne le sont pas.
-Edité le Vendredi 10 juin 2005 à 14:47 par Kevin Kofler-
-Edité le Vendredi 10 juin 2005 à 14:51 par Kevin Kofler-

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!

./Post n°20 Marquer comme non lu.

Folco

Ecrit le: Vendredi 10 juin 2005 à 14:47

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

>>Donc tu te retrouves avec une routine de gris inofficielle
Pourquoi inofficielle? par rapport à TIGCC? Mais TIGCC est inofficiel par rapprot à PreOS et la distrib de PpHd. Je vois pas trop ce que ça vient faire ici ça...

>>et non supportée par le compilateur (donc qui peut arrêter de marcher à tout moment, volontairement ou pas, sans que j'aie à fournir des justifications).
Ben voyons, faire ch**r le monde avec pour seul but de le faire ch**r, ça serait pas ça la diktature??

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°21 Marquer comme non lu.

Lionel Debroux

Ecrit le: Vendredi 10 juin 2005 à 14:50

Envoyer un message privé à Lionel Debroux

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

> Tu oublies HW2 AMS 1.05 dans tout ça (et je t'ai déjà fait la remarque, tu refais quand-même l'erreur, donc je dois supposer que tu fais exprès #roll#

).
Tu as raison. Je te ferai quand même remarquer que d'une, c'est petit comme réponse à mon post, que ça ne change en rien son contenu (même plus, tu vas dans mon sens: les TSRs aggravent le manque de mémoire, surtout sur HW2 d'ailleurs, à moins d'utiliser des ROMs patchées !), et que de deux, tu devrais éviter la fin.

> > Et quand à la diversité des libs graphiques, où est le problème si elles sont mieux que celles de TIGCCLIB?

> Le problèmes est qu'elles ne le sont pas.
Superbe, aucun argument.

> > De même que tu sais très bien que ton patch est rejeté, à cause de sa calling convention utilisant largement a4, que j'utilise et conseille comme base pour -freg-relative-an...
> Manque de chance, c'est l'endroit le plus efficace pour passer ces paramètres, donc on fait avec.
Pas dit, ça utilise un registre qui pourrait être utilisé de manière permanente pour faire autre chose.
J'ai du code surprenant (dans le mauvais sens) sur la version qui utilise a2 du programme que je t'ai déjà envoyé la semaine dernière. Je vais revérifier que je n'ai oublié aucun "const", parce que ça semble trop énorme pour être vrai: sauvegarde / restauration du registre même quand il n'est pas modifié, recopie dans un autre registre puis utilisation de a2, etc.

[EDIT: supprimé un mot qui faisait qu'une phrase n'avait pas beaucoup de sens; complété cette phrase]
-Edité le Vendredi 10 juin 2005 à 14:56 par Lionel Debroux-

Lionel Debroux - membre de TICT.

./Post n°22 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 10 juin 2005 à 14:50

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Martial Demolins :
>>et non supportée par le compilateur (donc qui peut arrêter de marcher à tout moment, volontairement ou pas, sans que j'aie à fournir des justifications).
Ben voyons, faire ch**r le monde avec pour seul but de le faire ch**r, ça serait pas ça la diktature??

"volontairement ou pas"... Si je fais une modif qui casse son fork d'une manière ou d'une autre (par exemple parce que ses symboles sont en conflits avec ceux du gray.h et/ou gray.s officiel, ou à cause d'un changement d'ABI qui nécessite de changer tous les fichiers ASM de TIGCCLIB, ...), ça ne sera pas mon problème, et je ne vais pas éviter de faire avancer TIGCC pour ne pas casser son fork. S'il fait bien son fork, ce risque ne sera pas grand, mais en tout cas, ce sera à lui de suivre l'évolution de TIGCC, pas l'inverse.

./Post n°23 Marquer comme non lu.

Lionel Debroux

Ecrit le: Vendredi 10 juin 2005 à 14:53

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

C'est évident que c'est au fork de suivre l'original.

> et je ne vais pas éviter de faire avancer TIGCC pour ne pas casser son fork
Cet argument me paraît risible. La librarie n'avance pas beaucoup, et ce n'est pas ma faute (pour qui étaient faites fastitoa.h et faststr.h, avant que tu deviennes le seul vrai mainteneur de TIGCC ?).

Lionel Debroux - membre de TICT.

./Post n°24 Marquer comme non lu.

Folco

Ecrit le: Vendredi 10 juin 2005 à 15:08

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

>>Justement, je ne veux pas sortir une bêta boguée, donc je relis le code de Lionel avant de le merger!
Je ne te parlais pas des bugs de Lionel (ben oui, ça arrive), mais des tiens! Pourquoi comprendre ça dans le mauvais sens?

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°25 Marquer comme non lu.

Lionel Debroux

Ecrit le: Vendredi 10 juin 2005 à 15:15

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

C'est sûr qu'il a bien plus fait bugger mes programmes que je n'ai fait bugger le sien (4/4 sur les premiers programmes de TICT où j'ai testé GCC 4.0, plusieurs bugs graves - score jamais atteint auparavant), mais ça n'est pas une bonne raison pour s'en vanter, ni d'un côté ni de l'autre. Relire et tester le code de part et d'autre est ce qu'il faut faire (au passage - c'est le sujet du topic, je voudrais du feedback sur la routine de grays, car je ne l'ai pas testée à fond - qu'il y ait un bug ne serait pas plus surprenant que ça).

Lionel Debroux - membre de TICT.

./Post n°26 Marquer comme non lu.

Sasume

Ecrit le: Vendredi 10 juin 2005 à 15:48

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

En même temps, on n'est pas obligé de forker, on peut faire une lib indépendante de tigcclib.
Et même si on forke, à mon avis, la maintenance ne sera pas bien difficile parce que les routines de niveaux de gris sont assez indépendantes du reste.

./Post n°27 Marquer comme non lu.

Lionel Debroux

Ecrit le: Vendredi 10 juin 2005 à 16:20

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Tout à fait d'accord sur les deux points...

Lionel Debroux - membre de TICT.

./Post n°28 Marquer comme non lu.

Kevin Kofler

Ecrit le: Samedi 11 juin 2005 à 05:58

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

J'ai relu les modifs de gray.s et elles m'ont l'air OK, donc je les ai mises dans le CVS de TIGCC. J'ai aussi complètement viré les instructions que tu as mises en commentaire (genre les move #0), ainsi que les tags Id et Log qui donnent un véritable bordel vu que le CVS de TIGCC n'a pas les mêmes révisions que celui de Thomas. Comme SourceForge met du temps pour synchroniser le CVS public avec celui que les développeurs utilisent, j'ai temporairement mis le fichier exact qui a été placé dans le CVS ici: http://www.tigen.org/kevin.kofler/ti89prog/gray.s. Je remplacerai le lien quand le fichier sera disponible par ViewCVS.
-Edité le Samedi 11 juin 2005 à 05:59 par Kevin Kofler-

./Post n°29 Marquer comme non lu.

Sasume

Ecrit le: Dimanche 12 juin 2005 à 23:31

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Prends garde, il ce n'est pas sûr que cette nouvelle version soit exempte de bugs.

./Post n°30 Marquer comme non lu.

Kevin Kofler

Ecrit le: Dimanche 12 juin 2005 à 23:38

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

J'ai relu les modifs avant de merger.

./Post n°31 Marquer comme non lu.

Lionel Debroux

Ecrit le: Mercredi 15 juin 2005 à 10:25

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Sasume a updaté grib.

Lionel Debroux - membre de TICT.

./Post n°32 Marquer comme non lu.

Lionel Debroux

Ecrit le: Jeudi 23 juin 2005 à 12:08

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Il a de nouveau updaté grib. Au programme: une diminution supplémentaire de la taille, une doc améliorée.

Lionel Debroux - membre de TICT.

./Post n°33 Marquer comme non lu.

Sasume

Ecrit le: Jeudi 23 juin 2005 à 16:55

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Bon, je profite de ce topic (pas la peine d'en recréer un...) pour annoncer que cette version de Grib sera la dernière sauf si des bugs sont trouvés ou que le rendu est moche.
J'espère que plusieurs personnes testeront sur des HW différents.
Merci

./Post n°34 Marquer comme non lu.

Sasume

Ecrit le: Jeudi 23 juin 2005 à 16:56

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Au fait, Kevin, tu n'as pas répondu à mes mini-messages concernant Grib : est-ce que le modèle que j'utilise pour gérer le double-buffering te plaît ? Est-ce que tu es toujours contre remplacer gray.s par grib ?

./Post n°35 Marquer comme non lu.

geogeo

Ecrit le: Jeudi 23 juin 2005 à 19:13

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4256

Membre n°3

Inscrit le 29 janvier 2004

Est-ce que tu es toujours contre remplacer gray.s par grib ?

Un fork est possible tout façon.

Sinon une question je n'ai pas testé Grib mais qu'est ce quelle apporte de plus au niveau de la qualité des niveaux de gris? Est-elle plus rapide et consomme-t-elle moins les piles? Dans ce cas je pense peut être l'adopter à GFA-Basic, mais à voir!

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°36 Marquer comme non lu.

Sasume

Ecrit le: Jeudi 23 juin 2005 à 19:20

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Grib est plus petite en taille que les routines de TIGCCLIB.
Sinon, le principe pour afficher les nvg est le même je crois, donc la qualité doit être la même.
Le double-buffering de Grib est moins restrictif que celui de TIGCCLIB (pas - ou presque - d'attente sur HW1).
Sinon, il reste quelques avantages subjectifs : possibilité de préciser soi-même où sont les planes (ils ne sont pas forcément alloués automatiquement par la lib), et je trouve que son API est plus agréable que celle de TIGCCLIB.

./Post n°37 Marquer comme non lu.

LionelA

Ecrit le: Jeudi 23 juin 2005 à 20:14

Modérateur général

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 947

Membre n°206

Inscrit le 19 avril 2004

donc il y a une API differente, ca n'aurait pas été mieux de garder exactement la même (comme ca la conversion de programmes existant serait instantanée) ?

Auteur de Mode7 Engine pour ti68k
Auteur de F-ZERO for TI68k
Membre de Orage Studio
Mon site perso : http://www.tigen.org/lionela/
Le gite de mes parents à coté de Narbonne :
http://chaletdenis.free.fr/

./Post n°38 Marquer comme non lu.

geogeo

Ecrit le: Jeudi 23 juin 2005 à 20:54

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4256

Membre n°3

Inscrit le 29 janvier 2004

Dommage que la qualité des niveaux de gris n'ait pas été améliorée. Mais bon à part ça si elle est plus petit alors autant la prendre!

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic