[Bêta] PythonExtra.
Posté le 29/10/2022 09:49
PythonExtra est un add-in Python alternatif pour (à ce stade) Graph 35+E II, Prizm et Graph 90+E. L'objectif est de fournir plus de fonctionnalités : modules standard,
getkey(), fonctions de dessin plus performantes, etc.
Version Bêta 0.2
Graph 35+E II / 
Prizm / 
Graph 90+E : PythonExtra-pe-0.2.0-beta.zip
Aperçu de PythonExtra sur Graph 90+E. (Cliquez pour agrandir)
Description sommaire des fonctionnalités :
- Compile pour Graph 90+E (fx-CG 10/20/50) et Graph 35+E II (fx-9860G III)
- Peu de RAM sur Graph 35+E II (c'est difficile d'en trouver sur ce modèle)
- Un shell pas trop mal (saisie rapide, scrolling) avec de bonnes performances
- Plein de modules standard
- array, builtins, cmath, collections, io, math, random, struct, sys, time
- Le module spécifique CASIO : casioplot (fidèle à part sur les polices)
- Un nouveau module gint avec les fonctionnalités avancées de gint :
- Pour l'instant, une bonne partie de <gint/display.h> et <gint/keyboard.h>
- Donc getkey() (attente de touche) ainsi que keydown() (test instantané) !
- Et des fonctions de dessin rapides comme dline() ou drect()
Le plan actuel :
- Être sensiblement compatible avec l'appli Python officielle.
- Pousser les fonctionnalités ajoutées pour vraiment relever le niveau de Python !
- Si du temps de développement se débloque : support autres Graph mono (pas de promesses).
Updates et screenshots à venir. Je n'ai pas l'intention d'implémenter un million de fonctionnalités, juste ce qu'il faut pour s'assurer que ça ne finisse pas mal documenté et non maintenu comme CasioPython.
Dépôt Git :
https://gitea.planet-casio.com/Lephenixnoir/PythonExtra
PythonExtra est notamment possible grâce à l'aide précieuse de
Mb88.
Comparaison directe
Dans l'exemple ci-dessous (
réalisé par Mb88), un Flappy Bird déjà bien optimisé (dessin partiel etc, à gauche) est accéléré un bon gros coup en utilisant PythonExtra et le module
gint pour le dessin (à droite).
Contexte historique
Aux
journées APMEP 2022, redgl0w racontait comment le port MicroPython pour Numworks n'était finalement pas super difficile. Moi je parlais de comment un port maison résoudrait le problème de
getkey(), et Critor m'a convaincu d'essayer sur-le-champ.
En fin de compte, j'ai clôné MicroPython Dimanche à midi et à 1 heure du matin j'avais un port fonctionnel avec
getkey() sur ma Graph 90+E (que j'ai d'ailleurs montré à CASIO Lundi, pour la démo). Comme quoi, des fois ça marche tout seul !
(Enfin, le début marche tout seul. Faire une bonne UI et gérer tous les détails ensuite c'est une autre paire de manches !)
Fichier joint
Citer : Posté le 29/10/2022 11:03 | #
Alors ça c'est vraiment génial.
En plus, le fait que ce soit toi qui prenne la main sur ce sujet nous garanti que le matériel sera utilisé au top.
J'ai eu un doute à ce sujet en voyant ta réponse hier à Charis
C'est donc confirmé.
Le rédacteur qui va faire le bilan de l'année 2022 va avoir du taf cette année
Citer : Posté le 29/10/2022 11:32 | #
Oui j'ai pas été très fin dans les indices haha.
Y'a pas mal de truc qui se passent bien parce que la fxlibc donne un système de fichiers POSIX. Typiquement les imports il y avait une petite fonction à coder (10 lignes) et une option à activer, et pouf ça marche comme un charme. J'ai pas trouvé pour open() encore, mais ce sera sans doute la même histoire. Donc oui, il y aura accès au système de fichiers pour les sauvegardes.
Maintenant que j'y pense j'ai pas surveillé les world switch, woops... je vais peut-être finir par implémenter un auto-world-switch pour le fs qui sera pas efficace mais qui permettra ce genre de ports.
J'ai toujours une ou deux bombes en tête derrière mais je vais commencer par ce qui est plus ou moins garanti de marcher et on verra après.
Bonne nouvelle pour la Graph 90+E : le GC peut accepter plusieurs zones de mémoire, donc on pourra avoir une quantité raisonnable (~600 kio) par défaut (par rapport au 1 Mo de l'appli officielle) et si on pousse jusqu'à utiliser la mémoire extra de la puce, bah comme CGDoom on peut avoir 3.5 Mo. Sur la Graph 35+E II je sais pas encore à quoi ça va se jouer - l'appli officielle donne 100 kio ce qui sera dur à battre sans partir dans des trucs très expérimentaux, surtout que l'appli en elle-même a déjà besoin d'une place non négligeable.
Citer : Posté le 29/10/2022 11:43 | #
Oui j'ai pas été très fin dans les indices haha.
C'est surtout qu'on te connait, tu es pas du genre à avancer des trucs sans avoir un minimum regardé avant.
Y'a pas mal de truc qui se passent bien parce que la fxlibc donne un système de fichiers POSIX. Typiquement les imports il y avait une petite fonction à coder (10 lignes) et une option à activer, et pouf ça marche comme un charme. J'ai pas trouvé pour open() encore, mais ce sera sans doute la même histoire. Donc oui, il y aura accès au système de fichiers pour les sauvegardes.
Maintenant que j'y pense j'ai pas surveillé les world switch, woops... je vais peut-être finir par implémenter un auto-world-switch pour le fs qui sera pas efficace mais qui permettra ce genre de ports.
C'est vrai que ce serait potentiellement intéressant pour les ports en fait. Il faudrait être en capacité de savoir si on est déjà dans un world_switch quand on touche au fs avec une fonction, et si pas, l'activer au vol. Pour les portages ça rendrait les trucs vraiment simple. Par contre en perf ça aurait certainement un prix. Je dis ça, mais je sais même pas si ce serait jouable de faire un truc automatique comme ça. Par exemple dans le port d'un programme utilisant la SDL, c'est clairement un truc qu'il faut bien penser dans la réécriture d'un programme, sinon boom !!!
J'ai toujours une ou deux bombes en tête derrière mais je vais commencer par ce qui est plus ou moins garanti de marcher et on verra après.
Fais gaffe, tu recommences à en dire trop
Bonne nouvelle pour la Graph 90+E : le GC peut accepter plusieurs zones de mémoire, donc on pourra avoir une quantité raisonnable (~600 kio) par défaut (par rapport au 1 Mo de l'appli officielle) et si on pousse jusqu'à utiliser la mémoire extra de la puce, bah comme CGDoom on peut avoir 3.5 Mo. Sur la Graph 35+E II je sais pas encore à quoi ça va se jouer - l'appli officielle donne 100 kio ce qui sera dur à battre sans partir dans des trucs très expérimentaux, surtout que l'appli en elle-même a déjà besoin d'une place non négligeable.
A mon sens il faut utiliser au max ce que chaque machine peut offrir, par exemple sur une CG50 pousser au 3.5Mo et limiter à moins sur le "vieux" matos (CG10/20). Niveler vers le haut en qq sorte quitte à limiter certains trucs sur les vieilles machines.
Citer : Posté le 29/10/2022 14:18 | #
Trop cool ! J'attends le port G35+e II avec impatience !
Citer : Posté le 29/10/2022 18:42 | #
C'est vrai que ce serait potentiellement intéressant pour les ports en fait. Il faudrait être en capacité de savoir si on est déjà dans un world_switch quand on touche au fs avec une fonction, et si pas, l'activer au vol. Pour les portages ça rendrait les trucs vraiment simple. Par contre en perf ça aurait certainement un prix. Je dis ça, mais je sais même pas si ce serait jouable de faire un truc automatique comme ça. Par exemple dans le port d'un programme utilisant la SDL, c'est clairement un truc qu'il faut bien penser dans la réécriture d'un programme, sinon boom !!!
Ok, j'entends - on va sans doute essayer ça. C'est pas très dur de détecter si t'es dans un world switch (gint le sait) et ensuite il suffit de passer dedans dès qu'on fait un appel à Bfile. C'est pas parfait mais ça suffira largement.
Carrément.
Trop cool ! J'attends le port G35+e II avec impatience !
Après test il commence à marcher
Citer : Posté le 29/10/2022 18:44 | #
🤔
Je pourrais fusionner avec mon éditeur de texte pour faire KiwiPyEbL.
kiwi Python Extra by Lephe.
Citer : Posté le 29/10/2022 20:03 | #
Exciting! If you're taking volunteers, I'd like to volunteer to help with mono support.
“They call me the king of the spreadsheets, got 'em all printed out on my bedsheets.” — “Weird Al” Yankovic
Citer : Posté le 29/10/2022 20:43 | #
🤔
Je pourrais fusionner avec mon éditeur de texte pour faire KiwiPyEbL.
kiwi Python Extra by Lephe.
Effectivement je ne pense pas faire un éditeur de texte... donc si ton éditeur peut supporter le Python ça serait cool !
Exciting! If you're taking volunteers, I'd like to volunteer to help with mono support.
That would be awesome! The core is similar but there are many UI concerns. I'll push the sources with some TODO list of independent tasks, let me know if there's anything you'd like to tackle.
Citer : Posté le 29/10/2022 21:47 | #
Pour info j'ai tenté de jouer à utiliser le open() classique style Unix. J'ai poussé ça sur une branche. En jouant un peu ça marche presque :
lexer.c:(.text+0xa1c): undefined reference to `_mp_reader_new_file'
/home/el/.local/share/fxsdk/sysroot/lib/gcc/sh3eb-elf/11.1.0/../../../../sh3eb-elf/bin/ld: build/extmod/vfs_posix.o: in function `_vfs_posix_chdir':
vfs_posix.c:(.text+0x3c0): undefined reference to `_chdir'
/home/el/.local/share/fxsdk/sysroot/lib/gcc/sh3eb-elf/11.1.0/../../../../sh3eb-elf/bin/ld: build/extmod/vfs_posix.o: in function `_vfs_posix_getcwd':
vfs_posix.c:(.text+0x518): undefined reference to `_getcwd'
/home/el/.local/share/fxsdk/sysroot/lib/gcc/sh3eb-elf/11.1.0/../../../../sh3eb-elf/bin/ld: build/extmod/vfs_posix_file.o: in function `_vfs_posix_file_ioctl':
vfs_posix_file.c:(.text+0x188): undefined reference to `__commit'
Il nous manque :
- mp_reader_new_file(), une fonction interne je fais pas trop attention
- La gestion du dossier courant avec chdir() et getcwd()
- Et la fonction _commit() apparaît parce que j'ai un peu triché pour éviter d'avoir à fournir poll()
Donc on n'y est pas tout à fait mais ce n'est pas hors de propos dans le futur.
Citer : Posté le 30/10/2022 18:42 | #
J'ai activé le module time. Actuellement on a les modules standard suivants :
Ainsi que les modules spécifiques MicroPython/calto suivants :
Citer : Posté le 30/10/2022 19:37 | #
Cool, mais la saisie est un peu pénible.
Je propose que le mode soit alpha par défaut et qu'il faut appuyer dessus pour basculer vers le mode "normal".
Citer : Posté le 30/10/2022 19:38 | #
En effet c'est très chiant pour l'instant. Je planifie d'imiter le mode de saisie de l'appli Python officielle, ce qui accomplira ton idée.
Citer : Posté le 30/10/2022 19:39 | #
Oui mais moi je propose quelque chose de différent à la méthode classique : une méthode optimisée pour le python.
Citer : Posté le 30/10/2022 19:40 | #
Attends, je vais te faire une démo.
Citer : Posté le 30/10/2022 19:40 | #
Il faut que tu précises alors, avec ta seule phrase précédente je ne vois pas tout à fait ce que tu imagines.
Citer : Posté le 31/10/2022 14:06 | #
Pourquoi ne pas reutiliser des parties de code de l'environnement shell/editeur de KhiCAS?
Il me semble qu'il y a pas mal d'outils qui pourraient servir: coloration syntaxique (ou soulignement sur la 35), parenthese match, line wrap dans l'editeur, touche VARS pour voir les variables definies, shift-INS pour acceder a la table de caracteres, menus rapides pour les commandes les plus frequentes... Aussi le fait de pouvoir tester la syntaxe directement depuis l'editeur avec en cas d'erreur, positionnement du curseur a la ligne de l'erreur ce que je trouve beaucoup plus simple a utiliser que l'environnement Python de l'OS.
Et inversement, nettoyer et optimiser un environnement qui accepte plusieurs interpreteurs pourrait servir a KhiCAS.
Citer : Posté le 31/10/2022 20:45 | #
On pourrait, en effet - pas mal de ces fonctions sont intéressantes. C'est plutôt orthogonal pour l'instant ; je cherche juste à fournir un shell décent et de quoi charger des fichiers, avec un focus sur l'exécution Python en elle-même, pas le développement sur la calculatrice.
De plus, j'aimerais que ce port puisse être maintenu par la communauté sur le long terme, et une passation requiert que le code soit facile à approcher, bien documenté, et puisse recevoir des contributions de façon collaborative sur Git. Ce ne sont pas les points forts de KhiCAS... ce qui nous laisse donc l'option de « nettoyer et optimiser l'environnement », qui est certainement la bonne chose à faire, mais ne passerait définitivement pas dans mon budget initial de cette semaine. x_x
Citer : Posté le 01/11/2022 08:35 | #
Ok, il y avait une ambiguite sur la fonctionnalite environnement de dev Python sur la calculatrice. Je pense aussi que faire une UI de dev Python sur calculatrices necessite nettement plus qu'une semaine de travail, surtout avec l'environnement de dev sur Casio ou on ne dispose pas d'un debuggueur comme sur la Numworks ou la ti nspire (G. Maia avait d'ailleurs passe beaucoup de temps a peaufiner l'UI d'Eigenmaths qui m'a servi de base pour l'editeur de texte, et la console est basee sur le travail de Mike Smith).
Cloner l'UI de KhiCAS me parait nettement plus facile, en tout cas pour moi je pense que ca doit etre faisable en moins d'une semaine a minima (i.e sans support des modules Micropython de KhiCAS graphic, turtle, matplotl, linalg/numpy, cas). Mais ca n'a d'interet que s'il y a des gens qui l'utilisent ensuite, or je n'ai pas trop l'impression que mon implementation MicroPython pour la 90 ait interesse beaucoup d'utilisateurs, peut-etre par manque d'information. Et sur la 35, le public potentiel me parait encore plus restreint.
Citer : Posté le 01/11/2022 13:03 | # |
Fichier joint
Je viens d'écrire la démo de mon système de saisie : https://gitea.planet-casio.com/mibi88/Superinput_demo .
Citer : Posté le 04/11/2022 00:38 | #
I had some exciting (in my own life) things happen, and it seems like the TODO items I planned to work on are already underway in the meantime (nice!). I'll step back for now so I don't duplicate efforts.
“They call me the king of the spreadsheets, got 'em all printed out on my bedsheets.” — “Weird Al” Yankovic