Forum TI-Planet.org

Salut à tous,

Tout ceux qui se sont essayé à la programmation Lua avant la version 3.2 connaissent déja Luna, l'outil, par Extended, qui permet de créer un fichier .tns ouvrable depuis n'importe quelle OS 3.X contenant un script Nspire-Lua, à partir du code source en .lua.
Et bien depuis la mise-à-jour de la gamme Nspire en version 3.2, TI a changé quelques trucs et les fichiers générés par Luna ne pouvaient pas profiter des nouveautés apportés dans l'API Lua 3.2, car le platform.apilevel était forcé à "1.0" (C'est ce qui se passe quand vous essayez d'ouvrir un document Lua enregistré avec TINCS 3.1 par exemple).

C'est maintenant du passé, puisque comme nous l'apprend le blog d'Extended, la dernière version de Luna (0.3 à ce jour) gère désormais la version 3.2 et permet donc, quelque soit l'OS, de générer des fichiers .tns contenant des scripts Lua non restreints par un apilevel forcé.
Plus besoin donc de créer multiples versino pour différents OS
(Il faudra cependant dans son code tenir compte du fait que le script peut tourner sur différentes version d'OS, donc faites un test pour la connaître (par exemple : if require then deviceOS = "3.2" end))

On note aussi que cette dernière version supporte la totalité des caractères spéciaux UTF-8, chose qui pouvait poser problème auparavant... (Faites bien attention à sauver vos fichier .lua en encodage UTF-8 donc, pour en profiter )

Merci Extended !


Téléchargement :
Luna v0.3

J'ai une erreur quand je veux ouvrir un fichier compilé par Luna. (Il s'agit du source de LuaCS)

Ma Nspire m'affiche: "Une erreur a été trouvée dans le format de ce classeur - luacs.tns"


Que faire? J'ai bien enregistré le fichier .lua en UTF-8... On doit apporter une modification dans le fichier source pour le compiler correctement avec Luna 0.3 ?

yatto wrote:Que faire? J'ai bien enregistré le fichier .lua en UTF-8... On doit apporter une modification dans le fichier source pour le compiler correctement avec Luna 0.3 ?

Tes commentaires contiennent des accents, il faut effectivement bien convertir le .lua en UTF-8. Je viens de tester, il ne semble pas y avoir de problème. Quel éditeur utilise-tu pour réaliser la conversion ? Pourrais-tu partager ta version convertie pour vérifier ?

Sinon hors sujet :
- Pourquoi ne pas traduire LuaCS en anglais ? Il y a une communauté de développeurs anglogphones qui serait probablement très intéressée.
- Embarquer directement un exécuteur de code à la oclua demanderait peu d'effort et serait beaucoup plus pratique

Pour enregistrer en UTF-8, j'ai utilisé simplement le bloc-notes... (en spécifiant UTF-8 à l'enregistrement)
Traduire LuaCS en anglais, pourquoi pas, effectivement. Faudra que je le fasse.
Embarquer un exécuteur de code, comme oclua, je ne sais pas du tout comment faire, il faudra que tu me dises comment on peut relier oclua à LuaCS.

Je rééssaie l'enregistrement en UTF-8 avec un autre logiciel...

yatto wrote:Embarquer un exécuteur de code, comme oclua, je ne sais pas du tout comment faire, il faudra que tu me dises comment on peut relier oclua à LuaCS.

Je l'ai déjà fait dans ma version que je t'avais donnée il ya maintenant 6 mois =)

Ca venait bien de l'UTF-8, en enregistrant via PSPad ça compile correctement.
Par contre, toujours le même problème au niveau des carctères spéciaux tapés dans LuaCS. Dommage.

La trad anglaise, elle est faite aux 2/3 là, je terminerai demain.

Et la version que tu m'as passé, c'est très gentil mais je n'y comprends rien, ^^

yatto wrote:Et la version que tu m'as passé, c'est très gentil mais je n'y comprends rien, ^^

Faut commencer par là =(

La prochaine version de Luna supportera le BOM UTF-8 probablement ajouté par PSPad.
En ce qui concerne les caractères tapés, je ne suis pas bien sûr que ce soit un probleme côté Luna.