1

J'ai besoin de compresser/décompresser des données on-calc. J'ai regardé shrnklib, mais ça ne compresse pas on-calc visiblement. Il ne reste donc que ziplib (sachant que vu son header, on ne parlera pas de hufflib) ?

2

Il y a aussi XPak de Pollux, une version de pucrunch/ttpack modifiée pour réduire la consommation mémoire lors de la compression qui est donc utilisable on-calc. Je pense que ça donnera des résultats nettement plus satisfaisants que ziplib.

!call Pollux
--- Call : Pollux appelé(e) sur ce topic ...
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

3

Merci Kevin.
C'est dynamique ou statique ? Sous quelle license ? Merci d'avance. smile

4

Pollux il est où ton site ? cry google fait le cachotier c'est point drôle ...

5

C'est un programme plutôt qu'une lib (il y a aussi une version statique pour le décompresseur, incluse dans GTC)... J'avais aussi le projet de faire une interface pour le compresseur sous forme de lib statique.

http://membres.lycos.fr/ltech/

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

6

Ah merci pour l'adresse de ton site, que j'ai pas trouvé avec google happy

7

Pollux, tu confirmes ça :
Memory requirements for compression: about 50 kb temporary RAM, plus a bit less than twice the packed size.
J'appelle pas ça "réduire la conso mémoire lors de la comperssion, ou alors ça reste super gourmand à mes yeux grin

8

Flanker a fait une lib/programme de décompression, voir "Compress" à http://19pouces.net/TI68k.html .
une lib qui décompresse n'importe quel format. En fait, c'est un wrapper « universel » qui détecte le format de compression (acf, filb, lzfo, pepzip, ppg, xpak, ziplib) et qui se charge d'appeler la bonne lib. Et pour que ça soit plus marrant, c'est une lib kernel, mais qui peut aussi se lancer comme un programme nostub (si aucun kernel n'est installé) ^^



[EDIT: par rapport à ttpack qui nécessite environ 128 KB + 15 * size of input, si, c'est une consommation mémoire réduite grin]
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

9

Ouep, mais ça rentre pas dans ce que je cherche, vu que je ne compte décompresser que ce que j'aurai compressé (format d'archive perso). Et puis au niveau de sa license, je crois pas que ce soit de la GPL.

10

Parmi les libs gérées par Compress, il doit bien y en avoir qui sont GPL wink
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

11

Folco (./7) :
Pollux, tu confirmes ça :
Memory requirements for compression: about 50 kb temporary RAM, plus a bit less than twice the packed size.
J'appelle pas ça "réduire la conso mémoire lors de la comperssion, ou alors ça reste super gourmand à mes yeux grin

Ah ben oui c'est gourmand (le format est optimisé pour le taux de compression et la vitesse de décompression), ce que Kevin disait c'est que la version PC dérivée de pucrunch est infiniment pire...

Exactement comme GTC : c'est plus gourmand et lent à compiler qu'un langage interprété simple, mais c'est plus rapide à l'exécution, et ça reste beaucoup moins gourmand que GCC.

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

12

13

Ok. L'API de ziplib me plait pas du tout en fait, je ne ferai avec que si je ne trouve que pire.

LZFO1 a l'air bien foutu, à utiliser avec pedrom__system par contre, parce que c'est un programme qui n'offre pas d'API aux programmes. Je regarde PpeZip maintenant.

14

PpHd -> quid de l'utilisation de la RAM par Ziplib ? ZPack est aussi un front-end super simple visiblement. smile

15

Parmi ceux qui sont cités dans ce topic, ziplib est le pire algorithme en termes de taux de compression...

Mouarf, je viens de me rendre compte, en relisant le topic de LZFO1 dans la section Custom Beta Tests du forum de TIGCC/TICT (lien ci-dessus), vieux de cinq ans, qu'il contient un gros flame à propos de Pollux (que j'appelle "Mister Vaporware", c'était nettement plus vrai à l'époque que maintenant), XPak, TIGCC/GTC grin
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

