Niveaux de gris - Page 6

Non.

arf, dommage

Elle t'a fait gagner de la mémoire???

il me semble que oui.
je vérifierai en enlevant ce switch et en le remettant, afin d'etre sur que c'est celui-là et pas un des autres que j'ai rajouté.

Je te signale aussi qu'il peut y avoir des problèmes avec les structures AMS si tu définis ce genre d'options non-standard

OK; si j'ai des pb avec des structures d'AMS, il faudra que je pense à voir si ça vient de là.
(pour l'instant, d'apres ce que j'ai testé, j'ai pas encore eu de pb)

squale : elle fait perdre en vitesse ?
KK : Non.
squale : arf, dommage

Je te signale aussi qu'il peut y avoir des problèmes avec les structures AMS si tu définis ce genre d'options non-standard

AMS et TIGCC c'est pas trop ça... J'ai passé six mois à me taper toutes sortes de bugs sur mon éditeur de textes alors que le problème provenait de l'optimisations d'appels en rom...

Plus précisément? (qu'on voit juste si finalement ça venait pas de toi )

Je pense qu'il voulait appeler des ROM_CALLs dans un callback avec OPTIMIZE_ROM_CALLS. C'est le genre de trucs à ne pas faire sans précautions particulières, c'est-à-dire:
void *olda5=__jmp_tbl;
__jmp_tbl=*(void **)0xc8;
...
__jmp_tbl=olda5;

./152> heu, dsl, j'avais mal lu la réponse de Kevin
(enfin, je ne me souvenais plus ma question, en fait ; je croyais avoir demandé si elle faisait gagner en vitesse)

Tu l'as demandé aussi, et la réponse était non aussi
En résumé : ça ne change rien à la vitesse mais ça augmente éventuellement la taille, donc --> poubelle (enfin c'est ce que j'ai compris...)

C'est ça.
Et la raison pour laquelle ça ne change rien à la vitesse est simple: le 68k des TI-89/92+/V200 s'en contrefiche si l'adresse est divisible par 4 ou non, tant qu'elle est paire.

Kevin Kofler :
Je pense qu'il voulait appeler des ROM_CALLs dans un callback avec OPTIMIZE_ROM_CALLS. C'est le genre de trucs à ne pas faire sans précautions particulières, c'est-à-dire:
void *olda5=__jmp_tbl;
__jmp_tbl=*(void **)0xc8;
...
__jmp_tbl=olda5;

Voilà justement. Mais je ne savais pas. De plus j'avais un autre problème à l'époque (un truc tout con):
TRY
instructions;
goto apres;
ONERR
instructions;
ENDTRY
apres:
Et si je vais à apres, à la prochaine erreur basic une fois l'exécution du prog terminée (pas toutes, mais ex. Window variable domain) je reçois une ER_THROW à la place... et j'ai aussi cherché longtemps. Cependant j'aurais bien pensé que le goto apres aurait généré une erreur de compilation, or ce n'est pas le cas.
Et après on gueule dessus les programmeurs BASIC car ça plante, mais bon c'est RAREMENT leur faute (les barres noire ça ne vient qu'avec les fenêtres (TOP-BOTTOM -> FULL et cie)

Ximoon :
Plus précisément? (qu'on voit juste si finalement ça venait pas de toi )

Pourquoi tu dis ça??? Non, juste qu'il faudrait peut-être préciser ça dans la doc de TIGCC de manière plus claire. En fait le problème venait avec l'appel au Var-Link, et même avec certaines boîtes de dialogue (à n'y rien comprendre)... Le Var-Link, même s'il ne plante plus à présent, je l'ai jarté car je n'en voyais pas vraiment l'utilité.
En gros, pour l'équipe TIGCC, ce serait "sympa" de lancer une erreur de compilation comme en TI-BASIC lorsqu'on fait des sauts entre les blocs TRY...ONERR...ENDTRY.

le pbm c que TIGCC ne peut pas detecter facilement se genre de choses et il par du principe que le programmeur sait un peu se qu'il fait. Il puorrait y avoir des cas ou il FAUT que tu fasse se saut en dehors du try/onerr/endtry, donc non il peuvent pas mettre d'erreur pour se genre de cas, d'ailleur a mon avis sa doit etre tres difficile a detecter, voir impossible

le pbm c que TIGCC ne peut pas detecter facilement se genre de choses et il par du principe que le programmeur sait un peu se qu'il fait. Il puorrait y avoir des cas ou il FAUT que tu fasse se saut en dehors du try/onerr/endtry, donc non il peuvent pas mettre d'erreur pour se genre de cas, d'ailleur a mon avis sa doit etre tres difficile a detecter, voir impossible

Il ne faut JAMAIS sortir de ces blocs car ça crée un plantage A TOUS LES COUPS! Sur TI, il n'y a pas d'exception, cela ne doit pas être possible.
[Edit:]Enlevé deux retours chariots en trop

les bloc TRY/ONERR/ENDTRY ne sont pas des mot clef du C, il d'agit de macro, regarde tigcc.h tu verra
donc SI tu peut sortir proprement de se bloc si tu sais comment cela fonctionne

Ma foi, c'est vrai, mais le seul but serait qu'on précise dans la doc qu'il NE FAUT PAS faire ça, c'est tout.

Brunni :
De plus j'avais un autre problème à l'époque (un truc tout con):
TRY
instructions;
goto apres;
ONERR
instructions;
ENDTRY
apres:
Et si je vais à apres, à la prochaine erreur basic une fois l'exécution du prog terminée (pas toutes, mais ex. Window variable domain) je reçois une ER_THROW à la place... et j'ai aussi cherché longtemps. Cependant j'aurais bien pensé que le goto apres aurait généré une erreur de compilation, or ce n'est pas le cas. Et après on gueule dessus les programmeurs BASIC car ça plante, mais bon c'est RAREMENT leur faute (les barres noire ça ne vient qu'avec les fenêtres (TOP-BOTTOM -> FULL et cie)

Il faut appeler ER_success(); avant de sauter en dehors d'un bloc TRY avec un goto:

TRY
 instructions;
 [b]ER_success();[/b]
 goto apres;
ONERR
 instructions;
ENDTRY
apres:

En gros, pour l'équipe TIGCC, ce serait "sympa" de lancer une erreur de compilation comme en TI-BASIC lorsqu'on fait des sauts entre les blocs TRY...ONERR...ENDTRY.

On ne peut pas (sans traffiquer GCC à beaucoup d'endroits), ce sont des macros qui appellent ER_catch, ER_success etc.
Et puis, si on faisait ça, on empêcherait aussi de faire ER_success();goto truc;, ce qui serait une régression. (Gosper89 en a besoin.)

Brunni
:

le pbm c que TIGCC ne peut pas detecter facilement se genre de choses et il par du principe que le programmeur sait un peu se qu'il fait. Il puorrait y avoir des cas ou il FAUT que tu fasse se saut en dehors du try/onerr/endtry, donc non il peuvent pas mettre d'erreur pour se genre de cas, d'ailleur a mon avis sa doit etre tres difficile a detecter, voir impossible

Il ne faut JAMAIS sortir de ces blocs car ça crée un plantage A TOUS LES COUPS! Sur TI, il n'y a pas d'exception, cela ne doit pas être possible.

Il suffit d'appeler ER_success(); à la main et ça marche!

Je ne savais pas pour ER_success. Je dois mal avoir lu la doc !