Les projets de Planète Casio pour 2025
Posté le 02/01/2025 20:00
Je pense que la nouvelle année est une bonne occasion pour remettre les pendules à l'heure sur les projets de Planète Casio. Juste pour clarifier, il s'agit du site en général, pas de moi personnellement, même si ça intersecte souvent.
La
dernière fois qu'un tel plan a été formulé, on en a tiré quelques mois de bon travail avant que le momentum s'essoufle, et on a à mon avis tout intérêt à recommencer.
Je vois 4 axes (sans ordre particulier) pour démarrer la discussion sur ce qu'on peut viser de faire :
Événements
Il y a des nouveautés côtés partenariats déjà. Vous avez sans doute vu le logo
Calcuso sur la page d'accueil ; ça date des dernières
journées APMEP, d'où on a ramené deux choses : des calculatrices offertes par
CASIO Éducation (techniquement ce n'est pas nouveau, mais on n'en demande pas au titre des événements de Plnaète Casio toutes les années), et un partenariat avec Calcuso qui nous a sponsorisé des housses de protection (en trésorerie sous peu) ainsi qu'une calculatrice avec une gravure au choix de la personne qui mettra la main dessus.
Parmi les événements j'aimerais organiser du nouveau un ou plusieurs week-ends de test, et on a de quoi faire pas mal de concours. N'hésitez pas à dire quels formats vous aimez bien ou si vous avez des idées uniques !
Préservation des contenus historiques
On se retrouve un peu à la croisée de chemins cette année avec beaucoup de vieux contenus en danger : en plus des programmes vieillissants dont on ne sait pas s'il marchent encore par manque de test (les vieux add-ins mono SH3 ?), on a une très grande quantité de programmes Basic qui ne marchera pas sur la Math+, et même dans le cas idéal où on porte
C.Basic il n'est pas garanti que tous marchent bien. À ça s'ajoutent, pour les programmes les plus vieux, des difficultés avec les logiciels de transfert qui peuvent ne plus marcher sous les versions récentes de Windows ou être perdu sur des pages disparues, un chantier déjà attaqué sous plein d'angles par
Cahute.
Une bonne partie de ce qui touche add-ins est à ma portée technique mais il restera dans tous les cas plein de travail sur les programmes Basic et le recensement des programmes qui marchent, ou pas.
Assurer la continuité de la programmation communautaire sur la Math+
Ça c'est l'affaire du
mod Math+, MPM, qui progresse doucement mais sûrement des nouvelles que j'ai. On attend de voir si CASIO va nous laisser faire nos add-ins dans notre coin ou continuer de supprimer des fonctionnalités. Ça reste une question assez existentielle mais pour l'instant la balle n'est pas dans notre camp (jusqu'à la publication officielle du mod en tous cas).
Daily-drive admin de la v5
La v5 est le dindon de la farce depuis longtemps mais les justifications techniques et de maintenance long terme sont toujours aussi valides qu'avant. On a remarqué plusieurs fois avec
Eragon que ça avance quand on s'y met, mais les heures ne sont juste pas là. De la main d'oeuvre serait hautement désirée.
Le but que je voudrais atteindre dans l'immédiat est de pouvoir synchroniser/importer assez de contenus pour que je puisse utiliser la v5 quotidiennement pour lire les messages, après quoi je suis confiant que le polissage suivra rapidement.
Donc voilà pour mes intuitions. Peut-être que les membres impliqués auront d'autres opinions sur ce qu'on a intérêt à privilégier : exprimez-vous, c'est le topic pour ça !
Citer : Posté le 07/01/2025 22:04 | #
Si je me rappelle bien, la licence de kiwitext ne nous permet pas d'utiliser quoi que ce soit. Faudrait que je regarde dans le détail.
En effet il y a un copyright et pas de licence, et pas les sources, donc dans l'immédiat on risque pas d'aller loin.
Citer : Posté le 07/01/2025 22:36 | #
Ne pas y avoir pensé, ce qui est maintenant corrigé. Est-ce que tu as des sources et/ou un poil de doc quelque part ?
Il n'y a pas de doc développeur. Le code initial provient de eigenmath en fait, je l'ai pas mal adapté. Les sources:
https://www-fourier.univ-grenoble-alpes.fr/~parisse/casio/python90.tgz
https://www-fourier.univ-grenoble-alpes.fr/~parisse/casio/python35.tgz
Ca utilise le prizm-sdk et ma version de la ustl, et c'est intégré avec le shell de micropy, mais ça ne devrait pas être trop difficile à extraire l'éditeur (textGUI.cc/.h) et le porter sur une autre toolchain pour Casio (avec support de la STL), vu que j'ai porté l'éditeur sur la toolchain de la ti83 (https://www-fourier.univ-grenoble-alpes.fr/~parisse/ti/shell.tgz).
J'avais comme objectif d'avoir un SDK universel pour calculatrices (k_csdk.c/k_csdk.h) qui permettrait de compiler pour ti83/ti nspire/casio et numworks, et on retrouve un peu de ça dans calc.h, mais je ne suis pas assez ordonné pour finaliser tout ça proprement.
Citer : Posté le 08/01/2025 10:49 | #
Effectivement Sly je pense que tu as raison. J'ai pondéré d'en mettre un dans PythonExtra mais faudrait commencer par un add-in auto-suffisant.
Je pense qu'on a tous les outils pour ce faire, personnellement si je devais me lancer je le ferais avec JustUI + une piece table + tree-sitter.
Je sais que c'est pas la première fois qu'on en parle, donc voilà ce que je peux vous proposer : je peux coder le prototype avec les libs qui compilent/configure comme il faut, les bases pour la structure de données et l'UI et je vous laisse la patate une fois que ça marche pas trop mal. C'est pas un truc que je peux maintenir long terme, mais si ce qu'il faut c'est démarrer, je peux.
Ca c'est une super bonne idée, en particulier sur la G90. Un truc propre avec syntax highlighting serait hyper cool. Faudrait aussi réfléchir à un système rapide pour taper/modifier du code, en particulier pour les caractères non alphanumériques (symboles), car là c'est vite chiant. Et apprendre une keymap virtuelle par cœur, bof !!
Sur la G35+EII, on risque par contre de cramer pas mal de RAM, déjà qu'on est cheap sur PythonExtra. Je le mettrais personnellement en priorité 2 pour cette machine, On aurait je pense intérêt à minimiser l'empreinte en RAM de la partie "IDE" pour maximiser ce qui reste pour exécuter les scripts. Mais ce n'est que mon humble avis.
Citer : Posté le 08/01/2025 11:08 | #
Je ne cache que ce serait utile d'avoir des fonctions un peu "avancées" pour contrer la difficulté de taper sur la calto. Un truc à la con c'est que une fois le code parsé (e.g. avec tree-sitter) on doit pouvoir savoir où sont les définitions de fonction et donc sauter directement à la fonction suivante/précédente. Ce genre de raccourcis est déjà utile sur PC alors sur la calto ça doit être encore mieux.
Ça fait longtemps que j'utilise pas activement ma calto comme périphérique interactif (je fais les manips de ce genre sur mon PC) et je le regrette un peu, c'est peut-être l'occasion d'améliorer cet expérience.
Pour ce qui est de l'empreinte mémoire, plusieurs options : si tu as un add-in séparé tu décharges l'IDE quand tu lances PythonExtra, et sinon tu peux toujours bouger les données dans les zones mémoire dures à utiliser (genre la mémoire fragmentée SPU) que Python n'utilise pas.
Citer : Posté le 08/01/2025 12:40 | #
Ca c'est une super bonne idée, en particulier sur la G90. Un truc propre avec syntax highlighting serait hyper cool. Faudrait aussi réfléchir à un système rapide pour taper/modifier du code, en particulier pour les caractères non alphanumériques (symboles), car là c'est vite chiant. Et apprendre une keymap virtuelle par cœur, bof !!
L'éditeur de micropy ou de KhiCAS dispose de syntax highlighting (par soulignement sur la 35), parenthese match, numérotation de ligne, search/replace, line wrapping. L'addin a une table de caractères qu'on active depuis le shell ou l'editeur avec shift-INS, et des menus rapides qui permettent de saisir les caractères les plus utiles non présents au clavier ainsi que les structures de programmation et des raccourcis pour indenter ou accéder à l'aide en ligne sur certaines commandes. KhiCAS dispose enfin d'un debugger interactif pour executer un programme pas à pas avec affichage des variables.
Cela permet de travailler assez confortablement oncalc sur des scripts jusqu'à quelques dizaines de lignes, ce qui est plus que suffisant dans un cadre scolaire.
Citer : Posté le 08/01/2025 14:12 | #
Il n'y a pas de doc développeur. Le code initial provient de eigenmath en fait, je l'ai pas mal adapté. Les sources:
https://www-fourier.univ-grenoble-alpes.fr/~parisse/casio/python90.tgz
https://www-fourier.univ-grenoble-alpes.fr/~parisse/casio/python35.tgz
Ca utilise le prizm-sdk et ma version de la ustl, et c'est intégré avec le shell de micropy, mais ça ne devrait pas être trop difficile à extraire l'éditeur (textGUI.cc/.h) et le porter sur une autre toolchain pour Casio (avec support de la STL), vu que j'ai porté l'éditeur sur la toolchain de la ti83 (https://www-fourier.univ-grenoble-alpes.fr/~parisse/ti/shell.tgz).
J'ai jeté un oeil. Ça a l'air assez isolé du reste pour être extrait en effet. Je dois reconnaître que la prise en main et les modifs futures semblent moins triviales. J'ai pas vu où était faite la coloration syntaxique ?
Complètement au hasard mais le memmem() que tu utilises ne marche pas, il échoue à trouver "aac" dans "aaac". Son auteur ne s'étonne pas d'avoir la complexité (algorithmique) de KMP sans la complexité (difficulté) de KMP, ce qui est bien sûr trop beau pour être vrai
Citer : Posté le 08/01/2025 15:29 | #
Si on repose sur des vieilles lib et un vieux SDK plus maintenu, mieux vaut peut être directement partir sur du from scratch mais up to date. Sinon on va juste creuser un peu plus notre dette technique.
L'homogénéisation avec JustUI, la STL officielle + des libs à jour me semble un compromis nettement plus porteur sur le long terme.
Citer : Posté le 08/01/2025 16:18 | #
memmem n'est pas utilisé, je n'ai juste pas nettoyé le code depuis la version initiale codée par Gabriel Maia.
La coloration syntaxique est générée par find_color, qui est défini dans main.cc et appelle des fonctions relatives à Python.
L'utilisation du prizm-sdk me semble un aspect mineur, puisque j'ai porté le même éditeur sur le ti83/84-ce sdk (bon en fait, sur la version ti83/84 j'ai du faire des optimisations en raison de la lenteur du processeur et je ne les ai pas back-portées). La ustl et la stl sont compatibles pour l'usage de l'éditeur (à savoir string et vector), ça ne devrait pas poser de problèmes (juste enlever des ustl ou les remplacer par des std).
Et en fait travailler sur une compatibilité des sources prizm-sdk avec gint pourrait être intéressant pour porter certains addins fxcg50 vers le MPM, non?
Citer : Posté le 08/01/2025 16:40 | #
La coloration syntaxique est générée par find_color, qui est défini dans main.cc et appelle des fonctions relatives à Python.
Oh je crois que je vois. Donc si je comprends bien tu découpes les mots au fur et à mesure que tu les vois venir et tu colores dans textarea_disp() à la volée, mais tu parses jamais le code... ?
L'usage du PrizmSDK est mineur... oui et non. En tant que système de compilation c'est "équivalent", mais y'a pas mal de fonctions utiles dans le fxSDK malgré tout : compilo plus à jour, libc plus complète/optimisée, la vraie lib C++, des floats plus rapides, et dans gint de quoi customiser les polices, une lib GUI qui évite de tout dessiner/positionner à la main, malloc() plus flexible avec une plus grande capacité, des facilités pour manipuler les fichiers, dans l'ensemble des choses qu'on a de prime abord envie d'utiliser dans un éditer de texte.
Accessoirement, y'a le coté long-terme qu'effectivement les add-ins PrizmSDK seront de toute façon plus durs à faire marcher sur la Math+ que les add-ins gint, et plus y'a de fonctions système utilisées plus c'est tendu.
Le côté qui me pose plus question c'est l'enjeu discuté d'avoir un éditeur de texte pour Python, Lua, potentiellement du C, où c'est la partie langage qui est surtout subtile. La partie interface j'ai déjà personnellement programmé ce machin-là avec word wrap, recherche, des polices, etc. ce qui est pas le plus difficile. La partie manipulation de texte peut poser des subtilités mais je suis pas convaincu que vector<string> découpé sur la syntaxe soit le meilleur plan et je sais pas si on peut découpler ça dans ton code. Voilà un peu ce qui me passe par la tête en gros.
Sur le principe, oui tout à fait. Une difficulté qui rend ça pas totalement gratuit est que les addins PrizmSDK peuvent utiliser des fonctions ou adresses directement sans passer par API auquel cas il faudrait réécrire des bouts au cas-par-cas. Mais surtout on n'a majoritairement pas les sources ! Sur Planète Casio la pratique de les inclure systématiquement (+ Git/open-source) a été poussée pendant le vide entre la Prizm et la 90+E où la plateforme était peu active et quand la 90+E est sortie gint était devenu le choix le plus courant via la mono. Faudrait que je tire les stats pour pas te mentir mais j'avais déjà ce ressenti à la sortie de la 90+E : https://www.planet-casio.com/Fr/forums/topic15127-last-portage-des-add-ins-prizm-sur-graph-90.html
Citer : Posté le 08/01/2025 16:56 | #
Oh je crois que je vois. Donc si je comprends bien tu découpes les mots au fur et à mesure que tu les vois venir et tu colores dans textarea_disp() à la volée, mais tu parses jamais le code... ?
Exactement.
L'usage du PrizmSDK est mineur... oui et non. En tant que système de compilation c'est "équivalent", mais y'a pas mal de fonctions utiles dans le fxSDK malgré tout : compilo plus à jour, libc plus complète/optimisée, la vraie lib C++, des floats plus rapides, et dans gint de quoi customiser les polices, une lib GUI qui évite de tout dessiner/positionner à la main, malloc() plus flexible avec une plus grande capacité, des facilités pour manipuler les fichiers, dans l'ensemble des choses qu'on a de prime abord envie d'utiliser dans un éditer de texte.
Oui, bien sur, je pense aussi qu'il faut passer à fxSDK. Ce que je voulais dire c'est que dans un monde idéal, du code source écrit avec les noms de syscalls du prizmSDK (au moins les plus courants) devraient pouvoir aussi se compiler avec fxSDK. En tout cas si je veux porter KhiCAS vers le fxSDK, ça m'arrangerait bien que les syscalls que j'utilise le soient :-)
La partie manipulation de texte peut poser des subtilités mais je suis pas convaincu que vector<string> découpé sur la syntaxe soit le meilleur plan et je sais pas si on peut découpler ça dans ton code. Voilà un peu ce qui me passe par la tête en gros.
A mon avis, c'est pas mal d'utiliser un vector<string>, on n'a pas à gérer la mémoire à la main, et une ligne ce n'est pas très gros en général, la STL n'a que des petits blocs mémoire à allouer. Mais bon, personnellement, ce n'est pas du tout le genre de code qui m'amuse, j'utilise un truc qui marche raisonnablement pour un langage de script (Python ou Xcas), sans me poser plus de questions. Adapter à Lua ou à Javascript (quickjs par exemple) devrait être relativement aisé.
Programmer en C sur la 90, je ne pense pas que ce soit raisonnable. Sur une hp prime G2 peut-être...
Citer : Posté le 08/01/2025 16:59 | #
C'est quelque chose de possible, je me note de le faire pour toi et je te tiendrai au courant.
Citer : Posté le 08/01/2025 17:19 | #
Après si c'est que pour moi, je peux aussi créer la couche de compatibilité moi-même, c'est exactement ce que j'ai fait pour la ti83 ou la numworks, mais je ferai ça à ma sauce, certainement pas de façon propre :-)
Est-ce qu'il y a un équivalent de https://prizm.cemetech.net/ pour la doc du fxSDK?
Citer : Posté le 08/01/2025 20:47 | #
Si on multiplie les langages supportés (LuaFX, MLC, ...), il serait intéressant de créer un éditeur spécifique pour coder on calc. On pourrait réutiliser le code de PythonExtra pour gérer ces différents langages.
Mini Militia App Lock
Citer : Posté le 09/01/2025 10:43 | #
Après si c'est que pour moi, je peux aussi créer la couche de compatibilité moi-même, c'est exactement ce que j'ai fait pour la ti83 ou la numworks, mais je ferai ça à ma sauce, certainement pas de façon propre :-)
Oh on pensait peut-être pas exactement à la même chose. La majorité des syscalls que tu appelles via le PrizmSDK tu peux aussi les appeler quand tu utilises gint. Genre si c'est pour dessiner dans la VRAM ça pose aucun problème. Sur la Math+ les syscalls ne peuvent plus être appelés par la méthode normale mais MPM documente les adresses d'un certain nombre et donc je pensais faire une extension de ça.
Si le but c'est de réimplémenter les syscalls intéressants par-dessus gint alors c'est pas pareil oui, hésite pas à essayer.
En termes d'informations, oui, les headers documentent toutes les fonctions disponibles avec le même niveau de discours que WikiPrizm: https://git.planet-casio.com/Lephenixnoir/gint/src/branch/master/include/gint (mais c'est moins joli évidemment)
Le tuto d'utilisation de gint a les bases pour compiler des programmes, dessiner, clavier, les trucs de base pour une entrée plus en douceur.
Un vrai truc style wiki est dans les cartons, mais pas encore prêt.
Si on multiplie les langages supportés (LuaFX, MLC, ...), il serait intéressant de créer un éditeur spécifique pour coder on calc. On pourrait réutiliser le code de PythonExtra pour gérer ces différents langages.
Yup c'est un peu la direction que ça prend !
Citer : Posté le 09/01/2025 12:50 | #
Sur la Math+ les syscalls ne peuvent plus être appelés par la méthode normale mais MPM documente les adresses d'un certain nombre et donc je pensais faire une extension de ça.
Du coup je ne suis pas sur de comprendre ce que signifie une compatibilité binaire des g3a existants sur la math+. Pour moi, compatibilité binaire veut dire que le code assembleur correspondant à un syscalls est appelé comme avant, donc avec un saut vers 0x80020070 (0x80010070 sur la 35). C'est le code à cet endroit que tu comptes modifier pour reconnaitre certains numéros de syscalls et appeler les adresses correspondantes sur la Math+? Mais du coup, ça risque de changer à chaque nouvelle version d'OS, une galère à maintenir.
Si le but c'est de réimplémenter les syscalls intéressants par-dessus gint alors c'est pas pareil oui, hésite pas à essayer.
Ca me parait beaucoup plus stable comme méthode, non? Pas besoin d'attendre une mise à jour du MPM si nouvelle version d'OS. Mais je vais attendre la sortie du MPM avant de commencer à travailler là-dessus. Tu as une idée de quand on aura une première version beta publique?
Citer : Posté le 09/01/2025 13:16 | #
Oui, c'est ça qu'une compatibilité binaire veut dire. Et oui, faudra se la trimballer à chaque version d'OS, chercher les syscalls à différents endroits, mettre à jour la table dans MPM. Là, y'a pas d'ambiguïté : CASIO nous a condamné à cette galère en virant la table des syscalls, pour les g3a dont on a pas les sources c'est la seule option. Note : je pense que ça va marcher mais c'est pas encore fait là tout de suite, donc petite astérisque.
Certainement. Je n'ai pas convergé vers cette option immédiatement parce que dans ma tête si tu commences à écrire du code gint autant porter le code original ; pas pour me jeter des fleurs mais les API gint pour le rendu et le texte (que j'imagine est la majorité des appels) sont sensiblement mieux que celles du SDK. Mais je sous-estime peut-être la quantité de code que tu as dans KhiCAS en fait...
Citer : Posté le 09/01/2025 13:37 | #
C'est surtout de la paresse, il me semble bien plus simple d'écrire une fonction de compatibilité par syscall sans toucher au code existant que de regarder à chaque appel. Il y a déjà un point positif me semble-t-il, c'est que les syscalls pour le filesystem on l'air d'etre dans bfile.h, juste avec un nom différent, correct? Après, j'espère que les caractéristiques géométriques des fontes de gint sont compatibles avec les fontes Casio, au moins l'intermédiaire, sinon il faudra que je reprenne certaines caractéristiques (par ex. nombre de lignes dans le shell...). Le plus long sera probablement la gestion du clavier et des menus rapides, existe-t-il une table de conversion entre les noms de touches Casio et les tiens ?
Citer : Posté le 09/01/2025 17:44 | #
De la paresse, ou... de la parisse ?
Eh, on nous a dit qu'on postait trop sur la shout et pas assez dans le forum, donc j'essaie de porter mes messages sur le forum, y compris mes blagues vaseuses !
Mon blog ⋅ Mes autres projets
Citer : Posté le 09/01/2025 18:01 | #
Ok Parisse je comprends où tu vas.
Oui, mais il faut world switch pour les appeler (* je peux rendre ça automatique dans le futur). Après avec gint t'as fopen(), fprintf() et toute la clique, si jamais... x)
Probablement pas les mêmes pile non il faudrait créer une police gint avec les glyphes de la police OS. À moins que ton code soit basé sur une primitive "taille du texte" sans hardcoder les résultats auquel cas ça ira tout seul.
Non mais on peut la faire en deux minutes vu que y'a genre 50 touches... ma liste à moi est ici : https://gitea.planet-casio.com/Lephenixnoir/gint/src/branch/master/include/gint/keycodes.h
Citer : Posté le 09/01/2025 20:49 | #
Non mais on peut la faire en deux minutes vu que y'a genre 50 touches... ma liste à moi est ici : https://gitea.planet-casio.com/Lephenixnoir/gint/src/branch/master/include/gint/keycodes.h
Il me faut une gestion avec shift/alpha en fait, donc ça fait plus que 50 touches.
En fait je me demande si le mieux ne sera pas de repartir du portage Numworks de l'UI, qui utilise fopen pour les fichiers. Cela présenterait un gros avantage pour la mise au point de l'UI (car en natif avec le simulateur Numworks) et la prise en compte du clavier de la math+ devrait être assez similaire à celui de la Numworks.
Citer : Posté le 09/01/2025 20:51 | #
Aah, getkey() ne renvoie pas de noms symboliques dans ce cas, si tu tapes Shift+4 il te renvoie un événement avec .key=KEY_4 et .shift=true. Il te faudra un wrapper mais du coup tu peux garder les noms de CASIO.