Kernel vs Nostub? - Page 14

Kevin Kofler a écrit :
Pas très coopératif. Mais je te comprends, je ne serais pas très content non plus de voir mes routines utilisées dans un concurrent commercial à mon propre projet.

Ben s'ils m'ambauchent, c'est ok.

Ou tout simplement qu'ils ne retiennent pas tes programmes dignes de news. Ce qu'on trouve intéressant ou non est fortement subjectif. Et il y a des raisons de ne pas faire de news sur CF, du moins en l'état en lequel il est actuellement.

C'est leur droit.

Et tu as pensé au nombre de vieilles librairies qu'il y a avec une version 0? smqlib par exemple? Oui, c'est un abus des librairies dynamiques, mais elles y sont quand-même!

Oui.

Ah bon? Mais ça fausse quand-même le tableau de mettre tous ces "no".

Ca reste vrai. J'ai differencie _nostub pur, et _nostub version booste tigcc avec stub.

C'est du vaporware comment? La spécification est déjà publique depuis des semaines. Et elle sera officialisée demain.

Ah.

C'est un kernel pour les programmes _nostub. Il apporte les fonctionnalités des kernels sauf le format kernel. C'est peut-être "bâtard", mais quand-même utile pour certains.

Je vois pas comment a part interdire l'install d'un laucnher kernel

Tu fais un tableau des possibilités qu'un format offre aux programmeurs. crashlib est une possibilité proposée aux programmeurs _nostub, donc elle a bien sa place dans ton tableau.

Je ne rentre pas en details des librairies offertes !

Tu as l'air de bien aimer ce mot "bâtard".
Les DLLs _nostub ne sont pas du tout un truc bâtard. Ce sont des fichiers externes qui contiennent du code. Il n'y a rien de bâtard là-dedans. Un exemple de format vraiment bâtard est ton idée de "mistub".

Ca porte mal son nom.

Parce que c'est un hack qui ne tient pas en compte la redéfinition des fontes qui est possible sous AMS 2.

Et c'est normal !

Ben alors je vais creer une lib dynamique ttpacklib

Une très bonne idée

>Et tu as pensé au nombre de vieilles librairies qu'il y a avec une version 0? smqlib par exemple? Oui, c'est un abus des librairies dynamiques, mais elles y sont quand-même! Oui.

Oui la aussi ca me fait peur Il faudrait que cette option ne soit fonctionelle que pour les lib en double(on suprime la plus ancienne)
Ou alors que ce soit un flag ajouté a la compilation.

>> Ben alors je vais creer une lib dynamique ttpacklib
> Une très bonne idée
Mais n'importe quoi ! L'algorithme de ttpack ne marche pas tel quel sur une TI-68k ! Il nécessite 128 KO + 15*la taille du fichier d'entrée.

Par ailleurs, "ttpacklib" n'est pas un nom AMS valide...

C'est vrai qu'il est pas jouable sur calco, je crois que KK avait essayer de le rendre compatible ...

Il me semble que c'est Thomas lui-même... Mais ça n'a aucune importance, la routine ne marche pas actuellement sur calculette...

On a essayé tous les 2, mais on s'est tous les 2 heurtés sur le même problème: pas assez de mémoire.

PS: Je répondrai aux autres messages quand j'aurai le temps.

