Visualiser la proportion de chaque version de Duniter parmi les membres forgerons

elois · 16 June 2020 17:49

Je ressentais le besoin d’avoir un outil qui me donne la proportion de chaque version de Duniter parmi les membres forgerons.

Un tel outil serait très pratique pour voir à quel point une mise à jours est déployée ou non, ce serait également très utile pour anticiper les changements de protocole;

Jusque-là j’essayais de l’évaluer a la main en couplant Remuniter, Cesium et les head ws2p mais c’est long, chiant et pas très précis.

N’ayant pas envie d’y passer du temps, je me suis dit que le mieux était d’utiliser du code existant qui permet déjà de récupérer la fenêtre courante ainsi que les HEADs WS2P. Je me suis alors rappelé que @vit avait intégré dans DuniterPy de quoi récupérer les HEADs WS2P.

J’ai donc décidé d’essayer de coder mon besoin dans silkaj, sachant que je n’ai jamais fait de python j’ai pris 4h pour faire ce qu’un dev python aurait plié en 30min mais bon j’ai ce que je voulais :

$ silkaj -p g1.librelois.fr smiths
Current frame: 33 issuers [166 blocks (#331240 to #331405)]

1.8.0: 19 smiths [57.58 %]
1.8.0-rc1: 2 smiths [6.06 %]
1.8.0-beta5: 1 smiths [3.03 %]
unknown: 2 smiths [6.06 %]
1.7.21: 9 smiths [27.27 %]
|       uid        |   version   |   blocks_on_frame |   diff |
|------------------+-------------+-------------------+--------|
|      elois       |    1.8.0    |                13 |    109 |
|       moul       |    1.8.0    |                13 |    517 |
|     ji_emme      |  1.8.0-rc1  |                12 |    210 |
|     pafzedog     |    1.8.0    |                11 |    108 |
|    KumaNinja     |    1.8.0    |                11 |    720 |
|   chronophonix   |    1.8.0    |                10 |    107 |
|    b_presles     |    1.8.0    |                 9 |    209 |
|     Fabwice      |    1.8.0    |                 9 |    107 |
|     Attilax      |    1.8.0    |                 7 |    208 |
|  Julien_Jardin   |    1.8.0    |                 7 |   2248 |
|    Matograine    |  1.8.0-rc1  |                 6 |    105 |
|  ThomasBourdon   |    1.8.0    |                 6 |    208 |
|      Tchois      |   unknown   |                 5 |    104 |
|      Damery      |    1.8.0    |                 5 |    104 |
|      Thatoo      |    1.8.0    |                 5 |    104 |
|    fdrubigny     |    1.8.0    |                 5 |    104 |
|     moricef      |   1.7.21    |                 4 |    103 |
|     DamageCo     |   1.7.21    |                 3 |    306 |
|     ofontes      |   1.7.21    |                 3 |    102 |
|      paidge      |    1.8.0    |                 3 |   1122 |
|      cgeek       |    1.8.0    |                 3 |    306 |
|      FredB       |   1.7.21    |                 2 |    102 |
| jeanlucdonnadieu |   1.7.21    |                 2 |    408 |
|      Bizou       |    1.8.0    |                 2 |    102 |
|     brouits      |    1.8.0    |                 2 |    102 |
|     tuxmain      |    1.8.0    |                 1 |    102 |
|       poka       | 1.8.0-beta5 |                 1 |    102 |
|     1000i100     |   unknown   |                 1 |    102 |
|    Mententon     |   1.7.21    |                 1 |    102 |
|     Guenoel      |   1.7.21    |                 1 |    102 |
|      Spyou       |    1.8.0    |                 1 |    102 |
|      janhsh      |   1.7.21    |                 1 |    102 |
|      LenaB       |   1.7.21    |                 1 |    102 |

Pour ceux qui veulent cette commande, elle est sur la branche smiths_command : https://git.duniter.org/clients/python/silkaj/-/commit/9a33175a00d159ae37742053dd33f6965bf93503

Moul · 16 June 2020 19:48

Pour ma part, je fais une recherche Firefox sur la vue réseau de l’administration web de Duniter pour avoir le nombre de nœuds en v1.7.21 et ceux en v1.8.0. À partir de ça, j’ai une idée des proportions sur tous les nœuds connectés :

Mais, ton outil est plus précis et vise que les identités dans la fenêtre courante, ce qui est idéal pour monitorer l’évolution pour un changement de protocole !
Une contribution de qualité pour une première dans l’environnement Python

elois · 18 June 2020 15:49

@Moul il y a peu être eu un quiproquo

Je ne souhaite pas me mettre au python ni contribuer a silkaj, je déteste les langages non typés et ces quelques heures de python m’ont rebuté.

C’est juste que j’avais un besoin et que je cherche le moyen le plus rapide d’y répondre, je l’ai fait en python car silkaj et duniterpy couvrait déjà 70% de mon besoin, y a avait plus qu’à assembler d’une certaine façon on va dire.

J’ai partagé le code, mais je ne souhaite pas retravailler dessus, si tu souhaites intégrer cette fonctionnalité ce sera à toi de retravailler ce code comme il te convient, tu peux aussi ne pas l’intégrer ça m’est égal

Moul · 19 June 2020 13:47

Comme tu veux. J’ai vu que tu as ouvert une demande d’intégration (merge request), du coup, j’ai compris que tu souhaitais l’intégrer.

Je comprends ce que tu veux dire, tu veux utiliser un langage à typage statique et surement fort.
Mais, notion pour les lecteurs, Python est fortement typé, contrairement au JS qui a un typage faible.
Pour prendre l’exemple du JS de l’article suivant, en Python il n’est pas possible de concaténer une chaîne de caractère (string) et un entier (integer), ce qui donne une erreur.

Après, oui, c’est du typage dynamique qui a ses avantages et ses inconvenants à la fois.

elois · 19 June 2020 18:13

J’aimerais bien que ce soit intégré oui, mais je ne souhaite pas y consacrer du temps

De mon point de vue le typage devrait être statique par défaut et dynamique seulement sur demande être seulement dans les cas ou c’est vraiment nécessaire.

On peut faire du typage Dynamique en Rust, je l’ai déjà fait et je n’hésiterai pas a le refaire si besoin, mais pour moi ça doit être l’exception et non la règle.

Je ne suis pas d’accord avec cette affirmation. Comme le montre l’article wikipedia que tu cites, il n’y a pas de définition claire de ces termes flous que sont “fort” et “faible”.

Disons que c’est relatif a quoi on compare. Mon echelle personnelle du degré de typage ressemble plutôt à ça :

pas typé : Js
faiblement typé: Python
Moyenne typé : Java
Fortement typé: Rust

Je suis désolé mais quand je manipule un dict c’est beaucoup moins typé qu’une HashMap<ed25519::Pubkey, IssuerInfo>. je ne sais pas quel est le type des valeurs contenues dans le dictionnaire.

De mon point de vue un langage fortement typé est un langage dans lequel :

Toutes les variables et leurs sous-composant/propriétés sont de type connu
Le type d’une variable ne peut contenir que des données que le métier accepte.

Exemple : stocker une clé publique Ed25519 dans une String, pour moi ce n’est pas fortement typé. Une String random ne correspondra pas forcément a une clé publique valide (ce n’est même quasiment jamais le cas).

Outre le typage, j’ai aussi personnellement un problème avec l’absence d’accolades et la délimitation des blocs de code par l’indentation, je trouve ça beaucoup moins lisible et plus facilement sujet à erreurs, mais c’est un goût personnel.