C’est vrai qu’à l’allure où les certifications arrivent, ces prévisions n’ont parfois pas grand sens. Sans parler des dossiers qui passent tellement vite que je n’ai même pas le temps de les recenser. Et puis il y a des petits malins qui voient vite que leur poulain va se faire doubler et qui ajoutent une certication en catastrophe 
. C’est assez amusant à regarder, et ça me laisse penser que WotWizard aide à provoquer ce genre de comportements. Il n’est peut-être donc pas très fiable, mais est peut-être utile quand même.
4 Likes
Alors absolument, loin de moi l’idée de dire que ce n’est pas utile !
Comme tout, il faut connaître le fonctionnement et les limites un minimum pour l’utiliser à bon escient.
Et l’étourdi surpris n’aura qu’à poser des questions.
L’observation aurait-elle donc une influence sur la mesure ?
7 Likes
Absolument. Une des grandes découvertes de la physique du 20e siècle 
3 Likes
Bonsoir @elois. J’ai un problème à propos du dossier d’inscription de Maeve. Sur g1-monit, tu signales que ce futur membre n’a pas encore demandé son adhésion, ce qui est sans-doute vrai puisque son dossier ne passe pas. Mais j’ai beau regarder les données dans duniter.db, je ne vois rien qui le différencie des autres. Peux-tu me dire où tu vois qu’il n’a pas fait de demande d’adhésion ? Je donne ma langue au chat 
.
Oui c’est normal car cette donnée n’est pas relative a l’identité ni a la certification, tu ne verra donc rien dans les tables qui contiennent ses objets.
Les notions de “demande d’adhésion” et “demande de renouvellement” sont portées par les objets de type membership et se trouvent dans les tables sandbox_memberships et m_index.
Si une identité i en piscine a bien effectuée une demande d’adhésion, alors tu doit trouver au moins un enregistrement m dans la table sandbox_memberships pour lequel m.idtyHash == i.hash 
Merci beaucoup. Je vais corriger le problème.
J’ai signalé ce soucis à Maeve.
1 Like
Merci. Je corrigerai ce soir. Les prévisions reprendront après. Désolé pour la déconvenue.
J’ai enfin une version publiable de WotWizard. Cela se présente sous la forme d’un fichier WotWizard.exe qui contient l’exécutable pour un cadre d’applications qui permet d’ouvrir en son sein une fenêtre WotWizard affichant les prévisions et qui est mise à jour toutes les cinq minutes. Ce cadre permet aussi d’afficher le mode d’emploi, les documentations et sources des principaux logiciels utilisés.
WotWizard peut fonctionner sur Windows ou sur Linux avec Wine. Il doit être copié pour cela dans un répertoire vide, sur un noeud du réseau Duniter car il doit pouvoir accéder à la base de données duniter.db. Il produit aussi les prévisions sous forme de deux fichiers textes dans son répertoire (l’un trié par dates, l’autre par noms), eux aussi mis à jour toutes les cinq minutes, ce qui devrait permettre au noeud de les afficher sur une page Web.
Je suppose que le mieux serait de le publier sur Github et j’aimerais avoir quelques directives pour cela. Je peux aussi ajouter les sources et les docs au format texte en dehors du .exe.
2 Likes
Je t’ai invité dans l’organisation Duniter.
Tu devrais pouvoir créer un nouveau dépôt et publier ton boulot dedans.
1 Like
Je ne trompe pas ? Je dois bien prendre Duniter comme propriétaire de mon nouveau répertoire WotWizard, de façon qu’il soit dans Duniter ? Mais je n’ai apparemment pas les droits pour ça.
J’ai créé un dépôt vide https://github.com/duniter/WotWizard ainsi que la team GitHub du même nom. Tu as les accès administrateur sur ce dépôt.
Il te suffit donc de le cloner avec Git et d’y pousser tes modifications.
1 Like
Merci, ça ne va pas tarder.
Tu devrais pas mettre de binaire dans un dépôt git.
Ça allourdis le dépôt sur toute ça durée de vie car git n’arrive pas à faire de diff avec.
Cependant, tu peux mettre les binaires dans les releases GitHub.
1 Like
Merci. J’ai fait ça plus ou moins bien.
T’inquiète pas, je connais des gens dont l’informatique est le métier qui ont encore plus galéré que toi leur de leurs premiers pas avec Git 
5 Likes
J’ai la question suivante sur un détail de la gestion des dossiers externes de la TdC dans Duniter : si plusieurs dossiers ont des dates de disponibilité égales, ou différentes mais suffisamment proches pour être traités dans le même bloc, l’ordre de traitement est aléatoire pour ceux qui ont la même date ; est-ce que cet ordre aléatoire s’étend à tous les dossiers traités dans le même bloc, ou est-ce que ceux qui sont plus tardifs sont traités après les autres (et subissent donc une randomisation à part) ?
Oui, pour être plus précis : Lors de la création du contenu d’un bloc, on sélectionne tout les dossier déjà disponibles (dont la date de dispo est passée) puis on les mélange aléatoirement.
Ce qu’il faut comprendre donc, c’est qu’un dossier est toujours écrit après sa date de dispo, jamais avant.
Exemple factice :
dossier A dispo a 12h00
dossier B dispo a 12h02
dossier C dispo a 12h03
dossier D dispo a 12h05
Le noeud reçoit un nouveau bloc valide, il passe donc au bloc suivant et créer son contenu avant de calculer la pow, il se base sur le medianTime du bloc courant qui est 12h04 (le bloc d’avant était a 11h59): Il sélectionne alors les dossier A, B et C puis les mélangent aléatoirement. Le dossier D est mis de coté, il devra attendra un futur bloc.
2 Likes