Je te propose qu’on se fasse un framatalk pour faire le point, ça aidera a faire un 1er dégrossissage 
Pour le reste, oui sur le gitlab 
Tu es disponible quand ?
Pour les framatalk, les soirs de semaine entre 19h et 22h, sinon les week-end.
Merci pour le framatalk ce soir, du coup voici ma première merge request pour le wizard 
Hésitez pas à me faire des commentaires avant que j’aille plus loin 
3 Likes
Nickel, ta MR est presque parfaite niveau écriture du code, j’ai juste 3 remarques a traiter sur des détails.
Par contre ta version de fmt n’est pas a jours il te faut la mettre a jours pour que la CI passe :
rm ~/.cargo/bin/cargo-fmt
rustup update
rustup component add rustfmt-preview --toolchain nightlyIl manquait un rm ~/.cargo/bin/rustfmt mais c’est bon à présent Par contre ça me fait un diff gigantesque relativement à la branche de dev.
J’ai un peu refactorisé le code pour pouvoir modifier la clé network et la clé member séparemment.
Normal le dernier commit sur la branche de dev était avant la mise a jours de fmt.
Pour qu’on y voit clair il te faut faire un commit a part juste pour les changements induits par fmt.
Arf je crains que ça me donne trop de conflits ingérables sur la branche ws2pv2 car j’ai refactoré cette partie aussi, je te demanderai peut etre d’annuler ça, on verra 
Tu n’utilises plus la structure DuniterKeyPairs? Car c’est ma seule interface avec la gestion des clés network et member.
SI je l’utilise toujours, faut que je check ton code si ça se trouve y aura pas de problèmes
Il va falloir mettre à jour la branche de dev avant de merge alors. Sinon le merge va être illisibile, ce serait dommage 
Ok je ne pourrais pas le faire avant ce soir, si tu veut tu peut pusher un commit fmt directement sur dev je te fait confiance 
@Inso merci pour ta contribution, c’est nickel mais un peu long a utiliser, je te propose de rajouter des options afin de permettre a l’utilisateur avancé d’aller plus vide en n’ayant pas besoin de répondre a des questions :
-m --member
-p --print
-c --change
Ainsi pour modifier la clé membre il suffira de saisir durs keys -mc et le programme devra proposer directement a la saisie du salt puis du password.
Et pour vérifier son trousseau il suffira de saisir durs keys -p ou durs keys -pm.
Pour converser une facilité d’utilisation, la commande durs keys sans option provoquerai l’échange de questions interactives que tu a codé, tu peut faire ça ?
2 Likes
C’est noté, je note ça pour quand j’ai du temps 
@elois pour faciliter les évolutions de Duniter et garantir son fonctionnement de version en version, j’ai produit des fichiers dits « snapshot » qui représentent l’état de la monnaie à un instant t représentant les index du protocole : https://git.duniter.org/c-geek/blockchain-archives
Si Durs arrive à reproduire ces fichiers, alors ce serait un bon indice que le code associé à la synchro est correct.
Les fichiers dont je parle se trouvent dans snapshots/g1 et snapshots/gt, sous forme de tarball (car sinon ça prend trop de place dans le dépôt), sous forme de 4 fichiers :
- mindex
- iindex
- sindex
- cindex
Pour Duniter la CI exécute systématiquement ce test, via les scripts :
- https://git.duniter.org/nodes/typescript/duniter/blob/dev/.gitlab/test/check_g1_sync.sh
- https://git.duniter.org/nodes/typescript/duniter/blob/dev/.gitlab/test/check_gt_sync.sh
En espérant que cela te soit utile.
2 Likes
C’est une bonne idée, faudra que je le fasse aussi pour Durs quand il sera plus mature, c’est encore trop tôt pour l’instant.
En tout les cas on ne pourra pas comparer car je ne produit pas du tout les mêmes index, le paradigme de structuration des données est radicalement différent.
Ce n’est pas gênant, je ne stocke pas non plus toutes les données d’index sous cette forme.
Néanmoins si Durs suit le protocole, alors il est en mesure de produire ces fichiers.
Cela dit tu n’es pas du tout obligé d’utiliser ces fichiers, mais ça pourrait beaucoup te rassurer, ainsi que les potentiels utilisateurs de Durs.
2 Likes