G un problème avec ma ROM 2.05 - Page 1

Avec la Rom 2.05, g eu des problèmes pour installer CF, et pour y jouer aussi. A l'heure actuelle g seulement pus l'installer mais i manque un patch (soit disant compris dans la ROM) pour ne plus avoir "ASAP string to long". Ca m'ennerve, HELP!

PS: Je veux garder ma ROM 2.05 si possible et/ou garder la langue française.

Installe PreOs (version hw2tsr-tictex).

Ca sert à rien la version française ! Ca fait ke des bugs avec les progs en Basic !!!

Avec des programmes BASIC mal programmés peut-être. Avec des programmes BASIC bien programmés (choisissez "TI-BASIC" en haut à droite ), aucun problème!

Le "", tu peux l'adresser aux programmeurs BASIC qui se fichent des utilisateurs internationaux.

D'ailleurs, certains de mes programmes sont même traduits en 4 langues. Mais ils sont tous compatibles avec presque toutes les langues de AMS. (Je mets "presque" parce que CHEMISLV ne supporte pas encore le polonais. Il faudra que je le mette à jour.)

Bof, TIBASIC Powwaa!! Vive l'ASM!! Et tout ceux qui programment dans plusieurs langues !!

KK> po bien de ne pas se preoccuper plus que ca des utilisateurs polonais

Il va falloir que je ressorte CHEMISLV des oubliettes cet été, et ça sera une des corrections à faire.

C ompatible intenationnal : tous les utilisateurs on la langue anglaise disponible sur leur calc.

Mais c'est ch**nt de devoir changer de langue à chaque fois qu'on veut lancer un programme. Personnellement j'utilise toujours l'anglais, mais il y a des personnes qui voudraient pouvoir choisir leur langue maternelle dans AMS sans avoir des ennuis avec des programmes mal programmés.

