Forum TI-Planet.org

D'apres la table des symboles, le probleme de KhiCAS sur graph 35eii apparait lors de l'execution d'une fonction de manipulation de chaines de la USTL

Code: Tout sélectionner

004cad2c g     F .text._ZN4ustl6string6assignEPKcj   00000034 __ZN4ustl6string6assignEPKcj
004cad2c l    d  .text._ZN4ustl6string6assignEPKcj   00000000 .text._ZN4ustl6string6assignEPKcj
004cad60 g     F .text._ZN4ustl6string6assignEPKc   00000038 __ZN4ustl6string6assignEPKc
004cad60 l    d  .text._ZN4ustl6string6assignEPKc   00000000 .text._ZN4ustl6string6assignEPKc


Reste a savoir laquelle precisement, pour pouvoir localiser dans le script. Je n'ai aucun moyen efficace de debugguer...

Apres avoir fait quelques tests, je pense que c'est un probleme de manque de memoire sur la 35eii au moment de l'interpretation ou de l'evaluation (ce qui paraissait l'hypothese la plus plausible sachant que ca passe sur la 90). Le script est d'abord stocke comme vecteur de chaine (USTL string), ensuite il est traduit en langage Xcas, ce qui genere une chaine plus grande que la taille du script (et plusieurs chaines intermediaires sont conservees a cette etape), ensuite il est interprete, avec creation des objets giac, puis il y a evaluation. En enlevant des parties du script, aux environs de 1K, j'obtiens un script editable et dont on peut tester la syntaxe une fois, ensuite parfois ca marche (plusieurs test fonctionnent), parfois il y a une fausse erreur, parfois un reboot. Ca semble etre la limite. Pour aller plus loin, il faudrait utiliser un tas different de celui de l'OS de Casio. Sinon il faut essayer de diviser le script en plusieurs scripts.
On en revient toujours au meme probleme, il n'y a pas assez de memoire sur ces calculatrices pour faire des programmes un peu plus consequents que juste quelques lignes! Que de temps perdu pour gagner une fraction d'euro sur le hardware...

Encephalogramme a écrit:Et beh il a était vite pour participer, un jour même pas, bravo, et merci pour la correction du script :3
Par contre le nombre de points attendu a été augmenté je suppose, j'atteind des 25 pts en un pokémon ( j'avais fais un beau tableau avec toutes les valeurs en plus )

Ton tableau reste exploitable, les compétences des Pokémons n'ont pas été modifiées.
Pour une main avec 1 seul Pokémon, l'ordre des scores est conservé.

parisse a écrit:D'apres la table des symboles, le probleme de KhiCAS sur graph 35eii apparait lors de l'execution d'une fonction de manipulation de chaines de la USTL

Code: Tout sélectionner

004cad2c g     F .text._ZN4ustl6string6assignEPKcj   00000034 __ZN4ustl6string6assignEPKcj
004cad2c l    d  .text._ZN4ustl6string6assignEPKcj   00000000 .text._ZN4ustl6string6assignEPKcj
004cad60 g     F .text._ZN4ustl6string6assignEPKc   00000038 __ZN4ustl6string6assignEPKc
004cad60 l    d  .text._ZN4ustl6string6assignEPKc   00000000 .text._ZN4ustl6string6assignEPKc


Reste a savoir laquelle precisement, pour pouvoir localiser dans le script. Je n'ai aucun moyen efficace de debugguer...

parisse a écrit:Apres avoir fait quelques tests, je pense que c'est un probleme de manque de memoire sur la 35eii au moment de l'interpretation ou de l'evaluation (ce qui paraissait l'hypothese la plus plausible sachant que ca passe sur la 90). Le script est d'abord stocke comme vecteur de chaine (USTL string), ensuite il est traduit en langage Xcas, ce qui genere une chaine plus grande que la taille du script (et plusieurs chaines intermediaires sont conservees a cette etape), ensuite il est interprete, avec creation des objets giac, puis il y a evaluation. En enlevant des parties du script, aux environs de 1K, j'obtiens un script editable et dont on peut tester la syntaxe une fois, ensuite parfois ca marche (plusieurs test fonctionnent), parfois il y a une fausse erreur, parfois un reboot. Ca semble etre la limite. Pour aller plus loin, il faudrait utiliser un tas different de celui de l'OS de Casio. Sinon il faut essayer de diviser le script en plusieurs scripts.

