uView 1.0, XPak 1.0 - Page 1

Voilà, uView 1.0 et XPak 1.0 viennent de sortir

Vous pouvez les télécharger sur mon site...

excellent [:
cepdt, vaudrait mieux inclure la doc pour faire des txt si tu en as le droit pke sinon ca va faire chier du monde de devoir DL txtrider juste pour ça

Oui mais moi aussi ça me fait chier de downloader txtrider pour aller chercher cette doc
Bon, je vais voir si j'ai le courage d'aller sur ticalc.org/pub

LOL

erf j'ai mis un temps fou à le trouver parce que j'avais oublié qu'il était caché au fin fond du répertoire "kernel"

Tu m'envoies les sources du dé/compresseur on-calc pour que je change le format d'Einstein vers le tient ?
Si ça te pose pb de me passer le code, fait-moi une lib statique

#include <xupak.h> pour le décompresseur (si ptr est un pointeur vers le début du fichier - sans la taille -, tu fais XPAK_HDR *hdr=ptr, tu vérifies si le fichier est valide via xpak_ismagic(hdr), tu crées un buffer de taille hdr->upksize, puis tu lances Unpack(buffer,hdr) )

Pour le compresseur, je me demande s'il vaudrait pas mieux interfacer avec le programme de compression lui-même (il fait quand même 5 ko). Et, quitte à interfacer, autant passer les arguments via l'estack Mais c'est vrai qu'à ce moment-là il faudrait que je rajoute un mode "silent" pour ne pas afficher les informations de progression dans la status bar. Et je vais peut-être rajouter un "tag" pour être sûr qu'on appelle bien XPak et pas autre chose.

Fait chier mon format doit prendre dans les 5 ko aussi ! Donc pas de pb !

#hésitation#

Côté nostub de la force (lib statique) ou côté kernel ("lib" dynamique) ?

kerneeeeeellll

pour un shell, je dirait _nostub. Mais vu que ulib peut-être utiliser dans un jeu, je dirait kernel

kerneeeeeellll

J'ai pas dit "pour kernel", j'ai dit "côté kernel de la force" Ca veut dire que dans tous les cas ça sera _nostub, mais la version côté Kevin inclurait 5 ko de code dans chaque programme qui utilise la compression, tandis que la version côté Kernel utiliserait le programme de compression xpak() (qu'on peut utiliser en stand-alone) comme une lib dynamique (mais en _nostub). Je pense qd même que la 2è solution est meilleure. A la limite, je peux même faire en sorte que xpak() soit auto-extractible et comme ça on aurait à la fois le décompresseur et le compresseur dans un seul fichier En poussant encore le raisonnement, je pourrais même supprimer le stub d'auto-extraction pour utiliser le stub de xpak(), mais ça commence à devenir un peu lourd

kerneeeeeellll

bon sans rire, la solution du programme indépendant ( xpack() ) me parait bien plus judicieuse

Petite question pratique : comment on fait pour récupérer le type d'une variable compressée (j'arrive à récupérer la taille d'origine, mais j'ai la flemme de le faire pour le type) ?

tu décompresse, u récupère la taille avec Vertel et tu recompresse

Pollux>programme indépendant
(si g bien comprit, elle pourrais aussi être utilisable en basic, de cette manière ??)

Flanker> Les structures de type XPAK_HDR sont faites pour stocker des données compressées quelconques, donc on ne peut pas extraire ce genre d'infos d'un fichier PAK, mais seulement d'un fichier XPAK. Pour un XPAK, je devrais le rajouter dans le header, mais voilà en gros comment ça se passe :

 typedef struct {
   ESQ type;
   char zero;
   char title[];
 } ENCAPS;

 ENCAPS *GetEncaps(HANDLE h) {
   char *p=HeapDeref(h);
   p=p+2+*(unsigned int *)p-7;
   if (strcmp(p+1,"XPAK"))
     return 0;
   // p points to the zero...
   while (*--p);
   return (ENCAPS *)(p-1);
 }

(le nom Encaps va probablement changer )

Il faudrait d'ailleurs que je modifie xpak() pour générer un XPAK et pas un PAK par défaut (actuellement, xpak() génère un PAK, et il y a un programme qui le transforme en un XPAK).
Mac>

(si g bien comprit, elle pourrais aussi être utilisable en basic, de cette manière ??)

Oui, et c'est même déjà le cas

C'est nul la solution du programme indépendant. Ça rajoute une dépendance débile aux shells. Fais plutôt une librairie statique qui peut être intégrée dans le TICT Explorer.

Ça rajoute une dépendance débile aux shells.

Ca n'a rien de débile. tictex lui même a besoin de deux fichiers, alors pourquoi pas 3 pour ceux qui veulent pouvoir compresser on-calc?

Fais plutôt une librairie statique qui peut être intégrée dans le TICT Explorer.

Je ne vois pas le rapport entre le fait d'avoir besoin d'un fichier externe ou pas et l'intégration avec tictex. Dans les deux cas, ce serait juste une fonction de compression à appeler. Et puis vu son mainteneur actuel je pense que c même pas la peine de penser pouvoir laisser approcher un prog compilé avec GTC

[edit: réponse à Kevin bien sûr]
Oui en rajoutant 5Ko par programme, je propose même de rajouter une image 240*128*4nvg pendant la décompression (non compressée, forcément) pour prendre 7680 octets supplémentaires.

C'est nul la solution du programme indépendant. Ça rajoute une dépendance débile aux shells. Fais plutôt une librairie statique qui peut être intégrée dans le TICT Explorer.

C'est pas un shell, tictex ? Et je sais pas si la lib statique supprime tellement la dépendance aux shells...
Au contraire, un prog indépendant est plus pratique vu qu'il peut-être utilisé par les progs basic (ça vient de là, la compression KOMP). Et un shell peut très bien compresser par le biais de programmes indépendants (mieux, ça laisse la possibilité à l'utilisateur de choisir le type de compression si le shell gère plusieurs types de compression)

Nan mais laissez tomber, il a juste le cerveau tellement lobotomisé par le nostub qu'il n'a pas eu d'autre choix que de nous inventer que ZE best c'est de faire une lib statique...

Bon, j'ai uploadé ça sur ticalc. Il faudrait les spammer à mort pour mettre une niouze Des volontaires?

En qui serait-ce digne de news? Compression on-calc (sérieuse, pas ziplib )? PepZip et LZFO1 le font déjà. Clone de TextRider? Rien de très original non plus.

et asteroids c'est original peut être?

Euh... Bonne question.
Il y en avait déjà un en kernel et 2 en _nostub, donc en quoi un quatrième ou troisième selon le point de vue est-il digne d'une news?

Pkoi avoir fait une news pour PedroM dans ce cas, vu qu'il y a AMS
Pkoi avoir fait une news pour HW2TSR dans ce cas, vu qu'il y a HW2Patch

Il n'y a jamais eu de news pour h220xTSR sur ticalc.org. (Mais il y en a eu une sur tict.ticalc.org à l'époque, merci encore à Thomas Nussbaumer. tigcc.ticalc.org n'existait pas encore, sa création a été annoncée un mois plus tard sur tict.ticalc.org.)

un quatrième ou troisième selon le point de vue