Ğcli: Un client GVA en ligne de commande écrit en Rust

Liberté, ğcli ton nom !

5 « J'aime »

J’ai commencé à faire une commande pour afficher l’historique des transactions.

Je ne sais pas encore comment intégrer la pagination dans l’interface, c’est peu pratique de recopier le curseur dans la commande pour chaque page. Sinon un truc interactif qui avance d’une page à l’appui d’une touche ?

3 « J'aime »

Oui par exemple :slight_smile:

EDIT: Pour la gestion interactive du terminal je te recommande termion.

Le mieux est de pouvoir permettre aussi le retour à la page précédente :slight_smile:

1 « J'aime »

En fait l’affichage des transactions est très complexe, on ne peut pas se contenter d’écrire « X : envoyé/reçu Y Ğ1 », il faut gérer les conditions et les cas où on s’envoie à soi-même…

Une même transaction peut-elle apparaître à la fois dans sent et dans received dans GVA et BMA ? Comment Duniter choisit ?

1 « J'aime »

Non elle ne peut pas, un compte est inscrit comme receiver uniquement s’il n’est pas issuer, c’est fait ici :

Dans Duniter 1.9, le code javascript qui fourni l’historique des transactions n’existe plus, il a été migré en Rust. Donc BMA se base sur ce même code Rust donc elle fournit les mêmes données que GVA.

EDIT: cela implique notamment qu’une transaction de change n’a pas de destinataire, ce qui est cohérent :slight_smile:

2 « J'aime »

@tuxmain attention il faut que tu utilises both et pas sent ou received !

En effet supposons que tu veuilles afficher les 10 dernières transactions d’un compte.
Tu ne peux pas prendre les 5 dernières émises et les 5 dernières reçues ça ne fonctionne pas.
Un compte peut très bien avoir émis 8 transactions sur les 10 dernières et reçus 2, et vice-versa, où n’importe quelle proportion entre les deux.

Il faut donc fusionner les transactions émises et reçus dans ure seule liste, la triée par date d’écriture, puis tronquer à la taille de la page voulue. C’est exactement ce que fait both coté serveur pour vous éviter d’avoir à coder cette logique côté client !

1 « J'aime »

Oui c’est ce que j’ai fait sur Ḡecko et jaklis, pourquoi ne pas avoir fait ça aussi pour les transcations en mempool ? Un both ? C’est moins utile peut être ?

Il n’y a aucune raison, je n’y ai juste pas pensé, car c’est surtout pour la pagination que j’ai pensé both. Un contributeur pourra rajouter ça à GVA si c’est souhaité :slight_smile:

1 « J'aime »

3 messages ont été scindés en un nouveau sujet : Comment faut-il afficher les transactions complexes?

Pour le moment j’ai ça :

2020-10-17T08:16:16+00:00  #365512
8AURKq5gWeESdPzgqL2fJYFoJv89X2wiSsWbx8Am2W3w  + 2 Ğ1  Commentaire

2020-10-17T12:24:07+00:00  #365694
SIG(9oca3YvBuJBYdK5tdJESbT4tPVfxkDBtjGetU8jnkRpp)  - 204.6 Ğ1  Commentaire
SIG(45GfjkWCWQhJ3epJVGC2NSg1Rcu4Ue1vDD3kk9eLs5TQ)  - 123 Ğ1
Total: 317.6 Ğ1

Pour les txs reçues on affiche la liste des issuers.

Pour les txs envoyées on affiche la liste des scripts d’outputs. On ignore les outputs SIG(issuer). Les txs de change apparaissent donc vides. S’il y a plusieurs outputs, on affiche le total en bas.

Le commentaire est écrit à la fin de la première ligne d’outputs/issuers. Il y a une option pour afficher en DU.

Est-ce que vous préféreriez une forme tabulaire, comme dans Silkaj ? On pourrait aussi mettre des couleurs (rouge/vert pour dépense/gain, gris pour le numéro de bloc). Ou aussi afficher conjointement Ğ1 et DU.

