Forum TI-Planet.org

Bonjour,

Je voudrais avoir vos avis sur une idée de projet.

En effet, je me pose la question de savoir si un nouveau langage de programmation, alternatif au lua, et programmable oncalc directement dans l'éditeur de programme ne serait pas la bienvenue.
Ce langage serait plus concis que le lua et se rapprocherait à mon avis fortement au Newprog v1.0 déjà existant sur ti68k (j'en suis moi même l'auteur).

Pensez vous qu'il soit possible de faire un langage beaucoup plus rapide que le lua, tout en restant évidemment plus lent que le C, à fonctionnalités équivalentes ? La question peut paraître incongrue mais je n'ai jamais programmé en lua donc je ne sais pas si ce langage est lent en comparaison au C.

Je pense avoir les connaissances nécessaires pour développer un tel projet, il me faudra juste trouver le temps...

Je ne souhaite m'investir que si le nombre d'utilisateurs potentiels est conséquent alors n'hésitez pas à répondre.

Salut,

Le Lua est très rapide sur Nspire sauf qu'on fera souvent cette comparaison avec le Nspire-Basic. En effet comparer un langage interprété et un langage compilé n'a pas de sens.

Après une analyse poussée des routines implémentées pour communiquer avec le "kernel" Nspire, on se rend compte que les instructions graphiques (qu'on pourrait qualifier de lentes des fois) sont directement les même que celles que l'OS utilise. Ces mêmes fonctions sont légèrement complexes et velues, et c'est normal du point de vue de la personne qui a programmé cette API, pensant à une API au niveau avec des systèmes de pinceaux, couleurs etc ... Donc comparer un programme Lua et une fonctionnalité de l'OS revient donc à exactement la même vitesse de dessin (je ne parle pas de la vitesse de traitement qui peut être plus rapide sur des tableaux que sur les hashtables du Lua).

En C, on fera beaucoup plus rapide mais avec plus d'effort, ça, je pense que tu en es conscient. Là où c'est difficile de penser qu'on puisse faire mieux que le Lua c'est que ce même langage est fait pour tourner sur des plateformes embarquées tout en restant un langage très simple, évolutif et introspectif. Il est donc, je pense, très difficile de faire mieux que le Lua sur tous les points tout en restant en interprété.

Ensuite, tu parles d'un éditeur On-calc : oui, c'est ce qui manque sur Nspire : un éditeur léger et fonctionnel Lua. A mon avis ton projet s'axera plus sur cela plutôt que de porter un nouveau langage interprété qui, je pense, n'aura pas de succès car Lua est intégré à l'OS : ceci veut donc dire qu'il est possible de partager des fenêtres, variables etc ... avec le classeur, chose qui ne sera pas possible avec un nouveau langage interprété qui viendrait avec ses bagages tous faits (pardonne moi l'expression).
La question est donc, en quel langage faire cet éditeur ?
Il existe déjà :
* oclua : codé en Lua, utilise l'éditeur mathématique (ou autre) comme buffer de code, une fois que l'on veut le lancer, il faut copier le code et le coller dans la fenêtre oclua.
* LuaCS : codé en Lua, conçu pour être un éditeur/launcher complet en fournissant un éditeur codé en Lua et utilisant oclua pour lancer le programme; non achevé.

Si tu veux axer performances et faisabilités (raccourcis etc ...) il serait judicieux de se taper l'éditeur en C, et d'utiliser luna pour produire le TNS (je parle bien de oncalc, oui, à voir si luna peut se compiler pour Ndless, ça serait très intéressant de savoir. A la limite, on peut utiliser les syscalls que Lua utiliser pour serialiser le document).
Si tu veux axer ouvertures et simplicité, reprendre l'idée de LuaCS, coder en Lua.

Tiens, newprog
NewProg aurait mérité plus de succès sur TI-68k; mais il est arrivé un peu tard, et puis tout ce qui n'était pas C/ASM avait un adversaire qui était puissant (à l'époque)...
Au fait: Stefan Bauwens, sur Omnimaga, cherchait récemment à te joindre


TI fait tout pour qu'il soit difficile de faire autre chose que leur sous-merde de BASIC (qui ne sait même pas lire le clavier et écrire des pixels à l'écran, ce que la 81 d'il y a plus de 20 ans savait faire) ou leur Lua propriétaire (qui ne sait même pas lire et écrire des fichiers, entre autres manques). "Autre chose" serait probablement implémenté en C/ASM et compilé en code natif, qui est loin d'être accessible en permanence sur Nspire...
Je suis donc assez d'accord avec Levak, un bon éditeur on-calc de Lua (achevé) serait intéressant.
Pour faire de la programmation, il y a plein d'autres plate-formes moins chères, plus puissantes et plus ouvertes, même si peu sont aussi emportables que les calculatrices.

Tout a fait d'accord. Je pense que si tu fait cet "IDE" tout le monde t'en sera reconnaissant (sauf TI, mais là c'est une autre histoire).

Merci pour vos réponses et conseils.

Je note que développer un nouveau langage oncalc serait vain, vous me faites donc gagner du temps en me prévenant à l'avance et je vous en remercie.

Je vais voir pour développer un nouvel IDE lua oncalc. Pour être franc, réaliser un tel projet me motive moins.

Encore merci

Je vais voir pour développer un nouvel IDE lua oncalc. Pour être franc, réaliser un tel projet me motive moins.

Je comprends, mais si tu développes au-dessus de Lua, ça n'ira pas vite, et si tu développes pour le code et natif, ton programme ne sera utilisable qu'à temps partiel...
Peut-être que l'arrivée de Linux sur la plate-forme va réduire, indirectement, le désintérêt des programmeurs pour la plate-forme Nspire, mais je ne parierais pas là-dessus.

(indirectement = par le fait qu'à cause de la protection anti-downgrade, dont personne ne croit qu'elle continuera à autoriser le retour à l'OS 3.1, il faudra obtenir l'exécution de code arbitraire sur les OS 3.2 et ultérieurs pour pouvoir accéder à Linux; et donc, efforts de reverse-engineering et de portage)

Je déterre le topic... En effet, après avoir pu essayé le lua, je me rends compte qu'il est par exemple impossible de lire le clavier sans attendre un certain délai (non reprogrammable). Cela me parait être un inconvénient majeur pour la programmation de certains jeux pas si évolués que ça. D'où pour moi l'intérêt d'une langage alternatif.
Par ailleurs, il me semble qu'il ne soit possible de dessiner à l'écran que dans la fonction on.paint() ce qui pour moi limite les possibilités (même si cela apporte des avantages sur d'autres niveaux).
Je sais que ndless n'est pas garanti d'être disponible tout le temps mais je pense qu'un langage alternatif serait tout de même le bienvenu.

Idée numéro 2 (lancée "comme ça", je n'y ait pas trop réfléchi): utiliser les extensions lua proposées par ndless pour faire une librairie lua qui comble les problèmes que tu soulèves.

(PS: Même si je pense que les deux problèmes en question peuvent être en partie résolus, avec un peu d'astuce. Les experts du lua t'en diront plus que moi).

Merci Excale pour ton idée. J'avais oublié qu'un exemple était fourni avec ndless. Seulement je n'arrive pas à faire fonctionner cet exemple. En effet, je transferts sur ma nspire runluaextdemo et luaextdemo et lance runluaextdemo : aucun message "hello" ne s'affiche. Peut être que je m'y prends mal.

HELP !

Ça affiche hello sur le port série. Autrement dit, ça écrit "hello" via le connecteur en bas de ta nspire, ou bien ça écrit hello dans la console de l'émulateur.