Compression - Page 1

Qu'y a-t-il d'autre pour compresser on-PC et décompresser on-calc que ttpack ? et y a-t-il mieux (par mieux, j'entends : qui compresse mieux, ou qui décompresse plus vite) ?

Autre question : telle qu'elle est distribuée, la fonction ttunpack_decompress est un gros tableau qui est casté en fonction. Alors déjà, est-ce que ça va marcher avec la nouvelle version de tigcc ? (c'est peut-être une question débile, mais je n'y connais pas grand-chose...)
Ensuite, même si ça marche, y a-t-il une bonne raison pour ne pas aller chercher la vraie source de la fonction (qui est disponible) et la compiler en même temps que le reste ? sachant que ça me permettrait a priori de la déclarer en static inline et de gagner à la fois de la place et du temps.

>pour compresser on-PC décompresser oncalc il y a shrinklib qui compresse généralement légerement mieux les données et légerement moins les programmes. A essayer pour comparer. shrnklib est une lib kernel. Elle est fournie avec PreOS

>Ce n'est pas vraiment débile. L'implémentation de ttunpack est une horreur. Je supose que ca a été fait comme ca pour une raison bien précise, mais si un problème ce pose ca complique le problème.

shrnklib est aussi bien plus rapide que ttpack pour decompresser.

OK, merci.
Pour la deuxième question, je vais aller la poser sur leur forum, c'est probablement plus simple...

(croisé)
./4 > Alors ça m'intéresse
Je vais voir... (le problème c'est que c'est pratiquement impossible de se rendre compte de la vitesse sous gtktiemu : tout est lent. Donc j'ai l'impression que les temps de décompression sont insupportables mais si ça se trouve ce n'est pas le cas sur une vraie TI...)

>c'est pratiquement impossible de se rendre compte de la vitesse sous gtktiemu :
Y'a aussi VTI qui me semble un peu moins lent

...mais ne tourne pas sous linux

quoi t'as réussi a compiler gtktiemu sous linux?
Ca va faire un an que j'essaie, j'ai jamais réussi

Ben, en fait, j'ai essayé pendant un an
Donc peut-être que tu vas bientôt réussir
Le tout est d'avoir les bonnes versions des bonnes bibliothèques, et je te recommande d'utiliser la dernière version dite "stable" et pas la dernière bêta (même si cette version "stable" ne l'est pas vraiment, elle n'a pas plus de bugs et elle est plus simple à compiler, il y a moins de dépendances dans tous les sens).
Si ça t'intéresse, je peux regarder exactement quelles versions de quoi j'ai.
J'ai peut-être modifié quelques-uns des fichiers source aussi, je ne sais plus trop bien mais je peux regarder aussi...

oui si tu pouvais me donner le numéro de version de Gtktiemu et de toutes les libs je t'en serais infiniment reconnaissant

OK je regarde ça ce soir.

Shadoko
: Autre question : telle qu'elle est distribuée, la fonction ttunpack_decompress est un gros tableau qui est casté en fonction. Alors déjà, est-ce que ça va marcher avec la nouvelle version de tigcc ? (c'est peut-être une question débile, mais je n'y connais pas grand-chose...)

Oui, sauf si tu veux créer une variable de données externe.

Ensuite, même si ça marche, y a-t-il une bonne raison pour ne pas aller chercher la vraie source de la fonction (qui est disponible) et la compiler en même temps que le reste ? sachant que ça me permettrait a priori de la déclarer en static inline et de gagner à la fois de la place et du temps.

Je ne sais pas, demande à Lionel.

Je ne sais pas, demande à Lionel.

C'est fait (sur le forum TICT).

Personnellement, j'ai compilé TiEmu 1.65 sous Linux sans trop de problèmes.

Ben, je l'ai compilé aussi, mais j'ai la nette impression qu'il n'apporte absolument rien par rapport à la version précédente, il faut encore plus de bibliothèques externes pour le faire marcher, et surtout il plante encore plus souvent me semble-t-il. Je ne vois donc pas l'intérêt, et je suis revenu à la version précédente.

Bon, donc j'ai gtktiemu version 1.53, compilé avec :
libticalcs-3.3.1
libticables-3.2.1
ces deux-là se trouvent sur http://sourceforge.net/projects/tilp . Il y a un ordre pour les compiler (l'une dépend de l'autre) mais je ne sais plus lequel.
Après il y a libti68k-1.4.2 qui elle est sur http://sourceforge.net/projects/gtktiemu .
Si jamais tu as déjà une installation de ces bibliothèques et que tu changes de version, je te recommande de d'abord renommer (voire virer) les répertoires /usr/include/tiemu et /usr/include/tilp.
Donc je sais que ça peut marcher avec cette combinaison de versions. Mais je ne sais plus si j'ai dû modifier des trucs dans les sources ; dis-moi si tu as un problème, ça me rappellera peut-être quelque chose.

Pour les autres bibliothèques, j'ai libSDL-1.2.3 (mais je pense que les versions ultérieures sont compatibles)
et glib/gdk/gtk 1.2.10 (là je crois que la version 2 n'est PAS compatible).
Et puis j'ai vu une dépendance sur jpeg 6b, mais c'est vraisemblablement la version que tu as.

Voilà.


Pour ce qui est de shrnklib, j'ai réussi (avec quelques difficultés) à compiler shrink92 (ce crétin dégénéré de gcc croyait que c'était du C++ sous prétexte que le nom du fichier était en majuscules et me donnait des messages d'erreur aussi explicites que « Undefined reference to la-fonction-qu'est-juste-sous-son-nez-on-voit-qu'elle » )
et la compression est légèrement meilleure qu'avec ttpack. Ça vient probablement en bonne partie du fait qu'il partage une table entre les différents fichiers de l'archive (il y en a 16).
Donc si en plus la décompression est vraiment plus rapide, je pense que ça justifie que je fasse une version kernel, surtout que ça n'a pas l'air très difficile. (Je précise que je maintiens de toute façon la version _nostub).

Ah oui, une question : il faut lancer ttbin2oth sur le résultat de shrink92 pour obtenir une variable TI, c'est bien ça ?

oui, ou tu fais import_binary (Cf doc de tigcc).

Je suis possesseur de la v200 et débutant en programmation ti Basique.

je me suis aperçu que dans quelques cas pour factoriser une expression du type 7x^2+5x-3 il fallait utiliser factor(expression,variable) en l' occurrence la variable x dans ce cas.
J' obtient avec la même syntaxe la forme factorisé que dans l' apps Home et cette fonction ne marche pas quand on demande son exécution à l' aide l' apps Program Editor.

Y a-t-il une alternative

Merci d' avance

login ti-rex et yAronet: flo200

Euh faut créer un topic parce que là c'est pas le sujet :\

Shadoko :
Pour ce qui est de shrnklib, j'ai réussi (avec quelques difficultés) à compiler shrink92 (ce crétin dégénéré de gcc croyait que c'était du C++ sous prétexte que le nom du fichier était en majuscules et me donnait des messages d'erreur aussi explicites que « Undefined reference to la-fonction-qu'est-juste-sous-son-nez-on-voit-qu'elle » )

-x c

et la compression est légèrement meilleure qu'avec ttpack.

?!
Dans mes tests, ttpack était la meilleure.

Ça vient probablement en bonne partie du fait qu'il partage une table entre les différents fichiers de l'archive (il y en a 16).

Ben, fais une archive solide avec ttpack. Regroupe d'abord, et compresse après.

Ah oui, une question : il faut lancer ttbin2oth sur le résultat de shrink92 pour obtenir une variable TI, c'est bien ça ?

Oui.

Faire des archives solides n'est pas forcement interressant. Ce que fait shrnklib est plus interressant lorsqu'il y a plusieurs fichiers de meme nature

Ben, fais une archive solide avec ttpack. Regroupe d'abord, et compresse après.

Mais si je fais ça je serai obligé de tout décompresser en RAM d'un coup, non ? c'est justement ce que je veux éviter (sinon je ne m'amuserais pas à découper mon fichier en blocs de 4k). Évidemment, la compression est meilleure si je ne découpe pas.
Euh, sinon, la différence n'est pas énorme et je n'ai testé que sur deux fichiers pour l'instant, peut-être que le cas était favorable à shrnklib, je ne sais pas. Mais ça a l'air au moins de valoir le coup d'essayer ; peut-être que je jetterai si c'est trop compliqué ou si ça n'apporte rien.

la difference n'a jamais ete enorme. Dans un sens ou dans l'autre.