Il s’avère que la condition limitante actuellement est le nombre d’itérations. Je vais donc me baser sur le nbre d’itérations effectuées par rapport au nbre max d’itérations pour afficher cette barre de progression.
EDIT : Mise à jour effectuée pour implémenter cette barre de progression 
si je voulais en faire une animation qui commence a l’instant 0 et non pas a l’instant t
comment devrais-je m’y prendre ?
cela avait déjà été fait. Le projet me semble pas maintenu et abandonné et je ne me rappelle plus qui avait fait ça. J’ai un screenschot mais peut-être que d’autres ont plus d’infos que moi. Néanmoins c’est toujours possible de le faire grâce aux timestamps enregistrés en BDD duniter
Pour ceux qui s’y connaissent un peu, des chercheurs en graphes m’ont parlé du “Label Propagation Algorithm” qui serait très efficient pour faire le calcul de détection de communautés. Apparemment, il y a très peu d’implémentation, excepté en Python et en Java (Je ne vous ai mis que deux exemples mais dans ces deux langages, j’ai trouvé d’autres implémentations). Or, ça fait deux jours que j’essaie de l’écrire en Javascript mais je coince 
: cela me retourne la même communauté pour tous les noeuds et j’arrive pas à trouver où est-ce que j’ai merdé.
Pour les habitués du Javascript, c’est par là que ça se passe.
J’ai réussi à implémenter cet algo sur des petits graphes… Mais pour la Toile de Confiance, ça boucle à l’infini 
Je sais pas si j’irai jusqu’au bout mais c’est intéressant. Pour les curieux, j’ai trouvé encore un autre algo de détection de communautés suite à la lecture d’un papier sur la comparaison entre différents algo. Il s’agit de l’agorithme LICOD
Je continue de faire un peu de R&D sur les graphes et je suis tombé sur cet article en français et plutôt complet.
Je suis en train de tester igraph en python Sinon, en java, y’a les chercheurs de mon Université qui développent le framework GraphStream
@tuxmain m’a fait un script en python pour générer le json de la wotmap afin de remplacer celui en PHP. Le but est de pouvoir interroger la nouvelle BDD duniter et, à termes, d’utiliser la bibliothèque igraph pour faire les calculs de communauté, de centralités et de position des nœuds côté serveur.
J’ai mergé son code puis ai fait 2/3 adaptations. Vous pouvez tester le résultat grâce au gitlab. @1000i100 : faudra que tu regardes pour le pipeline CI/CD (https://wotmap.duniter.io) quand tu auras 5min
Toujours dans le cadre de la R&D autour de la wotmap, je pose ça là :
PyGraphistry est une bibliothèque d’analyse de graphes visuelle qui permet d’extraire, de transformer et de charger de grands graphiques dans l’explorateur de graphes Graphistry (technologie basée dans le cloud).
Il supporte des graphiques exceptionnellement grands pour la visualisation interactive. Le moteur de rendu WebGL personnalisé du client restitue jusqu’à 8 millions de nœuds et liens à la fois, et la plupart des GPU anciens prennent en charge de manière fluide des éléments compris entre 100 000 et 1 000 000. Le moteur d’analyse OpenCL côté serveur prend en charge des graphiques encore plus volumineux.
J’ai ajouté une petite fonctionnalité à la wotmap mais qui m’aura pris presque toute la journée… Désormais, lorsque vous afficherez les liens (les certifications), le lien que vous survolez à la souris se mettra en surbrillance pour plus de clarté.
PS : @1000i100 : le CI/CD n’a pas fonctionné, je t’ai transféré l’erreur sur 1000i100 at tuta.io
Cette semaine, @tuxmain m’a aidé à importer la bibliothèque python-igraph pour le calcul de la position des nœuds et des communautés côté serveur.
Dans la liste des algorithmes proposés dans la bibliothèque python-igraph, on ne retrouve pas l’algo de Louvain pour les communautés mais, entre autres, l’algo LPA (“Label Propagation Algorithme”). Cet algo donne un résultat différent à chaque fois qu’il est exécuté et nous donne plus de communautés qu’habituellement (entre 40/45 communautés). Du coup, j’ai été obligé de repenser l’IHM. Désormais, un double-clic sur un nœud permet de n’afficher QUE la communauté du nœud (double-cliquez à nouveau sur noeud pour afficher à nouveau la toile en entier) alors qu’un clic-droit sur un nœud MASQUE la communauté du nœud. Dites-moi ce que vous en pensez
Pour la position des nœuds, la bibliothèque pyhon-igprah ne propose pas l’algo de positionnement de Gephi (ForceAtlas2) qui est, selon moi, le meilleur que j’ai trouvé pour afficher la toile de confiance de la June. Du coup, python-igraph pré-calcule la position des noeuds avec un autre algo et sigmaJS finalise le boulot. Il y a bien une tentative d’implémentation de cet algo en python mais il n’est pas terminé et je ne suis pas sûr d’avoir les compétences en Python pour l’intégrer au projet et le tester… J’ai regardé aussi du côté de la bibliothèque python NetworkX mais elle n’implémente pas non plus les algos que je souhaite utiliser.
N.B : je n’ai pas encore pushé le code sur le gitlab car j’attends qqes corrections de la part de @tuxmain 
L’interface est super comme ça ! Par contre c’est dur de lire les pseudos des petits nœuds, il faudrait une taille minimale pour le texte. Et aussi pouvoir zoomer avec +/- en plus de la molette ça serait pratique.
Pour info pour les autres : mon script trouve trop d’identités (un peu plus de 2000) alors qu’il est sensé ne prendre que les membres.
Edit: En fait c’est à cause des identités qui ont été membres mais qui ne le sont plus. Le problème : si on les met, il ça signifie que la wotmap ne liste pas que les membres ; si on ne les met pas, ça pose des problèmes puisque leurs certifications sont encore valides et doivent être représentées.
Re2·edit: wot_json.py qui prend toutes les identités, avec [“attributes”][“member”] qui indique si il est membre ou pas. Dans stats.json, total_nodes liste toutes les ids, total_members seulement les membres. total_noreferents ne compte que les membres non référents. Du coup il faudrait ajouter un figuré pour les non-membres dans l’interface, par exemple grisé ou hachuré.
Avant les vacances, je vous livre une nouvelle version de la wotmap grâce aux contributions de @tuxmain et de moi-même 
N’hésitez pas si vous avez des retours (bugs, améliorations). Je n’ai pas encore implémenté les demandes ci-dessus. Je verrai ça plus tard
Pour sa première version officielle, la wotmap passe en v0.10 sur l’adresse https://wotmap.duniter.org
Au programme :
N’hésitez pas à remonter les éventuels bugs que vous pouvez rencontrer ou vos idées d’amélioration. Le nouveau dépôt se trouve sur https://git.duniter.org/paidge/wotmap
Je cherche à automatiser le déploiement de la wotmap avec un fichier .gitlab-ci.yml inspiré de celui qu’avait fait @1000i100 :
stages:
- build
- publish
update-data:
stage: build
image: python:3.6.8-alpine3.9
script:
- wget http://g1.1000i100.fr/duniter.db
- mkdir -p /var/lib/duniter/.config/duniter/duniter_default/
- mv duniter.db /var/lib/duniter/.config/duniter/duniter_default/
- mkdir -p /var/www/wotmap/
- cp -r ./ /var/www/wotmap/
- python3 /var/www/wotmap/script/wot_json.py -d
- mv /var/www/wotmap ./release
artifacts:
untracked: true
paths:
- release/
only:
- master
pages:
stage: publish
image: python:3.6.8-alpine3.9
script:
- mv release public
artifacts:
untracked: true
paths:
- public
only:
- master
La méthode utilisée par @1000i100 ne permet pas d’avoir les données à jour puisque le script ne se lance que lors du git push. De plus, vu que la BDD de Duniter a changé de format, je ne vois pas trop comment faire pour importer les données dans le conteneur Docker. L’idée la plus pertinente qui me vient à l’esprit est de monter directement le dossier de la machine hôte (/var/lib/duniter/.config/duniter/duniter_default/data/leveldb/) dans le conteneur mais cette discussion sur Stackoverflow dit que ce n’est pas possible…
Est-ce que quelqu’un aurait une idée ?
EDIT :serait-ce une piste ?
Si, puisque le script se lance au git push ET peut être lancé sous forme de CI récurente, comme un cron, quotidiennement par exemple.
En revanche, effectivement, pour reprendre le principe que j’utiliser avec la nouvelle BDD, il faudrait exposer cette nouvelle BDD qui n’est plus en un seul fichier, en télécharger les éléments puis en extraire les info souhaitées.
Autre possibilité, maintenant que le sync est rapide : créer un noeud et faire une sync dans la CI.
@Paidge ce serait amusant de pouvoir jouer une animation avec l’évolution de la toile du premier bloc jusqu’à son état actuel, un peu dans ce genre là.
Par ailleurs, je me demandais pourquoi ton programme n’enregistrait pas la position des nœuds directement côté serveur pour éviter de calculer le layout à chaque chargement de la page.
En fait le programme côté serveur qui génère la liste des nœuds calcule déjà les positions, mais il n’est pas assez efficace. Du coup on recommence côté client avec une bibliothèque plus efficace. Le prépositionnement côté serveur permet tout de même de raccourcir la durée de calcul côté client.
Oui j’y ai pensé D’autant que le premier outil de visualisation web de la WOT montrait l’évolution de la toile au cours du temps. C’était écrit en PERL si je ne me trompe pas.
EDIT : Bah tiens, je viens de retrouver le code source.
Je pourrais ptet me pencher un peu plus sur la question mais est-ce vraiment d’une grande utilité ?