Tigcclib - Page 5

j'avais cru comprendre

Tu n'as pas du tout compris ce que je dis. Pour une librairie statique, seules les fonctions reellements utilisees sont sur la calculatrice. Les autres n'y sont pas, même pas en archive. Alors qu'avec ton système, la librairie entière traîne sur la calculatrice (en archive ou en RAM, peu importe, ça reste de la place perdue)!

PpHd a écrit :
De maniere extremement significative Ok, je les recompilerais. Mais faut que je recupere aussi les sources d'obj2ti pour enlever ce *ù*^*ù de message de 'Libraries are not executable' qui prend quasiment 3Ko sur les 10Ko.

C'est parce qu'on (JM, Sebastian et moi) trouve que c'est une mauvaise utilisabilité de quitter sans message d'erreur dans cette situation. Et je te signale que les packs archives ne sont pas officiellement supportés par TIGCC et ne le seront pas dans le futur proche. (Tu connais notre ligne actuelle: pas de fonctionnalités incompatibles avec les anciens kernels.) Et par conséquent, le fait que le message soit redondant si on est dans un pack archive ne nous intéresse pas.

c'est amusant, tu aimerais bien oublier à jamais les kernels en général mais pas les "anciens kernels" que tout le monde aimerait oublier...

bah... s'il accepte les nouveaux, tous le monde va se rendre compte qu'ils sont plus pratique que le _nostub. Donc il garde les anciens

Tu n'as pas du tout compris ce que je dis. Pour une librairie statique, seules les fonctions reellements utilisees sont sur la calculatrice. Les autres n'y sont pas, même pas en archive. Alors qu'avec ton système, la librairie entière traîne sur la calculatrice (en archive ou en RAM, peu importe, ça reste de la place perdue)!

certes mais 10ko en archive ce n'est pas le plus grave.

bah... s'il accepte les nouveaux, tous le monde va se rendre compte qu'ils sont plus pratique que le _nostub. Donc il garde les anciens

Certainement.

Kevin Kofler a écrit :
Tu n'as pas du tout compris ce que je dis. Pour une librairie statique, seules les fonctions reellements utilisees sont sur la calculatrice. Les autres n'y sont pas, même pas en archive. Alors qu'avec ton système, la librairie entière traîne sur la calculatrice (en archive ou en RAM, peu importe, ça reste de la place perdue)!

Tu n'as pas du tout compris ce que pas mal de gens essayent de te faire comprendre. Avec une librairie dynamique tu n'as qu'une seule fois le code sur la calculatrice. Avec les librairies statiques, tu peux avoir facilement jusqu'à 6 ou 7 fois les mêmes routines sur la même calculatrice.

Pour une librairie statique, seules les fonctions reellements utilisees sont sur la calculatrice. Les autres n'y sont pas, même pas en archive. Alors qu'avec ton système, la librairie entière traîne sur la calculatrice (en archive ou en RAM, peu importe, ça reste de la place perdue)!

avoir les memes fonctions en de multiples exemplaires sur la calc tu trouves que c'est mieux?
surtout que plus t'as de progs qui utilisent les librairies statiques plus ca fait de place gaspillee inutilement, et ca rattrape tres vite la "place gaspillee" par une lib dynamique... surtt que la taille prise par la lib dynamique reste fixe, alors qu'avec les libs statiques, plus t'as de progs, plus ca bouffe de la place, c pas vraiment super...

hum cross post

en plus de l'avantage de la mise ajour simplifiée

C clair si on a un scanf qui corrompt les certifs, mieux vaux avoir une lib dynamique pour mettre a jour que une lib statique !
Surtout si on a pas les sources du prog liké statiquement..

Et pi imaginez, si on a 32767 personnes qui utilise 7 programmes utilisant ce scanf, vaus mieux t'il qu'il doivent chercher 7 programme (soit 7*32767 téléchargement ?) ou recuperer 1 seule lib dyna (cad seulement 1*32767 téléchargement) ??

Sa fait quand meme bcp moins de temps perdu

(dsl kevin, mais ct trop tentant )

