Kernel ou nostub ? - Page 3

La prochaine version du TICT Explorer les lira.

il serait temps ! Ca fait plus d'un an que CS les gère parfaitement

Kevin Kofler
:

Pollux :
Mais qu'est-ce que tu racontes ?
- je comprends pas pkoi y aurait des faux positifs : si le type update sa lib et revient en arrière pour les n°s de version, il est vraiment con
- je comprends pas pkoi y aurait des faux négatifs non plus

Je parlais des tests "version!=0" à l'installation de PreOs.

Ben ça veut juste dire qu'il faut prendre stdlib parce qu'il y a des vieilles libs buggées... Ce n'est pas censé être une protection.

Pour les versions explicitement demandées par un programme, cf. ./51.

Pas très convaincant. Si un prog (récent) ne le fait pas alors que c nécessaire, c un bug du programme, qui se corrige comme n'importe quel autre bug

Flanker
:

La prochaine version du TICT Explorer les lira.

il serait temps ! Ca fait plus d'un an que CS les gère parfaitement

Y compris le troisième paragraphe de la section III.12 rajoutée dans la version 1.01 (cf. http://p080.ezboard.com/ftichessteamhqfrm3.showMessage?topicID=174.topic)? Sinon, au boulot!

Franchement, je pense que l'argument de la place gaspillée au niveau du combat lib dynamique/statique est peu convaincant (dans un sens comme dans l'autre), et ce ne sont pas quelques ko sur les 700 de ma TI-89 HW2 qui vont changer grand chose.
Le vrai argument que je trouve intéressant est en faveur des libs dynamiques : au niveau de la maintenabiilité c'est bien plus pratique. Par exemple, actuellement, tous les programmes _nostub (utilisant par exemple les nvg ou même simplement détournant les ints) doivent être patchés pour fonctionner sur titanium, tandis qu'avec des libs dynamiques, il suffit de ne mettre à jour que la lib pour que tous les progs fonctionnent (en partant du principe qu'on a pas les sources).
Bon, là l'exemple n'est peut-être pas parfait puisqu'il semble que même les prog kernel doivent être patchés pour tourner sous titanium, mais le principe est là.

Sasume
: Bon, là l'exemple n'est peut-être pas parfait puisqu'il semble que même les prog kernel doivent être patchés pour tourner sous titanium,

En effet.

Ton argument tiendrait si les niveaux de gris étaient la seule raison de détourner les interruptions, mais là, je vois plein de 0x40000 qui traînent dans les programmes kernel...

C'est peut-être dû à la superbe macro {Set|Get}IntVec de TIGCCLIB tu ne crois pas ? ...

Je trouve qu'il tient quand même, au niveau maintenabilité, c'est bien plus efficace même si dans le cas cité ça n'est pas parfait.
Pour corriger un bug.
Améliorer la librairie.
ça tient.

GoldenCrystal
: C'est peut-être dû à la superbe macro {Set|Get}IntVec de TIGCCLIB tu ne crois pas ? ...

Ben non, ça se trouve dans les programmes ASM aussi, et ça date de bien avant (il y a déjà ça dans les sources de PlusShell, par exemple). Ce sont les kernels qui ont introduit ce hack débile.

Que vous avez suivi dans TIGCC.
Bon on arrête là ce troll à propos de ce hack idiot.

N'es-tu pas d'accord avec mon post ./67 ?
Par exemple, geogeo vient de mettre à jour PolySnd, je suppose que si elle avait été dynamique il n'aurait pas eu à mettre à jour les programmes utilisant la lib, si ?

Pour l'ASM certes (quoique tu ai parfois encouragé l'utilisation de cette technique :/), mais pour le C vous en êtes responsables puisque vous avez préferé conserver le hack, pour des raisons pas totalement claires

Ben parce qu'ils ne pensaient pas que l'architecture allait à ce point changer.
On ne peut pas vraiment leur en vouloir pour ça, je trouve.

Perso je programmais en nostub parce que j'avais pas besoin des libs kernels! et puis rien que le fait que genlib soit imposé en kernel me range du cote des nostubien.

>là l'exemple n'est peut-être pas parfait puisqu'il semble que même les prog kernel doivent être patchés pour tourner sous titanium,
Non, non
Preos 0.70 fait fonctionner les programmes kernels directement sur titanium sans GhostBuster

Ben, parce qu'il les patche lui-même...

Maintenant, il y a des RAM_CALL pour ça

A propos des rom_call en F'line :

Flanker
:

Ben, il faut faire son choix: place ou compatibilité.

de toute façon, sur la TI, on n'est pas à qqes octets près, l'important c'est que ça marche

. Et les patchs sont ultra-simples, mais fonctionnent.

>et puis rien que le fait que genlib soit imposé en kernel me range du cote des nostubien.
Tu changes d'avis comme de chemises

>Ce sont les kernels qui ont introduit ce hack débile.
En fait y'a relativement peu de programmes kernels qui l'utilisent.

