Tigcclib - Page 3

PpHd
a écrit : Ils aiment ca a tigcc land.

Kevin Kofler
a écrit : Allez vous faire enc*ler!

..

deplorable..

mais non, je trouve ca hilarant moi

1) Porter EXTgraph est en effet une tres bonne idée :-)

2) Je vais essayer de recompiler des progs de la tict etc. avec cette lib, faudrait que je l'ai avant

lol, de plus en plus fort

solid a écrit :
mais non, je trouve ca hilarant moi

oué rmq vaut mieux en rire

et puis au fond on l'aime bien kevin

Et je te signale que l'ABI de certaines fonctions de TIGCCLIB (ne rêve pas, je ne vais pas te dire lesquelles) changera de manière certaine d'ici la bêta 1 de TIGCC 0.95.

C'est quoi l'ABI? Et pour les prochaine version et bien il faudra reporter. Merci aux numéros de versions de lib

La question est est ce que Kévin se rabaissera a restreindre la liscence du prochain TIGCCLIB. J'espère qu'il n'est pas borné a ce point là

Enfait, c'est uniquement drôle ....

Kevin: Mais j'y ai pense mon cher. Et ce que je prepare SERA compatible. Dans le pire des cas, on fournira plusieurs interfaces.

GNI Et la tu prends un axe nord/est, sud/ouest et tu casses

J'ameliore le caractere evolutif d'abord.

Huhu opur unr fois qu'une lib statique fait gagner 200% de place

C'est pas trop tot

AU moins si tt est en kernel avec cette lib on peu plus dire, "oui mais tt les jeu genlib il prennent tte l'archive et le gain de place est inexistant"

La le gain de place est plus que reel

solid
a écrit : oui mais si tout le monde installe tigcclib, et que tous les prgm l'utilisent, on fait un gain de place monstrueux !!!!

Pas du tout. C'est énorme 11 KO après compression. Rajoute la taille du kernel et tu trouveras que ça ne convient qu'à partir d'une vingtaine de programmes qui l'utilisent. Et TIGCCLIB proposera de plus en plus de fonctions, donc votre librairie dynamique sera de plus en plus grosse. Alors qu'avec la version statique, les nouvelles fonctions ne se retrouveront sur la calculatrice que si un programme les utilise vraiment. Par exemple, tu trouves ça intelligent d'avoir scanf (2 KO) qui traîne sur ta calculatrice alors qu'aucun programme sur ta calculatrice ne l'utilise?

et puis, backbammon en kernel, ca serait marrant non ?

C'est interdit par ma licence.

Uther Lightbringer
a écrit : C'est quoi l'ABI?

