Omega 1.23, ultime mise à jour compatible N0110 r3.43

by **critor** » 14 Nov 2021, 15:33

Pour cette rentrée 2021, de nouvelles calculatrices

NumWorks N0110

en révision matérielle

3.43

sont arrivées dans le stock des magasins.

Elles venaient préchargées d'une version

firmware

15.5

là où les révisions matérielles plus anciennes étaient venues en

11.2

.

Ces

NumWorks N0110 r3.43

n'étaient donc d'origine pas verrouillées, et tu pouvais tenter d'y installer par exemple le

firmware

tiers

Omega

.

Sauf qu'en pratique, cela ne marchait pas. Toute tentative d'installation d'

Omega

coinçait les

NumWorks N0110 r3.43

sur un écran noir avec la diode examen allumée en rouge.

Ne t'inquiète pas, rien de grave ni d'irréversible. Nous avons un tuto pour débloquer les machines dans cet état sans avoir à les verrouiller.

Bref, ce comportement signifiait que le

firmware

installé était incapable de s'amorcer correctement.

Nous venons tout juste de découvrir la cause de ce problème.

La révision matérielle

3.43

a changé la puce de mémoire

Flash

adesto

, passant d'une

25SF641

à une

25SF641

B

.

La nouvelle puce

Flash

25SF641B

est gérée par le

firmware

officiel

Epsilon

à compter de la version

15.5

.

Le problème d'

Omega

était que sa dernière version

1.22.1

publiée avant l'abandon du projet, était construite autour du code source d'

Epsilon 15.3.1

, et donc incompatible avec la dernière révision matérielle.

Nous t'avions déjà proposé la solution de passer au

firmware

tiers

Khi

, qui pour sa part reprenait le code source d'

Omega

et donc l'ensemble de ses fonctionnalités et à la différence continue à le faire évoluer, l'un des premiers ajouts ayant été la compatibilité

r3.43

avec l'intégration des changements apportés par

Epsilon 15.5

.

Mais peut-être que le

firmware

Khi

ne te convenait pas non plus ?

Bien qu'étant à ce jour le seul successeur d'

Omega

, le

firmware

Khi

était développé avec une philosophie très différente.

L'interface

web

d'installation du

firmware

Khi

et de ses applications n'a absolument rien à voir avec celle d'

Omega

, et le projet

Khi

à la différence n'est pas disponible sur

github

ce qui n'est pas l'usage pour les contributions.

Et bien bonne nouvelle pour toi si tu as été patient(e) et n'as pas commis l'erreur de verrouiller ta calculatrice depuis, l'équipe

Omega

s'est reformée le temps de pouvoir t'offrir une ultime mise à jour, la version

1.23

.

Le principal avantage d'

Omega 1.23

est d'être contruit autour d'

Epsilon 15.5

et donc d'être enfin compatible avec les

NumWorks N0110

en révision matérielle

3.43

!

Omega 1.23

t'apporte également quelques autres nouveautés.

Par exemple, l'interface

web

d'installation d'

Omega

t'offrait déjà quelque chose de très intéressant, la possibilité de signer numériquement ta calculatrice par un message de 15 caractères au maximum. Tu peux mettre ton nom, un surnom pour ta calculatrice ou bien d'autres choses entre autres, le message en question étant affiché à l'écran

à propos

comme on vient de voir. Un formidable moyen d'identification et donc une belle protection contre le vol.

Nouveauté, tes scripts

Python

seront désormais capables de récupérer ce message via la nouvelle méthode os.getlogin().

Ce n'est pas le seul ajout au module

os

, os.name te permettra aussi dorénavant à tes scripts

Python

d'itentifier facilement si ils tournent sur un

firmware

de type

Omega

, et donc de réagir en conséquence.

Autre ajout cette fois-ci par

Pixelpunker

, une amélioration de la traduction en Allemand des messages de la calculatrice, principalement dans la boîte à outils

Python

. Cela concerne des messages qui n'étaient pas traduits et restaient jusqu'à présent en Anglais, un affinage de la formulation pour d'autres messages, ou encore un raccourcissement de certains autres messages