>Et souvent, la version dans le header kernel ne change même pas pour des mises à jour qui ne font que corriger des bogues (et c'est normal, sinon on est vite arrivé à la version 256 qui ne rentre plus).
Et perso si j'ai un bug dans une lib, je mets a jour la version kernel.

ouai j'aime bien changer d'avis!

Allez change encore une fois !

mdr

Kevin Kofler :
Ben, parce qu'il les patche lui-même...

Et alors ? au niveau utilisation, la principe reste le même : l'utilisataeur n'installe qu'un nouveau programme et n'a pas besoin de se soucier des autres...
Et que penses-tu de ./67 ?

PpHd
: Y'a un programme pour enlever, et je bosse pour que preos resiste au reset (sans modifier la flash. Trou ams powa).

Chouette A partir des 'mots de passe' lus au reset par l'AMS ou autre chose ?

Oue Mais ca entraine pas mal de pbs a resoudre.

kerno rulez!!!!!!!!!! (non non j'ai pas envie de me faire frapper)

!slap Jack[tab]
• Nil slaps Jack[tab] around a bit with a large trout !

Pollux :
Mais qu'est-ce que tu racontes ?
- je comprends pas pkoi y aurait des faux positifs : si le type update sa lib et revient en arrière pour les n°s de version, il est vraiment con
- je comprends pas pkoi y aurait des faux négatifs non plus

Ben si tu as codé ça sur un octet, tu fais quoi après la version 255?

Sasume :
Que vous avez suivi dans TIGCC.
Bon on arrête là ce troll à propos de ce hack idiot.

N'es-tu pas d'accord avec mon post ./67 ?Par exemple, geogeo vient de mettre à jour PolySnd, je suppose que si elle avait été dynamique il n'aurait pas eu à mettre à jour les programmes utilisant la lib, si ?

Pas forcément, mais il aurait alors tenté de faire le nécessaire pour. S'il change le fonctionnement de l'une ou l'autre des fonctions (ou rajoute des préliminaires d'initialisation non-existantes auparavant), rajoute/modifie quelques bits dans le format sonore, et ainsi de suite, alors là, il devra inclure une bonne moitié de l'ancien code avec le nouveau, histoire de garder la compatibilité avec les anciens progs et l'ancien format. Ca fait grossir la lib, mais au moins ça sera compatible! C'est un avantage non négligeable.
C'est comme les fichiers de sauvegarde binaire vs texte -> texte, jamais de problème pour rajouter des trucs, à part en cas de modification générale -> importation comme en binaire.
L'avantage que je vois au nostub c'est la simplicité pour débuter avec TIGCC IDE (nouveau fichier source C -> tout est déjà bon!). De plus, il n'y a "rien besoin de plus qu'une TI 89 sous AMS", donc pratique quand on débute et qu'on distribue dans sa classe, tout fier, ses petits jeux qu'on vient de faire, surtout que la plupart des fois les autres ne savent pas qu'il faut aussi envoyer preos, stdlib et cie, donc bizarrement, ça ne marche pas © et on ne sait pas pourquoi -> gros frein à la distributioin calc->calc.
Avec les anciens progs kernel, c'était vraiment chiant de devoir toujours rechercher les bons packs de libs, car il y avait toujours des "Library not found: *lib" pendant un moment. Maintenant avec PreOS et stdlib, le problème a (enfin) disparu, donc c'est beaucoup mieux (en revanche le fait que genlib y soit inlcus me déçoit).
L'inconvénient du nostub est, comme dit plus haut, le fait que certaines choses, comme le support niveaux de gris, font grossir tous les programmes, plutôt que de ne le faire qu'une seule fois.
Perso j'ai quasi toujours écrit mes routines moi-même car j'aime ça, et comme je les adapte finement pour chacun de mes progs, je me range donc sur le _nostub (tous mes jeux n'utilisent que TIGCCLIB et mes routines).

> (en revanche le fait que genlib y soit inlcus me déçoit).
Rien ne t'empeche de recompiler stdlib sans genlib.

> gros frein à la distributioin calc->calc.
Perso ca ne m'a jamais freine la distribution calc <-> calc.

> gros frein à la distributioin calc->calc. Perso ca ne m'a jamais freine la distribution calc <-> calc.

En soi, ce n'est pas un gros frein. Mais j'ai dit pourquoi:

quand on débute et qu'on distribue dans sa classe, tout fier, ses petits jeux qu'on vient de faire, surtout que la plupart des fois les autres ne savent pas qu'il faut aussi envoyer preos, stdlib et cie, donc bizarrement, ça ne marche pas © et on ne sait pas pourquoi

ben tu sais, tous mes jeux utilisent beaucoup de fichiers (environ 5 si on compte pas CF) ,
donc bof 2 de plus

L'avantage que je vois au nostub c'est la simplicité pour débuter avec TIGCC IDE (nouveau fichier source C -> tout est déjà bon!).

c'est un peu voulu, ce n'est pas inhérent au format kernel