internal error - Page 1

j'aimerai savoir que sighifie exactement internal error merci a tous

Ca signifie que tu as essayé d'ouvrir avec l'éditeur de programmes (ou bien tu a fais F6 dessus) un programme basic qu'un petit idiot de lamerZ de trou du culZ de djeunz a "protégé" contre l'édition.

En fait, si j'ai à peu près compris, il a modifié le programme en y insérant un token invalide, si bien que la calculatrice ne peut pas détokeniser, provoquant une erreur à la moindre tentative de détokenisation

et si tu ne sais pas ce que signifie détokeniser, cela transforme ces 4 octets:
10,1,POSINT_TAG,EXACT_TAG (ou un truc de ce genre, je n'ai pas la doc sous les yeux) en ces 9 caractères:
exact(10)

c'est indispensable pour qu'on puisse éditer le programme

en fait jé programmer un jeu avec la librairie flib et lorsque je sort il y a un message dérreur aprés un moment ou un text clignote ds l'écran home et jé rien piger au coup de détokenisation dsl et merci kan meme pour le kou des screenshot

oublie le coup de la detokenization, c sans importance (il etale sa science )
et ca ne vient ptet pas da ca, link
mais explique un opeu mieux (sois plus précis) comment est ce que tu obtiens des 'internal error'

Il arrive pafois qu'on ait cette erreur quand on utilise goto après une condition mais cela est un bug de la ROM. Je ne suis pas sur de ce que je dis mais c'est peu être une résond valable.

Thor
a écrit : en fait jé programmer un jeu avec la librairie flib et lorsque je sort il y a un message dérreur aprés un moment ou un text clignote ds l'écran home et jé rien piger au coup de détokenisation dsl et merci kan meme pour le kou des screenshot

Honnêtement, et sans sens caché, c'est possible que ce soit dut à FLib ? Je me m'étendrais pas sur le sujet on va encore m'accuser :]

Si tu utilise les fonctions de lecture et d'écriture dans un fichier sur ce points Flib possède des bugs donc Vertyos a résond.

Thor>fait un reset et ré-essayes le prog qui plante (est-ce que tu utilise des try:else:endtry dans ton prog ??).

oui jutilise des try end try pas mal dailleur

Il faut éviter... Les try:endtry sont completement buggés et à l'origine de pas mal de comportements étranges. Si tu programme proprement tu ne devrais pas avoir besoinde try. Je suis d'accord que ça "simplifie la vie", mais il faut voir à quel prix...

c sale je trouve comme programation...
mis a part pour certains cas ou indispensable (genre executer dans un expr() une commande rentrée par l'utilisateur) c a proscrire

Thor
a écrit : oui jutilise des try end try pas mal dailleur

Voilà d'ou ça vient
Si t'utilise une instruction de communication dans une try, t'auras même le droit à une superbe Adress_Error

Comment résoudre le probleme alors sachan ke mon try sert a savoir si oui ou non on sort dela matrice alors il faudré ke je déclare une new variable sinon si vous voulé voir ce kil ty a comme probleme tt de suite je peu vous envoyer le prog (si vous avez une v200) dites moi votre adresse et je vous lenvoi ce week end

Le try est pas là pour faire le boulot d'un if (surtout que try est plus lent et moins fiable).

Moui... Cherche un peu mais le try n'est PAS une bonne solution, comme disais aze, à part dans le cas d'un expr, tu dois toujours pouvoir t'en passer.

si il y a des amteur pour voir ce ki ne va pa ds mon jeu donnez moi votre adresse

Tu les as les adresses
A droite des posts le 1er des 4 boutons...

golstein@caramail.com
(j'ai une v200 dinc si tu veux...)

tu peux aussi me l'envoyer si tu veux...

je reviens sur le debut ....excusez moi


Comment reconstruire un programme proteger en edition?

faut modifier un octet avec un éditeur hexa (genre tthedit), mais me rappelle plus lequel.

faut trouver l'octet qui a été modifié, et ca c pas de la tarte...

généralement c un retour a la ligne (ou ":") qui a été changé, mais faut savoir où
(soit apres un stop ou entre un goto et un lbl )

Mouais... Flib plante royalement avec la lecture des fichiers (lorsqu'il est censé renvoyer une chaine de plusieurs octets)
Flib plante également encore plus royalement (plus que Erreur Interne) et fait une Erreur d'adresse assez souvent si tu essaie d'écrire dans un fichier (texte, avec insertline par exemple)
Il y'a également des erreurs internes lorsque tu emboîtes trop de Try...Else...EndTry. Par exemple si tu fais un expr avec une boucle For à l'intérieur de deux ou trois blocs Try.
Le Try c'est effectivement très lent mais les If aussi
En fait je ne sais pas quelle lib tu utilises mais si tu utilises clib, elle renvoie parfois des Internal Error lorsque tu lui fournis de faux arguments. Je lui ai mis cette "protection" pour éviter de faire n'importe quoi lorsqu'elle détecte des arguments trop erronés.
Sinon c'est nul de protéger son programme...

en fait, ce n'ets pas flib a propreùent parlé qui plante avec le retour de fichiers, c'est juste que quand flib renvoit une chaine, et que dans cette chaine se trouve le char(0), le tios interprete ca comme la fin de la string, et les caracteres suivants sont interprété comme des nousveaux éléments de la liste fl (mais ils ne correspondent jamais à qqch de valide, d'ou l'erreur)

(et quand je dit "caracteres suivants", ca serait plutot les caracteres précedents, vu que le tios stoque les listes a l'envers)

azerty83 :
en fait, ce n'ets pas flib a propreùent parlé qui plante avec le retour de fichiers, c'est juste que quand flib renvoit une chaine, et que dans cette chaine se trouve le char(0), le tios interprete ca comme la fin de la string, et les caracteres suivants sont interprété comme des nousveaux éléments de la liste fl (mais ils ne correspondent jamais à qqch de valide, d'ou l'erreur)
(et quand je dit "caracteres suivants", ca serait plutot les caracteres précedents, vu que le tios stoque les listes a l'envers)

Ouah! Tu t'y connais toi! Je n'ai pas mis ce genre d'info car mon post était censé être adressé à un débutant . Je ne crois pas qu'il comprendra ces **nneries! Mais bon, on voit qu'avec mkpic flib reconnait les 00 (à se demander comment il ferait si le motif 48,48 arrivait vraiment dans l'image ) comme caractères zéro et tout et tout. Alors il aurait pu aussi pousser "00" en cas de caractères nuls. Non mais là FL!
OK je plaisante! Franchement elle est déjà super ta lib. C'est du super boulot (surtout la source!)

bah, en fait ce que j'ai dit, c'ets juste une suposition, mais connaissant le format des listes du tios, c'est ce qui est le plus probable

par contre pour mkpic, ben je peux te dire ce qui se passe, ca m'est deja arrivé
l'image est decalée, et faut la modifier pour supprimer les octets 48 48
ce qui monte que le format de mkpic esr foireux (ca aurait été mieux de mettre '\0' pour un char 0 et '\' pour le char '\', comme en C je crois, là plus de pb)

mais per contre, je pense que le retour de chaine aurait du s'arreter quand flib rencontre un 0...
(je crosi que c'ets ce qui se passe si on ommet les elts de la liste qui sont buggés)

et puis flib est bien est vertel est bien meilleure !!!
(plus rapide et plus puissante)

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 .
Mais bon, depuis que la fonction group existe, mkpic est devenue obsolète ...

>et puis flib est bien est vertel est bien meilleure !!!
On pourra en reparler quand les fonction v_grou (génial, le nom ) et v_komp existeront

azerty83 :
et puis flib est bien est vertel est bien meilleure !!! (plus rapide et plus puissante)

On pourra en reparler quand les fonction v_grou (génial, le nom ) et v_komp existeront

"v_grou" existe mais n'a pas été releasée (tjrs dans l'addon...) et n'a pas ce nom. v_komp, non, ça prend trop de place. Je préfere faire une lib plus souple et plus rapide que rajouter des tonnes de fonctions

azerty83
: bah, en fait ce que j'ai dit, c'ets juste une suposition, mais connaissant le format des listes du tios, c'est ce qui est le plus probable

Je confirme.

par contre pour mkpic, ben je peux te dire ce qui se passe, ca m'est deja arrivé
l'image est decalée, et faut la modifier pour supprimer les octets 48 48 ce qui monte que le format de mkpic esr foireux (ca aurait été mieux de mettre '\0' pour un char 0 et '\' pour le char '\', comme en C je crois, là plus de pb)

En effet, le format est foireux. Mais FL a refusé de résoudre ce problème quand je le lui ai reporté.

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.


Pour ceux qui n'arrêtent pas de demander le KOMP à Vertyos: pour compresser on-calc et en ligne de commande, il y a PepZip: http://www.ticalc.org/archives/files/fileinfo/297/29765.html.

> Il a dit que ça prend trop de place.
Mais bien sûr
Et puis il était préférable d'y gagner en place et d'y perdre en information

pepzip : merci beaucoup Kevin !
Bon, ça fait un "standard" de plus, mais celui-ci semble plus performant que zip, komp, etc ...