(pour respecter la limitation d'affichage à 35 caractères)

:

Normalement tu devrais également pouvoir en bénéficier si ta

NumWorks

est verrouillée, car

Pixelpunker

a également soumis ces mêmes améliorations au projet

Epsilon

officiel, et elles ont apparemment été acceptées.

Enfin, le nouvel

Omega 1.23

ajoute la gestion des fonds d'écran sur le menu de sélection des applications !

L'installation d'un fond d'écran se passe

après

l'installation d'

Omega

sur l'interface web permettant d'installer les applications. Un nouveau bouton te permet d'ajouter l'image de ton fond d'écran à la seule condition qu'elle respecte le format imposé

(

PNG

en

320×222

pixels)

.

À noter qu'il ne s'agit absolument pas d'une reprise du développement d'

Omega

, les nouveautés en question ayant simplement été codées avant l'annonce de l'abandon du projet. Les développeurs souhaitaient simplement ne pas rester sur un travail inachevé et sont donc venus ce week-end te dire au revoir avec cette ultime version, la version parfaite incluant tout ce qu'ils avaient encore sous la main.

Merci à vous tous pour cette surprise inespérée et bon vent !

Installation

:

https://getomega.dev/install/latest

by **parisse** » 14 Nov 2021, 20:30

J'applaudis cette version compatible, je regrette quand meme un peu qu'il ait fallu attendre ce week-end, car j'imagine que cela a conduit au verrouillage d'un certain nombre de possesseurs du nouvel hardware.

Concernant les contributions qui seraient "moins faciles" pour Khi/KhiCAS parce que non disponibles sur github, je me permets d'exprimer mon desaccord. La difficulte pour contribuer a un projet ce n'est pas de savoir s'il faut faire une commande git clone ou tar xvfz pour acceder a un code source ou de savoir si les discussions se font dans un cadre formalise par github ou sur des serveurs discord ou sur des forums ou des newsgroup, etc. La difficulte pour contribuer, c'est de comprendre un morceau de code source, comment y corriger un bug ou comment l'ameliorer. Trop uniformiser les processus c'est aussi une source de danger a moyen ou long terme, par exemple en devenant tres (trop?) dependant d'un mode de developpement tres connecte et controle par le proprietaire de serveurs github ou discord.

by **critor** » 14 Nov 2021, 20:41

parisse wrote:J'applaudis cette version compatible, je regrette quand meme un peu qu'il ait fallu attendre ce week-end, car j'imagine que cela a conduit au verrouillage d'un certain nombre de possesseurs du nouvel hardware.

Je le regrette aussi. Certains ont dû perdre espoir depuis le temps, et d'autres ont dû verrouiller leur machine suite au blocage rien qu'en suivant la procédure de récupération du site officiel.

parisse wrote:Concernant les contributions qui seraient "moins faciles" pour Khi/KhiCAS parce que non disponibles sur github, je me permets d'exprimer mon desaccord.

Disons que ce n'est pas l'usage, et qu'en conséquence cela ne facilite pas.

Mais je note l'objection, j'ai remplacé le mot

facilite

en ce sens.

by **Hayleia** » 14 Nov 2021, 20:45

parisse wrote:La difficulte pour contribuer a un projet ce n'est pas de savoir s'il faut faire une commande git clone ou tar xvfz pour acceder a un code source ou de savoir si les discussions se font dans un cadre formalise par github ou sur des serveurs discord ou sur des forums ou des newsgroup

La discussion on s'en fout, elle se fait partout. Par contre l'argument ne marche pas pour les contributions. Le but de git (et github, etc) n'est pas juste d'avoir une source officielle du code, le but est aussi de pouvoir avoir deux personnes qui bossent en concurrence et de merge avec moins d'efforts, et d'avoir un historique pour gérer les régressions par exemple. Bref, ça compte clairement pour faciliter les contributions.

parisse wrote:La difficulte pour contribuer, c'est de comprendre un morceau de code source, comment y corriger un bug ou comment l'ameliorer.

Et justement, puisqu'il y a déjà cette difficulté, autant ne pas en rajouter une couche...

parisse wrote:controle par le proprietaire de serveurs github ou discord.

Euh ça osef 100% ? T'as qu'à host ton gogs si tu veux pas que ton repo git soit sur github ?

by **Adriweb** » 14 Nov 2021, 20:47

parisse wrote:La difficulte pour contribuer, c'est de comprendre un morceau de code source, comment y corriger un bug ou comment l'ameliorer.

C'est

exactement

pour ca qu'il devrait être le plus simple possible de comparer des branches de codes d'E15 / Omega / Khi / etc., pour pouvoir se concentrer sur le code et non pas rester bloqué à cause d'une désorganisation des outils/sources sur un fork dont l'auteur s'obstine à utiliser autre chose !

L'avantage sur git et GitHub (mais même d'autres, et aussi en local une fois cloné), c'est qu'il y a pleins d'outils (au choix, chacun sa facon de faire) pour pouvoir explorer les commits, branches, etc. y compris même intégré à son éditeur favori ; et donc plus facilement comprendre l'évolution du code, la correction de bug au cours du temps, etc.
Bref, faciliter la compréhension du projet et permettre bien plus simplement les contributions externes donc.