Peut etre. Mais ca reste compatible (Je dis pas qu'il faut pas y penser néanmoins).

PpHd
a écrit : Peut etre. Mais ca reste compatible (Je dis pas qu'il faut pas y penser néanmoins).

pff fo surtout etre tres con pour mettre une autre langue ca prend de la place et ca sert a rien (a part s'attirer des ennuies)

Avec des programmes BASIC mal programmés peut-être

Autrement dit tes programmes sont les quasiment les seuls programmés proprement ? Je ne vois pas ça comme ça...
Avec ces histoires de multi-langue, ça fait des programmes lents et énormes. Il suffit de tockeniser avant la distribution, et ça passe. Ou encore de mettre sa calc en anglais comme le disais PpHd. Mais surement pas de sortir des progs avec des lignes de when() monstrueuses...

Bob 64
a écrit : Il suffit de tockeniser avant la distribution, et ça passe.

Justement non!
Je tokénise toujours mes programmes avant la distribution, et sans ça ils ne tourneraient jamais dans toutes les langues. Mais il y a des cas où ça ne suffit pas. Par exemple, la fameuse ligne de when dans CHEMISLV: C'est une situation où on est obligés d'utiliser expr parce que AMS ne comprend pas qqch. du genre:
{x,y,z}->liste
solve(x=0 and y=0 and y=0,liste)
Il faut faire:
{x,y,z}->liste
solve(x=0 and y=0 and y=0,{x,y,z})
et donc si le contenu de liste n'est pas connu à l'avance:
{x,y,z}->liste
expr("solve(x=0 and y=0 and y=0,"&string(liste)&")"
Seulement, comme tu peux voir, ici, solve est dans la chaîne de caractères, donc doit être traduit à la main. Et je ne vois pas comment faire ça sans utiliser un paquet de If ou de when.
Et puis tu oublies aussi que ceci ne marchera pas:
If getType(var1)="NONE"
Correct:
Local t
getType(t)->t
If getType(var1)=t
Là aussi, ce n'est pas une histoire de tokénisation.

Ah ouais c'est vrai j'avais oublié l'histoires des modes...
De toute façon au mieux tu stocke toutes les fonctions non compatibles dans des chaines pr prendre un minimum de place, mais même comme ça je trouve ça vraiment du gachi de place.

L'intermédiaire ça serait de faire un truc de detection, je ne sais pas avec quoi, peut-être avec gettype :
delvar zzzzzzzz
if gettype(zzzzzzzz)!="NONE"
text "Mettez votre calc en anglais bordel !"
stop
endif

Mais même ça j'aime pas trop... il suffit de marquer ds le readme que le prog ne fonctionne que si la calc est en anglais, voilà tout.

Bob 64 a écrit :
L'intermédiaire ça serait de faire un truc de detection, je ne sais pas avec quoi, peut-être avec gettype :
delvar zzzzzzzz
if gettype(zzzzzzzz)!="NONE"
text "Mettez votre calc en anglais bordel !"
stop endif

Au lieu de donner ce genre de messages d'erreur embêtants pour l'utilisateur, il vaut mieux programmer correctement!
C'est comme pour les programmes qui ne marchent que si on installe un autre programme appelé "kernel" avant: Ce genre de trucs m'énerve! Un programme doit fonctionner quelle que soit la configuration de l'utilisateur (langue anglaise ou autre, kernel installé ou pas, ...)!

Mais même ça j'aime pas trop... il suffit de marquer ds le readme que le prog ne fonctionne que si la calc est en anglais, voilà tout.

Bon alors:
Define mesure_g()=Prog:EndPrgm
Readme:

Ce programme mesure la constante g en le lieu précis où vous vous trouvez. Attention, ce programme ne fonctionne que si vous lancez votre calculatrice par la fenêtre, mesurez le temps qu'elle met pour tomber avec un chronomètre, mesurez la hauteur de votre fenêtre, et calculez g=2h/t², à la main évidemment parce que votre calculatrice sera vraisemblablement cassée.

D'après tes standards, ce genre de programmes serait tout à fait acceptable.

D'accord pour les kernel, mais reste dans la limite du raisonnable !!!
Tes histoires de progs compatibles c'est bien beau mais si c'est au détriment de leur qualité, non ! Je n'ai absolument pas envie de mettre sur ma calc un prog tout simple qui prends une place folle uniquement parcequ'il est compatible avec toutes les langues. Si ça t'amuse tellement de tout localiser, tu n'as qu'à faire des programmes séparés pour toutes les langues.
Des programmes énormes et exessivement lents, qu'ils soient localisés ou non ça n'a aucun interet. Tout le monde est capable de mettre sa calc en anglais.

Quand à ta comparaison je ne vois pas ce qu'elle fait ici... Tu peux m'expliquer le rapport entre prévenir des incompatibilité d'un programme et ton texte stupide ?

Bob 64
a écrit : Tes histoires de progs compatibles c'est bien beau mais si c'est au détriment de leur qualité, non !

Justement, un programme incompatible est un programme de mauvaise qualité!

Je n'ai absolument pas envie de mettre sur ma calc un prog tout simple qui prends une place folle uniquement parcequ'il est compatible avec toutes les langues.

Tu ne vas pas me dire que tu utilises un expr comme celui de CHEMISLV toutes les 3 lignes. Si c'est le cas, il faudra que tu revoies ton algorithme.
Pour le reste, c'est très simple de rester compatible avec toutes les langues. Il suffit de ne pas comparer avec des chaînes de caractères anglaises, mais d'utiliser getType sur une variable de type connu et de comparer avec ça.
En ce qui concerne les modes, tu ne vas pas me raconter que tu changes de mode toutes les 3 lignes. Si c'est le cas, là aussi, il y a un problème. En général, il est tout à fait possible de se passer complètement de changements de mode. (Mes programmes ne changent pratiquement jamais de mode.) Et puis ce qui est à mettre pour les modes n'est pas compliqué. Il suffit d'utiliser les modes numériques, dans un Try, et si ça échoue, utiliser les modes anglais (parce qu'il ne faut pas non plus négliger la compatibilité avec AMS 1).

Si ça t'amuse tellement de tout localiser, tu n'as qu'à faire des programmes séparés pour toutes les langues.

Ce n'est pas pratique non plus, parce que la langue peut être changée en tout moment et que c'est bête de devoir changer de programme à chaque fois qu'on change de langue.

Des programmes énormes et exessivement lents, qu'ils soient localisés ou non ça n'a aucun interet. Tout le monde est capable de mettre sa calc en anglais.

Si tu programmes ça correctement, tes programmes seront ni énormes ni excessivement lents. Regarde les miens pour avoir des exemples.

Quand à ta comparaison je ne vois pas ce qu'elle fait ici... Tu peux m'expliquer le rapport entre prévenir des incompatibilité d'un programme et ton texte stupide ?

C'est exactement la même chose. Ton programme ne marche que si on met la calculatrice en anglais, le mien ne marche que si on la jette par la fenêtre. Dans les 2 cas, il y a une précondition à respecter avant de pouvoir utiliser le programme.

Justement, un programme incompatible est un programme de mauvaise qualité !

Nan, au contraire un programme incompatible est un programme optimisé pour une seule langue

Tu ne vas pas me dire que tu utilises un expr comme celui de CHEMISLV toutes les 3 lignes. Si c'est le cas, il faudra que tu revoies ton algorithme.
Pour le reste, c'est très simple de rester compatible avec toutes les langues. Il suffit de ne pas comparer avec des chaînes de caractères anglaises, mais d'utiliser getType sur une variable de type connu et de comparer avec ça. En ce qui concerne les modes, tu ne vas pas me raconter que tu changes de mode toutes les 3 lignes. Si c'est le cas, là aussi, il y a un problème. En général, il est tout à fait possible de se passer complètement de changements de mode. (Mes programmes ne changent pratiquement jamais de mode.) Et puis ce qui est à mettre pour les modes n'est pas compliqué. Il suffit d'utiliser les modes numériques, dans un Try, et si ça échoue, utiliser les modes anglais (parce qu'il ne faut pas non plus négliger la compatibilité avec AMS 1).

Je ne change quasiment jamais les modes ds un prog (sauf exact approx, mais une seule fois et au début). Mais même si ça ne rajoute pas grand-chose (et encore, ta ligne de expr n'est pas négligeable..) je refuse de salir mes progs avec quelque chose d'aussi inutile qu'une localisation multilingue.

Ce n'est pas pratique non plus, parce que la langue peut être changée en tout moment et que c'est bête de devoir changer de programme à chaque fois qu'on change de langue.

Tiens tu viens de le dire toi même : la langue peut être changée à tout moment. Alors autant la changer en anglais avant d'executer des progs.

Si tu programmes ça correctement, tes programmes seront ni énormes ni excessivement lents. Regarde les miens pour avoir des exemples.

Justement qu'est-ce que tu crois ? Je suis allé voir tes programmes et c'est essenciellement sur eux que je me base, étant donné que tu es le seul que je connaisse qui localise tout comme ça... Et franchement tu devrais arrêter tu gagnerais quelques centaines d'octets dans tous tes progs.

C'est exactement la même chose. Ton programme ne marche que si on met la calculatrice en anglais, le mien ne marche que si on la jette par la fenêtre. Dans les 2 cas, il y a une précondition à respecter avant de pouvoir utiliser le programme.

Il me semble quand même quand changer la langue est quelque peu moins contraignant que jeter sa calculatrice par la fenêtre, et que donc comme je le disais ta comparaison est stupide. Ou alors tu es très riche, ou encore ta méthode pour changer la langue n'est pas au point... Sur ma calculatrice quelques touches suffisent

Bob 64 a écrit :
Nan, au contraire un programme incompatible est un programme optimisé pour une seule langue

Et mon programme mesure_g, il est optimisé pour une calculatrice jetée par la fenêtre.
Non, sérieusement: ce que tu n'as pas compris, c'est qu'il y a des qualités plus importantes que l'optimisation, et la compatibilité en fait partie.

Je ne change quasiment jamais les modes ds un prog (sauf exact approx, mais une seule fois et au début).

Tu devrais utiliser exact( ou approx( à chaque calcul où c'est important, ça t'éviterait de changer de mode.

Mais même si ça ne rajoute pas grand-chose (et encore, ta ligne de expr n'est pas négligeable..)

Comme j'ai dit, c'est un cas particulier qui ne devrait pas souvent être nécessaire.

je refuse de salir mes progs avec quelque chose d'aussi inutile qu'une localisation multilingue.

Tu emploies mal le terme "localisation" là. Localiser ton programme voudrait dire traduire le programme lui-même. Mes programmes ne sont pas tous localisés, et ceux qui le sont sont localisés en 4 langues seulement. Mais ils sont compatibles avec la localisation de AMS. C'est différent!

Et ce n'est pas du tout inutile d'être compatibles!

Tiens tu viens de le dire toi même : la langue peut être changée à tout moment. Alors autant la changer en anglais avant d'executer des progs.

Non, c'est vraiment hyper-ch**nt de devoir à chaque fois aller dans le menu mode pour lancer le programme et rechanger après!!!

Justement qu'est-ce que tu crois ? Je suis allé voir tes programmes et c'est essenciellement sur eux que je me base, étant donné que tu es le seul que je connaisse qui localise tout comme ça... Et franchement tu devrais arrêter tu gagnerais quelques centaines d'octets dans tous tes progs.

Je m'en contrefiche de ces quelques centaines d'octets!!! Tu n'as pas compris??? Il y a des choses plus importantes que gagner quelques octets, et l'absence de bogues en est une!!! Et pour moi, un programme qui ne tourne pas si je mets AMS en hongrois ou en finlandais est bogué!

Il me semble quand même quand changer la langue est quelque peu moins contraignant que jeter sa calculatrice par la fenêtre, et que donc comme je le disais ta comparaison est stupide. Ou alors tu es très riche, ou encore ta méthode pour changer la langue n'est pas au point... Sur ma calculatrice quelques touches suffisent

Et je te signale d'ailleurs qu'il n'y a pas que mes programmes BASIC qui ont dû être rendus compatibles avec les localisations de AMS. Ça concerne aussi XtraKeys. Installe XtraKeys, mets ta calculatrice en anglais et tape [SHIFT]+[F3] (TI-89) ou [DIAMOND]+[COS] (TI-92+/V200). Maintenant mets ta calculatrice en français et tape la même combinaison de touches. Tu verras que la chaîne de caractères a été traduite automatiquement. Tout ça parce que j'ai enrgistré la chaîne au format tokénisé, et que je la détokénise à chaque fois, pour que ça marche dans toutes les langues.

Non, sérieusement: ce que tu n'as pas compris, c'est qu'il y a des qualités plus importantes que l'optimisation, et la compatibilité en fait partie.

Premièrement je te vois encore écrire : "le basic est suffisament lent comme ça, arrêtez de le ralentir encore plus", deuxièmement quand c'est pour ce genre de compatibilité, non désolé l'optimisation me semble BEAUCOUP plus importante.

Tu devrais utiliser exact( ou approx( à chaque calcul où c'est important, ça t'éviterait de changer de mode.

Arf ok je commence à comprendre ta notion de l'optimisation

Comme j'ai dit, c'est un cas particulier qui ne devrait pas souvent être nécessaire.

Même utilisé une seule fois, c'est une fois de trop... Vu la taille qu'elle prends et la vitesse à laquelle elle doit se résoudre...

Non, c'est vraiment hyper-ch**nt de devoir à chaque fois aller dans le menu mode pour lancer le programme et rechanger après!!!

C'est également hyper-chiant d'avoir des programmes lents... Ceux en basic mal programmés le sont, alors les tiens qui doivent être quand même de bonne qualité, ne vas pas les gâcher avec ça !

Je m'en contrefiche de ces quelques centaines d'octets!!! Tu n'as pas compris??? Il y a des choses plus importantes que gagner quelques octets, et l'absence de bogues en est une!!! Et pour moi, un programme qui ne tourne pas si je mets AMS en hongrois ou en finlandais est bogué!

Tu devrais filtrer les programmes qui rentre à ticalc et ti-fr selon tes critères, ça diminuerais la taille des archives de façon radicale
Nan plus serieusement, tu n'as pas l'impression d'être le seul à faire ça ? Et si tu t'en est rendu compte (ça serait déjà une bonne chose...) tu ne t'es pas demandé POURQUOI tous ces programmeurs ne font pas comme TOI ? Est-tu vraiment persuadé d'être le seul qui a raison parmis ce tas d'idiots qui font des programmes non compatibles avec le hongrois et le polonais ?

Bob 64
a écrit : Même utilisé une seule fois, c'est une fois de trop... Vu la taille qu'elle prends et la vitesse à laquelle elle doit se résoudre...

J'ai mesuré la vitesse de CHEMISLV pour toutes les versions et cette ligne-là ne l'a même pas ralenti d'une seconde par équation-bilan (c'est de l'ordre de grandeur de quelques fractions de seconde seulement). Je te signale aussi que cette ligne est exécutée une seule fois par équation-bilan à équilibrer.

C'est également hyper-chia
nt d'avoir des programmes lents... Ceux en basic mal programmés le sont, alors les tiens qui doivent être quand même de bonne qualité, ne vas pas les gâcher avec ça !

Ils n'ont pas ralenti de façon mesurable quand j'ai rajouté la compatibilité avec la localisation de AMS!

Tu devrais filtrer les programmes qui rentre à ticalc et ti-fr selon tes critères, ça diminuerais la taille des archives de façon radicale

J'aurais bien envie de le faire. Si un programme plante, nécessite un kernel ou ne marche pas avec une certaine langue, rm -f programme.

Nan plus serieusement, tu n'as pas l'impression d'être le seul à faire ça ? Et si tu t'en est rendu compte (ça serait déjà une bonne chose...) tu ne t'es pas demandé POURQUOI tous ces programmeurs ne font pas comme TOI ? Est-tu vraiment persuadé d'être le seul qui a raison parmis ce tas d'idiots qui font des programmes non compatibles avec le hongrois et le polonais ?

J'ai l'impression que les programmeurs BASIC qui font des programmes incompatibles avec la localisation sont soit ignorants de ce problème et/ou de sa solution (ça doit être le cas pour la plupart vu que les programmeurs BASIC sont souvent des "newbies"), soit paresseux (ce que franchement je suspecte d'être ton cas).

J'ai mesuré la vitesse de CHEMISLV pour toutes les versions et cette ligne-là ne l'a même pas ralenti d'une seconde par équation-bilan (c'est de l'ordre de grandeur de quelques fractions de seconde seulement). Je te signale aussi que cette ligne est exécutée une seule fois par équation-bilan à équilibrer.

Bon déjà je ne sais pas combien ça met de temps à résoudre une équation bilan, donc je ne peux pas évaluer cette "même pas une seconde". Ensuite de toute façon c'est un ralentissement, point.

Ils n'ont pas ralenti de façon mesurable quand j'ai rajouté la compatibilité avec la localisation de AMS!

Encore heureux qu'ils ne soient pas devenus deux fois plus lents !!! Mais ils ont ralenti, et même un peu c'est ça qui compte. Et ils ont "prit du poids" aussi.

J'aurais bien envie de le faire. Si un programme plante, nécessite un kernel ou ne marche pas avec une certaine langue, rm -f programme.

Ben tiens... Tu ferais un bon webmaster toi. A part tes programmes, lesquels sont multilingue ? Quasiment aucun... Et pourtant malgré cette absence de "concurence", je ne pense pas que CHEMISLV soit le programme BASIC le plus connu et le plus répendu. Tu vois ou je veux en venir...

...soit paresseux (ce que franchement je suspecte d'être ton cas).

Hum... Autant en C je ne suis pas près de débattre avec toi, autant la si, et je ne vais pas m'en priver. Comparé à la taille de certains de mes programmes, l'ajout du support multilingue est dérisoire (même si ça prenait 1Ko de plus, c'est rien comparé au reste). Et vu le temps que je passe parfois à les faire, je trouve ta remarque quelque peu déplacée ! De plus rendre son prog compatible avec les langues n'a absolument rien de difficile, c'est à la portée de presque n'importe quel newbie. Si personne ne le fait c'est tout simplement parceque personne n'en voit l'utilité. Tous les utilisateurs de Ti, après un certain nombre de plantages, laissent leur calc en anglais.

Bob 64
a écrit : Bon déjà je ne sais pas combien ça met de temps à résoudre une équation bilan, donc je ne peux pas évaluer cette "même pas une seconde".

CHEMISLV nécessite dans l'ordre de 10-100 secondes selon l'équation-bilan. Pour celle que j'ai mesurée, ce sont 20 secondes.

Ensuite de toute façon c'est un ralentissement, point.

Et tu le prouves comment vu que tu ne peux pas le mesurer.
Et même si ça en est un, un ralentissement qu'on ne peut même pas mesurer avec un chronomètre est absolument imperceptible pour un être humain, donc totalement négligeable. Une optimisation qui ne donne pas une accéleration mesurable ne vaut pas le coup d'être effectuée. Et en aucun cas, une différence de vitesse non mesurable ne doit-elle être la raison pour négliger la compatibilité!

Encore heureux qu'ils ne soient pas devenus deux fois plus lents !!! Mais ils ont ralenti, et même un peu c'est ça qui compte.

Ils n'ont pas ralenti de manière mesurable, point final.
Une mesure de vitesse, c'est de la physique. Et en physique, si 2 mesures de vitesse donnent le même résultat, ça veut dire le programme n'a pas ralenti entre les 2 mesures, quoiqu'en dise la théorie.

Et ils ont "prit du poids" aussi.

Les fonctionnalités prennent de la place, c'est normal! Et la compatibilité avec la localisation de AMS, c'est une fonctionnalité.
Et la place supplémentaire prise est très petite par rapport à la taille totale du programme. Dans CHEMISLV (je viens de vérifier), la différence est de moins de 6%, et encore:
- Il y a une ligne problématique qui prend beaucoup de place si on la traduit, et qui se fait remarquer parce que c'est un programme relativement petit.
- J'ai aussi rajouté une aide syntaxique pour chacun des 9 programmes/fonctions qui composent CHEMISLV quand j'ai travaillé sur la compatibilité avec AMS 2, et la différence de taille est surtout due à ça, pas à la localisation.

Ben tiens... Tu ferais un bon webmaster toi. A part tes programmes, lesquels sont multilingue ? Quasiment aucun... Et pourtant malgré cette absence de "concurence", je ne pense pas que CHEMISLV soit le programme BASIC le plus connu et le plus répendu. Tu vois ou je veux en venir...

C'est parce que les programmeurs paresseux n'arrêtent pas de diffuser des rumeurs qui justifient leur paresse et/ou font peur à ceux qui veulent mettre leur calculatrice en leur langue maternelle. Style:

Ne mets pas le français, c'est une merde de toute façon, ça fait boguer ta calculatrice, et plus aucun programme ne marche.

(Je paraphrase, mais c'est à peu près ce que je lis parfois.)
C'est vraiment dommage de voir des utilisateurs contraints à mettre leur calculatrice en une langue étrangère à cause de la paresse et/ou de l'entêtement de certains programmeurs BASIC.

Hum... Autant en C je ne suis pas près de débattre avec toi, autant la si, et je ne vais pas m'en priver. Comparé à la taille de certains de mes programmes, l'ajout du support multilingue est dérisoire (même si ça prenait 1Ko de plus, c'est rien comparé au reste).

Ce qui montre bien que ton argument de taille est bidon.

Et vu le temps que je passe parfois à les faire, je trouve ta remarque quelque peu déplacée !

Tu n'es peut-être pas trop paresseux pour faire un programme, mais tu es soit trop paresseux, soit trop entêté pour le rendre compatible avec la localisation de AMS.

De plus rendre son prog compatible avec les langues n'a absolument rien de difficile, c'est à la portée de presque n'importe quel newbie.

Ben non. Beaucoup de personnes ne savent pas qu'il ne faut pas utiliser "NONE", ou s'ils le savent, ne savent pas par quoi le remplacer! Tu es vraiment mal parti si tu penses sérieusement que si tellement de programmes BASIC ne marchent qu'avec AMS en anglais, c'est parce que tout le monde est aussi entêté que toi!

Si personne ne le fait c'est tout simplement parceque personne n'en voit l'utilité. Tous les utilisateurs de Ti, après un certain nombre de plantages, laissent leur calc en anglais.

1. Quels plantages?
2. Parce que vous les y obligés! Soit à travers vos programmes, soit à travers les rumeurs et les attaques "FUD" (= fear, uncertainity and doubt = attaque qui fait règner la peur, l'incertitude et le doûte) contre l'application TIFRA sur le forum.

Et tu le prouves comment vu que tu ne peux pas le mesurer

Tu me l'as dit toi même... Et puis si dans un prog ou on attends 20 secondes ça passe, dans quelque chose de plus rigoureux comme un jeu, on ne peut pas se permettre de perdre une seconde ou même une demi seconde par cycle.

Ils n'ont pas ralenti de manière mesurable, point final. Une mesure de vitesse, c'est de la physique. Et en physique, si 2 mesures de vitesse donnent le même résultat, ça veut dire le programme n'a pas ralenti entre les 2 mesures, quoiqu'en dise la théorie.

Tu as rajouté des lignes de codes dans ton programme, il est donc forcément plus lent (enfin non pas forcément, mais dans le cas présent, si)

C'est vraiment dommage de voir des utilisateurs contraints à mettre leur calculatrice en une langue étrangère à cause de la paresse et/ou de l'entêtement de certains programmeurs BASIC

L'APP Français est une idiotie inventée par Texas, ça n'aurait jamais du exister et ça n'apporte aucun avantage. A partir de la, moi je prog sur la seule configuration "normale" : la calc en anglais.

Ce qui montre bien que ton argument de taille est bidon

Bah non : 1Ko de plus c'est jamais bon à prendre, et comme la je peux m'en passer, je ne m'en prive pas.

Tu n'es peut-être pas trop paresseux pour faire un programme, mais tu es soit trop paresseux, soit trop entêté pour le rendre compatible avec la localisation de AMS

Ah parceque c'est moi qui est entêté ?
Pourtant il me semble bien que tu es le seul à soutenir que le multilingue est une bonne chose

Tu es vraiment mal parti si tu penses sérieusement que si tellement de programmes BASIC ne marchent qu'avec AMS en anglais, c'est parce que tout le monde est aussi entêté que toi!

Il y a ici sur yN un bon nombre de programmeurs BASIC, qui sont tous très bien capables de rendre un programme compatible. Mais pas un seul ne le fait. Tu crois vraiment que c'est par paresse ?

1. Quels plantages?

Bon ok je vois... Alors je vais économiser 2 posts :
- He bien les plantages dus à des programmes ASM
- Ils n'ont qu'à utiliser les programmes de la TICT

2. Parce que vous les y obligés! Soit à travers vos programmes, soit à travers les rumeurs et les attaques "FUD" (= fear, uncertainity and doubt = attaque qui fait règner la peur, l'incertitude et le doûte) contre l'application TIFRA sur le forum.

Nan c'est parceque comme ça leur calc est compatible avec tous les programmes
Je sais on tourne en rond, mais ça marche très bien comme ça, alors...

Bob 64
a écrit : - He bien les plantages dus à des programmes ASM.

non, c'est inexact.
il fallait dire

Et bien les plantages dus à des programmes ASM en mode kernel.

et puis il existe au moins ne quinzaine d'APPs de localisation
rendre les progs basics compatibles pour toutes ces APPs est une tache tres difficile, voir impossible. (meme quelqu'un qui parle beaucoup de langues comme toi, kevin, ne peu pas connaitre l'ensemble des langues qui ont une localisation pour AMS)
Or -d'apres toi- un prog est mal programmé si on doit changer la langue de la calculatrice.
Donc aucun (je pense vraiment avoir raison en disant aucun) prog en ti-basic dispo sur dans l'univers n'est bien programmé, car aucun n'est compatible avec toutes les langues.

mais il y a un moyen tres simple de rendre TOUS les progs basic de la galaxie compatible avec sa calc, et ce moyen est de la mettre en anglais (qui est, on peu le dire la langue native de la 89).
et ce n'est parceque TI créé quelquechose qu'il faut absolument defendre celle chose, surtout quand elle est source d'incompatibilité (et ne dis pas que c'est une rumeur, c'ets une vérité, et qui a été prouvé par les plus grands chercheurs de la NASA)

Bob 64
a écrit : Tu me l'as dit toi même... Et puis si dans un prog ou on attends 20 secondes ça passe, dans quelque chose de plus rigoureux comme un jeu, on ne peut pas se permettre de perdre une seconde ou même une demi seconde par cycle.

Tu calcules les chaînes traduites au début, et après tu utilises la variable locale où tu les as mises au lieu de mettre la chaîne directement, comme ça tu ne perds pas de temps dans la boucle.

Tu as rajouté des lignes de codes dans ton programme, il est donc forcément plus lent (enfin non pas forcément, mais dans le cas présent, si)

J'ai bien dit: une mesure de vitesse, c'est de la physique, et en physique, la théorie ne compte pas. Tu ne peux pas dire que le programme a ralenti sans avoir des mesures qui le prouvent.

L'APP Français est une idiotie inventée par Texas, ça n'aurait jamais du exister et ça n'apporte aucun avantage. A partir de la, moi je prog sur la seule configuration "normale" : la calc en anglais.

Ça, c'est l'excuse des programmeurs paresseux. C'est facile de dire que tout ce qui rend la programmation légèrement plus compliquée (tout en rendant l'utilisation de la calculatrice bien plus facile aux utilisateurs!) est une "idiotie" et de ne pas porter ses programmes vers ces configurations.

Bah non : 1Ko de plus c'est jamais bon à prendre, et comme la je peux m'en passer, je ne m'en prive pas.

1 KO de plus ou de moins sur un programme d'une dizaine ou d'une centaine de KO n'a aucune importance en pratique. Tu sembles manquer de tout sens des relations!

Ah parceque c'est moi qui est entêté ?
Pourtant il me semble bien que tu es le seul à soutenir que le multilingue est une bonne chose

Je ne dis pas que son implémentation est idéale, mais je dis que l'implémentation est comme elle est et qu'il faut rendre les programmes compatibles avec ce qu'il y a.

Il y a ici sur yN un bon nombre de programmeurs BASIC, qui sont tous très bien capables de rendre un programme compatible. Mais pas un seul ne le fait.

Pas un seul??? Je n'existe pas pour toi?
Et à ta place, je ne serais pas aussi certain que ça qu'il n'y a que moi qui rend ses programmes compatibles avec la localisation de AMS.

Tu crois vraiment que c'est par paresse ?

Soit par paresse, soit parce qu'il y a des gens comme toi qui entérinent à tous les newbies que la localisation de AMS, c'est de la merde, que c'est très compliqué de rendre ses programmes compatibles avec la localisation de AMS et que ça rend les programmes 2 fois plus gros et 10 fois plus lents. Rien de tout ceci n'est le cas!

Bon ok je vois... Alors je vais économiser 2 posts : - He bien les plantages dus à des programmes ASM

Je ne vois pas du tout le rapport avec la localisation de AMS!

Nan c'est parceque comme ça leur calc est compatible avec tous les programmes Je sais on tourne en rond, mais ça marche très bien comme ça, alors...

C'est ça le problème. Tu oses avoir l'arrogance de demander qu'on rende sa calculatrice compatible avec tes programmes (en la mettant en une langue étrangère plutôt qu'en sa langue maternelle) plutôt que de rendre tes programmes compatibles avec les calculatrices des autres!

azerty83 a écrit :
et puis il existe au moins ne quinzaine d'APPs de localisation rendre les progs basics compatibles pour toutes ces APPs est une tache tres difficile, voir impossible. (meme quelqu'un qui parle beaucoup de langues comme toi, kevin, ne peu pas connaitre l'ensemble des langues qui ont une localisation pour AMS)

C'est totalement faux. Dans la plupart des cas, on n'est même pas obligés de mettre une langue sur sa calculatrice pour rendre ses programmes compatibles avec cette langue! Il suffit de remplacer les chaînes anglaises comme "NONE" par quelque chose qui les calcule (par exemple Local t:getType(t)->t), ou dans le cas des modes, par l'équivalent numérique que AMS 2 met à disposition exprès pour ça! (Pour AMS 1, on met un Try autour des utilisations des modes numériques, et dans leur Else, on met l'équivalent anglais - AMS 1 n'est pas localisable de toute façon.) Et hop, le programme marche avec toutes les localisations disponibles.
Pour CHEMISLV, j'ai été obligé d'essayer toutes les langues (à cause d'un expr("solve("&...) duquel je n'ai pas pu me passer parce que AMS ne comprend pas solve(equation,liste) avec liste une variable qui contient une liste de variables, il faut lui donner la liste directement), mais ça n'a pas du tout été un problème. Je connais l'interface de la TI-89 par cœur, donc bien que je ne connaisse pas un seul mot de hongrois par exemple, je n'ai aucun problème à utiliser ma TI-89 en hongrois pour le peu de temps nécessaire pour relever la traduction de 2 ou 3 chaînes de caractères!

Or -d'apres toi- un prog est mal programmé si on doit changer la langue de la calculatrice. Donc aucun (je pense vraiment avoir raison en disant aucun) prog en ti-basic dispo sur dans l'univers n'est bien programmé, car aucun n'est compatible avec toutes les langues.

Tu as tord! Tous mes programmes BASIC sauf CHEMISLV sont compatibles avec toutes les langues de AMS. CHEMISLV est compatible avec toutes les langues de AMS sauf le polonais, parce que la localisation en polonais est sortie après toutes les autres et que je n'ai pas encore pris le temps de traduire la ligne qui doit être traduite à la main.
Certains de mes programmes sont d'ailleurs eux-mêmes traduits en les 4 langues que je parle, et ils se mettront automatiquement en français si tu mets AMS en français par exemple. Et si on met AMS en une langue que le programme ne parle pas, le programme marche parfaitement, mais affiche ses messages en anglais. Ceci dit, j'ai aussi prévu la possibilité de choisir une langue différente que celle d'AMS, pour que des personnes peuvent utiliser mon programme en français avec AMS en anglais par exemple.

mais il y a un moyen tres simple de rendre TOUS les progs basic de la galaxie compatible avec sa calc, et ce moyen est de la mettre en anglais (qui est, on peu le dire la langue native de la 89).

Ma réponse au dernier paragraphe de Bob64 s'applique aussi ici, je ne la répèterai pas.

et ce n'est parceque TI créé quelquechose qu'il faut absolument defendre celle chose, surtout quand elle est source d'incompatibilité (et ne dis pas que c'est une rumeur, c'ets une vérité, et qui a été prouvé par les plus grands chercheurs de la NASA)

La NASA, que vient-elle à faire là-dedans?

Et il y a exactement 11 applications de localisation, pas "au moins une quinzaine" comme tu as prétendu sans aller vérifier, azerty83.

Tu calcules les chaînes traduites au début, et après tu utilises la variable locale où tu les as mises au lieu de mettre la chaîne directement, comme ça tu ne perds pas de temps dans la boucle

Si : l'appel de la variable et l'expr()

J'ai bien dit: une mesure de vitesse, c'est de la physique, et en physique, la théorie ne compte pas. Tu ne peux pas dire que le programme a ralenti sans avoir des mesures qui le prouvent.

Arrête de jouer l'ignorant, tu sais aussi bien que moi que rendre son programme compatible avec toutes les langues ne peut que le ralentir !!!

1 KO de plus ou de moins sur un programme d'une dizaine ou d'une centaine de KO n'a aucune importance en pratique. Tu sembles manquer de tout sens des relations!

Si justement : 1ko = pas très important, multilingue = encore moins important + perte de vitesse. Mon choix est vite fait !

Je ne dis pas que son implémentation est idéale, mais je dis que l'implémentation est comme elle est et qu'il faut rendre les programmes compatibles avec ce qu'il y a.

Pour les ordinateurs tu veux aussi que TOUS les programmes soient compatibles avec TOUS les systèmes d'exploitation ? Arrête de dire n'importe quoi. Un programme est dans une grande majorité des cas spécifique à un seul système et c'est très bien comme ça. Pour les calc c'est pareil, presque tous les programmes sont pour l'anglais.

Pas un seul??? Je n'existe pas pour toi?

Ormis toi bien sûr...

Et à ta place, je ne serais pas aussi certain que ça qu'il n'y a que moi qui rend ses programmes compatibles avec la localisation de AMS.

Vas-y présente moi tes semblables, et interdiction de créer de nouveaux pseudos

Soit par paresse, soit parce qu'il y a des gens comme toi qui entérinent à tous les newbies que la localisation de AMS, c'est de la merde, que c'est très compliqué de rendre ses programmes compatibles avec la localisation de AMS et que ça rend les programmes 2 fois plus gros et 10 fois plus lents. Rien de tout ceci n'est le cas!

On exagère pour les convaincre, mais l'idée generale est vraie.

Je ne vois pas du tout le rapport avec la localisation de AMS!

C'est toi qui me demande "quels plantages ?", alors je réponds...

C'est ça le problème. Tu oses avoir l'arrogance de demander qu'on rende sa calculatrice compatible avec tes programmes (en la mettant en une langue étrangère plutôt qu'en sa langue maternelle) plutôt que de rendre tes programmes compatibles avec les calculatrices des autres!

C'est pas pas MA langue, c'est la langue universelle !!! Alors comme tout le monde je m'y plie, voilà tout !


Bon Azerty a pas l'air doué pour les débats () mais il est quand même une 3l33t en basic, donc il peut très bien continuer à ma place. Moi je m'en vais, ceci est donc mon dernier post avant un mois.

Bye !