La NumWorks réinventée avec la N0110 - rentrée 2019

[jean-baptiste boric]

Je serais curieux de voir ce que ça fait d'allumer la led en rouge pétant avec la calculatrice d'ouverte. Est-ce que le guide serait tout rouge ?

Avec la coque ouverte, ça donne l'impression qu'il y a une rave party dans la calculette.

Ce qui m'étonne c'est qu'il a l'air transparent et pour moi pour pouvoir guider la lumière il faudrait justement que ça ne laisse pas passer la lumière

Si ça ne laisse pas passer la lumière, comment pourrait-elle traverser le guide depuis la LED jusqu'à sa destination? C'est le même principe qu'une fibre optique et la distance est suffisamment courte pour ne pas nécessiter une gaine réflective.

[matheod2]

Je serais curieux de voir ce que ça fait d'allumer la led en rouge pétant avec la calculatrice d'ouverte. Est-ce que le guide serait tout rouge ?

Avec la coque ouverte, ça donne l'impression qu'il y a une rave party dans la calculette.

Ce qui m'étonne c'est qu'il a l'air transparent et pour moi pour pouvoir guider la lumière il faudrait justement que ça ne laisse pas passer la lumière

Si ça ne laisse pas passer la lumière, comment pourrait-elle traverser le guide depuis la LED jusqu'à sa destination? C'est le même principe qu'une fibre optique et la distance est suffisamment courte pour ne pas nécessiter une gaine réflective.

Quand je disais qui ne laissait pas passer la lumière, j'excluais bien évidemment le début et la fin du guide

[parisse]

Un petit point d'info sur le portage de giac.
Pour l'instant je travaille sur le simulateur, pour la partie hardware ce sera plus tard, de toutes facons je n'ai pas de calculatrice pour tester.
Je pense faire un portage en 2 temps: d'abord modifier l'app Calculs pour la rendre formelle, en conservant l'UI en mode 2d. C'est plus simple, mais plus limite, car ca depend de l'interpreteur Numworks natif. Dans un deuxieme temps, on pourra envisager un shell plus complet en mode algebrique (1d) pour utilisateurs plus avances (comme KhiCAS sur la Casio graph 90).
Ca marche deja pas mal pour les commandes a 1 argument ou celles qui existent en natif





Il faut que je modifie le parseur natif Numworks pour gerer correctement les virgules et l'affichage des sqrt.
Je pense que je vais nommer l'association giac au-dessus de epsilon, delta, car pour tout epsilon>0 il existe delta

[Lionel Debroux]

Je pense que je vais nommer l'association giac au-dessus de epsilon, delta, car pour tout epsilon>0 il existe delta

Hu hu... bonne idée de nom

Le code d'epsilon a beaucoup changé depuis que zardam avait fait l'intégration d'une version plus ancienne de giac, donc c'est assez facile à comprendre que ce qu'il avait fait ne soit pas directement réutilisable.

[parisse]

Oui, a commencer par le parseur qui n'utilise plus bison mais est du code maison.
Ce qui m'inquiete le plus, c'est le support de la libstdc++ sur ARM. J'espere ne pas avoir a refaire ce que j'ai fait pour la Casio avec la ustl.

[Lionel Debroux]

D'une manière générale, surtout avec les toolchains modernes, la libstdc++ sur ARM est très bien. La lib C++ réduite actuellement intégrée dans epsilon ne contient peut-être pas tout ce qu'il te faut, mais même si tu devais la compléter, les sources d'origine pour ARM seraient de bonne qualité.

[jean-baptiste boric]

La libstdc++ intégré à la NumWorks est pour ainsi dire symbolique. Il faudra très certainement la remplacer par quelque chose de plus substantiel.

Prototyper en modifiant l'app Calculs est un bon début, mails il faudra s'orienter à terme sur une app dédiée. Je serais d'avis d'éviter de se reposer sur le moteur de calcul d'epsilon, le firmware n'offre aucune API stable et les apps tierce-partie ont tendance à rapidement bitrotter au gré des évolutions. Cela suppose d'écrire un parser/lexer pour construire l'AST du moteur de pretty-print et un serialiser pour générer des expressions compatibles avec giac depuis l'AST, mais ça sera bien moins compliqué que d'essayer de modifier directement poincare et surtout de rester à jour vis-à-vis des développements de NumWorks.

