karchnu a écrit 393 commentaires

Ce que tu dis est la raison pour laquelle je trouve magnifique les langages fonctionnels.

fib 0 = 1
fib 1 = 1
fib x = fib (x - 1) + fib (x - 2)

Le code de chaque condition particulière est séparé complètement du reste.
Chaque cas est visible d'un coup d'œil, même sans être trop réveillé.

J'ai toujours beaucoup apprécié Perl pour ce genre de raccourcis.

C'est sa plus grande qualité et son plus grand défaut à la fois.

L'objectif était de montrer qu'il était possible de publier n'importe-quoi qui allait dans le sens des préjugés des relecteurs. L'expérience a fonctionné.

Tu minimises le nombre de publications. 3 et 4 rétractées ? Oui, c'est bien 7 publications donc. Le fait qu'une publication ait été rétractée parce qu'ils ont compris après coup la supercherie ne compte pas : les papiers sont bel et bien passés. Ils n'avaient rien de scientifique, et ils sont passés. C'est un fait. Et oui, c'est grave. La relecture par les pairs peut laisser passer des bêtises parfois, mais pas à ce point anti-scientifique.

Cracher sur ce résultat à cause de ce qu'a fait Lindsey par la suite est un sophisme de déshonneur par association. Cela ne remet en aucun cas en cause le résultat de leur travail.

Merci pour toutes ces précisions !

En fait je pensais au PDF parce qu'on peut assez facilement changer la taille des colonnes (avec roff et tbl ou hdtbl, LaTeX, etc.). Cela rend le tout plus clair, même sans séparateur de lignes plus imposant.

Et ce serait possible de faire également avec le HTML, c'est un élément de style, mais pour ça il faut outrepasser le Markdown et écrire le code HTML et CSS directement.

La proposition reste intéressante, je pense.

Je ne connaissais pas ce programme. Noté ! Merci !

Je viens de voir que mon test était foireux. Je suis un boulet. Oublie ce que j'ai dit sur fmt. :D

Mon test (test-fmt.sh) en version corrigée montre bien qu'on coupe à 65 caractères :

#!/bin/sh

seq() { echo "for(i=0;i<$1;i++) i" | bc ; }

generate_data() {
        # Écrit 65 caractères, terminant par "X"...
        for i in $(seq 64) ; do
                v=$(echo "$i % 10" | bc)
                echo -n "$v"
        done
        echo -n "X"

        # ... puis ces caractères suivants :
        echo -n " 1 3 4 6 8 Y"
}

generate_data | fmt | tr " " "~"

Ce script produit le résultat suivant :

0123456789012345678901234567890123456789012345678901234567890123X
1~3~4~6~8~Y

Dès que fmt a pu (à 65 caractères, son goal), il a coupé.

Markdown c'est tout nul pour les gros documents.

Je suis bien d'accord !

Après, vu la taille de ce que je publie, j'écris tout dans un fichier texte avant de poster pour ne rien perdre au cas où il y ait un plantage ou que je doive attendre avant de poster (pour faire des corrections, par exemple). Ça me fait faire plein de copier-coller, c'est assez pénible, mais c'est indépendant de Markdown.

---

Pour en revenir au propos, il y a de tout et cette commande n'est pas POSIX… J'aurais du indiquer « 75/72/70 » au lieu de « 72 » ; ou alors « 75 » qui est la valeur des implémentations les plus couramment rencontrées ?

Je ne sais pas. En tout cas, à l'usage, je vois que fmt coupe à 72 et pas avant. Si j'ai une ligne de 80 caractères ou plus, c'est au caractère 72 qu'il coupe. Si le goal est de 65, il pourrait couper avant, je lui en laisse l'occasion.

Donc soit il y a un problème dans la page de manuel, soit je n'ai pas compris ce que sont le goal et le maximum.

---

Ce journal remet certaines commandes en contexte.