heu oui enfin... un scanf qui corromp les certifs.. ct ptetre pas super comme exemple

Lol

ct pour reprendre une longue discution entre PpHd et kevin

OU kevin parle de 32767 utilisateur et PpHd de corruption de certif (cf ici)
et ici si je me rapel il parlait du scanf, donc vala, on mélange le tt et sa donne sa

lol ok

MacIntoc a écrit :
bah... s'il accepte les nouveaux, tous le monde va se rendre compte qu'ils sont plus pratique que le _nostub. Donc il garde les anciens

C'est encore une accusation infondée. La compatibilité avec les anciens kernels est gardée pour des raisons de compatibilité. Et parce qu'on ne voit pas de bon œil le monopole d'un seul kernel (PreOs en l'occurrence).

Uther Lightbringer
a écrit : certes mais 10ko en archive ce n'est pas le plus grave.

11 KO, pas 10. Et c'est un gaspillage de place, un point, c'est tout.

BiHi
a écrit : Tu n'as pas du tout compris ce que pas mal de gens essayent de te faire comprendre. Avec une librairie dynamique tu n'as qu'une seule fois le code sur la calculatrice. Avec les librairies statiques, tu peux avoir facilement jusqu'à 6 ou 7 fois les mêmes routines sur la même calculatrice.

6 ou 7 fois 1 KO, c'est toujours moins que 11 KO.
Et les programmes TIGCC n'utilisent pas plus qu'un KO de tigcc.a en moyenne. Il y a beaucoup de routines dans tigcc.a, mais beaucoup sont rarement utilisées. La plupart des fonctions proposées par TIGCCLIB sont des ROM_CALLs.

sBibi
a écrit : avoir les memes fonctions en de multiples exemplaires sur la calc tu trouves que c'est mieux?

Oui.

surtout que plus t'as de progs qui utilisent les librairies statiques plus ca fait de place gaspillee inutilement,

Nuance: c'est de la place utilisée, pas de la place gaspillée.

et ca rattrape tres vite la "place gaspillee" par une lib dynamique...

Non, cf. ma réponse à BiHi. (Et ce n'est pas la première fois que je le dis.)

surtt que la taille prise par la lib dynamique reste fixe, alors qu'avec les libs statiques, plus t'as de progs, plus ca bouffe de la place, c pas vraiment super...

Ben, c'est plutôt logique que "plus de programmes" = "plus de place"...

godzil
a écrit : C clair si on a un scanf qui corrompt les certifs, mieux vaux avoir une lib dynamique pour mettre a jour que une lib statique !

Tu m'expliqueras comment tu corromps tes certificats avec mon scanf à part peut-être (et encore, ça ne sera certainement pas facile) en lui passant des pointeurs foireux en argument (mais dans ce cas, c'est de ta faute, pas de la mienne).
Désolé, mais tu exagères vraiment...
Je n'ai jamais vu une routine qui efface les certificats. Même pas une qui fait exprès, et encore moins une qui le fait par erreur.

Et pi imaginez, si on a 32767 personnes qui utilise 7 programmes utilisant ce scanf, vaus mieux t'il qu'il doivent chercher 7 programme (soit 7*32767 téléchargement ?) ou recuperer 1 seule lib dyna (cad seulement 1*32767 téléchargement) ??

Plus une librairie est utilisée, moins il y a de risque que ce genre d'erreurs passe inobservé. Donc il est peu probable qu'une mise à jour d'une librairie soit suffisamment importante pour qu'on doive mettre à jour 7 programmes à la fois. Ça arrive, mais rarement. Il est bien plus probable de devoir mettre à jour 7 librairies dynamiques séparément alors que dans le cas d'une librairie statique, il aurait suffi d'attendre la mise à jour du programme principal un mois plus tard pour avoir les 8 mises à jour à la fois.

Sa fait quand meme bcp moins de temps perdu

Ben non, cf. ci dessus.

sBibi a écrit :
heu oui enfin... un scanf qui corromp les certifs.. ct ptetre pas super comme exemple

En effet, c'est du n'importe quoi.

