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))

./POST DE DEPART (post n°0) Marquer comme non lu.

Lionel Debroux

Ecrit le: Jeudi 9 juin 2005 à 09:19

Envoyer un message privé à Lionel Debroux

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

J'ai la flemme de traduire le post, donc je vous invite à vous reporter à
http://p080.ezboard.com/ftichessteamhqfrm10.showMessage?topicID=183.topic
Les commentaires peuvent être postés là-bas en anglais uniquement, ou bien en français soit ici soit dans la section Actu / Divers du forum TI-68k de yAronet.
Merci d'avance.

Au passage, je signale la librairie Grib (niveaux de gris) de Sasume, dans la section Software du forum TI-68k de yAronet.
-Edité le Jeudi 9 juin 2005 à 09:29 par Lionel Debroux-

Lionel Debroux - membre de TICT.

./Post n°1 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 9 juin 2005 à 11:39

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4811

Membre n°40

Inscrit le 08 février 2004

Ton titre dit "Beta-tests de programmes de TICT..." et le contenu du message parle de Grib, donc tu ne respectes même pas ton propre sujet. #roll#

Soit dit en passant que je ne vois pas l'intérêt de Grib, il y a déjà trop de librairies de gris. En particulier, TIGCCLIB propose une librairie de gris qui marche très bien.
-Edité le Jeudi 9 juin 2005 à 11:40 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°2 Marquer comme non lu.

Lionel Debroux

Ecrit le: Jeudi 9 juin 2005 à 12:18

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

La librairie de grays de TIGCCLIB a quelque chose qui ne plaît pas à tout le monde, notamment moi, tu le sais bien. L'optimisation de 40 octets n'est qu'une étape...

Lionel Debroux - membre de TICT.

./Post n°3 Marquer comme non lu.

serioussam

Ecrit le: Jeudi 9 juin 2005 à 12:58

Membre: Maître Ultime

Messages: 3636

Membre n°23

Inscrit le 01 février 2004

C'est pas le sujet. Merci la modération en carton.

Lionel, c'est limite impoli de nous rebalancer comme ça sur le forum TICT...

la shasse é ouvèrte poure lay maychants

./Post n°4 Marquer comme non lu.

Folco

Ecrit le: Jeudi 9 juin 2005 à 15:32

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

mdr serioussam prends pas la mouche quoi. tu dois être le seul à avoir réagi comme ça.

Quand à ce que dit Kevin, je pense que seule la diversité et l'innovation fait progresser les résultats d'une communauté, et c'est pas parceque c'est ércit TIGCCLIB en bas à droite que c'est parfait et définitif.

<<< 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°5 Marquer comme non lu.

Lionel Debroux

Ecrit le: Jeudi 9 juin 2005 à 15:40

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

C'est bien dit, mais ce n'est pas le sujet...

Lionel Debroux - membre de TICT.

./Post n°6 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 9 juin 2005 à 17:47

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4811

Membre n°40

Inscrit le 08 février 2004

serioussam :
C'est pas le sujet. Merci la modération en carton.

Tu veux que je censure le post de départ parce qu'il n'est pas dans le sujet?! Tout le reste, ça répond au post de départ...

Lionel, c'est limite impoli de nous rebalancer comme ça sur le forum TICT...

Là, je ne vois pas le problème, j'ai fait ça aussi par occasion, il a autre chose à faire aussi que de copier-coller (voire traduire) tout.

./Post n°7 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 9 juin 2005 à 17:54

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4811

Membre n°40

Inscrit le 08 février 2004

Lionel Debroux :
La librairie de grays de TIGCCLIB a quelque chose qui ne plaît pas à tout le monde, notamment moi, tu le sais bien.

