Posté le 15/07/2018 12:09
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 65 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 01/06/2019 15:56 | #
Mise a jour de la doc et de l'addin avec la nouvelle interface:
https://www-fourier.ujf-grenoble.fr/~parisse/casio/khicasio.html
https://www-fourier.ujf-grenoble.fr/~parisse/casio/khicas.g3a
La principale nouvelle fonctionnalite, c'est de pouvoir modifier un niveau de l'historique des calculs, les niveaux en-dessous sont alors reevalues.
On peut d'ailleurs creer des curseurs pour faire varier des parametres de maniere plus efficace (assistant de creation dans le menu F6 Parameter), les calculs et les graphes qui suivent sont alors reactualises si on selectionne le niveau contenant la commande assume(...) en tapant sur la touche + ou -. L'exemple de session https://www-fourier.ujf-grenoble.fr/~parisse/casio/sessions/quad.xw illustre ce principe, c'est une version KhiCAS de l'applet quadratic explorer des HP.
Bonjour,
Il y a ne restriction pour ce qui concerne l'ouverture des ficher? Il faut obligatoirement que les sessions .xw soit a la racine de la calculatrice?
j'avais toutes mes sessions dans un dossier nommé "xw", et l'appli les ouvrait sans probleme. Avec la dernière version (téléchargé hier), l'appli "restart" complètement sans charger la session quand j'essaye de charger une sessions qui est dans un sous-dossier. Aucun problème si je charge la session depuis la racine de la calculatrice.
Citer : Posté le 01/06/2019 21:28 | #
Oui, tous les fichiers xw (et py) doivent etre a la racine. Ca me simplifie la gestion des chemins. Je pourrais sans doute reautoriser les chemins, mais c'est chaud il ne me reste que quelques centaines d'octets libres.
Citer : Posté le 01/06/2019 22:23 | #
Oh ok. Comme ça fonctionnait avec une version antérieure et avec l'ancienne version chargeait les fichiers .py de sous dossiers, je ne savais pas si c’était un bug ou volontaire pour sauver de la mémoire/taille de l'application.
Ajouté le 05/06/2019 à 16:35 :
Encore moi, désolé
A moins d'avoir raté une option Il y a un bug dans Xcas, et aussi dans la fonction d'export de xcas sur PC vers le format xw.
Quand j'utilise la commande "sort" sauvegarde et recharge ma session dans Xcas, Xcas a change la commande pour "trier". J'ai ouvert le fichier session ".xws" et le logiciel a bien sauver "sort" et non "trier". (voir prise d’écran). La fonction "sort" n'est pas traduite si j'utilise l'interface en Anglais.
Aussi quand j'exporte au format session Khicas ".xw", le logiciel soit exporte exactement le code que j'ai dans l'interface de programmation de Xcas, soit il réécrit/transforme mon code, et traduit mon "sort" part un "trier" qui n'existe pas dans Khicas, le Xcas sur Casio Graph 90. (voir autre prise d’écran). Le problème est présent que j'exporte avec l'interface en Français ou Anglais.
SI c'est une option, je ne l'ai pas trouve. S'il n'y a pas d'option, c'est possible d'ajouter une option qui empêche complètement le logiciel de traduire et/ou réécrire les fonctions d'une session/de mon programme selon l'interface que j'utilise?
Merci d'avance
Citer : Posté le 05/06/2019 20:58 | #
Effectivement, il faut que l'export se fasse avec les mots clefs en anglais, je vais regarder ca.
Citer : Posté le 05/06/2019 22:50 | #
Merci et petite rectification, j'ai du me mélanger quand j'ai regarde les fichiers exporte plus tôt, la version en Anglais exporte bien toutes les fonctions en Anglais.
Le problème n'est pressent qu'avec l'interface en Français qui s'amuse a traduire/réécrire en Français dans l'interface de programmation, sans que je lui demande, des fonctions/commandes écrites en Anglais quand je charge un session sauvegarde.
Ajouté le 06/06/2019 à 13:35 :
Bonjour, je viens de télécharger la nouvelle version, il y a un autre truc que je n'avais pas vu hier. Si je lance l'interface en Anglais et change la langue de l'aide pour le français, ouvre une session de programme sauvegarde, ça change la langue de l'aide mais aussi traduit certaines fonctions comme "sort" ou "print" comme quand je lance xcasfr.bat et charge une session programme depuis cette interface. Si je change l'aide en Francais, c'est pour avoir l'aide en FR, pas pour traduire mes fonctions
Merci encore
Citer : Posté le 06/06/2019 18:01 | #
On peut empecher la traduction de certaines commandes en editant le fichier doc/fr/keywords
L'export depuis Xcas vers Khicas (en xw) effectue maintenant la traduction vers les noms de commande natifs (1ers noms dans les couples de noms de doc/fr/keywords).
L'idee generale est de sauvegarder au format nom de commande natif pour permettre des echanges dans des langues differentes, mais d'afficher des traductions s'il y en a. Pour l'enseignement au lycee, je pense qu'il vaut par exemple mieux utiliser la commande traduite losange que la commande native rhombus (qui ne marche pas sur la Casio par manque de place, il faudrait que je rajoute une liste de fonctions utilisateur pour remplacer). Meme pour des mots clefs frequents (y compris while/for/if...), je pense qu'on sous-estime la difficulte supplementaire que constitue pour certains eleves l'utilisation de mots clefs en anglais (ce serait du reste interessant d'etudier dans quelques annees l'effet du passage d'Algobox a Python sur des eleves faibles a moyens...)
Citer : Posté le 07/06/2019 13:14 | #
Je comprends l’idée derrière la logique de traduction, même si quand j'utilise une IDE le dernier truc que je lui demande c'est de modifier le code que je charge sans mon accord. A ce moment la, faudrait que l'IDE traduise tout le code, les if en si, solve en résoudre, etc. Ca ferait plus de sens que de traduire centaines commandes et pas d'autres. Ou d’offrir une option qui charge un code quelconque en langage natif (Anglais), et traduit, pas a pas pour démystifier les commandes écrite en Anglais, ou tout d'un coup, en Français.
Après c'est clair que le passage d'un logiciel comme d’algobox ou, d’après ce que j'ai vu, tous le code s’écrit en Français a un langage comme Python (ou n'importe quel autre langage de code) ou le code s’écrit en Anglais, risque de démotiver certains/beaucoup élèves qui n'aime pas l'Anglais.
Merci encore
Citer : Posté le 07/06/2019 15:02 | #
Je ne pretends pas que tout soit coherent, c'est la consequence d'un processus evolutif (un peu comme l'orthographe ou la grammaire d'une langue). Dans Xcas, il y a des traductions via le fichier keywords, et des vraies commandes ou mots-clefs en francais qui sont synonymes de vraies commandes ou mots-clefs en anglais, par exemple si/alors/sinon/fsi ou resoudre sont des vrais mots-clefs/commandes, pas juste des traductions. Ces vraies commandes ne sont donc pas traduites, elles sont reconnues quelle que soit la langue choisie. Les traductions du fichier keywords ne sont reconnues que dans la langue correspondante, elles doivent donc etre traduites et stockees en natif pour qu'un texte source puisse etre utilise dans une autre langue, reciproquement au chargement la traduction inverse est appliquee.
Historiquement, le mecanisme de traduction a ete introduit apres la creation de pas mal de synonymes en francais, quand je me suis dit qu'il fallait un mecanisme simple de traduction qui ne necessite pas de creer de nombreuses commandes synonymes, et je n'avais aucune envie de modifier ce qui marchait deja (surtout s'il s'agit de supporter des mots-clefs pour les structures de controle en francais).
Sur la casio, il y a peu de commandes traduites en francais, et cela se fait directement au niveau du lexer, et est donc reconnu aussi en anglais. Ainsi la commande droite et la commande line sont synonymes et marchent dans la version francaise et anglaise de KhiCAS. On peut du reste tester en tapant droite EXE, on voit en reponse 'line'.
Avec l'evolution des programmes d'algorithmique au lycee, peut-etre qu'il faudrait enlever certaines traductions du fichier keywords, par exemple sort trier, et mettre certaines vraies commandes synonymes comme solve/resoudre en traduction dans le fichier keywords. Par contre, je ne toucherai pas aux structures algorithmiques en francais, le risque est bien trop grand de creer des bugs.
Ajouté le 07/08/2019 à 21:15 :
Petite mise a jour (pour graph 90 et 35eii). Le changement introduit est le suivant:
L'appui sur fleche droite depuis un niveau en surbrillance de l'historique des calculs affiche ce niveau dans l'editeur d'expressions, fleche gauche l'affiche dans l'editeur texte. Cela evite de devoir taper sur F3. Si on fait une modification dans l'editeur, puis si on valide par EXE, le niveau est modifie, et s'il s'agit d'un niveau d'entree, l'historique est re-evalue a partir du niveau modifie. Si on quitte l'editeur avec EXIT, l'historique n'est pas modifie.
Citer : Posté le 07/08/2019 22:32 | #
Je sais que je commente rarement car j'utilise plutôt le calcul formel sur PC... mais merci pour la maintenance continue de l'application. Grâce à toi on a une appli de premier choix pour ces deux plateformes.
Citer : Posté le 08/08/2019 09:32 | #
Merci!
Je viens de faire 2 changements: echanger le role de fleche droite et gauche, pour pouvoir lire les messages d'erreurs ou avertissements de maniere intuitive, et la gestion de INS quand on est dans l'historique des calculs (ajout d'un niveau vide, enfin plutot contenant 0).
Il y a encore (au moins) un bug dans la gestion de l'historique des calculs que se produit rarement et qui peut provoquer des resets, malheureusement je n'arrive pas a reproduire de maniere systematique pour le debugguer. Pensez a sauvegarder la session de temps en temps!
Citer : Posté le 08/08/2019 16:01 | #
Pour me donner une idée, à quel point as-tu dû réduire KhiCAS pour tenir dans les 2 Mo ? En termes de quantité de code, par exemple.
Bon courage aussi pour attaquer la prochaine Numworks. Ce sera certainement mieux documenté que la Casio...
Citer : Posté le 08/08/2019 23:04 | #
Je dirais environ 1/4 de fonctions de giac en moins (dont toute la geometrie 3d et presque toute la geometrie 2d), pas de librairies tierces (sauf libtommath pour les entiers multiprecision), et bien sur tout le code tres optimise polynomial/matrice en moins (mais ca reste quand meme bien optimise pour les tailles d'objets qu'on peut manipuler sur une calculatrice, juste qu'il n'y a pas le code pour travailler avec des polynomes ayant des centaines de milliers de monomes ou des matrices ayant plusieurs centaines de lignes/colonnes).
Pour la Numworks, j'attends d'avoir confirmation qu'on peut bien flasher sur la n110 un firmware tiers. Ca devrait en effet etre plus facile, deja parce qu'il y a la possibilite d'utiliser gdb pour mettre au point, et puis il n'y aura pas besoin de gratter des octets ce qui a ete source de bugs sur la Casio. On a environ 3 fois plus de flash disponible...
Citer : Posté le 09/08/2019 07:38 | #
Je vois, ça reste largement complet pour les lycéens et probablement une partie des prépateux.
Non qu'il n'y ait pas la Flash sur la Graph 90+E mais les limites de virtualisation sont plus serrées... c'est dommage qu'il n'y ait pas de contournement stable pour l'instant. Je suis sûr que ça peut se faire avec un peu de recherche.
Il y a combien de RAM dispo sur la N110 au fait ? (J'ai voulu retourner sur TI-Planet mais ma connexion mobile commence à me lâcher, j'espère que ce message va partir. >_>)
Citer : Posté le 09/08/2019 15:25 | #
Pas plus qu'avant, 256K, c'est dommage!
Ce serait effectivement tres interessant de pouvoir depasser la limite des 2M pour un addin sur la Casio!
Citer : Posté le 09/08/2019 18:21 | #
Ouf c'est serré. Bon courage !
Ce serait effectivement tres interessant de pouvoir depasser la limite des 2M pour un addin sur la Casio!
On peut adresser directement dans la ROM pour utiliser des fichiers. Il faudrait parcourir un peu le système de fichiers ou ruser, et la continuité n'est que par blocs (de combien, je ne sais pas), mais ultimement tu peux mettre des données en-dehors du fichier d'add-in. Du code, aussi, d'ailleurs.
Après faut voir si le design s'y prête, la contrainte de discontinuité est conséquente.
Citer : Posté le 09/08/2019 21:12 | #
En fait, 256K (- ce qui est utilise par l'OS) sur la Numworks, il me semble que c'est environ 2 fois plus que ce que malloc me donne sur la Casio, donc il ne devrait pas y avoir de problemes.
Pour la Casio, c'est plutot a eux de remonter la taille maximale d'un addin, je ne vais pas me lancer dans du code complique avec des outils de developpement quand meme assez rudimentaires. Sur la graph 90, je ne vois pas trop pourquoi empecher de monter a 4Mo, voire meme 8.
Citer : Posté le 09/08/2019 21:31 | #
Oui sur la Graph 90+E le tas est petit, mais il y a 512k de zone "statique" entièrement libre (plus au moins 350k dans la pile du système, je m'en sers perso pour mettre les VRAMs).
Pour la Casio, c'est plutot a eux de remonter la taille maximale d'un addin, je ne vais pas me lancer dans du code complique avec des outils de developpement quand meme assez rudimentaires.
Non c'est pas ton rôle, moi c'est quelque chose qui m'intéresse plus parce que je peux le faire dans une lib' et ensuite tout le monde en profite.
Sur la 35+E II c'est 90k, c'est assez limitant aussi.
Enfin voilà, pas de quoi refaire le monde, mais good luck avec ce nouveau portage.
Citer : Posté le 10/08/2019 09:22 | #
J'avais pendant un temps essaye d'utiliser cette extension de memoire, mais ca buggait, probablement parce que je n'avais pas un remplacement fiable de malloc/free. Et puis, finalement ce que malloc/free fournit suffit pour la quasi-totalite des calculs en licence, donc a fortiori au lycee, donc j'ai decide que ce n'etait pas la peine de m'embeter. En fait, ca devrait etre du travail pour Casio de proposer plus d'espace alloue par malloc/free. Mais ca doit etre une habitude des gens qui developpent en embarque depuis longtemps, ils utilisent tres peu ou pas du tout de memoire allouee dynamiquement, ils reservent plutot des zones pour des variables de taille fixee. Pour la plupart de ce qu'on fait sur une calc graphique non formelle et avec leur langage de programmation historique pour debutant (notamment sans fonction), c'est bien sur suffisant. Du coup, il n'y a jamais vraiment eu de demande pour avoir plus de RAM, et surtout plus de RAM allouable dynamiquement.
Et malheureusement, on observe le meme probleme de manque de RAM chez Numworks. Peut-etre que les remontees de la faiblesse de memoire disponible pour programmer en Python sont arrivees trop tard pour la N0110. Plus probablement, ca prenait juste trop sur la marge d'augmenter la RAM sachant que le prix final doit rester a 80 euros. Il est fort probable qu'en fait tres peu de profs programment reellement en Python sur calculatrice, ou alors seulement des trucs tres basiques.
La realite du marche fait que les constructeurs ne vont pas fournir un outil permettant d'aller vraiment plus loin pour les bons eleves car il n'y en a pas assez, du coup c'est le niveau moyen des eleves qui tire les specs du marche vers le bas. Le seul moyen d'ameliorer les specs c'est alors de faire jouer la concurrence entre les constructeurs, et je pense que KhiCAS sur Casio a un peu participe a l'amelioration de la N110, la raison principale etant quand meme le fait que leur firmware s'approchait de memory full. Maintenant il faudrait faire jouer la concurrence dans l'autre sens, mais je ne sais pas trop si ca a des chances de marcher. Cest peut-etre du cote de Symbolibre qu'il faut esperer un succes pour faire bouger les lignes. Ou bien c'est Google ou Apple qui vont se lancer dans un smartphone pour teenager avec fonctionnalite calculatrice et mode examen.
Citer : Posté le 13/08/2019 15:54 | #
Oui en effet. Pour la Graph 90+E, je n'ai pas peur faire moi-même un framework pour gérer ça, mais c'est pas la "bonne" façon de faire. Y'a des hacks partout dans nos environnements de développement.
Je comprends un peu mieux ton point de vue... je devrais mettre de l'eau dans mon vin pour Symbolibre. Au moins on a le matériel que d'autres n'ont pas, on devrait en profiter. Quel genre d'interface graphique utilises-tu pour KhiCAS ? J'avais vu du FLTK pour Xcas, mais clairement il n'y a pas ça sur les Graph.
Citer : Posté le 13/08/2019 16:52 | #
Pour KhiCAS sur la Casio, je n'utilise aucun environnement, tout est code dans les fichiers sources (a partir des syscalls d'affichage de pixels ou de texte). Un gros travail avait ete fait pour l'UI d'Eigenmaths, j'ai ajoute l'affichage des graphiques, l'editeur d'expression, j'ai pas mal ameliore l'afficheur de texte pour en faire un edtiteur de programmes et j'ai adapte le reste.
Je ne sais pas encore ce que je vais faire sur la Numworks. Se glisser dans l'appli de calculs va vite atteindre ses limites, car il faut interagir avec leur systeme qui est beaucoup trop restrictif (par exemple toutes leurs fonctions utilisateur sont unaires. Reecrire tout un environement comme sur la Casio est un travail important, et qui ne donnera pas de resultats tangibles avant un long moment. Sauf peut-etre en faisant le coucou dans le shell Python...
Citer : Posté le 02/09/2019 16:12 | #
Pour KhiCAS sur la Casio, je n'utilise aucun environnement, tout est code dans les fichiers sources (a partir des syscalls d'affichage de pixels ou de texte). Un gros travail avait ete fait pour l'UI d'Eigenmaths, j'ai ajoute l'affichage des graphiques, l'editeur d'expression, j'ai pas mal ameliore l'afficheur de texte pour en faire un edtiteur de programmes et j'ai adapte le reste.
D'accord, donc ça ce serait facile à porter sur la Symbolibre pouvu que tu aies la SDL ou équivalent si je suis bien.
Tu ne peux pas porter l'environnement existant que tu as utilisé sur la Graph 90+E (et pas que) ? :o