internal error - Page 2

Kevin, PasteK-> Le code ASCII ne doit pas être en décimal (0=48), mais en Hexa (0=0x30), sinon vous m'expliquerez comment on fait la différence entre 25 et 255...
Mais c'est vrai que cela prend deux fois plus de place, j'ai moi-même utilisé ce format pour un prog en Basic , et une chaine pour une image de 152*48 prend plus de 8 écrans de programme sur TI-89... En plus en Basic c'est super lent
Pour économiser un peu en place, je serais plutot pour \0 et \ ...

Link :
Kevin, PasteK-> Le code ASCII ne doit pas être en décimal (0=48), mais en Hexa (0=0x30),

Ah oui, évidemment... Je n'avais pas vu que PasteK voulait mettre les codes en décimal.

je pense que c'etait aussi pour garder une compatibilité avec les versions antérieures de flib (car l'ancien format de mkpic aurait été incompatible avec le nouveau)

et puis si mkpic etait fiablen ca aurait pu permettre d'inclure toutes sortes de fichiers dans les progs basics (on ceer une pic qui contient le code d'autre chose, et on change l'extension apres), en plus ca aurait été tres propre )

pastek > hum, ou est le 3eme (que je te smashe )

link -> on NE remplace QUE les nombres par leurs code ascii (c'est à dire 0->48, ... 9->58), et c'est tout !
Sinon, cela prendrait beaucoup trop de place qu'avant et comme tu viens de le dire, on pourrait faire des confusions ...

azerty83 -> cherche, gros fainéant

et puis si mkpic etait fiablen ca aurait pu permettre d'inclure toutes sortes de fichiers dans les progs basics (on ceer une pic qui contient le code d'autre chose, et on change l'extension apres), en plus ca aurait été tres propre )

C'est si propre qu'on a déjà été amenés à utiliser ce genre de chose ...

bah, mais c'est pas fiable, donc -> poubelle comme dirait l'autre

azerty83 ->
Ben oui, mais là, tu viens de démolir la conversation !

Et puis d'abord, ma façon de coder les images est fiable à 100% et plus optimisée que celle de Kevin, tralalèreuh
(alors que mettre tous les codes en hexa, c'est pas très classe, c'est comme comparer un fichier asm et la chaine exec obtenue avec makeexec à partir de ce programme ...)

vertyos ->
Pour les vertel-users qui souhaiteraient utiliser les fonction (un)group et ginfo sans utiliser flib, j'ai fait un truc en basic que vous trouverez à cette adresse : http://membres.lycos.fr/ppcenter/
C'est un peu lent, car memcpy n'existe pas (encore) sur vertel ...

trop leet ta page
(et salaud tu as copié le nom de mon hypothétique site !!!)

mais tha methose, je ne vois pas trop comment elle marche et surtout pourquoi est ce qu'elle est fiable 100%

pour moi le plus simple c'est \0 et \ pour remplacer 0h00 et '\'

PasteK
: C'est un peu lent, car memcpy n'existe pas (encore) sur vertel ...

C'est à se demander à quoi servent les retours de liste internes vertel("v_read","source","/","e_retr","/","v_writ","dest",0,"#©")Je ne pense pas que ça soit si lent que ça
Mais bon c'est vrai que la fonction manque... Si j'avais le courage il faudrait que je release ce qui traine sur mon disque dur mais ça n'a pas été suffisement testé pour ça

Par contre pour komp, je suis désolé, ça prend trop de place... Pas de "mais bien sûr" qui tienne. A moins que tu arrive à me faire un module de compression en moins de 800 octets

oui, mais on peut pa scopier plus de 20ko nananere

Heu... Exact
Il faut le faire en 2 (ou même 3) fois, mais vu la taille des variable, ce n'est pas le découpage qui va prendre de la place dans ce cas là
Et puis faire un groupe de fichiers de 20000 octets (pas ko ) je ne vois pas trop l'interet (super le groupe de 3 fichiers )

mais ca reste vrai pour 20Mo

non, mais ca peu sans doute peut etre meme surement enfin faut voir mais le contraire m'ettonerai quand meme un petit peu servir pour autre chose

azerty83
: non, mais ca peu sans doute peut etre meme surement enfin faut voir mais le contraire m'ettonerai quand meme un petit peu servir pour autre chose

(après 3 relectures de la phrase)
heu... oui tu dois avoir raison

arg, "" il est encore là lui...


quoi, je ne suis pas clair ?
pas assez concis ?

PasteK :
C'est clair pour mkpic : c'est bizare que FL qu'il ait laissé passer une telle erreur ...
Il y a longtemps, j'avais eu une autre idée pour contourner le problème du mkpic : on remplace les chiffres par leurs valeurs en ascii : par exemple, 0 sera remplacé par 48, 1 par 49, etc . C'est la solution que je lui avais proposée à l'époque. Il a dit que ça prend trop de place.

Je ne comprend pas là! Après on ne pourra pas utliser le quatre, ni le huit, etc. Ca plantera encore plus.

Entre pepzip et flib il y a une TOUTE CH'TITE différence: pepzip prend 8 ko de code alors que le support complèt de flib prend 1.5 ko Et totu ça pour gagner pas grand chose (quoi que)

Finalement la différence est énorme. J'ai gagné 7 ko sur le zip des clex (25'842 au départ, 18'339 pour KOMP, 11'140 pour pepzip), donc ça vaut bien les 6.5 ko de plus que demande pepzip finalement Le mieux serait d'avoir la posibilité de faire une compression comme celle des ppg on-calc et pour tous les types (bien que pepzip soit même meilleur que celle-ci, en fait quasiment identique). Peut-être que ça prendra moins de place.

