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 ?
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 
@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 !
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é
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 
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
@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 …
@tuxmain je viens d’ajouter les conventions du projet dans CONTRIBUTING
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
Aussi pense bien à découper en plusieurs fichiers. Prends de temps de faire un code lisible, ça ne sert à rien de se presser 
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.
Ok alors je pense supprimer la nécessité d’attribuer une issue, car une contribution doit pouvoir se faire sans avoir à demander des droits
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
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
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+…
Donc pas de souci @tuxmain, implémente ce dont tu as besoin, tant que c’est propre, testé, lisible et maintenable
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
Oui ce serait super pratique pour énormément de choses !
@poka je viens de faire ça à l’arrache, regarde dans le README.
Pour l’instant gcli n’a pas de release, pour l’installer faut cloner le dépôt git puis compiler avec la commande cargo build --release. Le binaire final nommé gcli se trouve alors dans target/release
Il est désormais possible de faire un paiement simple avec ğcli 
:
$ gcli balance 5txe6XBBJQ6WaQS82upPT6FmM2mc5JcBW97dAjyMpwq6
The server responded in 181 ms.
The balance of account 'SIG(5txe6XBBJQ6WaQS82upPT6FmM2mc5JcBW97dAjyMpwq6)' is 2.86 Ğ1 !
$ gcli wallet pay 3 -a 100 -r Do99s6wQR2JLfhirPdpAERSjNbmjjECzGxHNJMiNKT3P -c "from gcli"
Mnemonic:
Sending 1.0 Ğ1 to Do99s6wQR2JLfhirPdpAERSjNbmjjECzGxHNJMiNKT3P from transparent account 5txe6XBBJQ6WaQS82upPT6FmM2mc5JcBW97dAjyMpwq6 …
Payment succesfully processed in 242.734 ms.
Je crois qu’il s’agit du premier paiement réalisé depuis un HD wallet
ğcli ne supporte que les HD wallet, vous devez d’abord en générer un avec la commande gci wallet gen.
Ensuite, récupérez une clé publique d’un sous-compte transparent avec la commande gci wallet pubkey. puis envoyez des sous sur ce sous-compte transparent via un autre client Ğ1.
Enfin, réalisez votre paiement avec la commande gci wallet pay.
Prochaine étape, les paiements depuis un compte opaque/brouillé, ça va être une autre paire de manches 
Je précise que ğcli est compatible DEWIF et qu’un HD wallet créé dans ğcli pourra être importé dans ğecko (et vice versa) via le mnemonic.
Bonjour,
Bravo pour les progrès
Est-ce que la commande gcli wallet pay est documenté ? à quoi correspondent les arguments ?
Là, je lis (sûrement de travers) que la commande est de payer 3 Ğ1 depuis un compte qui en présente 2.86
ou bien de payer 100 centimes de Junes ce qui fait bien un virement de 1 Ğ1 ? mais alors c’est quoi ce 3 ?