GTC : un TIGCC sur votre calculatrice ? - Page 5

Je ne sais pas si je "pense comme XDanger", mais je dois avouer que ton comportement est assez pénible à supporter lorsque tu parles d'un projet dans lequel tu es impliqué (comme l'a si bien dit Lionel Debroux).

Ah ?
Quand je fais ma pub ? c'est vrai que j'aime bien ça
Mais j'en connais d'autres... Hein Kevin !

XDanger : les fonctions imbriquées font gagner de la place ?

Pas nécessairement. Mais dans le cas de la fonction de tthdex, ça m'évite de passer environ 5 paramètres (de 3 à 6, mais plus probablement 5 ou 6) à une fonction... Que je fasse le passage par registres ou pas, ça fait gagner beaucoup de place.

Tu as déjà vu un explorateur "à la Window$" sur TI89, distribué publiquement, avant Einstein ?

XPort et shL n'ont ils pas le look Windows, et ne sont-ils pas sortis publiquement, avant Einstein ?

mais je dois avouer que ton comportement est assez pénible à supporter lorsque tu parles d'un projet dans lequel tu es impliqué (comme l'a si bien dit Lionel Debroux).

Tiens tiens... Kevin et moi ne sommes pas les seuls...
On va en rajouter une couche. Tu as aussi dit le plus grand bien de ta propre librairie à toi, GraphX (qui a certes des qualités, il ne faut pas le nier). Tu as même fait de la pub (en même temps que pour XLib et GenLib) sur le forum de TIGCC, pour une personne qui ne comprenait pas le doublebuffering (le doublebuffering de ta librairie n'est certainement pas plus simple ni plus compliqué que celui de TIGCC, contrairement à ce que tu as alors prétendu). Ca nous a énervé, Kevin et moi, Kevin a supprimé les liens... C'était la veille de ton bannissement, fin août...
(quelqu'un veut des liens vers ce passage ?)

XDanger
a écrit : XPort et shL n'ont ils pas le look Windows, et ne sont-ils pas sortis publiquement, avant Einstein ?

Bien sûr, mais au moment où Thibaut a créé ce topic, ces deux softs n'avaient pas été annoncés.
Mais je trouve quand même que tu aurais pu prendre un autre nom pour ton topic.

Bah non, vu que c'était le seul shell de ce type à l'époque !
Xport et SHL sont sortis avant la fin de mon projet, mais je ne pouvais pas le deviner à l'époque où j'ai créé le topic

> doublebuffering de ta librairie n'est certainement pas plus simple ni plus compliqué que celui de TIGCC, contrairement à ce que tu as alors prétendu
Je ne vois pas comment faire plus simple !! on peut coder avec GraphX sans même savoir ce qu'est le "triple swap buffering".

Et ferme-là un peu, tu n'es pas mieux à nous bassiner avec TICTex, TIGCC, le mode nostub, etc... Tu es très pénible aussi avec les projets dans lesquels tu es impliqué, cher Môssieur.

je trouve pas le titre e son topic spécialement vaniteux

C'est selon chacun. Mais XDanger ne peut que mal ressentir ce que je fais

MacIntoc a écrit :
je trouve pas le titre e son topic spécialement vaniteux

En effet, par rapport au tien, ...

Je précise:
Thibaut: Un [shell] comme vous n'en avez jamais vu sur TI 68 k : [EINSTEIN]
MacIntoc: Les jours de PC-Tools, TicTex et Einstein sont compter...

Sans commentaires...

Je ne vois pas de prétention dans le mien.

"comme vous n'en avez jamais vu sur TI 68 k" ...

C'est bien ça, l'interprétation est très libre :/
Tu penses que j'ai voulu dire quoi avec cette accroche ?
Je crois que tu analyses trop il ne faut pas tenter de voir plus loin que "ça n'a jamais encore existé sur TI".

Le systeme qui emmerde personne :

[nom_du_programme] Description rapide

Ouais, sauf que là, 60% des topics sont pas visité

Et alors? Ce n'est pas en poussant les gens à visiter ton topic avec un titre attrayant que tu vas t'attirer des utilisateurs pour ton shell...

Au moins l'avantage de ne rien mettre d'autre que le nom et la description, c'est que ceux qui vont voir le topic savent à quoi s'attendre...
Ça diminue par exemple les cas "Réponses - 2 / Vues : 230"

Thibaut a écrit :

Tu as déjà vu un explorateur "à la Window$" sur TI89, distribué publiquement, avant Einstein ?

oui, sh'L

Kevin Kofler
a écrit : Et alors? Ce n'est pas en poussant les gens à visiter ton topic avec un titre attrayant que tu vas t'attirer des utilisateurs pour ton shell...

Si !!!!
Pasque des personnes qui aurait pas été accrocher par le titre mais qui aurait quand même été interresser par les fonctionnalités du shell (je parle pas spécialement de Shellian), bah il se serait dis, "encors un shell", et il passe à coté de se qu'il cherche.

MacIntoc
a écrit : bah il se serait dis, "encors un shell"

Et ils auraient eu raison. Arrête de présenter ton shell à toi comme le shell qui va révolutionner le monde! La même chose est valable pour Thibaut d'ailleurs...

Bah g jamais dit qu'il allait révolutionner le monde
C seulement, c le plus complet qui existe
Et puis là n'est pas la question.

Je ne vois pas comment faire plus simple !! on peut coder avec GraphX sans même savoir ce qu'est le "triple swap buffering".

On va citer ce qui s'est passé sur le forum de TIGCC:

Post initial: "Are there any tutorials on double buffering in greyscale? If there are not any could some one explain how to do it? (I have read the the documentation on it but i'm still confused.)
thanks"


Thibaut: " I don't know.

Some powerful graphic libraries which implement double-buffering display very simply exist: Xlib, GenLib and GraphX.

[EDIT by Kevin Kofler: Removed links. Don't try to advertise your own graphics library here. Do not try to recommend DLL graphics libraries here either. Next time I will remove the names too.]"


Myself: "Some good games feature double buffering, without using a messy dynamic library (GraphX doesn't, but the two others do): have a look at Duke 68k, available on ticalc.org.
Thibaut: if the user is not familiar with double buffering, I am not sure he will understand everything in the GraphX documentation (first it's in French, and second the explanation might be a little short). I didn't check if the documentation was good, though, so I might be telling wrong things."


Kevin: "You do not need any external library for double-buffering support. It is built-in into the TIGCCLIB grayscale support.

And no, there is no tutorial yet. Is there a specific part of our documentation you did not understand? Or do you just want a small example to show how everything interacts."


Thibaut: "Lionel: He doesn't understand how to use the double-buffering functionnality of TIGCCgray.
With GraphX and other specialized libraries, the user don't have to understand the mechanism.

For exemple, with Graphx, he just have to write "GX_DisplayWorkBuffer" to display modifications to the screen! It's GraphX which <handles> the synchronisation and the swap buffering, not the user

[EDIT by Kevin Kofler: "gère" = "handles"]


Kevin: ">With GraphX and other specialized libraries, the user don't have to understand the mechanism.

That's wrong. You have to understand double-buffering to use it, whether you use our routines or yours.

<< For exemple, with Graphx, he just have to write "GX_DisplayWorkBuffer" to display modifications to the screen! It's GraphX which <handles> the synchronisation and the swap buffering, not the user >>

What's the difference between calling GX_DisplayWorkBuffer and calling GrayDBufToggleSync?

Yes, you need to wait for synchronization once more after calling GrayDBufToggleSync on HW1. (Use GrayWaitNSwitches(2); after GrayDBufToggleSync .) I think that this needs to be fixed (it should be done by the GrayDBufToggleSync macro)."


Thibaut: "Kevin: the "link" balise exist for what?????????????"


Kevin "To give links related to the topic, not to advertise some programs (at least not in the TIGCC Programming section, and not when it is unrelated to the thread!).

He wants an example for using the built-in double-buffering support in TIGCCLIB, not advertising for external graphics libraries."

fabetal > oui, sh'L
Relis le post #124

Kevin > Arrête de présenter ton shell à toi comme le shell qui va révolutionner le monde ! La même chose est valable pour Thibaut d'ailleurs...
Putain mais arrête d'être idiot ! Arrête de prendre ton interprétation inobjective pour une vérité !


A propos du résumé de XDanger : quand je pense que cet ******* de Kevin m'a censuré, et deux jours après il a remplit sur yAronet un post de liens vers son site alors que l'auteur n'avait pas demandé ça... Tu mérites des baffes Kevin

Donne un lien vers ce dont tu parles, ou cite ce qui s'est passé.

Ca ce passe au moins une fois par semaine mais franchement ce débat stérile de celui qui fait le plus de pub m'énèrve de plus en plus. Je comprends tout a fait que l'on veille faire parler ce ses programmes (sourtout quand ils sont bons et trop peu utilisés) alors arretez ces querelle débiles.
Je vous rappelle que le sujet est un débat sur GTC/TI-GCC pas un problème de pub ca serait bien que vous en discutiez sur un autre topic.

Revenons au sujet

Pour résumer, GTC devrait faire beaucoup d'heureux à sa sortie. Il permet de compiler les sources TIGCC, moyennant quelques fois des adaptations.

Incontestablement, il n'a rien à voir avec CC. Il est mille fois plus convivial, rapide, performant.
Ce n'est pas encore 100% compatible avec TIGCC, mais il n'en est pas loin, surtout pour ceux qui n'utilisent pas certaines extensions pointues du C.

Un membre de l'équipe TIGCC le rejette (il rêve de garder son monopole, de dominer le monde avec son TIGCC). Il est très malin d'encourager de la sorte l'auteur ! après il trouve que de moins en moins de personnes programment sur TI.

Je rajoute: on attends toujours noël et un reve que ca ne soit pas uns fois de plus reporté!

moi c le nouvelle an

surtout pour ceux qui n'utilisent pas certaines extensions pointues du C.

Qui sont ceux-là ? Je pense que ce sont surtout (démontrez-moi le contraire):
- les newbies, pour une partie importante d'entre eux.
- ceux qui ne se soucient pas trop de performance ou de taille (les ASM inline avec opérandes C améliorent parfois beaucoup la taille, et évidemment la vitesse s'ils sont écrits correctement). Je rappelle que j'estime avoir gagné au moins 1,5 KO sur 13 environ dans tthdex, en utilisant de l'assembleur, avec ou sans opérandes C. Le changement de compilateur ne donnera jamais un résultat pareil...

Il est mille fois plus convivial, rapide, performant.

Je prendrai le 'mille fois' comme une façon de parler...
Rapide et performant, le bench que tu as posté semble le montrer (du moins pour des sources qui ne sont pas trop compliqués...). Est-ce que GTC supporte 'inline' maintenant ? Parce que c'est une "dépub" formidable de ne pas le supporter, d'autant plus que ton bench montre que sur un programme particulier (ça pourrait changer un peu sur d'autres types de programmes), le code produit est 10% plus lent que celui produit par GCC, qui n'est pourtant pas toujours très fin en optimisation, même si c'est un des meilleurs...

Il est très malin d'encourager de la sorte l'auteur ! après il trouve que de moins en moins de personnes programment sur TI.

On ne va pas revenir sur le sujet de la déliquescence de la communauté... Cependant, ne penses-tu pas que si Kevin n'avait pas été ici depuis un certain temps, pour aider ceux qui ont des problèmes en C ou assembleur, la communauté aurait été plus bas ?
Et puis les calculettes scientifiques sont de moins en moins bien vues par l'Education Nationale Française, il ne faut pas l'oublier. Pourtant, les capacités mathématiques de la 89 ne sont pas impressionnantes (à part pour les pompes, c'est insuffisant au-delà de la terminale)...

Et je suis d'accord avec Uther Lightbringer et MacIntoc. Ca serait super si le projet sortait dans les temps, sans bugs ! (Il vaut mieux que ça sorte en retard de plusieurs mois, plutôt que ça soit plein de bugs ou que ça produise du code inefficace...)

Qui sont ceux-là ? Je pense que ce sont surtout (démontrez-moi le contraire):
- les newbies, pour une partie importante d'entre eux. - ceux qui ne se soucient pas trop de performance ou de taille (les ASM inline avec opérandes C améliorent parfois beaucoup la taille, et évidemment la vitesse s'ils sont écrits correctement). Je rappelle que j'estime avoir gagné au moins 1,5 KO sur 13 environ dans tthdex, en utilisant de l'assembleur, avec ou sans opérandes C. Le changement de compilateur ne donnera jamais un résultat pareil...

Tu oublie:- ceux qui ont appris le C ANSI et n'ont pas envie ou le temps de ce farcir de nombreuses extensions plus ou moins utiles dont on peut se passer.

Erf... en fait, je pensait plutot à GT-Basic