Un dump de sources dans une archive compressé, ben on perd tout le contexte et donc on se heurte à une différence supplémentaire vis à vis du projet original et de ses fork (omega en l'occurrence), c'est quand même bien dommage.

De manière générale, quand on fork un projet, on reste sur la plateforme hébergeant ledit projet, afin de faciliter les intéractions (notamments les PR). Que ce soit GitHub, ou autre (gitlab, bitbucket, etc. etc.). Et même quand on n'aime pas la plateforme (c'est mon cas avec gitlab, et pourtant je m'y force, pour certaines choses).

De toute facon c'est simple, comparons le nombres de propositions de modifications de code pour Khi (ou autre version d'avant) vs Omega.... Il me semble qu'il y a pas mal de PR (et de review collaborative etc.) sur Omega. Et je n'ose même pas parler des avantages des systèmes de CI automatisés que proposent GitHub et cie.
Elle est où, la transparence publique (revue collaborative, PRs, CI.) etc. pour Khi et autre ?

A un moment donné, il faut savoir reconnaître que l'on a tort, personne ne le reprochera, au contraire.

(Et au passage, il y a des "bridge" SVN->Git pour faciliter l'usage de l'un ou l'autre selon son habitude, si c'est ca qui coince)

En vrai je ne suis pas impacté par le problème parce que je saurais me débrouiller quand même avec un zip d'archive, que j'ai suffisamment de connaissances C++ etc, et aurait suffisamment de motivation pour outrepasser ces barrières artificielles.
Mais je n'ai plus vraiment le temps de m'intéresser à tout ca de toute maniere, donc je "lutte" (c'est un grand mot) par gentillesse/compassion pour d'autres qui ont moins d'experience/patience/motivation
Github leur facilite quand même grandement le travail. Et quelques petites modifs par ci par la, meme mineures, ca peut etre bien sympa (voire motiver davantage pour la suite pour de modifications plus conséquentes)

by **parisse** » 14 Nov 2021, 22:17

Je n'y peux rien si les habitudes de developpement qui sont efficaces pour moi sont differentes de celles de la generation suivante de programmeurs (vous verrez dans 10, 20 ou 30 ans comment vous arriverez a vous adapter aux nouvelles methodes!) Pour faire une analogie, travailler avec le shell de KhiCAS necessite un petit travail d'apprentissage de l'environnement par rapport aux apps de calcul sur calculatrice, de meme ajouter une contribution a KhiCAS necessite un petit travail car le processus est different de celui a la mode aujourd'hui.
Apres, je concois qu'il y a differents niveaux de contribution de code source. Celles que je trouve interessantes necessitent un investissement dans le code qui depasse nettement le petit travail d'adaptation dans le processus de developpement. D'ailleurs, l'historique des modifications des sources de KhiCAS est accessible via le git de geogebra.
Il me semble un peu etrange de juger de l'interet d'un projet par le nombre de contributeurs. ca devrait plutot etre sur les fonctionnalites. On verra bien dans quelques mois ou annees qui aura le plus avance, et dans quels domaines. Personnellement, ca ne me derange pas du tout de developper essentiellement seul, c'est comme ca que j'ai toujours developpe, ca m'evite de perdre trop de temps en palabres et ca a l'air de marcher plutot bien. En tout cas, pas de projet arrete a ce jour...