Le Python et la Nspire enfin réunis grâce à "Micro Python" !

[Lionel Debroux]

Version française, English version

TL;DR : Initial TI-Nspire port of Micro Python now available !
Download / Téléchargement : here / ici.

Un peu d'histoire

History

Depuis avril 2011 avec l’OS 3.0.1.1753, en plus de son habituel langage BASIC spécifique, la série TI-Nspire a inclus une implémentation d’un langage de programmation adapté aux plates-formes mobiles de par sa légèreté et ses performances raisonnables (pour un langage interprété) : Lua.

Since OS 3.0.1.1753 in April 2011, in addition to the usual platform-specific BASIC language, the Nspire series has provided an implementation of an established programming language originally made for other platforms and well-suited to embedded platforms due to its relatively limited footprint and reasonable execution efficiency (for an interpreted language), namely Lua.

Même si l’implémentation du Lua sur TI-Nspire est amputée par la suppression des bibliothèques standard ‘io’ et ‘os’ (rendant impossible la lecture/écriture de fichiers, entre autres), elle devint rapidement un outil de développement populaire pour TI-Nspire : contrairement au BASIC qui est également beaucoup plus lent, le Lua permet de dessiner des pixels individuels sur l’écran et de lire l’état des touches clavier

Even if the Nspire’s Lua implementation is crippled by the removal of standard io and os packages (making it unable to e.g. read and write files on the FS), it immediately became a popular development option for the Nspire: the Nspire’s Lua can draw single pixels to the screen and read from the keyboard, unlike the BASIC (which is much slower too)