Brunni
: Je ne comprend pas là! Après on ne pourra pas utliser le quatre, ni le huit, etc. Ca plantera encore plus.

Nan t'as rien comprit Il parle de coder chaque caractère avec son code ascii. Le problème c'est que du coup chaque octet prendrait 2 octets. Chaque mkpic prendrait 2 fois plus de place qu'avec la méthode actuelle -> Même pas la peine d'y penser

Et pourquoi pas faire un format:
flib("mkpic:section=type:uncompressed_bitmap;section=header:subsection=size:160x100;section=data:11101101,10011100,... (etc.)")
hein?

Toi non plus, tu n'as rien compris, vertios ...
Voici un tableau qui explique comment je voulais coder en mkpic :

caractère -> ce que ça donne en mkpic
0 -> 00
1 -> char(1)
2 -> 02
3 -> char(3)
...
12 -> char(12)
13 -> 13
14 -> char(14)
...
47 -> char(47)
48 -> 48
49 -> 49
...
57 -> 57
58-> char(58)
...
255 -> char(255)

=> Le codage est fiable et seulement 13 caractères prennent 2 octets (les 242 autres prennent 1 octet) ...

C'est bon là, avez-vous compris ce que j'essaie d'expliquer depuis 2 ans ???
Si oui, vous serez les premiers à avoir compris ce codage (après moi, bien sûr )

Super malin sauf que 13 c'est char(59) puis char(je sais pas koi) bref ça porte à confusion. Il suffit de réserver un char spécial "d'échappement" (à recopier 2 fois pour l'écrire lui même), mais je te rassure t'as rien inventé c'est un procedé utilisé dans plein de trucs depuis un bon moment

ha, ok, j'ai compris
comme vertyos : pourquoi se faire chier ?
"\0" "\" et hop !

Vertyos ->
Ah, je suis impressionné !!!
En fait, je suis plus impressionné par ton raisonnement que par ton résultat, car char(59), c'est ";" sur ti89
S'il te plait, trouve moi d'autres contre-exemples foireux que je me marre un peu

PasteK: ca dépend des fichiers mais c'est vrai que généralement c'est un peu supérieur ...
Il existe des prorgammes permettants de zipper (le vrai format ZIP) on calc ... recherche un peu dans la partie software

PasteK :
S'il te plait, trouve moi d'autres contre-exemples foireux que je me marre un peu

Foireux ? Qui fait des propositions foireuses ici

La proposition de PasteK est parfaitement pertinente. Relis-la bien...

D'autant plus quelle est parfaitement exploitable.

Kevin Kofler
: La proposition de PasteK est parfaitement pertinente. Relis-la bien...

Dans ce cas là qu'est-ce que la proposition de caractère d'échappement a de foireux ?

Rien.

Bon donc voilà... "foireux" injustifié (faux qui plus est).

Il existe des prorgammes permettants de zipper (le vrai format ZIP) on calc ... recherche un peu dans la partie software

Quels sont-ils? Est-ce que "pepzip" est bien pour la compression? J'ai remarqué qu'il compressait LARGEMENT mieux que flib, cependant peut-être qu'il y en a d'autres qui sont encore meilleurs?