Valeurs exactes

[critor]

Merci. C'était une remarque générale qui ne te visait pas en particulier.
C'est l'impression que j'ai en lisant la liste des améliorations soumises : globalement à quelques rares exceptions près, de la dispersion dans des choses bien mineures/négligeables par rapport à certains manques.

Et Github permet de proposer des améliorations sans fournir de code, donc la complexité n'explique pas vraiment cette curieuse tendance.

On peut rajouter les conversions de bases et/ou constantes physiques comme demandé. C'est certes sympa mais quelconque et assez spécifique. Ce n'est sûrement pas ça qui suffira à faire changer d'avis les acheteurs non encore 'charmés', que ce soit dans un sens ou dans l'autre.

[parisse]

Il me semble aussi probable que numworks doit avoir sa branche de developpement privee, sinon le jour ou ils passeront au-dessus des radars des constructeurs traditionnels, ils auraient un desavantage strategique. Et ca expliquerait qu'il n'y ait essentiellement rien de nouveau depuis un mois.
C'est parfaitement normal que la communaute ne se lance dans rien d'ambitieux: la licence actuelle ne permet pas de partager son travail, meme gratuitement, et puis "life is short and rom is full", il n'y a pas assez de place pour faire qqchose d'ambitieux qui soit compatible avec les evolutions a attendre du systeme. D'ailleurs il me semble avoir vu un commit rendant les applis independantes, il faudra peut-etre choisir entre un tableur et un editeur Python. Sans parler du fait qu'avec des applis independantes au niveau du firmware, ca laisse peu d'espoir de pouvoir utiliser une fonction definie depuis l'appli fonction dans l'appli calculs ou suites.
En conclusion, ca fait vraiment beaucoup de choix strategiques de Numworks qui vont dans le sens contraire de ce qui me semble souhaitable, il n'y a donc pas de raisons de faire preuve d'indulgence pour cette calculatrice.

[Adriweb]

Les applications indépendantes (ie la bonne modularisation du code) c’est un principe de base extrêmement positif, et sur GitHub il est clair que tout le monde a été d’accord la dessus. NumWorks reprend le travail de JB a ce sujet. Mais justement, ça permet de choisir des applis et non obligé à le faire. (Une appli tableur ne prendra pas grand place d’ailleurs, quelques dizaines de Ko grand maximum selon moi, sachant que les composants requis sont déjà la sous d’autres formes)

En ce qui concerne le partage de variables ou d’autres, en fait ça n’a pas de rapport avec la modularisation, surtout qu’on parle pour le moment d’une modularisation au compile time. Il est parfaitement possible pour toutes les applis d’aller appeler une pool/table globale (partagée j’entends) de variables.

Mais bref, oui, les priorités niveau maths par exemple me semblent plus importantes, et je suppose qu’on va en voir arriver « en bloc » (cf. Le fait qu’ils aient un repo de leur côté, oui)

[Hamza.S]

applications indépendantes, ça a des avantages et des inconvénients.
j'espère que s'il y a un moteur de calcul exact ça ne sera pas sous une application indépendante, ça ne sera pas bon du tout.
(je vois déjà la même chose que sur la Casio Graph 100+, moteur CAS limité à une application. j'ai envie de dire c'est débile)

[Adriweb]

Non non mais je pense pas que vous saisissiez la teneur des changements : ce sont des « détails » de compilation de telle sorte que des applications de l’OS puissent être compilées ou non sans que ça casse le reste du code. Par exemple si toutes les applis sont choisies à la compilation alors il n’y aura strictement aucun impact utilisateur. On ne parle pas de rajouter des cloisons entre les applications, ça n’a strictement aucun rapport, au contraire.

[parisse]

