Convertrir Programme fr en anglais - Page 1

Je Programme en basic en français et je voudrai le mettre en anglais
comment faire

Mettre ta calc en french
Lancer le prog
Mettre ta calc en anglais
Ouvrir le prog
Miracle !!!!

(la partie important est le lancement du prgm)

Il faut qu'il soit désarchivé lors du lancement aussi.
Et toute information sous forme de chaîne de caractères (par exemple les types des variables, style "AUC") ne sera pas traduite automatiquement! C'est pour ça qu'il faut éviter à tout prix l'utilisation de ces chaînes de caractères dépendantes de la langue dans les programmes.

merci

Attention, cependant, les paramètres de défmode entre guillemets resteront en anglais, il en est de même pour quelques autres fonctions... Il existe un remède à cela en appelant le paramètre pas son n° dans la liste et plus par son nom, ainsi, on évite tous les problèmes...

4 kernels - 3 librairies - 1 OS.

di555
: Attention, cependant, les paramètres de défmode entre guillemets resteront en anglais, il en est de même pour quelques autres fonctions... Il existe un remède à cela en appelant le paramètre pas son n° dans la liste et plus par son nom, ainsi, on évite tous les problèmes...

Sauf la compatibilité avec AMS 1...
La bonne solution est:
:Try
:setMode("1","1")
:Else
:ClrErr
:setMode("English name","ENGLISH SETTING")
:EndTry
Et le mieux est d'éviter au maximum les changements de mode, il y a souvent moyen de faire mieux. Par exemple, pour virer les axes, il suffit de mettre:
:Local p
toPic p
:XorPic p
:DelVar p

mais ca prend bcp de mémoire tout ça non ?

oui
mettre juste un avertissement dans le read-me est beaucoup plus simple, et ça évite de multiplier par 2 la taille du programme, et de diviser par 2 sa vitesse

Obliger l'utilisateur à changer de langue n'est pas une solution. Il faut faire l'effort de coder proprement. Sinon, vous ne faites qu'alimenter la rumeur que "programme BASIC" == "programme pourri".

Et parler de vitesse pour un programme BASIC... C'est carrément ridicule. Le TI-BASIC est toujours lent.

elle existe, cette rumeur ? c'est la première fois que j'en entends parler

