compression... - Page 3

par contre, est-ce qu'à votre avis ça serait utile pour la compression ?

non, je ne crois pas.
J'avais une idée de faire un format custom pour hibView de fichier préparsé dans lequel il y aurait plusieurs blocs de données compressées, et donc j'utiliserais des fonctions de bas niveau de compression. Mais étant donné que ce serait spécifique, j'aurais sûrement une préférence sur un algo de compression, et donc je me brancherais directement sur l'API de l'algo en question.

compress::compress  equ  compress@0000 ;short value = compress::compress(const char *file, long compress_type); compress::extract equ compress@0001 ;short value = compress::extract(const char *file); compress::isCompressed equ compress@0002 ;long value = compress::isCompressed(const char *file, ); compress::extractHandle equ compress@0003 ;long value = compress::extractHandle(HANDLE handle); compress::setDefaultCompression equ compress@0004 ;short value = compress::setDefaultCompression(long compress_type); compress:getDefaultCompression equ compress@0005 ;long value = compress::getDefaultCompression(void); compress::getSize equ compress@0006 ;long value = compress::getSize(HANDLE handle); compress::getType equ compress@0007 ;long value = compress::getType(HANDLE handle); compress_fail equ -1 compress_default equ 0 compress_not_compressed equ 0 compress_ZIP equ 'ZIP' compress_XPAK equ 'XPAK' compress_KOMP equ 'KOMP' compress_ppg equ 'ppg' compress_PEP equ 'PEP' compress_LZFO equ 'LZFO'

ça irait comme prototypes ?

Faudrait songer à écrire du C correct quand même
Est-ce que c'est possible d'exporter des variables dans une lib kernel (il me semble que oui) ? Ce serait plus simple pour gérer la compression par défaut...

oué, je sais, c'est pas le header C, c'est plutôt du pseudocode un peu plus explicite que l'asm

la compression par défaut ne sera pas une variable mais une valeur écrite dans un fichier de conf

Ah oui c'est vrai.

getType reverrai quoi comme type ? le type de compression ? le type de la variable compressée ?
Ce qui serait top, c'est les deux. Moi j'ai fait ça :

unsigned short h_getFileType(unsigned char * data) {
  unsigned short size = *(unsigned short *)data;
  short type = data[size + 1];
  if (type == OTH_TAG) {
    if (strcmp(&(data[size - 4]), "LZFO") == 0) {
      return LZFO_TAG + h_getLzfoTag(data);
    } else if (strcmp(&(data[size - 3]), "ZIP") == 0) {
      return ZIP_TAG + h_getZippedTag(data);
    }
  }
  return type;
}

#define h_getZippedTag(data) h_filelib2tiosTable[data[2]]

#define h_getLzfoTag(data) data[4]

#define h_getCompTag(tag) (tag&0xFF00)

#define h_getRealTag(tag) (tag&0x00FF)

#define ZIP_TAG     0x0100
#define LZFO_TAG    0x0200

unsigned char h_filelib2tiosTable[15] = {
  ASM_TAG,
  OTH_TAG,
  FUNC_TAG,
  FUNC_TAG,
  MATRIX_TAG,
  LIST_TAG,
  MAC_TAG,
  TEXT_TAG,
  STR_TAG,
  DATA_TAG,
  FIG_TAG,
  PIC_TAG,
  GDB_TAG,
  EXPR_TAG,
  OTH_TAG
};

c'est compress::isCompressed equ compress@0002
;long value = compress::isCompressed(const char *file, );
qui renverrait le type de compression si c'est compressé

