Convertrir Programme fr en anglais - Page 3

naPO :
Bah là, Vertyos utilise correctement Try, et il dit que ça bug

Ben non, utiliser Try dans une boucle de link n'est pas un usage correct, parce que ça bogue, justement...

Martial Demolins
: oué cool pour le débogage

Tu le mets pour le release seulement.

Justement, NAN !

Justement, SI! Pourquoi pas?

naPO
: Tu vois, ici le try, n'englobe pas le prog... Et je te mets au défi de le faire bugger.

L'intérêt de faire un Try global est d'éviter d'en mettre un à chaque instruction, justement. D'autant plus qu'il est facile d'en oublier si on fait comme ça.

-> TU <- peux oublier.

Tu fais preuve d'une arrogance énorme là! Tout le monde peut se tromper, tu n'en est pas exempt! Cf. ton exemple avec abs(int(n)), par exemple!

Et puis c'est vrai qu'un Try est rudement conseillé pour des commandes du genre Disphome, Local, etc...

Pourquoi réfléchir à ça cas par cas si on peut en mettre un seul?

Et mettre un seul Try donne aussi des programmes nettement plus compacts!

Nom de diouss, utiliser des Try à la toque pour une release finale, c'est porcasse...

Pourquoi?

Vertyos
:

Kevin Kofler :
Si tu utilises Try de la manière que je conseille, ce n'est pas dans une boucle, donc il n'y a pas de problème.

C'est comme ça que tu corriges un bug ? En évitant le cas où il se déclanche ?

C'est une solution tout à fait valide, et en l'occurrence la seule vu que tu ne peux pas corriger AMS, et que même si TI corrigeait AMS 3.0x, le bogue serait toujours là dans les versions d'avant.

Ben oui, donc il faut les éviter...

cite de cite de cite...

Ben non, utiliser Try dans une boucle de link n'est pas un usage correct, parce que ça bogue, justement...

Heu je parlais du prog de test de Vertyos, pas le send a.

Justement, SI! Pourquoi pas?

Ça veut dire : "Oué, j'ai fait mon prog, mais comme il y a plein de possibilités de le faire bugger, alors je mets des Try de partout..." cf. Vertyos, pour corriger un bug, tu évites et c'est tout :/

Tu fais preuve d'une arrogance énorme là!

Tout le monde
peut se tromper, tu n'en est pas exempt! Cf. ton exemple avec abs(int(n)), par exemple!

Disons que chacun a ses méthodes, mais bon, je reconnais m'être emporté... Cela dit, chacun a sa façon de coder en Basic, hein, je maintiens que Try, on l'utilise avec parcimonie.

Pourquoi réfléchir à ça cas par cas si on peut en mettre un seul?

Pas vu que je délirais ?

Et mettre un seul Try donne aussi des programmes nettement plus compacts!

Bof. Ne pas en mettre c'est mieux aussi.

Pourquoi?

cf. plus haut.

Kevin:
1) Pour un prog qui fait pas mal de clrdraw, ça peut être cool de virer carrément les axes. Il faut aussi ajouter le FnOff, ClrGraph...
2) Le mieux pour ça, c'est StoGDB et RclGDB
3) le try FOIRE avec setMode! je te l'ai déja dit! Il faut non pas tryer le setmode, mais tester si on est ou non en anglais!
-->Anglais: Possibilité qu'on soit en AMS 1, donc les chiffres ne sont pas forcément compatibles: On y va en Anglais, puisque lui, on est sur qu'il marche
--> Pas Anglais: Tout appel en anglais foirera, mais on est sur qu'on est sous AMS 2 qui supporte les chiffres: On emploie les chiffres.
4) Oui, j'utilise try avec Expr
5) Passer en mode Exact est plus économique en vitesse quand il s'agit d'afficher dans une boucle une chaine (ou pire, une image) avec des chiffres. On essaie de se débrouiller pour diminuer les SPF...

Link :
Kevin: 1) Pour un prog qui fait pas mal de clrdraw, ça peut être cool de virer carrément les axes. Il faut aussi ajouter le FnOff, ClrGraph...

Beurk! Beurk! Beurk!
Pour effacer l'écran, il faut utiliser StoPic p:XorPic p, pas ClrDraw. ClrDraw, c'est le truc à faire pour le nettoyage avant de quitter seulement.

3) le try FOIRE avec setMode! je te l'ai déja dit! Il faut non pas tryer le setmode, mais tester si on est ou non en anglais!
-->Anglais: Possibilité qu'on soit en AMS 1, donc les chiffres ne sont pas forcément compatibles: On y va en Anglais, puisque lui, on est sur qu'il marche --> Pas Anglais: Tout appel en anglais foirera, mais on est sur qu'on est sous AMS 2 qui supporte les chiffres: On emploie les chiffres.

Ça dépend du mode! Pour Exact/Approx, ça foire (parce que NG_control est sauvegardé/restauré dans la structure ERROR_FRAME), mais de toute façon il ne faut pas utiliser ça (mais les fonctions exact ou approx). Pour tous les modes ne passant pas par NG_control, il n'y a pas de problème.

5) Passer en mode Exact est plus économique en vitesse quand il s'agit d'afficher dans une boucle une chaine (ou pire, une image) avec des chiffres. On essaie de se débrouiller pour diminuer les SPF...

