Forum TI-Planet.org

Bonjour,

Cet été avec deux élèves volontaires et motivé de 1ère S nous avons conçu un script pour la NumWorks, une boîte à outil pour les polynômes du second degré en y intégrant un menu et en essayant de rendre le tout User-Friendly.

Très vite nous avons été confronté à des problèmes de gestion de la mémoire de la Numworks, et après quelques échanges intéressants avec les développeurs de NumWorks nous avons tenté de réduire encore et encore la taille du script.

S'ils ont répondu à nos messages, avec précision et rapidité, la limitation 16/16 ko stockage/exécution nous parait ridiculement faible, risible, agaçante même !

Bref, d'un script incomplet de 12ko nous avons réussi à aboutir à un script de 6ko parfaitement fonctionnel mais ... uniquement sur Thonny, Spyder, etc ... Et comme il ne tourne pas sur la numworks on ne peut pas faire les derniers réglages.

Lassé de cette situation, et ne voulant pas attendre une hypothétique mise à jour qui augmenterait l'espace pour exécuter les scripts, j'ai tenté de recompiler la ROM et là cela fut pire.

La documentation officielle de numworks est très incomplète, elle est belle, courte, ça parait hyper facile mais elle ne permet pas de compiler une ROM.
Le wiki non officiel est plus complet, mais dans le meilleur des cas, à la fin de la compilation j'ai un message qui me dit que le .bin est trop gros pour la calculatrice (d'ailleurs j'ai un .elf mais le .bin je ne l'ai jamais vu dans aucun sous dossier.)

J'ai parcouru reddit, github, et ce forum et j'ai l'impression que tous ceux qui réussissent à compiler la ROM de la calculatrice sont ici.

Tests effectués pour le script en Python

Définir un maximum de f°
Définir un minimum de f°
Stocker les f° dans deux scripts différents
Effacer tous les autres scripts
Limiter les manipulations des chaines de caractère
Définir le moins de variable possible
Regrouper des f°
I=input P=print etc ...
Couper des morceaux du script pour identifier d'ou viendrait le pb

Tests effectués pour la compilation

Windows 10 : 2x
Ubuntu sur VM : 2x
Debian sur VM : 2x
Ubuntu sur machine dédié fraîchement installée : 1x
Debian 10 sur machine dédié fraîchement installée : 1x > Meilleur résultat observé, ça compile sans erreur, on déplace le .elf au bon endroit mais ça refuse de flasher.

Quelques liens

Le script en question sur github. 9 ko pas optimisé.
Le script sur workshop 6ko minimal
La première version non fonctionnelle qui c'est mise à planter nous obligeant à procéder à des coupes massives et à chercher ou était passé la mémoire.

Et en remontant l'historique de github, on peut trouver les versions précédentes, mais je ne vous apprend rien là.

Je ne vois qu'une solution à mon problème, partir sur une Lexibook GC3000FR et laisser la numworks dans un placard ...

Bonjour.

C'est tout un défi que de faire fonctionner des scripts Python un minimum conséquents (entre autres avec des interfaces/menus utilisateur) sur la NumWorks.
Sachant qu'à l'exécution, tout va dans la mémoire de travail d'environ 16Kio :

• l'intégralité du texte du script
• de plus toutes les fonctions qu'il définit sont également créées en mémoire de travail, chacune associée avec son nom et son code

Il faut réduire le nombre de lignes, utiliser des noms de fonctions/variables courts, éviter les commentaires, factoriser le code... et encore ça ne suffit pas toujours.

On est un petit peu moins à l'étroit chez Texas Instruments (environ 20Kio de mémoire de travail Python sur TI-83 Premium CE).
Chez Casio par contre aucun problème de ce genre : environ 100Kio de mémoire de travail sur Graph 35+EII, et 1Mio sur Graph 90+E.

Sinon en effet le script ne plantera pas sur Lexibook GC3000FR.

C'est quand même inquiétant de ne pas pouvoir construire des programmes non triviaux sur beaucoup de modèles de calculatrices gérant Python...
Ce n'est pas comme ça qu'on va rendre populaire l'algorithmique et donner le goût de la programmation à certains élèves qui auraient pu être intéressés.
Certes, les ordinateurs permettent de faire beaucoup plus de choses, mais pas tout le monde n'a encore accès à un ordinateur chez soi !