je dois bien avoir 11 fois les routines de gray sur ma TI...
utiliser tigcclib.9xz ferait la même taille que ces 11 routines, mais avec plus de fonctionnalités

Mais tu n'es pas le cas moyen. En moyenne, on n'a pas 11 jeux en C et en niveaux de gris sur sa calculatrice.

C'est encore une accusation infondée. La compatibilité avec les anciens kernels est gardée pour des raisons de compatibilité. Et parce qu'on ne voit pas de bon œil le monopole d'un seul kernel (PreOs en l'occurrence).

Pourtant vous faites bien un MIN_AMS alors pourquoi pas un MIN_KERNEL

11 KO, pas 10. Et c'est un gaspillage de place, un point, c'est tout.

Pphd a dis qu'après optimisation il pourait faire 3Ko de moins alors j'ai pris 10Ko pour être pésimiste et éviter que l'on ai un débat inutile sur le place gagné

6 ou 7 fois 1 KO, c'est toujours moins que 11 KO. Et les programmes TIGCC n'utilisent pas plus qu'un KO de tigcc.a en moyenne. Il y a beaucoup de routines dans tigcc.a, mais beaucoup sont rarement utilisées. La plupart des fonctions proposées par TIGCCLIB sont des ROM_CALLs.

On va prendre un cas moyen: 5 jeux niv de gris dont 3 utilisent les sprites et 2 progs qui utilisent les printf scanf. On approche les 11Ko(comme ca tu arretera de te pleindre). Et il reste l'énorme avantage des mise a jours simplifiées.

>surtout que plus t'as de progs qui utilisent les librairies statiques plus ca fait de place gaspillee inutilement, Nuance: c'est de la place utilisée, pas de la place gaspillée.

Peut importe : le mot inutilement vaut quand même dans les deux cas.

heu oui enfin... un scanf qui corromp les certifs.. ct ptetre pas super comme exemple

En effet c'est pas bon example. Mais si on s'apperçoit d'un bug sur une routine est mauvaise il suffit de faire une mise a jour de la lib et pas retélécharger tous programmes en ce posant la question est ce que l'auteur afait la mise a jour.

Uther Lightbringer
a écrit : Pourtant vous faites bien un MIN_AMS alors pourquoi pas un MIN_KERNEL

Parce que:
1. il n'est pas possible ou du moins pas pratique (selon la fonctionnalité individuelle) de vérifier que le bon kernel soit présent avant d'utiliser ses fonctionnalités. (Comment est-on censés distinguer les "bons" kernels des "mauvais"? Avec une sorte de switch sur les identifiants? Et on fait quoi avec les kernels pas encore sortis? Bref, c'est lourd, et ce n'est pas satisfaisant comme solution.)
2. la demande n'est pas suffisante.
3. les fonctionnalités supplémentaires apportées par les nouveaux kernels ne sont pas suffisantes pour justifier les efforts nécessaires pour les implémenter. Surtout qu'il ne s'agit pour la plupart pas de nouvelles fonctions qu'il suffit de déclarer comme pour MIN_AMS, mais d'additions de format à gérer du côté du linker. Et pour les nouvelles fonctions, nous ne les supportons pas officiellement parce que nous ne rajoutons aucune fonction ou variable à TIGCCLIB qui ne marche qu'en mode kernel. Donc: pas d'implémentation _nostub -> pas de support par TIGCCLIB. Si vous avez une implémentation _nostub équivalente, ça s'envoie à Team@tigcc.ticalc.org (sachant que nous nous réservons le droit d'utiliser uniquement cette implémentation _nostub et pas la fonction kernel équivalente pour des raisons de compatibilité).
4. comme déjà dit, on ne voit pas de bon œil le monopole d'un seul kernel (PreOs en l'occurrence).

Pphd a dis qu'après optimisation il pourait faire 3Ko de moins alors j'ai pris 10Ko pour être pésimiste et éviter que l'on ai un débat inutile sur le place gagné

Tant que ce n'est pas fait, je continue à compter 11 KO.

