Suivre

Hier j'ai utilisé la crate nom en c'est un combinateur de parseur pensé pour manger du texte octet à octet.

github.com/Geal/nom

D'habitude je plutôt avec des lexeurs/parseurs genre LALRPOP, Menhir etc, c'était intéressant comme approche et ça m'a permis de sortir découvrir un truc.

1/3

Merci à la personne qui a écrit ce formidable tutoriel: github.com/benkay86/nom-tutori

Suivre un tutoriel dispos sur le dépôt ou lire la doc sera très important!

Conseil: gardez cette page de la doc pour avoir vite une vue d'ensemble:
github.com/Geal/nom/blob/maste
2/3

Afficher le fil de discussion

PS: ami·e·s versées dans l'analyse des langages de programmation je sais qu’on connaît pas de façon démontrée le pouvoir d'expression d'un combinateur de parser.

Mais quand on a un tout petit format texte ou que notre format c'est du binaire, c'est déjà mieux que écrire à la main et il y a des outils pour le debugger proprement!

3/3

Afficher le fil de discussion

@darnuria
Merci pour ce tuto découverte de nom, très bien écrit il est facile à suivre. Du coup je suis pas sur de savoir quand une regex est mieux et quand un parser nom est plus indiqué 🤔.

Le tuto sur comment gérer les erreurs dans un code normal (pointé par l'auteur) est aussi génial. Pour une fois que c'est pas juste du « utilise anyhow pour une app et thiserror pour une lib » (remplacer par la/les crates du moment).

@Zykino Si tu sens que ta besoin de «parser» un truc structuré qui dépasse une «recherche+parsing» 90% du temps tu veux pas une Regex.

Tu veux de l'analyse de texte du coup:

- un generateur de lexeur+parseur (genre pour un langage)
- Nom + logique pour gérer ensuite

Ça depends de ton besoin ! Pour parser un seul pattern présent partout dans un document oui c'est bien une regex.
Un langage de prog -> Non
Un format de data -> Non

@darnuria
Ok donc pour le cas que j'ai en tête je vais garder mon fonctionnement avec une regex :
Je veux parser des noms de fichiers au format (text)?(nombre)(text, dont extension) pour normaliser le padding du nombre. Donc pour un album de musiques ou d'images faire en sorte qu'ils soient triés par numéro quel que soit l'explorateur de fichiers.

Ex:
1.jpg
10.jpg
2.jpg

->

01.jpg
02.jpg

@Zykino Pour un truc simple comme ça ouais ça peut suffir pense a construire ta Regex une seule fois avec `lazy_static!`. :)

Cependant attention c'est pas Rust qui va faire que c'est rapide car le gros truc lent ici c'est demander à l'OS les noms de fichiers puis les récrire.

Ça peut valoir le coup une fois que ta un programme correct de regarder si Async-std fait mieux que juste la version séquentielle avec attente de l'OS (std).

@darnuria Oui je me suis bien rendu compte que le goulot d’étranglement se situe sûrement au niveau de l’appel pour lister les fichiers et les renommer. Du coup je ne pensais pas utiliser `rayon`, ou alors pour faire des benchs.

Je ne comprends pas bien ce que `lazy_static!` peut m’apporter. 🤔 zykino.net/gitea/zykino/comic-

Mais j’ai tellement à faire/revoir. `String` de partout au lieu de `&str`, pas de test…

1/2

@darnuria Surtout un truc qui peut changer mon avis c’est que je veux rajouter la possibilité de choisir le préfixe : certains fichiers manga par exemples ont des noms de fichiers qui contiennent le numéro de la saison.
Titre-S2-Chapt7-5.jpg -> l’utilisateur ne veux pas trier par rapport au premier chiffre. Donc je veux leur laisser renseigner le préfix qui ne change pas d’un chapitre à l’autre.

Comme ton dernier lien : je fait fonctionner d’abord, j’optimise après.
2/2

@Zykino LazyStatic evite de reconstruire la RegeX a chaque appel on la construit une fois pour toute en "fausse globale". :)

@darnuria Mais du coup si je construit la regex qu’une fois puis itère sur toutes les valeurs (comme dans mon lien), `lazy_static` n’es plus si utile si ?

@Zykino ça va mais souvent on veux la Regex en global pour la praticité et Rust permet pas trop ça, si tu veux la passer dans les appels de fonctions ça va aller aussi. :)

@Zykino Lancer quelques threads peut aider mais ça risque de se jouer avec de l'async.

Thread ~= calcul: trucs qui nécessitent pas d'IO
Async ~= IO: Syscalls, Requêtes réseaux, Fichiers

Par défaut les API-IO/systemes de la std vont bloquer et rajouter des threads ça va quand même bloquer et attendre la reponse de l'OS.

L'async juste tu bloque, hop tu fait une autre requête et tu va continuer sur celles qui débloquent (c'est plus dur a faire qu'a dire).

En très gros, vu de loin :D

@darnuria Merci, je regarde ça dès que j’ai un peu de temps.
Je vois l’idée et effectivement async a plus de chance de m’être utile.

@Zykino Dans un premier temps correct, mono-thread et synchrone c'est déjà beaucoup et bien en 🤗

@Zykino PS: hésite pas a passer sur les canaux de discussions de la communauté pour avoir du retour! :D

rust-lang.org/community

@darnuria Oui c’est ce que je me dis. Il y a tellement à apprendre mais en tant que développeur pro je n’ai pas trop l’occasion de toucher à ces concepts (d’autant plus que l’env n’est pas en rust).

Je suis sur le discord mais il y a tellement de personnes que j’ai l’impression de devoir insister pour avoir des retours. Et la c’était dans la suite de la conversation.

-> je vais réfléchir à lazy_static pour passer la regex en global et pas planquée dans l’impl. Pas cacher une valeur hard-codé.

@Zykino Surtout que a chaque new de ComicBook tu recree une regex. Si tu crée une seule fois ComicBook ça va sinon c'est plus tendu \o/

Je sais pas trop si on peut utiliser une `const` expression car c'est quand même compliqué compiler une regex donc pas sur que le pouvoir d'expression des const-expr soit suffisant donc : lazy-static pour l'instant après je peux me tromper!

Bout de doc la dessus issu de la crate Regex:

docs.rs/regex/1.4.1/regex/#exa

@Zykino Mais ouai faut relaxer déjà coder, apprendre, se faire plaisir c'est important! :D

Inscrivez-vous pour prendre part à la conversation
Framapiaf

Le réseau social de l'avenir : Pas d'annonces, pas de surveillance institutionnelle, conception éthique et décentralisation ! Possédez vos données avec Mastodon !