NumWorks, 1ère graphique française programmable en Python

[parisse]

Certes mais pourquoi le ferai-je? J'ai deja longuement explique tout ce que je n'aime pas dans cette calculatrice: tout le moteur mathematique me deplait, les apps qui sont completement independantes et rendent l'utilisateur presse-bouton, le style de programmation dans le source avec des templates et des new partout (au lieu d'utiliser la STL), le hardware qui n'offre pas assez de memoire. Le seul point vraiment positif c'est l'ouverture, mais pour en profiter il faudrait que je puisse porter giac dessus, mais voila il n'y a pas assez de memoire. Quel dommage, ca aurait pu etre une calc comme je le souhaite, pas chere et formelle, mais non!

[clifward]

Il serait possible d'y porter une version amoindrie de giac ?

[Adriweb]

Il n'est pas exclu cela dit, pour autant que je puisse imaginer, que des composants compatibles soient mis à jour au cours du temps par des versions plus évoluées (Lionel citait l'exemple d'un STM compatible avec plus de mémoire)... on verra bien au cours du temps ?

En effet, ça permettrait bien plus de choses niveau soft sans avoir à se casser la tête (si c'est possible tout court !) pour optimiser des choses à fond.
Giac serait un exemple de programme tiers, mais il y a plein d'autres exemples.

[clifward]

La quantité de mémoire en plus est risible... Sans mémoire ROM/RAM déportée, ça le fera pas... Et bonjour la rage, si tous les modèles qu'ils sortent en ce moment deviennent obsolètes dans 1 an...

[parisse]

Il n'est pas possible de faire une version amoindrie de giac qui tienne dans la flash de la numworks, il faut au moins 5M de flash (en gros le minimum c'est khicas - les flottants multiprecisions).

[Lionel Debroux]

le style de programmation dans le source avec des templates et des new partout (au lieu d'utiliser la STL)

Ben... La STL n'est pas connue pour être un modèle d'efficacité taille et vitesse en embarqué dur, donc ne pas l'utiliser à fond est clairement une bonne chose

Je vois dans https://github.com/numworks/epsilon/blo ... pression.h une note TODO sur l'utilisation de std::unique_ptr.
Ca facilite certes le codage, mais std::unique_ptr a des coûts cachés, et std::shared_ptr encore plus. J'utilise au boulot une forme de shared pointers avec comptage de référence intrusif (dans l'objet pointé), ce qui permet d'avoir sizeof(smart pointer type) == sizeof(pointer type) et une seule allocation mémoire... c'est quand même sympa.
Il y a même eu un papier WG21 pour standardiser de tels smart pointers ( http://www.open-std.org/jtc1/sc22/wg21/ ... 468r0.html ), mais sans suite (pour l'instant ?).

[critor]

Plusieurs problèmes avec la diode examen.

Je n'ai pas cherché à avoir accès au cahier des charges officiel, mais à ce que je devine vu ce qu'ont fait tous les autres constructeurs, une fois le mode examen activé la diode doit avoir un clignotement régulier en toute situation.

En pratique, ce n'est pas le cas :

• la diode cesse de clignoter et s'éteint quand on éteint la calculatrice (et reprend son clignotement quand on rallume)
• la diode fige son clignotement et reste donc allumée ou éteinte dans certaines situations :
  
  • pendant que l'on maintient enfoncée la touche d'extinction
  • pendant que l'on exécute un programme Python

Ce n'est pas dramatique si bien sûr c'est corrigé par une mise à jour dans les 9 prochains mois. La TI-84+CE-T elle aussi avait un défaut de clignotement dans sa première version.
En espérant qu'il n'y ait aucune contrainte matérielle empêchant de poursuivre un clignotement régulier dans ces situations.

[Adriweb]

Il faut reporter le(s) problème(s) ici : https://github.com/numworks/epsilon/issues (ils sont très réactifs) - cela dit je suppose qu'en tant que contact privilégié, tu peux leur en parler par mail etc. directement. Mais bref, au moins histoire d'être sûr qu'ils ont l'info, même si on peut imaginer qu'ils lisent ce(s) topic(s).
En tout cas, vu leur vitesse de réaction pour les choses reportées, il n'y a pas de problème, je pense, pour corriger ces comportements de LED là...

D'ailleurs je vois que le problème d'un reflashage bidouillant le mode exam a été posé... https://github.com/numworks/epsilon/issues/53

[critor]

J'ai déjà signalé par mail pour l'extinction.
Pas pour le Python, certes - mais c'est peut-être plus général, avec un blocage pendant tout calcul conséquent.

Edit : Oui, je viens de tester avec un lourd graphique. La diode se fige pendant le tracé.
Donc toute occupation du processeur/système est actuellement incompatible avec le clignotement.

[parisse]

le style de programmation dans le source avec des templates et des new partout (au lieu d'utiliser la STL)

Ben... La STL n'est pas connue pour être un modèle d'efficacité taille et vitesse en embarqué dur, donc ne pas l'utiliser à fond est clairement une bonne chose

L'interet de la STL (ou de tout autre remplacement populaire), c'est d'automatiser la gestion de la memoire meme si on en a besoin d'un peu plus. On peut faire de meme dans les constructeurs/destructeurs d'une classe. Ici la memoire est geree a la main

We decided to manually manage dynamic memory, but to use it as sparingly as possible.

(section "Working with limited memory" de https://www.numworks.com/resources/engineering/software/embedded/), c'est une source potentielle d'erreurs et cela augmente forcement le temps d'ecriture et maintenance du code. Je pense que le gain espere sur le hardware memoire est annule a cause de cela. C'est meme peut-etre ce qui explique que la calculatrice a beaucoup d'aspects inacheves ou mathematiquement naifs aujourd'hui.