Ce quelque chose est là pour une bonne raison et tu le sais très bien. Le problème, c'est que Sasume et toi, vous refusez d'adapter votre Tilemap Engine (enfin, celui de Sasume... tu n'as rien fait pour ce Tilemap Engine à part le copier-coller dans la distribution de ExtGraph) avec mon patch qui existe depuis des mois. Ce n'est pas un problème de TIGCCLIB.

L'optimisation de 40 octets n'est qu'une étape...

Tu veux vraiment maintenir ton fork de gray.s (et ainsi créer encore une librairie de gris, en plus de la version officielle de TIGCCLIB, de la lib de Sasume et de toutes les libs kernel)? Je ne pense vraiment pas que ça vaille le coup. Ton optimisation sera probablement mergée (mais il faudra que je vérifie qu'elle est valide d'abord, tu as déjà soumis des optimisations foireuses à TIGCCLIB, donc je ne te fais plus confiance), mais pour tes autres modifs, la chance qu'elles soient mergées est de zéro pile.

./Post n°8 Marquer comme non lu.

Sasume

Ecrit le: Jeudi 9 juin 2005 à 18:44

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

En fait, ce serait bien que tu acceptes le fork, ça éviterait de créer encore une librairie de gris.

./Post n°9 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 9 juin 2005 à 18:56

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4811

Membre n°40

Inscrit le 08 février 2004

Non, ce qui éviterait ça, c'est de ne pas forker dès le départ.
Il est hors de question de rajouter ne serait-ce qu'une seule instruction pour permettre d'allouer des buffers consécutifs, et il est encore plus hors de question de remplacer le schéma d'allocation actuel optimisé en consommation mémoire par un schéma de buffers consécutifs. Ceci a déjà été discuté plusieurs fois et n'est plus sous discussion (et tu le sais très bien).
Et ce n'est pas que moi qui dis ça, Thomas et Sebastian sont d'accord avec moi. Les plans consécutifs ne servent à rien.
-Edité le Jeudi 9 juin 2005 à 19:00 par Kevin Kofler-

./Post n°10 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 9 juin 2005 à 19:10

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4811

Membre n°40

Inscrit le 08 février 2004

Je rajouterai que je retiens ta manière d'essayer (en vain - je ne suis pas du genre à céder sous cette forme de racket) de forcer un mauvais choix d'implémentation parce qu'il t'arrange (parce que ton Tilemap Engine bogué en dépend et que tu refuses d'appliquer mon patch qui corrige ce bogue) absolument déplorable.

./Post n°11 Marquer comme non lu.

Jfg

Ecrit le: Jeudi 9 juin 2005 à 20:31

Administrateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 1260

Membre n°60

Inscrit le 23 février 2004

Et le fork fut.

Kill Mario

./Post n°12 Marquer comme non lu.

Dari

Ecrit le: Jeudi 9 juin 2005 à 20:50

Membre privilégié

Messages: 968

Membre n°203

Inscrit le 18 avril 2004

[JOKE]Et le double post ? C'est bien beau d'être modérateur, mais si tu sais pas où est le bouton EDIT, ça craint [/JOKE]

"iPod, therefore, I am."

http://media.laquadrature.net/Quadrature_black-out_HADOPI_468x60px.gif

./Post n°13 Marquer comme non lu.

geogeo

Ecrit le: Jeudi 9 juin 2005 à 21:00

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4253

Membre n°3

Inscrit le 29 janvier 2004

Kevin Kofler> Penses et regardes bien au dessus de toi, y a quelqu'un et ce quelqu'un quand il est pas content peut appliquer des mesures extrémistes qu'on applique généralement sous un régime de type dictature. Je vois une certaine provocation et j'aime pas ça, vous pouvez parler comme vous voulez mais sans vous provoquer et faire tourner le topic en sucette.
Sur ce, sujet clos et on revient au titre du topic, si je vois un post hors sujet je m'en occupe personnelement et inutle Kevin de revenir dans mon dos délocker au autre (la sanction pour se genre de chose fait assez mal). Si quelqu'un veut s'opposer à ce que je dis ou continuer le sujet c'est par mini-messages.
-Edité le Jeudi 9 juin 2005 à 21:00 par geogeo-

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°14 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 9 juin 2005 à 21:20

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4811

Membre n°40

Inscrit le 08 février 2004

Euh, tu veux nous empêcher de discuter maintenant? C'est nouveau... On se croirait chez yN... C'est toi qui provoques avec tes menaces abusives.

Je ne vois vraiment pas en quoi notre discussion est hors sujet, vu que c'est l'auteur du topic qui l'a lancée dans son post de départ!
-Edité le Jeudi 9 juin 2005 à 21:23 par Kevin Kofler-

./Post n°15 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 9 juin 2005 à 21:22

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4811

Membre n°40

Inscrit le 08 février 2004

Jfg :
Et le fork fut.

Bah, à moins de forker TIGCC en entier (ce qui demande beaucoup de travail), ils se retrouveront forcément avec une version inofficielle et non supportée de gray.s.

./Post n°16 Marquer comme non lu.

Lionel Debroux

Ecrit le: Vendredi 10 juin 2005 à 11:38

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

geogeo: c'est plus ou moins moi qui ai lancé le sujet au début, même s'il aurait pu ne pas partir sur de telles bases. Tant qu'il ne part pas plus en sucette que ça, laissons le topic aller comme ça. C'est la façon habituelle dont Kevin et moi "discutons" des sujets polémiques, en privé comme en public.

> Il est hors de question de rajouter ne serait-ce qu'une seule instruction pour permettre d'allouer des buffers consécutifs,
Rotfl. Si tu avais regardé en détail le code de la routine de grayscale (ce dont je finis par douter puisque tu as quand même laissé passer des choses qui se voient comme le nez au milieu de la figure, menant à une quarantaine d'octets d'optimisation taille; je sais, tu m'as expliqué qu'il y a maintenir et maintenir), tu saurais que ça en enlève...

> et il est encore plus hors de question de remplacer le schéma d'allocation actuel optimisé en consommation mémoire par un schéma de buffers consécutifs.
Un petit rappel pour tous:
* AMS 1.xx / HW1: la configuration qui a le plus de mémoire disponible (pas de FlashApps = pas d'ACBs et de Frames).
* AMS 2.xx / HW1: la configuration ayant la mémoire disponible d'un AMS 2.xx (avec ACBs, Frames), moindre que celle des AMS 1.xx / HW1.
* AMS 2.xx/3.xx / HW2-HW3: la configuration ayant la mémoire disponible d'un AMS 2.xx et ultérieur (avec ACBs, Frames), moindre que celle des AMS 1.xx / HW1, AMS 3.xx étant pire qu'AMS 2.xx. Planes obligatoirement alloués en-dehors de LCD_MEM.
AMS 2+ / HW2+ est la configuration la plus limitante - et la plus répandue. C'est donc celle pour laquelle les programmes doivent être faits. Autrement dit, il ne sert absolument à rien du point de vue optimisation de la consommation mémoire d'allouer les planes non consécutifs sur HW1, car cette façon de faire permet de se passer d'utiliser de la mémoire qui ne pourrait de toute façon pas être utilisée, puisqu'elle n'est tout simplement pas disponible sur AMS2+/ HW2+ ! [EDIT: Cela rend par la même occasion irrecevables les arguments à propos de la fragmentation de la mémoire qui pourrait faire que LCD_SIZE fonctionne, mais pas GRAYDBUFFER_SIZE: la GrayOn() actuelle fait précisément des allocations de GRAYDBUFFER_SIZE contiguës sur AMS 2.xx.]

> Ceci a déjà été discuté plusieurs fois et n'est plus sous discussion (et tu le sais très bien).
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... "Faites ce que je dis qui n'est pas ce que je fais", je n'aime pas trop.

#11: bien vu.
[EDIT: #15: le fork ne concerne que gray.s, et il sera maintenu. TIGCC n'est-il pas lui-même un fork non officiel et non supporté de GCC ?]
-Edité le Vendredi 10 juin 2005 à 12:27 par Lionel Debroux-

Lionel Debroux - membre de TICT.

./Post n°17 Marquer comme non lu.

Folco

Ecrit le: Vendredi 10 juin 2005 à 14:21

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

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

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

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

<<< 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°18 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 10 juin 2005 à 14:39

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4811

Membre n°40

Inscrit le 08 février 2004

Lionel Debroux :
> Il est hors de question de rajouter ne serait-ce qu'une seule instruction pour permettre d'allouer des buffers consécutifs,
Rotfl. Si tu avais regardé en détail le code de la routine de grayscale (ce dont je finis par douter puisque tu as quand même laissé passer des choses qui se voient comme le nez au milieu de la figure, menant à une quarantaine d'octets d'optimisation taille; je sais, tu m'as expliqué qu'il y a maintenir et maintenir), tu saurais que ça en enlève...

Je parle de permettre aussi les buffers consécutifs. Permettre seulement les buffers consécutifs comme tu le proposes est encore plus hors de question! Le gaspillage de mémoire est inacceptable.

Un petit rappel pour tous:
* AMS 1.xx / HW1: la configuration qui a le plus de mémoire disponible (pas de FlashApps = pas d'ACBs et de Frames).
* AMS 2.xx / HW1: la configuration ayant la mémoire disponible d'un AMS 2.xx (avec ACBs, Frames), moindre que celle des AMS 1.xx / HW1.
* AMS 2.xx/3.xx / HW2-HW3: la configuration ayant la mémoire disponible d'un AMS 2.xx et ultérieur (avec ACBs, Frames), moindre que celle des AMS 1.xx / HW1, AMS 3.xx étant pire qu'AMS 2.xx. Planes obligatoirement alloués en-dehors de LCD_MEM.

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#

AMS 2+ / HW2+ est la configuration la plus limitante - et la plus répandue. C'est donc celle pour laquelle les programmes doivent être faits. Autrement dit, il ne sert absolument à rien du point de vue optimisation de la consommation mémoire d'allouer les planes non consécutifs sur HW1, car cette façon de faire permet de se passer d'utiliser de la mémoire qui ne pourrait de toute façon pas être utilisée, puisqu'elle n'est tout simplement pas disponible sur AMS2+/ HW2+ !

Il n'y a pas que ton programme qui consomme de la mémoire, il y a aussi les fichiers en RAM et les TSRs! Moins ton programme consomme de mémoire (même si c'est seulement sur certaines configurations), plus on peut avoir de fichiers en RAM et/ou de TSRs, ce qui est toujours un plus. Il faudrait que les programmeurs arrêtent de présupposer que toute la RAM des calculatrices leur appartient!

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. Il y a d'autres méthodes pour optimiser les références (déjà il y a aussi -freg-relative-a5, et ensuite il y a aussi les relogements format MLink). Soit dit en passant que *scanf, qui est officiellement dans TIGCCLIB, utilise aussi %a4 pour le passage de paramètres, donc ce registre est en principe déjà réservé à cette fin.

le fork ne concerne que gray.s

Donc tu te retrouves avec une routine de gris inofficielle 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).

./Post n°19 Marquer comme non lu.

Kevin Kofler

Ecrit le: Vendredi 10 juin 2005 à 14:43

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4811

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-