Un IDE avancé pour Casio - Idées et roadmap
Posté le 22/02/2025 13:23
Hello,
il y a quelques semaines, nous parlions avec la sortie du mod MPM+ pour la Math+ de nous lancer dans un projet d'IDE (
Integrated Development Environment) capable de gérer possiblement divers langages.
Il s'agirait pour faire simple de partir d'une base connue type
PythonExtra et de lui ajouter un module d'édition de code.
Idéalement cet IDE ferait :
permettre d'éditer du code "on-calc" avec lecture/modification/écriture dans des scripts existants et/ou créés directement depuis la partie éditeur. On aimerait avoir les features avancées suivantes :
- Coloration syntaxique pour les langages les plus courants (sur calculatrices) : Python / Basic / Lua / ...
- Recherche dans le code d'une occurrence
- Frappe avancée et optimisée du code : catalogue de fonctions, raccourcis claviers malins (éventuellement configurables)
naviguer dans les fichiers de sources
- possibilité d'uploader/downloader des fichiers depuis/vers un PC directement depuis l'application
- possibilité d'ouvrir le script dans l'éditeur, de lancer son execution
- pourquoi pas faire un backup, une compression, ...
- voir un asset graphique (BMP)
exécuter du code
- possibilité de lancer du code et de suivre son évolution dans un shell intégré (graphique/console)
- entrée/sorties de valeurs
Ce fil est pour échanger sur le sujet, pour éventuellement demander des trucs en plus, dans la limite du raisonnable (on compilera pas du C++ on-calc), sachant qu'on a déjà testé 2/3 trucs avec Lephé et qu'il y a des limites techniques à être sur une calculatrice (RAM, puissance, taille écran) et avec lesquelles il faut fonctionner. Notamment l'option Tree-Sitter pour la coloration syntaxique nous a fortement refroidie (c'est trop gourmand pour une calculatrice).
A priori à ce stade, on utiliserait une base entre PythonExtra et
TextViewer "boosté aux amphétamines", donc interface JustUI et gint/fxlibc en motorisation.
On se donne un peu de temps pour poser bien le projet car c'est un gros truc et on veut faire ça bien, sans être dans la précipitation.
Il faut aussi qu'on regarde comment éventuellement supporter d'autres langages car autant notre connaissance de Python est pas mal (via micropython), autant pour d'autres langages on a pas encore checké (Lua/LuaFX, Basic, Malical, ...).
N'hésitez pas à partager vos avis/idées. C'est le moment.
Citer : Posté le 22/02/2025 23:14 | #
Salut Sly
Pourquoi pas un Github Copilot intégré dans l'IDE?
Sinon, j'ai une question, tous ça sera un seul add-in ou plusieurs? Car par exemple, moi qui suis intéressé au Python et au Lua, si il y aura un interpreteur Malical inclu dans l'addin, je pourrais le considérer comme stockage "gaspillé" si tu comprends ce que je veux dire.
Mais en même temps, avoir plusieurs différents add-in peut être un peu mal organisé ou "all over the place"... (je n'aide pas en fait xD)
D'ailleurs, j'y ai pensé que le HTML pourrais être cool mais comme tu as dit, les dimensions de l'écran de la calculatrice est limitant mais en mettant les texts verticals (et du coup tourné l'écran 90°) pourrais peut être le faire?
Sinon, j'espère pouvoir m'acquérir une G90 d'ici début avril alors ce projet m'intéresse beaucoup
Voilà tout ce que je voulais dire
Bonne soirée
Par ce que Oct 31= Dec 25
Citer : Posté le 22/02/2025 23:32 | #
Salut.
Le but est d'avoir une base commune au maximum, donc assez souple, mais qui ensuite est intégrée dans différents addins, un par langage.
On se bat pour les ressources alors faire un addins qui permettrait de gérer 2, 3 ou plus langages ne semble pas très pertinent.
En plus beaucoup seront intéressés seulement par 1 ou 2 langages différents donc auraient plein de modules en trop inutiles.
Citer : Posté le 02/03/2025 15:11 | #
Il y a un truc qui m'échappe encore et qu'on n'a pas résolu c'est comment on mélange les langages techniquement.
Soit un fait un truc monolithique où tous les langages sont dans le même add-in avec un éditeur mais c'est sans doute trop gros comme évoqué ci-dessus.
Soit il y a en gros une app centrale IDE et on utilise des interpréteurs externes sans que les interpréteurs aient d'interface graphique, auquel cas il faut en gros forker la partie UI de PythonExtra de la mettre dans l'IDE pour ne garder que l'exécution.
Citer : Posté le 03/03/2025 15:15 | #
La deuxième option me plait bien perso, mais là tout de suite je sais pas comment la mettre en place.
Faudrait une app IDE centrale que l'on builderait en associant le bon interpréteur (et Lexer pourquoi pas pour la coloration) afin de donner une appli complète pour un langage.
Par exemple IDE + micropython + Lexer python --> PythonExtra 2.0
ou IDE + luafx + Lexer Lua --> LuaExtra (
ou IDE + malical + Lexer MLC --> MalicE (
Faudrait réussir à tout bien scinder, faire des API propres et commune, ce qui implique une analyse du fonctionnement assez précise de chacun des interpréteurs afin de checker comment il fonctionne.
Ca implique aussi de voir quels sont les meilleurs clients pour les langages.
Perso, je verrais bien :
1/ Python
2/ C.Basic
3/ Lua (ou LuaFX)
4/ MLC (Malical)
Franchement je sais pas où ceci nous emmène, j'ai du mal à voir la complexité du bouzin dans son ensemble. Mais le projet est hyper motivant.
Citer : Posté le 03/03/2025 15:49 | #
Hello,
C'est l'experte locale en Malical qui aimerais vous faire savoir que le MLC et le Malical sont deux languages differents.
https://www.planet-casio.com/Fr/forums/topic14371-1-est-ce-que-je-peux-programmer-en-tel-langage-sur-ma-calto.html
Bisous 💜
L'experte locale en Malical
Citer : Posté le 03/03/2025 15:54 | #
Youps
Merci pour l'explication.
D'ailleurs en tant qu'Experte Locale en Malical, aurait tu des liens vers le projet originel car les lien du Malical (et du MLC aussi d'ailleurs) sont out soit cassés soit morts (ce qui revient au même)
Citer : Posté le 03/03/2025 16:07 | #
La page du wiki pc marche encore, c'est juste le certificat qui est cassé.
https://wiki.planet-casio.com/en/Malical
De la tu as le lien de DL casiopeia (https://www.casiopeia.net/forum/downloads.php?view=detail&df_id=25), et l'anonce casioscene (rip) à été crosspost ici: https://community.casiocalc.org/topic/6855-malical-25-an-alternative-language-to-basic/
Sinon pour l'original, le vrai topique d'origine. Il faut savoir que c'est un project des amis de chez cncalc (genre PC mais tout le monde parle chinois):
https://www.cncalc.org/thread-6900-1-1.html
Citer : Posté le 03/03/2025 16:14 | # |
Fichier joint
@Slyvtt @Hackcell
The source code is actually available there but requires 2 cnCalc coins for downloading (lmao), and is also splited into 2 .rar archives. I rezipped them into a single .zip file and upload here instead
Citer : Posté le 03/03/2025 17:58 | #
Faudrait une app IDE centrale que l'on builderait en associant le bon interpréteur (et Lexer pourquoi pas pour la coloration) afin de donner une appli complète pour un langage.
Par exemple IDE + micropython + Lexer python --> PythonExtra 2.0
ou IDE + luafx + Lexer Lua --> LuaExtra (
ou IDE + malical + Lexer MLC --> MalicE (
Est-ce idéal d'avoir un add-in par langage ? Vu que ça dupliquerait tout l'éditeur et la base (gint coûte quand même de la place), et la place est plutôt limitée sur la Math+ notamment. J'aurais été tenté de jouer une carte un peu différente :
- Un add-in central "IDE" contenant l'éditeur, la console, et des grammaires courantes.
- Pour chaque language, un blob interpréteur/console genre ide-py.bin, ide-lua.bin, qui ne soit pas un add-in.
- L'IDE charge l'interpréteur et le connecte à la GUI.
La subtilité serait alors de bien choisir l'interface entre l'UI et les interpréteurs. Le faire proprement pour C.Basic serait aussi une direction fascinante, cela dit C.Basic est probablement "le plus avancé" déjà donc je me précipiterais pas pour le changer.
Citer : Posté le 03/03/2025 18:28 | #
Du linkage dynamique. J'en rêvais sans oser demander 🥰
C'est mon rêve de déporter tout de qui pèse dans des dlls.
J'achète !!!
Citer : Posté le 03/03/2025 19:05 | #
Ok, on est d'accord. Le link resterait statique je pense, sous l'hypothèse qu'on ne charge jamais plus d'un interpréteur à la fois.
Citer : Posté le 03/03/2025 19:46 | #
Bein ça on peut forcer le truc.
On force à tout "décharger" avant de recharger un nouveau.
Si l'IDE s'en charge, ça devrait rester sous notre maîtrise.
C'est le mécanisme qu'utilise Parisse avec Khicas en 2 morceaux si je comprends bien.
J'ai pas forcément étudié le truc, si j'ai bien compris on installe la lib en mémoire, un peu comme Addin Push (ou mpm.bin) fait avec la partie executable, ainsi qu'une table d'adresses pointant vers les fonctions de la lib? C'est ça ? Et du coup le call de la function donne un jump vers l'adresse contenue dans le tableau pour la fonction données (un peu comme les syscalls dans les OS de Prizm/fxCG50).
Citer : Posté le 04/03/2025 12:48 | #
Ok je pense que j'ai un design en tête qui sera pas trop dur à construire (i.e. pas de libs dynamiques) mais donnerait cette flexibilité.
D'abord, on compile les interpréteurs, séparément chacun de leur côté, sous la forme de bibliothèques, genre libide_python.a. Les interpréteurs peuvent à ce stade appeler des fonctions de la libc et de gint mais la lib ne contient que le code de l'interpréteur.
Ensuite, on écrit l'add-in principal "normalement", on choisit une adresse fixe à laquelle charger l'interpréteur en cours en RAM (probablement dans la RAM haute après 0x8c200000). Et on utilise un linker script qui :
- Met l'add-in lui-même à 0x00300000 comme d'habitude
- Crée un overlay où les libs vont toutes à dans la RAM haute à la même adresse (comme une union)
Et enfin de l'ELF résultant on garde que l'add-in pour faire le g3a, on met à la place les éléments de overlay dans des fichiers annexes ide_python.bin, ide_lua.bin, etc. que l'add-in peut charger à l'exécution.
Avantages :
- Un seul build statique donc les interpréteurs peuvent utiliser la libc/gint librement sans code spécial et ce serait mutualisé avec l'IDE.
- On peut installer ou pas les interpréteurs pour limiter la mémoire de stockage utilisée.
Inconvénients :
- Il faut trouver une adresse fixe pour l'overlay. On peut viser 0x8c200000 ce qui nécessiterait juste un peu d'ajustement côté Math+ pour pas créer l'arène _ld1 trop vite.
- Le g3a de l'IDE et les binaires des interpréteurs sont intimement liés donc chaque changement au g3a nécessite de recompiler les interpréteurs, et ajouter un interpréteur nécessite de mettre à jour le g3a.
Citer : Posté le 04/03/2025 16:57 | #
Ce qui n'est pas très clair dans ma tête non plus ce sont les modalités des "échanges" entre l'IDE et l'interpréteur.
L'IDE pourrait envoyer le code à l'interpréteur, oui lui indiquer le script, par contre comment on gérerait le shell / la console ?
Comment on indique à l'interpréteur comment afficher en retour dans le shell de l'IDE ?
J'ai du mal à voir.
Et question bonus: est-ce que ce potentiellement ceci serait compatible avec un Debugger à terme (je demande pas cette feature pour le moment, je réfléchis à la structuration).
Citer : Posté le 04/03/2025 17:57 | #
Dans la version que je propose tout est linké en semble donc les échanges sont juste des appels de fonction. Pour une interface unifiée l'interpréteur peut donner une liste de pointeurs de fonction représentant les fonctionnalités principales (genre exécuter un fichier ou une ligne de shell). Mais on peut aussi créer des cas particuliers partout avec "si langage courant est Python alors appeler python_truc()".
Oui ce serait a priori compatible avec un debugger ; je ne sais pas très clairement quelle forme prendrait un debugger mais comme on peut appeler n'importe quelle fonction n'importe comment, je suis sûr que ce ne serait pas une limitation.
Imagine en gros que je coupe un g3a (IDE + Python + Lua + ...) en plusieurs morceaux et qu'à l'exécution je le charge depuis plusieurs fichiers. C'est toujours un add-in complet, je l'ai juste chargé d'une façon inhabituelle. Avec la subtilité que tu charges pas tous les morceaux en même temps.
Citer : Posté le 05/03/2025 10:34 | #
Ca me parait très intéressant, et certainement utilisable sur une foultitude d'autres projets (je pense par exemple à un lecteur d'images qui pourrait être construit de manière modulaires (1 module par format d'image par exemple).
Quand tu auras le temps, je serai preneur d'un exemple minimal d'utilisation du concept, mais y'a pas d'urgence. Car j'imagine qu'il doit y avoir quelques règles d'écriture pour que ça fonctionne.
Citer : Posté le 27/03/2025 18:10 | #
Voilà un proto du système en question : https://git.planet-casio.com/Lephenixnoir/ide (accès Slyvtt)
Pour l'instant privé parce que c'est pas clair où on va et c'est un peu le bazar.
Globalement ce système permet de construire un gros add-in avec tous les langages dedans en même temps, et ensuite de garder que l'UI dans le g3a et mettre chaque language dans un .bin optionnel. À l'exécution on peut passer d'un .bin à l'autre à volonté et on n'installe que ceux qu'on veut. Par contre on ne peut en utiliser qu'un à la fois.
Ce que je ferais bien ce serait prendre la partie UI de PythonExtra, la mettre dans le g3a de l'IDE, ajouter un éditeur, et après faire de PythonExtra le .bin qui fournit le langage Python.
Citer : Posté le 27/03/2025 19:54 | #
Bien reçu, je regarde comment fonctionne le truc.
C'est fonctionnel sur math+ ou seulement sur G90 ? En fait c'est purement une question pratique pour savoir si je dois prendre ma G90 lors de mes balades ou si seulement la Math+ c'est OK, car sur M+, on a pas du tout le même mapping mémoire pour charger les modules.
Citer : Posté le 27/03/2025 20:36 | #
J'ai testé que sur 90+E, j'utilise 8c200000, donc sur Math+ probablement pas. Mais je peux le porter si besoin