PowerZip est sorti. Votre Utilitaire de compression. - Page 2

Ca plante tout le temps avec Komp mm en ne zippant que des fichiers ASM.

Reste à voir comment hibou prendra ça... En tout cas voilà bien un exemple qui montre pourquoi je ne distribuerais jamais mes sources dans le zip, mais uniquement après demande pour me rappeller qui les as...

hibou est au courant

Ah... Et il lui a demandé avant ou il l'a prévenu après ?

demandé

ah ça va alors

mm ... pkoi ne pas prendre complib directement ?

Au fait, pourquoi tu utilises encore doorsos, flow ?

bon, je pense que je vais dev pour prog, histoire de le faire beta tester

si y'en a qui veulent ...

ha ok aussi
ceci etant dit si tu veux gagner plus de place fou tes fonctions dans le header

pourquoi ?

héhé essaye je suis sur que tu gagneras de la place (ca doit se compter en octet pas en Ko mais bon)

Bah explique pourquoi !

c'est de l'intuition, ca s'explique pas

en fait, une archive link comme des .c différent, et si tu utilises un header, tu n'as qu'un .c
et du fait de la compilation, un seul .c ca prend moins de place, y'a un liens qui prend qq octets en plus sinon ...

Utilisez Einstein, il peut aussi compresser des répertoires entiers, et il ne plante pas

Tu devrais adopter un algo compatible avec celui de ziplib dans ton einstein

J'aimerai beaucoup
... C'est le même algo !
Ce qui n'est pas pareil, c'est le format du fichier. Et puis probablement la convention 0/1 <-> fils droit/fils gauche.

Donc à quelques détails près, Einstein pourrait être compatible. Il me faudrait juste le format ZipLib et les conventions adoptées pour l'arbre.

Bah hibou a trouvé, lui, tu pourrais trouver aussi, non ?

Il a passé énormément de temps à le faire, j'ai pas envie de me prendre la tête comme lui pour si peu (à mes yeux).

Sinon, question pratique, tu stockes comment le "dictionnaire" (il me semble que ça s'appelle comme ça), c'st à dire la correspondance entre une certaine suite de bits et l'octet associé. Par ex : 0100 correspondrait à 'E'.
Tu fais comment ? Parce que ça doit prendre quelques octets

On stocke pas de dico. On stocke l'arbre. 1 neud = 1 bit. Comme il y a 512 neuds au maximum dans un arbre de Huffman, le stockage de l'arbre prend au max 512/8=64 octets. Il faut ajouter les octets correspondant aux feuilles à ça.

Je ne capte pas trop, comment tu le stoques, l'arbre ? Comment tu différencies une feuille d'un noeud ?

La flemme d'expliquer ce soir Samedi j'aurai finit le bac, je détaillerai la méthode si quelqu'un d'autre ne l'a pas fait entre temps

J'y pense : Flib est open-source. Si FL commente suffisament ses sources, tu devrais piger

OK, je vais voir

Les sources de Flib sont vraiment simple à comprendre mais j'avoue que sur cette partie de compression il faut avoir un cours avant de comprendre parce que les histoires d'arbres binaires... C'est difficile à comprendre quand on a jamais vus ça.
Flib c'est le premier programme en C que j'ai ouvert, maintenant que je comprend le code ça fait bizarre comparé à la première fois.

J'ai regardé un peu son code, mais il n'est pas beaucoup commenté.
Enfin, en y mettant de la bonne volonté, je comprendrai peut-être

La solution est tres simple:
#include <kernel.h>
Ca m'a pris 5 minutes d'implémenter la gestion des zip dans TIM. Pour enstein, t'as qu'a faire une version kernel compatible zip et une nostub qui gere que le komp ou même mieux une version mistub.