Forum TI-Planet.org

Un des gros défauts du langage de programmation Lua à sa sortie était l'absence d'éditeur pour calculatrice.
Tout développement ou modification d'un script Lua nécessitait de faire appel au logiciel TI-Nspire et donc d'avoir un ordinateur à portée de main, ce qui n'est pas toujours le cas notamment en situation nomade.

Plusieurs outils communautaires étaient sortis afin de contourner ce problème, mais aucun ne n'avait su s'imposer à cause de divers défauts.

On peut citer LuaTerm du célèbre Jimbauwens, sorti début juin 2011. Il se présente sous la forme d'une ligne de commande (console ou encore terminal si vous préférez). En utilisant la commande load(), il est possible d'exécuter du code Lua enregistré dans une variable au choix de type chaîne de caractères. Ces chaînes de caractères sont donc à éditer avec les fonctionnalités standard de l'OS dans un onglet de calculs, ce qui est effectivement lourd et peu pratique...


LUA onCalc de Dyar est sorti fin juin 2011 et reprend le même principe, mais se débarrasse de la console (qui était très loin d'être intuitive, et perturbait les sorties graphiques). La procédure est donc bien plus automatisée, les noms de chaînes de caractères devenant statiques.

Oclua d'ExtendeD sorti en juillet 2011, rajoute lui un véritable éditeur de code Lua. Il est possible ensuite d'enregistrer le code dans un onglet de votre classeur par simple copier/coller, exactement comme l'on procède avec l'outil officiel préliminaire sur PC avec les logiciels Nspire. Sans doute y a-t-il eu au moins étude du format de ce que cet outil enregistrait dans le presse-papiers, ou au plus décompilation/désassemblage de cet outil. Mais ce copier/coller à faire à chaque modification devient rapidement une procédure lourde et peu naturelle...


Yatto lui avait commencé LuaCS, un éditeur avec coloration syntaxique, mais l'a hélas abandonné dans un état non final.




Mais heureusement, voici venir le nouvel outil révolutionnaire de Nadrieril Feneanar, TIDE.
TIDE se compose de deux parties:

• un éditeur de code Lua en onglet 1.1
• un évaluateur de code Lua en onglet 1.2

Plus besoin de copier/coller ou d'autre manipulation non naturelle - toute insertion ou modification de code Lua dans l'onglet 1.1 est immédiatement répercutée dans l'onglet 1.2!




Un superbe outil qui pourrait t'être très utile dans le cadre de notre concours TI-Planet été 2013!




Lien:
TIDE

Source: CompassTech

Ca peut servir pour le concours ca ?

Si tu veux développer la partie Lua directement sur calculatrice et non sur ordinateur ou tablette, alors oui.

Evidemment que je veux j'aime pas programmer sur l'ordi... ^^ merci pour cet outil en tout cax !

Oh my god !
Tout vient à point à qui sait attendre...
Enfin, je vais pouvoir me mettre au Lua (mince, l'Axe va encore passer à la trappe, désolé nikitouzz) : moi aussi j'ai horreur de programmer ailleurs que sur calculette...

Ça tombe vraiment bien pour le concours !

Est-il possible d'ouvrir un script existant ? (Je n'ai pas encore testé)

Parce que ce n'était pas possible avec Oclua, et c'est surtout ce genre de fonctionnalité qui serait utile pour le concours, puisqu'il s'agit d'éditer un script existant, pas d'en créer un de zéro...

Non. Pour bosser sur un script existant tu dois commencer par le coller dans l'éditeur.

Je pense que le vrai problème d'Oclua n'était pas de devoir faire CTRL C puis CTRL V, ce qui ne prend pas beaucoup de temps, mais d'interférer avec certains évènements, notamment celui du presse-papier puisqu'il le capte déjà. Quand à LuaCS, il me semblât tout à fait logique que son auteur cesse son développement étant donnée la lenteur de l'éditeur. En effet, le Lua est bien trop lent pour programmer en ce langage sur la TI-Nspire un éditeur à coloration syntaxique.

Quand à ce nouveau programme, l'inconvénient majeur ne fait aucun doute : il ne fonctionne pas sur OS 3.1.

La seule vraie solution d'éditeur Lua serait, je pense, que ce soit TI qui le code, en natif.

En fait, je crois que LuaCS a un problème qui résulte d'une mauvaise programmation de ma part. Quand, par exemple, je charge le code source de LuaCS dans LuaCS (qui fait dans les 800 lignes), sur les lignes 1 à 50 y'a aucun problème, c'est très fluide, mais à la fin du document il faut attendre parfois plusieurs minutes pour changer un caractère. Je crois que c'est pas normal.

Le code source est à disposition pour qui veut essayer d'y farfouiller un peu. Comme j'ai pas mal oublié le Lua, je ne pense pas pouvoir tenter de résoudre ça tout de suite.

N'empêche, la concurrence stimule la créativité. J'y jetterai un coup d'oeil un de ces quatre (avec les vacances, tout ça).

D'ailleurs, je serais curieux de voir comment TIDE se comporte avec un code source de 800 lignes !!!

yatto wrote:En fait, je crois que LuaCS a un problème qui résulte d'une mauvaise programmation de ma part. Quand, par exemple, je charge le code source de LuaCS dans LuaCS (qui fait dans les 800 lignes), sur les lignes 1 à 50 y'a aucun problème, c'est très fluide, mais à la fin du document il faut attendre parfois plusieurs minutes pour changer un caractère. Je crois que c'est pas normal.

Je viens de regarder un peu comment marche le Lua aujourd'hui, et ça m'étonnerait pas que ce soit à cause de la façon dont les tableaux sont gérés dans ce langage. C'est pas juste comme en C où tous les éléments du tableau sont de taille identique et indexés par un nombre.

Je ne sais pas comment ça marche exactement, mais peut-être que quand tu lui dis "Je veux le 4013e caractère" il ne va pas chercher directement le 4013e élément du tableau, mais tous les parcourir un par un jusqu'à trouver le 4013e. Alors forcément ça met du temps. Et comme c'est on-calc, la vitesse laisse à désirer.