Avançons de trois ans. Lua est toujours léger, il est un choix de développement populaire pour plusieurs types de programmes (notamment l’IA et les couches supérieures des moteurs de jeux vidéo), et il y a même LuaJIT pour faire tourner les programmes plus vite.
Toutefois, au sein de la sphère des développeurs il est facile de trouver des classements de langages par popularité (entre autres http://blog.codeeval.com/codeevalblog/2014 , http://www.tiobe.com/index.php/content/ ... index.html , http://spectrum.ieee.org/static/interac ... -languages ); qui montrent que le Lua est (beaucoup) moins populaire que nombre d’autres langages de script bien connus, tout particulièrement Javascript, Perl, PHP, Python, Ruby (par ordre alphabétique).

Fast forward three years. Lua keeps being lightweight, it remains a popular development option for several classes of programs (e.g. the AI and suchlike higher-level functionality of game engines), and there’s LuaJIT for making programs run faster.
However, in the general developer population, it’s easy to find language popularity contests (e.g. http://blog.codeeval.com/codeevalblog/2014 , http://www.tiobe.com/index.php/content/ ... index.html , http://spectrum.ieee.org/static/interac ... -languages ) which concur that Lua is (much) less popular than multiple other well-known scripting-type languages, especially Javascript, Perl, PHP, Python, Ruby (in alphabetical order).

Motivations

Compte tenu de tout ceci, il est assez naturel de vouloir [essayer de] porter d’autres langages de script comme le Javascript, Perl, PHP, Python, Ruby… sur calculatrice - d'une part parce que l'on peut le faire, et d'autre part car une partie des utilisateurs de calculatrices qui deviendront développeurs professionnels un jour peuvent avoir envie d'apprendre des langages populaires en premier
Avant même de commencer ceci, on sait que réussir à faire tenir/fonctionner des environnements d'exécutions de ces langages (programmés en C ou C++), même sur les calculatrices les plus puissantes (TI-Nspire, HP Prime), est un défi en soi, car :

• La puissance brute du CPU, les quantités de RAM et d'espace de stockage sont généralement bien en-dessous des standards modernes du marché ;
• La Nspire est une plateforme hostile au développement natif, même si cela a été amélioré dernièrement grâce aux efforts pour mettre en place le C++ et newlib (Vogtinator, Ikj…) pour le SDK - déjà utilisé pour le portage de giac/xcas (cf. KhiCAS). La HP Prime est une plateforme ouverte et a un CPU plus puissant et plus de Flash (mais moins de RAM) que la TI-Nspire CX, mais son logiciel n’est pas documenté à l'heure de ce post, et la plateforme n'est pas vraiment populaire parmi les utilisateurs.

Based on the above, it makes lots of sense to (try and) port other established scripting languages among Javascript, Perl, PHP, Python, Ruby to calculators - just because we can, and also because the subset of calculator users who will become professional software developers one day might want to learn popular languages first
Before even starting the process, we know that fitting the execution environments (written in C or C++) for these languages, on even the most powerful calculators (TI Nspire, HP Prime), is a challenge due to:

• the raw CPU power, amount of RAM and amount of persistent storage of calculators being generally highly sub-par by modern market standards;
• the TI Nspire being a hostile platform for developing native code programs, even if this improved recently with the expanded Ndless SDK featuring C++ support and newlib (Vogtinator, lkj et al.), already used for porting giac/xcas to the Nspire (cf. KhiCAS). The HP Prime is an open platform, it has a faster CPU and more Flash (althrough less RAM) than the Nspire CX, but its software is undocumented at the time of this writing, and the platform is not really popular among users.

Ainsi, nous (admins de TI-Planet) avons initié le projet de port d'un interpréteur Python pour la TI-Nspire. Le Python est clairement le choix le plus populaire parmi les 5 listés plus haut, et il est devenu le langage le plus populaire à des fins éducatives d'après un récent sondage :

Therefore, we (TI-Planet staff) sparked the port of some Python flavor to the Nspire. Python is clearly the most popular choice among the 5 ones listed above, and it has become the most popular language for learning purposes, according to a recent survey:

http://www.pcworld.com/article/2451880/ ... guage.html .

Le portage

Porting process

En gros, la totalité du travail a été faite par Fabian “Vogtinator” Vogt, bien connu dans la communauté pour des réalisations dont nous nous sommes faits l’echo par le passé, comme :
* contributions au portage Nspire de Linux et au système de build automatisé ( http://tiplanet.org/nspire-linux-builds/ )
* contributions à la librairie de base et à la toolchain Ndless, ayant notamment permis KhiCAS sus-mentionné;
* lecteur de fichiers WAV sur Nspire;
* Crafti, un Minecraft-like en code natif, démonstration du moteur 3D nGL qu’il a également programmé

• Portage de CPython + libs : il n’a pas été réalisé, car cela prendrait un temps considérable et poserait vraisemblablement d’importants défis de portabilité. Il est probablement mieux de s'attaquer à quelque chose de plus simple en premier lieu
  
• Portage de python-on-a-chip, a.k.a “p14p” (que Lionel Debroux avait d'ailleurs déjà partiellement porté pour la plateforme TI-68k/AMS) : portage effectué, et rapidement. Cependant, il ne pouvait qu'exécuter du bytecode généré par une version spécifique de CPython et non du code source Python directement ; p14p est assez limité au niveau des fonctions disponibles et des types de données. On note aussi qu'il y a eu assez peu de changements dans la base de code au cours des trois dernières années.
  
• Portage de MicroPython (un projet Kickstarter qui a réussi) : portage effectué aussi, et tout aussi rapidement. MicroPython supporte une version plus récente de Python que p14p, a plus de fonctionnalités et sa base de code est encore active actuellement.
  Sa performance sur un calcul de Fibonacci était correcte, mais néanmoins inférieure au Nspire Lua.
  Afin d'augmenter la vitesse, Fabian s'est mis à écrire un émetteur de code ARM natif, qu'il a d'ailleurs contribué à l'upstream de Micro Python (rapidement intégré)
  Des premiers tests sur une version de développement montrent qu'avec ce "JIT", le Lua est alors dépassé par le Python.

Pretty much all of the work was done by the well-known Fabian “Vogtinator” Vogt, famous for multiple pieces of work that we mentioned in the past, such as:
* contributions to the Nspire port of Linux and the automated build system ( http://tiplanet.org/nspire-linux-builds );
* contributions to the base library and toolchain of Ndless, which made it possible to port the powerful Giac/Xcas engine to the Nspire, mentioned above;
* Nspire WAV file player;
* Crafti, a native code Minecraft-like program, showcasing the nGL 3D engine that he programmed as well.

• porting full-blown CPython + libs: it was not done, as it would be (much ?) more work and pose interesting portability challenges. It’s probably better trying something simpler first
  
• porting python-on-a-chip, known as “p14p” (which Lionel Debroux had already partially ported to the TI-68k/AMS platform) : the port is done and it was pretty quick. However, it could only execute bytecode generated by a specific version of CPython and not python source; it was quite limited in available functions and data-types; fairly few code changes have been performed over the past three years.
  
• porting MicroPython (a successful Kickstarter project): that, too, was a quick success. Micro Python supports a newer version of Python than p14p does, it’s more featureful than p14p is, and it’s still under active development.
  Performance on the Fibonacci test was decent, though lower than Nspire Lua. In order to improve speed, Fabian set to write a native ARM code emitter, which he contributed to upstream micropython; it was quickly integrated
  Some tests on developement versions show that Micro Python is then faster than Lua when using the "JIT".

(zoom = click)

Bien que la taille du code (quelques centaines de Ko sur la Nspire) et la consommation de RAM de Micro Python soient ridiculement minuscules selon les normes modernes, elles dépassent les capacités de la plupart des modèles de calculatrices sur le marché ... Seule la famille TI Nspire et la HP Prime peuvent exécuter facilement Micro Python ; peut-être aussi la Casio fx-CP400, qui a des caractéristiques moindres (en particulier la quantité de RAM), qui est encore plus chère, et qui est une plate-forme fermée sur laquelle personne n'a encore exécuté de code natif arbitraire. Cependant, certainement pas la série des TI-Z80, presque certainement pas la série TI-68k (même en utilisant l'exécution depuis la Flash, les programmes complexes poseraient probablement problème), et d'autres non plus, comme les Casio fx-98*, Prizm, ou les HP-49G + / 50G pour la même raison: elles n'ont que trop peu de RAM (disponible).

While the code size (several hundreds of KBs on the Nspire) and RAM consumption of Micro Python are laughably tiny by modern standards, they’re above the specs of most calculator models on the marketplace... Only the Nspire family, the Prime can easily run Micro Python; maybe the Casio fx-CP400, which has lower specs (especially the amount of RAM), is even more expensive, and is a closed platform on which nobody has yet executed arbitrary native code, could do it too. However, definitely not the TI-Z80 series, almost certainly not the TI-68k series (even when executing from Flash, complex programs would probably be troublesome), and AFAICT not Casio fx-98*, Prizm or HP-49G+/50G for the same reason: too little (available) RAM.

Liens :
- MicroPython pour TI-Nspire
- Code source du fork pour Nspire : sur GitHub

Links :
- MicroPython for the TI-Nspire
- Source code of the Nspire fork : on GitHub

(News article by Lionel Debroux, Adriweb and Critor; A less technical article, more on an educational level, about Python is available here)

(Article par Lionel Debroux, Adriweb et Critor. Une autre news d'un point de vue moins technique et plus éducatif est disponible ici)

[Bisam]

YEAH !!
Ca, c'est vraiment top !

Encore un argument pour faire acheter des Nspire à mes petits sup : ils pourront s'entraîner au Python sur leur calculette... et tester de petits programmes lors des DS. [Edit 3]Ô déception: je n'avais pas vu le "Ndless required"...

En plus, je ne m'y attendais pas du tout car à chaque fois que je l'avais évoqué, on m'avait répondu : "Mouais, pas sûr que ça intéresse grand monde et difficile à faire..."

Un grand merci à tous ceux qui ont participé à cela... et pourvu que ça dure.


PS : Vous pourriez préciser dans la news que le Python est au programme de toutes les prépas scientifiques...

[Edit 1] Argh !! Défaut majeur : le symbole ":" indispensable à la syntaxe Python n'est pas accessible sur le clavier de la Nspire... et rien n'a été prévu dans le portage : on ne peut pas le taper.
Pour l'instant, le classeur n'est donc pas utilisable oncalc.
Il faut penser à prévoir également le symbole "%" pour les modulo.

[Edit 2]Enfin, il serait bon de préciser que pour quitter l'interpréteur, il suffit de taper [Enter] sur une ligne vierge...

[critor]

Oui en effet, il faut Ndless puisqu'il s'agit d'un portage de code source C++.
Et les élèves équipés en version 3.9 seront donc privés de Python sur leur calculatrice - tu sais pourquoi...
C'est peut-être l'occasion d'écrire à TI ? Parce que là avec leur version 3.9, ils se tirent une balle dans le pied, littéralement...

Si l'on avait recodé au complet un émulateur Python en Lua, je n'ose imaginer les performances...


Le problème de saisie des caractères serait facilement résolu avec une interface Lua pour la saisie/édition du code.
Comme cela a été fait pour S2 et KhiCAS.

[Adriweb]

"""Solution""" pour le problème de certains caractères : écrire le script depuis l'ordinateur ou via un éditeur de texte Ndless (qui permet ces caractères) et l'enregistrer en tant que blabla.py.tns.
En ayant configuré les associations d'extensions pour ouvrir ça avec micropython, ca va lancer le script directement
(Note : c'est sur CX que certains caractères sont pas accessibles, d'ailleurs, comme '<' et '>' aussi, sur Clickpad, comme c'est des touches en elles-mêmes, il n'y a pas ce problème...)
(Edit : j'ai ouvert un ticket sur le repo d'nspire-io, on verra...)

Mais bref, oui, une interface à la KhiCAS permettant de lier Lua et C(++) serait effectivement le meilleur choix.

Par rapport à ton Edit 2, c'est uniquement sur cette version, dans les versions de développements plus récentes, la façon propre de quitter (et moins problématique par erreur ) est de faire :
import sys; sys.exit()


Et, oui, pour les profs qui nous lisent en ce moment : écrivez à TI en râlant sur le blocage de la programmation native (C/C++/ASM) sur la TI-Nspire, parce que ca permettrait entre autre d'avoir du Python comme on vient de le montrer, sans avoir besoin de jailbreaker avec Ndless


Edit pour Bisam : comme dit en fin de news, un autre article avec un point de vue plus éducatif sera écrit prochainement

[Lionel Debroux]

Je ne peux que rejoindre critor et Adriweb sur la nécessité d'écrire à TI pour leur demander de:
* ne pas combattre le code natif et ainsi permettre l'utilisation de programmes tiers dont l'intérêt éducatif est aussi clair que celui-là;
et/ou
* fournir une version pas trop dégradée de Micro Python (= sans amputation des lectures et écritures de fichiers et autres fonctions standard de base, comme le Lua des Nspire !), intégrée à l'OS des Nspire;
* fournir des plate-formes aux caractéristiques techniques moins dépassées que celles des Nspire. Il y a d'excellents Cortex-A5 pour remplacer les vieux ARM9.

Les performances d'un interpréteur Python écrit en Lua seraient trop horribles, d'autant que l'interpréteur Lua des Nspire n'est pas LuaJIT, et puis les fonctionnalités de Python seraient limitées par les amputations sus-mentionnées du Lua des Nspire...

En plus, je ne m'y attendais pas du tout car à chaque fois que je l'avais évoqué, on m'avait répondu : "Mouais, pas sûr que ça intéresse grand monde et difficile à faire..."

Après l'amélioration de la toolchain et de la librairie Ndless il y a quelques mois, amélioration qui était depuis longtemps sur la todo list et qui fut déclenchée par KhiCAS, les portages de logiciels vers la plate-forme Nspire sont devenus techniquement moins difficiles.
Bien sûr, ils restent soumis aux limitations matérielles des Nspire (CPU, RAM, Flash)... un portage de Python complet prendrait facilement des MBs de Flash et de RAM, entre l'interpréteur (qui n'est pas connu pour être très léger) et les libs de base.

[technolapin]

Le Python et la Nspire enfin réunis grâce à "Micro Python" !

Génial!

ndless required

Au revoir

[Bisam]

Bien, j'ai finalement trouvé comment faire certains symboles supplémentaires :

• ou pour obtenir :
• pour ;
• ou bien ou encore pour _
• pour "
• pour\
• pour [ et pour ]
• pour { et pour }
• pour ~

Mais toujours rien pour le modulo (à part le "overkill" divmod(27,4)[1] pour obtenir 27 % 4)
Rien non plus pour les symboles de comparaison < et >.

Enfin, il manque également cruellement un "récupérateur des lignes précédemment tapées"...


Par ailleurs, j'ai fait des tests en conjonction avec nTxt pour voir ce qu'on peut faire.

• On peut sans problème taper du Python dans nTxt (attention, dans nTxt, il faut appuyer sur les touches ou en même temps que sur la touche qu'ils modifient, contrairement à Micro Python) et l'enregistrer en "machin.py.tns" si on le souhaite.
• On peut faire une association Ndless entre cette extension ".py" et "micropython.prg".
• "Micro Python" semble se lancer lorsqu'on ouvre un fichier ".py"... mais se referme aussitôt sans qu'on ait eu le temps de voir quoi que ce soit (même si on met des input pour stopper le flux d'exécution). Il doit y avoir une erreur à l'ouverture... mais je n'ai aucune idée de ce que ça peut être.

Enfin, je n'ai trouvé qu'un seul module embarqué par Micro Python à savoir le module "math"... aucun des autres que j'ai testés ne sont présents ("os", "random", "time", "itertools", "fractions") C'est bien dommage, surtout que ceux que j'ai cités sont bien moins lourds que le module "math" !

[critor]

"""Solution""" pour le problème de certains caractères : écrire le script depuis l'ordinateur

Dans un contexte scolaire, ce n'est pas une solution.

Si il y a besoin que les élèves aient accès à un ordi pour saisir leur code, pourquoi s'embêter ensuite à transférer sur Nspire pour exécuter ce même code ?
Autant l'évaluer directement sur l'ordi ayant permi la saisie.

Non, à mon sens l'éditeur Lua est la seule solution scolairement viable.
Pas besoin de changer de machine après chaque modification, et pas besoin de le fermer/rouvrir pour chaque exécution comme l'éditeur Ndless.

[parisse]

Y-a-t-il du support pour les extensions python comme pour lua? Je pose la question parce qu'on a un module python d'extension de giac qui tourne sur PC (linux, windows) et mac (ca s'appelle giacpy), qui est beaucoup plus complet que le pont lua<->giac, car toutes les commandes de Xcas peuvent s'appeler directement dans un script Python. Avoir ca sur la calc, ce serait tres sympa!

[Vogtinator]

I modified nspire-io a bit to add some forgotten characters:
'<': Shift + '-'
'>': Shift + '+'
'&': Shift + 'EE'
'%': Ctrl + 'EE'
'|': Shift + '='

I also added a readline-like history and fixed the screen clearing. The uncleared columns on the right side should now be gone.
Also, the nsp.Texture class now supports greyscale calcs. I attached the latest version, just for testing and the mandelbrot script.

Y-a-t-il du support pour les extensions python comme pour lua? Je pose la question parce qu'on a un module python d'extension de giac qui tourne sur PC (linux, windows) et mac (ca s'appelle giacpy), qui est beaucoup plus complet que le pont lua<->giac, car toutes les commandes de Xcas peuvent s'appeler directement dans un script Python. Avoir ca sur la calc, ce serait tres sympa!

It's planned, but now there are some more important things to work on. Writing an extension should be fairly easy, https://github.com/Vogtinator/micropyth ... e/modnsp.c for instance exposes a class defined in texture.c and two functions.
Dynamically loading them will be hard, as there's a lot of compile time constants (e.g. number of embedded modules).