Forum TI-Planet.org

Lien : https://workshop.numworks.com/python/andreanx/mem

Nul besoin de tester expérimentalement quand on a la réponse dans le code : https://github.com/numworks/epsilon/blo ... ller.h#L84

Il y a 16 KiB de RAM disponible pour le tas de l'interpréteur MicroPython. En pratique, la pile d'appel Python, toutes les variables/fonctions/classes définies dans les scripts importés et à l'exécution ainsi que leurs overhead associés vont puiser dedans, d'où les ~13 KiB trouvés expérimentalement.

Pour l'outil de visualisation en ligne, ce sont les mêmes 16 KiB de RAM qui sont utilisés, une piste possible pour expliquer une mémoire de travail moins spacieuse serait l'usage d'entiers et de pointeurs 64 bits dans les programmes/OS modernes. Il faudrait tester avec un navigateur web 32 bits si on observe le même comportement que sur la calculette.

Le vrai problème n'est pas les 16 KiB, mais l'absence de gestion de mémoire intelligente dans le firmware de NumWorks. Il y a bien un mécanisme pour allouer dynamiquement de la mémoire, mais un malloc qui rate et c'est le RESET direct. Il n'est pas possible à l'heure actuelle de gérer précisément le stockage mémoire et les variables comme sur une TI ni de savoir où on en est. On peut supprimer des données par applications pour faire de la place, mais ça ne va pas aider pour le Python.

Ce n'est pas avec les 4K de stockage des scripts que ca va changer grand chose... Il faut changer la taille de la memoire flash et RAM, comme je le dis depuis le debut, j'espere que Numworks prevoit aussi ca dans son modele avec nouveau clavier pour la rentree!
Sur la Numworks actuelle avec une capacite memoire digne d'une calculatrice d'il y a plus de 20 ans, il ne vous reste plus qu'a stocker a la main les donnees temporaires plus grosses que 4K dans la memoire ecran

parisse a écrit:Ce n'est pas avec les 4K de stockage des scripts que ca va changer grand chose... Il faut changer la taille de la memoire flash et RAM, comme je le dis depuis le debut, j'espere que Numworks prevoit aussi ca dans son modele avec nouveau clavier pour la rentree!

Comme je l'ai noté, dans ce cas présent le problème n'est pas réellement un manque de RAM mais plutôt l'impossibilité de finement contrôler les données en RAM avec l'architecture logicielle actuelle du firmware qui pousse à des choix (très) conservateurs. Sur une TI, une erreur d'allocation mémoire pour une variable entraîne une erreur qui est remontée à l'utilisateur, qui peut agir en conséquence. Sur NumWorks, c'est le RESET pur et simple, donc ils sont assez frileux pour le moment.

Si NumWorks gérait la Flash comme mémoire d'archive y'en aurait pour 350 KiB et pourtant on est limité à 4 KiB en RAM pour les scripts. Au bout d'un moment faut reconnaître que y'a pas que des problèmes d'ordre matériel

parisse a écrit:Sur la Numworks actuelle avec une capacite memoire digne d'une calculatrice d'il y a plus de 20 ans, il ne vous reste plus qu'a stocker a la main les donnees temporaires plus grosses que 4K dans la memoire ecran

Pas possible, y'a pas de fonction pour lire un pixel à l'écran

jean-baptiste boric a écrit:Comme je l'ai noté, dans ce cas présent le problème n'est pas réellement un manque de RAM mais plutôt l'impossibilité de finement contrôler les données en RAM avec l'architecture logicielle actuelle du firmware qui pousse à des choix (très) conservateurs. Sur une TI, une erreur d'allocation mémoire pour une variable entraîne une erreur qui est remontée à l'utilisateur, qui peut agir en conséquence. Sur NumWorks, c'est le RESET pur et simple, donc ils sont assez frileux pour le moment.

Si NumWorks gérait la Flash comme mémoire d'archive y'en aurait pour 350 KiB et pourtant on est limité à 4 KiB en RAM pour les scripts. Au bout d'un moment faut reconnaître que y'a pas que des problèmes d'ordre matériel

Justement si, le probleme a la base de tout, c'est bien la memoire insuffisante. Ca leur coute certainement bien plus cher de passer des heures et des heures de developpement/bugfixes/choix conservateurs pour eviter le memory full/reset que d'avoir des le depart choisi des capacites de memoire plus conformes a notre epoque. En prime je pense que tous ces efforts n'auront pas servi a grand chose (si ce n'est enerver les early adopters), parce que je suis a peu pres persuade qu'ils finiront par faire une Numworks avec plus de memoire. En tout cas, c'est la lecon que j'ai retiree du developpement de la hp39gii.

Pas possible, y'a pas de fonction pour lire un pixel à l'écran

il me semblait pourtant que get_pixel sert a ca.

jean-baptiste boric a écrit:Nul besoin de tester expérimentalement quand on a la réponse dans le code : https://github.com/numworks/epsilon/blo ... ller.h#L84

Certes mais l'autre but de ce script est de tourner aussi sur Graph 90+E, calculatrice pour laquelle nous n'aurons pas le code source.
A date, son exécution sur le logiciel de démo disponible qui a été analysé et n'est pas un émulateur mais un simulateur ne prouve rien. Mais au moins, je sais que ça marche.

Ce critère sera donc évaluable de façon aussi équitable que possible pour un des points du QCC 2018.

jean-baptiste boric a écrit:Il y a 16 KiB de RAM disponible pour le tas de l'interpréteur MicroPython. En pratique, la pile d'appel Python, toutes les variables/fonctions/classes définies dans les scripts importés et à l'exécution ainsi que leurs overhead associés vont puiser dedans, d'où les ~13 KiB trouvés expérimentalement.

J'ai omis de le préciser, mais j'ai désactivé les importations automatiques de tous les scripts préchargés avant de tester.

D'ailleurs en passant puisqu'il m'avait été demandé de donner des exemples, c'est justement un des nombreux scripts Python n'allant pas chercher de modules et qui pourtant ne passent pas sans artifice sur HP Prime.
La machine ne comprend pas True ni len().
Et même après remplacement, je pense que la machine ne comprend pas du tout ce que la ligne l = l + l[l[0]:] lui demande de faire.

Dans la configuration actuelle de la Prime, le parser CAS ne reconnait pas True, et les indices commencent a 1 (il faudrait que la configuration contienne une case Python a cocher pour faire demarrer les indices a 0). Mais meme si les modifs etaient apportees, je ne pense pas que ce script particulier marchera car il suppose qu'une exception soit levee par les routines d'acces a la memoire. Les capacites de travail de la HP sont limitees par la RAM, il y a donc 3 ordres de grandeur de plus que sur la Numworks et l'evaluateur passe en mode non recursif donc on n'est pas limite par la taille de la stack pour les programmes recursifs, par exemple

Code: Tout sélectionner

#cas
def facto(n):
  if n<=1:
    return 1
  return n*facto(n-1)
#end


puis facto(100)
Au passage, si vous voulez tester ce que pourrait donner la compatibilite Python, essayez dans Xcas pour Firefox, pas sur la Prime qui a 6 mois de retard sur Xcas. Je continue a y travailler avec les scripts publics Numworks (non orientes objets) pour faire en sorte qu'on puisse les faire tourner avec tres peu de modifications, voire pas du tout, dans Xcas pour Firefox.

c'est vieux comme le monde mais
+ de mémoire = bénéfice en moins