Le fait que les applis puissent etre compilees separement ne va pas dans le sens d'une integration des applis entre elles. Bien sur, c'est quand meme possible de creer des liens entre applications, mais ca rend le code plus complique (par exemple avec des #ifdef en C/C++), plus difficile a tester (plusieurs configs a tester) et je ne suis pas sur que ca soit toujours possible (par exemple je ne sais pas faire un fichier source flex ou bison avec des #ifdef, or on peut imaginer que c'est ce qui permettrait d'utiliser une fonction f(x) definie dans l'appli fonctions ailleurs).
Quant au tableur, on verra, mais je suis sceptique sur une taille de quelques dizaines de Ko, en tout cas si on veut avoir un niveau de fonctionnalite minimum.

[parisse]

Les applications indépendantes (ie la bonne modularisation du code) c’est un principe de base extrêmement positif, et sur GitHub il est clair que tout le monde a été d’accord la dessus.

Je pense qu'il faut etre tres prudent sur la portee reelle d'un consensus entre personnes qui ont deja tendance a penser de la meme facon au depart. Je precise que je ne suis pas contre la modularite pour des applications peripheriques mais a mon sens il y a un pool d'applications centrales qui devraient etre toujours presentes.

[Lionel Debroux]

En effet, un certain nombre d'applications centrales devraient toujours être présentes. Notons que pour l'instant, on est encore assez loin de devoir en enlever:
* le firmware n'utilise la Flash interne qu'à moitié;
* il est montré qu'au moins un cinquième de cet espace utilisé est gaspillé en pessimizations taille (et souvent vitesse) diverses et variées (*);
* la modularité, indispensable pour les applications tierces, vient juste de commencer à arriver dans upstream, et il n'y a pas encore d'applications tierces;
* les barrières légales à la contribution vont affecter également les applis tierces.

*: https://github.com/numworks/epsilon/pull/62 gagne actuellement presque 68000 octets sur un peu plus de 526000 (plus d'1/8ème). Par ailleurs, Jean-Baptiste a fait remarquer, tout à fait à juste titre, que le stockage non compressé, non palettisé des bitmaps en 16 bits gaspille des dizaines de KBs. Pour quantifier plus précisément le gaspillage / gain possible, hier soir, j'ai instrumenté en local l'inliner d'icônes pour compter les pixels et les couleurs: le simple passage des icônes en 8 bits palettisé permettrait de gagner de l'ordre de 30 KB supplémentaires. En effet, même si la taille des palettes et du blitter simple utilisant une palette plutôt que des pixels bruts vient en décompte du gain, il y a plus de 10 images de plus de 3000 pixels.

LogoIcon: in 3948 pixels, found 225 colors, allocated 256, would need 8 bits for palette.
SequenceIcon: in 3080 pixels, found 38 colors, allocated 64, would need 6 bits for palette.
CalculationIcon: in 3080 pixels, found 63 colors, allocated 64, would need 6 bits for palette.
GraphIcon: in 3080 pixels, found 121 colors, allocated 128, would need 7 bits for palette.
SettingsIcon: in 3080 pixels, found 104 colors, allocated 128, would need 7 bits for palette.
StatIcon: in 3080 pixels, found 145 colors, allocated 192, would need 8 bits for palette.
Calcul1Icon: in 897 pixels, found 84 colors, allocated 128, would need 7 bits for palette.
BinomialIcon: in 665 pixels, found 2 colors, allocated 64, would need 1 bits for palette.
ProbabilityIcon: in 3080 pixels, found 244 colors, allocated 256, would need 8 bits for palette.
Calcul4Icon: in 897 pixels, found 88 colors, allocated 128, would need 7 bits for palette.
Calcul3Icon: in 897 pixels, found 86 colors, allocated 128, would need 7 bits for palette.
ExponentialIcon: in 665 pixels, found 41 colors, allocated 64, would need 6 bits for palette.
FocusedCalcul2Icon: in 897 pixels, found 86 colors, allocated 128, would need 7 bits for palette.
FocusedCalcul1Icon: in 897 pixels, found 77 colors, allocated 128, would need 7 bits for palette.
FocusedBinomialIcon: in 665 pixels, found 2 colors, allocated 64, would need 1 bits for palette.
FocusedCalcul4Icon: in 897 pixels, found 83 colors, allocated 128, would need 7 bits for palette.
FocusedPoissonIcon: in 665 pixels, found 2 colors, allocated 64, would need 1 bits for palette.
Calcul2Icon: in 897 pixels, found 87 colors, allocated 128, would need 7 bits for palette.
FocusedCalcul3Icon: in 897 pixels, found 84 colors, allocated 128, would need 7 bits for palette.
FocusedExponentialIcon: in 665 pixels, found 41 colors, allocated 64, would need 6 bits for palette.
FocusedNormalIcon: in 665 pixels, found 50 colors, allocated 64, would need 6 bits for palette.
PoissonIcon: in 665 pixels, found 2 colors, allocated 64, would need 1 bits for palette.
NormalIcon: in 665 pixels, found 54 colors, allocated 64, would need 6 bits for palette.
ExamIcon: in 162 pixels, found 49 colors, allocated 64, would need 6 bits for palette.
RegressionIcon: in 3080 pixels, found 146 colors, allocated 192, would need 8 bits for palette.
UniformIcon: in 665 pixels, found 3 colors, allocated 64, would need 2 bits for palette.
FocusedUniformIcon: in 665 pixels, found 3 colors, allocated 64, would need 2 bits for palette.
CodeIcon: in 3080 pixels, found 340 colors, allocated 384, would need 9 bits for palette.

La police de caractères doit être sujette au même genre d'optimisations ? Non, elle est déjà en 8 bpp.

[Adriweb]

Oui, même si en théorie il deviendrait possible de plus ou moins "tout" enlever si c'est 100% modularisé (au niveau applis présentes), je suis aussi d'accord sur le fait que conserver une base commune reste un minimum. Après sinon, ce n'est plus du tout une calculatrice graphique, mais bon, en fin de compte ça reste le problème des utilisateurs qui décident de tout enlever, le cas échéant ^^.
De toute manière, on peut imaginer que les builds officielles contiennent de toute manière l'intégralité des applis officiels par défaut, donc tout ceci ne s'appliquera pas pour la grosse majorité des gens. Pour les développeurs etc. par contre, ce sera très pratique de customiser à souhait ses choses.

[parisse]

Ca va sacrement restreindre si le modele de developpement necessite de modifier le firmware. Et je continue a penser que meme si aujourd'hui la moitie de la flash est dispo, elle se remplira vite, et que c'est triste de passer du temps a faire de la place a notre epoque.