Inflation quantitative 
dirais-tu qu’il y a déflation du prix de l’octet si 5Mo de plus dans le code te permette a terme d’avoir une BDD qui en fait 50 de moins ?
J’ai téléchargé et installé Duniter 1.7.7 .deb le 18/12 sur Ubuntu 16.04.
Synchro terminée au bout 45mn 
, impressionnant. J’ai depuis calculé plusieurs blocks et j’étais prêt à remplir le cahier de test en cochant toutes les cases pour l’interface graphique, à part les seuils de mémoire que je ne sais pas mesurer.
Mais 
je me suis aperçu ce matin que je ne calculais plus de blocks depuis le N° 181016, block que j’ai calculé et qui contenait une transaction (21/12/18 à 18H20) .
Après avoir relancé Duniter je lance la commande grep Done ~/.config/duniter/duniter_default/duniter.log
où il apparaîtrait que j’ai calculé le block 181035 mais ce n’est pas moi qui ai calculé ce bloc sur la branche courante (sûrement dans un forck !?)
Dans « Home », sur l’interface graphique, le N° de block courant est à jour et j’ai ça dans Network View
Un petit coup de main serait le bienvenu. Merci
En fait, je ne suis plus callé sur le block courrant dans l’interface graphique, je suis au 181035 (celui que je suis censé avoir calculé) au lieu du 181583. Je suppose que je suis sur un forck, dois-je attendre tranquillement?
J’ai pas vraiment compris,ma question porte plutôt sur le fait de savoir si tout ce qui est inclus dans le binaire correspond au strict nécessaire, ou si il y a du superflu, du code mort qui pourrait être nettoyé.
je troll mais aussi talentueux que soit Cedric je ne penses pas qu’il ait rajouter 5MO de code donc ça doit être dans les lib j’ai essayé de faire un diff de package.json mais je sais pas comment faire dans gitlab.
bonne chance et jme permet de faire un liens vers un autre probleme de taille. et oui ya des gens dont le but c’est d’avoir la plus petite !
GZip comparaison
2 Likes
Refait une synchro et c’est reparti !
mon noeud est en 1.7.7 avec bma d’activé. (sur G1, pas sur G1-test)
Cesium 1.2.9 tourne dessus, mais il y a visiblement des choses qui ne passent pas.
- dans cesium-web, pas moyen de s’y connecter, mais c’était déjà le cas avec duniter 1.6.25 :
Blocage d’une requête multiorigines (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur https://g1.1000i100.fr/node/summary. Raison : l’en-tête CORS « Access-Control-Allow-Origin » est manquant.Ça doit être un souci de config de mon reverse-proxy nginx. - dans cesium-desktop je n’ai plus que le DU quand je regarde mes transactions.
- dans cesium-desktop coté annuaire, c’est vide pour les nouveau membres.
C’est tout ce que j’ai constaté pour l’instant.
Aie. C’est une régression sur BMA. Les appels à /tx/history/<from>/<size> ne retournent rien. Une idée @cgeek ? Est-ce que l’historique est encore accessible en V1.7 ? je ne sais plus ce que tu m’avais dit.
cette fois c’est /wot/newcomers. Mais j’ai l’impression que ca fonctionne en v1.7.8
Ah oui, désolé. En fait c’est optionnel désormais et par défaut c’est désactivé pour libérer de l’espace et synchroniser plus rapidement. Je vais repasser g1.duniter.org en 1.6.25 demain, ça corrigera les lenteurs observées par @PiNguyen et rétablira aussi l’historique des transactions.
Avec la 1.7 il faut ajouter l’option --store-txs pour indexer les transactions des blocs synchronisés.
Oui. Régression sur l’indexation lors de la synchro également (comme /with/ud), mais corrigé en 1.7.8.
On me fait la remarque que la dernière release est la 1.7.7 sur le Wiki https://git.duniter.org/nodes/typescript/duniter/wikis/Releases
Petite remarque intéressante : avec le mode --store-txs la synchro prend littéralement autant de temps sur Nordstrom (16 coeurs, 32 go de ram) que sur mon serveur maison (Core2Duo, 2 go de ram)
J’ai lancé les deux synchro en meme temps, et elles progressent exactement à la même vitesse.
2 Likes
C’est le HDD qui est sollicité avec cette option. C’est aussi ce qui ralentit la synchro de la 1.6.
Petit rappel de chiffres :
~Volumétrie au 24/11/2018
1,582 devenus membres
13,719 certifications
354,236 sources de monnaie
15,211 transactions
Stocker ces 15,211 transactions, et notamment les indexer, ça sollicite le disque. Il est certainement possible d’améliorer cette procédure de stockage d’ailleurs, notamment il n’y a pas d’insertion en masse je crois.
2 Likes
Normalement @sveyret avait conçu cela de façon à ce que seules les releases estampillés stable soient publiés sur le wiki, cela se produit par l’éxécution manuelle du job “release” dans la CI, or @cgeek quelqu’un a éxécuté ce job sur plusieurs version 1.7.x alors que le cahier des tests n’est pas encore complet, il faudrait d’ailleurs de refaire de zéro pour la 1.7.8.
Je propose donc qu’on supprime les version 1.7.x du wiki tant qu’elles ne sont pas estampillés stable, comme cela avait été pensé a l’origine 
Je suis d’accord
Possible que ce soit moi lorsque j’ai joué avec les PR en voulant tester ce job release que j’ai lancé.
Je voulais savoir à quoi il correspond.
J’ai peut-être fait des releases ou cette modification vers stable a eu lieu.
1 Like
Ha autant pour moi, je croyais qu’il n’y avait que cgeek et moi qui touchaient a la CI de Duniter 
Je renommerai bien ce job en publish_stable pour que ce soit plus clair
2 Likes
On pourrait pas séparer en deux tâches ?
Une pour tester que ça package bien (ex: PR sur Node.js 10) et une autre pour tagger la release de stable ?
C’est déjà ce que fait le stage package non ?