On va prendre un cas moyen: 5 jeux niv de gris dont 3 utilisent les sprites et 2 progs qui utilisent les printf scanf. On approche les 11Ko(comme ca tu arretera de te pleindre).

Non. Niveaux de gris et sprites tiennent en environ 1 KO après compression. printf et scanf aussi. (Et ne te plains pas: la librairie dynamique est elle-aussi compressée.) Donc on en est à environ 7 KO. Et puis les 2 programmes qui utilisent scanf, tu me les trouves. Je n'en connais aucun. Je n'ai même pas reçu de confirmation que mes routines marchent.

Et il reste l'énorme avantage des mise a jours simplifiées.

Les mises à jour ne sont pas simplifiées, elles sont compliquées: on est obligés à mettre à jour tigcclib à la main (en plus des mises à jour individuelles) alors que dans le cas de tigcc.a, il suffit d'attendre la prochaine mise à jour du programme individuel.

Peut importe : le mot inutilement vaut quand même dans les deux cas.

Non. "Inutile" implique que le code est inutilisé, ce qui n'est pas le cas avec les librairies statiques.

En effet c'est pas bon example. Mais si on s'apperçoit d'un bug sur une routine est mauvaise il suffit de faire une mise a jour de la lib et pas retélécharger tous programmes en ce posant la question est ce que l'auteur afait la mise a jour.

Comme déjà dit plus haut, mais apparemment ignoré par toi:
Plus une librairie est utilisée, moins il y a de risque que ce genre d'erreurs passe inobservé. Donc il est peu probable qu'une mise à jour d'une librairie soit suffisamment importante pour qu'on doive mettre à jour 7 programmes à la fois. Ça arrive, mais rarement. Il est bien plus probable de devoir mettre à jour 7 librairies dynamiques séparément alors que dans le cas d'une librairie statique, il aurait suffi d'attendre la mise à jour du programme principal un mois plus tard pour avoir les 8 mises à jour à la fois.

Et enfin, je ne vois pas l'intérêt de rajouter le support des packs archive PreOs à TIGCC sachant que:
1. il suffit d'utiliser kpack.exe sur les programmes produits par TIGCC pour en faire des packs archive.
2. TIGCC permet déjà la compression ExePack qui:
2.1. compresse mieux et
2.2. est plus portable (compatible avec les anciens kernels et avec l'absence de kernel).

Kevin Kofler a écrit :
C'est encore une accusation infondée. La compatibilité avec les anciens kernels est gardée pour des raisons de compatibilité. Et parce qu'on ne voit pas de bon œil le monopole d'un seul kernel (PreOs en l'occurrence).

Je n'y peux rien si je suis le seul a mettre a jour un kernel.

11 KO, pas 10. Et c'est un gaspillage de place, un point, c'est tout.

8Ko maintenant. J'ai aussi recompile en _regparm(2) en mode kernel les fichiers .c.

6 ou 7 fois 1 KO, c'est toujours moins que 11 KO.
Et les programmes TIGCC n'utilisent pas plus qu'un KO de tigcc.a en moyenne. Il y a beaucoup de routines dans tigcc.a, mais beaucoup sont rarement utilisées. La plupart des fonctions proposées par TIGCCLIB sont des ROM_CALLs.

8 programmes suffisent pour rattraper alors. 8 programmes tigcc ce n'est pas beaucoup.

Nuance: c'est de la place utilisée, pas de la place gaspillée.

Qui pourrait etre evitee.

Tu m'expliqueras comment tu corromps tes certificats avec mon scanf à part peut-être (et encore, ça ne sera certainement pas facile) en lui passant des pointeurs foireux en argument (mais dans ce cas, c'est de ta faute, pas de la mienne).
Désolé, mais tu exagères vraiment...

Oui. scanf est exagere. Mais c'est juste un exemple d'ecole.

Je n'ai jamais vu une routine qui efface les certificats. Même pas une qui fait exprès, et encore moins une qui le fait par erreur.

Forcement, personne n'a envie de les distribuer ce genre de routine...

