NumWorks Omega 1.21 : 100K de heap pour scripts Python !

[Admin]

Les interpréteurs MicroPython ou similaires qui tournent sur nos calculatrices font appel à différents types de mémoires :

• 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...

Tout ceci pour dire que la mémoire heap sera très souvent le facteur limitant lors de tes projets Python sur calculatrices.

Afin de te permettre de choisir ton modèle en toute connaissance de cause, nous t'avions déjà communiqué un classement des différents modèles Python par capacité heap :

en exam
officiel en exam
tiers hors exam
officiel hors exam
tiers

1. 252,1 Mo : HP Prime G2
2. 15,6 Mo : HP Prime G1
3. 2,068 Mo : TI-Nspire CX II
4. 1,033 Mo : Casio Graph 90+E
5. 101,262 Ko : Casio Graph 35+E II
6. 33,545 Ko : NumWorks
7. 18,354 Ko : TI-83 Premium CE Edition Python

1. 252,1 Mo : HP Prime G2
2. 15,6 Mo : HP Prime G1
3. 4,100 Mo : TI-Nspire CX (Ndless + KhiCAS)
4. 2,068 Mo : TI-Nspire CX II
5. 1,033 Mo : Casio Graph 90+E
6. 101,262 Ko : Casio Graph 35+E II
7. 64,954 Ko : NumWorks (firmware Omega + appli KhiCAS)
8. 33,545 Ko : NumWorks
9. 18,354 Ko : TI-83 Premium CE Edition Python

1. 252,1 Mo : HP Prime G2
2. 15,6 Mo : HP Prime G1
3. 2,068 Mo : TI-Nspire CX II
4. 1,033 Mo : Casio Graph 90+E / fx-CG50
5. 101,262 Ko : Casio Graph 35+E II / fx-9750/9860GIII
6. 33,545 Ko : NumWorks
7. 20,839 Ko : TI-83 Premium CE + TI-Python
8. 18,354 Ko : TI-83 Premium CE Edition Python / TI-84 Plus CE Python Edition

1. 252,1 Mo : HP Prime G2
2. 15,6 Mo : HP Prime G1
3. 4,100 Mo : TI-Nspire CX / CX II (Ndless + KhiCAS CX / KhiCAS CX II)
4. 2,068 Mo : TI-Nspire CX II
5. 2,050 Mo : TI-Nspire (Ndless + MicroPython)
6. 1,033 Mo : Casio Graph 90+E / fx-CG50
7. 258,766 Ko : Casio Graph 35/75+E / 35/75/95 / fx-9750/9860GII (SH4 - appli CasioPython)
8. 101,262 Ko : Casio Graph 35+E II / fx-9750/9860GIII
9. 64,954 Ko : NumWorks (firmware Omega + appli KhiCAS)
10. 33,545 Ko : NumWorks
11. 32,648 Ko : Casio Graph 35+E II / 35/75/85/95(SH3) / fx-9750/9860GIII / fx-9750/9860GII(SH3) / fx-9860G (appli CasioPython)
12. 23,685 Ko : TI-83 Premium CE + TI-Python (firmware tiers)
13. 20,839 Ko : TI-83 Premium CE + TI-Python
14. 18,354 Ko : TI-83 Premium CE Edition Python / TI-84 Plus CE Python Edition

De nouveaux éléments concernant la NumWorks nécessitent aujourd'hui la mise à jour de ce classement : une bonne et une mauvaise nouvelle. Commençons par la mauvaise.

Sur NumWorks N0110, tu as la possibilité d'installer KhiCAS, une application t'offrant un environnement intégré de Mathématiques et de Sciences développé par Bernard Parisse, enseignant-chercheur à l'Université de Grenoble, en parallèle de son logiciel Xcas pour ordinateur. Elle intègre nombre de choses : moteur de calcul formel GIAC, bibliothèques d'unités et de constantes physiques, application tableur, application de tableau périodique des éléments, langages de programmation Python et Xcas, ...

Le firmware officiel ne gérant pas les applications additionnelles, pour l'installer il te fallait commencer par passer ta calculatrice sous un firmware tiers, comme par exemple Omega. Or, l'application KhiCAS distribuée sur la page du firmware tiers Omega est sûrement suffisante pour nombre de choses, mais n'est pas stable.

Si tu es un utilisateur exigeant de KhiCAS, il te faut une version aussi fiable que possible et elle existe ; il te suffit de prendre l'application KhiCAS distribuée pour Delta, un autre firmware tiers.

Mise à part la gestion des applications, Delta apporte beaucoup moins d'améliorations qu'Omega, et malheureusement ces deux éditions de l'application KhiCAS ne sont pas interchangeables. En attendant une éventuelle résolution du problème, nous nous devons donc de tenir compte de Delta au classement.

D'autre part, nous ne l'avions pas remarqué mais Omega a changé la capacité du heap Python à compter de sa version 1.21 un peu plus tôt cette année...

Alors découvrons tout cela sans plus attendre.

Le module Python standard gc permet de connaître la capacité exacte du heap, d'un simple appel gc.mem_alloc() + gc.mem_free(). Toutefois, toutes les calculatrices Python n'intègrent pas ce module.

Afin de pouvoir faire des comparaisons équitables, nous construisons notre propre script d'estimation de la capacité heap. Il utilise les tailles des objets Python suivantes, valides pour les plateformes 32 bits que sont à ce jour nos calculatrices :

• pour un entier nul : 24 octets déjà...
• pour un entier court non nul (codable sur 31 bits + 1 bit de signe) : 28 octets
• pour un entier long :
  
  • 28 octets
  • + 4 octets pour chaque groupe de 30 bits utilisé par son écriture binaire au-delà des 31 bits précédents
• pour une chaîne :
  
  • 49 octets
  • + 1 octet par caractère
• pour une liste :
  
  • 64 octets
  • + 8 octets par élément
  • + les tailles de chaque élément

Notre script va tenter de remplir le heap. Il utilise pour cela plusieurs objets qu'il va tenter de faire grandir chacun son tour, jusqu'à déclenchement d'une erreur, et retourner alors le calcul de la capacité ainsi consommée.


Nous récupérerons de plus la plus grand taille d'objet que nous avons réussi à utiliser lors de ce test, on t'explique de suite.

Voici donc le script, issu du QCC 2020 :

Code: Select all

def size(o):
  t = type(o)
  s = t == str and 49 + len(o)
  if t == int:
    s = 24
    while o:
      s += 4
      o >>= 30
  elif t == list:
    s = 64 + 8*len(o)
    for so in o:
      s += size(so)
  return s

def mem(v=1):
  try:
    l=[]
    try:
      l.append(0)
      l.append(0)
      l.append("")
      l[2] += "x"
      l.append(0)
      l.append(0)
      while 1:
        try:
          l[2] += l[2][l[1]:]
        except:
          if l[1] < len(l[2]) - 1:
            l[1] = len(l[2]) - 1
          else:
            raise(Exception)
    except:
      if v:
        print("+", size(l))
      try:
        l[0] += size(l)
      except:
        pass
      try:
        l[3], l[4] = mem(v)
      except:
        pass
      return l[0] + l[3], max(l[0], l[4])
  except:
    return 0, 0

Selon l'état de l'interpréteur Python, la capacité retournée par un appel mem() peut légèrement varier. Aussi lancerons-nous le test plusieurs fois et conserverons-nous la valeur maximale, voici une fonction en ce sens :

Code: Select all

def testmem():
  m1, m2 = 0, 0
  while 1:
    t1, t2 = mem(0)
    if t1 > m1 or t2 > m2:
      m1 = max(t1, m1)
      m2 = max(t2, m2)
      input(str((m1,m2)))

Sur les NumWorks munies du firmware officiel Epsilon nous trouvons 32,526 Ko, et c'était pareil avec le firmware tiers Omega jusqu'à la version 1.20.3.

Sur la NumWorks N0110 munie du firmware tiers Delta, nous trouvons nettement moins pour le heap de l'application Python officielle, seulement 24,179 Ko.

Est-ce cette économie de mémoire qui permet à KhiCAS de fonctionner correctement ? En tous cas l'interpréteur Python de KhiCAS retourne pour le même test la superbe capacité de 63,898 Ko.

Si tu munis maintenant ta NumWorks des dernières version 1.21 du firmware tiers Omega, tu obtiens alors une fantastique capacité heap de désormais 98,928 Ko !

Avec la nouvelle capacité heap Python de près de 100 Ko dans Omega 1.21, ta NumWorks a enfin presque terminé de rattraper son retard sur la Casio Graph 35+E II bien moins chère !

Précisons que pour être aussi exact que possible, il faut rajouter à ces valeurs de retour la consommation mémoire des définitions du script, soit 1,056 Ko.

D'où le classement maintenant à jour :

en exam
officiel en exam
tiers hors exam
officiel hors exam
tiers

1. 252,1 Mo : HP Prime G2
2. 15,6 Mo : HP Prime G1
3. 2,068 Mo : TI-Nspire CX II
4. 1,033 Mo : Casio Graph 90+E
5. 101,262 Ko : Casio Graph 35+E II
6. 33,582 Ko : NumWorks
7. 18,354 Ko : TI-83 Premium CE Edition Python

1. 252,1 Mo : HP Prime G2
2. 15,6 Mo : HP Prime G1
3. 4,100 Mo : TI-Nspire CX (Ndless + KhiCAS)
4. 2,068 Mo : TI-Nspire CX II
5. 1,033 Mo : Casio Graph 90+E
6. 101,262 Ko : Casio Graph 35+E II
7. 98,928 Ko : NumWorks (firmware Omega)
8. 64,954 Ko : NumWorks N0110 (firmware Delta / Omega + appli KhiCAS)
9. 33,582 Ko : NumWorks
10. 25,235 Ko : NumWorks N0110 (firmware Delta)
11. 18,354 Ko : TI-83 Premium CE Edition Python

1. 252,1 Mo : HP Prime G2
2. 15,6 Mo : HP Prime G1
3. 2,068 Mo : TI-Nspire CX II
4. 1,033 Mo : Casio Graph 90+E / fx-CG50
5. 101,262 Ko : Casio Graph 35+E II / fx-9750/9860GIII
6. 33,582 Ko : NumWorks
7. 20,839 Ko : TI-83 Premium CE + TI-Python
8. 18,354 Ko : TI-83 Premium CE Edition Python / TI-84 Plus CE Python Edition

1. 252,1 Mo : HP Prime G2
2. 15,6 Mo : HP Prime G1
3. 4,100 Mo : TI-Nspire CX / CX II (Ndless + KhiCAS CX / KhiCAS CX II)
4. 2,068 Mo : TI-Nspire CX II
5. 2,050 Mo : TI-Nspire (Ndless + MicroPython)
6. 1,033 Mo : Casio Graph 90+E / fx-CG50
7. 258,766 Ko : Casio Graph 35/75+E / 35/75/95 / fx-9750/9860GII (SH4 - appli CasioPython)
8. 101,262 Ko : Casio Graph 35+E II / fx-9750/9860GIII
9. 98,928 Ko : NumWorks (firmware Omega)
10. 64,954 Ko : NumWorks N0110 (firmware Omega + appli KhiCAS)
11. 33,582 Ko : NumWorks
12. 32,648 Ko : Casio Graph 35+E II / 35/75/85/95(SH3) / fx-9750/9860GIII / fx-9750/9860GII(SH3) / fx-9860G (appli CasioPython)
13. 25,235 Ko : NumWorks N0110 (firmware Delta)
14. 23,685 Ko : TI-83 Premium CE + TI-Python (firmware tiers)
15. 20,839 Ko : TI-83 Premium CE + TI-Python
16. 18,354 Ko : TI-83 Premium CE Edition Python / TI-84 Plus CE Python Edition

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

[parisse]

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.

[critor]

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é.

[critor]

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.

[critor]

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.

[cent20]

• 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

À 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 !

[redgl0w]

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

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

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.

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 )

On va se contenter de 100 Ko pour l'instant

Soon (tm)

[parisse]

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.

[redgl0w]

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.

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 :/ ).

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).

[Fime]

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é ?