En voulant compresser simplement un programme avec Flib en fichier KOMP j'ai été surpris par la lenteur inhabituelle de compression.
Une fois fini mon programme compressé n'était pas un fichier KOMP mais EXPR de + de 53 Ko (alors que le programme de base pesait environ 3 Ko ...).
Je ne comprend pas ce qui s'est passé et je cherche surtout un moyen de récupérer mon programme original duquel je n'ai pas de sauvegarde et qui a vraiment beaucoup d'importance pour moi.
Merci beaucoup
Zeph Le 25/05/2008 à 20:17 sauvegarde le fichier sur ton pc et poste-le ici, peut-être que quelqu'un pourra t'aider à le récupérer
(évite les titres en majuscules, aussi)

All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez
par ici :)
Je le fais en moyenne toutes les 12 heures. je l'ai fait il n'y a pas longtemps juste avant de voir ces dossiers ...
Sinon, pas d'idée pour le fichier planté ?
Zeph Le 25/05/2008 à 20:39 ton fichier a l'air d'avoir le tag "KOMP" à la fin donc peut-être qu'il contient également les bonnes données compressées, mais du coup c'est pas évident à réparer (faudrait voir en éliminant tous les 255 à la fin du fichier et en rectifiant le tag de voir si flib arrive à en tirer quelque chose, mais j'en doute)

All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez
par ici :)
et si je dékomp le fichier, est-ce pus facile de le réparer ?
comment le réparer avec flib ? avec Setbyte !?!?
Sinon, Thibaut avait raison un reset Ram s'imposait car mon pC ne détectait même plus la machine ...
Zeph Le 25/05/2008 à 20:48 le décompresser ? tu n'avais pas dit que c'était un fichier "EXPR" (qui ne sera donc pas reconnu par flib, enfin peut-être qu'on peut forcer une décompression quand même, je ne connais pas le fonctionnement de flib)
le réparer avec setbyte ça va être encore plus chiant, je pensais plutôt à le réparer avec un éditeur hexa sur PC mais ça va pas forcément être sympa (ni possible d'ailleurs)

All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez
par ici :)
Voila ce qui s'est passé :
fichier : effects Type : PRGM Size : 3248 bytes (je crois)
Je compresse avec Flib, mais il plante et a la place d'un fichier Komp, j'obtient :
fichier : effects Type : EXPR Size : 53143 bytes
Je relance le processus de compression (en croyant le décompresser puisque c'est la même commande) et j'ai :
fichier : effects Type : KOMP Size : 10981 bytes
Zeph Le 25/05/2008 à 21:29 ça a l'air d'avoir correctement compressé ton fichier la 2eme fois, mais ça ne règle pas le pb : la compression a foiré au 1er coup et à moins de trouver un moyen de réparer le fichier, tu ne pourras pas récupérer tes données :/

All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez
par ici :)
je comprend.
Est-ce que flib est open source ... ?
sinon je peux refaire le prog tant que je l'ai en tête mais il est quand même assez difficile a programmer.
ok je regarde ca mais je connais pas trop les algo de comp donc ca risque d'etre chaud ^^
ibi0tux Le 25/05/2008 à 21:51Edité par ibi0tux le 25/05/2008 à 21:56
if (strncmp(str, "komp:", 5) == 0)
{
struct hArbre *arbre, *debut, *lecture;
unsigned char *tampon, *n2, *limite, *limite2;
short chemin[512];
short nbre1 = 0, nbre2 = 0, mode;
unsigned short val, longueur;
unsigned long bit = 0;
arbre = HeapDeref(handle = HeapAllocHigh(512 * sizeof(struct hArbre)));
str += 5;
nam = get_ptr(entry = get_entry(str));
if (nam != NULL && handle != H_NULL)
{
longueur = var_len(nam);
limite = nam + longueur - 1;
if (memcmp(limite - 5, "KOMP", 5) != 0)
{
if ((tampon = malloc(longueur + 250)) == NULL)
{
int_add(3);
goto Fini;
}
if (longueur < 17)
{
int_add(2);
goto Fini;
}
// HeapLock(*(unsigned short*)(tampon-2)) ;
*(unsigned short *)tampon = *(unsigned short *)nam;
tampon[2] = *limite;
memset(chemin, 0, 1024);
for (n = nam + 2; n < limite; n++)
chemin[*n]++;
for (i = 0; i < 256; i++)
{
val = chemin[i];
nbre1 += (val && val < 256);
nbre2 += (val >= 256);
}
mode = nbre2 != 0 ? 2 : 1;
if (nbre1 + 2 * nbre2 < 255 * mode)
mode = 0;
tampon[3] = mode;
n2 = tampon + 4;
if (mode)
{
for (i = 0; i < 256; i++)
{
val = chemin[i];
*n2++ = val;
if (mode == 2)
*n2++ = val >> 8;
}
}
else
{
*n2++ = nbre2;
*n2++ = nbre1;
for (i = 0; i < 256; i++)
{
if ((val = chemin[i]) > 255)
{
*n2++ = i;
*n2++ = chemin[i] >> 8;
*n2++ = val;
}
}
for (i = 0; i < 256; i++)
{
val = chemin[i];
if (val && val < 256)
{
*n2++ = i;
*n2++ = val;
}
}
}
arbre_to_tab(mk_arbre(arbre, tampon + 3), 0, 0, (unsigned long *)chemin);
j = 0;
limite2 = tampon + longueur - 10;
for (n = nam + 2; n < limite; n++)
{
bit += (unsigned long)(chemin[2 ** n + 1]) << j;
j += chemin[2 ** n];
while (j >= 8)
{
if (n2 >= limite2)
{
int_add(2);
goto Fini;
}
*n2++ = bit;
bit >>= 8;
j -= 8;
}
}
if (j > 0)
*n2++ = bit;
longueur = n2 - tampon;
nam = mk_perso_ptr(str, "KOMP", longueur + 9);
}
else
{
longueur = var_len(nam + 2) - 2;
if ((tampon = malloc(longueur)) == NULL)
{
int_add(3);
goto Fini;
}
// HeapLock(*(unsigned short*)(tampon-2)) ;
debut = mk_arbre(arbre, nam + 5);
n = nam + 6 + 256 * (nam[5] == 1) + 512 * (nam[5] == 2) + (3 * nam[6] + 2 * nam[7] + 2) * (nam[5] == 0);
n2 = tampon;
j = 0;
while (n2 - tampon < longueur - 1)
{
lecture = debut;
do
{
if (j == 0)
{
nbre1 = *n++;
j += 8;
}
val = nbre1 % 2;
nbre1 >>= 1;
j--;
if (val == 0)
lecture = lecture->gauche;
else
lecture = lecture->droite;
}
while (lecture->gauche != NULL || lecture->droite != NULL);
*n2++ = lecture->valeur;
}
*n2 = nam[4];
nam = mk_ptr(str, longueur + 2);
}
if (nam != NULL)
{
memcpy(nam, tampon, longueur);
int_add(0);
}
else
int_add(3);
Fini:
if (tampon != NULL)
free(tampon);
}
else
int_add(1);
HeapFree(handle);
}
Si quelqu'un peut m'aider ...
et on peut pas en sortir des strings, ou tenter une détokénisation, ou un truc comme ça?
Zeph Le 26/05/2008 à 11:25 détokénisation de quoi ? il faudrait déjà récupérer les données non compressées

All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez
par ici :)
Zeph Le 26/05/2008 à 11:33 bah oui, télécharge le fichier qu'il a posté : c'est supposé être un programme en basic (donc avec du texte à peu près lisibles à quelques caractères près), or ça ressemble plutôt à un fichier binaire (donc probablement compressé dans son cas); de plus on voit un footer "KOMP" vers la fin, même si il est mal placé.