Plus une librairie est utilisée, moins il y a de risque que ce genre d'erreurs passe inobservé. Donc il est peu probable qu'une mise à jour d'une librairie soit suffisamment importante pour qu'on doive mettre à jour 7 programmes à la fois. Ça arrive, mais rarement. Il est bien plus probable de devoir mettre à jour 7 librairies dynamiques séparément alors que dans le cas d'une librairie statique, il aurait suffi d'attendre la mise à jour du programme principal un mois plus tard pour avoir les 8 mises à jour à la fois.

Je dirais le contraire.

En effet, c'est du n'importe quoi.

Oui.

Kevin Kofler a écrit :
Parce que:
1. il n'est pas possible ou du moins pas pratique (selon la fonctionnalité individuelle) de vérifier que le bon kernel soit présent avant d'utiliser ses fonctionnalités. (Comment est-on censés distinguer les "bons" kernels des "mauvais"? Avec une sorte de switch sur les identifiants? Et on fait quoi avec les kernels pas encore sortis? Bref, c'est lourd, et ce n'est pas satisfaisant comme solution.)
2. la demande n'est pas suffisante.
3. les fonctionnalités supplémentaires apportées par les nouveaux kernels ne sont pas suffisantes pour justifier les efforts nécessaires pour les implémenter. Surtout qu'il ne s'agit pour la plupart pas de nouvelles fonctions qu'il suffit de déclarer comme pour MIN_AMS, mais d'additions de format à gérer du côté du linker. Et pour les nouvelles fonctions, nous ne les supportons pas officiellement parce que nous ne rajoutons aucune fonction ou variable à TIGCCLIB qui ne marche qu'en mode kernel. Donc: pas d'implémentation _nostub -> pas de support par TIGCCLIB. Si vous avez une implémentation _nostub équivalente, ça s'envoie à Team@tigcc.ticalc.org (sachant que nous nous réservons le droit d'utiliser uniquement cette implémentation _nostub et pas la fonction kernel équivalente pour des raisons de compatibilité).
4. comme déjà dit, on ne voit pas de bon œil le monopole d'un seul kernel (PreOs en l'occurrence).

Le nombre de RAM_CALL minimale. Et vous ne supportez pas les fontes du boot.
De toute facon, kernel.h est la pour combler ce manque.

Les mises à jour ne sont pas simplifiées, elles sont compliquées: on est obligés à mettre à jour tigcclib à la main (en plus des mises à jour individuelles) alors que dans le cas de tigcc.a, il suffit d'attendre la prochaine mise à jour du programme individuel.

Cf kernel VS nostub.

Non. "Inutile" implique que le code est inutilisé, ce qui n'est pas le cas avec les librairies statiques.

Redondant alors.

Comme déjà dit plus haut, mais apparemment ignoré par toi: Plus une librairie est utilisée, moins il y a de risque que ce genre d'erreurs passe inobservé. Donc il est peu probable qu'une mise à jour d'une librairie soit suffisamment importante pour qu'on doive mettre à jour 7 programmes à la fois. Ça arrive, mais rarement. Il est bien plus probable de devoir mettre à jour 7 librairies dynamiques séparément alors que dans le cas d'une librairie statique, il aurait suffi d'attendre la mise à jour du programme principal un mois plus tard pour avoir les 8 mises à jour à la fois.

Cf + haut.