critor a écrit:Il faut réduire le nombre de lignes, utiliser des noms de fonctions/variables courts, éviter les commentaires, factoriser le code... et encore ça ne suffit pas toujours.

On a déjà épuisé le stock de possibilité ... Raccourcir tous les noms fut la première chose qu'on a fait, c'était tellement trivial que je ne l'ai pas précisé.

Quand on vu les premiers plantages on a testé la quantité de mémoire utilisée, et à force d'optimiser on est arrivé à moins de 8ko mais ça c'était sans compter la fragmentation de celle-ci et sa non optimisation...

Bon l'année prochaine je fais mettre la Lexibook GC3000FR sur la liste des fournitures scolaire, au moins on n'aura pas de problème de mémoire.

Bon l'année prochaine je fais mettre la Lexibook GC3000FR sur la liste des fournitures scolaire

Tu es sérieux ?

Lionel Debroux a écrit:C'est quand même inquiétant de ne pas pouvoir construire des programmes non triviaux sur beaucoup de modèles de calculatrices gérant Python...
Ce n'est pas comme ça qu'on va rendre populaire l'algorithmique et donner le goût de la programmation à certains élèves qui auraient pu être intéressés.
Certes, les ordinateurs permettent de faire beaucoup plus de choses, mais pas tout le monde n'a encore accès à un ordinateur chez soi !

Je plussois à 100%.

Autant en maths en seconde la limitation 16ko/16ko ne serait jamais atteinte, autant en NSI ça sera un vrai problème...

Pour s'implanter sur le marché il faut séduire :

- Les enseignants pour qu'ils recommandent la calculatrice,
- Les élèves en situation de réussite différée en leur proposant un outil simple,
- Les élèves en situation de réussite accéléré en CAR ils sont souvent des prescripteurs auprès de leurs camarades.

et cette troisième catégorie ne sera pas accessible avec 16ko / 16 ko !

Lionel Debroux a écrit:

Bon l'année prochaine je fais mettre la Lexibook GC3000FR sur la liste des fournitures scolaire

Tu es sérieux ?

Toujours !

Pour avoir un problème de mémoire, il faut avoir de la mémoire.
Pas de mémoire, pas de problème.

En m'arrachant pas mal de cheveux (il ne m'en reste déjà plus beaucoup), j'arrive à faire tourner des scripts une fois réduits à un peu moins de 4Kio.

8Kio serait un tout autre record...

Ah depuis le temps que je hurle que 16Ko c'est ridicule !
et encore au début on était à 4Ko et on était limité à 8 scripts (de mémoire)
Je ne comprends pas cette limitation ridicule ! Numworks a fait un choix audacieux en mettant une superbe calculatrice sur le marché avec python intégré. Malheureusement si on ne peut quasiment rien faire avec elle va finir aux oubliettes. D'ailleurs la mienne je l'ai quasiment remisée au fond d'une meuble en attendant un tableur et plus de mémoire pour Python.
provisoirement je me sers d'autres modèles ...

Alors Numwoks, si vous voulez rester en vie sur ce marché des calculatrices, Bougez-vous !

ptitjoz a écrit:Ah depuis le temps que je hurle que 16Ko c'est ridicule !
et encore au début on était à 4Ko et on était limité à 8 scripts (de mémoire)
Je ne comprends pas cette limitation ridicule !

Pour avoir lu a peu prés tout ce que j'ai trouvé la dessus, il me semble qu'un membre de ce forum a expliqué que c'était une mesure conservatrice pour éviter les crash causé par une saturation de la mémoire disponible, ce qui obligerait à un RESET de la calculatrice. (en tout cas c'est ce que j'ai compris !)

Bon une fois ceci dit, le problème reste le même.

Ce script devait servir de modèle à mes futurs élèves de NSI, pour fixer le niveau d'exigence attendu.
Mais s'il ne tourne pas sur la calculatrice, je vais avoir l'air fin !

D'ailleurs il ne tourne pas non plus sur la TI 83 CE avec l'adaptateur, on a testé ça il y a quelques jours.