Trop bien
Oui bien sur je déduit les paramètres a partir du genesis bloc
Trop bien
Oui bien sur je déduit les paramètres a partir du genesis bloc
Appel a testeurs disposant d’un raspberry pi (je n’en ai pas encore), j’ai besoin de quelqu’un pour tester le bon fonctionnement d’une release cross-compilée via docker, @jytou peut être ?
j’ai mis a jours le tuto, c’est la méthode 1 qu’il faut tester :
https://duniter.org/fr/wiki/duniter-rs/cross-compilation-pour-arm/
Si ça marche je me servirai de cette méthode pour les livrables officiels, une fois que vous avez copier le binaire tout en un sur votre raspberry, voici comment tester :
Assurez vous d’avoir un noeud duniter-ts synchronisé sur votre raspberry puis lancez la commande :
./durs sync_ts
Si la sync ce passe sans erreur, lancez votre noeud :
./durs start
Vous devriez voir des connexions WS2P s’afficher dans l’interface du terminal, puis des HEADS si vous attendez suffisamment longtemps
Notamment assurez vous que dans la liste de vos connexions vous en ayez de temps en temps quelques unes en 443.
Si vous vous amusez a laisser tourner de longues heures ils se peut que le noeud plante ou se désynchronise, c’est normal c’est encore une alpha, il n’y a cependant aucun risque car c’est un noeud purement passif, il ne transmet aucune information sur le réseau a l’exception de son propre head, ce qui ne peut en aucun cas perturber le reste du réseau.
EDIT : @jytou au cas ou tu aurai déjà exécuté durs par le passé sur ton raspberry il te faut préalablement supprimer le dossier de config :
rm -rf ~/.config/durs-dev
La documentation du code de Duniter-Rust est publiée via la CI gitlab ici :
Il est désormais possible de désactiver n’importe-quel module dans la configuration (code générique).
Par exemple pour désactiver le module tui (Interface graphique dans le terminal) :
durs disable tui
Vous pouvez également lister tout les modules :
$ durs modules
tui (disabled)
ws2p
Ou lister uniquement les modules activés :
$ durs modules -e
ws2p
Enfin pour réactiver un module désactivé :
durs enable tui
La configuration est sauvegardée dans le fichier ~/.config/durs-dev/default/conf.json
. Il ne faut pas modifier ce fichier a la main, car a la moindre erreur duniter-rust ne démarrera plus, utilisez la ligne de commande, l’aide est votre amie :
durs --help
\o/ pu**** je suis plutôt fier de moi, 2 grosses avancés aujourd’hui :
Pour le point 1, je vais avoir besoin de quelqu’un sous window pour vérifier que le binaire final fonctionne bien, @nanocryk peut-être ?
Pour tester:
Télécharger l’artifact ici : https://git.duniter.org/nodes/rust/duniter-rs/-/jobs/7787 (cliquez bouton download)
Extraire l’archive puis dans work/bin/ extraire la 2ème archive qui contient durs.exe
Ouvrir une console windows
Exécuter directement durs.exe en testant quelques commandes :
durs.exe --help
doit afficher l’aide.
Si vous avez un noeud duniter-ts synchro sur votre windows vous pouvez tester la sync :
durs.exe sync_ts
Vos retours me serait très précieux, merci
Pour les curieux, l’image docker est là : https://git.duniter.org/docker/rust/win64-builder
Je vois que tu touches encore beaucoup en profondeur au code de WS2Pv2.
Tu vois des tasks durs simples et qui demandent pas trop de temps ?
J’aimerai bien prendre 1h ou 2 par ci par là pour coder un peu en Rust quand je trouve du temps…
Ce que je vois de plus simple :
Si besoin on peut se faire un framatalk un soir pour t’aider a te repérer dans le code
Est-ce que pour les commandes tu utilise la magnifique crate structopt
?
Sinon je me remettrais bien à contribuer un peu, tu as quelque chose chose de sympa à me proposer ?
Non je ne connaissais pas celle-ci, cependant j’utilise déjà la crate clap
sur laquelle se base structopt
donc a mon avis il devrait être relativement facile de migrer toutes les commandes sous structopt
, voila par exemple une contribution qui peut être sympa pour toi
Super, ça serait un plaisir de faire un peu de structopt
Quel avantage de cette crate relativement a Clap ? Je trouve ca hyper élégant les commandes dans un yaml …
Autrement pour le wizard, j’ai quelques questions :
tui
ou à conf
?termion
pour développer le code du wizard. Est-ce que ça vous parait être une bonne idée ou est-ce qu’une autre crate semble plus adaptée ?Alors battez vous jusqu’a e que mort s’en suive
Blague a part, je n’ai pas d’avis sur ce point, c’est vrai qu’avoir les commandes dans un yaml c’est plus facile et ça fait un point de repère pour les nouveaux contributeurs. Du coup @nanocryk quel sont tes arguments ?
Ca dépend quel wizard. Le wizard key concerne le coeur qui a forcément un trousseau. Par contre je ne prévois pas de wizard network car cela concerne les différents module.
Il serait plus propre que chaque module injecte lui même ses sous commandes de configurations. Ce qui donnera par exemple des commandes comme ws2p config
et gva config
. Mais l’injection c’est un peu compliqué donc je te suggère de te limiter déjà a wizard key dans un premier temps
La crate tui n’a pas a gérée la conf, c’est un module optionnel dont le seul role est de servir d’interface “graphique”. Il te faut utiliser la crate conf en association avec la crate core, comme je l’ai fait pour les commandes enable/disable qui permette respectivement d’activer/désactiver un module.
Pour le code du wizard pas besoin de termion, c’est comme prendre un semi remorque pour aller chercher une bagettte
On n’a pas besoin d’effets de console particuliers, juste de pouvoir récupérer une saisie de salt et password.
Tu défini des structures avec de la documentation classique et des annotations, et les commandes sont automatiquement générées avec la vérification des types, des options, etc. Du coup tu déclare tes structures, tu appelle structopt
et tu optiens ta structure remplie si tout est bon, ou une aide générée s’il y a des erreurs (voir le README de la crate).
Du coup tu n’as besoin de connaître que le Rust et pas le YAML (alors que le format de config “officiel” de rust est le TOML), et tes structures sont autodescriptives et évite de faire manuellement tout traitement et vérifications de la ligne de commande.
Ca c’est déjà le cas actuellement avec clap. On ne vérifie pas manuellement la ligne de commande.
Donc les “gains” de structopt vs clap seule sont faibles. Quand au YAML c’est le format que j’ai choisi mais clap supporte aussi le TOML donc la aussi ce n’est pas un argument recevable.
Ceci étant structopt réduit les sources de bug car avec clap quand je match si la commande toto a été saisie le compilateur ne peut pas vérifier si toto est une commande existante, donc des erreurs de frappe peuvent se faufiler.
Donc si ça te fait plaisir fait le
Yeap, on pourra en débattre dans la Merge Request
Et puis bon, si ça me permet de me remettre un peu à contribuer à durs alors que je suis celui l’ayant initié à la base xD
@nanocryk j’ai quand même une question : est ce que structopt permet l’injection de sous commandes par des plugins ? De sorte que le coeur qui déclare la Struct ne peut évidemment pas connaitre les sous commandes injectés. Parce que ça clap seule sait le faire, et c’est un besoin !
Aucune idée, ça sera l’occasion de le découvrir.
Je sais que l’on peut gérer les sous-commande avec une Enum
, mais peut-être qu’il est possible de les “injecter” manuellement.
Aïe ça sent pas bon. Il faut que chaque plugin puisse injecter sa sous-commande (au moins une, elle pourra elle même contenir autant de sous-commandes que nécessaire). En lisant la doc de structopt je ne vois rien a ce sujet, si l’injection n’est pas possible alors il nous faudra rester sur clap seule.
Le fait que ne sache pas (car je ne l’ai jamais fait) ne veux pas dire que ce n’est pas faisable. J’ai vu notament que l’on peut récupérer la structure clap générée par structopts, donc on peut peut écrire du code pour les “combiner entre elles”.
En effet je viens de voir les fonctions clap et from_clap dans la doc,( je n’avais pas encore eu le temps de tout voir) donc on peut injecter les clap::App des différents plugins, donc tout est parfait
EDIT : Pour l’injection faudra modifier le trait DuniterModule (que je doit d’ailleurs renommé ,en DursPlugin) pour y ajouter une méthode retournant une clap::App. Et faut que le core appelle cette méthode pour chaque plugin pluggé afin d’agréger les Clap::App. Tu te sent de le faire ?