30

C'est que je n'aime pas les programmeurs qui rabattent une partie de leur travail sur les utilisateurs. C'est au programmeur de mettre à jour une librairie, pas à l'utilisateur!
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

31

>"Ça sent la publicité!"
NNNNNNOOOOOOOOONNNNNNNNNN JE REEEVEEE !!!!!!!!!!!!!

TU AS LE CULOT DE DIRE UN TRUC COMME CA??????????????????????
non mais t'as regardé tes posts??????

on dirait un gamin qui défend son jouet! (©PpHd grin)
In many respects the Yoshi is like a beautiful woman. A man can come so enamoured that he bestows on her all his time, his energy and his fortune.
- Fred whipple, 1960

*** Ne sous-estimez pas la puissance de la Marmotte ***
© Marmotte Team : LaMarmotte, sBibi, Vark & Sabrina

32

"C'est que je n'aime pas les programmeurs qui rabattent une partie de leur travail sur les utilisateurs. C'est au programmeur de mettre à jour une librairie, pas à l'utilisateur!"

ooooh! merde alors grin et c'est con tu vois, mais si les utilisateurs veulent avoir des programmes a jour, ils devront les mettre a jour quand même grin
oublie ton argument, comme tous les autres de tes derniers posts, il est bidon, ça revient EXACTEMENT au même
In many respects the Yoshi is like a beautiful woman. A man can come so enamoured that he bestows on her all his time, his energy and his fortune.
- Fred whipple, 1960

*** Ne sous-estimez pas la puissance de la Marmotte ***
© Marmotte Team : LaMarmotte, sBibi, Vark & Sabrina

33

j'en reviens pas que tu sois si borné et fermé d'esprit...
In many respects the Yoshi is like a beautiful woman. A man can come so enamoured that he bestows on her all his time, his energy and his fortune.
- Fred whipple, 1960

*** Ne sous-estimez pas la puissance de la Marmotte ***
© Marmotte Team : LaMarmotte, sBibi, Vark & Sabrina

34

ben moi je vois un gros avantage au nostub:
un mec qui viens d'acheter une ti89 il telecharge TIGCC et il peut faire ce qu'il veus !
il n'a pas besoin d'uploader sur ca calc un kernel => il peut rentrer dans le vif du sujet plus vite !! wink
IP IP OURA ! ;)

35

Comme d'habitude je suis du côté de Kevin...
PpHd: le post n°10 est désagréable à lire. Il manque de présentation (regarde le post n°1 de Kevin pour voir ce que je veux dire).
Nitro: "J'ai fait le loader nostub pour genlib parce que ceux qui ne veulent pas de kernel ne pouvaient pas s'en servir.": Certes, mais genlib ne marche toujours pas sur VTI, ce qui est un défaut grave pour une librairie qui se voudrait largement utilisée: VTI est un meilleur outil de debug que la calculette normale.

Les arguments de sbibi, PpHd manquent souvent d'objectivité (notamment post 23, dans lequel Kevin répond). PpHd, tu devrais lire la documentation de TIGCC, et documenter des fonctions inconnues (il n'en reste plus autant qu'avant, dépêche-toi).
sbibi:" j'en reviens pas que tu sois si borné et fermé d'esprit...": ne l'es-tu pas toi aussi ? Si on veut dire que des arguments ne tiennent pas (et je ne suis pas persuadé que ce soit le cas des arguments de Kevin), il faut faire des critiques qui tiennent debout...

Les librairies des kernels ont plein de fonctions très vieilles et inutiles (Kevin les a citées), gardées par 5 ans de compatibilité (que le nostub ne traîne pas comme un boulet, lui, forcément).

Bien évidemment je suis aussi d'accord avec le post n°33 de IP.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

36

exact : c'est au programmeur de la libréairie de mettre à jour sa librairie, pas à l'utilisateur de la librairie. (aka le programmeur qui utilises la lib statique)
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

37

sBibi a écrit :
"C'est que je n'aime pas les programmeurs qui rabattent une partie de leur travail sur les utilisateurs. C'est au programmeur de mettre à jour une librairie, pas à l'utilisateur!"

ooooh! merde alors grin et c'est con tu vois, mais si les utilisateurs veulent avoir des programmes a jour, ils devront les mettre a jour quand même grin oublie ton argument, comme tous les autres de tes derniers posts, il est bidon, ça revient EXACTEMENT au même

Non: si c'est le programmeur qui met à jour la librairie, l'utilisateur aura à mettre à jour un seul fichier. Si c'est à l'utilisateur de le faire, il aura à mettre à jour 2 fichiers: le programme (qui lui aussi évolue au cours du temps normalement) et la librairie.
En plus quand l'utilisateur voudra vérifier s'il a la version la plus récente, si c'est le programmeur qui met à jour la librairie, l'utilisateur ne devra aller vérifier que sur un site, s'il doit le faire lui-même, il devra aller vérifier sur deux sites (sauf dans le cas particulier où le programme et la librairie sont de la même équipe, mais ce n'est pas le cas général).
Et si le programme utilise plusieurs librairies, remplace "deux" par le nombre de librairies + 1. Ça devient encore plus lourd!
squale92
a écrit : exact : c'est au programmeur de la libréairie de mettre à jour sa librairie, pas à l'utilisateur de la librairie. (aka le programmeur qui utilises la lib statique)

Arf, tu détournes mes propos là!

