D’autres petits changements intéressent, comme la conservation de la langue choisie lorsque naviguez d’une page a l’autre, c’est quand même plus confortable.
Il peut être intéressant d’utiliser pubkeyBalance pour vérifier que le pot commun “Remuniter” dépense bien la monnaie comme énoncé “0,05 Ğ1 / bloc”.
Notamment on voit dans les paiements Remuniter (pour ceux qui en reçoivent) qu’il rémunère tous les 500 blocs. On devrait donc avoir 500 x 0,05 = 25 Ğ1 par paiement.
la page pubkeyBalance ne charge plus aucune clé par défaut, pour vous éviter de devoir attendre le temps de chargement d’un compte par défaut qui n’est pas forcément celui que vous souhaitez consulter.
Pour consulter un compte membre, vous pouvez saisir directement un uid dans le champ pubkey.
Le pas (précision), se limite automatiquement de manière a ne pas a voir plus de 100 points, ce qui correspond à 16h actuellement.
Oui mais c’est difficile a voir car mélanger avec les dons. mais on voit bien par exemple le versement de 25 Ğ1 vers le 7/8 avril
Ça me donne envie de rajouter une option pour visualiser séparément les entrées (monnaie reçue) et les sorties (monnaie dépensée), là je suis sur autre chose mais je rajouterai ça bientôt
Je soupçonne un bug dans l’affichage :
Sur le graphique, on constate que le premier approvisionnement de ma clé date du 9/03, or j’ai commencé à utiliser cette clé uniquement fin Avril.
Peut-être que la première transaction est forcément comptée au bloc 0 ?
@florck oui j’avais remarquer en fait, il y a plusieurs autres bug liés a mon 1er algo que j’ai coder en début de semaine dernière et qui tourne actuellement en prod, en plus il est franchement moche et lent, mais mon but était dans un 1er temps d’arriver a le faire et surtout a comprendre le format des transactions et le concepts de sources.
J’ai refondu entièrement l’algo depuis zéro ce week-end, et ça fonctionne beaucoup mieux, mais je ne peut pas encore le déployer en prod car j’utilise un cache pour charger pubkeyBalance plus vite (chargement inférieur à 1,5 sec même pour des clés avec un gros historique !!).
Il faut d’abord que je vérifie que le cache se comporte correctement avec l’ajout de blocks et avec les fork réseau (dépilement) donc faudra patienter quelques jours
Ci-dessous ton compte avec le nouvel algo, est-ce ça te semble plus correct ?
Et ci-dessous pour @cgeek la balance de remuniter, on a bien un « inputs move » régulier à 25, bon faudra que je renomme ça parce que les inputs de la clé consultée correspondent en fait aux « dépenses ».
Marrant le dernier graphe, mais pourquoi voit-on toujours des mouvements négatifs pour Remuniter, même quand il ne fait que recevoir un don, ce qui devrait donc être purement positif (la courbe rouge devrait rester à zéro) ?
C’est un problème de parametrage de chartjs, qui essaye de tracer une courbe lisse qui relie tout les points, il faut que je passe en mode stepLine ce sera plus correct. En fait il n’y a un point négatif que tout les 2 jours, le reste du temps “inputs moves” est bien à zéro
Ca signifie que la certification fait référence à un bloc d’une branche et non de la chaine principale. Comme elles doivent faire référence à des blocs valides dans la chaine principal, le blockstamp est considéré incorrect
Cool enfin un fork réseau ! En fait, avant de déployer la nouvelle version, j’attend seulement que mon noeud de dev dépile sa branche lors d’un fork pour m’assurer que mon code de dépilement du cache se comporte correctement, cependant je ne sais pas si mon noeud dev-monit a changer de branche ou appartenait déjà à la branche qui s’est maintenue, @jytou ou quelqu’un qui garde un historique du réseau peut t’il me le dire ?
YoanSallami et @wyllyjon viennent de devenir les 36ème et 37 ème co-écrivains de la blockchain ğ1 respectivement aux blocs #19377 (12h13 17/05/17*) et #19446 (19h10 17/05/17*)
*temps blockchain
Déploiement de la version 0.3, seulement deux pages changent :
page pubkeyBalance/solde d’une clé :
refonte totale de l’algorithme
affichage des mouvements de dépenses et recettes sur chaque étape de la période (la longueur de l’étape dépend des paramètres step et stepUnit)
gestion totale des mauvaises valeurs de begin et end
solde correct quelque soit la valeur de begin
mise en cache pour un chargement plus rapide (moins de 3sec quelque soit l’historique de la clé)
reconnaissance directe d’un uid dans le champ pubkey
page membersCount/nombres de membres :
affichage du nombre de membres référents
affichage du nombre moyens de membres calculateurs de blocs sur chaque étape de la période (la longueur de l’étape dépend des paramètres step et stepUnit)
Notez que vous pouvez masquer des courbes en cliquant sur leur légende, le graphique adapte alors automatiquement l’échelle, exemple :
Bon j’ai visiblement un bug mystérieux que je n’avais pas en dev, je regarde les log, sachez que quand ça plante seul les pages membersCount et pubkeyBalance ne se chargent pas, les autres fonctionnent toujours !
EDIT; je crois avoir trouver l’origine du problème : d’après les log le bug surviens lorsque deux consultations des pages membersCount et pubkeyBalance se font presque en même temps, il faut que j’ajoute un verrou pour que le cache ne puisse pas être mis à jours par deux requêtes simultanées, je n’aurais jamais pu me rendre compte de ça en dev puisque je suis le seul utilisateur de mon noeud de dev. je vais essayer de déployer un correctif dans la soirée.
En attendant pour la stabilisé j’ai redéployer l’ancienne version en prod.
