Avant d'aller me coucher... - Page 5

a oui, merde, c pas con comme remarque, ça...

mdr, bien joué mac

Pollux
: Et GTC version PC sortira sûrement bien avant...

Pas sûr. TIGCC 0.95 bêta 1 est prévue pour très bientôt. Et le nouveau linker rendra GTools C (surtout la version PC) totalement obsolète. Pas de vrai linker -> poubelle. Tu ne pourras pas du tout utiliser les versions à jour de TIGCCLIB parce qu'elles nécessitent le nouveau linker. Et nous ne corrigerons très probablement plus aucun bogue dans TIGCC 0.94, aussi grave qu'il soit. Donc tu dépendras d'une version de librairie totalement dépassée, obsolète et boguée.

ton état d'esprit est tres obsolété KK.
tout faire pour éliminier la concurence, on sait ou ca mene

à la dictature...
ceci dit lorsque GTC on PC sortira, il sera je parie laaaaaargement mieux que la 1ere release de TIGCC, et ça c'est surprenant que tu n'en parle pas, hein mon ptit KK ?
au bout du compte, un gtc avec autant d'ancienneté que tigcc serait sans doute mieux, alors que pollux y travaille seul !

Microbug
: tout faire pour éliminier la concurence

On ne fait pas tout pour éliminer la concurrence, mais pour faire avancer notre projet. Si la concurrence n'arrive pas à suivre, ce n'est pas notre problème. Les concurrents n'ont qu'à ne pas parasiter notre librairie (TIGCCLIB).

PS: La nouvelle TIGCCLIB nécessitera aussi le passage par registres complètement fonctionnel.

solid
: ceci dit lorsque GTC on PC sortira, il sera je parie laaaaaargement mieux que la 1ere release de TIGCC

1. Avec tout le temps que Pollux nous fait attendre, il a intérêt que ce soit le cas.
2. Avec son absence de vrai linking (un seul fichier objet seulement), il me rappelle énormément l'âge de pierres de la programmation TIGCC, justement.

le parasite, c'est plutot toi la qui considere toutes les personnes qui s'interesse à la création d'un compilo alternatif comme des sous merdes

!slap Kevin Kofler
• GoldenCrystal slaps Kevin Kofler around a bit with a large trout !

Arrête de critiquer tout ce que les autres font quand ça ne te plaît pas.

C'est clair moi j'en ai très marre. Son comportement insocial devrait être interdit par la charte du forum.
Moi je kicke maintenant.

Nerick
: Tous les programmes de FlashZ sont écrits en asm, sauf BallRace3D (si mes souvenirs sont bons)

Mais GTC compile aussi l'ASM

Thibaut :
C'est clair moi j'en ai très marre. Son comportement insocial devrait être interdit par la charte du forum. Moi je kicke maintenant.

C'est ton insolence qui devrait être interdite par la charte!

vous seriez interdits tous les deux, moi aussi, et pas mal de monde encore surement ...

Euuuh, presque tout le monde (dont yAro, en cherchant bien) a transgressé la charte au moins une fois.
Et si Kevin est gonflant, Thibaut l'est aussi, donc, avec ça, on est bien avancé...

uéééé faut kické vark

Avec son absence de vrai linking (un seul fichier objet seulement), il me rappelle énormément l'âge de pierres de la programmation TIGCC, justement.

Non mais tu sais seulement de quoi tu parles? C'est complètement inutile de diviser la source en plusieurs morceaux avec un compilo 12x plus rapide que TIGCC, donc je ne vois absolument pas le problème de ne pas passer par des fichiers intermédiaires

Et si tu parles du support des sections comme dans le nouveau système de patch de TIGCC 0.95, ne t'inquiète pas, il arrive...

Pollux
:

Avec son absence de vrai linking (un seul fichier objet seulement), il me rappelle énormément l'âge de pierres de la programmation TIGCC, justement.

Non mais tu sais seulement de quoi tu parles? C'est complètement inutile de diviser la source en plusieurs morceaux avec un compilo 12x plus rapide que TIGCC,

Ce n'est pas inutile, c'est pratiquement indispensable pour les gros projets. Diviser le programme en plusieurs fichiers objets permet aussi:
* de choisir des options de compilation pour chaque fichier (sans utiliser des pragmas non-standard de ton compilateur qui sont incompatibles avec TIGCC).
* de contrôler l'accès aux fonctions et variables (static).
* de créer des librairies statiques.

Kevin Kofler
: C'est ton insolence qui devrait être interdite par la charte!

Ton attitude de chef aussi.