Merci pour le travail fourni de façon aussi réactive.

parisse a écrit:On en revient toujours au meme probleme, il n'y a pas assez de memoire sur ces calculatrices pour faire des programmes un peu plus consequents que juste quelques lignes! Que de temps perdu pour gagner une fraction d'euro sur le hardware...

Il n'y a que la NumWorks qui est limite avec ses 16K de mémoire de travail, et nécessite en ce moment que l'on fasse attention au moindre octet pour toute mise à jour du script.

Les autres configs ne posent strictement aucun problème, malgré un script qui est quand même conséquent (près de 4K de source), notamment :

• l'appli CasioPython sur Graph 35+E II qui prend la machine pour un vieux modèle SH3 et ne s'alloue que 32K de mémoire de travail, problème signalé depuis des mois, correction a priori mineure, simple détection de modèle quitte au pire à fournir deux versions, mais hélas aucune mise à jour depuis des mois malgré le caractère hautement stratégique de cette appli de haute qualité
• TI-83 Premium CE Edition Python ou TI-83 Premium CE avec module externe TI-Python, et leur ~20K de mémoire de travail

Que les constructeurs ne soient pas généreux en mémoire allouée est une chose, mais sauf sur NumWorks la capacité est suffisamment confortable pour permettre de grandes choses en Python sans prise de tête.

J'ignorais que KhiCAS était encore plus gourmand en mémoire qu'un interpréteur Python standard (ce qui n'est déjà pas rien).
Pour référence, l'appli s'alloue combien sur Graph 90+E et Graph 35+E II ?

Je ne sais pas exactement quelle est la taille du tas sur les Casio, j'ai limite empiriquement les matrices a 14x14 sur la 35eii. Il y a des zones memoires autres qui seraient utilisables, mais necessitent un malloc/free ad hoc, je crois que CasioPython utilise de la memoire de ce type.
Je suis en train de nettoyer le code du lexer/parser pour economiser de la memoire. On verra si ca suffit pour passer le script (allege de la recherche de plateforme hardware) ou pas. De toutes facons ca devrait ameliorer l'utilisation, meme si quand on tape sur la calculatrice un programme, ca ne doit pas etre frequent de depasser les 1000 caracteres...

Alors, sur la graph 90, le parser passe une fois, mais pas deux. On est donc en limite avec 3.7K de script. Si on enleve la detection hardware, il passe 2 fois, mais pas 3. Il passe a nouveau si on fait restart. A voir si je peux economiser encore un peu, mais ca va devenir difficile...
Tout ca est tres interessant, ca va me permettre de mettre des garde-fous.
En consequence, je ne pense pas qu'il y aura assez de ram pour parser sur la graph 35eii, a voir si ca passe en decoupant le script.

Le tas fait environ 90k sur la Graph 35+E II et environ 128k sur la Graph 90+E.

(Certains OS de Graph 90+E présentés lors de la tournée pédagogique avaient 3M rapportés dans le gestionnaire mémoire, mais cela n'a été vérifié dans aucune mise à jour publique de l'OS.)

Lephe a écrit:Le tas fait environ 90k sur la Graph 35+E II et environ 128k sur la Graph 90+E.

C'est sur ces estimations de tas?
Voila mes estimations d'occupation memoire: texte source dans l'editeur (eclate sur 100 lignes environ, 100 string) 5K, console 3K, texte source reassemble 4K, variables (si on revalide alors que c'est deja parse) une dizaine de K. En temporaire pendant le parse, on a duplication des variables, eventuellement triplement pendant l'evaluation, j'arrive aux environs de 50K, mais je ne vois pas comment approcher des 128K...

J'ai mis a jour khicas.g3a/g1a avec quelques optimisations. J'arrive maintenant a interpreter le programme sur la 35eii en enlevant la detection hardware et en le coupant en 4 morceaux. Je vais encore un peu fouiller mais il y a peu d'espoir de faire mieux.
Je ne sais pas combien il y a de place sur le tas, en tout cas pour giac il n'en reste qu'environ 30K d'utilisable sur la 35eii me semble-t-il...

Merci, c'est déjà une belle avancée.