16

Pour LZFO1, l'API, ça se crée, c'est sous GPL.

PepZip est dérivé de LHA, l'auteur qui a fait le portage dit avoir eu la permission de sortir ça sous GPL, mais je ne suis pas sûr si tout est en ordre, parce que LHA lui-même n'a jamais changé de licence et n'est pas inclus dans Fedora à cause de ça par exemple, et il y a au moins 2 auteurs de LHA, je ne suis pas sûr que l'auteur de PepZip a bien eu la permission de tous les auteurs de LHA pour un tel changement de licence.

Quant à XPak:
Folco (./9) :
Ouep, mais ça rentre pas dans ce que je cherche, vu que je ne compte décompresser que ce que j'aurai compressé (format d'archive perso).

L'intérêt n'est pas la compatibilité, mais le facteur de compression (lamentable pour ziplib).
Et puis au niveau de sa license, je crois pas que ce soit de la GPL.

Effectivement. sad pucrunch est maintenant sous LGPL (+ l'exception de wxWidgets (permission de linker statiquement dans un logiciel propriétaire sans donner un moyen de relinker) pour la routine de décompression), donc en principe rien n'empêcherait Pollux de sortir ses modifications sous LGPL aussi. Pollux, comptes-tu le faire? À mon avis, ça arrangerait tout le monde, ça rendra certainement XPak plus utilisé.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

17

Euh attends, j'ai pas compris un truc ? Au niveau de la license, je parlais de Complib de Flanker, malheureusement XPak ne m'intéresse pas on-calc à cause de la mémoire consommée...

18

Si tu veux une compression convenable, il faudra accepter une certaine consommation de mémoire. Je ne vois pas trop le problème, ça ne consomme pas plus de mémoire que par exemple un jeu comme TI-Chess, et je rappelle que c'est seulement pour la compression, pas la décompression. Le seul problème que je vois avec XPak est la licence (et l'absence de lib pour la compression, mais ça se corrigerait très vite si les sources étaient disponibles et sous une licence qui permet leur modification).