Ça fait du bien de savoir d'où viennent les commandes disponibles sur nos systèmes. Je ne connais que trop peu la très grande majorité des commandes qui me sont disponibles, et encore moins leur utilité initiale. Je compte 2724 programmes sur mon système, c'est colossal et je n'ai pas la moindre idée de ce à quoi servent peut-être la moitié d'entre eux.

Je suis d'accord avec l'article que tu as cité, ainsi qu'avec les articles que lui-même cite, Unix était très lié au langage lui-même. Nos systèmes actuels sont très fortement liés, encore aujourd'hui, au langage et c'est un élément un peu trop oublié de nos jours.

Je m'explique. Dans Unix et ses dérivés plus modernes, un paquet de commandes introduisent leur propre langage : dc, bc, sed, awk… la liste est longue. À chaque fois, c'est un nouveau langage qu'il faut apprendre, mais c'est également un langage adapté à ce qu'on cherche à faire, lié à un usage. Et ça, c'est magnifique. Pour moi c'est toute la beauté de l'approche Unix : une tâche = un outil, voire un langage. Ce n'est malheureusement pas assez exprimé de cette façon dans les explications sur Unix, pourtant cela fait sens.

Et quand on comprend ça, ça fait d'autant plus détester les outils modernes qui veulent tout réduire à quelques langages de programmation, là où la diversité des approches permettaient de ne manipuler que la complexité inhérente à la tâche à laquelle on s'attaquait. Autrement dit, pourquoi vouloir tout résoudre avec Javascript, Java ou Python, quand on a accès à des langages plus pertinents dans bien des cas ?

Et là, on pourrait parler de plein de dérives actuelles, la liste n'en est que trop longue. Le JavaScript dans le navigateur n'était pas suffisamment ridicule qu'on a voulu l'intégrer au système : pouf, node ! Python n'apporte strictement rien de neuf par rapport à Perl, mais allons-y pour le développer jusqu'à l'intégrer à plein d'outils systèmes pour avoir une forte dépendance à ce langage alors qu'il sert à rien. Deux langages qui ont une base de code de plus d'un million de lignes chacun, c'est parfaitement raisonnable…
Pendant ce temps-là, awk a été implémenté dans toybox en 2700 lignes.

Je pense sincèrement qu'on dérive. Nos usages sont de moins en moins raisonnables. Les langages créés pour l'occasion dans Unix servaient un usage, une fonction bien particulière. De nos jours, nous inventons des langages qui se veulent génériques, pour résoudre tout type de problème, et nous les intégrons à nos machines sans plus de considération. C'est une erreur que de rejeter la simplicité en faveur de l'unicité des langages. Je préfère connaître 3 langages simples appris en 1h chacun, qu'un langage qui évolue jusqu'à nécessiter des compilateurs (ou interpréteurs) de plusieurs centaines de milliers de lignes de code.

Bref, fin de la digression.

Pour le présentiel, je ne suis pas fan. C'est assez long et fastidieux d'un point de vue de l'organisation, et le produit final n'est pas aussi agréable qu'une vidéo avec des schémas et le loisir de choisir le rythme. J'apprécie davantage une vidéo explicative, longue ou courte, plutôt qu'une heure de « cours » où on passe du temps à gérer une salle (avec plein de problèmes liés : gestion du bruit des participants, captation du son ± acceptable mais souvent pas terrible, captation de l'image souvent désastreuse…) plutôt qu'à rendre son contenu attractif.

Niveau plateforme, je peux aussi diffuser ça sur un peertube. En vrai, mes vidéos pourraient être retransmises ailleurs, je publie pour l'instant en CC.

Wow. C'est trop d'honneur que tu me fais. Je n'ai fait que parler d'un sujet qui m'intéressait et qui mérite de l'attention, selon moi.

Bon, à part ça, j'ai quelques notes rapides.

Taille des lignes dans les mails

(qui est de 75 caractères par défaut …parce-que conçu avec la nétiquette et les RFC du courriel en tête)

