compression2 - Page 2

mulder :
je ne vois pas uview en ppg dans ton lien :s
du moins dans ma calculette il n'y a pas marqué 'ppg' mais 'asm'...
-->est-ce parce que je telecharge le mauvais fichier de uview?

uview est déjà compressé, mais ce n'est pas un ppg puisque tu n'as pas besoin de lanceur spécial ^^

et sinon attention ticalc n'a pas la dernière version de uview, la dernière version est dans ma signature...

mulder :
l'idée de faire
flib("komp:repertoire_du_programme\nom_du_prog")
repertoire_du_programme\nom_du_prog()
flib("komp:repertoire_du_programme\nom_du_prog") c'est ok?

Oui oui ça fonctionne sinon. @pollux: lol psychokwack il est trop lent

ok pour l'autodécompression de uview.

a propos de ce programme :

lanceur(prog)
prgm
copyvar #prog,tmp
flib2("komp:tmp")
tmp()
delvar tmp
endprgm


il copie la variable, la décompresse, puis la supprime (d'apres ce que je comprends du basic en tout cas) c'est vraiment plus long que de décompresser, puis recompresser?



et vu que je maitrise pas trop le basic, on peut me dire comment modifier ce programme de telle sorte qu'il n'ait plus besoin d'argument ? (je voudrais en fait pouvoir l'utiliser avec un raccourci - kbdprgm )

Non non le plus long c'est la compression. Copier et supprimer c'est presque instantané.
Et ce lanceur la est valable pour n'importe quel programme: tu l'appelles comme ça lanceur("rep\nom").
Si tu fais une version sans argument, elle sera valable pour un seul programme (c'est peut-être ce que tu recherches) voila ce que tu peux faire:

lanceur() 
prgm 
copyvar nom\rep,tmp 
flib2("komp:tmp") 
tmp() 
delvar tmp 
endprgm

petite conclusion de tout ce sujet sur la compression : (confirmez que ce qui est ecrit est correct, svp)

1/ l'utilisation de la compression de flib n'est possible qu'avec du basic donc (pas avec du texte ni du asm,c) (et on est bien d'accord que komp est la meilleure compression qui existe pour basic?)

!!!!!!!!!!!!!!!!!! je viens de m'apercevoir d'un probleme majeur de flib (voir la ligne de programme post ./34) : d'habitude la ti 'enregistre' le programme dans sa memoire (me demander pas pourquoi, ni comment...) de telle sorte qu'elle n'ait pas besoin de le lire en entier avant de l'ouvrir (elle ne le lit en entier lors de sa premiere ouverture, a moins bien sur qu'il n'y ait un edit du programme en question) ... mais avec cette methode, la ti doit relire a chaque fois le nouveau programme, ce qui le rend tres tres long a ouvrir !!!!!!!!! (personne n'a une idée pour remedier a ce probleme?)



2/ en ce qui concerne les fichiers textes, on est bien d'accord que la meilleure compression est avec xpack, fourni dans uview

3/ en ce qui concerne les fichiers en C et ASM, on est bien d'accord que la meilleure compression s'effectue avec du ppg, et que le fichier ppg s'ouvre avec un lanceur de ppg, tel que superstart ou ttstart,et que la mise en ppg s'effectue avec ttppggen (je me le suis procuré et aimerais bien qu'on m'explique comment l'utiliser pour compresser en ppg un fichier asm,c)

note : par 'meilleure compression' j'entends un bon pourcentage de compression, tout en restant rapide à ouvrir (c'est a dire entre autre ne pas avoir a passer par un autre programme)


edit : et en ce qui concerne les fichiers asm qui sont en fait deja compresses (tels que uview) : y en a-t-il d'autres que uview, et si oui comment sont-ils reconnaissables

y a 'xpak' de pollux qui compresse mieux que 'flib'. Mais bon tu pourra toujours dire que ca fait un programme de trop.
C'est utilisable en basic. La decompression est quasi instantanee

comment sa marche exactement xpak : la compression, la décompression, et comment ouvrir un programme compressé en xpack avec une ligne de basic ; et est-ce que sa permet de ne pas avoir a lire a chaque fois le programme en entier (voir ./35)

et voir mes autres questions, et demandes de confirmations, du ./35

mulder :
petite conclusion de tout ce sujet sur la compression : (confirmez que ce qui est ecrit est correct, svp)

1/ l'utilisation de la compression de flib n'est possible qu'avec du basic donc (pas avec du texte ni du asm,c) (et on est bien d'accord que komp est la meilleure compression qui existe pour basic?)

