[sondage=13242]
Comme je l'avais promis pour la sortie de TI-GCC 0.94, je compte faire une mise à jour de tous mes programmes pour TI.
Je viens de relire le code source de Flib pour apporter quelques améliorations, et j'ai remarqué que je pouvais améliorer la compression KOMP. Une question : est-ce que vous pensez que ça vaut le coup, sachant que je garderai bien sûr une compatibilité ascendante ? Je n'ai pas spécialement envie de me prendre pour Micro$oft dont les nouveaux formats ne sont jamais lisibles par les vieux programmes, mais avoir une compression qui est toujours meilleure que l'ancienne peut être vraiment intéressant non ?
guilc Le 28/12/2002 à 19:29 Oui, tant que l'algo est compatible avec l'ancien... Mais j'ai du mal a voir comment tu vas faire pour conserver la compatibilité en améliorant la compression...
Ben sur, mais flib va bien faire 24 ko après ca non?
Vark Le 28/12/2002 à 20:31 Vertel Suxxxxx !!!!!!!!! FLib PoWa !!!!!!!!!!!
*** Ne sous-estimez pas la puissance de la Marmotte ***
©
Marmotte Team : LaMarmotte, sBibi, Vark & sabrina
aze Le 28/12/2002 à 21:05Edité par Boo le 28/12/2002 à 21:07 bah, si c compatible, pourquoi pas
mais il faudrait aussi que tu ameliore le format de mkpic qui est foireux
en effet, si dans une image se trouve le mot 0h3030 cad "00" et ben flib va prendre ca pour un 0h00, ce qui corrompt l'image (et en meme temps ca empeche d'utiliser mkpic pour créer des var d'un autre type car là une erreur comme ca c bien plus grave...)
enfin par contre ca supprimerait toute compatibilité avec les anciennes versions
comme format tu pourais faire comme en C (il me semble) : remplacer les 0h00 par des 0h5C30 ("\0") et les 0h5c ("\") par 0h5c5c ("\"), et là ca ne poserait plus de probleme
Link Le 29/12/2002 à 00:28 Oué, les séquences d'échappement standard, ce serait mieux.
Maintenant j'ai la flemme de garder une signature à jour sur ce site. Je n'ai même plus ma chaîne Exec sous la main.
Quelques infos sur Flib 3.2 :
pas de changement majeur. J'aurai bien aimé réussir à gérer parfaitement les variables locales, mais j'ai pas réussi.
Pour KOMP, je ne vais bien sûr pas toucher à la compression elle-même qui fonctionne avec l'algorithme de Huffman, mais à la manière dont je stocke le dictionnaire. Aujourd'hui, la fréquence de chaque caractère peut être stockée de plusieurs manières, mais toujours sur un ou deux octects ; je vais maintenant l'enregistrer sur le nombre de bits minimal, je pourrai toujours lire les vieux fichiers en prenant 8 ou 16 comme nombre de bits, mais les anciennes versions de Flib ne pourront pas toujours lire les nouveaux fichiers. Je devrai m'en tirer avec 200 octets de plus, et comme mes optimisations m'ont permis de gagner pas mal de place...
Pour Mkpic, le problème n'arrive qu'une fois sur 2^16, je ne vais sûrement pas casser la compatibilité juste pour ça, il faudrait adapter tous les vieux codes sources !
Link Le 29/12/2002 à 16:21 Et si tu faisais deux modes?
Maintenant j'ai la flemme de garder une signature à jour sur ce site. Je n'ai même plus ma chaîne Exec sous la main.
Je v surement dire une conneris, mais je pense que tu devrait filer l'algo de compression le plus puissant à Bob (Vertyos), qu'il l'intègre à Vertel (qui est trés largement plus rapide que FLib, qui gère parfaitement les variables locales (et gère même les variable locals d'un autre programme que celui qui appelle Vertel) et qui supporte les listes en argument) et améliorer celui de FLib en gardant la compatibilité.
Membre fondateur de la Ligue Anti-MacIntoc
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Un expert est quelqu'un qui en sait de plus en plus sur de moins en moins
de choses, jusqu'à ce qu'il connaisse absolument tout à propos de rien.
bah vertyos peut surement faire un algo puissant lui même je pense ...
Zeph Le 01/01/2003 à 15:10 Oh mais il s'en dit des choses ici...
Jackiechan vient de me dire sur IRC qu'il a apprit un algo de compression huffman et qu'il peut me l'expliquer. Et puis je ne suis pas sûr que ce soit une bonne idée que FL me passe sa routine (en admettant qu'il veuille, bien sûr).
En tout cas la fonction de compression viendra grossir la librairie auxiliaire (jamais releasée) et non Vertel 2.00 que je veux maintenir en-dessous de 8000 octets (~7200 pour le moment).
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez
par ici :)
bah... je l'est saouler pas mal pour qu'il le mette, mais il est aussi anti-kenel que Kevin:]
Membre fondateur de la Ligue Anti-MacIntoc
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Un expert est quelqu'un qui en sait de plus en plus sur de moins en moins
de choses, jusqu'à ce qu'il connaisse absolument tout à propos de rien.
rah non, ce serait marrant de pouvoir ce servir de ziplib...
MacIntoc> si tu vuex, j'ai un programme qui fait ca ... mais bon, ca te fait un prog en plus a utiliser ... c pas fun
limmt Le 02/01/2003 à 17:59 C'est pour qnd flib v3.2?
Wenn ich morgen meinem Gott gegenübertrete, kann ich ihm sagen: "Ich bin unschuldig, ich hab' niemandem etwas getan - außer mir selben" Und das verzeiht er mir offentlich !
Falco - Hans Hölzel 1957 - 1998
RIP
