Forum TI-Planet.org

J'avance tout doucement sur le clavier, j'essaie de creer des correspondances avec les touches Casio pour me faciliter le portage. Je n'aime pas du tout le fait que la touche d'effacement soit inaccessible en mode alpha, si on se trompe d'une touche il faut faire au moins 4 frappes pour corriger (alpha backspace alpha alpha), souvent plus car on s'en rend compte plus tard...
De plus, il y a certains caracteres inaccessibles au clavier, par exemple ' (utilie pour la derivee) et # (pour les commentaires).
J'ai donc implemente:
- en mode alpha: effacement donne % uniquement en majuscules
- en mode alpha majuscules: la touche " donne '
On pourrait aussi avoir un 2eme caractere pour ?, !, ;, : en mode alpha majuscules, qu'en pensez-vous?
Il y a ensuite la gestion de cut/copy/paste (d'ailleurs inexistante dans le shell). Je ne vois pas d'interet a cut, vu que la touche d'effacement peut tres bien servir a ca. Du coup la touche pourrait servir a faire undo? (j'ai un niveau de undo/redo dans l'editeur d'expressions). Utilise-t-on copy comme un marqueur de debut de selection (equivalent de la touche CLIP des Casio dans l'editeur de programmes de KhiCAS).
D'autre part, il y a plein de touches qui n'ont actuellement pas de significations shiftees, par exemple les chiffres, ces touches ont un sens sur d'autres calculatrices, elles permettent un acces rapide a certains menus: par exemple shift-7 List sur HP, shift-1 LIST sur Casio. Ca vaudrait peut-etre le coup de faire pareil ici, vu que pour acceder a une fonction matricielle actuellement depuis le shell, il faut faire Toolbox>Calcul formel>Matrices, ce qui necessite 7 touches. Evidemment, on n'aura pas de legendes pour rappeler cette nouvelle signification, mais on conserverait bien sur la possibilite de passer par Toolbox... Qu'en pensez-vous?

parisse a écrit:Je n'aime pas du tout le fait que la touche d'effacement soit inaccessible en mode alpha, si on se trompe d'une touche il faut faire au moins 4 frappes pour corriger (alpha backspace alpha alpha), souvent plus car on s'en rend compte plus tard...

De mémoire ça fait partie des points abordés dans mon premier retour après avoir reçu le prototype N0200, et ce défaut (selon moi) ayant malgré tout été conservé il est mentionné dans le test.

J'ai régulièrement des saisies à corriger en Python.
Quand j'y pense, ça m'embête d'avoir à déverrouiller le mode alphabétique systématiquement avant la moindre correction, pour dans majorité des cas le reverrouiller immédiatement après. Cela casse mon rythme de saisie.
Et quand je n'y pense pas, ce qui est encore bien souvent le cas, je commence donc par empirer les choses, ce qui n'est pas mieux.

Dans les deux cas, ça me sort de la pensée algorithmique, ce qui est un défaut. Le clavier est là pour servir l'algorithmique et donc se faire oublier, ce qui n'est plus le cas avec la N0110.

Mais après tout... il suffit juste que quelqu'un nous sorte un firmware tiers qui supprime ce raccourci clavier.

Oui, c'est precisement ce que je vais faire avec delta.
J'ajoute aussi 2 commandes qui semblent manquer en programmation: Pause(t) (arret de t secondes, avec t un flottant) et get_key() qui renvoie un code numerique touche (le code ascii de la touche quand c'est possible, en tenant compte de shift et alpha). Ces 2 commandes fonctionneront aussi si on passe a l'evaluateur micropython avec la commande python.

Apres reflexion, il me semble que la place naturelle du % est la touche division shiftee, aussi bien du point de vue Python que du point de vue de la representation du signe de division, on le fait un peu pencher
Je suis aussi en train de redefinir shift-* en factor et shift-+ en normal, shift-- en \.
Il restera a definir des raccourcis pour shift-0 a 9 (probablement des acces directs a des menus).

Pendant que j'expérimentais dans le cadre des applications tierce-partie, je suis tombé sur ça: https://github.com/boricj/epsilon/commi ... c484e89704

Pour faire simple, au lieu d'allouer statiquement les données des apps, je les alloue sur le tas. C'est tout bête comme modification, cependant je passe de 62828 à 120 572 octets disponibles dans le tas sur master, soit quasiment le double. Je ne sais pas ce que NumWorks a fait depuis la dernière fois que j'ai regardé la consommation mémoire car y'a plus de tas qu'avant, mais la modification reste très pertinente.

Maintenant la mauvaise nouvelle: on introduit de l'allocation dynamique dans epsilon (qui n'en fait plus du tout maintenant) à des endroits assez critiques, chaque changement d'app faisant une paire libération/allocation de mémoire potentiellement substantielle, tout échec se traduisant par un reset brutal. Pour moi, par principe chaque app doit impérativement libérer toute mémoire allouée dynamiquement au moment où on la quitte pour toujours repartir d'un tas vide, afin de prémunir tout problème d'allocation mémoire. De ce que je crois savoir, ce n'est pas le comportement actuel de Delta avec giac, le risque d'un reset grandira donc avec le temps et l'allocation/fragmentation du tas... On peut limiter les risques dans un second temps (par exemple sérialiser/désérialiser l'état du contexte giac à la sortie/entrée de l'app dans une seule allocation dynamique pour "compacter" le tas), mais c'est à garder à l'esprit.