!!!!!!!!!!!!!!!!!! je viens de m'apercevoir d'un probleme majeur de flib (voir la ligne de programme post ./34) : d'habitude la ti 'enregistre' le programme dans sa memoire (me demander pas pourquoi, ni comment...) de telle sorte qu'elle n'ait pas besoin de le lire en entier avant de l'ouvrir (elle ne le lit en entier lors de sa premiere ouverture, a moins bien sur qu'il n'y ait un edit du programme en question) ... mais avec cette methode, la ti doit relire a chaque fois le nouveau programme, ce qui le rend tres tres long a ouvrir !!!!!!!!! (personne n'a une idée pour remedier a ce probleme?)

Non tu peux compresser les basic en zip (zip de TI pas de PC), ...

Quand tu édites un programme Basic il est stoqué en texte, à la première exécution il est tokenisé (vérification des erreurs, transformation en codes binaires, ...) puis il est exécuté. Si tu compresses un programme non tokenisé dans une variable a à chaque fois que tu décompressera a dans b tu devra repasser par l'étape de tokenisation. La solution est donc d'exécuter une fois ton programme avant de le compresser. (il se passe la même chose si tu archives un programme avant de le tokeniser)

mulder
:comment sa marche exactement xpak : la compression, la décompression

Edit : cf post de pollux plus loin.

Quand tu édites un programme Basic il est stoqué en texte, à la première exécution il est tokenisé (vérification des erreurs, transformation en codes binaires, ...) puis il est exécuté. Si tu compresses un programme non tokenisé dans une variable a à chaque fois que tu décompressera a dans b tu devra repasser par l'étape de tokenisation. La solution est donc d'exécuter une fois ton programme avant de le compresser. (il se passe la même chose si tu archives un programme avant de le tokeniser)

ça explique tout...
je me disai qu'il metait vachement longtemps a trouver les erreur et que y'avait des difference de taille #enfincompris#

mulder
: comment sa marche exactement xpak : la compression, la décompression, et comment ouvrir un programme compressé en xpack avec une ligne de basic

Je viens d'uploader une nouvelle version (cf mon site dans ma signature), il suffit de faire xpak("fichier") pour le compresser ou le décompresser (ça marche aussi avec les répertoires).

Cela dit, si tu veux compresser des programmes asm, ça ne sera pas plus facile à utiliser que les autres programmes de compression puisqu'il faudra aussi un lanceur externe...

[HorsSujet]

XPak has fully been written in C language on my calculator, thanks to the soon-to-be-released
GTC embedded compiler, and much of the performance-critical code has been rewritten in assembly for optimal performance.

[/HorsSujet]

[HS] bah quoi, il est publiquement disponible à une URL pas très dure à deviner et protégée par aucun mot de passe, on peut presque dire qu'il est releasé [/HS]

Pollux
:

mulder
:comment sa marche exactement xpak : la compression, la décompression, et comment ouvrir un programme compressé en xpack avec une ligne de basic

Je viens d'uploader une nouvelle version (cf mon site dans ma signature), il suffit de faire xpak("fichier") pour le compresser ou le décompresser (ça marche aussi avec les répertoires).

Cela dit, si tu veux compresser des programmes asm, ça ne sera pas plus facile à utiliser que les autres programmes de compression puisqu'il faudra aussi un lanceur externe...

et donc un lanceur externe c'est un programme du type superstart?

et c'est quoi le meilleur taux de compression entre xpack et ppg?


et donc si la compression en xpack est meilleure que celle en flib, proposez un programme en basic qui permette d'ouvrir un programme ecrit en basic.
(que pensez vous de :

1/compresser le programme avec
xpak("repertoire_du_programme\nom_du_programme")
dans home puis :
2/ kbdprgm1()
prgm
copievar repertoire_du_programme\nom_du_programme,H
xpak("h")
h()
supvar h
effes
affecran
endprgm



et confirmez svp les autres assertions proposées dans le post ./35

pour le 2/ ta pas besoin de effes et de affecran
sinon c bon, le ./35 aussi

[quote] et c'est quoi le meilleur taux de compression entre xpack et ppg? [\quote]

c'est le même principe, le format xpack peut être aussi bien compressé que ppg, mais le compresseur on-calc ne peut pas garder autant de choses en RAM donc il compresse un peu moins bien que ppg ^^

(cela dit ça serait possible de compresser sur PC pour avoir un taux équivalent à celui de ppg)

"(cela dit ça serait possible de compresser sur PC pour avoir un taux équivalent à celui de ppg) "

comment?


et n'est-il pas possible de se procurer uview sans xpak, dans le cas ou on veut avoir le programme xpak disponible separement, de telle sorte qu'il puisse compresser a la fois textes et progs, sans les avoir en double?

et on est bien d'accord que xpak sa compresse aussi c et asm, dans le cas ou on a un lanceur de type superstart?

mulder :
"(cela dit ça serait possible de compresser sur PC pour avoir un taux équivalent à celui de ppg) "
comment?

Pour ça il faudrait que je sorte une version PC ^^ (tous les algorithmes ont une version PC qui marche, mais il faudrait que je fasse un package propre pour que ça soit pratique à utiliser sans avoir à se servir de ttstrip/ttbin2oth en plus)

et n'est-il pas possible de se procurer uview sans xpak, dans le cas ou on veut avoir le programme xpak disponible separement, de telle sorte qu'il puisse compresser a la fois textes et progs, sans les avoir en double?

Oui, c'est la version "Light" d'uview...

et on est bien d'accord que xpak sa compresse aussi c et asm, dans le cas ou on a un lanceur de type superstart?

Ca m'étonnerait que superstart gère le xpak ^^

ttstart le gere?

ce sont des lanceurs de ppg et en plus recomprimer des formats deja comprimé tu va pas gagner grand chose et tu vas perdre en vitesse