Discussions autour du developpement de duniter-rs (Duniter en Rust)

Je trouve ça curieux de mettre les tests dans le meme fichier que les sources. C’est une “bonne pratique” Rust ?

Oui. Les tests unitaires sont dans un module tests dans le module qu’on veut tester, et les tests d’intégration (s’il y en a) sont dans un dossier tests à côté de src.

Ca fait parti des bonnes pratiques, mais il est possible de mettre les tests dans un autre fichier (je viens de le découvrir).

C’est vrai que pour des modules assez long ça me semble une bonne idée, cependant je ne connais aucune crate qui sépare ses tests. Je vais faire quelques recherches, je te tiens au courant :slight_smile:

EDIT : Je viens de tester la solution et mes tests ne sont pas trouvés. J’ai du me tromper quelque part, mais il n’empêche que par défaut les tests sont dans le mod testé.

1 « J'aime »

Ok, ça a une certaine cohérence cette distinction “unit test” / “integration tests” :slight_smile: Ca me choque pas plus que ça !

2 « J'aime »

En plus vu que tests est un sous module de keys, il peut tester des fonctions/structures non publiques. Ca peut être utile si tu as une fonction interne assez complexe et que tu veux tester son comportement directement, et non ses conséquences dans d’autres fonctions.

De plus, si tu met des blocs de code dans ta documentation, Rust va les considérer comme des tests unitaires supplémentaires. Ca peut être un bon endroit pour mettre des tests simples.

J’avoue que des fois les fichiers sont un peu long, mais dans de grosses crates il y a aussi beaucoup plus de doc, ce qui aère pas mal le fichier et le rend plus lisible. Je pense rajouter un peu de doc d’ailleurs pour préciser les “cas d’erreurs”.

1 « J'aime »

En Rust tu as des macros qui permettent de faire du formatage de strings.

let a = 1;
let b = 2;
let c = a + b;

println!("{} + {} = {}", a, b, c);
let operation = format!("{} + {} = {}", a, b, c);

C’est la façon la plus simple de faire. Les accolade peuvent prendre des paramètres en interne pour définir le formatage. Par exemple dans blocks.rs, tu as

    pub fn to_hex(&self) -> String {
        let strings: Vec<String> = self.0.iter().map(|b| format!("{:02X}", b)).collect();

        strings.join("")
    }

Cette fonction itère sur chaque élément de mon tableau d’octet, le formate en hexadécimal à 2 caractères majuscules ({:02X}), collecte littérateur dans un Vec pour ensuite les concaténer.


Un des formatages est {:?} qui permet d’afficher des informations de debugage. Ce ce que permet de définir le trait Debug. Le trait Display quand à lui gère un affichage normal d’une variable.

Dans Debug je rajoute le nom de ma struct, comme ça si 2 types ont un contenu similaire, je pourrais les dissocier. Dans une cadre d’un affichage, je peux simplement afficher la valeur sans avec le nom du type. C’est ce que fait Display.

Tu remarquera que Debug utilise Display en ne passant que self dans

write!(f, "BlockUId ( {} )", self)

Après ce cas là est un peu spécial car on appellera jamais directement fmt. Cependant dans un autre cas où 2 fonctions de 2 traits différents ont le même nom, il y a une syntaxe pour lever l’ambiguïté.

Il faut noter aussi que pour utiliser une fonction définie dans un trait il faut use ce trait. Du coup si seulement 1 des 2 est importé, pas d’ambiguïté, et la bonne fonction est appelée.


Tu noteras donc qu’on implémente des traits pour adapter ses structures au langage. Il y a par exemple le trait Add qui permet d’utiliser l’opérateur +, ou Deref qui permet de déréférencer un pointeur intelligent.

1 « J'aime »

Par curiosité, quel site tu recommandes pour comprendre les bases de Rust ?

Si tu comprends bien l’anglais, fonce direct ici. C’est un peu la bible du Rust.

Sinon, il me semble qu’il y a un tutoriel sur le Rust sur developpez.com. Je l’ai à peine survolé donc je ne peux te garantir sa qualité.

3 « J'aime »