Est-ce que par défaut on ne devrait pas écrire des mails avec une longueur de 72 caractères plutôt que 75 ? Cela laisse l'espace pour 2 réponses (72 + 2*2 = 76, soit 80 caractères moins les 4 pour CR + LF, la limite décrite dans les documents que tu as partagé).

Valeur par défaut pour fmt

Quand j'utilise fmt il coupe à 72 par défaut (je viens de tester pour être sûr :D).

À part ça

J'ai lu en diagonale l'article. Il est très dense et il y a énormément de choses dont je ne me servirai pas. J'utilise spécifiquement roff pour ne pas avoir à gérer tout ça ! Le besoin semble très très proche des matériels très limités que tu as présenté, mais cela semble réellement historique, ou au moins, plus du adapté à nos jours. Sauf éventuellement pour écrire des mails (je coupe à 72 caractères avec fmt, et c'est bien suffisant, àmha).

Je note que l'usage de tableaux est pas terrible étant donné la largeur imposée. Il est difficile de distinguer le changement de ligne de tableau dans la dernière colonne. C'est une limitation de linuxfr, malheureusement, et j'aurai bien vu ça dans un PDF (on en revient à roff, décidément ! :p).

En tout cas, très bon travail ! Je mets ce journal dans mes marque-pages au cas où ça pourrait me servir un jour.

Vu la taille du journal… je pense qu'il me faudra une petite heure pour tout lire. Merci pour toutes ces informations… que je verrai plus tard. :D

Merci merci merci ! Je suis vraiment content d'apprendre que le projet utroff est toujours maintenu !

Content également de voir que roff te plaît ! J'espère que l'outil te satisfera. Même avec les limitations décrites dans le journal j'en suis satisfait. Et avec mom et un peu de bidouille pour l'intégration des images, ce sera parfait pour moi. Je ferai un autre journal pour compléter celui-ci.

En tout cas, je n'espérais pas un aussi bon retour sur ce journal. C'est une agréable surprise.

Ce serait effectivement intéressant d'en faire une vidéo. Je pense que ce serait mieux de l'adapter au format web plutôt qu'en faire une conférence. J'ai présenté le langage Zig de cette manière (en anglais).

J'ai déjà vu quelques vidéos sur le sujet, mais pas forcément de très bonne qualité audio, parfois trop survolé, et jamais en Français. Donc oui, cela demande un peu de temps, mais ce serait une bonne chose, et je peux faire ça (abonne-toi, met la cloche).

Merci ! (rougis)

Au passage, j'ai bien l'intention un jour de me pencher sur les macros mom et montrer comment outrepasser les limitations décrites dans le journal. Pour le moment j'ai d'autres projets en tête, ces limitations ne sont pas bloquantes pour moi, mais je veux vraiment montrer tout ce qu'on peut faire avec l'outil.

Je suis content de l'intérêt que le journal a pu susciter, j'ai d'ailleurs appris moi-même quelques trucs au passage.

Oui, et ils confirment que le problème vient du code qui est affreusement lourd. À l'époque ils arrivaient aux mêmes temps de compilation qu'aujourd'hui car il y avait vraiment beaucoup moins de code à lire et interpréter.

J'apprécie quand un langage est expressif, qu'il permet d'exprimer des choses simplement, en abstrayant les détails techniques. Mais là, je pense sincèrement que l'architecture de roff est meilleure. Qu'on ne puisse pas gérer le traitement d'un bout de texte en moins d'une minute sur nos machines qui exécutent des milliards d'instructions à la seconde, c'est ridicule. Des giga de données pour savoir cracher un PDF, c'est ridicule tout pareil.

Ce qui ne veut pas dire que roff est parfait. Parmi les trucs à améliorer, je pense à :