> sans utiliser des pragmas non-standard de ton compilateur qui sont incompatibles avec TIGCC
Ce sont des #pragma !

Pour le point 2, ce n'est pas indispensable. TIGCC le permettait-il quand il est sortit ?
GTC va évoluer, pour avoir de moins en moins de défauts

Pour 3, alors explique-moi pourquoi GTC est fournit avec 7 librairies statiques...
Il ne permet pas d'en créer, mais il permet d'en utiliser. C'est le principal !
Pour en créer, je suppose que Pollux utilise un convertisseur .a -> .dat. C'est pas compliqué

Thibaut :
> sans utiliser des pragmas non-standard de ton compilateur qui sont incompatibles avec TIGCC Ce sont des #pragma !

C'est bien ce que j'ai dit...

Pour 3, alors explique-moi pourquoi GTC est fournit avec 7 librairies statiques... Il ne permet pas d'en créer, mais il permet d'en utiliser.

C'est bien ce que j'ai dit...
"* de créer des librairies statiques"...

Pour en créer, je suppose que Pollux utilise un convertisseur .a -> .dat. C'est pas compliqué

Je me demande ce qu'il fout dans ses fichiers .dat, d'ailleurs.

vous allez encore squatter longtemps des topic ?
maintenant vous n'etes meme plus dans votre section !

Désolé Mais comme d'habitude c'est le même qui a lancé le débat...

J'arrête là.

Perso, même si j'approuve deux (enfin trois avec l'officiel de TI) compilateurs pour la TI, je trouve vraiment dommage qu'on ne puisse gérer qu'un fichier .c avec GTC. Sur ce point, je suis assez d'accord avec Kevin, dès qu'on a un projet assez important, c'est bien pratique.

Explique-moi en quoi la gestion GTC lorsqu'on a plusieurs .c présente des inconvénients par rapport à la gestion TIGCC, si ce n'est que TIGCC passe par des énormes fichiers .o intermédiaires et que ça accélère le processus lorsque, dans le cas de TIGCC, le temps de compilation n'est pas négligeable.

et bien par exemple si on souhaite réutiliser certains morceaux de source dans plusieurs projets
Dans ce cas la on peut évidemment faire un copier coller , mais si on mets à jour le code, il faudra remodifier tous les projets. En utilisant le meme fichier, il n'y a plus qu'a recompiler.
Pour moi c'est une fonctionnalité qui , même si elle n'est pas indispensable, est très pratique .
Et puis, même si GTC est tres rapide pour compiler, il le sera encore plus si on ne doit pas tout recompiler

Je pense que ce serait une bonne chose à ajouter ds une version ultérieur

Dans ce cas la on peut évidemment faire un copier coller , mais si on mets à jour le code, il faudra remodifier tous les projets. En utilisant le meme fichier, il n'y a plus qu'a recompiler.

Tu peux simplement inclure ton fichier .c dans le projet au lieu du fichier .o. Et tu dois mettre à jour ton fichier .o comme pour ton fichier .c ; le mieux est d'utiliser un path relatif pour que le compilo aille chercher la dernière version lui-même.

Et puis, même si GTC est tres rapide pour compiler, il le sera encore plus si on ne doit pas tout recompiler

Perso une compilation de 1 sec ou 2 sec je ne vois pas la différence

Perso une compilation de 1 sec ou 2 sec je ne vois pas la différence

Certe, mais si tu as un très vieux pc, genre un 133mhz :/
Et puis 1 secondes de gagner x plein de compilation pour tester, moi je suis jamais contre

Euh faut pas déconner, si tu peux pas te contenter d'une compilation 12x plus rapide
Si ça prend 1.4 sec sur mon 350, ça devrait prendre 3.7 sec sur ton 133. C'est pas la mort...

Et si vraiment tu veux une compilation ultra rapide je peux désactiver l'optimisation VCG. Le code sera un peu moins bon mais la compilation sera probablement bien plus rapide.

heu moi tu sais je m'en fou je prog pas pour ti
je dis juste que plus la compilation est rapide, mieux c'est.
Le mieux serait d'avoir un mode 'debug' qui compile rapidement mais sans forcémment toutes les optimisations possibles, et un mode 'release' qui compile plus lentement, mais produit le meilleur code possible

Vu la vitesse du mode "release" pour un projet qui s'approche de la limite des 64k, ce n'est pas vraiment la peine d'avoir 2x plus de makefiles...

Pollux, moi aussi je trouve que ça serait mieux qu'on puisse compiler des sources séparément pour les lier après. Même si ce n'est pas 100 % indispensable, c'est bien pratique !
J'espère que ce sera possible dans une version future