Script qui refuse de s’exécuter sur la Numworks N0100

[cent20]

et critor l'a testé tôt ce matin: il a pu flasher la calculatrice avec succès
(...)
peut-être que ce changement ça permettra de tourner des scripts un peu moins pas complexes sans avoir à rendre le code source moche ?

J'imagine que si cela avait marché il serait venu nous le dire !
Je suis en train de le faire avec cette page : https://tiplanet.org/forum/viewtopic.php?f=97&t=20746

Dump flash from device

Reading up to 0x100000 bytes starting at 0x8000000
Copying data from DFU device to browser 100%
Read 1048576 bytes

J'ai récupéré un firmware.bin de 1024ko

Flash firmware onto device

Erasing DFU device memory 100%
Copying data from browser to DFU device 100%
Wrote 745829 bytes
Manifesting new firmware
Done!

[cent20]

Je viens de tester à nouveau mon script polynome_ne_marche_pas_6ko_seulement.py et je n'ai pas un message d'erreur lié à la mémoire de la calculatrice, mais un message

Last command
RuntimeError :

On progresse donc.

Et le script pour tester la mémoire me rassure test_memory_size.py car le premier bloc de mémoire fait 8385 octets (si j'ai bien compris ce que fait ce script) ce qui répond en partie à ma précédente interrogation.

1258
+8385
+4316
+4283
+3260
+2235
+1850
+1211
+(...)
31069

[Lionel Debroux]

@parisse: le pool est fait pour stocker les TreeNode utilisés un peu partout comme opérande et résultat d'opération d'epsilon.

Ok, quelle consequence si on le divise par 2? Parce que ca permettrait de recuperer un peu de place pour le tas, ca ne serait pas du luxe pour KhiCAS.

La conséquence me semble être une réduction de la taille maximale de l'historique des calculs pour une complexité donnée, ou de la complexité maximale pour une taille donnée.
Changer la valeur de BufferSize dans Poincare::TreePool (poincare/include/poincare/tree_pool.h) baisse rapidement la taille de Poincare::Init()::pool, par exemple 32768 -> 24576 change la taille de 0xD558 à 0xA008 octets.

[cent20]

D'ailleurs en créant des scripts bidons effacés depuis, en dépassant 5 ko environ ils plantaient dès le lancement. Si la taille maximale d'un script est de 4ko cela doit être marqué en clair dans la documentation !

J'ai retrouvé mes scripts bidons ...

test_memory_available.py

Code: Select all

a="a"
i=1
while i>=0:
  a=a+"a"
  i=i+1
  print(i)


N0100 stock : plante lorsque i=4080 sur la calculatrice
N0100 emulateur : plante lorsque i=5007
N0100 (.bin avec k_pythonHeapSize = 32768) : plante lorsque i=11199 sur la calculatrice

mem_test_list_rand.py

Code: Select all

from random import *
n=int(0)
a=["debut"]
while n < 5000:
  a.append(random())
  n=n+1
  print(a)
  print(n)


N0100 stock : plante lorsque n=713 sur la calculatrice. 713*19=12ko
N0100 emulateur : plante lorsque n=713
N0100 (.bin avec k_pythonHeapSize = 32768) : plante lorsque n=1023 sur la calculatrice. 1023*19=19ko

[critor]

et critor l'a testé tôt ce matin: il a pu flasher la calculatrice avec succès
(...)
peut-être que ce changement ça permettra de tourner des scripts un peu moins pas complexes sans avoir à rendre le code source moche ?

J'imagine que si cela avait marché il serait venu nous le dire ! [/url]

Je n'ai pas testé le script des polynômes (compressé ou non) avec le firmware de Lionel.

J'ai juste testé mon script d'estimation de la mémoire de travail : https://workshop.numworks.com/python/andreanx/mem
Il m'a bien retourné 32204 au lieu de l'habituelle autour de 16000.

[Lionel Debroux]

Puisque l'utilisation d'un tas Python de 32 KB change le comportement... allons un peu plus loin ?
En pièce jointe, un build avec un tas de 40 KB et un nombre maximum de noeuds réduit (3/4 de la valeur d'origine mentionnée plus haut, et sizeof(TreeNode) == 12, donc ça laisse 2048 noeuds). Comme le deuxième changement réduit davantage la RAM consommée que le premier ne l'augmente, le tas pour malloc (section .heap) est plus grand, 0xEB64 octets maintenant.
Je me demande si on ne pourrait pas réduire la taille de la pile (section .stack), aussi... sauf utilisation de grosses variables locales, 32 KB (0x7FF8) est élevé alors que le tas ne fait même pas le double de ça.

sizeof(TreeNode) == 12 parce qu'il y a deux int16_t et un int8_t, et un pointeur vers la vtable, donc du padding. De toute façon, la taille doit être multiple de 4 pour faciliter les copies mémoire, c'est également marqué en commentaire.

[critor]

Merci.

J'ai à nouveau testé le script d'estimation de la mémoire de travail; il renvoie 40279.

[critor]

Je viens de tester à nouveau mon script polynome_ne_marche_pas_6ko_seulement.py et je n'ai pas un message d'erreur lié à la mémoire de la calculatrice, mais un message

Last command
RuntimeError :

C'est juste le import polynome_ne_marche_pas_6ko_seulement qui échoue.
Une fois le script de 6K renommé de façon plus raisonnable, il marche sur le dernier firmware (40K) de Lionel.
Pas retesté sur les autres firmwares.

[cent20]

La version pas du tout minifié de ce script ( 8.5 ko ), écrite sans aucune astuce du type I=input tourne parfaitement sur la version 40k mais pas sur la version 32k... : polynome_degre2.py

Avec le temps qu'on y a passé dessus (on ne développe pas tous aussi vite que critor), c'est non sans une certaine émotion que je la teste directement sur la numworks...

Les deux coauteurs vont être ravi !

Merci à tous pour votre aide, maintenant il faut pousser numworks à cesser la limitation arbitraire à 16ko, les échanges que j'ai eu par mail avec le support de numworks m'ont permis de comprendre que le 16ko avait été fixé un peu au petit bonheur la chance.

[Lionel Debroux]

Merci pour vos tests
https://github.com/numworks/epsilon/pull/1064 pour élargir le tas à 32 KB, donc.