il me faut un long pour le type de compression (qui est la signature)
et au moins 2o pour le type, vu que je renvoie le type utilisé par userlib (qui spécifie si c'est un asm nostub, un asm kernel, une lib)

euh pour XPAK par exemple il n'y a pour l'instant que le type de donnée TIOS qui soit fourni dans les métadonnées ^^ (et aussi la chaîne correspondant au type pour les OTH)

Pollux :
euh pour XPAK par exemple il n'y a pour l'instant que le type de donnée TIOS qui soit fourni dans les métadonnées ^^ (et aussi la chaîne correspondant au type pour les OTH)

edit : mal compris

y a la taille aussi ?

Godzil > j'ai édité ^^

oui il y a aussi la taille

et on récupère comment ces infos-là ?

c'est le champ upksize de XPAK_HDR, mais xupak.h n'est pas dans la distrib de xpak puisque j'ai pas encore fait les headers tigcc ^^ (pour la version gtc ça fait partie des headers standard)
donc en fait c'est le mot qui se situe 4 octets après la signature magique 'GTPk'...


pour le type de données :

  // *p==OTH_TAG
  p--;
  while (*--p);
  while (*--p);
  type = *--p;

> 1. LibsExec peut conduire à un HeapCompress, non ? Et du coup, le SymPtr va être complètement invalide ?
Oue, c'est vrai.
Mais on peut se debrouiller en lockant ce qu'il faut. A toi de voir.

>2. Moué, je vais ptêt mettre un place un système de code d'erreur
>ok pour le pointeur nul (je pensais que le numéro de version suffisait)
Dans un monde gentil, oui.
Dans un monde mechant, non.

Pollux > merci

PpHd :
> 1. LibsExec peut conduire à un HeapCompress, non ? Et du coup, le SymPtr va être complètement invalide ?
Oue, c'est vrai.
Mais on peut se debrouiller en lockant ce qu'il faut. A toi de voir.

je n'aime pas locker la table sans raison, d'autant plus que je préfère avoir un code le plus générique ,possible ^^
(mais je vais y réfléchir quand même )

>2. Moué, je vais ptêt mettre un place un système de code d'erreur
>ok pour le pointeur nul (je pensais que le numéro de version suffisait)
Dans un monde gentil, oui.
Dans un monde mechant, non.

ayé, c'est corrigé

Heiiiinnn ?? on est dans un monde méchant ?

Flanker :
il me faut un long pour le type de compression (qui est la signature)
et au moins 2o pour le type, vu que je renvoie le type utilisé par userlib (qui spécifie si c'est un asm nostub, un asm kernel, une lib)

au fait, c'est quoi l'utilité des types de userlib, pourquoi pas utiliser tout simplement ceux du Ti-OS ? Ce serait quand même bien plus simple non ?

parce qu'ils sont plus précis pour certaines choses ils distinguent nostub/kernel/lib et programme et fonctions
par contre, le type n'est pas donné pour les OTH

Flanker :
par contre, le type n'est pas donné pour les OTH

Pour ça passe par AMS, c'est quelques lignes de code.

ExtendeD
:

Flanker :
par contre, le type n'est pas donné pour les OTH

Pour ça passe par AMS, c'est quelques lignes de code.

pour les fichiers compressés ?

ayé, j'ai rajouté le code pour chercher dans le fichier de conf la compression par défaut.
y a pas à dire, ça poutre d'avoir juste à copier-coller 12 lignes de code pour gérer ça

Flanker :
parce qu'ils sont plus précis pour certaines choses ils distinguent nostub/kernel/lib et programme et fonctions

mais si mes souvenirs sont bons, tous les types Ti-OS ne sont pas supportés...
rah, si ca tenait qu'à moi, je casserais la compatibilité ascendante de userlib...
ou alors faire deux fonctions différentes ?

Flanker
:

ExtendeD
:

Flanker :
par contre, le type n'est pas donné pour les OTH

Pour ça passe par AMS, c'est quelques lignes de code.

pour les fichiers compressés ?

ce qui est sûr c'est que dans les fichiers compressés par ziplib, elle y est pas l'info

hibou
:

Flanker :
parce qu'ils sont plus précis pour certaines choses ils distinguent nostub/kernel/lib et programme et fonctions

mais si mes souvenirs sont bons, tous les types Ti-OS ne sont pas supportés...
rah, si ca tenait qu'à moi, je casserais la compatibilité ascendante de userlib...
ou alors faire deux fonctions différentes ?

en fait, à l'origne je pensais renvoyer uniquement l'octet tios et le type userlib (et pas les types étendus OTH)
du coup, avec un long, c'était bien, en partie haute le type userlib, en partie basse l'octet TIOS. Si tu n'as pas besoin du type userlib, tu castes le long en char

ptêt rajouter un pointeur dans les arguments, pointeur qui serait rempli par "PRGM", "FUNC", etc....

j'ai toujours ce problème pour le type d'une variable
1) je pourrais renvoyer uniquement l'octet TIOS et userlib sur un long. Pour les types perso, ça limite à renvoyer 248
2) je pourais également renvoyer le type sous forme de chaîne codée sur un long. Ca permet de renvoyer plus de détails sur les types perso mais j'ai deux autres problèmes :
-> si un type perso s'appelle ASM, on ne fera pas la différence avec un vrai ASM
-> en français, une fonction est de type FONC, et je renvie quoi ? FONC ou FUNC ?

du coup, je me demande si je ne vais pas renvoyer un pointeur vers une structure contenant les 4 infos

bon, en attendant je code le tout de toute façon, je ne fait qu'une fonction qui va calculer également la taille, après les appels de libs vont se résumer à 2 ou 3 lignes.

ss::BasicCommand(const char *command);

D'ailleurs, j'ai rajouté une fonction compress::BasicCommand equ compress@0008
;void compre

qui exécute une instruction basic. Ca coûte uniquement 4o, alors je me suis dit que ça pourrait toujours intéresser des gens ^^

et pourquoi pas 3 fonctions différentes ? car en général, tu n'en as besoin que d'une.
getTiOSVarType()
getUserlibVarType()
getOTHTag() qui reverrai NULL is indisponible, notemment pour les OTH dans les zip.

et ce serait quoi la 4ème au fait ?

ah oui, possible aussi de faire 3 fonctions différentes. Comme de toute façon, ça ne prend quasiment pas de place ... (4octets par fonctions)


la 4ème, ça sera la taille fu fichier d'origine ^^

humm, en fait, si j'utilise ta lib, je pense que je vais toutes les utiliser, donc bon... un structure ou des fonctions, c'est du pareil au même pour moi.
Cependant, si jamais y'a d'autre infos à rajouter, le coup des fonctions, c'est plus évolutif.

Flanker :
la 4ème, ça sera la taille fu fichier d'origine ^^

ca peut être utile ^^

ah non, y aura 5 fonctions en fait
getTiOSVarType() -> un octet (exemple : 243 = 0xF3 = ASM_TAG pour un ASM)
getUserlibVarType() -> un octet (compris entre 0 et 15 en fait)
getVarType() -> un long (représentant une chaîne de 4o, exemple "ASM" ou "FUNC")
getLocalVarType() -> la même, mais en localisé (exemple "FONC" en français)
getSize() -> la taille du fichier d'origine

et peut-être
getTrueSize() -> la taille du fichier compressé
getComp() -> le type de compression (déjà fait en fait)


si le fichier n'est pas compressé, ces fonctions marchent quand même