Journal softs dev en Rust empaqueté pour Ubuntu & cie

Posté par  . Licence CC By‑SA.
Étiquettes :
29
11
sept.
2018

Voici quelques softs développés en Rust que j'aime utiliser et que je mets à disposition dans un PPA : https://launchpad.net/~jerem-ferry/+archive/ubuntu/rust/+packages

Ça manque sans doute de finition mais c'est fonctionnel.
Je viens de voir que ça commence sérieusement à s'y mettre sur Debian https://qa.debian.org/developer.php?email=pkg-rust-maintainers%40alioth-lists.debian.net

Ce qui est étonnant, c'est que leur process n'est pas le même que le mien.
Et surtout, ils ne s'attardent pas sur les mêmes softs donc ça peut être complémentaire.

Pour ceux qui sont intéressés par le process : https://forum.ubuntu-fr.org/viewtopic.php?id=2023943

  • # C’est bat !

    Posté par  . Évalué à 10.

    Plusieurs de ces commandes ont pour l’un de leur principaux avantages une sortie en couleur (pertinente).

    C’est bien, mais on lance la commande, le résultat dépasse la taille d’un terminal, on se dit qu’on va la piper dans un more ou dans un less en forçant les couleurs avec --color=always, et là, c’est le drame !

    less affiche les codes d’échappements. more affiche bien les couleurs (il se contente peut-être de les laisser passer), mais compte les codes d’échappement pour la longueur des lignes et coupe les lignes avant même la moitié pour une sortie d’exa !

    Là, je me dis « c’est con, les développeurs auraient surtout dû prévoir un remplacement de more ». Et puis, je me dis « sait‐on jamais, essayons bat »…

    Et bien bat fait le boulot de more (ils auraient dû l’appeler « bore » ☺)… mais en supportant correctement les couleurs !

    Accessoirement, il ajoute un cadre et des numéros de lignes, qu’on peut toutefois éviter avec l’option -p.

    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

    • [^] # Re: C’est bat !

      Posté par  (site web personnel) . Évalué à 6.

      N'oublies pas l'option -R de less pour les couleurs.

      Perso, j'ai dans mon bashrc:

      export LESS="-Rd"

      • [^] # Re: C’est bat !

        Posté par  . Évalué à 2.

        Bien vu. Habituellement, j’utilise more et je n’ai jamais dû lire le man de less (ou pas en entier)…

        Reste pour bat l’intérêt de permettre de parcourir un code source avec la coloration syntaxique et de sortir plus rapidement (q) qu’avec vim (ESC : q Entrée) ou emacs (Ctrl+X Ctrl+C).

        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

        • [^] # Re: C’est bat !

          Posté par  (Mastodon) . Évalué à 7.

          Tu peux aussi parcourir un code source avec de la coloration syntaxique en utilisant less.
          Mais ce n'est pas immédiat et nécessite un poil de configuration.

          En très rapide :
          Tu as une variable d'environnement LESSOPEN="|lesspipe.sh %s".
          Un script lesspipe.sh, sous Slackware il est dans /usr/bin/lesspipe.sh, dans le paquet less.
          Tous les contenus envoyés à less le sont d'abord à ce lesspipe.sh qui va faire un pré-traitement avant de laisser travailler less. C'est typiquement ce qui permet de voir le contenu d'une archive, d'une page de man. Celui de la Slackware ne va pas tellement plus loin que ça.

          Mais ce fichier lesspipe.sh peut permettre de faire de la coloration syntaxique.
          Typiquement tu utilises un autre lesspipe.sh, par exemple $HOME/.lesspipe, et tu mets export LESSOPEN="|$HOME/.lesspipe %s" ou l'équivalent en dialecte local dans ton init shell.
          Et tu modifies ton lesspipe pour faire passer tes fichiers source à travers highlight ou pygmentize.

          Ensuite less te fait automatiquement la coloration syntaxique.

          Tu peux aussi traiter les PDF avec pdftotext, et avoir le contenu texte d'un PDF avec less, etc.

          Mais je le concède, si ta distrib a pas géré ça pour toi, c'est assez ardu, il faut connaître, et même comme ça, la mise en place est pénible sans un lesspipe déjà tout fait.

          Yth.

          • [^] # Re: C’est bat !

            Posté par  . Évalué à 1.

            J'utilise activement LESSOPEN depuis plusieurs années. Un truc assez pratique, quand on a des fichiers chiffrés individuellement (c'était le cas à $PREVIOUS_JOB), on peut faire le déchiffrement avant de l'afficher dans less. J'avais des autocommandes dans vim pour faire la même chose (déchiffrement en lecture, chiffrement en écriture). Très pratique !

            bépo powered

    • [^] # Re: C’est bat !

      Posté par  . Évalué à 1. Dernière modification le 12 septembre 2018 à 20:53.

      j'aurais tendance à dire que bat c'est plutôt cat + less car on peut naviguer de page en page, aller au début ou à la fin du fichier avec les touches qui vont bien.
      C'est franchement un confort de ne pas réfléchir à la taille du fichier : avant de l'utiliser, ça m'arrivait de faire des cat sans le less et de pester derrière.

      Il faudrait sans doute proposer la même fonctionnalité aux autres outils que sont exa, fd, ripgrep.

      Pour rigrep, je ne faisais même plus gaffe mais j'ai ceci dans mon .zshrc :

      export LESS='-R'
