Choix des technologies logicielles

Le seul outil logiciel fixé par le matériel est le choix de Linux pour le Raspberry Pi. Le reste de la pile système est entièrement libre, et les applications mathématiques sont à écrire pour la plupart. Voici un tour d’horizon des choix que nous avons faits pour développer notre calculatrice.

Système d’exploitation

Plusieurs possibilités se présentent pour le choix de la distribution Linux, parmi lesquelles Arch Linux et Gentoo, que l’on considère légères et personnalisables. Après discussions, c’est Gentoo qui l’emporte, ce qu’il doit à un niveau de personnalisation supérieur et au fait que Arch soit difficile à dissocier de systemd. Notre co-chef de projet Nicolas est également un utilisateur adepte de la distribution, ce qui a joué en sa faveur.

Le système Gentoo affichant les détails du pilote graphique.

L’inconvénient du Raspberry Pi Zero en termes de logiciel est qu’il utilise une architecture armv6l qui n’est généralement pas présente dans les dépôts binaires : il faut donc compiler tous les paquets. Ce n’est pas possible sur le Pi lui-même parce qu’il n’est pas assez puissant. (Surtout pour SageMath ! Et ce n’est pas faute d’avoir essayé.) Il y a donc deux options : cross-compiler les programmes depuis un ordinateur en x86_64 ou émuler un système hôte armv6l dans QEMU sur une machine robuste. Nous avons utilisé les deux.

Environnement graphique

On trouve ici le fameux dilemme X contre Wayland que nous avons rapidement tranché en faveur de Wayland, qui offre les compositeurs les plus légers. Cela inclut notamment sway voire rootston, le compositeur d’exemple de la bibliothèque wlroots.

Nos besoins en termes de composition graphique sont bas voire très bas pusique dans l’immédiat, nous n’envisageons qu’une barre d’état et une fenêtre en plein écran. Il existe des situations où avoir deux applications affichées en parallèle peut être intéressant (par exemple avoir des données statistiques sur la gauche et un graphe sur la droite), mais elles nous semblent toutes réductibles à l’utilisation de deux widgets partagés dans la même application.

Notre premier compositeur graphique sera certainement sway, que nous savons déjà utiliser et configurer ; mais il sera possible de l’alléger en jouant avec, quitte à monter un compositeur trivial si des besoins particuliers de performance ou mémoire se présentent.

Le plus dur restera de faire coopérer la carte graphique. Nous y reviendrons !

Interfaces graphiques

Les GUIs que nous allons construire ne sont pas très complexes comparées à ce que nos ordinateurs habituels supportent, mais elles sont quand même structurées. Il n’est pas question de dessiner directement sur une surface comme on pourrait le faire avec la SDL, par exemple.

Il faut donc choisir une bibliothèque permettant de mettre en page des widgets et capables de gérer les événements à un bon niveau d’abstraction. Les choix parmis les bibliothèques communes sont assez réduits : parmi ce que nous maîtrisons, on trouve essentiellement GTK et Qt. Pour esquiver la lourdeur de la programmation avec GLib et profiter des abstractions du C++, nous avons conclu sur Qt. Son IDE, Qt Creator, est également un bon point d’entrée pour toutes les personnes du groupe qui n’ont jamais programmé avec le framework.

Applications mathématiques

Notre idée initiale était de compiler pour la calculatrice SymboLibre une version réduite de SageMath pour lui laisser toute la partie calcul et résolution mathématique, qu’il n’est bien sûr pas question d’implémenter à partir de zéro. SageMath consitute un bon symbole de technologie libre et collaborative, et nous proposions de contribuer à son utilisation.

Seulement, la conception logicielle de SageMath se prête mal aux plans que nous avions pour lui. Le plus gros problème, et de loin, est que sa structure très monolithique nous empêche de le réduire à un noyau raisonnable. La bibliothèque n’étant pas pensée pour ce type de découpages, impossible de compiler sans les modules de théorie de groupes et d’algèbre linéaire avancée… de plus, il tourne encore en Python 2, ce qui nous obligerait à maintenir à la fois Python 2 et Python 3 sur le système.

Nous avons tout de même poussé le test à bout. Comme attendu, la quantité de modules complémentaires réduisent les performances à 1 minute 50 de démarrage et 170 Mo de mémoire consommés à blanc. C’est difficilement négociable, surtout qu’une seule instance peut tourner sur la calculatrice à chaque instant.

Nous étudions donc une alternative moins immédiate mais plus viable : Giac. La bibliothèque de calcul formel de Bernard Parisse fait partie des nombreux composants de SageMath, mais peut tenir seule les fonctions de la calculatrice puisque c’est le moteur utilisé par la HP Prime.


Voilà qui fait le tour de notre pile logicielle. Les GUIs ne sont pas encore assez peaufinées pour vous les présenter dès maintenant, mais nous y reviendrons !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *