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

[redgl0w]

Pour l'anomalie n°1, je ne sais pas. Je ne dispose que d'une seule NumWorks N0110, donc c'est assez lourd pour moi d'avoir à chaque fois non seulement à changer de firmware, mais en plus à réinstaller l'application KhiCAS vu que ses éditions Omega et Delta ne sont pas interchangeables.

C'est pas moi qui est Ce n'est pas moi qui ai géré ça (et vu la galère que maxime a eu pour faire tourner l'app, je ne veux pas y toucher ). Il faudrait vraiment chercher à un moment pourquoi elles ne sont pas compatibles (car à part le heap pour external, il ne devrait pas y avoir tant de différences).

[critor]

Il faudrait vraiment chercher à un moment pourquoi elles ne sont pas compatibles (car à part le heap pour external, il ne devrait pas y avoir tant de différences).

Me concernant, ça vous avait déjà été signalé. De mémoire, pour l'été 2020.

Voici ce que donne l'édition Delta de KhiCAS si installée sur Omega, une erreur d'API :


Donc si je ne peux pas faire de mélange, difficile de savoir si la série d'anomalies est due au firmware Omega, ou bien à sa déclinaison de KhiCAS.

[redgl0w]

Voici ce que donne l'édition Delta de KhiCAS si installée sur Omega, une erreur d'API :


Donc si je ne peux pas faire de mélange, difficile de savoir si la série d'anomalies est due au firmware Omega, ou bien à sa déclinaison de KhiCAS.

Cette erreur est retourné lorsque l'application externe retourne la valeur 1, qui correspond normallement à une version de l'API différente entre le firmware et l'app. Sur omega, nous sommes à external V2, et je voulais regarder si la version est la même sur khicas, et sur l'installateur qui me semble être celui de delta + KhiCas, la dernière version du firmware date du dernier commit sur cette branche, qui est aussi sous version 2.

[parisse]

Quand je regarde le script seuil de critor, il me semble qu'il ne nécessite pas d'allocation mémoire interne à MicroPython : toutes les variables sont numériques à taille fixe sauf n mais il reste petit entier pendant le déroulement du script.
Supposons que seuil(0.008) se termine normalement. Dans ce cas, KhiCAS reprend la main et va afficher le résultat, ce qui nécessite des appels à malloc, mais beaucoup moins que n'importe quel calcul effectué en interne par Xcas donc ça me parait peu vraisemblable. D'autant plus que la vidéo de critor montre qu'ensuite on a un "keyboard interrupt".
Donc je penche plutôt sur un problème lorsque MicroPython teste si le clavier est actif pour gérer l'appui de la touche d'interruption pendant le déroulement d'un programme. Il y a une fonction int micropython_port_vm_hook_loop() {...} qui gère ça, et, dans l'implémentation de cette fonction, j'utilise des appels au "SDK C". Si ces appels n'utilisent pas la même interface que dans Delta, ça va bugguer. Et d'ailleurs l'interruption d'un script ne doit probablement pas marcher. Si c'est bien ça, il faudrait peut-être recompiler libmicropy.a.

[redgl0w]

Si ces appels n'utilisent pas la meme interface que dans Delta, ca va bugguer.

Malheureusement, le control de version de delta/external est une réelle galère pour l'instant, et il est pour nous presque impossible de pouvoir comparer omega et delta. En effet, il y a les sources de khiCas sur le repo nw-external de zardam, celle que maxime a essayé de fix sur le repo d'omega, delta avec 50 branches, qui datent toutes d'il y a longtemps, donc impossible de savoir laquelle est celle compilée pour zardam/nw-external, ...

[critor]

Donc je penche plutôt sur un problème lorsque MicroPython teste si le clavier est actif pour gérer l'appui de la touche d'interruption pendant le déroulement d'un programme. Il y a une fonction int micropython_port_vm_hook_loop() {...} qui gère ça, et, dans l'implémentation de cette fonction, j'utilise des appels au "SDK C". Si ces appels n'utilisent pas la même interface que dans Delta, ça va bugguer. Et d'ailleurs l'interruption d'un script ne doit probablement pas marcher. Si c'est bien ça, il faudrait peut-être recompiler libmicropy.a.

Merci.

Sous Delta+KhiCAS, si je lance un while 1:pass, la seule touche d'annulation me permet d'interrompre le script, et toutes les autres sont sans effet, comportement attendu.

Et effectivement bien vu, sous Omega+KhiCAS quelque chose ne semble pas du tout aller avec le clavier...
N'importe quelle touche me permet d'interrompre le script, et la touche on/off éteint même directement la calculatrice alors que le script est pourtant en cours d'exécution.

Cela expliquerait-il l'ensemble des anomalies que je rencontre avec la version Omega de KhiCAS ?
Scripts qui semblent se figer jusqu'à l'appui sur une touche ?
Scripts qui semblent se terminer sans réponse ni exception ?
Calculatrice qui semble pouvoir s'éteindre (automatiquement ou manuellement) pendant l'exécution de scripts, et retournant dans les deux cas une exception KeyboardInterrupt au rallumage ?

Merci.

[parisse]

S'il n'y a pas d'anomalies dans l'utilisation de KhiCAS en-dehors de MicroPython, alors oui ca pourrait etre responsable de l'ensemble des anomalies que vous avez constatees. L'implementation de micropython_port_vm_hook_loop incremente un compteur et teste le clavier une fois tous les 2048 appels (pour eviter de ralentir trop la VM).

Code: Select all

int micropython_port_vm_hook_loop() {
  /* This function is called very frequently by the MicroPython engine. We grab
   * this opportunity to interrupt execution and/or refresh the display on
   * platforms that need it. */

  /* Doing too many things here slows down Python execution quite a lot. So we
   * only do things once in a while and return as soon as possible otherwise. */
  static int c = 0;

  ++c;
  if (c & 0x7ff ) {
    return 0;
  }

  // Check if the user asked for an interruption from the keyboard
  int g=getkey(mp_interrupt_char | 0x80000000);
  if (!g) return 0;
  mp_keyboard_interrupt();
  return 1;
}


[critor]

Merci.

Oui, ces anomalies ne concernent que le mode Micropython de KhiCAS édition Omega.
Elles ne sont pas présentes dans le mode de compatibilité Python.

[redgl0w]

S'il n'y a pas d'anomalies dans l'utilisation de KhiCAS en-dehors de MicroPython, alors oui ca pourrait etre responsable de l'ensemble des anomalies que vous avez constatees. L'implementation de micropython_port_vm_hook_loop incremente un compteur et teste le clavier une fois tous les 2048 appels (pour eviter de ralentir trop la VM).

Sur epsilon l'implémentation a changé, et peut être qu'il serait intéressant de faire comme eux : ils vérifient l'appuie de la touche après un certains temps et non pas un certains nombres de cycles.

[parisse]

Sur epsilon l'implémentation a changé, et peut être qu'il serait intéressant de faire comme eux : ils vérifient l'appuie de la touche après un certains temps et non pas un certains nombres de cycles.

Il faudrait connaitre le cout en temps de l'execution de l'instruction uint64_t t2 = Ion::Timing::millis();, si c'est proche de quelques cycles (incrementation d'un entier et test) alors c'est mieux. Mais vu que j'ai mis la valeur 0x7ff pour le test, la VM doit vraiment appeler tres souvent vm_hook, donc ca ne doit pas changer grand chose.

