TIGCC :: Lib kernel? - Page 6

Moumou a écrit :
Enfin voila le principe :

Sur la calculatrice, il y a un kernel (qu'on appellera PreOs pour des raisons de commodité ), et une librairie (notée mainlib par exemple).
Lors de la compilation du programme, le compilateur sort un fichier (genre pack archive) qui contient le programme, et une lib dynamique customisée, qui ne contient que les fonctions dont le programme a besoin.
Ensuite, lors du premier lancement du programme, PreOs décompresse le pack archive, sort la librairie, intègre à mainlib les fonctions qui n'en font pas déjà partie (et uniquement elles), et éxécute le programme. Ce serait bien sur fait de manière transparente.

Comme ça, on aurait sur la calculette uniquement les fonctions effectivement utilisées, et en un seul exemplaire, ça combinerait donc les avantages des deux méthodes.
C'est con, ou c'est crédible ?

C'est beaucoup trop compliqué à implémenter. Surtout du côté du linker. Et en plus, comme tu dis, ça nécessite un kernel. Ou alors un code de démarrage de plusieurs KO. Donc ne vous attendez pas à voir ça dans TIGCC.

Bon, le camp Tigcc/nostub a répondu, j'attends Pollux et PpHd pour le camp GTC/Kernel

bah Pollux parlait pas d'une seul lib qui à une partis static et une autre dynamique, mais d'une lib static et d'un autre lib dynamique, nan ???

Moumou a écrit :
Bon, le camp Tigcc/nostub a répondu, j'attends Pollux et PpHd pour le camp GTC/Kernel

La difficulté d'implémenter tout cela (à la fois le support côté linker et le support côté kernel ou code de démarrage) est là indépendemment du "camp" tel que tu le définis.

MacIntoc
a écrit : bah Pollux parlait pas d'une seul lib qui à une partis static et une autre dynamique, mais d'une lib static et d'un autre lib dynamique, nan ???

Ça s'appelle "jouer sur les termes", ça.

Si ces 2 librairies sont le résultat du découpage en 2 d'une seule librairie, elles ne sont pas vraiment indépendantes.

ce que tu appelle jouer sur les termes est la manière dont g compris la phrase.
Sinon, découper une lib en 2 permet en effet de bénéficier des avantages des 2, mais aussi des désavantages

C'est con, ou c'est crédible ?

En tout ca c'est chiant a implémenter et ca pourait devenir un vrai bordel. Ceci dit l'idée n'est pas mauvaise

C'est beaucoup trop compliqué à implémenter. Surtout du côté du linker. Et en plus, comme tu dis, ça nécessite un kernel. Ou alors un code de démarrage de plusieurs KO. Donc ne vous attendez pas à voir ça dans TIGCC.

Encore une excuse pour ne pas implémenter ce qui pourait avantager le kernel car ce qui serait vraiment complexifié c'est le kernel et non le linker.

Le linker aussi. Je sais de quoi je parle.

Le linker aussi. Je sais de quoi je parle.

Pardon je viens de relire attentivement le post de Moumou et je me rend compte que j'avais mal compris ce qu'il comptait faire. C'est vrai que c'est aussi du travail coté linkeur.
L'idée me plais pas mal mais il faut avouer que c'est du boulot. Et si en plus il faut trouver un moyen de libérer le pack des fonctions devenues inutiles et la ça deviens vraiment dur.

Uther Lightbringer
a écrit : Et si en plus il faut trouver un moyen de libérer le pack des fonctions devenues inutiles et la ça deviens vraiment dur.

Tu pouvais dire "impossible" directement, le mot n'est pas tabou.

KK>Le cas de ExtGraph est justement le cas désirable. Il y a des tas de fonction proposées, et le programme a la possibilité de choisir celle(s) qui lui convien(nen)t le plus. Une librairie plus flexible est une librairie meilleure.

Tu a deja programmer avec XLib (pas celle de Timad, moi et Neurone, mais celle du system X Window) ??

Pasque si tu veux une lib flexible, ben t servi, mais vu le bordel que c, ben c et extgraph risque (perso) de finir au meme endroit si elle se complexifie trop..

Un bonne lib est une lib SIMPLE, FACILE A UTILISER, et surtout QUI NE PROPOSE PAS 36 MILLION DE MANIERE DIFFERENTE POUR FAIRE LA MEME CHOSE.

Se n'est plus de la flexibilité dans se cas la mais de la co**erie profonde

Je ne suis pas d'accord. On peut faire une librairie flexible sans qu'elle soit aussi complexe que la librairie X11.

ce que tu appelle jouer sur les termes est la manière dont g compris la phrase. Sinon, découper une lib en 2 permet en effet de bénéficier des avantages des 2, mais aussi des désavantages

Bon, je réexplique : disons que Z veut faire ZLib, il met ses fonctions couramment utilisées dans ZLib.89z, et les fonctions plus exotiques dans ZLib.a. Evidemment ce serait idiot de mettre la même chose dans les deux

C'est une mauvaise idée: * pour les problèmes de version (synchronisation version de la partie statique - version de la partie dynamique)

Je ne vois pas le pb.

* pour les raisons de flexibilité décrites ci-dessus: tu ne peux pas proposer des alternatives aux fonctions "très utilisées" (que tu mets dans ta librairie dynamique) sans perdre de la place.

Hein?

Sur la calculatrice, il y a un kernel (qu'on appellera PreOs pour des raisons de commodité ), et une librairie (notée mainlib par exemple).
Lors de la compilation du programme, le compilateur sort un fichier (genre pack archive) qui contient le programme, et une lib dynamique customisée, qui ne contient que les fonctions dont le programme a besoin.
Ensuite, lors du premier lancement du programme, PreOs décompresse le pack archive, sort la librairie, intègre à mainlib les fonctions qui n'en font pas déjà partie (et uniquement elles), et éxécute le programme. Ce serait bien sur fait de manière transparente.

Comme ça, on aurait sur la calculette uniquement les fonctions effectivement utilisées, et en un seul exemplaire, ça combinerait donc les avantages des deux méthodes.
C'est con, ou c'est crédible ?

C'est plus ou moins ce que je comptais faire dans GTools (et que je vais mettre dans la Virtual Machine de GT-Dev), mais pas fonction par fonction (overhead pour chaque fonction, et puis impossibilité des accès PC-relatifs entre 2 fonctions => pas cool).

Pollux a écrit :
Bon, je réexplique : disons que Z veut faire ZLib, il met ses fonctions couramment utilisées dans ZLib.89z, et les fonctions plus exotiques dans ZLib.a. Evidemment ce serait idiot de mettre la même chose dans les deux

Pourquoi ça serait idiot? Ça me permettrait de n'utiliser que la version statique et d'envoyer aux ... euh ... toilettes ... la version dynamique.
Mais il est vrai qu'il vaut mieux n'offrir que la version statique.

Je ne vois pas le pb.

Il risque d'avoir des problèmes de compatibilité si les versions ne correspondent pas.

Hein?

Lis le message #146 en entier. Je n'ai pas envie de tout répéter.

C'est plus ou moins ce que je comptais faire dans GTools (et que je vais mettre dans la Virtual Machine de GT-Dev), mais pas fonction par fonction (overhead pour chaque fonction, et puis impossibilité des accès PC-relatifs entre 2 fonctions => pas cool).

Si ce n'est pas fait fonction par fonction, ça perd une grande partie de son intérêt.

Tu pouvais dire "impossible" directement, le mot n'est pas tabou.

Je sais pas pour l'autriche mais chez nous on dit "impossible n'est pas français."
Plus sérieusement ou pourait faire en sorte qu'a l'appel d'un prog kernel, le kernel vérifie tous les fichiers mais la ça commence a devenir tordu.

Uther Lightbringer a écrit :
Je sais pas pour l'autriche mais chez nous on dit "impossible n'est pas français."

Et PpHd, non content d'être français, est aussi un dieu #leche# powaaa

XDanger a écrit :
Et je redis que je n'ai aucune intention de supporter PedroM. PpHd pourrait émuler les attributs 0x300, 0x301 et 0x302 de OO_GetAttr (c'est OO_CondGetAttr que j'utilise), ça n'est pas bien difficile (pseudo-code):
OO_CondGetAttr:
si attribut n'est pas 0x300, 0x301 ou 0x302: lancer une erreur, le soft ne tournera pas.
sinon, on renvoie les adresses.
Mais cela ne suffira pas, à cause du hack pas très propre mais stable (ce qui n'est pas le cas des fonts du boot ou de trucs comme ça), utilisé pour AMS 1.xx... TI-Chess utilise les nouvelles routines, S1P6, tthdex et d'autres, notamment ebook, vont le faire. Les routines sont censées être intégrées à TIGCCLIB à moyen terme.

Le hack des fontes du boot a le merite de marcher niquel... Celui de la heap aussi.
Tes hacks ne fonctionnent pas.

Kevin Kofler a écrit :
Pour moi, "plus pratique" = "moins de travail". Donc je préfère avoir un seul programme à mettre à jour. Prends l'exemple d'une distribution Linux: préfères-tu mettre à jour tes programmes un à un en allant chercher les mises à jour sur les sites officiels des applications sans arrêt, ou préfères-tu attendre la prochaîne version de la distribution? Moi, c'est le deuxième choix. Quand il y a un vrai problème dans une des applications, il y aura un errata immédiatement, et c'est la même chose pour les programmes linkés statiquement quand il y a un vrai problème dans une librairie.

Ils s'emblent a t'entendre que tu n'aimes pas les mises a jour.

Kevin Kofler a écrit :
Même pas, vu la moyenne de taille des programmes qui utilisent genlib et par conséquent le petit nombre de programmes utilisant genlib qui peuvent être présents sur calculatrice en même temps (1 ou 2 normalement, à la limite 3 en ne mettant vraiment rien d'autre sur sa calculatrice).

Tu peux monter a 4.

Corollaire: Les librairies dynamiques ne peuvent pas être flexibles. Il est impossible d'écrire une librairie dynamique qui s'adapte aux nécessités du programme client sans gaspiller une quantité énorme de place. Par conséquent, le programme est obligé de s'adapter à la librairie, ce qui veut souvent dire réduire ses fonctionnalités ou dans le cas de genlib la qualité de ses graphismes.
Conclusion: Les librairies statiques offrent une flexibilité majeure, elles sont donc meilleures.

Avec ce raisonnement on arrive aux libs statiques de plusieurs centaines de Ko...
Et le programme apres ne se compilera + <= > a 64Ko.
Merci beaucoup pour toute cette place prise.

Le cas de ExtGraph est justement le cas désirable. Il y a des tas de fonction proposées, et le programme a la possibilité de choisir celle(s) qui lui convien(nen)t le plus. Une librairie plus flexible est une librairie meilleure.

Et + de place prise car elles sont toutes independantes les 1 des autres.

Pas du tout. C'est l'exemple-même de l'inflexibilité. Par exemple, PpHd a refusé d'ajouter des fonctions de sprites en 4 ndg et pas 3. Pourquoi? Parce que c'est une librairie dynamique, ce qui fait que rajouter des fonctions prend de la place, qu'elles soient utilisées ou non, et que proposer 2 fonctions en alternative veut dire 2 fois la place prise, alors que pour une librairie statique (correctement divisée en fichiers objet séparés), les fonctions inutilisées ne prennent même pas 1 octet sur la calculatrice, et proposer 2 fonctions en alternative veut dire exactement la même place prise qu'en ne proposant qu'une seule fonction.

Mais si on utilise les 2 ?

C'est une mauvaise idée:
* pour les problèmes de version (synchronisation version de la partie statique - version de la partie dynamique)
* pour les raisons de flexibilité décrites ci-dessus: tu ne peux pas proposer des alternatives aux fonctions "très utilisées" (que tu mets dans ta librairie dynamique) sans perdre de la place.

1. Faux. <= ABi stable.
2. C'est un probleme de concept.

Non, c'est une très mauvaise idée. Cf. ci-dessus.

Hum

Moumou: C'est possible. Mais comment gerer la desinstallation ?

> Dans le cas d'ExtGraph (300 fonctions avec plein de tailles de sprites différentes), oui.
Et le nombre de fonctions va plus que doubler...

PpHd
a écrit : Ils s'emblent a t'entendre que tu n'aimes pas les mises a jour.

Je n'aime pas avoir à mettre à jour une dizaine (voire des centaines dans mon exemple de la distribution de Linux) de programmes/librairies individuellement quand mettre à jour un seul logiciel ou un seule distribution de logiciels en une seule fois suffit.

PpHd
a écrit : Tu peux monter a 4.

Pas vraiment...

Avec ce raisonnement on arrive aux libs statiques de plusieurs centaines de Ko...

Et alors? Personne ne t'oblige à utiliser toutes ses fonctions!

Et le programme apres ne se compilera + <= > a 64Ko.

Il se compilera parce qu'on n'utilise pas toutes les fonctions.

Merci beaucoup pour toute cette place prise.

As-tu des problèmes de place sur ton disque dur? Parce que toute cette place prise ne se retrouvera jamais entièrement sur la calculatrice. Juste sur les disques durs des programmeurs.

Et + de place prise car elles sont toutes independantes les 1 des autres.

Pas tellement. Et une routine peut dépendre d'une autre quand ça a vraiment un sens. Par exemple DrawRectangle peut dépendre de DrawHorizontalLine et DrawVerticalLine. De toute façon, pour tracer un rectangle, on a forcément besoin de tracer 2 lignes horizontales et 2 lignes verticales quelque part.

Mais si on utilise les 2 ?

Heureusement que j'ai dit "en alternative".
Si les 2 routines font vraiment la même chose de 2 manières différentes, en général, on n'utilisera pas les 2.

1. Faux. <= ABi stable.

Mais ce n'est plus une question d'ABI exportée, mais d'ABI à l'intérieur de la librairie. Ça complique beaucoup les choses.

2. C'est un probleme de concept.

Ce n'est pas un problème du concept de la librairie individuelle, mais du concept des librairies dynamiques en général, qui ne permet pas de concevoir des librairies flexibles. Tu parles comme si concevoir une librairie flexible était une erreur. Pour moi, l'erreur, c'est de concevoir une librairie inflexible.

PpHd
a écrit : Moumou: C'est possible. Mais comment gerer la desinstallation ?

Impossible de la gérer avec son système.

On peut facilement mettre une dizaine de programmes genlib sur sa calc : rien que les exemples, ça fait 7 progs

>Mais ce n'est plus une question d'ABI exportée, mais d'ABI à l'intérieur de la librairie. Ça complique beaucoup les choses
La lib statique respecte l'ABI exportée. Tu vois d'autres solutions ?

Au lieu de repondre individuellement, je dirais que tu supposes que le programmeur va faire un choix restreint parmi toutes les fonctions proposees. Plus il choisira de fonctions, plus ca coutera. D'apres mon experience, je sais que cela entraine des programmes surdimensionnes.

jackiechan
a écrit : On peut facilement mettre une dizaine de programmes genlib sur sa calc : rien que les exemples, ça fait 7 progs

PpHd a écrit :
>Mais ce n'est plus une question d'ABI exportée, mais d'ABI à l'intérieur de la librairie. Ça complique beaucoup les choses La lib statique respecte l'ABI exportée. Tu vois d'autres solutions ?

Non, et c'est exactement ce que je critique. Par exemple, les fonctions d'une librairie devraient pouvoir accéder aux variables globales, mais privées de cette librairie, et l'implémentation exacte de ces variables devrait pouvoir changer sans problèmes. Avec une librairie coupée en 2 de cette manière, ce n'est pas le cas.

Au lieu de repondre individuellement, je dirais que tu supposes que le programmeur va faire un choix restreint parmi toutes les fonctions proposees.

Oui.

Plus il choisira de fonctions, plus ca coutera.

Évidemment. Et c'est tout à fait normal.

D'apres mon experience, je sais que cela entraine des programmes surdimensionnes.

Pas si le programmeur sait ce qu'il fait.

PpHd
a écrit : Moumou: C'est possible. Mais comment gerer la desinstallation ?

Je ne sais pas ... vérification de la table des fichiers à chaque lancement ? Ca risque d'être un peu lourd et lent... un truc genre effacer les fonctions non utilisées depuis longtemps ne doit pas etre une bonne idée non plus...

Peut-être un truc genre si on tape mainlib("clean"), le nettoyage (par vérification exhaustive de la fat) est effectué... ou il affiche simplement une table des fonctions qu'il possède et donne des informations sur celles ci (a jour / obsolète / inutilisée / etc...) et propose un moyen de suppression manuelle)

Bon, ça complique encore un peu le tout, malheureusement...

Pas si le programmeur sait ce qu'il fait

je croyais que tu avais pr habitude de considérer les users comme des crétins finis ?

plein de programmeurs sont des débuttants, et rare sont ceux qui vont plus loin que le stade de débuttant...

squale92
a écrit : je croyais que tu avais pr habitude de considérer les users comme des crétins finis ?

Les users oui, mais pas les programmeurs. Il faut quand-même avoir un cerveau pour programmer.