alias rg='rg --pretty'

      • [^] # Re: C’est bat !

        Posté par  . Évalué à 8.

        cat + less

        Donc less en fait.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: C’est bat !

          Posté par  . Évalué à 0.

          Ben non (je me suis mal exprimé) : avec less, t'as un fichier de 2 lignes, t'es obligé de quitter quand même donc tu perds l'avantage d'un simple cat.

          • [^] # Re: C’est bat !

            Posté par  . Évalué à 3.

            Comme un less -FX, tu veux dire ?

            • [^] # Re: C’est bat !

              Posté par  . Évalué à 0.

              Faut croire… je connaissais pas !
              Mais pourquoi c'est pas le comportement par défaut (ou au moins dans les distrib) parce que je vois pas à quoi ça sert sans.

              • [^] # Re: C’est bat !

                Posté par  . Évalué à 3.

                Ça prends de la place sur ton terminal, c'est pas forcément cool. Tu peux voir garder à portée de vue le résultat des commandes précédentes.

                • [^] # Re: C’est bat !

                  Posté par  . Évalué à 0.

                  C'est vrai que mon utilisation est cloisonné sur de l'émulateur de terminal donc l'intérêt est moindre.

  • # cool !

    Posté par  . Évalué à 7.

    Merci beaucoup, super utile !

    La ligne pour installer le repo, j'ai bien mis 2 minutes à la trouver:
    sudo add-apt-repository ppa:jerem-ferry/rust

  • # Upstream ?

    Posté par  . Évalué à 3.

    As-tu prévu de pousser pour mettre cela dans les dépôts upstream ? (Y a-t-il moyen de collaborer avec les gens côté Debian ?)

  • # performances RipGrep

    Posté par  . Évalué à 3.

    Sait-on pourquoi RipGrep est plus rapide que grep ? Serait-ce le traitement des regex qui serait plus rapide ?

    • [^] # Re: performances RipGrep

      Posté par  . Évalué à 2.

      Sur le dépôt de fd, il y a une partie benchmarks qui conclut par :

      Concerning fd's speed, the main credit goes to the regex and ignore crates that are also used in ripgrep (check it out!).

    • [^] # Re: performances RipGrep

      Posté par  (site web personnel) . Évalué à 10. Dernière modification le 12 septembre 2018 à 13:49.

      On sait ;-)

      L'auteur de RipGrep a pondu un excellent article sur quels sont les spécificités d'un programme de type grep ainsi que les optimisations utilisées dans RipGrep qui le rend aussi rapide tout en comparant avec les choix techniques des autres greps (git grep, silver searcher, GNU grep etc.).

      Pour ceux qui ont la flemme de cliquer sur le lien, un petit one liner pour piquer votre curiosité :)

      python -c "import re; re.search('(a*)*c', 'a' * 30)"

      • [^] # Re: performances RipGrep

        Posté par  . Évalué à 2.

        Bien sur que je suis curieux.

        C'est vraiment sans appel :

        time python -c "import re; print(re.search('(a*)*c', 'a' * 30))"
None
python -c "import re; print(re.search('(a*)*c', 'a' * 30))"  506,43s user 0,39s system 61% cpu 13:43,80 total

        et le code équivalent en Rust (après compilation en release) :

        extern crate regex;
use regex::Regex;

fn main() {
    let re = Regex::new("(a*)*c").unwrap();
    print!("{:?}", re.find("aaaaaaaaaaaaaaaaaaaaaaaaaaaaa"));
}

        ça donne :

        time ./target/release/essai_regex
None./target/release/essai_regex  0,00s user 0,00s system 53% cpu 0,007 total

        J'ai mis moins 10 fois moins de temps à compiler + exécuter en rust.

    • [^] # Re: performances RipGrep

      Posté par  (site web personnel) . Évalué à 7.

      Oui, la bibliothèque des regexp est particulièrement bien optimisée en Rust et c'est une partie de la réponse. Mais il y a d'autres éléments. Par exemple, l'algorithme de recherche utilisé (ce sont des variantes de Boyer-Moore qui sont utilisés par tous les greps) est un peu plus poussé dans le cas de ripgrep : il fait une analyse rapide de la fréquence des caractères pour choisir un caractère peu fréquent à utiliser avec memchr.

      https://blog.burntsushi.net/ripgrep/ donne pas mal d'informations pour ceux qui veulent creuser le sujet.

      • [^] # Re: performances RipGrep

        Posté par  . Évalué à 5.

        Exact, j'ai également suivi le travail de Burntsushi.
        C'est lui qui est le principal dev de la lib de regex de Rust donc ripgrep est vraiment un proof of concept de sa qualité. (basé sur une machine à état fini)

        C'est effectivement édifiant de voir sa démarche jusqu'au benchmark : un savoureux mélange entre la mise en pratique d'un automate fini, de petites astuces pour gagner en perf, sa comparaison avec la concurrence etc.

        Y'a l'approche théorique pour un projet sain et le pragmatisme du dev.

  • # Un clône de coreutils en Rust

    Posté par  (site web personnel) . Évalué à 3.

    https://github.com/uutils/coreutils

    si tu veux l'ajouter à ta liste :)

    • [^] # Re: Un clône de coreutils en Rust

      Posté par  . Évalué à 3.

      Ça doit être plus compliqué à empacter sans générer de conflit.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Un clône de coreutils en Rust

      Posté par  . Évalué à 1.

      J'ai suivi ce projet aussi du coin de l'oeil mais plus d'un point de vue didactique. (comment vont-ils dev tel commande unix)

      Il n'y a pas encore de versionning : c'est pas un peu tôt pour en faire un paquet ?

      Je regardais dans les jours qui viennent ce que je peux faire ;)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.