Lancer l'exécution d'un programme en Basic - Page 1

Dans la documentaion de TIGCC, il est dit de faire comme ça : short progrun (char *name) {   char fname[25];   HANDLE h;      TRY     strcpy(fname, name);     strcat(fname, "()");     push_parse_text(fname);     h= HS_popEStack();     NG_execute(h, FALSE);     HeapFree(h);   ONERR     return FALSE;   ENDTRY   return TRUE; }
1) il ne serait pas plus optimisé en taille et en vitesse de faire sprintf(fname, "%s()", name) pour l'ajout des parenthèses ?????????
2) au retour de cette fonction, si le programme Basic est archivé, la copie en RAM du programme ainsi que son entrée en VAT ne semblent pas effacés : on se retrouve avec deux fichiers de même nom et de même taille !
3) en cas d'erreur, le handle alloué par HS_popEStack n'est pas libéré !! si ?
4) lorsqu'une erreur survient dans le programme Basic, il est immédiatement quitté, sans qu'on ait le temps de lire la boîte de dialogue donnant l'erreur.


bref voilà, si vous avez un code plus performant que la bizarrerie ci-dessus, je suis preneur...

il me semble que ceci ne arche pas sur HW2 sans HW2patch ,non ?
(enfin, il me semble seulement)

Ben si en plus ça ne fonctionne pas sur les HW2 non patchées ! j'espère que non, ça serait grave que la documentation de TIGCC accumule tant d'erreurs

je suis pas sûr !
Mais il me semble que Kevin avait parlé de quelque chose de genre il y a super longtemps... (je crois que ct pour PCT, mais pas sûr)

il me semble qu'il faut faire quelque chose de plus complexe...
en fait, il doit falloir que le programme en appellant un autre soit dans le ghost_space ou quelque chose comme ça
(ce qui exipluqe le #define EXECUTE_IN_GHOST_SPACE ou queluqe chose comme ça dans TIGCC)

EXECUTE_IN_GHOST_SPACE
Sometimes it is necessary to execute a program in the so-called "ghost space", which is the area of addresses above 0x40000. If you need to know more about this, read the launcher FAQ entry. If you put

#define EXECUTE_IN_GHOST_SPACE

at the beginning of your program, the program will automatically be executed in the ghost space. This causes an overhead of about 130 bytes. More precisely, it will relocate itself in the ghost space (by applying EX_patch to itself with the start address increased by 0x40000) before entering the ghost space. Everything will be performed before anything else. Therefore, there are no limitations introduced by this directive, whereas the older enter_ghost_space function was very limited and hard to use.
EXECUTE_IN_GHOST_SPACE allows the user to simply call one program from another, without worrying about the AMS protections which usually prevent this.

Le code posté ne marche pas sur HW2 AMS 2 sans HW2Patch ni h220xTSR si et seulement si le programme TI-BASIC appelle un programme en assembleur ou C (genre FLib) ou une chaîne Exec. Ça marchera avec du TI-BASIC pur. Et EXECUTE_IN_GHOST_SPACE ne changera rien à la situation. Il faut rediriger le trap 11 comme le fait h220xTSR pour résoudre le problème. (D'ailleurs, h220xTSR résout en effet ce problème en tant qu'"effet collatéral" positif de son travail.)

Pourquoi vous ne le dites pas dans la documentation de TIGCC (j'ai trouvé ce code dans la FAQ) ???
Et pour les 4 points du premier post, si quelqu'un pouvait y répondre...

Thibaut a écrit :
1) il ne serait pas plus optimisé en taille et en vitesse de faire sprintf(fname, "%s()", name) pour l'ajout des parenthèses ?????????

En taille probablement, en vitesse pas forcément, vu que sprintf est assez lent. (Dans ce cas, il lui faut interpréter ce que veut dire %s et aller chercher le paramètre correspondant, problème que n'ont pas strcpy et strcat.)

2)
au retour de cette fonction, si le programme Basic est archivé, la copie en RAM du programme ainsi que son entrée en VAT ne semblent pas effacés : on se retrouve avec deux fichiers de même nom et de même taille !

AMS l'effacera automatiquement plus tard (quand on revient à l'écran HOME).

3)
en cas d'erreur, le handle alloué par HS_popEStack n'est pas libéré !! si ?

Non, et c'est une erreur. À corriger.

4)
lorsqu'une erreur survient dans le programme Basic, il est immédiatement quitté, sans qu'on ait le temps de lire la boîte de dialogue donnant l'erreur.

C'est normal, il faut rajouter un ERD_dialog si tu veux voir l'erreur.

merci Kevin (d'ailleurs je vais t'avouer que ce topic t'était destiné, je savais que toi seul pouvait y répondre )

En taille probablement, en vitesse pas forcément, vu que sprintf est assez lent.

Parfait, tu vas pouvoir modifier le code de la FAQ puisque tu adores l'optimisation en taille

AMS l'effacera automatiquement plus tard (quand on revient à l'écran HOME).

Donc ça bouffe de la RAM Y'a pas un moyen de contourner ce bordel ?

Non, et c'est une erreur. À corriger.

En même temps que l'ajout des parenthèses avec sprintf

C'est normal, il faut rajouter un ERD_dialog si tu veux voir l'erreur.

Faudrait en parler dans la FAQ. Décidément elle est vraiment mal foutue la page concernant le lancement de programmes Basic

Si tu veux, tu peux tester si le programme basic est archive.
Si c'est le cas, tu le desarchives puis tu l'executes.
Puis tu testes si la sym est bien avec le flag twin, si c'est le cas tu supprimes. (SymDelTwin)
Faut faire gaffe, car le ptr vers SYM_ENTRY *, le Hsym sont invalides apres l'appel au Ti-basic

Merci PpHd ! j'y avais pas pensé, t'es pas con