1. la gestion des calculs. La gestion des nombres est un peu foireuse à mon avis, trop exotique.
2. quelques constructions de code qui ne sont pas intuitives.
3. la volonté d'économiser du temps d'écriture pour les auteurs est peut-être trop présente.
4. l'écriture des macros, qui pourrait être revue. À mon avis, baser les macros sur le langage TCL serait plutôt agréable à lire, écrire. Les macros seraient peut-être très légèrement plus longues, mais tellement plus lisibles. Et en plus ce serait accessible à plus de monde, car beaucoup plus intuitif et moins exotique.

J'ai même noté quelques citations drôles dans la documentation de groff hier.

[…] it is better not to use this feature to avoid confusion.

(dans la doc sur les séquences d'échappement)

Don’t use this command! […]

(dans la doc des requête de dessin)

Despite of being silly, […]

(également dans la doc des requêtes de dessin)

Aux nouvelles :

• il n'y a plus de ré-encodage par défaut
• il y a une nouvelle variable d'environnement FFOPTS qui permet de passer des options à ffmpeg (notamment quand il y a effectivement besoin de ré-encoder)
• le README contient quelques informations concernant la nouvelle option, ainsi que la description de différentes situations

Maintenant qu'il n'y a plus de ré-encodage par défaut et que le script n'utilise plus que des outils POSIX, je considère l'application stable. Je la sors donc en v1.0.

Merci à ceux qui ont participé ! N'hésitez pas si vous avez d'autres suggestions.

J'ai pas vu de problème, et ça se copie de manière quasi instantanée vu qu'il n'y a pas de calcul.

Pour préserver la qualité du fichier de base, j'ajoute un paramètre de qualité.

Par défaut, ce paramètre vaut -c:a copy, ce qui indique à ffmpeg de ne pas ré-encoder.

Cela a pour effet de nécessiter le même format de fichiers en entrée et en sortie. Rien de trop contraignant, mais il faut peut-être que je bidouille pour garder le même format par défaut, plutôt que mettre un format fixe par défaut. Pour faire simple, il faudrait prendre l'extension du fichier audio fourni en paramètre. Tout le monde est d'accord, ou il y a mieux sans nécessiter une nouvelle dépendance ?

Voici la liste des changements apportés au script depuis la publication :

• suppression de la dépendance à xxd, remplacé par des appels à tr, awk, bc
• README : prise en compte du changement précédent
• divers changements de noms de fonctions
• commentaires (un peu) plus explicites dans le code
• un </dev/null a été déplacé d'un appel à ffmpeg à bien plus haut dans la pile d'exécution, dans le bloc while read X; do ... done où le problème apparaît (pour rappel : cette construction de code implique qu'un sous-shell peut lire ce qui doit être en entrée du while read à sa place)

Certains de ces changements étaient prévus, d'autres font suite à des commentaires pertinents.

N'ayant plus de dépendance à xxd, une nouvelle sortie voit le jour.

Reste à faire

1. s'assurer de ne pas avoir de perte de qualité audio lors de l'extraction des plages
2. Si 1. n'est pas possible, l'indiquer via une alerte.

Pourquoi résister à la tentation de faire des fonctions d'une ligne ? Je trouve ça tellement plus lisible plutôt que d'essayer de comprendre ce que fait chaque appel. C'est également moins cryptique pour ceux qui ne font pas d'unix tous les jours, ils peuvent même apprendre en lisant simplement les noms des fonctions.

Aussi, deux appels à tr au lieu d'un c'est pas grave si ça améliore la lisibilité : une fonction ne fait qu'une chose. J'optimise uniquement quand c'est nécessaire et que ça ne nuit pas à la lisibilité. Je défie quiconque de me justifier devoir supprimer un appel à tr parce que c'est trop coûteux niveau perfs pour lire un document de 20 lignes. :D

awk '{print toupper($0)}'

Peu importe si ça fonctionne mieux avec les accents, on travaille sur de l'hexa. ;)
Du coup, tr étant l'outil le plus simple, il est prioritaire.

awk -vRS=" " '{printf "%d\n", (("0x" $1) + 0)}'

Ça ne fonctionne pas sur OpenBSD. Nous n'avons pas la même implémentation de awk.

strtonum()

Extension GNU.

script awk

Ne fonctionne pas.

echo $((0x61))

Je viens de tester avec /bin/sh sur OpenBSD. Ça fonctionne. Et je ne vais quand même pas l'utiliser : bc et dc font ça très bien, ils sont même plutôt fait pour et sont efficaces. En plus, ça se gère naturellement dans un script shell, c'est un simple filtre.

[…] tu peux combiner les deux en une opération […]

Alors, oui, c'est parfaitement valide. En revanche, c'est un poil moins lisible.

Je verrai plutôt tr " " "\n" dans une fonction avec un nom explicite, pour pouvoir enchaîner des fonctions avec un nom lisible par un humain, quelque-chose comme to_single_column | uppercase.

Bien vu pour printf.

Je n'ai aucun mérite. C'est l'implémentation de chr sur mon système. :D

awk '{printf "%c", (("0x" $1) + 0)}'

Malheureusement, cette astuce ne fonctionne pas sur OpenBSD. Je suppose que la gestion de l'hexadécimal est une extension GNU…

Très bien, affûtons notre unix-fu.

Traduction de xxd -p -c 1

En premier, il nous faut une traduction d'une entrée quelconque en une colonne hexa. Tu l'as pratiquement donnée avec od, mais il manque de mettre les valeurs en colonne.

# Convert input into hexadecimal and a single byte per line.
to_hex_one_column() {
        od -An -tx1 | awk '{for(i=1;i<=NF;i++){ print $i }}'
}

Traduction de xxd -p -r

Maintenant, (presque) l'inverse avec tr, bc (et dc), od et awk. « Presque » car l'entrée n'est pas sur une seule colonne, puisque je regroupe des caractères pour traiter l'UTF-8. Je mets tous les caractères d'une ligne sur une seule ligne. L'entrée peut ressembler à ceci :

61 62 0a
63 64 0a

Et là, on aimerait bien passer tout ça à awk pour qu'il traduise ça en caractères affichables via sa fonction printf. Mais il lui faut un nombre en base 10 et je sais pas traduire l'hexa facilement avec awk (hors version GNU), donc on va passer par quelques étapes supplémentaires.

Première chose à faire, remettre tout ça en une seule colonne : tr " " "\n".

Ensuite, on veut passer l'entrée à bc (et par conséquent à dc) pour qu'il convertisse l'hexadécimal en décimal. Attention, bc est sensible à la casse, donc il faut mettre l'hexadécimal en majuscules :

uppercase() tr "[a-z]" "[A-Z]"

Maintenant la conversion avec bc :

# One col hexa to one col decimal.
from_hex_to_decimal() {
        { echo "obase=10;ibase=16;" ; cat ; } | bc
}

Et enfin, on fait la traduction décimal -> caractères UTF-8 avec awk et sa fonction printf.

# One col decimal to plain text.
from_dec() awk '{ printf ("%c", $1 + 0) }'

Et donc la fonction complète qui passe de l'hexadécimal à la sortie finale :

# Reverse hexadecimal (with space separators) to original value.
from_hex() {
        tr " " "\n" | uppercase | from_hex_to_decimal | from_dec
}

Je ne sais pas trop quoi penser du résultat. Je l'ai testé et ça semble fonctionner, mais est-ce suffisamment « simple » ? Est-ce qu'on aurait pas plus simple encore ?

Vieux rip, je ne sais plus quel outil j'avais utilisé. Mes débuts avec Linux, il y a 15 ans. Et quelques trucs trouvés sur le net entre temps, que j'ai depuis trop longtemps pour me souvenir d'où ça vient.

Ha mais je suis parfaitement d'accord avec toi : il faut s'assurer que le programme ne ré-encode pas, et au moins indiquer une alerte si c'est impossible. Après avoir viré xxd des dépendances je m'occupe de ça.