Merci @tuxmain :slight_smile:

Puisque tu demandes des avis, voici le mien :

A titre perso je préférerai un tableau avec une vue condensée sur une ligne pour chaque tx. Et une possibilité de voir plus en détail une seule tx si on en a besoin :slight_smile:

3 « J'aime »

@tuxmain j’ai hâte que tu intègres la gestion de la pagination de l’historique à ḡcli, parce-que dans Ḡecko j’ai des artefacts étrange au bout de plusieurs pages, je voudrais être sûr que le soucis ne vient pas de GVA …

2 « J'aime »

@tuxmain je viens d’ajouter les conventions du projet dans CONTRIBUTING :slight_smile:

Le plus important est surtout de bien découpler l’affichage de la logique en créant un type AccountHistoryView qui contiendra toutes les données à afficher et un type AccountHistoryState qui contiendra «l’état» courant de l’application.

L’idée étant que les actions utilisateur (appui sur urne touche) mettent à jour le State uniquement. Puis que séparément, le State met à jour la View.

Ainsi tu peux injecter la logique dans des fonctions pure, donc testable :slight_smile:

Aussi pense bien à découper en plusieurs fichiers. Prends de temps de faire un code lisible, ça ne sert à rien de se presser :wink:

2 « J'aime »

J’ai fait une issue pour la commande tx-history, mais je n’ai pas le droit de me l’assigner.

Dans l’avis de licence, tu as laissé « either version 3 of the License, or (at your option) any later version », or dans Cargo.toml c’est « AGPL-3.0 », donc la licence est-elle AGPLv3 ou AGPLv≥3 ? Autoriser les versions ≥3 me paraît une faille de sécurité (c’est faire confiance aveuglément à la FSF et l’autoriser à retirer des restrictions de la licence du code).

Ce n’est pas prioritaire, mais pour que le client soit pratique à utiliser il faut qu’il supporte la panne du nœud Duniter par défaut. Pour ça il pourrait y avoir plusieurs nœuds par défaut, choisis au hasard à chaque exécution.

1 « J'aime »

Ok alors je pense supprimer la nécessité d’attribuer une issue, car une contribution doit pouvoir se faire sans avoir à demander des droits :slight_smile:

Tu as raison et si tu veux faire une MR pour ça je la mergerai.

L’idée est plutôt que l’utilisateur choisisse son noeud de référence au lancement de la commande. Il y a déjà une option -s qui le permet :slight_smile:
Je n’ai pas l’ambition de faire de ğcli un client p2p, ça me semble un peu overkill pour un client en ligne de commande . Mais si quelqu’un veut faire ça ok :slight_smile:

1 « J'aime »

Sans aller aussi loin que Sakia, juste en essayer plusieurs jusqu’à ce que ça marche. J’ai déjà tout ce qu’il faut dans ĞMixer pour ça (ça ajoute une boucle dans le client et un itérateur shuffle). J’ai toujours la flemme d’utiliser Silkaj à cause de ça, du coup je vais sur Cesium mais il ne gère pas ça très bien donc il faut attendre 30 secondes qu’il propose un autre nœud Cesium+…

1 « J'aime »

Donc pas de souci @tuxmain, implémente ce dont tu as besoin, tant que c’est propre, testé, lisible et maintenable :slight_smile:

1 « J'aime »

Est-ce que Gcli permet de générer des mnemonic et juste le sortie en output brut ?

Est-ce qu’il permet de générer un DEWIF avec code secret à partir de ce mnemonic ?

Si oui, des exemples d’utilisations ?

Non car personne ne l’a demandé. C’est rapide à faire, si tu en à besoin je peut implémenter la génération du mnemonic et du dewif. Le code Rust existe déjà, faut juste le «plugger» à ğcli :slight_smile:

1 « J'aime »

Oui ce serait super pratique pour énormément de choses ! :slight_smile: