NumWorks, 1ère graphique française programmable en Python

[Adriweb]

Hmm, je sais pas, @parisse. Ca me parait un peu étrange de partager une config git pour le user/mail.

Code: Select all

Commits     Name               Github Name
---------------------------------------------
   2014     Émilie Feral       EmilieNumworks
    746     Romain Goyet       Ecco
    122     Felix Raimundo

Sachant que Romain a lancé le projet (commits de Mai 2015), puis Felix a fait des commits entre mars et avril 2016 (mais pas depuis). Emilie les a rejoint vers le milieu (sept. 2016) et est toujours là.
Je vois d'autres personnes sur GitHub, mais je ne sais pas s'ils sont actif niveau code.

[parisse]

Un seul dev a plein temps, c'est peu, on ne peut pas etre bon au four et au moulin.

[Adriweb]

Ben il y en a au moins 2 à plein temps là
Mais évidemment, ça reste peu, oui.

[clifward]

D'où l'"open source"...

[parisse]

Ben il y en a au moins 2 à plein temps là

Romain Goyet n'est surement pas a plein temps, vu que c'est le chef. D'ailleurs, ca se voit dans les commit.

[Adriweb]

Certes, mais dans ce genre de startup, les heures ne sont pas comptées (surtout pour les chefs), donc qu'il soit a un équivalent plein-temps, rien que pour de la prog, ne me surprendrait pas du tout.

[parisse]

Je ne pense pas que ce soit possible de faire de la programmation comme un salarie a plein temps en dirigeant une startup, meme si on programme 8h par jour, on ne peut pas avoir l'esprit suffisamment serein pour bien programmer. Je le vois bien quand j'ai beaucoup d'enseignements, je travaille sur giac mais pas du tout de la meme facon que pendant les vacances ou le week-end.
Ecco (Romain Goyet) est un membre enregistre sur tiplanet depuis mai 2017, il n'a rien poste (ce qui n'a rien d'etonnant), mais peut-etre qu'il ne connait tiplanet que depuis ce moment-la...
Émilie Feral a un tres bon cursus, mais elle semble avoir laisse de cote les maths a son entree a l'X en 2012, ce qui expliquerait le codage naif de certains algorithmes.

Allez, une petite amelioration facile, c'est ma tournee: https://github.com/numworks/epsilon/issues/75
Quelqu'un a une idee pour pouvoir remplacer le parser/evaluateur de l'app calculs par la fonction extern "C" const char * caseval(const char *); de giac? Bien sur ca ne marchera pas sur le hardware actuel, mais si ca marche sur le simulateur, ca pourrait les faire reflechir...

[Lionel Debroux]

TI a déjà une intégration du Lua, sans éditeur on-calc officiel il est vrai... mais il y en a un officieux qui est très bien; intégrer une REPL Python et la possibilité d'enregistrer les programmes n'est certainement pas la mer à boire

On ne parle peut-etre pas de la meme chose en terme d'integration. Pour moi integration veut dire que le systeme est capable de rechercher une fonction ou une variable dans l'OS ou dans l'espace micropython et de traduire les arguments et valeur de retour dans les 2 sens de maniere aussi transparente que possible pour l'utilisateur. Un peu comme ce qui se fait entre les ecrans Home et CAS de la Prime: faire communiquer harmonieusement les deux interpreteurs/evaluateurs n'a pas ete de la tarte... Je ne sais pas ce qu'il en est de l'integration de lua sur la nspire en ce sens.

Le Lua Nspire peut interagir avec les variables du Nspire BASIC et déclencher des opérations du moteur de calcul (CAS ou non selon le modèle). Comme Nspire (CX) (CAS) et Prime ont déjà des briques de base, un peu différentes, pour une interopérabilité dans les deux sens entre un certain mode et un autre, c'est pour ça que je ne pense pas que l'effort de développement d'une intégration telle qu'on l'entend tous les deux (j'avais moi aussi dans la tête une interopérabilité dans les deux sens sur le modèle du Lua Nspire, voire mieux) serait si énorme que ça pour les Nspire CX (CAS) - TI ayant arrêté de développer l'OS pour les Nspire Clickpad et Touchpad - et pour les Prime.
Les TI-eZ80 et les Graph 90+E / fx-CG50 sont beaucoup plus loin d'un tel objectif. Un portage de MicroPython est dans la wishlist de la communauté depuis le début, mais jusqu'à l'arrivée de la toolchain eZ80 basée sur LLVM reprise par jacobly, ça n'était pas jouable. Même si elle permet de builder Oiram, je n'ai pas suivi précisément l'évolution des capacités de la toolchain eZ80 ces derniers mois.

[parisse]

Mais est-ce que cela se fait avec la syntaxe naturelle du langage ou avec un appel explicite? Par exemple si f est une fonction lua, a une variable lua, b une variable ti-basic peut-on ecrire en ti-basic f(sin(a),b)? Ou l'equivalent depuis lua?
Faire cela entre Home et CAS sur la Prime necessite de faire interagir les 2 evaluateurs et de convertir les objets en objets equivalents (ou degrades), ca n'a rien d'evident (surtout avec les types a representation exacte et approchee + les types symboliques). De meme integrer des UI pour gerer les deux langages n'est surement pas trivial, sinon TI aurait developpe un editeur lua oncalc.
On a souvent tendance a sous-estimer le temps necessaire pour developper une fonctionnalite en version stable...

[Lionel Debroux]

Sur Nspire, l'environnement Lua peut utiliser les variables et fonctions TI-Basic par appel explicite de l'utilisateur, cf. notamment https://wiki.inspired-lua.org/var . En revanche, de mémoire, le TI-Basic ne peut pas déclencher des choses dans l'environnement Lua, ce qui a à ma connaisance un intérêt limité avec le système de documents/classeurs des Nspire (certes complexe et implémenté de façon sauvagement et stupidement inefficace, mais assez puissant).
Mais c'est suffisant pour implémenter rapidement une REPL Nspire Lua (= Lua sans io.* + os.* et avec des fonctions spécifiques) capable de stocker des variables de façon persistante - possiblement une variante d'un onglet de calculs. Ensuite, il faut l'étendre pour stocker des fonctions. Et TI peut adapter l'éditeur on-calc de TI-Basic au Nspire Lua (de préférence en adoptant aussi les fonctionnalités plus avancées de Jens' Script Editor). Alors, décliner à la fois REPL et éditeur de programmes pour du Python (ou tout autre langage, mais l'intérêt est limité) est bien envisageable.

Sur la Prime, HP a fait un bon éditeur et debugger de PPL, donc une partie importante des briques de base d'une intégration de MicroPython est là aussi disponible pour adaptation à MicroPython. La dualié d'environnements numérique / CAS a déjà nécessité la mise en place de mécanismes d'intégration, comme tu l'indiques. La REPL est là aussi envisageable comme variante de la page où on tape les calculs et consulte l'historique.