Je précise donc ce que je voulais dire. C'est:
- au programmeur de la librairie de la mettre à jour.
- au programmeur du programme utilisant la librairie de mettre à jour la librairie dans son programme.
- à l'utilisateur du programme ("end user") de mettre à jour le programme.
L'utilisateur du programme n'a pas à aller chercher des mises à jour directement chez le programmeur de la librairie. En fait, il n'est même pas censé savoir qu'un programme utilise une telle ou telle librairie sauf s'il lit les remerciements dans la documentation par pure curiosité. Un modèle où l'utilisateur doit savoir quel programme utilise quelle librairie (et en plus s'occuper de mettre à jour régulièrement ces librairies) n'est pas du tout un modèle acceptable du point de vue facilité d'utilisation.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

38

Kevin> oui, j'ai détourné tes propos... je n'ai pas pu résister à la tentation
(même si j'avais saisi ce que tu voulais dire)


Kevin> Admettons que, demain, je sorte KII en version finale, pas de bug ni quoi que ce soit qui puisse m'obliger à sortir un jour une nouvelle version, et que, ensuite, après-demain, je quitte définitivement la communauté.
Dans quelques mois, on se rend compte que les routines de décompression d'Extgraph que j'utilises comportent un bug...
Si je ne suis plus là, et vu que je n'aurai pas releasé les sources, KII ne seréa jamais corrigé.
Alors que si les routines de décompression étaient en librairie dynamique, il suffirait de changer la librairie...
Donc, dans ce cas, en lib statique, ça fait un programme buggué... alors qu'avec une librairie dynamique, il ne le resterai pas !

Ne me dit pas que ce cas n'arrive jamais : combien de programmeurs ont quitté la communauté dpeuis sa naissance ?
certes, ce pb ne s'est pas encore bcp vu, car les codeurs nostub ne sont pas là depuis très très longtemps, et que peu d'entre eux sont partis... mais dans quelques années, qd certains seront parti, le problème que j'évcoque commencera à apparaitree !!!
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

39

XDanger
a écrit : Nitro: "J'ai fait le loader nostub pour genlib parce que ceux qui ne veulent pas de kernel ne pouvaient pas s'en servir.": Certes, mais genlib ne marche toujours pas sur VTI, ce qui est un défaut grave pour une librairie qui se voudrait largement utilisée: VTI est un meilleur outil de debug que la calculette normale.

Ce n'est pas de ma faute si VTI n'est pas parfait... Genlib marche parfaitement bien sous VTI chez moi, suffit d'avoir un dump de la ROM et non pas un TIB (qui ne contient pas le systeme complet de la calculatrice roll)... De toute façon à l'heure qu'il est, ce probleme est deja corrigé.
So much code to write, so little time.

40

mdr, des arguments qui tiennent debout... ça c'est de votre point de vue aussi...
vous voyez je viens de me rendre compte comme c'est marrant comme tout est relatif... personne ne peut avoir un regard objectif... les pro _nostub ne veulent même pas se dire que leurs arguments peuvent ne pas tenir debout (quand je lis les posts de kevin, ça me fait travailler les abdos tellement je me marre grin) et les pro-kernels (dont moi) ne veulent pas admettre non plus que certains de leurs arguments sont nuls (kevin ou XDanger va me faire remarquer que je n'ai pas employé la même formule que pour les arguments du _nostub, etc, etc... eh oui, je n'ai pas un regard objectif, mais vous non plus)

franchement, le Kernel soulage les 2 côtés: le programmeur ET l'utilisateur. d'abord le programmeur: il n'a pas besoin de toucher son prog si une lib est mise a jour, ensuite l'utilisateur n'a qu'à envoyer la lib, pas le programme entier...
je me vois mal réinstaller CF sur ma calc juste pke une version plus récente de Genlib est sortie... (oui, je sais la aussi je ne suis pas objectif, je cite un prog kernel de PpHd qui ne marche que sur PreOs, mais c'est pareil pour vous ac la tict...)

en ce qui concerne le fait de devoir aller sur plusieurs sites pour récupérer les libs/progs, puisque vous dites si bien que le programmeur doit épargner du travail a l'utilisateur, dans chacune des releases de ses progs, il devrait inclure la version la plus récente des libs nécessaires (sous l'accord de l'auteur des libs), ou tout simplement mettre un lien... ne seraist-ce qu'un lien vers le kernel requis.

si on en vient a même avoir la flemme de taper "preos()" (ouii, je sais, pub gratuite, mais c'est une pub pour le kernel, de même que kevin fait de la pub pour le _nostub), on aura bientôt la flemme d'appuyer sur les touches de la calc... (ce qui est partiellement le cas de Kevin apparemment...)

ce qui me fait bien marrer aussi, c'est qu'apparemment kevin se prend pas pour de la merde, notemment en insinuant que toutes les personnes qui ont conçu tous les systèmes d'exploitations actuels sont des cons de ne pas avoir tout programmé en _nostub (kevin: je n'ai pas oublié le underscore)... regrouper les routines récurrentes est une des bases de l'optimisation en taille, je ne vois pas qui pourrait me contredire la dessus, surtout toi kevin... on trouve ça au niveau du code (bsr), au niveau des logiciels (libs), même dans la société... Kevin a été un des premiers a dire dans je ne sais plus que Topic que selon lui l'éducation était un peu trop généraliste...
vous voyez un patron qui soit a la fois cuisinier, secrétaire, comptable, balayeur de chiottes, etc... non? ben moi je vois un peu le _nostub comme ça...
pour avoir la même efficacité, il faudrait plus de personnes comme ça qu'il n'en faut si elles sont spécialisées dans un domaine... un patron, une secrétaire, un cuisinier, un balayeur... c'est pareil avec les routines, avoir par exemple 4 ou 5 routines de sprite16 ne sert a rien, sinon a alourdir le prog, a entrainer des bugs, etc etc... pour les libs et les progs, c'est la même chose, en _nostub on a des tas de progs avec exactement les mêmes routines dans le ventre... avec le Kernel (uniquement dans l'idéal malheureusement) on a une seule routine par fonction... (que ça soit clair, je ne parle PAS des rom calls, mais de la diff libs statiques/dynamiques!)

ça peut vous paraitre stupide comme point de vue, mais c'est une façon comme une autre d'imager les choses... des progs _nostub peuvent avoir des libs statiques de différentes versions, certaines seront peut etre encore buggées, d'autres non, certaines seront rapides, d'autres encore pas très optimisées... avec les libs dynamiques, si la lib est buggée, on la change, un point c 'est tout.

mais bon, puisque le _nostub supporte aussi les libs dynamiques, pas de probleme...triso

XDanger>"sbibi:" j'en reviens pas que tu sois si borné et fermé d'esprit...": ne l'es-tu pas toi aussi ? Si on veut dire que des arguments ne tiennent pas (et je ne suis pas persuadé que ce soit le cas des arguments de Kevin), il faut faire des critiques qui tiennent debout..."
je le suis déjà moins que Kevin, puisqu lui n'est apparemment pas capable de concevoir qu'il peut avoir tort...
des critiques qui tiennent pas debout? arf désolé, j'ai subi l'influence du syndrome de Kofler...

IP>"un mec qui viens d'acheter une ti89 il telecharge TIGCC et il peut faire ce qu'il veus !
il n'a pas besoin d'uploader sur ca calc un kernel => il peut rentrer dans le vif du sujet plus vite !! "

un mec vient de s'acheter une 89 -> tres bien, malheureusement dans 90% des cas, le temps qu'il apprenne a s'en servir...
il telecharge TIGCC -> ça pourrait vouloir dire qu'il sait programmer en C ou qu'il veut apprendre... dans le même ton on pourrait aussi avoir:
il telecharge A68k -> ça pourrait vouloir dire qu'il sait programmer en ASM ou qu'il veut apprendre...

>il n'a pas besoin d'uploader (note de moi: on dit downloader grin) sur ca calc un kernel => il peut rentrer dans le vif du sujet plus vite !!
bof la aussi on pourrait avoir:
le temps que TIGCC finisse de se dl, A68k et le kernel seront dl depuis longtemps..., en même temps il aura makeprgm inclus dans PreOs, trois pour le prix de deux...
le temps que TIGCC s'installe, ça fait belle lurette qu'il a killé le graphlink, que le kernel se prélasse dans sa calc, et qu'il a tapé "preos()"+[ENTER] grin

et ce que je n'ai pas pu supporter, c'est quand kevin a dit "ça sent la publicité"
j'ai même pas la force d'aller chercher tous ses posts de la page d'avant pour les commenter...
dailleurs g une lib opengl récalcitrante qui m'attend (tiens, en passant, merci NSPIRIT smile)
In many respects the Yoshi is like a beautiful woman. A man can come so enamoured that he bestows on her all his time, his energy and his fortune.
- Fred whipple, 1960

*** Ne sous-estimez pas la puissance de la Marmotte ***
© Marmotte Team : LaMarmotte, sBibi, Vark & Sabrina

41

c en machant le travail des nioubi (simplicite !!! gol du _nostub) que apres ils comprennent plus rien alors que si ils font l'effort de comprendre des le debut c mieuxsmile
En préretraitre

42

XDanger : "Les librairies des kernels ont plein de fonctions très vieilles et inutiles (Kevin les a citées), gardées par 5 ans de compatibilité (que le nostub ne traîne pas comme un boulet, lui, forcément)"

Ha ! Kevin et toi vous me faites rire.
Votre refus d'ajouter les ROM_CALLs des derniers AMS dans la bibliothèque de TIGCC afin de garder la compatibilité 1.0x, c'est pas "un boulet" ?

Comique va ! grin
avatar
Un site complet sur lequel vous trouverez des programmes et des jeux pour votre calculatrice TI 89 / Titanium / 92+ / Voyage 200 : www.ti-fr.com.
Quelques idées personnelles ici.

43

Thibaut> ils vont te répondre par le truc du define AMS_MIn_machinechose, qui me gave un peu en fait... obligé à chauqe fois de le supprimer sad
avatar
Tutorial C (TI-89/92+/v200) - Articles Développement Web (PHP, Javascript, ...)
« What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? » - Larry Wall

44

Ouais, là, je suis plutôt d'accord Thibaut.

45

squale92 a écrit :
Kevin> oui, j'ai détourné tes propos... je n'ai pas pu résister à la tentation
(même si j'avais saisi ce que tu voulais dire)


Kevin> Admettons que, demain, je sorte KII en version finale, pas de bug ni quoi que ce soit qui puisse m'obliger à sortir un jour une nouvelle version, et que, ensuite, après-demain, je quitte définitivement la communauté.
Dans quelques mois, on se rend compte que les routines de décompression d'Extgraph que j'utilises comportent un bug...
Si je ne suis plus là, et vu que je n'aurai pas releasé les sources, KII ne seréa jamais corrigé.
Alors que si les routines de décompression étaient en librairie dynamique, il suffirait de changer la librairie...
Donc, dans ce cas, en lib statique, ça fait un programme buggué... alors qu'avec une librairie dynamique, il ne le resterai pas !

Ne me dit pas que ce cas n'arrive jamais : combien de programmeurs ont quitté la communauté dpeuis sa naissance ? certes, ce pb ne s'est pas encore bcp vu, car les codeurs nostub ne sont pas là depuis très très longtemps, et que peu d'entre eux sont partis... mais dans quelques années, qd certains seront parti, le problème que j'évcoque commencera à apparaitree !!!

Solution simple: tu publies soit les sources, soit, si tu veux garder tes sources secrètes, les fichiers objet nécessaires pour linker avec une version corrigée de ExtGraph si nécessaire.
sBibi
a écrit : franchement, le Kernel soulage les 2 côtés: le programmeur ET l'utilisateur. d'abord le programmeur: il n'a pas besoin de toucher son prog si une lib est mise a jour, ensuite l'utilisateur n'a qu'à envoyer la lib, pas le programme entier...

Déjà, qu'on envoie une nouvelle version de la librairie ou une nouvelle version du programme statiquement linkée, on n'envoie qu'un seul fichier dans les 2 cas, donc ça ne change rien.
Et si le programmeur met à jour le programme et qu'il faut une nouvelle version de la librairie, soit parce que la nouvelle version du programme la veut, soit parce qu'on veut mettre à jour la librairie également? Ça fait 2 fichiers à mettre à jour avec une librairie dynamique, et un seul avec une librairie statique.
je me vois mal réinstaller CF sur ma calc juste pke une version plus récente de Genlib est sortie...

Dans ce cas, le problème est que PpHd a tout mis dans un installeur qui ne permet pas de choisir les composants à installer. Donc si on ne veut mettre à jour que le programme principal, on doit se taper toute l'installation. C'est un problème de l'installeur de CF (tinstall), pas du principe des librairies statiques.
en ce qui concerne le fait de devoir aller sur plusieurs sites pour récupérer les libs/progs, puisque vous dites si bien que le programmeur doit épargner du travail a l'utilisateur, dans chacune des releases de ses progs, il devrait inclure la version la plus récente des libs nécessaires (sous l'accord de l'auteur des libs),

Et où est la différence avec les librairies statiques? Avec ce que tu proposes, le programmeur doit quand-même mettre à jour son programme à chaque fois qu'une nouvelle version de la librairie sort.
ou tout simplement mettre un lien... ne seraist-ce qu'un lien vers le kernel requis.

Mais l'utilisateur doit quand-même suivre le lien, aller chercher le fichier dont il a besoin, le télécharger et le décompresser séparément. C'est lourd.
ce qui me fait bien marrer aussi, c'est qu'apparemment kevin se prend pas pour de la merde, notemment en insinuant que toutes les personnes qui ont conçu tous les systèmes d'exploitations actuels sont des cons de ne pas avoir tout programmé en _nostub (kevin: je n'ai pas oublié le underscore)... regrouper les routines récurrentes est une des bases de l'optimisation en taille, je ne vois pas qui pourrait me contredire la dessus, surtout toi kevin...

Non, pas du tout! Si pour avoir un seul programme, il faut installer 30 dépendances, on perd 3000% de place!!!
on trouve ça au niveau du code (bsr), au niveau des logiciels (libs), même dans la société... Kevin a été un des premiers a dire dans je ne sais plus que Topic que selon lui l'éducation était un peu trop généraliste... vous voyez un patron qui soit a la fois cuisinier, secrétaire, comptable, balayeur de chiottes, etc... non? ben moi je vois un peu le _nostub comme ça...

Elle est assez tirée par les cheveux, cette comparaison! Je ne trouve pas qu'elle s'applique ici.
pour avoir la même efficacité, il faudrait plus de personnes comme ça qu'il n'en faut si elles sont spécialisées dans un domaine... un patron, une secrétaire, un cuisinier, un balayeur... c'est pareil avec les routines, avoir par exemple 4 ou 5 routines de sprite16 ne sert a rien, sinon a alourdir le prog, a entrainer des bugs, etc etc... pour les libs et les progs, c'est la même chose, en _nostub on a des tas de progs avec exactement les mêmes routines dans le ventre... avec le Kernel (uniquement dans l'idéal malheureusement) on a une seule routine par fonction... (que ça soit clair, je ne parle PAS des rom calls, mais de la diff libs statiques/dynamiques!)

Justement, on en est très loin de ce cas "idéal" avec les librairies dynamiques. Malgré cette considération purement théorique, en pratique, les librairies statiques épargnent souvent de la place pour des raisons que j'ai déjà citées dans ma longue réponse à PpHd.
ça peut vous paraitre stupide comme point de vue, mais c'est une façon comme une autre d'imager les choses... des progs _nostub peuvent avoir des libs statiques de différentes versions, certaines seront peut etre encore buggées, d'autres non, certaines seront rapides, d'autres encore pas très optimisées... avec les libs dynamiques, si la lib est buggée, on la change, un point c 'est tout.

Si tous les programmes utilisaient les même routines, un bogue dans une de ces routines se retrouverait dans tous les programmes. Regarde ce qui s'est passé avec l'exploit zlib sous Linux récemment: de nombreux programmes linkaient avec cette librairie (soit statiquement, soit dynamiquement), et un grand nombre d'entre eux étaient à risque à cause de l'exploit. Le problème a vite été résolu en corrigeant zlib (et pour les programmes statiquement linkés, il a suffi de les recompiler, ça n'a pas été plus lourd que pour ceux linkés dynamiquement), mais tant que ça n'a pas été fait (il faut du temps pour corriger un bogue dans une librairie), il y avait beaucoup de programmes à risque d'exploit. Donc avoir le choix entre des routines différentes est une très bonne idée, même si ça pourrait te paraître du gaspillage.
XDanger>"sbibi:" j'en reviens pas que tu sois si borné et fermé d'esprit...": ne l'es-tu pas toi aussi ? Si on veut dire que des arguments ne tiennent pas (et je ne suis pas persuadé que ce soit le cas des arguments de Kevin), il faut faire des critiques qui tiennent debout..." je le suis déjà moins que Kevin, puisqu lui n'est apparemment pas capable de concevoir qu'il peut avoir tort...

Évidemment que je peux avoir tort. Mais prouve-le moi. Pour l'instant, à chacune de tes critiques de mon raisonnement, j'ai pu te répondre pour le défendre.
des critiques qui tiennent pas debout? arf désolé, j'ai subi l'influence du syndrome de Kofler...

Comme tu n'as plus d'arguments, tu passes aux attaques personnelles... roll
un mec vient de s'acheter une 89 -> tres bien, malheureusement dans 90% des cas, le temps qu'il apprenne a s'en servir...
il telecharge TIGCC -> ça pourrait vouloir dire qu'il sait programmer en C ou qu'il veut apprendre... dans le même ton on pourrait aussi avoir: il telecharge A68k -> ça pourrait vouloir dire qu'il sait programmer en ASM ou qu'il veut apprendre...

Je te signale que la version officielle de A68k est celle de TIGCC. Toutes les autres sont des distributions non-officielles. Raison: c'est moi le mainteneur.
>il n'a pas besoin d'uploader (note de moi: on dit downloader grin) sur ca calc un kernel => il peut rentrer dans le vif du sujet plus vite !!
bof la aussi on pourrait avoir:
le temps que TIGCC finisse de se dl, A68k et le kernel seront dl depuis longtemps..., en même temps il aura makeprgm inclus dans PreOs, trois pour le prix de deux...
le temps que TIGCC s'installe, ça fait belle lurette qu'il a killé le graphlink, que le kernel se prélasse dans sa calc, et qu'il a tapé "preos()"+[ENTER] grin

C'est normal qu'un environnement moderne (vous aimez cette expression, donc je l'utilise grin) qui offre aussi le C en plus de l'assembleur prenne plus de place qu'un environnement préhistorique à base d'un fichier BAT et pour l'assembleur seulement.
Et même pour l'assembleur, TIGCC offre une fonctionnalité importante que les tools de développement de PreOs n'offrent pas: la possibilité de linker plusieurs fichiers objet compilés séparément! On en a marre des include "toto.asm"! On inclut des headers, pas des sources!
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

46

gugusg a écrit :
c en machant le travail des nioubi (simplicite !!! gol du _nostub) que apres ils comprennent plus rien alors que si ils font l'effort de comprendre des le debut c mieuxsmile

Bravo, tu as compris tout le principe de la facilité d'utilisation. grin roll
Dans le cas où tu n'aurais pas compris tout de suite, la phrase ci-dessus était ironique!
Thibaut a écrit :
XDanger : "Les librairies des kernels ont plein de fonctions très vieilles et inutiles (Kevin les a citées), gardées par 5 ans de compatibilité (que le nostub ne traîne pas comme un boulet, lui, forcément)"

Ha ! Kevin et toi vous me faites rire.
Votre refus d'ajouter les ROM_CALLs des derniers AMS dans la bibliothèque de TIGCC afin de garder la compatibilité 1.0x, c'est pas "un boulet" ?

Comique va ! grin

Tu en es resté à quelle version de TIGCC? C'est depuis un certain temps déjà que tu peux définir:
#define MIN_AMS 205
et tu pourras utiliser tous les ROM_CALLs documentés soit par nous, soit par TI. (Ceux documentés par TI, mais pas par nous, ont été rajoutés à unknown.h.) Et nous sommes en train d'en documenter de plus en plus (notamment, XDanger - Lionel Debroux de son vrai nom - a contribué des documentations pour un certain nombre de fonctions spécifiques à AMS 2 - merci beaucoup d'ailleurs).
squale92 a écrit :
Thibaut> ils vont te répondre par le truc du define AMS_MIn_machinechose, qui me gave un peu en fait... obligé à chauqe fois de le supprimer sad

Tu le décoches dans l'IDE... roll
Sinon, si tu veux que le programme marche sous tous AMS (même TI-92+ AMS 1.00), mets:
#define MIN_AMS 100
(Il faut mettre ça explicitement parce qu'il y a beaucoup de ROM_CALLs souvent utilisés - comme OSdequeue - qui ne sont pas disponible sur TI-92+ AMS 1.00. Le support officiel pour cette version de AMS n'a été rajouté à TIGCC qu'avec l'introduction de la directive MIN_AMS.)
ExtendeD
a écrit : Ouais, là, je suis plutôt d'accord Thibaut.

Je répète: MIN_AMS, c'est pour les chiens?
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

47

Déjà qu'on envoie une nouvelle version de la librairie ou une nouvelle version du programme statiquement linkée, on n'envoi qu'un seul fichier dans les 2 cas, donc ça ne change rien. Et si le programmeur met à jour le programme et qu'il faut une nouvelle version de la librairie, soit parce que la nouvelle version du programme la veut, soit parce qu'on veut mettre à jour la librairie également? Ça fait 2 fichiers à mettre à jour avec une librairie dynamique, et un seul avec une librairie statique.


c'est comme un kernel a installer, ça fatigue trop d'envoyer un truc de plus sur la calc, alors qu'il y a plein d'autres avantages...
Dans ce cas, le problème est que PpHd a tout mis dans un installeur qui ne permet pas de choisir les composants à utiliser. Donc si on ne veut mettre à jour que le programme principal, on doit se taper toute l'installation. C'est un problème de l'installeur de CF (tinstall), pas du principe des librairies statiques.


bah, même en envoyant que le programme principal (de toute manière si genlib y était inclus, ça dépasserait les 64K) il est plus lourd que genlib... rhalala ça va mettre 20 secondes de plus pour envoyer le prog... (raisonnement ©CENSURE POUR NE PAS FAIRE D ATTAQUES PERSONNELLES grin)
Et où est la différence avec les librairies statiques? Avec ce que tu proposes, le programmeur doit quand-même mettre à jour son programme à chaque fois qu'une nouvelle version de la librairie sort.


de ce point de vue, aucun... ce qui veut dire que ton argument comme quoi les libs statiques étaient mieux pke elle évitaien d'aller chercher deux fichiers sur un site, ne tient pas...
Mais l'utilisateur doit quand-même suivre le lien, aller chercher le fichier dont il a besoin, le télécharger et le décompresser séparément. C'est lourd.

mon dieu t'as raison, que c'est fatiguant, bien plus que quand tu reset a cause d'un crash not intercepted et que tu dois reinstaller tt ce qui était en ram... (bon, je sais tu vas dire que les progs _nostub ne plantent pas... roll)
Non, pas du tout! Si pour avoir un seul programme, il faut installer 30 dépendances, on perd 3000% de place!!!

et si t'as 30 programmes?
Justement, on en est très loin de ce cas "idéal" avec les librairies dynamiques. Malgré cette considération purement théorique, en pratique, les librairies statiques épargnent souvent de la place pour des raisons que j'ai déjà citées dans ma longue réponse à PpHd.

et qu'il t'a répondu en disant que dans le cas de libs comme genlib ou 90% du code était indiscossiable, ça n'apportait RIEN, et qu'au contraire ça faisait perdre de la place...
Si tous les programmes utilisaient les même routines, un bogue dans une de ces routines se retrouverait dans tous les programmes. Regarde ce qui s'est passé avec l'exploit zlib sous Linux récemment: de nombreux programmes linkaient avec cette librairie (soit statiquement, soit dynamiquement), et un grand nombre d'entre eux étaient à risque à cause de l'exploit. Le problème a vite été résolu en corrigeant zlib (et pour les programmes statiquement linkés, il a suffi de les recompiler, ça n'a pas été plus lourd que pour ceux linkés dynamiquement), mais tant que ça n'a pas été fait (il faut du temps pour corriger un bogue dans une librairie), il y avait beaucoup de programmes à risque d'exploit. Donc avoir le choix entre des routines différentes est une très bonne idée, même si ça pourrait te paraître du gaspillage.


très bon exemple, je connaissais pas smile mais bon, en ce qui concerne les Ti, compiler comme pour les PC, ça ne sert pas vraiment a grand chose... je mets 5 sec a compiler un prog de 20K sur un portable archi merdique, c'est quasi instantané sur mon pIII 500, quand on voit les procs a 1.7 GHZ ou plus, ne recompiler qu'un bout du code n'a plus vraiment bcp d'intérêt (tjrs pour les ti!)... mais bon la je ne connais pas trop le vocab linux/unix, mais apparemment ça ne s'applique pas aux progs sur ti, mais aux compilos, dc le pbl n'est pas la, au contraire ça favoriserait plutot les progs utilisant des libs dynamiques, puisqu'il ne faudrait corriger que la lib (enfin bon g ptet mal compris grin)
Évidemment que je peux avoir tort. Mais prouve-le moi. Pour l'instant, à chacune de tes critiques de mon raisonnement, j'ai pu te répondre pour le défendre.

j'ai pu te répondre aussi, tes réponsent ne me conviennent pas, le miennes ne te conviennent pas non plus... me demande jusqu'ou ça va durer grin
Comme tu n'as plus d'arguments, tu passes aux attaques personnelles...

heu, désolé si tu as vu ça comme une "attaque" personnelle, mais pour moi c'est tes arguments qui ne tiennent pas debout smile et de quels arguments j'aurai eu besoin pour répondre à ça? grin on me dit un truc gratuit, je répond par un autre truc gratuit smile la encore c'est votre pt de vue smile
Je te signale que la version officielle de A68k est celle de TIGCC. Toutes les autres sont des distributions non-officielles. Raison: c'est moi le mainteneur.

je sais smile ça serait marrant que tu fasse un chck dans a68k pour savoir si tigcc est installé grin si il est pa installé, a68k lance ie a la page de le tict gringringrin
C'est normal qu'un environnement moderne (vous aimez cette expression, donc je l'utilise ) qui offre aussi le C en plus de l'assembleur prenne plus de place qu'un environnement préhistorique à base d'un fichier BAT et pour l'assembleur seulement.

l'"environnement préhistorique" marche très bien smile tigcc peut etre aussi, mais pour un crétin et un énorme paresseux comme moi, c'est plus simple, plus court, ConText compile pour moi (pas la peine de me dire que tigc aussi, chuis au courant lol), j'ai un compilo et un linker, je sais ce qu'ils font, j'ai pas le dossier de mon proj encombré avec des fichiers générés par une IDE que je sais même pas ce qu'ils viennent foutre la...
Bravo, tu as compris tout le principe de la facilité d'utilisation. Dans le cas où tu n'aurais pas compris tout de suite, la phrase ci-dessus était ironique!

la facilité d'utilisation? franchement si quand j'ai commencé l'asm j'avais eu un compilo qui gueule quand je mettais add.l a0,a1 au lieu de adda.l a0,a1 ou and.b #$fe,d0 au lieu de andi.b #fe,d0 (entre autres) ou encore muls.l au lieu de muls.w, etc, etc, ça m'aurait vachement plus appris qu'un compilo gentil tout plein qui dit rien et se contente de modifier mes instructions sans que je lui demande... la facilité d'utilisation ne rime PAS FORCEMENT avec qualite d'apprentissage...
In many respects the Yoshi is like a beautiful woman. A man can come so enamoured that he bestows on her all his time, his energy and his fortune.
- Fred whipple, 1960

*** Ne sous-estimez pas la puissance de la Marmotte ***
© Marmotte Team : LaMarmotte, sBibi, Vark & Sabrina

48

Kevin Kofler a écrit :
Si tous les programmes utilisaient les même routines, un bogue dans une de ces routines se retrouverait dans tous les programmes. Regarde ce qui s'est passé avec l'exploit zlib sous Linux récemment: de nombreux programmes linkaient avec cette librairie (soit statiquement, soit dynamiquement), et un grand nombre d'entre eux étaient à risque à cause de l'exploit. Le problème a vite été résolu en corrigeant zlib (et pour les programmes statiquement linkés, il a suffi de les recompiler, ça n'a pas été plus lourd que pour ceux linkés dynamiquement), mais tant que ça n'a pas été fait (il faut du temps pour corriger un bogue dans une librairie), il y avait beaucoup de programmes à risque d'exploit. Donc avoir le choix entre des routines différentes est une très bonne idée, même si ça pourrait te paraître du gaspillage.


L'exemple est parfait... sur mon serveur FreeBSD j'ai plus d'une 20aine de programmes qui utilisent zlib.
Pour ceux qui linkent dynamiquement, aucun probleme, je download et j'installe le patch pour libz.so.. 2 commandes à taper, et c'est fini.
Pour ceux qui linkent statiquement, deja bonne chance pour les trouver... et comme le dit le site lui meme:
Various ports may statically link zlib or contain their own versions
of zlib that have not been corrected by updating the FreeBSD libz.
Efforts are underway to identify and correct these ports.

Qu'est-ce que ça veut dire ? eh ben je te laisse faire la déduction...

alors ton "et pour les programmes statiquement linkés, il a suffi de les recompiler, ça n'a pas été plus lourd que pour ceux linkés dynamiquement" j'en ris encore... grin
So much code to write, so little time.

49

sBibi a écrit :
mon dieu t'as raison, que c'est fatiguant, bien plus que quand tu reset a cause d'un crash not intercepted et que tu dois reinstaller tt ce qui était en ram... (bon, je sais tu vas dire que les progs _nostub ne plantent pas... roll)

Ce que je dis, c'est qu'il ne faut pas avoir ses fichiers en RAM. La mémoire archive est là pour une raison. Et personne ne t'empêche d'utiliser un anti-crash pour programmes _nostub. Il y en a un intégré dans PreOs, et il y a aussi KerNO.
et si t'as 30 programmes?

30 programmes utilisant les mêmes librairies?
et qu'il t'a répondu en disant que dans le cas de libs comme genlib ou 90% du code était indiscossiable, ça n'apportait RIEN, et qu'au contraire ça faisait perdre de la place...

Et je lui ai répondu qu'il n'est pas difficile de changer genlib pour qu'il n'y ait plus 90% du code indissociable.
très bon exemple, je connaissais pas smile mais bon, en ce qui concerne les Ti, compiler comme pour les PC, ça ne sert pas vraiment a grand chose... je mets 5 sec a compiler un prog de 20K sur un portable archi merdique, c'est quasi instantané sur mon pIII 500, quand on voit les procs a 1.7 GHZ ou plus, ne recompiler qu'un bout du code n'a plus vraiment bcp d'intérêt (tjrs pour les ti!)... mais bon la je ne connais pas trop le vocab linux/unix, mais apparemment ça ne s'applique pas aux progs sur ti, mais aux compilos, dc le pbl n'est pas la, au contraire ça favoriserait plutot les progs utilisant des libs dynamiques, puisqu'il ne faudrait corriger que la lib (enfin bon g ptet mal compris grin)

En effet, tu as mal compris. grin Je ne parlais pas du temps de compilation, mais du temps pris pour modifier la source elle-même, quand je disais "il faut du temps pour corriger un bogue dans une librairie".
je sais smile ça serait marrant que tu fasse un chck dans a68k pour savoir si tigcc est installé grin si il est pa installé, a68k lance ie a la page de le tict gringringrin

Tu me donne de bonnes idées. grin Sauf qu'on le mettrait à notre page, pas à celle de la TICT. grin
Non franchement, je n'ai aucune intention d'empêcher les distributions non officielles, mais je précise juste qu'elles ne sont pas officielles!
l'"environnement préhistorique" marche très bien smile tigcc peut etre aussi, mais pour un crétin et un énorme paresseux comme moi, c'est plus simple, plus court, ConText compile pour moi (pas la peine de me dire que tigc aussi, chuis au courant lol), j'ai un compilo et un linker, je sais ce qu'ils font, j'ai pas le dossier de mon proj encombré avec des fichiers générés par une IDE que je sais même pas ce qu'ils viennent foutre la...

Et le linkage de plusieurs fichiers objets compilés séparément?
Nitro a écrit :
L'exemple est parfait... sur mon serveur FreeBSD j'ai plus d'une 20aine de programmes qui utilisent zlib.
Pour ceux qui linkent dynamiquement, aucun probleme, je download et j'installe le patch pour libz.so.. 2 commandes à taper, et c'est fini.
Pour ceux qui linkent statiquement, deja bonne chance pour les trouver... et comme le dit le site lui meme:
Various ports may statically link zlib or contain their own versions
of zlib that have not been corrected by updating the FreeBSD libz.
Efforts are underway to identify and correct these ports.

Déjà pour mettre tellement longtemps à trouver des programmes qui linkent zlib statiquement, j'ai bien l'impression qu'ils ne sont pas doués. Ça doit bien se voir:
- dans les makefiles
- dans les headers utilisés
(Ceci présume un programme open-source. Pour un programme closed-source, c'est la responsabilité de celui qui le délivre de le corriger, pas du projet FreeBSD.)
Quant au problème des programmes qui font du copier-coller au lieu de linker statiquement (et là, il en a eu plein pour zlib en effet), c'est un autre problème qui n'a aucun rapport avec les librairies statiques. Pire: les librairies dynamiques qui ne peuvent pas être linkées statiquement (comme c'est le cas sur TI-89/92+) encouragent ce genre d'actions, vu qu'il n'y a pas d'autre moyen d'utiliser ces librairies comme des librairies statiques.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

50

boon, juste un truc avant daller dormir...
Et je lui ai répondu qu'il n'est pas difficile de changer genlib pour qu'il n'y ait plus 90% du code indissociable

ah ça c'est sur, c'est pas difficile de bien le ralentir aussi grin

CF avec -10000 cycles de rabe par frame grin
In many respects the Yoshi is like a beautiful woman. A man can come so enamoured that he bestows on her all his time, his energy and his fortune.
- Fred whipple, 1960

*** Ne sous-estimez pas la puissance de la Marmotte ***
© Marmotte Team : LaMarmotte, sBibi, Vark & Sabrina

51

Kevin Kofler a écrit :
Déjà pour mettre tellement longtemps à trouver des programmes qui linkent zlib statiquement, j'ai bien l'impression qu'ils ne sont pas doués. Ça doit bien se voir:
- dans les makefiles
- dans les headers utilisés
(Ceci présume un programme open-source. Pour un programme closed-source, c'est la responsabilité de celui qui le délivre de le corriger, pas du projet FreeBSD.)


Le résultat est là, les programmes qui sont linkés dynamiquement avec zlib sont secures, ceux qui sont linkés statiquement ne le sont pas. Et dire que l'équipe de FreeBSD n'est pas douée ça me fait rire aussi. grin FreeBSD c'est justement l'exemple où c'est le moins pire (avec les autres BSD qui ont un système de paquetage automatisé similaire), par contre sous Solaris ou sous Linux, c'est toi qui va devoir te taper le boulot toi meme pour trouver quel logiciel utilise zlib statiquement... alors là qui se tape le sale boulot, l'utilisateur ou le programmeur ?
So much code to write, so little time.

52

RedHat a mis à jour tout un paquet de programmes linkant statiquement (ou recopiant carrément) zlib en même temps que zlib elle-même. Il suffisait d'aller télécharger tous les errata (et il y a des moyens automatiques de le faire: up2date pour les abonnés, sinon apt4rpm ou alors des shell scripts qui traînent sur Internet). Donc désolé de te décevoir, mais on peut faire mieux que FreeBSD! Il y a même un scanneur automatique qui reconnait des programmes utilisant zlib en regardant le binaire seulement!
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

53

Kevin Kofler a écrit :
RedHat a mis à jour tout un paquet de programmes linkant statiquement (ou recopiant carrément) zlib en même temps que zlib elle-même. Il suffisait d'aller télécharger tous les errata (et il y a des moyens automatiques de le faire: up2date pour les abonnés, sinon apt4rpm ou alors des shell scripts qui traînent sur Internet). Donc désolé de te décevoir, mais on peut faire mieux que FreeBSD! Il y a même un scanneur automatique qui reconnait des programmes utilisant zlib en regardant le binaire seulement!

C'est un cas particulier... tu as tendance à penser que le monde doit etre parfait, mais bienvenue dans la vie réeelle, dans laquelle des milliers de machines sont insécures à cause de zlib linké statiquement. Le temps mis par les admins à corriger tout ça c'est de l'argent de perdu.
Pourquoi d'apres toi le ELF est consideré comme le format d'objet moderne et le COFF/AOUT/etc.. sont considerés obsoletes ? Parce que le ELF gere nativement le C++ et les libraries dynamiques.
Et je t'entends encore me dire "oui c'est bien beau sur les ordinateurs, mais la on est sur calculatrice, mémoire/proc limitée, etc etc...". Alors regarde du coté de RTEMS, noyau temps réel pour l'embarqué (tourne sur 68000 entre autres, prend 70 Ko avec la libc posix), ils sont passés de COFF à ELF depuis un bout de temps.. regarde également du coté de uCLinux (noyau Linux qui tourne sur 68000, prend moins de 500Ko), ils sont également passés de COFF à ELF, pour les memes raisons.
Ca n'a plus grand chose à voir avec kernel/nostub, mais c'est juste pour essayer de te faire prendre conscience que l'immense majorité des OS utilisent des libs dynamiques et que tu ne peux pas te prétendre plus intelligent que tous leurs concepteurs.
So much code to write, so little time.

54

Encore d'accord avec Nitro.

55

kevin a dit : Dans ce cas, le problème est que PpHd a tout mis dans un installeur qui ne permet pas de choisir les composants à utiliser. Donc si on ne veut mettre à jour que le programme principal, on doit se taper toute l'installation. C'est un problème de l'installeur de CF (tinstall), pas du principe des librairies statiques.



et ça ne t'es jamais venu à l'esprit que si PpHd sortais une beta 3.29 BETA 2 par exemple (grin) il sortirait une version complète 3.29 BETA 2 ET une version UPDATE 3.29 BETA 1 to 3.29 BETA 2 qui ne réinstallerait QUE les fichiers mis à jours ?triso
avatar
納 豆パワー!
I becamed a natto!!!1!one!

56

Nitro
a écrit : C'est un cas particulier...

La seule chose qui est particulière dans le cas de zlib est le nombre de programmes qui l'utilisent! Elle s'est retrouvée même dans des programmes de M$! Pour la plupart des autres librairies, les dégats seraient de loin plus petits.
Et puis les considérations de sécurité (comme dans le cas de zlib) n'ont pas du tout leur place sur TI-89/92+.
tu as tendance à penser que le monde doit etre parfait, mais bienvenue dans la vie réeelle, dans laquelle des milliers de machines sont insécures à cause de zlib linké statiquement. Le temps mis par les admins à corriger tout ça c'est de l'argent de perdu.

Si les admins ne sont pas foutus lancer up2date (une entreprise est censée être abonnée à RedHat Network), ils ne méritent pas d'être admins.
Et je sais bien que RedHat n'est pas la seule distribution *nix qui utilise zlib, mais pratiquement toutes (FreeBSD serait l'exception si tu dis vrai) ont mis à jour les paquets linkant statiquement zlib dans leurs erratas, et pratiquement toutes offrent un système automatique équivalent à up2date ou à apt-get de Debian.
D'ailleurs, si zlib a été linkée statiquement, c'est souvent pour des raisons techniques: dans un environnement où la plupart des répertoires sont sur des partitions réseau (c'est souvent le cas dans les entreprises ou les universités), les fichiers boot doivent être indépendants de toute librairie dynamique. Du moins c'est l'explication donnée par RedHat.
Pourquoi d'apres toi le ELF est consideré comme le format d'objet moderne et le COFF/AOUT/etc.. sont considerés obsoletes ? Parce que le ELF gere nativement le C++ et les libraries dynamiques.

Et ça complique inutilement le format, et ça crée des bogues. Surtout en combinaison. Il y a un thread entier sur ceci dans la mailinglist de GCC en ce moment, regarde les archives pour voir comment il est énorme. Et c'est tout dû à la "flexibilité" excessive du format ELF.
Et je t'entends encore me dire "oui c'est bien beau sur les ordinateurs, mais la on est sur calculatrice, mémoire/proc limitée, etc etc...". Alors regarde du coté de RTEMS, noyau temps réel pour l'embarqué (tourne sur 68000 entre autres, prend 70 Ko avec la libc posix),

Une libc POSIX pour Motorola 68000 qui tient en 70 KO??? Avec le noyeau real time en plus?
Je n'arrive pas à te croire ceci...
ils sont passés de COFF à ELF depuis un bout de temps.. regarde également du coté de uCLinux (noyau Linux qui tourne sur 68000, prend moins de 500Ko), ils sont également passés de COFF à ELF, pour les memes raisons.

Ce n'est pas très malin à mon avis.
Mais bon, le format COFF est déjà trop compliqué (regarde tous les trucs inutiles du format COFF que Obj2ti est obligé de virer avant d'avoir un exécutable dans un format compréhensible).
Ca n'a plus grand chose à voir avec kernel/nostub, mais c'est juste pour essayer de te faire prendre conscience que l'immense majorité des OS utilisent des libs dynamiques et que tu ne peux pas te prétendre plus intelligent que tous leurs concepteurs.

Je ne suis pas le seul critique des librairies dynamiques!
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

57

Perso je vais dire ce que je pense (vu que je suis mi stub mi nostub, je vais me faire gt par tout le mondesmile):

Pourquoi j'aime le nostub: ca evite d'avoir 150libs sur la calc et d'installer 'unios/preos/doorsos' a chaque fois. A quand la release de Autoinst?
J'aime pas avoir besoin d'une lib pour des programmes comme 'TxtRider/TGV', qui je pense devrait etre nostub (il y en a qui ont que ca sur leur calc.. interet d'un kernel..?) pour des utilitaire comme cela, sur ti, je prefere le nostub.


Pourquoi le nostub est limité:
Je m'en rend compte pour le dev de Xlib, sa taille tend vers celle de genlib... et il est inconsiderable de la foutre dans chaque programme. le mode kernel semble etre la bonne solution .. pourtant je ne le pense pas...

L'idée que je propose:
On a 40 ko de libre dans la rom... de quoi mettre:
Une lib graphique puissante: X/Gen
Une lib utilitaire: Userlib like
2 libs de compression: Zip/runc?

Franchement je vois que cela comme solution... et c'est ce que je vais faire sur ma calc...
XLib v1.00 Powerrrrrrrrrrrrrrrrrrrr!

58

C'est vraiment une mauvaise solution. C'est beaucoup mieux de laisser _X_Lib en librairie statique. Les programmeurs n'utiliseront en général pas toutes les fonctions de toute façon.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

59

Kevin Kofler a écrit :
La seule chose qui est particulière dans le cas de zlib est le nombre de programmes qui l'utilisent! Elle s'est retrouvée même dans des programmes de M$! Pour la plupart des autres librairies, les dégats seraient de loin plus petits.
Et puis les considérations de sécurité (comme dans le cas de zlib) n'ont pas du tout leur place sur TI-89/92+.


Ce n'est pas de sécurité dont il s'agit, mais d'upgrader une lib buggée.
Si les admins ne sont pas foutus lancer up2date (une entreprise est censée être abonnée à RedHat Network), ils ne méritent pas d'être admins.
Et je sais bien que RedHat n'est pas la seule distribution *nix qui utilise zlib, mais pratiquement toutes (FreeBSD serait l'exception si tu dis vrai) ont mis à jour les paquets linkant statiquement zlib dans leurs erratas, et pratiquement toutes offrent un système automatique équivalent à up2date ou à apt-get de Debian.

Ca ne marche qu'avec les programmes recuperés grace au systeme automatique... tous ceux compilés à la main, il faut aller fouiller dedans. De plus le temps necessaire pour corriger tous les paquetages est nettement supérieur au temps necessaire pour corriger zlib tout seul... et pendant ce temps, la sécurité est compromise pour ceux qui linkent statiquement.
Et ça complique inutilement le format, et ça crée des bogues. Surtout en combinaison. Il y a un thread entier sur ceci dans la mailinglist de GCC en ce moment, regarde les archives pour voir comment il est énorme. Et c'est tout dû à la "flexibilité" excessive du format ELF.

Pourtant il est utilisé partout.
Une libc POSIX pour Motorola 68000 qui tient en 70 KO??? Avec le noyeau real time en plus? Je n'arrive pas à te croire ceci...


Je l'ai compilé moi meme... avec 80 fonctions de la libc (dont je peux etre sur qu'elles sont incluses car j'ai mis une table de saut vers toutes les fonctions), le noyau, le stub GDB, et le filesystem: 84 Ko
Je ne suis pas le seul critique des librairies dynamiques!

Il n'en demeure pas moins qu'elles sont utilisées partout...
So much code to write, so little time.

60

Mais arretez z'etes lourds


Vous voyez bien que ca n'a avancé a rien de laisser le topic ouvert?! Qui estime avoir appris? ce sont toujours les memes qui se disputent!

J'estime qu'on a rien appris dans ce topic, comme je l'avais dit, de plus je trouvais que kevin etait fermé au niveau de ces idées, meme si a coté de ca je l'apprecie mais, la je m'apercois qu'il est pas tout seul, et de plus en plus je m'apercois que l'ouverture d'esprit est une qualité qui se fait tres rare, c dommage. Meme s'il y a du vrai de chaque coté, il ne faut pas se borner a denigrer a tout prix parce qu'on est pas d'accord sur certains points, j'ai vu des exemples et contres exemples completement debile, juste pour contredire...

Le seul avantage que l'on peut tirer de ce genre de discussion, est de se sentir un peu moins con, en voyant que les personnes qu'on estime ne le sont pas moins que soi-meme.