La calculette NumWorks dispose d'un mode algébrique (Settings > Writing Format > Linear) qui devrait ne pas poser de problèmes par rapport au moteur de calcul/pretty-print.

[parisse]

A terme, il vaudra peut-etre mieux une app completement independante, comme sur la Casio, mais ici je n'ai pas de shell Eigenmath comme base de depart, donc il y a nettement plus de travail a fournir pour avoir une UI qui tourne (le plus simple c'est peut-etre d'adapter a partir du source du shell de KhiCAS sur la Casio).
C'est pour cela que je prefere commencer par faire des modifs minimales sur l'UI de l'app calculs en concentrant le travail sur le portage hardware de giac, en prenant bien note de ce que je fais sur epsilon, pour pouvoir mettre a jour si necessaire. Le travail de zardam devrait pouvoir servir, ca devrait permettre de savoir comment gerer la libstdc++.
Ensuite, j'espere bien que si le portage hardware de giac+epsilon=delta se passe bien, les gens qui l'auront installe reflechiront a deux fois avant de repasser a un firmware Numworks sans CAS, meme si Numworks continue a ameliorer son propre code.

[parisse]

Je viens de regarder de plus pres le portage ARM fait par zardam (https://zardam.github.io/post/numworks-giac/) pour voir comment adapter a giac-1.5.0. Pas de problemes pour compiler libtommath. Pour giac, ca semble compiler en allant dans le repertoire src et en copiant config.h.numworks dans config.h et en faisant make -f Makefile.numworks (il faut ajouter -fpermissive pour compiler input_lexer.o). On obtient une libgiac.a, donc libraire statique, j'ai donc l'impression qu'il n'y a pas de problemes de libstdc++, on verra vraiment au link final.
Justement pour le linkage final hardware, j'ai essaye de voir ce que zardam avait modifie dans le epsilon de l'epoque, je vois dans le fichier ion/src/device/boot/flash.ld ce qui suit:

Code: Select all

...
SECTIONS {
    .giac : {
      . = ALIGN(4);
      *libtommath.a:(.text);
      *libtommath.a:(.text.*);
      *libtommath.a:(.rodata);
      *libtommath.a:(.rodata.*);
      *libgiac.a:(.text);
      *libgiac.a:(.text.*);
      *libgiac.a:(.rodata);
      *libgiac.a:(.rodata.*);
    } >EXTFLASH
...


j'ai l'impression qu'il n'y en a plus besoin ici, mais je n'y connais rien.
Le Makefile principal de epsilon a l'epoque contenait en plus:

Code: Select all

LDFLAGS := -L../giac-1.4.9/src -L../libtommath-0.39 -lgiac -ltommath $(LDFLAGS)


ca il va falloir bien sur faire l'equivalent pour PLATFORM=device uniquement dans scripts/config.mak.
Puis deux autres references a giac dans la suite:

Code: Select all

ifdef OBJCOPY
products += $(products:.$(EXE)=.hex) $(products:.$(EXE)=.bin)
%.hex: %.$(EXE)
   @echo "OBJCOPY $@"
   @$(OBJCOPY) -O ihex $< $@
%.bin: %.$(EXE)
   @echo "OBJCOPY $@"
   @$(OBJCOPY) -O binary -R.giac $< $@
%-extflash.bin: %.$(EXE)
   @echo "OBJCOPY $@"
   @$(OBJCOPY) -O binary -j.giac --gap-fill 0xff --pad-to 0x90800000 $< $@
endif


mais la je n'ai pas l'impression que ca soit necessaire de faire des modifs.

[Lionel Debroux]

Oui, c'est tout à fait crédible que certaines de ces modifs, en particulier celles du script linker et du Makefile pour séparer .bin / -extflash.bin, ne soient plus nécessaires pour la N0110: (presque ?) tout est dans la Flash externe.