Je ne savais pas que tu avais essayé toi aussi.
C'est dommage que l'algorithme nécessite tant de mémoire (en fait c'est plutôt que le hardware est trop faible...), parce qu'il n'y a pas beaucoup d'algorithmes généraux plus performants sur tous les types de fichiers...

Kevin a ecrit:
Il est vraiment dommage qu'on en soit arrivé là! Le problème "missing libs" est tellement grand qu'on en est arrivé avec PreOs à vouloir copier toutes les librairies dynamiques sur toutes les calculatrices.

Je croit que tu oublie un cas "pire" (UniOS pour pas le citer) et la a cette epoque tu n'avais rien dit que je sache (pour rappel UniOS possede toutes les libs DIRECTEMENT dans le fichier "kernel"...)

Perso la profusion des libs j'ai jamais trop aimé sa (enfin je rangait sa plutot bien dans un joli ptit rep "Libs" ) mais le coup d'UniOS je trouvait sa plutot lourd, mais perso PreOS a "répondu" a mon apel avec le PackLib
plus de soucis now

PpHd, a ce propos, (j'ai pas chercher des masses) il serait pas possible de puovoir ajouter/supprimer d'un PackArchive des fichier directement de la calc ? sa serait

edit: oups.... pbm de nom (cf post a XDanger)

>pour rappel UniOS possede toutes les libs DIRECTEMENT dans le fichier "kernel"...
Oui et non. GenLib n'est pas dans le fichier "kernel" d'UniOS...

>PpHd, a ce propos, (j'ai pas chercher des masses) il serait pas possible de puovoir ajouter/supprimer d'un ExePack des fichier directement de la calc ? sa serait [bien]
Non, ça n'est pas possible. La compression au format ExePack ne fonctionne pas on-calc... A moins que tu veuilles ne pas recompresser le fichier ExePack, mais je ne vois carrément pas l'intérêt...
Peut-être que tu parles d'une Pack Archive, le format "standard" propriétaire PreOS utilisé uniquement par PreOS dans les dernières versions... A ce moment-là, je ne peux pas te répondre...

Tiens pour continuer d'animer le débat :

godzil
a écrit :

Link a écrit :
C'est fait.

ici et là.

ou
Ici et là

>PpHd, a ce propos, (j'ai pas chercher des masses) il serait pas possible de puovoir ajouter/supprimer d'un PackArchive des fichier directement de la calc ? sa serait

Oui c'est possible. Mais seulement en compressant avec ziplib.
Plus d'infos avec zunpack, et zpack dispo dans Preos/src/pack/oncalc

godzil: c'est pas grave. Ca arrive à tout le monde de se tromper...
Je me suis douté que tu parlais des Pack Archives, car tu posais la question à PpHd, alors que ceux qui sont le plus en mesure de répondre, sont en principe Kevin et moi...

Il y a plusieurs raisons de ne pas faire de news sur CF:
* CF n'est qu'une bêta.
* C'est une bêta instable et bourrée de bogues.
* Elle est en mode kernel.
* Elle remplit la mémoire archive entière.

1- 95 % voire plus des jeux ds les archives 68k sont des BETAS
2- Elle est aussi stable que Ti-chess, je peux te le garantir : ayant utilisé les 2, g constaté qu'ils ont planté le mm nbre de fois (0), pour les bogues : on se demande pkoi il y a autant de releases pour les jeux comme TI-Chess huhu... (qui a dit bugs ? )
3- Et alors ? le kernel reste le moyen le plus efficace pour ecrire un jeu
4- Faux, j'avais encore la place pour mettre SMA

> 1- 95 % voire plus des jeux ds les archives 68k sont des BETAS
95% ça fait beaucoup, mais effectivement, une bonne partie des jeux dans les archives 68k est en bêta. Il y a un grand nombre de jeux kernel qui n'ont pas été finis, entre autres raisons à cause de la disparition de l'auteur sans qu'il laisse les sources...

> on se demande pkoi il y a autant de releases pour les jeux comme TI-Chess huhu...
Pas faux, il y avait effectivement des bugs graphiques dans toutes les versions antérieures... Mais chaque release n'est pas nécessairement une correction de bug, lis le fichier history.txt...

> 3- Et alors ? le kernel reste le moyen le plus efficace pour ecrire un jeu
Ton avis n'est pas partagé par tout le monde... Et, tu pourrais argumenter un peu ?

Que ce soit de la programmation de jeux ou d'apps, il est plus avantageux pour le programmeur de programmer KERNEL mais pas pour l'utilisateur non programmeur

sur Ti, pour ecrire un jeu rapide et puissant, le seul moyen c le kernel, je ne pense pas avoir besoin d'argumenter, vous devriez etre d'accord avec moi
par contre pour faire des jeux moins orientés rapidité et graphismes, ou pour un utilitaire, nostub est mieux adapté selon moi

Tu vas te faire taper dessus, Solid

pardon, les données viennent de changer en la faveur du kernel pour tous les jeux et utilitaire

> Tu vas te faire taper dessus, Solid
Et ce d'autant plus (pas de façon trop méchante cependant, c'est évident) qu'il donnera moins d'arguments et qu'il utilisera plus de formules du style "vous devriez être d'accord avec moi"... C'est valable aussi pour nEUrOne qui ne donne aucun argument...
Il n'y en a que très peu qui sont capables de donner des arguments corrects pour justifier ce que dit Solid. Soit Solid n'en fait pas partie, soit il ne se donne pas la peine de le faire, ce qui est une forme de mépris...

> utilitaire, nostub est mieux adapté selon moi
Rien de ce qui se fait en mode kernel n'est infaisable en _nostub; la réciproque est fausse...

> pardon, les données viennent de changer en la faveur du kernel pour tous les jeux et utilitaire
D'une, il n'y a pas d'arguments; de deux, je rappelle encore une fois que le kernel est utilisé par une minorité de gens, il est donc *bête* de faire un utilitaire sous kernel, alors que le but de cet utilitaire est d'être utilisé par un nombre de personnes aussi grand que possible...

En theorie le plus rapide entre kernel et nostub est le nostub
En pratique on voit pas la dif
Mais bon XPower

XDanger a écrit :
> pardon, les données viennent de changer en la faveur du kernel pour tous les jeux et utilitaire D'une, il n'y a pas d'arguments; de deux, je rappelle encore une fois que le kernel est utilisé par une minorité de gens, il est donc *bête* de faire un utilitaire sous kernel, alors que le but de cet utilitaire est d'être utilisé par un nombre de personnes aussi grand que possible...

De même il est inutile de faire des utilitaires sous Mac et Linux pour particuliers. Et pourquoi traduit-on des films en Français alors qu'après tout cette langue est minoritaire dans le monde
et tant qu'on y est, une minorité de gens roule dans des voitures de luxe, mais à la différence du kernel, tout le monde ne peut pas se payer une voiture de luxe

XDanger a écrit :
> Tu vas te faire taper dessus, Solid
Et ce d'autant plus (pas de façon trop méchante cependant, c'est évident) qu'il donnera moins d'arguments et qu'il utilisera plus de formules du style "vous devriez être d'accord avec moi"... C'est valable aussi pour nEUrOne qui ne donne aucun argument...
Il n'y en a que très peu qui sont capables de donner des arguments corrects pour justifier ce que dit Solid. Soit Solid n'en fait pas partie, soit il ne se donne pas la peine de le faire, ce qui est une forme de mépris...

heu moi j'aurais dis que ct la flemme ou le patron qui passait pas loin du bureau m'enfin ...
Alors, tu me demandes pkoi le kernel est le plus adapté pour faire des jeux puissants ?
genlib
non c vrai, g pas vraiment d'arguments techniquesmais il me semble que l'utilisation de libs dyna rend un jeu plus rapide et evite les "DLL" caca du nostub

> utilitaire, nostub est mieux adapté selon moi
Rien de ce qui se fait en mode kernel n'est infaisable en _nostub; la réciproque est fausse...

a ton tour d'argument tres cher monsieur parce que je suis pas du tout convaincu

> pardon, les données viennent de changer en la faveur du kernel pour tous les jeux et utilitaire D'une, il n'y a pas d'arguments; de deux, je rappelle encore une fois que le kernel est utilisé par une minorité de gens, il est donc *bête* de faire un utilitaire sous kernel, alors que le but de cet utilitaire est d'être utilisé par un nombre de personnes aussi grand que possible...

tigcclib.9xz

>Rien de ce qui se fait en mode kernel n'est infaisable en _nostub; la réciproque est fausse... a ton tour d'argument tres cher monsieur parce que je suis pas du tout convaincu

Xdanger a raison puisse qu'en effet un kernel est programmé en nostub En nostub tu peux ecrire un kernel qui te permet de faire tout ce que fait le kernel

>Rien de ce qui se fait en mode kernel n'est infaisable en _nostub; la réciproque est fausse...
Rien de ce qui se fait en C n'est infaisable en ASM ; la réciproque est fausse...
Rien de ce qui se fait en C++ n'est infaisable en C ; ...

Uther Lightbringer a compris en partie ce que je sous-entendais... Il y a aussi les TSRs qui utiliseraient une lib kernel (aucun intérêt...), qui sont infaisables. Et peut-être d'autres choses sont faisables en _nostub et pas en kernel...

>non c vrai, g pas vraiment d'arguments techniques
C'est ce que je demande...

> mais il me semble que l'utilisation de libs dyna rend un jeu plus rapide et evite les "DLL" caca du nostub
Il te semble que... Argumente !
Pour les "DLL" 'caca' du _nostub: les "DLL" _nostub ne sont pas des DLLs kernel. Le seul but des "DLL" _nostub est de dépasser la limite des 64 KO. C'est marqué dans la doc. On ne peut de plus pas charger plus d'un "DLL" _nostub à la fois, c'est fait exprès pour éviter des abus. Abus que ne se gênent pas de faire certains, qui ne sont même pas foutus de lire une doc, d'une parce qu'ils font le contraire de ce qui est écrit, de deux parce qu'ils ne sont pas foutus de recopier correctement un exemple et avec ça, ils râlent que le truc c'est de la merde et que l'exemple ne marche pas (TiMad a fait les deux)...

Kevin> chui pas paresseux, mon parti est déjà pris, c tt...

>> Ben alors je vais creer une lib dynamique ttpacklib
> Une très bonne idée
Mais n'importe quoi ! L'algorithme de ttpack ne marche pas tel quel sur une TI-68k ! Il nécessite 128 KO + 15*la taille du fichier d'entrée.
Par ailleurs, "ttpacklib" n'est pas un nom AMS valide...

Hé hé, je connais une version de TTPack qui nécessite 40 ko+2*la taille du fichier de sortie, soit grosso modo 40 ko+1*la taille du fichier d'entrée Il compresse quasiment aussi bien que TTPack, et la compression est plutôt rapide (2x plus lent que ziplib pour la compression, rien à voir avec runcc)

Et n'allez pas me taxer encore de vaporware, il n'est pas tout à fait fini

C'est très bien. J'attends de voir une bêta publique...

> 40 ko+2*la taille du fichier de sortie, soit grosso modo 40 ko+1*la taille du fichier d'entrée
C'est pas tout à fait pareil, tout de même... Je croyais que tu étais en prépa ?

He bien c'est les vacances et on aura peut-etre GTC sous 15 jours!