Preos 0.64 - Page 1

Une question : [sondage=13214]

a savoir, dans la ligne de commande, dans les programmes assembleurs necessitant des fichiers, que la decompression se fasse en temps reel, "derriere" le dos du programme.

Je ne sais pas si je serais capable de le faire de facon tres stable...
J'ai deja reussi un truc, mais ca fait planter tictex au demarrage

Autre chose: correction de bugs (Les programmes asm archives de taille sup a la RAM ne font plus planter la calc - correction de 3 bugs dans genlib) .

Je ne comprends pas tout à fait ta question...
Tu veux faire quoi-là? Des packs archives pouvant contenir des fichiers de données externes?

j'ai pas vraiment tout pigé non plus

pr les bugs, c des bons points
mais le pr pack... tu peux filer + de détails ?

Tu mets tes fichiers textes, tes progs basics, tes expressions, tes machins trucs, tu les mets dans une Pack Archive.
Et lorsque le systeme en aa besoin il le decompresse et l'utilise de maniere transparente (que ca soit sous ams ou dans les progs asm).

Tu sais comment décompresser un fichier en temps réél quand AMS en a besoin??? Tu fais comment?

si tu réussi à l'implémenter, ce serai pratique
(en plus, je n'utilise pas tictex )

Moi si...
Et je ne pense vraiment pas que l'implémentation d'une fonctionnalité qui fait planter TICT Explorer soit une bonne idée. À moins que le problème ne soit dans le TICT Explorer et ne puisse être corrigé dans celui-ci. Mais je n'ai pas l'impression que ce soit le cas d'après la description (courte, certes ) du problème de la part de PpHd.

PpHd>Désolé j'ai voté comme un con, avant que tu ne postes ta réponse (la démocratie est morte)
Mais quand tu parles de l'appeler depuis AMS, tu veux dire qu'on pourra aussi s'en servir dans un prog Basic? (qui ne passe que par AMS)
Si c'est le cas, tu peux retirer un non et rajouter un oui!

ben, au pire, tu met cette fonctionnalité dans une version que tu ne compile pas toi-même...
(sous forme d'option de compilation, de la même façon que certains trucs existant)

=> pr avoir cette fonctionnalité, il faudra compiler soi-même PreOS...
et pr savoir quelles options de comp changer, il faut lire la doc...
ainsi, tu précise dans la doc que ça peut planter si on le fait...

Oui, dans les programmes basics, sans aucun probleme.
Meme afficher des PICS en les decompresant en temps reel.

Le truc est simple : address error interceptee.
Je rajoute un folder avec une adresse corrompue...
Puis dans le handler de l'error, je teste l'adresse et j'agis en consequence en la corrigeant en temps reel. Si c dans SYmfindPtr, je decompresses le fichier et l'ajoute dans la VAT.

Avec tictex et son pb address errror handler, ca marche pas evidemment
Le gros pb est QUAND se debarrasser du fichier.

Enfin bon voila.

PpHd a écrit :
Le truc est simple : address error interceptee. Je rajoute un folder avec une adresse corrompue...

Beurk! J'ai voté "non".

erf, c'est violent, mais j'aimerais bien voir ça

Mais décompresser en plein milieu d'une rom call et modifier la VAT, ça ne peut pas rendre des pointeurs invalides, ou des trucs comme ça ?

à mon avis squale92, ta technique n'est pas bonne, parce que pas grand monde à part quelques programeurs vont s'amuser à recompiler preos pour rajouter cette fonctionnalité.

Tant mieux, comme ça au moins, ceux qui utiliseront cette fonctionnalité seront ceux qui savent que ce n'est pas stable.

Extended / Kevin: Je n'ai jamais dit que c'etait stable, mon truc ! Je voulais le faire, c'est tout. Et en plus, ca marche pas sous Vti, alors, bof quoi.

santi> justement !
C'est que pour que les utilisateur sachent ce qu'ils risquent en agissant ainsi !
ils seront forcé de lire la doc s'ils veulent recompiler...
(du moins, pr savoir quels flags activer)

ExtendeD a écrit :
erf, c'est violent, mais j'aimerais bien voir ça

oué moi zaussi :]

Au fait, nouveaute de preos 0.64 : shrnklib est integre a stdlib (Et bien + encore puisque les datra peuvent etre integres au fichier sans surcout de memoire)

Nouveaute: Les pack Archives ont desormais un commentaire et une icone !

S'il te plaît, donne une explication du format à Thomas Nussbaumer pour qu'il puisse afficher le commentaire dans TICTEX.

Heu, arg. Mais. Si tu veux je peux t'expliquer pourquoi c'est (presque) impossible.
Tu sais que les Pack Archive ont une table de symboles integres. Or les commentaires sont accessibles en recherchant le symbol 'comment' dans cette table.
Ensuite une fois qu'on a trouve le symbole :
+ Soit il est stockee non compressee (Nouveaute de Preos 0.64), dans ce cas c ok.
+ Sinon il est compressee : faut rechercher la library de compression, le decompresser, et le supprimer.
dans tous les cas, un appel a kernel__ExtractFileFromPack(Handle, "comment")
Marche Mais en nostub, c'est presque impossible de le recuperer alors...

NOTE: Je suis en train de refaire le code de gestion des kernels dans tictex pour que ca soit correct. Je coderais le cas particulier ou on peut le faire en nostub dans les modifications que je vais faire.

Tu ne peux pas mettre kernel__ExtractFileFromPack dans la table des vecteurs?

Tu crois que ca vaut le coup ? Faut que je reflechisse au mieux.

Au fait: pourquoi ne pas faire en sorte qu'il y ait toujours une copie non-compressée du commentaire? Parce que devoir attendre une décompression à chaque fois juste pour lire un commentaire est lourd...

encore une bonne nouvelle
(notament, pr shrnklib intégrée à stdlib)

Kevin, c'est pour cette raison que je pense que le lire a la main devrait tres bien marcher. Decompresser pour chaque commentaire c lourd... Donc voila. Et puis exporter une fonction peut faire planter tictex.
J'ai corrige un grave pb a Preos 0.64 et j'ai ajoute qqs trucs pour arranger la gestion de la RAM.

Nouveaute: Les pack Archives ont desormais un commentaire et une icone !

une icone: a quel format?

Fichier Bitmap classique.

Noveau format en cours pour les progs kernels auto-installant, compatibles Tictex et sans le pb des 8/24Ko limite.

Y'a pas de taille standard pour ces images? Parce que si c'est le cas ca risque de devenir peu utile.