> Et parce qu'on ne voit pas de bon œil le monopole d'un seul kernel (PreOs en l'occurrence
Excuse-moi, mais PreOS est facilement modifiable (open-source, et pas de source de 20 Mo, qu'il faut compiler encore avec un gros compilo - 10 Mo de download), donc je n'appelle pas ça un monopole. J'en connais qui voient d'un moins bon oeil la perte du monopole de leur soft

et qui voit d'un bon oeil le monopole de leur mode de programmation

... je sens déjà que Kevin va dire que c normal si TI a le monopole ...

et alors ???
ça empèche de dévellopper un mode alternatif ????

PpHd
a écrit : Je n'y peux rien si je suis le seul a mettre a jour un kernel.

Je sais, mais si on ne veut pas créer un monopole, on n'a pas d'autre choix que de continuer à supporter les kernels qui ne sont pas à jour.

8Ko maintenant. J'ai aussi recompile en _regparm(2) en mode kernel les fichiers .c.

C'est de l'inefficacité gratuite que d'utiliser du regparm(2).

8 programmes suffisent pour rattraper alors. 8 programmes tigcc ce n'est pas beaucoup.

Tu repasseras à au moins 12 KO quand les nouvelles fonctions sur lesquelles je travaille seront rajoutées à TIGCC 0.95.

Je dirais le contraire.

Et pourquoi?

PpHd a écrit :
Le nombre de RAM_CALL minimale. Et vous ne supportez pas les fontes du boot. De toute facon, kernel.h est la pour combler ce manque.

Si nous ne supportons pas certains RAM_CALLs, c'est parce qu'ils sont inutiles et encouragent la programmation sale. C'est le cas de Heap, FolderListHandle, MainHandle etc. Et aussi des fontes du boot. Déjà, la méthode de XDanger est à la limite de l'acceptable (personnellement, je trouve toujours qu'il faut utiliser DrawStr et DrawChar et rien d'autre), mais le fait de prendre les premières fontes qu'on trouve dans l'ordre numérique des adresses de la ROM est vraiment inacceptable.

Pollux a écrit :
> Et parce qu'on ne voit pas de bon œil le monopole d'un seul kernel (PreOs en l'occurrence
Excuse-moi, mais PreOS est facilement modifiable (open-source, et pas de source de 20 Mo, qu'il faut compiler encore avec un gros compilo - 10 Mo de download), donc je n'appelle pas ça un monopole. J'en connais qui voient d'un moins bon oeil la perte du monopole de leur soft

Je te signale qu'il faut un paquet de presque 4 MO (TIGCC) pour compiler PreOs.

MacIntoc a écrit :
et alors ??? ça empèche de dévellopper un mode alternatif ????

Oui. Il y a un mode natif, et c'est le mode à utiliser. Tout le reste n'a pas lieu d'être.

Parce que:
1. il n'est pas possible ou du moins pas pratique (selon la fonctionnalité individuelle) de vérifier que le bon kernel soit présent avant d'utiliser ses fonctionnalités. (Comment est-on censés distinguer les "bons" kernels des "mauvais"? Avec une sorte de switch sur les identifiants? Et on fait quoi avec les kernels pas encore sortis? Bref, c'est lourd, et ce n'est pas satisfaisant comme solution.)
2. la demande n'est pas suffisante.
3. les fonctionnalités supplémentaires apportées par les nouveaux kernels ne sont pas suffisantes pour justifier les efforts nécessaires pour les implémenter. Surtout qu'il ne s'agit pour la plupart pas de nouvelles fonctions qu'il suffit de déclarer comme pour MIN_AMS, mais d'additions de format à gérer du côté du linker. Et pour les nouvelles fonctions, nous ne les supportons pas officiellement parce que nous ne rajoutons aucune fonction ou variable à TIGCCLIB qui ne marche qu'en mode kernel. Donc: pas d'implémentation _nostub -> pas de support par TIGCCLIB. Si vous avez une implémentation _nostub équivalente, ça s'envoie à Team@tigcc.ticalc.org (sachant que nous nous réservons le droit d'utiliser uniquement cette implémentation _nostub et pas la fonction kernel équivalente pour des raisons de compatibilité). 4. comme déjà dit, on ne voit pas de bon œil le monopole d'un seul kernel (PreOs en l'occurrence).

1. En effet, je n'avais pas réfléchi a ce problème
2. Tu as fait une enquète ?
3. OK
4. Tigcc c'est un monopole comme beaucoup de logiciel sur TI et personne ne s'en pleint. C'est meme plustot l'inverse.

Tant que ce n'est pas fait, je continue à compter 11 KO.

C'est génial d'argumenter précisément sur des valeurs que tu sait fausses.

On va prendre un cas moyen: 5 jeux niv de gris dont 3 utilisent les sprites et 2 progs qui utilisent les printf scanf. On approche les 11Ko(comme ca tu arretera de te pleindre). >Non. Niveaux de gris et sprites tiennent en environ 1 KO après compression. printf et scanf aussi. (Et ne te plains pas: la librairie dynamique est elle-aussi compressée.) Donc on en est à environ 7 KO. Et puis les 2 programmes qui utilisent scanf, tu me les trouves. Je n'en connais aucun. Je n'ai même pas reçu de confirmation que mes routines marchent.

Pour la compression ne le prends pas mechament je sais comparer ce qui est comparable. Et si aucun programme n'utilise scanf c'est surtout qu'il n'est pas disponible depuis très longtemps mais je suis sur qu'il sera bientot utilisé(peut-etre par moi-meme).

Et il reste l'énorme avantage des mise a jours simplifiées. >Les mises à jour ne sont pas simplifiées, elles sont compliquées: on est obligés à mettre à jour tigcclib à la main (en plus des mises à jour individuelles) alors que dans le cas de tigcc.a, il suffit d'attendre la prochaine mise à jour du programme individuel.

et dans ton cas il faut mettre a jour tous le programmes a la main! Dans un cas tu ne change que ta lib, dans l'autre tous les programmes sans compter qu'il faut attendre que l'auteur ait mis a jour son programme et etre au courant qu'une version corigée existe.

Peut importe : le mot inutilement vaut quand même dans les deux cas. Non. "Inutile" implique que le code est inutilisé, ce qui n'est pas le cas avec les librairies statiques.

Tu joues sur les mots là, tu comprends très bien ce qu'on veut dire: le code y est plusieurs fois alors qu'on pourrait ne l'y mettre qu'une fois.

Comme déjà dit plus haut, mais apparemment ignoré par toi: Plus une librairie est utilisée, moins il y a de risque que ce genre d'erreurs passe inobservé. Donc il est peu probable qu'une mise à jour d'une librairie soit suffisamment importante pour qu'on doive mettre à jour 7 programmes à la fois.

Certes mais ca peut arriver et puis un changement mineur de ROM ou de HW peut remener a devoir faire une MAJ de la lib aussi. Si par exemple il faut faire un changement a une section très utilisée de TIGCCLIB c'est sans doute énormément de progs à recompiler.

Ça arrive, mais rarement. Il est bien plus probable de devoir mettre à jour 7 librairies dynamiques séparément alors que dans le cas d'une librairie statique, il aurait suffi d'attendre la mise à jour du programme principal un mois plus tard pour avoir les 8 mises à jour à la fois.

Avec stdlib, il suffit d'en mettre à jour une seule. Et meme si on veut utiliser des lib séparées elles sont souvent dispo par packs donc facile a récupérer.

1. il suffit d'utiliser kpack.exe sur les programmes produits par TIGCC pour en faire des packs archive.
2. TIGCC permet déjà la compression ExePack qui:
2.1. compresse mieux et 2.2. est plus portable (compatible avec les anciens kernels et avec l'absence de kernel).

1.Certes mais ca cerait plus pratique
2.1 Oui mais oblige une appli externe a chaque lancement
2.2 Intéret de décompresser un prog kernel si on n'a pas de kernel

Uther>
Certes mais ca peut arriver et puis un changement mineur de ROM ou de HW peut remener a devoir faire une MAJ de la lib aussi. Si par exemple il faut faire un changement a une section très utilisée de TIGCCLIB c'est sans doute énormément de progs à recompiler.

Tout a fait d'accord, mais un seul pbm.. (malheureusement en faveur de KK... :/) si le prog qui utilise la lib utilise aussi TIGCCLIB... (la lib n'inclu pas tt les hacks de tigcc nan ?) il va falloir recompiler.. Mais je précise, PAS A CAUSE DE LA LIB ! mais a cause de TIGCC/TIGCCLIB !

Faut donc mettre TIGCC en lib dynamique

LOL Kevin t'en a pas marre de raconter des conneries ?

"monopole de PreOs", on aura tout entendu ...

le monopole du _nostub ça te dérange pas par contre ?