string(exact(x)) marche très bien... Et si les fps comptent, il faut programmer en C ou en assembleur, ou à la limite en GFA Basic ou ETP Basic, mais certaiment pas en TI-BASIC (où on a effectivement des spf )!

Vous avez pas l'impression de faire dériver le sujet sur plus de 2 pages uniquement pour arriver à une conclusion douteuse ?
Surtout que chacun restera sur sa position

Vous avez pas l'impression de faire dériver le sujet sur plus de 2 pages uniquement pour arriver à une conclusion douteuse ? Surtout que chacun restera sur sa position

ça fait des années que c'est comme ça...
dans le temps, il y avait des pages et des pages sur "kernel vs nostub", ou "extgraph vs genlib"...

squale92 :
dans le temps, il y avait des pages et des pages sur "kernel vs nostub", ou "extgraph vs genlib"...

Ou pour ou contre l'OO

Les gens aiment bien la pagaille et les jeux de réthorique

1) J'ai pas mis de compilo oncalc, et c'esttrop fastidieux de devoir archiver son source entre chaque essai. Pour les cours où l'on s'ennuie, le basic est préférable
2) Rclpic p J'en fait déja pas mal à chaque affichage. En fait, j'ignore si clrdraw est plus rapide ou non, il faudra que je teste...
Mais je ne prendrai pas le plus lent, spf oblige.
3) Je programme en C quand je suis chez moi, et si j'ai le temps.

Link :
2) Rclpic p J'en fait déja pas mal à chaque affichage. En fait, j'ignore si clrdraw est plus rapide ou non, il faudra que je teste... Mais je ne prendrai pas le plus lent, spf oblige.

En fonction des graphiques/plots activés, ClrDraw peut être très lent, et ne pas faire ce que tu veux faire.
Maintenant, si tu fais FnOff et PlotsOff, tu te mèles vraiment des affaires de l'utilisateur de manière AMHA inacceptable.

Je conseille de faire un PassErr dans le Try, parce qu'il n'y a rien de plus embêtant que d'avoir un message "Error" qui ne dit pas quoi comme erreur il y a eu! Bien sûr, les messages par défaut de AMS ne sont pas idéaux, mais c'est mieux que rien.

Et je ne vois pas du tout, mais alors vraiment pas du tout, le rapport avec le cas du FnOff.

Et alors? Je ne vois toujours pas le rapport.

Mon FnOff/PlotsOff, il est supprimé par le RclGDB bdgtemp.
Je suis un programmeur Basic propre, moi.
Mes progs complets quittent proprement, et restaurent l'écran ET l'image.
Dommage qu'il soit impossible de faire la même chose dans l'écran IO quand je l'utilise, mais je l'utilise rarement.

Bon, désolé pour le up (menfin bon, c le 4è topic de la liste alors je me sens pas trop coupable ), mais juste pour signaler que pour une fois je suis plutôt d'accord avec Kevin et je ne vois pas trop pourquoi vous lui tombez dessus... A part quelques points où évidemment il est trop extrémiste (mettre des lettres grecques dans ttes les variables, ou ne pas utiliser flib/vertel ), ça me paraît une bonne idée de mettre le moins de bordel possible, et par exemple le fait de mettre un Try..EndTry autour du programme est une très bonne manière de faire si on utilise des variables globales/des modes globaux... Ca permet d'être sûr à 100% que ça va pas laisser du bordel, tant mieux non ? Alors à part peut-être des bugs dans AMS (que je ne connais pas, mais apparemment ça ne concerne pas ce cas-là ), et le fait de vouloir garder le contenu des variables pour débugger (mais pour débugger on va de toute façon vouloir garder le contenu dans pleins d'autres cas, donc on va par exemple avoir envie de transformer des variables locales en variables globales, ou encore de ne pas nettoyer les variables même si y a pas eu d'erreur -- chose qu'il faudra donc changer pour la release aussi ^^), y a aucune raison de critiquer ça de manière aussi virulente... Même Kevin peut dire des choses sensées, sisi

Link :
1) J'ai pas mis de compilo oncalc, et c'esttrop fastidieux de devoir archiver son source entre chaque essai. Pour les cours où l'on s'ennuie, le basic est préférable

Euh, si tu utilises un éditeur comme Side ou l'IDE de GTC, l'éditeur archive et désarchive tout automatiquement...

un simple try autour d'un gros programme, c'est assez foireux (surtout s'il a plein de sous-programmes). pareil pour les variables locales, je ne suis pas sûr qu'elles soient visibles par un sous-programme

un simple try autour d'un gros programme, c'est assez foireux (surtout s'il a plein de sous-programmes).

c'est-à-dire ?

pareil pour les variables locales, je ne suis pas sûr qu'elles soient visibles par un sous-programme

oui, bien sûr, c'est le pb des variables locales en basic... mais je ne parlais pas de rendre les variables globales locales

on va dire que le comportement n'est pas parfaitement déterministe, surtout s'il y a bcp de try imbriqués

erf mais c seulement la commande Try en basic, ou c'est aussi tous les ER_* ?

j'en sais rien, je pense que c'est le try

Flanker :
on va dire que le comportement n'est pas parfaitement déterministe, surtout s'il y a bcp de try imbriqués

Le comportement est déterministe, c'est toi qui ne le comprends pas.

nan, quand y a plusieurs niveaux de try, à travers différents sous-programmes, j'ai souvent eu des bugs aléatoires.