Bizarre, elle est pourtant très diffusée. Et franchement, mon avis est que 90% ou plus des programmes BASIC sont codés de manière "porc". Et que 99,99% des programmes BASIC sont lents (les autres, c'est de style 1/x->f(x) ).

les débutants commencent par le basic, et globalement, un débutant sait moins bien programmer qu'un programmeur confirmé
forcément, si tu compares une boucle For en basic à une boucle For en C ...

Et si vous voulez une liste de tout ce que je trouve dégueulasse dans les programmes BASIC (dans aucun ordre particulier):
* programmes incompatibles avec toutes les langues de AMS sauf une ("bonus" si cette langue n'est pas l'anglais).
* programmes qui laissent traîner des tonnes de variables globales. Sauf rares exceptions, une variable doit toujours être locale. Quand ce n'est vraiment pas possible, il faut impérativement effacer la variable aussitôt que possible, au plus tard quand on quitte le programme.
* programmes qui utilisent des noms de variables causant des conflits. Il faut toujours mettre des lettres grèques et des chiffres dans les noms de variables globales, et de préfèrence aussi dans les noms de variables locales (cf. tous les programmes bogués qui utilisaient Local sec).
* programmes qui changent des modes alors que ce n'est pas nécessaire. On peut virer les axes sans changer de mode, on peut forcer un résultat exact ou approché sans changer de mode etc. Changer de mode ne doit être qu'une dernière solution si tout le reste est impossible.
* programmes qui changent les modes sans les restaurer. Rien de plus lourd que de devoir remettre les axes à la main, par exemple.
* programmes qui laissent traîner des cochonneries sur l'écran PrgmIO ou Graph. Il y a des routines pour effacer ce que vous avez écrit, utilisez-les!
* programmes qui laissent la calculatrice sur autre chose que l'écran Home. C'est aussi dur que ça de mettre un DispHome?
* programmes qui n'utilisent pas Try pour effacer les variables globales, restaurer les modes, nettoyer l'écran etc. même en cas d'erreur. Il peut toujours y avoir une erreur à laquelle vous n'avez pas pensé, prévoyez cette éventualité et évitez de laisser traîner des cochonneries dans ce cas.
* programmes incompatibles avec certaines versions de AMS, cf. utilisation de sec en tant que nom de variable, et cf. aussi l'utilisation de fonctions introduites dans AMS 2.00 ou 2.08 seulement.
* utilisation de programmes quand une fonction suffit ("bonus" si c'est une fonction intégrée).
* programmes qui rament à fond, mais ça c'est inhérent au BASIC...
* programmes "BASIC" dans lesquels une ligne sur 2 est un appel à un programme compilé (vertel, flib, Exec, ...), réunissant ainsi la lenteur du BASIC et le risque de plantages des langages compilés.

Tu es libre de créer un sujet dédié, mais ça n'est pas trop le sujet ici en fait ...

* programmes incompatibles avec toutes les langues de AMS sauf une ("bonus" si cette langue n'est pas l'anglais).

"français mode sux" -> pourquoi programmer en français ?

* programmes qui laissent traîner des tonnes de variables globales. Sauf rares exceptions, une variable doit toujours être locale. Quand ce n'est vraiment pas possible, il faut impérativement effacer la variable aussitôt que possible, au plus tard quand on quitte le programme.

ouep, sauf quand on veut sauvegarder des données, peut-être ? et toujous à la fin du prog, ça suffit largement

* programmes qui utilisent des noms de variables causant des conflits. Il faut toujours mettre des lettres grèques et des chiffres dans les noms de variables globales, et de préfèrence aussi dans les noms de variables locales (cf. tous les programmes bogués qui utilisaient Local sec).

ouééé ça c'est super cool pour avoir un programme compréhensible
et les programmes buggués qui utilisent la variable sec, j'en connais pas beaucoup (un seul)

* programmes qui changent des modes alors que ce n'est pas nécessaire. On peut virer les axes sans changer de mode, on peut forcer un résultat exact ou approché sans changer de mode etc. Changer de mode ne doit être qu'une dernière solution si tout le reste est impossible.

bof, je vois pas qu'est-ce que ça peut te faire que le prog les change, s'il les restaure

* programmes qui changent les modes sans les restaurer. Rien de plus lourd que de devoir remettre les axes à la main, par exemple.

ok

* programmes qui laissent traîner des cochonneries sur l'écran PrgmIO ou Graph. Il y a des routines pour effacer ce que vous avez écrit, utilisez-les! * programmes qui laissent la calculatrice sur autre chose que l'écran Home. C'est aussi dur que ça de mettre un DispHome?

ok

* programmes qui n'utilisent pas Try pour effacer les variables globales, restaurer les modes, nettoyer l'écran etc. même en cas d'erreur. Il peut toujours y avoir une erreur à laquelle vous n'avez pas pensé, prévoyez cette éventualité et évitez de laisser traîner des cochonneries dans ce cas.

faut pas déconner, y a pas toujours des risques d'erreur. Si tu viens de créer la variable, tu peux êter sûr que tu pourras l'effacer

* programmes incompatibles avec certaines versions de AMS, cf. utilisation de sec en tant que nom de variable, et cf. aussi l'utilisation de fonctions introduites dans AMS 2.00 ou 2.08 seulement.

et comment tu fais pour dire si un programme est compatible avec l'AMS 3.05 ?

* utilisation de programmes quand une fonction suffit ("bonus" si c'est une fonction intégrée).

ok

* programmes qui rament à fond, mais ça c'est inhérent au BASIC...

ça, tu peux rien y faire

* programmes "BASIC" dans lesquels une ligne sur 2 est un appel à un programme compilé (vertel, flib, Exec, ...), réunissant ainsi la lenteur du BASIC et le risque de plantages des langages compilés.

t'as toujours pas compris que vertel et flib permettent de faire des trucs qu'on peut pas faire en basic

Ximoon > dsl, cross

Hum, avec qelques astuces, un programme BASIC peut avoir une vitesse acceptable hein

Après avoir lu les posts à Kevin, je vais essayer de démonter ses dogmes un à un :

Kevin Kofler :
Et si vous voulez une liste de tout ce que je trouve dégueulasse dans les programmes BASIC (dans aucun ordre particulier):
* programmes incompatibles avec toutes les langues de AMS sauf une ("bonus" si cette langue n'est pas l'anglais).

Depuis quand on programme autrement qu'en anglais ? (cf. moumou)

* programmes qui laissent traîner des tonnes de variables globales. Sauf rares exceptions, une variable doit toujours
être locale. Quand ce n'est vraiment pas possible, il faut impérativement effacer la variable aussitôt que possible, au plus tard quand on quitte le programme.

Cf. moumou encore.

* programmes qui utilisent des noms de variables causant des conflits. Il faut toujours mettre des lettres grecques et des chiffres dans les noms de variables globales, et de préfèrence aussi dans les noms de variables locales (cf. tous les programmes bogués qui utilisaient Local sec).

Moi, j'ai mieux, utiliser des acronymes qui veulent rien dire, comme ça on est sûr de pas causer de conflits, et commenter le nom de la variable.

* programmes qui changent des modes alors que ce n'est pas nécessaire. On peut virer les axes sans changer de mode, on peut forcer un résultat exact ou approché sans changer de mode etc. Changer de mode ne doit être qu'une dernière solution si tout le reste est impossible.

Heu, je veux pas dire, mais les programmes Basic rrépondent aussi à un cahier des charges défini par son programmeur... Par exemple, [PUB]pour mon M'enfin[/PUB], j'ai clairement réfléchi (sous la douche, pendant que je bouffais, pendant que je faisais des BD) à comment afficher les résultats sans passer par mode... Par exemple, j'ai un petit prog qui teste la présence d'un prog sans passer par GetType

Try
Lock machin
Else
Text "Le prog machin, je le trouve pas
Endtry

* programmes qui changent les modes sans les restaurer. Rien de plus lourd que de devoir remettre les axes à la main, par exemple.
* programmes qui laissent traîner des cochonneries sur l'écran PrgmIO ou Graph. Il y a des routines pour effacer ce que vous avez écrit, utilisez-les!
* programmes qui laissent la calculatrice sur autre chose que l'écran Home. C'est aussi dur que ça de mettre un DispHome?

Ça c'est du ressort du programmeur, comme Moumou je suis d'accord.

* programmes qui n'utilisent pas Try pour effacer les variables globales, restaurer les modes, nettoyer l'écran etc. même en cas d'erreur. Il peut toujours y avoir une erreur à laquelle vous n'avez pas pensé, prévoyez cette éventualité et évitez de laisser traîner des cochonneries dans ce cas.
Euh, delvar une variable qui n'existe pas, ça marche pas sous HW1 ?

* programmes incompatibles avec certaines versions de AMS, cf. utilisation de sec en tant que nom de variable, et cf. aussi l'utilisation de fonctions introduites dans AMS 2.00 ou 2.08 seulement.

Ben on sait pas que TI va ajouter des fonctions à la con...

* utilisation de programmes quand une fonction suffit ("bonus" si c'est une fonction intégrée).

* programmes qui rament à fond, mais ça c'est inhérent au BASIC...

Pas d'accord, cf. M'enfin (du moins pour les menus)

* programmes "BASIC" dans lesquels une ligne sur 2 est un appel à un programme compilé (vertel, flib, Exec, ...), réunissant ainsi la lenteur du BASIC et le risque de plantages des langages compilés.

Pas d'accord, cf. M'enfin.

Bah non, Kevin ne sait pas le faire donc ça n'est pas possible, voyons (</SARCASM>, si il passe par là il risque de ne pas comprendre).

Oui bien sûr avec des "libs qui rajoutent l'instabilité d'un programme en C" (j'aimerais bien que tu me montres une grosse release qui plante avec une des libs habituelles, histoire de vérifier), on peut faire des trucs qui tracent pas mal... Pour ça, il faut éviter les hacks de porc pour que ça marche avec toutes les langues, qui ne servent à rien et rendent le programme à la fois plus gros et plus lent .

Moumou
: ouep, sauf quand on veut sauvegarder des données, peut-être ?

OK, dans ce cas, une liste ou matrice dans un répertoire dédié et avec un nom évitant les conflits. Mais c'est la seule exception.

et toujous à la fin du prog, ça suffit largement
[...]
bof, je vois pas qu'est-ce que ça peut te faire que le prog les change, s'il les restaure

La touche [ON], tu connais?

ouééé ça c'est super cool pour avoir un programme compréhensible

Prends des lettres grèques qui sont l'équivalent de la lettre latine correspondante, et tu pourras encore lire ce qu'il y a écrit.

et les programmes buggués qui utilisent la variable sec, j'en connais pas beaucoup (un seul)

Je pense qu'il y en a au moins 2 ou 3, et puis tu ne sais pas:
* ce que les versions futures de AMS vont rajouter comme noms,
* ce que les localisations de AMS vont utiliser comme noms (cf. aussi car, sh, ch, th qui créent des conflits avec la calculatrice en français).

* programmes qui n'utilisent pas Try pour effacer les variables globales, restaurer les modes, nettoyer l'écran etc. même en cas d'erreur. Il peut toujours y avoir une erreur à laquelle vous n'avez pas pensé, prévoyez cette éventualité et évitez de laisser traîner des cochonneries dans ce cas.

faut pas déconner, y a pas toujours des risques d'erreur. Si tu viens de créer la variable, tu peux êter sûr que tu pourras l'effacer

Bah non, tu n'as rien compris.
Je parle de:

:setGraph("Axes","OFF")
...
ligne produisant une erreur
...
:setGraph("Axes","ON")

qui laisse traîner le mode changé. Chose qui peut facilement être évitée:

:setGraph("Axes","OFF")
:Try
  ...
  ligne produisant une erreur
  ...
:Else
:  setGraph("Axes","ON")
:  PassErr
:EndTry
:setGraph("Axes","ON")

(Cela dit, comme déjà dit, on peut se passer complètement de ce changement de mode stupide en utilisant XorPic.)

et comment tu fais pour dire si un programme est compatible avec l'AMS 3.05 ?

Tu utilises des noms de variables qui évitent au maximum le risque de conflits!

* programmes "BASIC" dans lesquels une ligne sur 2 est un appel à un programme compilé (vertel, flib, Exec, ...), réunissant ainsi la lenteur du BASIC et le risque de plantages des langages compilés.

t'as toujours pas compris que vertel et flib permettent de faire des trucs qu'on peut pas faire en basic

Justement, dans ce cas, faut pas programmer en BASIC.
Pourquoi utiliser exprès un langage inadapté, c'est-à-dire un langage qui ne permet pas de faire ce qu'on veut faire?

et toujous à la fin du prog, ça suffit largement
[...]
bof, je vois pas qu'est-ce que ça peut te faire que le prog les change, s'il les restaure

La touche [ON], tu connais?

Oui, mais dans ce cas-là, on a affaire à un gros con d'user qui refuse d'utiliser le prog.

Prends des lettres grèques qui sont l'équivalent de la lettre latine correspondante, et tu pourras encore lire ce qu'il y a écrit.

T'as déjà regardé la lettre Sigma ?

Je pense qu'il y en a au moins 2 ou 3, et puis tu ne sais pas:
* ce que les versions futures de AMS vont rajouter comme noms,
* ce que les localisations de AMS vont utiliser comme noms (cf. aussi car, sh, ch, th qui créent des conflits avec la calculatrice en français).

Programmer en français, stou pourri.

* programmes qui n'utilisent pas Try pour effacer les variables globales, restaurer les modes, nettoyer l'écran etc. même en cas d'erreur. Il peut toujours y avoir une erreur à laquelle vous n'avez pas pensé, prévoyez cette éventualité et évitez de laisser traîner des cochonneries dans ce cas.

faut pas déconner, y a pas toujours des risques d'erreur. Si tu viens de créer la variable, tu peux êter sûr que tu pourras l'effacer

Bah non, tu n'as rien compris.
Je parle de:

:setGraph("Axes","OFF")
...
ligne produisant une erreur
...
:setGraph("Axes","ON")

qui laisse traîner le mode changé. Chose qui peut facilement être évitée:

:setGraph("Axes","OFF")
:Try
  ...
  ligne produisant une erreur
  ...
:Else
:  setGraph("Axes","ON")
:  PassErr
:EndTry
:setGraph("Axes","ON")

OSEF !!!!!!!! C'est au programmeur de faire gaffe à ce qu'il met comme commandes.

Justement, dans ce cas, faut pas programmer en BASIC.

Alors pourquoi faire des librairies pour améliorer le Basic ? Et les débutants en programmation ? T'as l'air de les ignorer complètement là.

Pourquoi utiliser exprès un langage inadapté, c'est-à-dire un langage qui ne permet pas de faire ce qu'on veut faire?

^42

[edit] : Balises cite foireuses

naPO
:

Prends des lettres grèques qui sont l'équivalent de la lettre latine correspondante, et tu pourras encore lire ce qu'il y a écrit.

T'as déjà regardé la lettre Sigma ?

Oui.

OSEF !!!!!!!! C'est au programmeur de faire gaffe à ce qu'il met comme commandes.

Il peut toujours se tromper, ou ne pas prévoir une entrée incorrecte de l'utilisateur!
Mettre un Try ne coûte rien et résout le problème de manière très simple et sans risque d'erreurs.

Justement, dans ce cas, faut pas programmer en BASIC.

Alors pourquoi faire des librairies pour améliorer le Basic ?

Pour les programmes qui en ont besoin à 2-3 endroits? Mais faire tout un programme "en Vertel", c'est idiot, autant le faire en C directement...

Et le débutants en programmation ? T'as l'air de les ignorer complètement là.

S'ils peuvent apprendre à utiliser une lib à syntaxe bizarre comme Vertel, ils peuvent apprendre le C aussi.

Et je ne réponds même pas à tes autres propos qui sont des trolls purs et nets.

Sauf que la syntaxe d'une lib ça n'est qu'une 30aine d'appels de fonction, incomparable avec l'apprentissage d'un langage. Et puis ça permet de programme oncalc sans trop de risques, vu que ces librairies doivent gérer les erreurs (idéalement, ne jamais planter, en pratique ça peut arriver mais ça reste très rare).

ligne produisant une erreur

Ne doit pas exister dans un programme en basic, l'argument ne tient pas debout.

Oh que si que ça existe!
Exemple tout bête: Tu as un dialogue, tu veux un nombre, l'utilisateur rentre "1/". expr va forcément te donner une erreur. Et il y a plein de cas comme ça. Tu ne peux pas prévoir tout ce que l'utilisateur va te rentrer comme conneries!
Autre exemple: tu demandes un nom de variable, l'utilisateur rentre pi...

Dans ce cas-là, le programmeur doit prévoir ce cas de figure. Donc ton argument ne tient pas, puisque c'est le programmeur ET LE PROGRAMMEUR seul qui doit se démerder avec différents profils d'utilisateurs.

Et comment, à part avec un Try?
Je ne comprendrai jamais les Try-phobes...

Je suis pas Try-phobe

Exemple :

Input "Entre un nombre positif entier de 1 à 10",nbr
abs(int(nbr))->nbr

Picétou

[edit] : Martial, non, pas krawç !!!!

Kevin Kofler :
Oh que si que ça existe!
Exemple tout bête: Tu as un dialogue, tu veux un nombre, l'utilisateur rentre "1/". expr va forcément te donner une erreur. Et il y a plein de cas comme ça. Tu ne peux pas prévoir tout ce que l'utilisateur va te rentrer comme conneries! Autre exemple: tu demandes un nom de variable, l'utilisateur rentre pi...

expr est un des rares cas qui peuvent planter un programme, et donc pour celui-ci le try peut être utilisé (c'est à peu près le seul moment d'ailleurs). Mais pas de changement de mode ici, uniquement "try:expr(var):else:message d'erreur:endtry". Sinon quand on demande un nom de variable, une boucle qui vérifie la chaine et teste si il est valide, c'est pas bien compliqué...

naPO > erreur.