Forum TI-Planet.org

Il faudrait analyser plus precisement ce qui rend instable KhiCAS lorsqu'il est utilise conjointement avec Omega. Peut-etre la taille de la pile? KhiCAS alloue sur la pile le catalogue des commandes et ca consomme beaucoup.

Ceci etant dit, pour les personnes qui souhaitent utiliser KhiCAS pour travailler, je conseille bien sur d'utiliser Delta, car c'est la-dessus que je teste. Quand je dis travailler, je veux bien sur dire faire des maths, mais aussi programmer, avec un MicroPython plus complet que celui d'Epsilon. Ne vous inquietez pas trop lorsque critor ecrit "Delta apporte beaucoup moins d'améliorations qu'Omega", ces ameliorations d'Omega sont (a mon avis forcement un peu subjectif) essentiellement cosmetiques, on travaille tout aussi bien avec Delta+KhiCAS qu'avec Omega+KhiCAS (d'ailleurs certains raccourcis comme les shift-nombre d'Omega sont tres probablement inspires des raccourcis menus rapides de KhiCAS).

A noter que la version Numworks de KhiCAS ne propose pas d'interpreteur Javascript contrairement a la version TI Nspire CX, par manque de memoire RAM disponible: deja partager les environ 100K de memoire entre UI, Xcas et MicroPython c'est vraiment limite, alors il est impossible d'en reserver pour QuickJS, surtout si on veut profiter de la specificite de QuickJS qui est son excellente integration avec les maths (types entiers longs, flottants longs, complexes, polynomiaux, matrices/vecteurs avec surcharge des operateurs) mais qui necessite d'interpreter un script Javascript assez lourd.

parisse wrote:A noter que la version Numworks de KhiCAS ne propose pas d'interpreteur Javascript contrairement a la version TI Nspire CX, par manque de memoire RAM disponible: deja partager les environ 100K de memoire entre UI, Xcas et MicroPython c'est vraiment limite, alors il est impossible d'en reserver pour QuickJS, surtout si on veut profiter de la specificite de QuickJS qui est son excellente integration avec les maths (types entiers longs, flottants longs, complexes, polynomiaux, matrices/vecteurs avec surcharge des operateurs) mais qui necessite d'interpreter un script Javascript assez lourd.

Merci, j'ai corrigé.

parisse wrote:Il faudrait analyser plus precisement ce qui rend instable KhiCAS lorsqu'il est utilise conjointement avec Omega. Peut-etre la taille de la pile? KhiCAS alloue sur la pile le catalogue des commandes et ca consomme beaucoup.

Mais je peux vous donner un exemple de suite :

Code: Select all

def seuil(d):
  n=0
  u=2.
  d=d**2
  while (u-1)**2>=d:
    u=1+1/((1-u)*(n+1))
    n=n+1
  return [n,u]

Avec l'appli KhiCAS distribuée pour Omega et en mode MicroPython, l'appel seuil(0.008) ne marche pas.
C'est-à-dire qu'il se termine sans fournir ni de résultat ni d'exception, la calculatrice s'éteint sans avoir rien affiché, ce qui est totalement anormal.

Et ce alors qu'il marche parfaitement avec l'appli KhiCAS distribuée pour Delta, ou encore dans le mode de compatibilité Python.

De mémoire c'est très loin d'être la seule anomalie concernant l'application KhiCAS Omega.

Autre exemple problématique avec l'édition de KhiCAS pour Omega :

Code: Select all

def nodivisorin(n,l):
  for k in l:
    if n//k*k==n:
      return False
  return True