Application Binary Interface (par opposition à API - Application Programming Interface). L'interface binaire proposée par la librairie. TIGCC ne garantit que la compatibilité source (API stable, on recompile et c'est bon), pas la compatibilité binaire (ABI stable, on relinke les vieux fichiers objet avec une nouvelle version de tigcc.a et c'est bon). Pour une librairie dynamique, vous avez besoin d'un ABI stable, et nous ne pensons même pas à le garantir. Grâce au système de librairies statiques, on peut changer l'ABI à tout moment sans que quelqu'un ne le remarque. Les anciens programmes utiliseront l'ancienne tigcc.a avec l'ancien ABI, les nouveaux programmes utiliseront la nouvelle tigcc.a avec le nouvel ABI. Et grâce à la compatibilité source, il suffit de recompiler pour mettre à jour la librairie, que l'ABI ait changé ou pas.

Et pour les prochaine version et bien il faudra reporter. Merci aux numéros de versions de lib

Résultat: une librairie dynamique différente pour chaque version de TIGCC. Et il y en a une trentaine chaque année. Résultat: 330 KO par an. Il est où le gain de place???

godzil a écrit :
La le gain de place est plus que reel

Il est totalement théorique. Un programme TIGCC moyen utilise moins d'un KO non-compressé. Alors que la librairie dynamique en est à 11 KO compressés.

C'est clair que je n'utilise à peu près aucune fonction de tigcclib dans mes prog, je crois...
Ou alors à peine une ou deux, mais pas plus.

lol excellent j'av pas vu ce topic

Kevin Kofler a écrit :
Par exemple, tu trouves ça intelligent d'avoir scanf (2 KO) qui traîne sur ta calculatrice alors qu'aucun programme sur ta calculatrice ne l'utilise?

Par exemple, tu trouves ça intelligent d'avoir scanf (2 KO) qui traîne en multiples exemplaires sur ta calculatrice lorsque plusieurs programmes l'utilisent?

à mon avis, il a raison cette fois. Peu de personnes utilisent vraiment beaucoup de fonctions de tigcclib.
Enfin, en tout cas, c'est vrai que maintenant, on pourra les utiliser sans se soucier de la taille qu'elles prennent. Par exemple, moi je n'ai jamais utilisé les fonctions du genre fopen, fclose, etc parce qu'elles prennaient plus de place que l'équivalent avec des ROM_CALL. Mais maintenant que tigcclib est en dynamique, je vais pouvoir les utiliser tout le temps, vu que ça ne grossira pas la taille de mes programmes.

ERREUR! Tu ne tiens pas compte du fait que ces fonctions existent, même si elles existent dans un fichier externe! Donc tu ne peux pas les utiliser sans te soucier de la taille qu'elles prennent! J'en ai marre des gens qui perpétuent ce mythe-là! Et ne me dis pas que tu comptes passer toi aussi du côté obscur des kernels...

tant qu'il ne reste pas du cote obscur du _nostub moi ca me va

Kevin Kofler a écrit :
ERREUR! Tu ne tiens pas compte du fait que ces fonctions existent, même si elles existent dans un fichier externe! Donc tu ne peux pas les utiliser sans te soucier de la taille qu'elles prennent! J'en ai marre des gens qui perpétuent ce mythe-là!

Mais si, on pourra se permettre de les utiliser dans tous nos programmes, vu qu'elles ne feront pas augmenter la taille du prog...
Enfin, on peut très bien s'en passer. et c'est ce que j'ai fait pour l'instant (sauf les focntions de gray.h).

Et ne me dis pas que tu comptes passer toi aussi du côté obscur des kernels...

Mais non...

jackiechan
Mais non...

argh

Kevin, il me suffit de patcher tigcclib.h pour offrir une ABI stable. C'est pas complique. Juste modifie vos formes d'appels.

Et ne me dis pas que tu comptes passer toi aussi du côté obscur des kernels...

Bof,n côté obscur, côté obscur...
pour y avoir le mal, il fallait que le Bien existe avant

PpHd
a écrit : Kevin, il me suffit de patcher tigcclib.h pour offrir une ABI stable. C'est pas complique. Juste modifie vos formes d'appels.

Si tu fais ça, tu passeras ton temps à modifier nos fonctions en assembleur à chaque mise à jour pour les rendre compatibles avec une ancienne ABI, qui de plus est moins efficace. (On ne change pas notre ABI pour faire beau...) Cela aura aussi comme effet que quoi que tu fasses, la DLL sera toujours en retard par rapport au .a (parce que ça prend du temps de modifier toutes les fonctions). Donc les programmeurs qui voudront les nouvelles fonctionnalités et surtout les nouvelles corrections de bogues (et je pense que tout le monde est dans ce cas - qui veut utiliser une ancienne version de TIGCCLIB avec des bogues qui sont corrigés dans la version la plus récente?) continueront à utiliser le .a.

Donc tu n'as pas de souci à te faire, Kevin
Tu peux dormir sur tes deux oreilles sans te soucier de tigcclib.9xz.

Kevin Kofler
a écrit : [...] Allez vous faire enc*ler!

Tu tombe bien bas Kevin ses dernier temps...

Je me suis fâché beaucoup parce que:
* PpHd lance ce projet en sachant très bien que c'est contre ma volonté et celle de mon équipe (les auteurs du code en question, je rappelle), en abusant de notre licence permissive, qui est là pour permettre à tous les programmes de l'utiliser et pour permettre à tout le monde de l'améliorer, pas pour que des gens fassent ce genre de portages malgré notre opposition explicite
* des personnes proposent de compiler Backgammon avec cette librairie dynamique, alors que ma licence interdit explicitement la distribution de versions modifiées (et ce genre de recompilation est une version modifiée). Ce ne serait donc pas seulement immoral (comme ce que fait PpHd), mais illégal.

Ha bon, recompiler qq chose dont la licence le permet est immoral ????

Quand il parlait de recompiler tt les programmes de la TICT ainsi que backgammon, ct pour rire, mais apparement ta pas eu l'air de comprendre...

Kevin Kofler>À mon avis, c'est aussi surtout parce que tu détestes les kernels.
Si qq1 avait proposé de porter un jeu kernel en _nostub alors que l'auteur n'aurait pas été d'accord, tu n'aurais certainement pas réagi comme ça...