[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.3 (Changelog)
Graph 35+E II / 
Prizm / 
Graph 90+E : PythonExtra-pe-0.3.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 03/03/2025 18:03 | #
Mis à jour le lien de téléchargement du post principal, que SlyVTT m'a indiqué est légèrement pas à jour. o(x_x)o
Citer : Posté le 16/03/2025 16:53 | #
Wow c'est magnifique comment PE avance !
J'attends avec impatience l'éditeur, et d'ailleurs est ce que vous avez réussi à utiliser la ram étendue dans PE depuis la dernière fois où j'avais essayé (ça remonte à assez longtemps maintenant) ?
Citer : Posté le 16/03/2025 17:26 | #
Salut, tu parles sur G35+EII ? Dans ce cas hélas là réponse est bofbof !! On a un peu de RAM en plus et Lephé a amélioré la console pour diminuer la consommation de RAM par PythonExtra en lui-même, mais globalement la quantité de RAM reste un souci permanent sur la G35+EII.
On avait pensé un moment à utiliser la PRAM, mais pour le moment rien n'est fait sur ce point. Sachant que c'est un peu plus compliqué car il y a un système particulier à mettre en place (on peut utiliser seulement 3 octets sur 4 sur la plage).
Pour la G90+E et la Math+ désormais, on est large.
Pour la Prizm, on est moins large, mais on a quand même les mains plus libres que sur G35+EII.
Je ne sais pas si cela répond à ta question.
Citer : Posté le 16/03/2025 17:30 | #
Oui je parlais de la G35+eII. Je ne me souviens plus où est ce qu'on avait essayé de récupérer de la ram avant. C'est peut être encore dans un #if dans le code
Citer : Posté le 16/03/2025 17:35 | #
Globalement la RAM que l'on donne à micropython est définie ici sur G35 : https://git.planet-casio.com/Slyvtt/UltimatePython/src/branch/main/ports/sh/main.c#L417-L445
On a l'arène "_os" et pour debug on prend dans la RAM Python, mais c'est un peu "touchy" donc on laisse pas cette partie dans les versions release sans mode Debug.
Idéalement il faudrait en trouver ailleurs.
(je donne le lien dans la version Ultimate qui sert de base pour tester micropython 1.25, mais c'est pareil dans PythonExtra)
Citer : Posté le 25/03/2025 13:49 | #
Résumé pour Sly qui veut voir les polices, pendant que je regarde l'upgrade de MicroPython (merci !). Le template est le cas des images qui suit exactement la même méthodologie.
1. Il faut de quoi manipuler le type de données. Pour les images, voir objgintimage.h et objgintimage.c. Un prérequis important est que les champs qu'on va définir comme des bytes/bytearray en Python doivent être des pointeurs. Pour les images il y avait à un époque un champ u16 data[] en fin de structure qui a été remplacé à un moment par un pointeur void *data. Sans ça on pourrait pas faire nos affaire facilement en Python. Pour les images il n'y a pas de tableau donc ça devrait le faire.
La question donc c'est quels champs sont des objets non triviaux comme des memoryview ou des chaînes de caractères. Mes notes dans objgintfont.c (qui est à écrire avec le header objgintfont.h associé) donne les indications suivantes :
Un bon début serait donc d'écrire les constructeurs. Il faut en gros deux constructeurs, objgintfont_make_fixed() pour les fixed-width et objgintfont_make_proportional() pour les proportionnelles, vu que les arguments sont pas les mêmes. Plus une fonction interne font_print() dans le même style que image_print() pour vérifier que les objets construits sont corrects.
2. Générer les données dans fxconv. Ça c'est pas trop dur, il faut se mettre dans la fonction de conversion principale associée au type de données. Il y a une sous-fonction qui fait l'encodage et renvoie tous les tableaux. Ensuite il suffit d'ajouter un if python dans lequel on retourne un appel au constructeur. Exemple pour les images. À partir de là ou peut convertir une police réelle avec fxconv et vérifier que son print est correct.
3. Enfin s'en servir pour appeler les fonctions de gint. La structure font_t est à générer à la demande parce que le format de stockage interne de µPy n'est pas celui de gint. Pour ça faire une fonction objgintfont_get() similaire à objgintimage_get(). Notez qu'on ne copie pas les données c'est juste un réagencement en surface des champs de la structure. Et ça on s'en sert dans les fonctions type dimage(), à part que là c'est dfont(). dfont() renvoie aussi l'ancienne police, pour ça il faut pouvoir reconvertir de gint vers Python, d'où la fonction objgintimage_make_from_gint_image() à laquelle il faudra un équivalent. Note que du coup les buffers/memoryview manipulés par objgintfont ne sont pas forcément des buffers Python. Il faut bien traquer si c'est le cas ou pas (ce que le code pour les images fait bien).
Rien de très révolutionnaire dans l'ensemble mais il faut le faire rigoureusement.
Potchkee Invité
Citer : Posté le 25/03/2025 17:03 | #
Lephe, thanks for all your work. I learned python through the example programs you provided and I wrote a sudoku program using the Casio python script editor that runs beautifully on extrapython. Can't wait for your script editor release. Just wondering if you still have plans to implement support for reading and writing files?
Citer : Posté le 25/03/2025 17:52 | #
Thanks for the kind words! SlyVTT already has a prototype for reading/writing files in scripts (open() and stuff) more or less ready to be merged. There are a few changes we need to make before that such as getting up-to-date with the latest MicroPython version. But this shouldn't be difficult as this was all tested already. So yes still plans and in fact possibly soon™
As for a script editor this will take more work but the plans for a full IDE-type program are underway. No deadlines for this however.
Potchkee Invité
Citer : Posté le 25/03/2025 22:53 | #
Good to hear! Also, once I'm here, maybe you can tell me a program/website to find the closest 4x16bit hex code/number for colors that gint seems to use? Unless I'm missing something and there is a way it can take regular 6x16bit color codes? For now I wrote a quick program that generates random colors.
Potchkee Invité
Citer : Posté le 25/03/2025 23:15 | #
Nevermind- I found a website. Here it is for anyone else interested:
https://rgbcolorpicker.com/565
Apparently it's called 16 bit high color or rgb565. Red and blue get 5 bits while green gets 6 bits.
Citer : Posté le 26/03/2025 08:03 | #
You got it! This format comes from the display, not gint itself. Using integers for colors instead of tuples is a bit inconvenient but it's much much faster, so definitely a better option overall. You can use gint.C_RGB(r, g, b) to create a color from 3 RGB values each ranging from 0 to 31 (the extra bit for green is ignored for uniformity).