Pour ce qui est du commit, tenter de l'intégrer dans l'upstream risque d'être compliqué, NumWorks ayant pris la décision d'éviter au maximum l'allocation dynamique pour éviter tout problème. Même avec ces explications pour montrer que la méthode est sans risque en l'état, je ne sais pas si ça sera accepté...

Bien qu'on passe à un respectable 120 KiB de tas avec cette manipulation, on peut probablement gratter encore plus vu que le segment bss reste conséquent. Peut-être une investigation pour un autre jour.

parisse a écrit:Je n'aime pas du tout le fait que la touche d'effacement soit inaccessible en mode alpha, si on se trompe d'une touche il faut faire au moins 4 frappes pour corriger (alpha backspace alpha alpha), souvent plus car on s'en rend compte plus tard...

Je confirme c'est une horreur à utiliser avec les élèves.
Ils ont vraiment eut une drôle d'idée sur ce coup ...
Il n'avait qu'à mettre le % dans le catalogue en on en parlait plus. Sur la division comme proposé c'est encore mieux.

critor a écrit:De mémoire ça fait partie des points abordés dans mon premier retour après avoir reçu le prototype N0200, et ce défaut (selon moi) ayant malgré tout été conservé il est mentionné dans le test.

Ils se sont attaqué au problème des couleurs sur les touches ? Car le gris foncé / gris clair / jaune orange c'est pas lisible. Un bleu ou un vert bien intense pour remplacer le gris clair serait vraiment souhaitable ...

jean-baptiste boric a écrit:
Pour faire simple, au lieu d'allouer statiquement les données des apps, je les alloue sur le tas. C'est tout bête comme modification, cependant je passe de 62828 à 120 572 octets disponibles dans le tas sur master, soit quasiment le double. Je ne sais pas ce que NumWorks a fait depuis la dernière fois que j'ai regardé la consommation mémoire car y'a plus de tas qu'avant, mais la modification reste très pertinente.

Voila une modif que je vais tester rapidement! De toutes facons, si on utilise vraiment Khicas, on n'a plus guere besoin du reste, sauf de settings. Et le risque de reset existera quoi qu'on fasse si on lance un calcul
trop complique. En passant le tas au-dessus de 100K, ce risque devrait neanmoins etre faible, du meme ordre que sur la graph 90+e.

Réintroduire de l'allocation dynamique pour les données des applis, j'y avais pensé, mais je m'étais dit que ça serait trop compliqué (NumWorks a quand même passé du temps à la supprimer ) et je n'ai de toute façon pas véritablement le temps d'essayer. C'est bien de l'avoir fait

Lionel Debroux a écrit:(NumWorks a quand même passé du temps à la supprimer )

Oui, sans doute pas mal de temps, qui aurait pu servir a faire d'autres choses, par exemple, un procede de sauvegarde en flash. Sur Casio, Khicas sauvegarde son etat en flash a chaque fois qu'on change d'application, ce qui permet d'une part de ne pas tout perdre en cas de reset, et aussi de recharger l'environnement avec un tas tout neuf (par exemple sur le defi Python, si on parse le programme en syntaxe Python cela fragmente le tas, on gagne environ 20K en rechargeant).
La sauvegarde en flash pourrait aussi servir pour les scripts Python qui sont a l'etroit dans les 16K de RAM prevus a cet effet (et cela libererait 16K de RAM).
Maintenant qu'ils ont un certain succes sur le marche francais, j'espere qu'ils vont avoir suffisament de cash pour pouvoir integrer une puce avec plus de RAM pour leur prochain hardware dans 1 ou 2 ans, le plus tot serait le mieux.

parisse a écrit:

Lionel Debroux a écrit:(NumWorks a quand même passé du temps à la supprimer )

Oui, sans doute pas mal de temps, qui aurait pu servir a faire d'autres choses, par exemple, un procede de sauvegarde en flash. Sur Casio, Khicas sauvegarde son etat en flash a chaque fois qu'on change d'application, ce qui permet d'une part de ne pas tout perdre en cas de reset, et aussi de recharger l'environnement avec un tas tout neuf (par exemple sur le defi Python, si on parse le programme en syntaxe Python cela fragmente le tas, on gagne environ 20K en rechargeant).
La sauvegarde en flash pourrait aussi servir pour les scripts Python qui sont a l'etroit dans les 16K de RAM prevus a cet effet (et cela libererait 16K de RAM).

Ma question est surement très bête mais la RAM fait 256 ko, ils ne réservent que 16ko à Python, c'est ridiculement faible. Ils font quoi avec le reste de la RAM ? Je veux bien qu'il faille faire tourner l'OS, gérer les interactions claviers, etc mais aucune raison de réserver 240 ko de RAM pour ça ...

Je comprends que "sauvegarder son état en flash a chaque fois qu'on change d'application" est une solution pour la N0110 et ces 8 mo de mémoire, mais pour la N0100 c'est quand même problématique...