Débugger Duniter v1

Nodes Duniter-v1
,
1

Je voudrais débugger Duniter v1, en ajoutant des console.log() dans la méthode requirementsOfIdentity() pour trouver l’origine des lenteurs actuelles.

Mais encore faut-il réussir à faire tourner la requete (via un test d’intégration ou autre) sur la BDD de prod, non ?

As tu déjà débugger DUniter sur une BDD copie de prod ?

2

Non, je n’ai jamais utilisé d’outils de debug en None/TS. Avec des logs autant le compiler directement et l’exécuter comme en prod, non ?

3

Oui. J’ai essayé de compiler duniter, mais je n’arrive pas à lancer exécutable. Il ne reconnait aucune commande du CLI…

cd duniter
cargo xtask build
./target/release/duniter wizard bma

This upgrade requires resetting the data and resynchronization (duniter reset data && duniter sync).
2023-05-15T13:33:53+02:00 - error: This upgrade requires resetting the data and resynchronization (duniter reset data && duniter sync).

Et si je lance `reset data``j’ai la même erreur :

./target/release/duniter reset data
This upgrade requires resetting the data and resynchronization (duniter reset data && duniter sync).
2023-05-15T13:34:23+02:00 - error: This upgrade requires resetting the data and resynchronization (duniter reset data && duniter sync).

EDIT: le tuto de développement indique de lancer la commande :

node bin/duniter sync g1.duniter.org:443

Mais pas mieux : j’ai une erreur “SyntaxError: Invalid or unexpected token”

4

Sur la branche dev l’exécutable intermédiaire c’est bin/duniter_js. Il y a juste une chose en plus à définir : la variable d’environnement DUNITER_MODE.

Exemple :

image
image1414×696 50.3 KB

Oui c’est un bug de cette version pour ceux qui ont des données 1.8.
Il faut simplement supprimer son répertoire $HOME/.config/duniter/duniter_default manuellement.

La doc ne doit pas être à jour car sous le répertoire bin/ il n’existe que duniter_js désormais.
Essayes plutôt :

DUNITER_MODE=sync bin/duniter_js sync g1.duniter.org

Ça devrait suffire.

À noter que DUNITER_MODE ne prend que ces deux valeurs : sync ou start. Je n’ai pas creusé la différence mais par défaut c’est start, tandis que sync ne sert que pour la synchro.

1 Like
5

Moi non plus, c’est un bug que je constate depuis longtemps.

Pour la configuration de l’IDE, je ne fais rien de plus que ce que j’explique ici : Débugger Duniter v1 - #4 by cgeek

Mis à part que j’ai toujours une command npm run tsc -w en fond pour transpiler à chaque modification.

1 Like
6

cool. merci pour ta réponse ! :slight_smile:

7

Je penses avoir trouvé la raison de la duplication des tests sous WebStorm : c’est juste parcequ’il lance le test “.ts” ET du “.js”
Pour contourner, il suffit de changer le nom du fichier de test, en précisant “.js” au lieu de “.ts” :

image
image719×647 44.9 KB

2 Likes
8

@tuxmain pour réussir à modifier duniter-gva, je dois publier mes nouvelles fontions dans le module duniter-core.
Peux tu dire ce que je dois faire ensuite, pour que duniter-gva vois ma mise à jour ?
ce que j’ai fait :

  • modifier <duniter-gva>/Cargo.toml pour que duniter-core pointe vers le chemin relatif (…/duniter-core)
  • cargo build, dans les deux projets
    il y a surement autre chose à faire ?

EDIT: c’est bon, j’ai réussi à tout compiler. Les tests passent tous.
Je vais faire des MR pour duniter-core et duniter-gva

9

Comme les dépendances sont indiquées dans Cargo.toml par l’adresse du dépôt, il n’y a besoin de rien faire pour les mettre à jour.

Par contre en local il y a un cache. Pour le mettre à jour il faut faire cargo update, ou cargo update -p <crate>.

Pour développer en local on peut utiliser directement un chemin local, en décommentant la ligne patch : (ne pas oublier de la recommenter avant de commit)

[patch.'https://git.duniter.org/nodes/rust/modules/duniter-gva']
duniter-gva = { path = "../duniter-gva" }
1 Like