Le tuto de développez.com, que j’ai commencé paraît bien pour une vue d’ensemble, pour un dev averti et je pense suffisant. Après, je ne suis pas allé au bout et je ne suis pas dev… :wink:

1 « J'aime »

En aparté, Firefox ont sorti leur nouvelle version de Firefox qui utilise leur nouveau moteur de rendu écris en Rust, et qui profite grandement des architectures multi-cœur. J’avais même entendu parlé de l’utilisation du GPU pour le rendu des pages web.

1 « J'aime »

J’ai rajouté les documents Certification et Membership, et factorisé certains comportements. Ça devrait être plus lisible du coup :slight_smile: (j’ai aussi rajouté des tests sur les valeurs extraites des documents)

@nanocryk merci, je n’ai pas commencer le Rust mais il y a deux ateliers d’iniatiation au CdL auquels je vais participer ça va m’apprendre les bases :wink:

https://2017.capitoledulibre.org/programme/#introduction-a-rust

https://2017.capitoledulibre.org/programme/#clippy-un-linter-pour-rust

Le 2ème est sur le linter Clippy , tu connais ?

Je connais de nom, je vais aller le tester tout de suite :slight_smile:

EDIT : Hey j’ai que 6 warnings x)

1 « J'aime »

Alors j’ai suivi le tuto de developpez.com et je suis déçu je le trouve très mal fait, c’est incomplet et dans le désordre bref je déconseille…

En revanche j’ai commencé le rust book, (j’ai lu 4 chapitres sur 21) et il est vraiment très complet et très détaillé j’aime beaucoup, il part quasiment de zéro donc même quelqu’un qui a très peu programmer peu comprendre :slight_smile: (en tout cas les premiers chapitres)

1 « J'aime »

Ah ! Je ne l’avais pas lu, je vais jeter un coup d’œil.
EDIT : Je viens de regarder, en effet il me semble plutôt mauvais.

Ce n’est pas pour rien qu’on le surnomme la “Bible du Rust” :wink:

Je vais m’y mettre aussi, notamment car j’ai remarqué que noter « Rust » dans son C.V. (même à faible niveau) était remarqué par les recruteurs, or j’en ai rencontré une dizaine ces dernières semaines.

Le Rust semble avoir le vent en poupe !

2 « J'aime »

Haha. Il est assez réputé au niveau des utilisateurs, mais je ne savais pas que les recruteurs s’y intéressaient. C’est un très bonne chose de voir Rust se développer en entreprise.

Personnellement où je bosse il y a peu de chance qu’il y ai une “migration” vers Rust, même si je compte l’utiliser pour des projets où je serais le seul contributeur/reviewer.

Sinon si tu veux pratiquer ton Rust fraîchement appris, n’hésite pas à venir contribuer à duniter-rs xD

1 « J'aime »

C’est précisément cela : un intérêt pour les développements futurs, pas pour migrer du C/C++ existant.

À noter que ce sont surtout les recruteurs les plus techniques qui ont été intéressés.

Ce qui est bien avec Rust, c’est qu’il y a un inter-op direct avec du C/C++ grâce à l’absence de runtime/garbage-collector.

Pour mon implémentation du protocole actuel en Rust, je vais sûrement revoir la structure pour faire quelque chose de puis idiomatique et plus propre. Pour l’instant tous les documents sont gérés avec des HashMap : c’est bien pour la partie signature et parsing des documents textes, mais c’est vraiment pas ouf pour les manipuler ensuite. Il faudrait que je fasse des types de base pour les documents, puis que je fasse des types permettant de les transformer en documents signés suivant un certain protocole (actuel comme futur, texte comme binaire (DIP0002)).

@cgeek Ça serait bien d’avoir tes retours sur mon implémentation quand elle sera plus avancée. Sans que tu ai forcement à contribuer, tes connaissances sur l’implémentation de duniter-ts pourraient aider à vérifier que duniter-rs ne s’éloigne pas trop du fonctionne du premier, surtout que je ne pense pas creuser fichier par fichier dans l’original. Je vais reprendre l’architecture générale et (bien évidement) le protocole, mais je pense refaire le reste à ma façon :stuck_out_tongue:

J’y jetterai certainement un œil, oui.