De toutes facons, ce n'est pas ca qui est en cause ici. En y reflechissant, recompiler libmicropy.a ne servira probablement a rien, par contre il faudrait verifier que l'implementation d'Omega de getkey suit la meme convention que dans Delta, a savoir regarder ce que renvoie getkey(mp_interrupt_char | 0x80000000); avec mp_interrupt_char=5.
D'ailleurs je vois que dans ma version de Delta, la declaration dans nw-external-apps/api/api.c est incorrecte (parametre bool au lieu de int), j'ai:

Code: Select all

int getkey(bool allow_suspend) {
  return ((int (*)(bool))_api_base[74])(allow_suspend);
}

Mais l'implementation dans delta/python/port/port.cpp correspond a ce qui est attendu dans main.c de micropython:

Code: Select all

int getkey(int allow_suspend){
  if (allow_suspend & 0x80000000)
    return iskeydown(allow_suspend & 0xff)?1:0;
...
}

bool iskeydown(int k){
  Ion::Keyboard::State scan = Ion::Keyboard::scan();
  return scan.keyDown(Ion::Keyboard::Key(k));
}


Ca marche malgre l'erreur de declaration bool/int parce qu'un bool en parametre est stocke physiquement comme un int.

Donc voila ce qu'il faudrait verifier sur Omega, d'abord est-ce que le numero de syscall est le bon (((int (*)(bool))_api_base[74])) et ensuite est-ce que l'implementation de getkey est bonne ?