def isprimep(n):
  l,k=,[3],7
  if n==2 or n==5:return True
  if int(n)!=n or n//2*2==n or n//5*5==5:
    return False
  if n<k:return n in l
  while k*k<n:
    if nodivisorin(k,l):l.append(k)
    k+=2+2*((k+2)//5*5==k+2)
  r=nodivisorin(n,l)
  return r

Pareil, avec l'appel isprimep(10000019) en mode MicroPython, la calculatrice semble s'éteindre pendant le calcul, sans avoir affiché le moindre résultat ni la moindre exception.

Et ce alors que le même code marche parfaitement en mode de compatibilité Python, ou encore sur l'édition de KhiCAS pour Delta.

critor wrote:

• La mémoire de stockage, qui contient physiquement tes scripts prêts à l'emploi.
• La pile (stack) qui référence, à l'exécution, les objets Python créés. Sa capacité limite donc le nombre d'objets Python pouvant coexister simultanément en mémoire.
• Le tas (heap) qui stocke, à l'exécution, le contenu des objets Python créés. Il limite donc la taille globale utilisée pour les données de ces différents objets.

Le langage Python est un très gros consommateur de mémoire heap. En effet sur les plateformes 32 bits, un entier nul occupe déjà pas moins de 24 octets. Alors imagine tout le reste...

Je comprends de mieux en mieux ces histoires de mémoire. Je ne sais pas si se sont les explications qui sont de plus en plus claires ou si cela commence enfin à pénétrer mon esprit.

Cela n'a l'air de rien, mais la taille du tas heap est très importante pour développer des projets un peu important, sans être obèses. Entre juillet 2019 et mars 2020, avec le heap de 16 ko c'était juste un enfer, comme en témoigne le topic : Script qui refuse de s’exécuter sur la Numworks N0100

En mars 2020, les choses se sont un peu débloqués et on a enfin vu passer la taille du heap de 16 ko à 32 ko, ce qui m'a permis avec des élèves motivés de pouvoir commencer à développer des petits jeux pour la NumWorks.

Et la taille du heap n'est pas importante que pour les jeux, les scripts un peu costaud, les boîtes à outils en mathématiques par exemple peuvent consommer rapidement de la mémoire.

Lors du lancement du Tetris, nous avions réussi avec Golden Man à consommer la quasi-totalité de la taille du heap, par chance le jeu était fini mais nous avions quelques idées potentiels qui ont été abandonnées faute de mémoire.

Aujourd'hui une nouvelle génération de codeurs arrive, elle est brillante, intuitive, fait des jeux superbes maitrisant parfaitement les codes des jeux arcades et n'hésitant pas à "coder large" pour avoir un beau rendu. Si vous n'avez pas encore découvert les jeux de fime, votre vie n'est pas encore foutu mais il ne faudrait pas trop tarder non plus.

Son espace workshop : https://workshop.numworks.com/python/fime

Il a fait un Doodle Jump qui ne marche pas sur le Workshop mais sur la calculatrice il est juste parfaitement calibré.

Si je préfère le design flat, je dois reconnaitre que sa proposition de snake est juste incroyable.

Son jetpack_bird a d'ailleurs eu l'honneur de passer ici même, et ce n'est pas le meilleur de ces jeux je trouve.

Enfin, pour son pong, il m'a expliqué qu'il consommait trop de mémoire mais qu'il tournait sur Omega. C'est à ce moment là que j'ai compris que Omega avait débloqué la taille du heap, montrant à NumWorks le chemin à prendre.

Je me suis un peu égaré, mais je n'ai pas perdu le fil

critor wrote:À quand les 120K histoire que cela change l'ordre du classement ?

Sur le Tetris, nous avions demandé à Omega de nous faire un tas de 120 Ko, sans vraiment y croire, juste pour les occuper, les génies ne doivent pas s'ennuyer trop longtemps, il faut toujours les nourrir de projets à mener. Nous ne pensions pas voir la taille du tas se débloquer si vite, mais il est très appréciable de pouvoir exploiter le potentiel de la NumWorks.

Un grand bravo donc aux développeurs de Omega !

On va se contenter de 100 Ko pour l'instant , et il faut espérer que le chemin tracé sera suivi par Epsilon, l'OS officiel de la NumWorks, et si la pente est trop raide, on peut se contenter de 64 ko pour commencer (sautons mais alors à titre vraiment exceptionnel, l'étape des 42 ko)

Un grand bravo donc aux développeurs de Omega !

critor wrote:Toutefois, toutes les calculatrices Python n'intègrent pas ce module.

On peut l'activer si tu trouves ça nécessaire

parisse wrote:Il faudrait analyser plus precisement ce qui rend instable KhiCAS lorsqu'il est utilise conjointement avec Omega. Peut-etre la taille de la pile? KhiCAS alloue sur la pile le catalogue des commandes et ca consomme beaucoup.

Sur omega, on a drastiquement réduit le heap natif en effet (pour augmenter celui pour python), mais comme le firmware lui même n'utilise pratiquement pas d'allocations dynamiques ça ne devrait pas déranger (même si on a eu des crash lié à de vieux problèmes). Cependant, les allocations dynamiques d'external ce font sur un buffer qu'on passe en paramètre lors de l'execution d'une app externe (cf. les sources d'external) qui est un buffer non alloué dynamiquement dans omega (il est dans l'application external). Le seul changement qu'on ai fait est d'augmenter sa taille jusqu'à aussi 100000o.

cent20 wrote:En mars 2020, les choses se sont un peu débloqués et on a enfin vu passer la taille du heap de 16 ko à 32 ko, ce qui m'a permis avec des élèves motivés de pouvoir commencer à développer des petits jeux pour la NumWorks.

Ce changement est du à l'arrivée du module pyplot d'ailleurs (c'était pas pour toi )

cent20 wrote:On va se contenter de 100 Ko pour l'instant

Soon (tm)

redgl0w wrote:

parisse wrote:Il faudrait analyser plus precisement ce qui rend instable KhiCAS lorsqu'il est utilise conjointement avec Omega. Peut-etre la taille de la pile? KhiCAS alloue sur la pile le catalogue des commandes et ca consomme beaucoup.

Sur omega, on a drastiquement réduit le heap natif en effet (pour augmenter celui pour python), mais comme le firmware lui même n'utilise pratiquement pas d'allocations dynamiques ça ne devrait pas déranger (même si on a eu des crash lié à de vieux problèmes). Cependant, les allocations dynamiques d'external ce font sur un buffer qu'on passe en paramètre lors de l'execution d'une app externe (cf. les sources d'external) qui est un buffer non alloué dynamiquement dans omega (il est dans l'application external). Le seul changement qu'on ai fait est d'augmenter sa taille jusqu'à aussi 100000o.

Ce n'est pas moi qui ai travaille sur l'allocation memoire dans Delta, c'est zardam, de mon cote je me contente d'utiliser malloc, donc je ne vais pas pouvoir dire grand chose de precis .
Je peux quand meme dire que d'apres les symptomes decrits par critor, le probleme semble venir du malloc appele pour initialiser le tas MicroPython. Il semble probable qu'une partie de la memoire donnee par malloc soit utilisee par autre chose quand KhiCAS tourne depuis Omega, ca pourrait etre la pile par exemple ou bien de la memoire utilisee par une des routines systemes qui sont appelees par MicroPython (gestion ecran/clavier?).
Quelques suggestions de tests pour isoler mieux le probleme: reduire la taille du tas micropython dans les parametres de KhiCAS et voir si les programmes de critor tournent ou pas. Tester aussi quelques calculs qui prennent un peu de memoire (par exemple calcul d'inverses de matrices nxn du genre n:=10; a:=ranm(n,n); inv(a); et augmenter la valeur de n ou/et le nombre de matrices) pour voir si le probleme n'apparait qu'avec MicroPython ou aussi avec Xcas.

parisse wrote:Ce n'est pas moi qui ai travaille sur l'allocation memoire dans Delta, c'est zardam, de mon cote je me contente d'utiliser malloc, donc je ne vais pas pouvoir dire grand chose de precis .

De toute manière comme je l'ai écrit au dessus, normalement les appels de malloc sont alloués dans un buffer qui n'a rien à voir avec la baisse du heap du firmware.

parisse wrote:Je peux quand meme dire que d'apres les symptomes decrits par critor, le probleme semble venir du malloc appele pour initialiser le tas MicroPython. Il semble probable qu'une partie de la memoire donnee par malloc soit utilisee par autre chose quand KhiCAS tourne depuis Omega, ca pourrait etre la pile par exemple ou bien de la memoire utilisee par une des routines systemes qui sont appelees par MicroPython (gestion ecran/clavier?).

Normallement la mémoire est dans le buffer static des apps. Une des sources possibles serait le lancement depuis l'application home que M4x1m3 a écrit (que personne n'a review :/ ).

parisse wrote:Quelques suggestions de tests pour isoler mieux le probleme: reduire la taille du tas micropython dans les parametres de KhiCAS et voir si les programmes de critor tournent ou pas. Tester aussi quelques calculs qui prennent un peu de memoire (par exemple calcul d'inverses de matrices nxn du genre n:=10; a:=ranm(n,n); inv(a); et augmenter la valeur de n ou/et le nombre de matrices) pour voir si le probleme n'apparait qu'avec MicroPython ou aussi avec Xcas.

Le plus simple pour trouver la source du problème serait d'avoir de quoi debug sur n0110 (j'ai un stlink v2, mais pas de quoi le connecter, car les seuls vendeurs de connectiques qui proposent ce que je cherche se font une très bonne marge).

Salut
J'étais le premier enthousiasmé par cette mise à niveau, j'avais déjà du stopper le dev d'un tetris en POO alors que celui-ci n'avais un taille "que" de 9ko.

Apres cette MAJ j'ai donc repris le développement très vite et j'ai pondu un script d'environ 16ko (et le jeu étais pas fini !). Enfin, bref, ma calculatrice s'est reset quand j'ai voulu entrer dans l'application suites (et j'avais pas fait de backup le soir précédent, j'vous jure j'étais sur le cul \o/ ).

Donc ma remarque/question est la suivante : je ne m'y connais pas très bien en architecture système, mais n'y a-t-il pas un risque de "collision" de mémoire entre applications qui causerais des bugs?
Est-ce que ce potentiel problème a été pris en compte ?

D'autant plus que numworks, eux (qui on conçu le système) limitent leur tas à seulement un tier de celui de Omega (comme on l'a dit, environ 33ko). Serais-ce par mesure de sécurité ?