Quant à lib Compress de Flanker (apparemment renommée pour éviter d'usurper le nom de la CompLib de hibou, une lib statique compatible ziplib sous LGPL), je viens de vérifier, le lisezmoi dit que c'est sous LGPL, mais je ne sais pas si ça concerne aussi toutes les routines de (dé)compression incluses.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

19

Mais ça va bouffer 50 ko même pour en compresser 10 ?

edit -> on me souffle à l'oreille que la lib de Flanker serait sous LGPL. Désolé.

20

Le problème est qu'en fait c'est juste un wrapper autour des différentes libs, elle ne contient aucun code de compression/décompression elle même. À mon avis, tu ferais mieux de te fixer sur une seule lib et l'utiliser directement.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

21

Je pense aussi, Complib n'est pas faite pour l'usage que je vais avoir de la compression.

22

Ben pour comprendre tes besoins il faut savoir :
- quel type de données tu veux compresser (texte, exécutable, données binaires ?)
- à quel point c'est important d'avoir un bon taux de compression (est-ce que c'est grave si c'est 1% plus gros ? 5% plus gros ? 10% plus gros ?)
- combien de fois tu vas décompresser chaque fichier compressé
- s'il y a autant de pression sur la RAM à la compression qu'à la décompression

Kevin Kofler (./16) :
Effectivement. sad pucrunch est maintenant sous LGPL (+ l'exception de wxWidgets (permission de linker statiquement dans un logiciel propriétaire sans donner un moyen de relinker) pour la routine de décompression), donc en principe rien n'empêcherait Pollux de sortir ses modifications sous LGPL aussi. Pollux, comptes-tu le faire? À mon avis, ça arrangerait tout le monde, ça rendra certainement XPak plus utilisé.

De toute façon il n'y a pas une ligne de code de Pucrunch dans la version oncalc de XPak ^^ J'ai rien contre, mais il y a déjà un exécutable séparé qui fait office de lib dynamique, et qui évite de dupliquer 50x un code de 5 ko. Et comme toujours c'est du boulot de packager proprement donc j'évite à moins qu'il y ait des gens pour qui ça soit vraiment important d'avoir une lib statique de compression (vu l'activité débordante sur TI je me permets d'en douter).

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

23

Pollux (./22) :
- quel type de données tu veux compresser (texte, exécutable, données binaires ?)

Ca se rapproche de l'exécutable, même s'il y a en rab des pointeurs et divers trucs
- à quel point c'est important d'avoir un bon taux de compression (est-ce que c'est grave si c'est 1% plus gros ? 5% plus gros ? 10% plus gros ?)

Rein à foutre du pourcent, je suis même pas à 10% près, la compression est là "pour le principe", parce que c'est juste dommage de perdre de la place quand on peut éviter.
- combien de fois tu vas décompresser chaque fichier compressé

Juste une fois. Le temps CPU, c'est pas très très important.
- s'il y a autant de pression sur la RAM à la compression qu'à la décompression

Oui. Je dirais que c'est el point essentiel. Ca peut cartonner partout ailleurs, si ça prend de la place au run-time, j'en veux pas grin

Alors, ton verdict ? grin

24

Ben alors les compresseurs asymétriques classiques risquent pas de te convenir, ils sont conçus pour répondre exactement le contraire aux 3 dernières questions cheeky Ziplib devrait t'intéresser, même si c'est pas extraordinairement rapide et que la méthode est pas très efficace sur les programmes ^^ (i.e. c'est probable que tes utilisateurs préféreraient éviter de perdre 5 secondes pour gagner 5 ko sur 30 ko...)

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

25

Et je suppose que du RLE c'est pire que tout sur des binaires ? cheeky (je dis ça parce que je me suis jamais penché sur le moindre algo de compression, et que celui-ci parait simple grin)

Sinon, merci pour ta réponse. smile

26

Ziplib, c'est du Huffman (et seulement du Huffman, il n'y a aucun algorithme à portée plus globale, type LZ ou RLE, dedans, ce qui limite le facteur de compression).
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

27

./25: vu que RLE n'optimise que les octets consécutifs identiques, il est effectivement mauvais sur la plupart des binaires.
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

28

Ah mon sens la meilleur compression est le LZH (LZSS + Huffman) mais très gourmande en ressources (à cause de la recherche dans le dictionnaire). Si on veut un truc léger mais qui compresse dans tous les cas on prendra du Huffman. Enfin, on peut toujours avoir une méthode qui compresse et qui soit rapide (AFE (Adaptative Frequency Encoding) + RLE) ?
avatar
la Nature nous montre seulement la queue du lion. Mais je suis certain que le lion a qui elle appartient pense qu'il ne peut pas se révéler en une fois en raison de son immense taille.

- Fondateur de Ti-Gen -: http://www.tigen.org

- Membre du Groupe Orage Studio -: http://oragestudio.free.fr/

- Mon site perso -: http://tisofts.free.fr

Projets TI68K en cours:
GFA-Basic = http://www.tigen.org/gfabasic
Arkanoid.
PolySnd 3.0.

29

Je viens de lire tt vos article et j'avoue que pour moi c'est assez compliqué alors comment faire pour compressé des textes
......

30

Bonjour momo12345

Il me semble que le ziplib dont ils parlent (et pour cause je l'avais déjà installé auparavant sur ma calculette) est un fichier asm (assembleur), mais que tu ne pourras pas utiliser sans un utllitaire de type doorsos sur les anciennes calculatrices (hw1 ou hw2) . Par contre je ne sais pas si doorsos est obligatoire sur les calculatrices récentes (hardware hw3 ou hw4) .
Tu peux vérifier la version du hardware de ta calculatrice en tapant allant dans le menu F1 | About depuis le Home Screen (cad la fenêtre où tu tapes tes calculs) .

En espérant t'avoir aidé à y voir plus clair smile