Forum TI-Planet.org

parisse a écrit:critor, quel travail encore une fois!
Juste une precision sur la commande show_screen() de KhiCAS : elle ne fait effectivement rien sur Numworks, elle est juste la pour qu'on puisse avoir des scripts compatibles sur les differents ports de KhiCAS/Xcas. Sur Numworks, les commandes de trace sont executees immediatement, la seule chose qu'on peut faire pour eviter le scintillement c'est attendre le rafraichissement de l'ecran, j'ai une fonction en natif pour ca (bool waitforvblank()), elle n'est pas accessible depuis les langages utilisateurs (en fait en natif je ne la trouve pas facile a utiliser).

Merci pour le retour et la précision.

Mon travail n'est qu'un très pâle reflet de celui de nos développeurs HP préférés.

Oui, je me doutais bien que l'on n'avait pas suffisamment de RAM sur la NumWorks pour avoir du double buffering...

critor a écrit:Merci pour le retour et la précision.

Oui, je me doutais bien que l'on n'avait pas suffisamment de RAM sur la NumWorks pour avoir du double buffering...

Environ 120Kio d'après mes calculs si je me souviens bien, soit presque 50% de la RAM
Le matériel ne le permet juste pas

redgl0w a écrit:

critor a écrit:Merci pour le retour et la précision.

Oui, je me doutais bien que l'on n'avait pas suffisamment de RAM sur la NumWorks pour avoir du double buffering...

Environ 120Kio d'après mes calculs si je me souviens bien, soit presque 50% de la RAM
Le matériel ne le permet juste pas

Dans cet ordre-là merci, je trouve un peu plus pour allouer en RAM un buffer offscreen de l'affichage graphique Python, mais peut-être que j'oublie quelque chose et ne fais pas le même calcul que toi :
320×222×2 = 142,08 Ko = 138,75 Kio

Mais dans tous les cas, le manque de RAM se fait douloureusement sentir.

La fonction TEXTOUT_P() ne fonctionne toujours pas correctement si l'on précise le mode d'affichage naturel (2D).

Elle n'accepte d'afficher que si x≤0 :

Code: Tout sélectionner

EXPORT TEXT(s)
BEGIN
  LOCAL x0, dx, y, dims;
  x0:=10;
  dx:=2;
  dims:=TEXTSIZE(s);
  y:=0;
  FOR A FROM x0 DOWNTO -x0 STEP dx DO
    TEXTOUT_P(s, A, y,{"2D"});
    y:=y+dims(2);
  END;
  WAIT();
END;

D'où l'absence des affichages des premières lignes, car x>0 :


Le problème semble disparaître si l'on retire le mode 2D.

Et toujours impossible pour moi d'établir la moindre connexion USB.

Je viens de retester avec 3 souris différentes + 1 carte micro:bit v2 pour sa part bien détectée par le smartphone avec exactement la même connectique.

Voilà, pour le moment je ne trouve rien d'autre à dire.

L'ensemble des problèmes encore constatés en version 2.1.14549 vient d'être transmis à calcbeta@hp.com .

Pour la fonction round(), le codage en virgule flottante double précision fait que l'on n'obtient pas toujours le nombre de décimales ce que l'on demande.

Mais ce qui est curieux, c'est que l'on peut avoir des résultats différents sur HP Prime G1 et G2 :


Toutes les solutions Micropython/CircuitPython concurrentes utilisent le codage des flottants double précision et répondent comme la HP Prime G1.
C'est donc la HP Prime G2 qui sur cet exemple fait quelque chose qu'elle ne devrait pas...

Autre gros problème avec les versions bêta. De mémoire je l'avais déjà signalé puisque déjà présent dans la version Python bêta publiée par erreur 2019 ; mais dans le contexte que l'on sait ça n'a pas dû être reçu au bon moment.

En mode CAS on a la fonction print() pour afficher des valeurs à des fins d'information ou de debug :


Avec les bêtas Python, plus possible d'afficher la moindre valeur en mode CAS, aussi bien en écriture Xcas qu'en écriture Python :


En fait, il semble que la fonction CAS.print() a été marquée comme interdisant toute évaluation de son argument ; on peut mettre n'importe quoi même un eval() pour tenter de forcer l'évaluation, ça ressort tel quel :

Bonne nouvelle, quand on est dans l'application Python,

Shift

Plot

permet de configurer directement le heap et le stack :


Quand on a besoin de plus de stack/heap, plus besoin de passer par la fonction Python() et donc d'englobler son script Python dans un programme HPPPL !

La mémoire RAM actuellement disponible y est même indiquée.

Ils ont eu bien raison de copier le fonctionnement de l’application probabilité de la NumWorks
Autant j’ai plein de reproches à faire à l’application fonction de la NumWorks, autant l’application probabilité est juste parfaite.

Après, il y a trop peu d’utilisateurs de cette calculatrice en France, donc potentiellement peu de passionnés qui produiront du contenu de grande qualité, la plateforme HP n’a pas bcp d’avenir, mais ce n’est qu’un point de vu personnel.