[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 02/01/2024 14:27 | #
Pour expliquer le problème, quand je code un script (avec Pyhon natif - Python Casio - ), et que je fais une erreur de syntaxe et j'exécute ce script avec PE, ça me dit erreur de syntaxe (normal !) et quand je veux modifier ce même script avec Python natif, je constate que je ne peux pas enregistrer les modifications (sauf à enregistrer sous un nouveau nom). De plus je ne peux plus détruire le script incriminé ni par Pyton Casio ni par le menu MÉM. Il faut que je Reset la machine et là seulement je peux modifier/supprimer le script.
il faudrait que je creuse un peu puisque je ne maitrise pas certaines choses... (un peu comme les class)
Bien à toi et merci de ton investissement
Citer : Posté le 02/01/2024 18:39 | # |
Fichier joint
Hello,
J'ai commencé de regarder de plus près PythonExtra pour voir ce qu'on peut faire avec et regarder pour identifier/tracker les bugs.
Quelques bonnes nouvelles pour commencer :
Je n'ai pas fait un milliard de tests, mais en réécrivant une fonction round( n, nbdigit ) j'ai pu faire tourner tous les examples de turtle que j'avais sous la main et idem pour matplotl.
Attention, turtle fonctionne chez moi sur ma G90+E et sur ma G35.EII, mais matplotl lui ne fonctionne que sur ma G90+E. J'ai une erreur d'allocation mémoire sur la G35+EII, problème hélas connu de manque de mémoire.
Pour le moteur de gris sur G35+EII, ça devrait pas être trop compliqué, je me mettrai dessus un de ces 4 matins.
Parmis les trucs plus pénibles, j'ai un souci avec des petits bouts de codes très simples :
dclear(C_WHITE)
dtext( 1, 1, C_BLACK, "Hello" )
dupdate()
k=getkey()
Alors que :
g.dclear(g.C_WHITE)
g.dtext( 1, 1, g.C_BLACK, "Hello" )
g.dupdate()
k=g.getkey()
et la variante
dclear(C_WHITE)
dtext( 1, 1, C_BLACK, "Hello" )
dupdate()
k=getkey()
eux fonctionnent parfaitement.
Avez vous déjà rencontré ce problème ?
Je précise que c'est pas un souci avec le module gint car c'est vrai pour tous les modules.
Donc ça progresse gentiment.
Citer : Posté le 02/01/2024 18:51 | #
J'ai pris un moment pour comprendre ca aussi. En gros, si tu fais
gint.dtext( 1, 1, C_BLACK, "Hello" )
gint.dupdate()
k=gint.getkey()
Citer : Posté le 02/01/2024 18:56 | #
ok merci je savais pas.
donc ça répond à cette interrogation
Citer : Posté le 02/01/2024 18:59 | #
J'ai pris un moment pour comprendre ca aussi [...] tu n'as pas besoin de mettre "gint."
Oui c'est tout le principe de la syntaxe
importe le module gint en tant que son nom, donc "gint", il faut donc utiliser gint.xxx pour utiliser la fonction "xxx"
Tu peux faire
pour pouvoir l'utiliser en tant que xxx.fonction.
Alors que
importe la fonction yyy du module (programme) xxx comme si elle faisait partie du tien, et l'étoile représente toutes les fonctions du module
Caltos : G90+E, FX-92+ (x2)
Citer : Posté le 03/01/2024 18:07 | #
Bonjour
merci pour les nouvelles fonctions à venir
si je n'ai besoin que de cos et pi, j'utilise cette syntaxe :
Je n'y connais pas grand-chose, mais faire des from gint import * ça doit utiliser de la mémoire, car je pense que python charge toutes les fonctions en ram ? (donc ne mettre que les fonctions qui sont utilisées dans le script)
Sinon un autre point qui me gêne est que la machine ne s'éteint pas si on ne sort pas du menu PythonExtra. Pouvez-vous y remédier ?
et dernier point, peut avoir une sorte de comparatif pour savoir comment se situe pythonExtra par rapport à des programmes écrits en basic, en c etc. ? (vitesse d'exécution)
Citer : Posté le 03/01/2024 18:16 | #
si je n'ai besoin que de cos et pi, j'utilise cette syntaxe :
C'est ça
Je n'y connais pas grand-chose, mais faire des from gint import * ça doit utiliser de la mémoire, car je pense que python charge toutes les fonctions en ram ? (donc ne mettre que les fonctions qui sont utilisées dans le script)
Oui, mais si j'ai bien suivi pour gint par exemple, l'impact est négligeable vu que ce sont des liens vers des fonctions compilées et non des fonctions python
Sinon un autre point qui me gêne est que la machine ne s'éteint pas si on ne sort pas du menu PythonExtra. Pouvez-vous y remédier ?
Ça c'est un truc avec tous les addins, pense juste a retourner au menu pour éviter de vider tes piles
et dernier point, peut avoir une sorte de comparatif pour savoir comment se situe pythonExtra par rapport à des programmes écrits en basic, en c etc. ? (vitesse d'exécution)
Le basic est un peu plus rapide, mais le C/C++ est plusieurs ordres de magnitude plus rapides
De toute façon pour la comparaison il suffit de regarder ce qui ce fait dans les différents languages sur le même hardware :
De la 2D simple/du texte, au mieux de la 3D extrèmement simple en Python, de la 2D pas mal et de la 3D wireframe stylée en Basic, et des véritables pépites de 2D et de la véritable 3D texturée en addins (C/C++ et ASM)
Caltos : G90+E, FX-92+ (x2)
Citer : Posté le 04/01/2024 01:50 | #
SlyVTT a créé une PR avec pas mal de choses : https://gitea.planet-casio.com/Lephenixnoir/PythonExtra/pulls/2
Je vais les prendre petit à petit, si les détails vous intéressent vous pouvez jeter un oeil à la page de la PR.
Je n'y connais pas grand-chose, mais faire des from gint import * ça doit utiliser de la mémoire, car je pense que python charge toutes les fonctions en ram ? (donc ne mettre que les fonctions qui sont utilisées dans le script)
Ça ne change rien en pratique, il est obligé de charger tout le fichier dans tous les cas ; la seule différence c'est si les noms sont visibles ou pas.
C'est plus un problème de gint mais oui on peut le faire. Faut juste que je voie comment ne pas perdre encore plus de mémoire parce qu'en principe y'a des trucs à sauvegarder/restaurer quand on éteint la calculatrice.
Y'a un tableau comparatif avec le Python officiel très très bref ici : https://gitea.planet-casio.com/Lephenixnoir/PythonExtra
Les programmes Basic calculent à peu près à la même vitesse mais le dessin est significativement plus lent. Python est confortablement supérieur à mon avis, surtout sur Graph 90+E (sur ce point je diffère de Fcalva).
Les add-ins en C/C++ sont infiniment plus puissants et sont de toute façon dans une catégorie intouchable en termes de performance.
Citer : Posté le 04/01/2024 13:44 | #
* Au sujet de "donnée est protégée" je reproduis le bug de cette façon :
Dans un script avec python normal, si je rentre ce code :
et EXE
j'ai le message SyntaxError : Invalid syntax
si j'exécute ce code dans pythonExtra j'obtiens le même message d'erreur
c'est à ce moment-là, je pense, que PythonExtra ne sait pas refermer le fichier et je ne peux plus le modifier ni le supprimer depuis Python normal (à moins de faire un reset) au dos de la machine
Je confirme que je peux reproduire sur Graph 35+E II et sur Graph 90+E. C'est très chiant dis donc. x)
Citer : Posté le 04/01/2024 14:25 | #
Ca c'est du MWE !!
Citer : Posté le 04/01/2024 19:37 | #
J'ai creusé le bug de non-fermeture du fichier en cas d'erreur. Long story short, c'était la faute de MicroPython, c'était un bug qui a été corrigé il y a quelques mois.
La version de MicroPython sur laquelle PythonExtra était basé datait d'Octobre 2022, donc j'ai fusionné pour mettre à jour. J'ai récupéré ce bugfix avec tout un tas de petites évolutions. Je ne vous envoie pas de g1a/g3a immédiatement parce que je voudrais vérifier dans les prochains jours que j'ai rien cassé en faisant ça.
Une chose que je peux dire tout de suite c'est que les modules time et random qui étaient avant des alias des utime et urandom sont maintenant des modules à proprement parler, et les vieux noms utime et urandom ne devraient plus marcher.
J'ai aussi corrigé un bug d'interface graphique qui se manifestait si on naviguait dans un dossier vide ou ne contenant ni sous-dossier ni fichier *.py.
Citer : Posté le 05/01/2024 08:11 | #
Salut
J'arrive pas à build la version dev, je me retrouve avec une erreur de linkage dans la version fxcg50:
...
...
CC ../../ports/sh/modcasioplot.c
CC ../../ports/sh/modgint.c
CC ../../ports/sh/mphalport.c
CC ../../ports/sh/pyexec.c
CC ../../shared/runtime/gchelper_generic.c
CC ../../shared/runtime/stdout_helpers.c
CC ../../shared/runtime/interrupt_char.c
LINK build/firmware.elf
/home/sylvain/.local/share/fxsdk/sysroot/lib/gcc/sh3eb-elf/11.1.0/../../../../sh3eb-elf/bin/ld : build/py/objmodule.o:(.rodata+0x8c) : référence indéfinie vers « _mp_module_urandom »
collect2: erreur: ld a retourné le statut de sortie 1
make: *** [../../ports/sh/Makefile:41 : build/firmware.elf] Erreur 1
paradoxalement la version fx9860G3 build bien quand à elle, sans ce message d'erreur au linkage.
...
...
CC ../../shared/runtime/gchelper_generic.c
CC ../../shared/runtime/stdout_helpers.c
CC ../../shared/runtime/interrupt_char.c
LINK build/firmware.elf
text data bss dec hex filename
276512 1264 2816 280592 44810 build/firmware.elf
fxgxa --g1a -n PythonExtra -i icon.png build/firmware.bin -o PythonEx.g1a
Citer : Posté le 05/01/2024 09:33 | #
Hello, and (belated) Happy new year!
I get different results trying to build the dev branch
LINK build/firmware.elf
/home/iard/.local/share/fxsdk/sysroot/lib/gcc/sh3eb-elf/11.1.0/../../../../sh3eb-elf/bin/ld: build/ports/sh/modgint.o: in function `_modgint_cleareventflips':
modgint.c:(.text+0x24): undefined reference to `_cleareventflips'
/home/iard/.local/share/fxsdk/sysroot/lib/gcc/sh3eb-elf/11.1.0/../../../../sh3eb-elf/bin/ld: build/ports/sh/modgint.o: in function `_modgint_keypressed':
modgint.c:(.text+0x1e0): undefined reference to `_keypressed'
/home/iard/.local/share/fxsdk/sysroot/lib/gcc/sh3eb-elf/11.1.0/../../../../sh3eb-elf/bin/ld: build/ports/sh/modgint.o: in function `_modgint_keyreleased':
modgint.c:(.text+0x208): undefined reference to `_keyreleased'
/home/iard/.local/share/fxsdk/sysroot/lib/gcc/sh3eb-elf/11.1.0/../../../../sh3eb-elf/bin/ld: build/ports/sh/modgint.o: in function `_modgint_dcircle':
modgint.c:(.text+0x518): undefined reference to `_dcircle'
/home/iard/.local/share/fxsdk/sysroot/lib/gcc/sh3eb-elf/11.1.0/../../../../sh3eb-elf/bin/ld: build/ports/sh/modgint.o: in function `_modgint_dellipse':
modgint.c:(.text+0x558): undefined reference to `_dellipse'
collect2: error: ld returned 1 exit status
make: *** [../../ports/sh/Makefile:41: build/firmware.elf] Error 1
The main brach still builds without any error.
Citer : Posté le 05/01/2024 09:45 | #
Lard, il faut que tu update ton gint pour passer sur la branche dev
Il y a des fonctions relatives à la gestion du clavier notamment et les nouvelles primitives graphiques (dcircle/dellipse) qui sont pas poussées dans la branche main de gint pour le moment. Donc c'est normal.
Essaye de rebuild et dis nous ce que tu obtiens.
Citer : Posté le 05/01/2024 09:54 | #
Thanks for the reply, I've updated all before build and I'm using dev versions, but what I failed to notice was this
./build.sh: line 7: cd: build: No such file or directory
<sh-elf-binutils> Compiling binutils (usually 5-10 minutes)...
error: build failed, please check /home/iard/.local/share/giteapc/Lephenixnoir/sh-elf-binutils/giteapc-build.log o(x_x)o
gmake: *** [giteapc.make:13: build] Error 1
error: error 2 in command: gmake -f giteapc.make build
It puzzles me, never had this before...
PS: actually my username is iard, not Lard, but that's a common issue, happens all the time
Citer : Posté le 05/01/2024 09:58 | #
This is the content of the log file
gmake[1]: *** No targets specified and no makefile found. Stop.
gmake[1]: Leaving directory '/home/iard/.local/share/giteapc/Lephenixnoir/sh-elf-binutils'
Citer : Posté le 05/01/2024 10:51 | #
@Slyvtt Please remove the build folder and rebuild. I had the same issue.
@Iard What's happening is that GiteaPC is trying to build binutils but the build folder (which is created in configure and then removed after install) is missing. That also kind of puzzles me. My best guess is that the build folder was removed after the first normal install and now for some reason GiteaPC wants to rebuild without configure. I'm not sure why that would happen. If binutils is still installed on your system that should not prevent you from compiling add-ins, at least.
Citer : Posté le 05/01/2024 10:54 | #
J'ai creusé le bug de non-fermeture du fichier en cas d'erreur. Long story short, c'était la faute de MicroPython, c'était un bug qui a été corrigé il y a quelques mois.
La version de MicroPython sur laquelle PythonExtra était basé datait d'Octobre 2022, donc j'ai fusionné pour mettre à jour. J'ai récupéré ce bugfix avec tout un tas de petites évolutions. Je ne vous envoie pas de g1a/g3a immédiatement parce que je voudrais vérifier dans les prochains jours que j'ai rien cassé en faisant ça.
Une chose que je peux dire tout de suite c'est que les modules time et random qui étaient avant des alias des utime et urandom sont maintenant des modules à proprement parler, et les vieux noms utime et urandom ne devraient plus marcher.
J'ai aussi corrigé un bug d'interface graphique qui se manifestait si on naviguait dans un dossier vide ou ne contenant ni sous-dossier ni fichier *.py.
Super !
Citer : Posté le 05/01/2024 11:26 | #
Tiens Mb pendant que tu es là n'hésite pas à fermer cette question du coup
Citer : Posté le 05/01/2024 11:57 | #
Hello, sorry Iard, I got confused between uppercase "i" a,d lowercase "l".
@Lephe, will try to check if by removing the build folder it solves the problem. I am pretty sure I already made this but will redo to be 100% sure. I'll keep you posted when done.
Citer : Posté le 05/01/2024 13:24 | #
@Lephe, je confirme qu'en supprimant le dossier build et en recompilant cette fois ça passe.
Je vais passer aux tests pour voir si il y a des changements effectifs.
En fait j'ai pas dû virer le dossier correctement la première fois comme je le pensais.
Merci beaucoup.