All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez
par ici :)
Le fichier qu'il poste est le fichier corrompu (EXPR), compressé encore une fois avec KOMP (parce qu'il a voulu le décompresser et la logique de FLib, c'est "si fichier KOMP, décompresse, sinon compresse"). Si tu le décompresses avec FLib, tu as le EXPR, qui ne ressemble pas du tout à un fichier compressé valide et ne contient nulle part la chaîne "KOMP".
Zeph Le 26/05/2008 à 12:35Edité par Zephyr le 26/05/2008 à 12:38 [edit] j'ai compris ton post de travers, autant pour moi
par contre je suppose que c'est simplement le fichier compressé qu'il a posté, et non pas le fichier "compressé encore une fois"

All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez
par ici :)
Les 0xFF à la fin du fichier compressé sont le résultat de la compression d'une encore plus grosse quantité d'octets 0x05. C'est du Huffman, un caractère est codé en au moins 1 bit, donc si le code est 0b1, 0b11 ou 0b111 (ce qui est probable pour une telle probabilité d'occurrence), ça donne une quantité de 0xFF.
Zeph Le 26/05/2008 à 12:39 cross, cf édit; ceci dit ça ne règle pas la question : il faudrait réparer à la main le fichier corrompu pour avoir une chance de récupérer les données, et je pense que ça demande bien plus de travail que de recopier 3 petits ko de programme basic.

All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez
par ici :)
Zeph Le 26/05/2008 à 15:07 C'est possible, mais pour décompresser le fichier il faut remettre le tag à sa place (flib se base dessus pour déterminer si un fichier est compressé ou non), donc il faut savoir où est cette place, donc il faut voir dans le code source quelles sont les indications qui permettraient de voir où s'arrêtent les données compressées et où commencent les données corrompues. C'est peut-être faisable, mais il faut commencer par lire le code de flib... ce qui est difficile quand on code en basic.

All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez
par ici :)
Bon, je ne sais pas si tout cela vous donne des idées mais j'ai recommencé a faire le prog.