Voici un extrait de mes notes sur le sujet. L’original est en anglais, je traduis sans vérifier la terminologie exacte en français. Je laisse quelques concepts en anglais en tant que différentes pistes à explorer avec un moteur de recherche.
Parsing, token, alphabet, terminaux
Parsing, première approximation : c’est de l’analyse syntaxique. Comment y procéder ? À l’aide d’une grammaire, structurer une succession linéaire de symboles — linéaire : le prochain symbole dépend d’une façon ou d’une autre des symboles qui l’ont précédés.
Token : on nomme tokens ce que les linguistes appellent phrases. En combinant la structure obtenue après le parsing avec les tokens, on peut définir une sémantique. Exemple : 3 + 4 × 5 est un token dont on pourrait structurer comme 3 + (4 × 5) pour lui attribuer la sémantique 23.
Un alphabet est un fonds où l’on peut puiser des symboles qui engendreront un langage. Celui-ci comportera deux catégories de symboles : ceux qui sont ‘visibles’ ou ‘palpables‘ participent à la construction de phrases (e.g. ‘freem’, ‘;’), ceux qui constituent des ‘méta-données’ ne peuvent pas apparaître dans une phrase (e.g. les notions de ‘phrase’ ou de ‘nom commun’).
Les symboles palpables sont appelés symboles terminaux. Les méta-données sont appelés symboles non-terminaux.
Grammaires, productions
Generative grammar : est ainsi appelée une grammaire qui définit comment faire des substitutions de symboles. Ainsi, écrire Y → X signifie « X pourrait remplacer Y » . Une procédure systématique d’applications de règles du genre Y → X est dite “generative process”.
Les règles sont appelées “production rules”, les différentes étapes “production steps”.
On peut construire différents types de grammaires et les regrouper selon les types de productions qu’elles permettent. Un regroupement de ce genre qui est très connu est la “Chomsky hierarchy” où on trouve une catégorie de grammaires dite “context-free” (CF).
Pour écrire les règles de production d’une grammaire CF, il existe une palanquée de notations. Exemples: Backus-Naur Form (BNF), notation de van Wijngaarden, Extended BNF (EBNF), …
Parsing, redux
L’objectif du parsing d’une chaîne de caractères est de détailler les étapes qui mènent à la chaîne en partant d’une grammaire. On ne peut pas se baser seulement sur la grammaire : au moment où celle-ci a été écrite, une sémantique lui a été attachée ; les règles de production dont elle comporte possèdent elles aussi une sémantique. Ce dont on a besoin alors, c’est de trouver quelles règles ont participé à la construction de la chaîne et comment elles ont été impliquées.
La succession des règles de production forme un arbre (ou des arbres) qui est appelé “parse tree”. Parser revient à appliquer ces règles, parfois en prenant des décisions intermédiaires quand il y a plusieurs symboles candidats à la prochaine substitution.
Parser generators
On peut automatiser le processus qui, à partir d’un symbole donné, passe au prochain et, le cas échéant, lève les ambiguïtés. Un programme capable d’accomplir pareil processus est nommé “parser generator”. Ses entrées : la grammaire (toujours), les symboles terminaux (parfois) ; ses sorties : un parseur.
Ce processus de passage de symbole en symbole peut se faire de haut-en-bas ou de bas-en-haut.
Notion de direction
La génération de parseurs peut être “non-directional” : on consulte la chaîne cible symbole après symbole afin de construire l’arbre (parse tree) au fur et à mesure. La méthode d’Unger y va de haut-en-ba tandis que la méthode CYK (ou CYK) y va de bas-en-haut — appellation faite d’après Cocke, Younger, et Kasami.
La génération peut aussi être “directional” : on procède de symbole en symbole, de gauche à droite (c’est ça la direction). Deux techniques prévalent pour cette méthode : “predictions/matches” quand on va de haut-en-bas, “shifts/reductions” de bas-en-haut.
Notion de déterminisme
Un automate qui génère des parseurs directionnels possède les caractéristiques suivantes.
Il est d’abord muni des symboles qui restent à parser.
Il est également muni d’instructions qui lui permettront de se débloquer dans tous les cas possibles.
Au cas où il est confronté à une ambiguïté, il a besoin de « tricher » et consulter un nombre k de symboles à venir sans les consommer. Cette technique de triche est appelée look-ahead. La méthode est appelée X(k).
Il n’existe qu’une seule méthode déterministe allant de haut-en-bas : LL. Première lettre L : “Left-to-right”. deuxième L : la méthode identifie “the Leftmost production”. L’appellation générale de X(k) devient alors LL(k). Parfois, on inverse la chaîne à parser avant d’appliquer LL. Dans ce cas, on fait spécifiquement du RR(k).
Les méthodes déterministes allant de bas-en-haut font légion. La plus connue est LR(k) avec L : “Left-to-right” ; R : identifier “the Rightmost production”.
Quand on fait l’inversion comme au point précédent, on obtient RL(k).
Bibliothèques de génération de parseurs
Dans les langages de programmation dotés de types algébriques de données, la définition d’une grammaire est juste une définition de type. Cette simplicité mène à une prolifération de bibliothèques du genre parser generator, chaque se démarquant sur un point particulier.
TatTempo, le retour !
Regarde de ce côté pour un exemple d’utilisation d’une de ces bibliothèques ; chaque option
comporte une valeur par défaut ;
peut être parsée en version longue (--foo) ou courte (-f) ;
sera documentée après que le programme aura été invoqué via programme --help.
Un commentaire plus haut a pointé vers cette page où on peut notamment lire :
“To create your own set of compose keys copy the file /usr/share/X11/locale/en_US.UTF-8/Compose … to your home directory as .XCompose … and edit this file.”
Il serait contre‐productif de copier le Compose du système …
Oui, j’avais vu ça, c’est bien documenté dans man 5 Compose, c’est pourquoi baser un commentaire sur la page susmentionnée — ce que j’avais entrepris avant de lire Compose(5) — aurait été du pinaillage.
Tu peux avoir besoin d’une même formule dans un traitement de texte, dans un mail, dans un webmail , dans un système de suivi de ticket …
D’où : « je vois ça comme un moyen de généraliser … »
Tu as raison, il n’y a pas de paramétrage. Je pourrais pinailler et dire que
cp /usr/share/X11/… ~/.XCompose
serait de la “délocalisation” du paramétrage mais ce serait un troll déguisé …
Quant à la génération automatique de longues incantations, c’est effectivement pratique ; je vois ça comme un moyen de généraliser :command Agréer… (vim) ou équivalent.
Merci d’avoir clarifié tout ça.
P.S.
(une méthode de saisie, ça a une réelle utilité… pour le chinois).
À l’origine, ibus n’était pas développé pour cette famille de langues. D’ailleurs, il semblerait que le mandarin et les autres variantes ne soient toujours pas proprement supportés.
En outre, je trouve très honorable un projet qui est conçu de telle façon que les claviers soient utiles et utilisables dans une distribution, sans présumer que le public visé tapera un alphabet latin.
L’avantage de ne toucher qu’un sous-répertoire de /home est indéniable.
Quid des variables d’environnement ? Des chemins non standards1 ? Des modifications dans ibus ?
Certes, la syntaxe des /usr/share/X11/xkb/symbols n’est pas des plus communes. Elle me semble pourtant un inconvénient mineur par rapport à désactiver ibus qui est tout de même un composant important quand on veut interagir avec différents périphériques d’E/S.
« Standard » au sens large — i.e. passe-partout du moment qu’on a un X11 — pas à la façon rigoureuse du genre ISO. Par exemple, /etc/default/keyboard n’existe pas ici (Fedora 32). ↩
S’il faut mobiliser toutes affaires cessantes un Edward Gibbon (« Grandeur et décadence »), autant le faire à la E.G. à fond : aborder systématiquement les causes intrinsèques et extrinsèques, prouver la soi-disante « perte du principe KISS » à l’aide des ressources disponibles, ainsi que sa relation avec « la chute ».
Bref, oui, la rationalité n’est pas de ce monde (programme ambitieux). Elle n’est même pas dans cet article-là (il était permis d’espérer).
Quand on en est au point de paramétrer des chemins menant vers /usr/share/X11, quel est l’avantage de la méthode « compose » par rapport à une personnalisation directe d’un fichier /usr/share/X11/xkb/symbols/FOO ?
Je n’ai pas essayé la dernière méthode, ni sur du matériel diversifié, ni dans diverses distributions, mais dans tous les cas où je l’ai appliquée, elle a bien fonctionné sans nécessiter de variables d’environnements supplémentaires ou autre désactivation de protocoles (ibus, …).
À la surface, le langage apparaît répondre à des problématiques maison (Alphabet/Google) : en remplacer un autre qui s’est avéré être rigide par le temps.
Sémantiquement, les posets régissent tout et cela fait sens quand on a certaines configurations en ligne de mire. Quant à l’expressivité, je dirais qu’il y a des germes de types dépendants, ce qui soulève la question : pourquoi ne pas passer directement à un langage qui en est complètement doté ? D’autres points suscitent des questions similaires, par exemple le besoin de génération de code …
P.S. Toutes mes excuses pour la réponse très asynchrone ! Je n’avais pas l’intention de balancer un journal et laisser les contributions en réponse languir sans réaction.
Actuellement, le noyau ne propose pas (plus) de configuration concernant l’ordonnanceur par défaut pour des classes de périphériques quelconques. Ces derniers sont essentiellement groupés en deux catégories : ceux qui sont spécialisés dans le traitement de millions d’E/S par seconde et ceux que l’on trouve dans les machines à usage courant. Apparemment, les devs du sous-système des ordonnanceurs en préfèrent les moins complexes ou qui sont dotés de fonctionnalités minimales (mq-deadline, kyber). bfq serait complexe mais beaucoup plus adapté aux périphériques non-spécialisés à de vastes débits en E/S.
Paolo Valente, la personne derrière bfq, a tenté de convaincre Jens Axboe — en charge des ordonnanceurs dans Linux — et compagnie pour qu’il y ait des configurations par défaut, ce qui serait par exemple le cas dans le sous-système Réseau. Jusqu’à maintenant, J. Axboe rejette ces tentatives pour diverses raisons.
Afin d’outrepasser cela et faire adopter bfq à plus de gens, P. Valente a choisi de plutôt travailler avec les distributions étant donné qu’elles ont la capacité de mettre en place des règles udev en vigueur par défaut. Ainsi ai-je regardé ce qui se passe du côté de NixOS et Fedora — je fais tourner ces deux distributions-là. Seule la dernière a des mécanismes en place par défaut quant aux ordonnanceurs. Sans surprise, sous NixOS, en amont on énumère les possibles et en aval, on est invité à écrire ses propres dérivations … Chez Fedora, bfq est en place par défaut depuis la version 31. Mais cela a nécessité des contorsions :
J. Axboe a supprimé le champ CONFIG_IOSCHED_DEFAULT dans
les options du noyau et, par la même occasion, interdit de définir l’ordonnanceur par défaut à ce niveau-là.
P. Valente a contourné cela en proposant à Fedora d’introduire bfq par défaut via udev. Zbigniew Jędrzejewski-Szmek y a répondu favorablement mais a voulu définir les paramètres dans systemd-upstream au lieu de patcher le paquet Fedora.
En fin de compte, le paquet systemd sous Fedora a été
patché.
La saga n’est pourtant pas terminée ! io.weight et les autres propriétés des cgroups ont été conçues pour cfq. Elles nécessitaient des adaptations afin de fonctionner correctement avec bfq. Fam Zheng a rédigé un patch pour réaliser ce port. Tejun Heo et J. Axboe ont demandé des modifications, P. Valente les a faites mais elles languiraient toujours quelque part en attendant d’atterrir dans une version publique de Linux. Du coup, Kai Krakow a rédigé un contrournement dans systemd qui a été accepté. Ce qui mène à ce constat : afin de se servir d’io.weight et assortis, il faudrait à la fois activer bfq sur le périphérique cible et utiliser une version de systemd qui comporte le patch de K. Krakow.
Pour terminer, en lisant la documentation des cgroups, il me semble qu’un contrôle plus fin des E/S devrait concerner la priorié (IOPS) et le débit (BPS) en même temps. Les commandes que j’ai proposées plus haut ressembleraient alors à ceci :
Et au lieu de contrôler la priorité en absolu, le faire par périphérique : -p "IODeviceWeight=${DOSSIER} 100".
Bien entendu, tout ceci est désormais superflu vu que tu as réussi à faire ce que tu voulais et comme tu le souhaitais, via ionice. Disons que ce petit pavé est pour la postérité.
Hier, après une lecture en diagonale d’une volée de pages sur le web, des choses ont piqué ma curiosité et j’aimerais approfondir un peu. J’ai mis des marques-pages sur ces pages, pense qu’une solution est là-dedans, n’ai pas encore eu le temps de les relire et reviendrai là-dessus d’ici samedi (une longue phrase pour qualifier la procrastination …).
Entre-temps, si l’ordonnanceur du périphérique sur lequel tu fais les E/S est bfq, tu peux explorer le sujet et trouveras sans doute la solution avant mon prochain post.
Ah oui ! Je n’avais pas lu ce paragraphe. Je fais la même lecture que toi : le cgroup que tu veux utiliser n’est valable que pour cfq qui, après un rapide tour sur le web, a été retiré des récentes versions du noyau. Donc, il vaudrait mieux chercher à installer/activer le pilote de cfq et y basculer avant de tenter de l’utiliser.
Par curiosité, j’ai tenté de voir ce que ça donnerai ici.
Pourrais-tu indiquer les commandes qui lancent les processus ?
Une chose semblable (propriétés CPUQuota et MemoryHigh) réagit de la manière attendue chez moi™.
Une des différences entre les première et deuxième versions des cgroups réside dans la capacité de créer des branches dans la hiérarchie. En v2, la seule hiérarchie qui existe est gérée par une seule entité ; du moins, dans l’implémentation de systemd. Un système faisant tourner ce dernier lui délègue tout ce qui a trait aux cgroups — leur création, suppression, modification …
Pour le cas qui t’intéresse, essaie de créer deux unités semblables presque en tout, sauf dans le paramètre « priorité des E/S. » qui, d’après ce que j’ai tiré de la documentation, serait io.weight. systemd.resource-control(5) explique la correspondance entre les API du noyau et systemd ; on peut notamment y lire que l’option correspondant à io.weight est IOWeight. Voici par exemple deux unités créés à la volée et lançant deux processus avec une différence dans IOWeight:
Ton post indique que tu voudrais plus que ça : définir l’IOWeight d’une unité conditionnellement à la valeur du même paramètre d’une autre unité. Il faudrait alors écrire de vrais fichiers unit qui spécifient cette dépendance.
P.S. Au cas où tu n’utiliserais pas systemd, toutes mes plates.
P-P.S. Au cas contraire, si la v2 casse des choses qui tournaient bien en v1 sur une machine ayant systemd, tu peux booter en indiquant au noyau d’utiliser v1 et systemd respectera ça. La hiérarchie des cgroups utilisée pendant une session donnée est, par exemple, consultable avec systemctl --version #⇒ default-hierarchy=unified.
P-P-P.S. Je touche à ces questions de très loin, i.e. ai compétences proches du néant dans le domaine, pourrai pas aider au-delà de ce qui précède.
« Les choses les plus difficiles en Informatique sont au nombre de deux : vider le cache et identifier les choses.1 »
Les choses premières en premier, je commence avec l’identification pour noter que le projet est nommé Augeas et est chapeauté par une équipe nommée Hercules ; nul doute que cette équipe s’est à un certain moment proposée de nettoyer les écuries dans les config :) Bref, c’est toujours une agréable surprise de voir des emprunts faits à la mythologie grecque …
Élégance d’Augeas — l’outil, non pas les écuries, hein2
Il semble qu’un objet configurable est modélisé en tant que foncteur. Pour des besoins de présentations, j’imagine, le vocabulaire foncteur et consorts est évacué de ce qu’on peut trouver sur le site web officiel. Les auteurs préfèrent parler d’arbre ou graphe. Pour les besoins de ce qui suit, je retiens foncteur.
La structure sur laquelle est bâtie le reste d’Augeas serait Lens valeur, où Lens est une co-algèbre pour le foncteur Config valeur qui, lui, est une F-algèbre sur les configurables. Prosaïquement, Augeas ferait abstraction des objets configurables de telle façon que, quelle soit ce qu’ils configurent, il serait possible de les manipuler grâce à deux opérations de base, à savoir3
retirer_valeur : config → val, la consultation d’une configuration ;
modifier_valeur : config → val → config, l’actualisation d’une configuration.
Ces opérations sont applicables à la fois sur un objet en entier ou à ses parties, grâce aux propriétés des Lenses. Et comme on a une algèbre, et ben, des opérations algébriques supplémentaires sont possibles sur ces Lenses.
Avec un outillage pareil, on peut désormais uniformiser tout ce qui a trait à la configuration, à condition bien sûr de préalablement l’encapsuler sous une Lens. Le bidirectionnel est une conséquence immédiate de l’utilisation des Lenses. Très élégant !
Et comme des paquets pour nombreuses distributions sont disponibles, j’ai mis la main dans le cambouis.
# Comment sont traités les processus lancés# dans la session en cours si je la ferme ?
augtool get /files/etc/systemd/logind.conf/Login/KillUserProcesses/value
# /files/…/value = true
Au lieu de get, j’aurais pu utiliser un set et cela, indépendamment de la syntaxe réelle qui se trouve dans /etc/systemd/logind.conf (INI dans ce cas-ci mais ça aurait pu être du Bash, du Python, …). En somme, un outil conceptuellement balaise, je dirais. Viennent ensuite les points qui font tache.
Implémentation d’Augeas
Le langage à utiliser afin d’ajouter une nouvelle Lens est dérivé de ML, ça promet ! Sauf qu’en jetant un coup-d’œil sur les sources, on voit que Augeas — le ML-like — fait 59.8 % et le C 36.7 %. Le plus du tiers du dépôt en C fait des choses telles du parsing, dommage ! Je pense que ces dernières années, il est devenu inutile d’élaborer sur les méfaits de parser en C.
Même au-delà du parsing, la manière dont les implémentations alternatives est faite consiste à appeler le C original. Je base cela sur ce qu’on peut par exemple voir pour les bindings en
Haskell : {-# LANGUAGE CPP, ForeignFunctionInterface #-} …
Cela étant dit, le projet est là depuis au-moins 2008, sous la houlette de David Lutterkort, employé de Red Hat. Donc, j’imagine qu’il y avait des contraintes corporate à se reposer sur du C pour des tâches pareilles. En plus, le regard qu’on peut porter sur des outils durant cette décennie n’est pas certainement le même qu’il y a deux décennies.
Un petit détour sur le langage en soi avant de terminer. Ses types primitifs sont unit, string, regexp, lens, tree, et filter. Faire de REGEX un type primitif, même en se limitant à du POSIX étendu, en prenant en plus le soin de contrôler quelles sont les regex qu’on acceptera, ça reste un choix que je qualifierais de hack. Quand on crée un langage de toutes pièces, au lieu d’évacuer un problème (d’expressivité peut-être) dans des regex, autant enrichir la syntaxe du langage qu’on est de toutes façons en train d’inventer.
En tout cas, merci d’avoir posté sur Augeas, ces satanés travaux d’Héraclès, on finira par les terminer, quelle que soit la configuration !
Je donne mes impressions en première approximation, je découvre la chose, je commettrai certainement des erreurs qu’une familiarité avec Augeas permettrait d’éviter. ↩
En reprenant les notations mentionnées dans le journal. ↩
[…] coûts de formation […] et support, de la complexité […] de convaincre …
Cela est bien entendu plus proche d’un caviardage que d’une citation, mais je le fais pour signaler qu’un glissement vers un biais cognitif ne serait pas éloigné. Le post antérieur a bien caractérisé les choses :
barmic :
C'est des choix de techno que tu fais. [À propos d’une potentielle migration :] c'est un point qui a un minimum était envisagé puisqu'il peut générer du yaml et du json.
Voilà ! Un seul clic sur le site du langage et en promenant la souris au-dessus de la section “Packages”, on se rend compte qu’Ansible & Kubernetes, entre autres, ont une place de choix dans les efforts de promotion. Encore une fois, sur le fond technique, l’échange s’est asséché même si les choses ne sont pas si arides : envisager les coûts d’une migration, certes avec réticence, laisse penser qu’on reconnaît du bon quelque part.
Alors, dans le plan de conquête ultime du monde, lorsque l’avant-garde sera en train de ramer, peut-être que des renforts seront envoyés incognito de ta part :) Moins légèrement, quant aux planifications de nature de celle en discussion ici, puisque visiblement ça te tient à cœur, parlons-y : comment y procèdes-tu d’habitude ? À la Geoffrey Moore ? À la John Kotter ? Ou alors à la Clausewitz ?
Sur le fond, il est incertain que je pourrais ajouter quoi que ce soit. Voici donc quelques lignes qui rentrent dans la catégorie « style/goût ».
Simplicité (lecture). La forme normalisée de Dhall est tellement simple qu’elle s’explique en une courte phrase : entre {} se trouve un ensemble hétérogène, entre [] un ensemble homogène, le reste constitue des valeurs primitives.
Simplicité (programmation). C’est un langage très limité. L’exemple de ce qui est possible sur les Texts est très parlant : on ne peut que les concaténer. L’originalité n’est clamée nulle part car, en fin de compte, on pourrait dire que tous les langages de haut niveau seraient des DSL autour de l’Assembleur qui, soi-même, serait un DSL autour du Code Machine, … :)
Pertinence & Apport. Je trouve qu’à chaque fois que la correction, la précision sont augmentées grâce à un outil, ce dernier devrait de facto faire partie des choix possibles dès que ses alternatives imprécises étaient considérées. Mais là, on bifurque dans le normatif et des eaux troubles …
Donc, dont acte des objections, merci de la conversation.
La personne qui avait la dalle est bien servie, dis donc !
L’origine du nom donné au langage est tout aussi facétieuse, voir ici. L’ancêtre du langage est Morte, une appellation encore rigolo ; Morte a un front-end nommé Annah … et on aura deviné ce qui a inspiré cette appellation !
Il semble que nous sommes d’accord que le YAML est problématique.
Maintenant, sur les points où tu objectes, pourrais-tu donner des détails ?
Tous les langages de conf pas trop débiles ont des schemas qui les définissent. Problème déjà résolu depuis l'ère des confs en xml.
Les types de Dhall ne sont pas là seulement pour émettre des jugements du genre « on attendait un nombre réel et on en a reçu un. » Ils participent de la fiabilité globale qu’une conf Dhall vous donne. Tu connais certainement des joyeusetés du genre XML entity expansion, sujet largement traité à propos de XML. Regarde ce que ça donne quant au YAML. Les schémas ne protégeront pas de cela à moins de restreindre les fonctionnalités de la norme à implémenter.
Par conception, une expression Dhall qui a été validée
n’induit jamais des erreurs et autres exceptions, donc ne plante jamais ;
n’admet jamais des entrées qui se révéleront malformées et n’en donne jamais en sortie ;
ne conduira jamais à une boucle infinie. Sur ce point, il y a des cas pathologiques de la famille de la fonction d'Ackermann, mais ici on parle de temps très longs mais finis.
Les vérificateurs de schémas ne peuvent pas garantir cela, ici également par conception. C’est implicitement de cela dont je voulais évoquer quant à la validité.
Tout cela peut paraître péremptoire de loin. Sur le site officiel, il y a des explications plus détaillées de beaucoup d’autres choses que ce qu’un journal ou un commentaire peut couvrir. Au fur et à mesure que le côté formel sera exploré, tu verras que la fiabilité de Dhall n’est pas une stratégie de marketing ou quelque chose du genre.
J'ai beau avoir lu le journal, je ne comprend absolument pas l'intérêt du truc.
Programmer la configuration, la valider strictement, la découper en petits morceaux sans crainte que le fusionnement éclatera, etc.
La syntaxe est tellement peu lisible pour de la config …
C’est imbibé de la syntaxe des langages comme OCaml et Haskell.
Et la lisibilité d'une fichier de config est hyper importante aussi.
Les annotations de types sont là pour augmenter la lisibilité. Le fichier à lire est celui qui est normalisé si on ne veut pas voir les étapes ayant conduit à générer la configuration.
Bref, je suis partisan du YAML pour la conf (qui est à la fois lisible par un humain, et facilement parsable pour une machine).
Le YAML n’est ni facile à lire ni à implémenter. Le journal comporte un lien sur une page qui expose succinctement où le bât blesse avec le YAML.
Tiens, une question en passant : pourquoi Lollypop n'est encore dans aucune distribution?
Je compte une dizaine de distributions sur cette page-là.
Pour avoir traîné ici depuis longtemps, je dirai qu’il y a une forte concentration de Debian-istes sur LinuxFr ; c’est peut-être ton cas et commelollypop n’est pas dans Debian Stable, tu aurais trop rapidement extrapolé.
Comme le journal évoque Sénèque, voir aussi son L’Oisiveté. J'ajoute un journal dédié au thème, The Idler ! Ici par exemple, on attribue ceci à Bill Gate : “[…]an unwritten rule attributed to Bill Gates from the software industry: hire lazy programmers. Why? Lazy programmers will figure out the smartest way to get something done to avoid having to do it.”
Dans l'absolu, ce n’est pas une mauvaise pratique de mettre les signatures car, pour moi au moins, elles font partie de la documentation.
Cependant, selon le code sur lequel l’on travaille et pendant la phase « brouillon » du code, mettre systématiquement des signatures reviendrait à toujours rouler sur un vélo la tête dans le guidon. En effet, les besoins immédiats ont tendance à faire écrire des signatures (et implémentations) mono-morphiques même là où cela ne comporte aucun avantage. Et plus tard, par exemple, il n’est pas rare de se rendre compte que des implémentations « obtuses » respectivement de type Foo et Bar ont beaucoup de ressemblances ; on se mettra alors à faire du refactoring a posteriori alors qu’il aurait été inutile si l’on avait écrit une implémentation plus générale du premier coup. Il y a d’autres cas plus gênants, voire limitants, qui peuvent arriver quand on met systématiquement les signatures mais c’est presque toujours lors d’usages avancés de Haskell (donc à un stade où l’on n'a plus besoin des recommandations d’un quidam sur DLFP).
En gros, je trouve plus efficace de se défaire des signatures pendant la phase « brouillon » du cycle de vie d’un code et de les mettre au moment où le code passe en mode release. Mes 2$.
La théorie est utilisable indépendamment de Darcs. Ce dernier est lui aussi utilisable, mais c’est vrai que certaines de ces commandes sont lentes si elles sont appliquées sur un dépôt très vaste, typiquement des dépôts de la grandeur d’un compilateur grand public ou d’un noyau de même nature. Par contre, sur de petits et moyens dépôts, Darcs est tout à fait rapide. Et quelle que soit la taille des dépôts, ses simplicité et élégance à l’usage sont AMHA des atouts à considérer.
Aussi, la compréhension de la théorie des patches n’est-elle pas nécessaire pour se mettre à Darcs. Ceci est un récent fil de discussion (en anglais) qui comporte des éléments de comparaison entre Git, Mercurial et Darcs. Dans la discussion, Ben Franksen est le nom de la personne qui, à mon avis, en connaît le plus sur le Darcs de ces dernières années que n’importe qui d’autre, le mainteneur officiel du projet inclus.
# Condensé de glossaire
Posté par gipoisson . En réponse au journal quick start pour coco/R. Évalué à 8.
Sommaire
Voici un extrait de mes notes sur le sujet. L’original est en anglais, je traduis sans vérifier la terminologie exacte en français. Je laisse quelques concepts en anglais en tant que différentes pistes à explorer avec un moteur de recherche.
Parsing, token, alphabet, terminaux
Parsing, première approximation : c’est de l’analyse syntaxique. Comment y procéder ? À l’aide d’une grammaire, structurer une succession linéaire de symboles — linéaire : le prochain symbole dépend d’une façon ou d’une autre des symboles qui l’ont précédés.
Token : on nomme tokens ce que les linguistes appellent phrases. En combinant la structure obtenue après le parsing avec les tokens, on peut définir une sémantique. Exemple :
3 + 4 × 5est un token dont on pourrait structurer comme3 + (4 × 5)pour lui attribuer la sémantique23.Un alphabet est un fonds où l’on peut puiser des symboles qui engendreront un langage. Celui-ci comportera deux catégories de symboles : ceux qui sont ‘visibles’ ou ‘palpables‘ participent à la construction de phrases (e.g. ‘freem’, ‘;’), ceux qui constituent des ‘méta-données’ ne peuvent pas apparaître dans une phrase (e.g. les notions de ‘phrase’ ou de ‘nom commun’).
Les symboles palpables sont appelés symboles terminaux. Les méta-données sont appelés symboles non-terminaux.
Grammaires, productions
Generative grammar : est ainsi appelée une grammaire qui définit comment faire des substitutions de symboles. Ainsi, écrire
Y → Xsignifie « X pourrait remplacer Y » . Une procédure systématique d’applications de règles du genreY → Xest dite “generative process”.Les règles sont appelées “production rules”, les différentes étapes “production steps”.
On peut construire différents types de grammaires et les regrouper selon les types de productions qu’elles permettent. Un regroupement de ce genre qui est très connu est la “Chomsky hierarchy” où on trouve une catégorie de grammaires dite “context-free” (CF).
Pour écrire les règles de production d’une grammaire CF, il existe une palanquée de notations. Exemples: Backus-Naur Form (BNF), notation de van Wijngaarden, Extended BNF (EBNF), …
Parsing, redux
L’objectif du parsing d’une chaîne de caractères est de détailler les étapes qui mènent à la chaîne en partant d’une grammaire. On ne peut pas se baser seulement sur la grammaire : au moment où celle-ci a été écrite, une sémantique lui a été attachée ; les règles de production dont elle comporte possèdent elles aussi une sémantique. Ce dont on a besoin alors, c’est de trouver quelles règles ont participé à la construction de la chaîne et comment elles ont été impliquées.
La succession des règles de production forme un arbre (ou des arbres) qui est appelé “parse tree”. Parser revient à appliquer ces règles, parfois en prenant des décisions intermédiaires quand il y a plusieurs symboles candidats à la prochaine substitution.
Parser generators
On peut automatiser le processus qui, à partir d’un symbole donné, passe au prochain et, le cas échéant, lève les ambiguïtés. Un programme capable d’accomplir pareil processus est nommé “parser generator”. Ses entrées : la grammaire (toujours), les symboles terminaux (parfois) ; ses sorties : un parseur.
Ce processus de passage de symbole en symbole peut se faire de haut-en-bas ou de bas-en-haut.
Notion de direction
La génération de parseurs peut être “non-directional” : on consulte la chaîne cible symbole après symbole afin de construire l’arbre (parse tree) au fur et à mesure. La méthode d’Unger y va de haut-en-ba tandis que la méthode CYK (ou CYK) y va de bas-en-haut — appellation faite d’après Cocke, Younger, et Kasami.
La génération peut aussi être “directional” : on procède de symbole en symbole, de gauche à droite (c’est ça la direction). Deux techniques prévalent pour cette méthode : “predictions/matches” quand on va de haut-en-bas, “shifts/reductions” de bas-en-haut.
Notion de déterminisme
Un automate qui génère des parseurs directionnels possède les caractéristiques suivantes.
kde symboles à venir sans les consommer. Cette technique de triche est appelée look-ahead. La méthode est appeléeX(k).Il n’existe qu’une seule méthode déterministe allant de haut-en-bas : LL. Première lettre L : “Left-to-right”. deuxième L : la méthode identifie “the Leftmost production”. L’appellation générale de
X(k)devient alorsLL(k). Parfois, on inverse la chaîne à parser avant d’appliquer LL. Dans ce cas, on fait spécifiquement duRR(k).Les méthodes déterministes allant de bas-en-haut font légion. La plus connue est
LR(k)avec L : “Left-to-right” ; R : identifier “the Rightmost production”.Quand on fait l’inversion comme au point précédent, on obtient
RL(k).Bibliothèques de génération de parseurs
Dans les langages de programmation dotés de types algébriques de données, la définition d’une grammaire est juste une définition de type. Cette simplicité mène à une prolifération de bibliothèques du genre parser generator, chaque se démarquant sur un point particulier.
TatTempo, le retour !
Regarde de ce côté pour un exemple d’utilisation d’une de ces bibliothèques ; chaque option
--foo) ou courte (-f) ;programme --help.Et c’est compilé :)
[^] # Re: Pinailler
Posté par gipoisson . En réponse au journal Qu’on pose. Évalué à 1.
En bout de compte, le pinaillage s’est imposé ! Le commentaire renvoie à cette page qui, dès le premier paragraphe, renvoie à l’autre page …
Si tu contribues au wiki d’Ubuntu, peut-être que cet échange servira in fine à une modification de ce qui est apparemment une recommandation erronée.
[^] # Re: Intérêt
Posté par gipoisson . En réponse au journal Qu’on pose. Évalué à 1.
Un commentaire plus haut a pointé vers cette page où on peut notamment lire :
“To create your own set of compose keys copy the file /usr/share/X11/locale/en_US.UTF-8/Compose … to your home directory as .XCompose … and edit this file.”
Oui, j’avais vu ça, c’est bien documenté dans
man 5 Compose, c’est pourquoi baser un commentaire sur la page susmentionnée — ce que j’avais entrepris avant de lireCompose(5)— aurait été du pinaillage.D’où : « je vois ça comme un moyen de généraliser … »
[^] # Re: Intérêt
Posté par gipoisson . En réponse au journal Qu’on pose. Évalué à 4.
Tu as raison, il n’y a pas de paramétrage. Je pourrais pinailler et dire que
serait de la “délocalisation” du paramétrage mais ce serait un troll déguisé …
Quant à la génération automatique de longues incantations, c’est effectivement pratique ; je vois ça comme un moyen de généraliser
:command Agréer…(vim) ou équivalent.Merci d’avoir clarifié tout ça.
P.S.
À l’origine,
ibusn’était pas développé pour cette famille de langues. D’ailleurs, il semblerait que le mandarin et les autres variantes ne soient toujours pas proprement supportés.En outre, je trouve très honorable un projet qui est conçu de telle façon que les claviers soient utiles et utilisables dans une distribution, sans présumer que le public visé tapera un alphabet latin.
[^] # Re: Question de n00b
Posté par gipoisson . En réponse au journal Qu’on pose. Évalué à 1.
L’avantage de ne toucher qu’un sous-répertoire de
/homeest indéniable.Quid des variables d’environnement ? Des chemins non standards1 ? Des modifications dans
ibus?Certes, la syntaxe des
/usr/share/X11/xkb/symbolsn’est pas des plus communes. Elle me semble pourtant un inconvénient mineur par rapport à désactiveribusqui est tout de même un composant important quand on veut interagir avec différents périphériques d’E/S.« Standard » au sens large — i.e. passe-partout du moment qu’on a un X11 — pas à la façon rigoureuse du genre ISO. Par exemple,
/etc/default/keyboardn’existe pas ici (Fedora 32). ↩[^] # Re: La qualité ne fait pas le succès
Posté par gipoisson . En réponse au lien Grandeur et décadence de Linux (et j'ajoute: sic transit Linux regnum). Évalué à 1.
[warning : commentaire allant sur une tangente …]
S’il faut mobiliser toutes affaires cessantes un Edward Gibbon (« Grandeur et décadence »), autant le faire à la E.G. à fond : aborder systématiquement les causes intrinsèques et extrinsèques, prouver la soi-disante « perte du principe KISS » à l’aide des ressources disponibles, ainsi que sa relation avec « la chute ».
Bref, oui, la rationalité n’est pas de ce monde (programme ambitieux). Elle n’est même pas dans cet article-là (il était permis d’espérer).
# Question de n00b
Posté par gipoisson . En réponse au journal Qu’on pose. Évalué à 2.
Quand on en est au point de paramétrer des chemins menant vers
/usr/share/X11, quel est l’avantage de la méthode « compose » par rapport à une personnalisation directe d’un fichier/usr/share/X11/xkb/symbols/FOO?Par exemple:
Je n’ai pas essayé la dernière méthode, ni sur du matériel diversifié, ni dans diverses distributions, mais dans tous les cas où je l’ai appliquée, elle a bien fonctionné sans nécessiter de variables d’environnements supplémentaires ou autre désactivation de protocoles (
ibus, …).[^] # Re: cue
Posté par gipoisson . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à 1.
Merci du lien.
À la surface, le langage apparaît répondre à des problématiques maison (Alphabet/Google) : en remplacer un autre qui s’est avéré être rigide par le temps.
Sémantiquement, les posets régissent tout et cela fait sens quand on a certaines configurations en ligne de mire. Quant à l’expressivité, je dirais qu’il y a des germes de types dépendants, ce qui soulève la question : pourquoi ne pas passer directement à un langage qui en est complètement doté ? D’autres points suscitent des questions similaires, par exemple le besoin de génération de code …
P.S. Toutes mes excuses pour la réponse très asynchrone ! Je n’avais pas l’intention de balancer un journal et laisser les contributions en réponse languir sans réaction.
# Maintenir un sous-système de Linux
Posté par gipoisson . En réponse au message Jeu : prioriser les entrées/sorties d'un processus avec cgroupsv2. Évalué à 1.
Actuellement, le noyau ne propose pas (plus) de configuration concernant l’ordonnanceur par défaut pour des classes de périphériques quelconques. Ces derniers sont essentiellement groupés en deux catégories : ceux qui sont spécialisés dans le traitement de millions d’E/S par seconde et ceux que l’on trouve dans les machines à usage courant. Apparemment, les devs du sous-système des ordonnanceurs en préfèrent les moins complexes ou qui sont dotés de fonctionnalités minimales (
mq-deadline,kyber).bfqserait complexe mais beaucoup plus adapté aux périphériques non-spécialisés à de vastes débits en E/S.Paolo Valente, la personne derrière
bfq, a tenté de convaincre Jens Axboe — en charge des ordonnanceurs dans Linux — et compagnie pour qu’il y ait des configurations par défaut, ce qui serait par exemple le cas dans le sous-système Réseau. Jusqu’à maintenant, J. Axboe rejette ces tentatives pour diverses raisons.Afin d’outrepasser cela et faire adopter
bfqà plus de gens, P. Valente a choisi de plutôt travailler avec les distributions étant donné qu’elles ont la capacité de mettre en place des règlesudeven vigueur par défaut. Ainsi ai-je regardé ce qui se passe du côté de NixOS et Fedora — je fais tourner ces deux distributions-là. Seule la dernière a des mécanismes en place par défaut quant aux ordonnanceurs. Sans surprise, sous NixOS, en amont on énumère les possibles et en aval, on est invité à écrire ses propres dérivations … Chez Fedora,bfqest en place par défaut depuis la version 31. Mais cela a nécessité des contorsions :CONFIG_IOSCHED_DEFAULTdans les options du noyau et, par la même occasion, interdit de définir l’ordonnanceur par défaut à ce niveau-là.bfqpar défaut viaudev. Zbigniew Jędrzejewski-Szmek y a répondu favorablement mais a voulu définir les paramètres danssystemd-upstream au lieu de patcher le paquet Fedora.systemdsous Fedora a été patché.La saga n’est pourtant pas terminée !
io.weightet les autres propriétés descgroupsont été conçues pourcfq. Elles nécessitaient des adaptations afin de fonctionner correctement avecbfq. Fam Zheng a rédigé un patch pour réaliser ce port. Tejun Heo et J. Axboe ont demandé des modifications, P. Valente les a faites mais elles languiraient toujours quelque part en attendant d’atterrir dans une version publique de Linux. Du coup, Kai Krakow a rédigé un contrournement danssystemdqui a été accepté. Ce qui mène à ce constat : afin de se servir d’io.weightet assortis, il faudrait à la fois activerbfqsur le périphérique cible et utiliser une version desystemdqui comporte le patch de K. Krakow.Pour terminer, en lisant la documentation des
cgroups, il me semble qu’un contrôle plus fin des E/S devrait concerner la priorié (IOPS) et le débit (BPS) en même temps. Les commandes que j’ai proposées plus haut ressembleraient alors à ceci :Et au lieu de contrôler la priorité en absolu, le faire par périphérique :
-p "IODeviceWeight=${DOSSIER} 100".Bien entendu, tout ceci est désormais superflu vu que tu as réussi à faire ce que tu voulais et comme tu le souhaitais, via
ionice. Disons que ce petit pavé est pour la postérité.[^] # Re: systemd
Posté par gipoisson . En réponse au message Jeu : prioriser les entrées/sorties d'un processus avec cgroupsv2. Évalué à 1.
Hier, après une lecture en diagonale d’une volée de pages sur le web, des choses ont piqué ma curiosité et j’aimerais approfondir un peu. J’ai mis des marques-pages sur ces pages, pense qu’une solution est là-dedans, n’ai pas encore eu le temps de les relire et reviendrai là-dessus d’ici samedi (une longue phrase pour qualifier la procrastination …).
Entre-temps, si l’ordonnanceur du périphérique sur lequel tu fais les E/S est
bfq, tu peux explorer le sujet et trouveras sans doute la solution avant mon prochain post.[^] # Re: systemd
Posté par gipoisson . En réponse au message Jeu : prioriser les entrées/sorties d'un processus avec cgroupsv2. Évalué à 2.
Ah oui ! Je n’avais pas lu ce paragraphe. Je fais la même lecture que toi : le
cgroupque tu veux utiliser n’est valable que pourcfqqui, après un rapide tour sur le web, a été retiré des récentes versions du noyau. Donc, il vaudrait mieux chercher à installer/activer le pilote decfqet y basculer avant de tenter de l’utiliser.Par curiosité, j’ai tenté de voir ce que ça donnerai ici.
CFQ n’est pas une option. Il en est de même en scannant ce qui est disponible pour tous les périphériques :
Bref, tente d’abord de configurer CFQ si ton noyau est compilé avec, sinon il faudra compiler Linux dans une ancienne version.
[^] # Re: systemd
Posté par gipoisson . En réponse au message Jeu : prioriser les entrées/sorties d'un processus avec cgroupsv2. Évalué à 2.
Pourrais-tu indiquer les commandes qui lancent les processus ?
Une chose semblable (propriétés
CPUQuotaetMemoryHigh) réagit de la manière attendue chez moi™.# systemd
Posté par gipoisson . En réponse au message Jeu : prioriser les entrées/sorties d'un processus avec cgroupsv2. Évalué à 3.
Une des différences entre les première et deuxième versions des cgroups réside dans la capacité de créer des branches dans la hiérarchie. En v2, la seule hiérarchie qui existe est gérée par une seule entité ; du moins, dans l’implémentation de systemd. Un système faisant tourner ce dernier lui délègue tout ce qui a trait aux cgroups — leur création, suppression, modification …
Pour le cas qui t’intéresse, essaie de créer deux unités semblables presque en tout, sauf dans le paramètre « priorité des E/S. » qui, d’après ce que j’ai tiré de la documentation, serait
io.weight.systemd.resource-control(5)explique la correspondance entre les API du noyau et systemd ; on peut notamment y lire que l’option correspondant àio.weightestIOWeight. Voici par exemple deux unités créés à la volée et lançant deux processus avec une différence dansIOWeight:Ton post indique que tu voudrais plus que ça : définir l’IOWeight d’une unité conditionnellement à la valeur du même paramètre d’une autre unité. Il faudrait alors écrire de vrais fichiers unit qui spécifient cette dépendance.
P.S. Au cas où tu n’utiliserais pas systemd, toutes mes plates.
P-P.S. Au cas contraire, si la v2 casse des choses qui tournaient bien en v1 sur une machine ayant systemd, tu peux booter en indiquant au noyau d’utiliser v1 et systemd respectera ça. La hiérarchie des cgroups utilisée pendant une session donnée est, par exemple, consultable avec
systemctl --version #⇒ default-hierarchy=unified.P-P-P.S. Je touche à ces questions de très loin, i.e. ai compétences proches du néant dans le domaine, pourrai pas aider au-delà de ce qui précède.
[^] # Re: Ça me fait un peu penser à Augeas
Posté par gipoisson . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à 2.
Les choses premières en premier, je commence avec l’identification pour noter que le projet est nommé Augeas et est chapeauté par une équipe nommée Hercules ; nul doute que cette équipe s’est à un certain moment proposée de nettoyer les écuries dans les config :) Bref, c’est toujours une agréable surprise de voir des emprunts faits à la mythologie grecque …
Élégance d’Augeas — l’outil, non pas les écuries, hein2
Il semble qu’un objet configurable est modélisé en tant que foncteur. Pour des besoins de présentations, j’imagine, le vocabulaire foncteur et consorts est évacué de ce qu’on peut trouver sur le site web officiel. Les auteurs préfèrent parler d’arbre ou graphe. Pour les besoins de ce qui suit, je retiens foncteur.
La structure sur laquelle est bâtie le reste d’Augeas serait
Lens valeur, où Lens est une co-algèbre pour le foncteurConfig valeurqui, lui, est une F-algèbre sur les configurables. Prosaïquement, Augeas ferait abstraction des objets configurables de telle façon que, quelle soit ce qu’ils configurent, il serait possible de les manipuler grâce à deux opérations de base, à savoir3retirer_valeur : config → val, la consultation d’une configuration ;modifier_valeur : config → val → config, l’actualisation d’une configuration.Ces opérations sont applicables à la fois sur un objet en entier ou à ses parties, grâce aux propriétés des Lenses. Et comme on a une algèbre, et ben, des opérations algébriques supplémentaires sont possibles sur ces Lenses.
Avec un outillage pareil, on peut désormais uniformiser tout ce qui a trait à la configuration, à condition bien sûr de préalablement l’encapsuler sous une Lens. Le bidirectionnel est une conséquence immédiate de l’utilisation des Lenses. Très élégant !
Et comme des paquets pour nombreuses distributions sont disponibles, j’ai mis la main dans le cambouis.
Au lieu de
get, j’aurais pu utiliser unsetet cela, indépendamment de la syntaxe réelle qui se trouve dans/etc/systemd/logind.conf(INI dans ce cas-ci mais ça aurait pu être du Bash, du Python, …). En somme, un outil conceptuellement balaise, je dirais. Viennent ensuite les points qui font tache.Implémentation d’Augeas
Le langage à utiliser afin d’ajouter une nouvelle Lens est dérivé de ML, ça promet ! Sauf qu’en jetant un coup-d’œil sur les sources, on voit que Augeas — le ML-like — fait 59.8 % et le C 36.7 %. Le plus du tiers du dépôt en C fait des choses telles du parsing, dommage ! Je pense que ces dernières années, il est devenu inutile d’élaborer sur les méfaits de parser en C.
Même au-delà du parsing, la manière dont les implémentations alternatives est faite consiste à appeler le C original. Je base cela sur ce qu’on peut par exemple voir pour les bindings en
from cffi import FFI …external create …{-# LANGUAGE CPP, ForeignFunctionInterface #-} …Cela étant dit, le projet est là depuis au-moins 2008, sous la houlette de David Lutterkort, employé de Red Hat. Donc, j’imagine qu’il y avait des contraintes corporate à se reposer sur du C pour des tâches pareilles. En plus, le regard qu’on peut porter sur des outils durant cette décennie n’est pas certainement le même qu’il y a deux décennies.
Un petit détour sur le langage en soi avant de terminer. Ses types primitifs sont
unit,string, regexp,lens,tree, etfilter. Faire de REGEX un type primitif, même en se limitant à du POSIX étendu, en prenant en plus le soin de contrôler quelles sont les regex qu’on acceptera, ça reste un choix que je qualifierais de hack. Quand on crée un langage de toutes pièces, au lieu d’évacuer un problème (d’expressivité peut-être) dans des regex, autant enrichir la syntaxe du langage qu’on est de toutes façons en train d’inventer.En tout cas, merci d’avoir posté sur Augeas, ces satanés travaux d’Héraclès, on finira par les terminer, quelle que soit la configuration !
Traduction libre d’une célèbre citation. ↩
Je donne mes impressions en première approximation, je découvre la chose, je commettrai certainement des erreurs qu’une familiarité avec Augeas permettrait d’éviter. ↩
En reprenant les notations mentionnées dans le journal. ↩
[^] # Re: Où est l'intérêt ?
Posté par gipoisson . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à -1.
damaki :
Cela est bien entendu plus proche d’un caviardage que d’une citation, mais je le fais pour signaler qu’un glissement vers un biais cognitif ne serait pas éloigné. Le post antérieur a bien caractérisé les choses :
barmic :
Voilà ! Un seul clic sur le site du langage et en promenant la souris au-dessus de la section “Packages”, on se rend compte qu’Ansible & Kubernetes, entre autres, ont une place de choix dans les efforts de promotion. Encore une fois, sur le fond technique, l’échange s’est asséché même si les choses ne sont pas si arides : envisager les coûts d’une migration, certes avec réticence, laisse penser qu’on reconnaît du bon quelque part.
Alors, dans le plan de conquête ultime du monde, lorsque l’avant-garde sera en train de ramer, peut-être que des renforts seront envoyés incognito de ta part :) Moins légèrement, quant aux planifications de nature de celle en discussion ici, puisque visiblement ça te tient à cœur, parlons-y : comment y procèdes-tu d’habitude ? À la Geoffrey Moore ? À la John Kotter ? Ou alors à la Clausewitz ?
[^] # Re: Où est l'intérêt ?
Posté par gipoisson . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à 1.
Sur le fond, il est incertain que je pourrais ajouter quoi que ce soit. Voici donc quelques lignes qui rentrent dans la catégorie « style/goût ».
Simplicité (lecture). La forme normalisée de Dhall est tellement simple qu’elle s’explique en une courte phrase : entre
{}se trouve un ensemble hétérogène, entre[]un ensemble homogène, le reste constitue des valeurs primitives.Simplicité (programmation). C’est un langage très limité. L’exemple de ce qui est possible sur les
Texts est très parlant : on ne peut que les concaténer. L’originalité n’est clamée nulle part car, en fin de compte, on pourrait dire que tous les langages de haut niveau seraient des DSL autour de l’Assembleur qui, soi-même, serait un DSL autour du Code Machine, … :)Pertinence & Apport. Je trouve qu’à chaque fois que la correction, la précision sont augmentées grâce à un outil, ce dernier devrait de facto faire partie des choix possibles dès que ses alternatives imprécises étaient considérées. Mais là, on bifurque dans le normatif et des eaux troubles …
Donc, dont acte des objections, merci de la conversation.
[^] # Re: Où est l'intérêt ?
Posté par gipoisson . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à 3.
La personne qui avait la dalle est bien servie, dis donc !
L’origine du nom donné au langage est tout aussi facétieuse, voir ici. L’ancêtre du langage est Morte, une appellation encore rigolo ; Morte a un front-end nommé Annah … et on aura deviné ce qui a inspiré cette appellation !
[^] # Re: Où est l'intérêt ?
Posté par gipoisson . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à 4.
Il semble que nous sommes d’accord que le YAML est problématique.
Maintenant, sur les points où tu objectes, pourrais-tu donner des détails ?
Les types de Dhall ne sont pas là seulement pour émettre des jugements du genre « on attendait un nombre réel et on en a reçu un. » Ils participent de la fiabilité globale qu’une conf Dhall vous donne. Tu connais certainement des joyeusetés du genre XML entity expansion, sujet largement traité à propos de XML. Regarde ce que ça donne quant au YAML. Les schémas ne protégeront pas de cela à moins de restreindre les fonctionnalités de la norme à implémenter.
Par conception, une expression Dhall qui a été validée
Les vérificateurs de schémas ne peuvent pas garantir cela, ici également par conception. C’est implicitement de cela dont je voulais évoquer quant à la validité.
Tout cela peut paraître péremptoire de loin. Sur le site officiel, il y a des explications plus détaillées de beaucoup d’autres choses que ce qu’un journal ou un commentaire peut couvrir. Au fur et à mesure que le côté formel sera exploré, tu verras que la fiabilité de Dhall n’est pas une stratégie de marketing ou quelque chose du genre.
[^] # Re: Où est l'intérêt ?
Posté par gipoisson . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à 0. Dernière modification le 20 mai 2020 à 15:53.
Sur la YAML et dans ces colonnes, voir par exemple ce fil, divers points de vue y sont présentés.
[^] # Re: Où est l'intérêt ?
Posté par gipoisson . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à 3.
Programmer la configuration, la valider strictement, la découper en petits morceaux sans crainte que le fusionnement éclatera, etc.
C’est imbibé de la syntaxe des langages comme OCaml et Haskell.
Les annotations de types sont là pour augmenter la lisibilité. Le fichier à lire est celui qui est normalisé si on ne veut pas voir les étapes ayant conduit à générer la configuration.
Le YAML n’est ni facile à lire ni à implémenter. Le journal comporte un lien sur une page qui expose succinctement où le bât blesse avec le YAML.
[^] # Re: Sinon
Posté par gipoisson . En réponse au journal Fraise ou Clementine ?. Évalué à 1.
Je compte une dizaine de distributions sur cette page-là.
Pour avoir traîné ici depuis longtemps, je dirai qu’il y a une forte concentration de Debian-istes sur LinuxFr ; c’est peut-être ton cas et comme
lollypopn’est pas dans Debian Stable, tu aurais trop rapidement extrapolé.[^] # Re: Au début était la flemme…
Posté par gipoisson . En réponse au journal `smk`, un make sans Makefile. Évalué à 6.
Comme le journal évoque Sénèque, voir aussi son L’Oisiveté. J'ajoute un journal dédié au thème, The Idler ! Ici par exemple, on attribue ceci à Bill Gate : “[…]an unwritten rule attributed to Bill Gates from the software industry: hire lazy programmers. Why? Lazy programmers will figure out the smartest way to get something done to avoid having to do it.”
[^] # Re: Oui mais
Posté par gipoisson . En réponse au journal Non, l'inférence de types n'est pas du typage faible. Oui, elle rend les programmes plus lisibles. Évalué à 3.
Dans mon cas, les deux probabilités sont nulles grâce à deux options de configuration :
-Wno-missing-signatures-Wmissing-signatures[^] # Re: Oui mais
Posté par gipoisson . En réponse au journal Non, l'inférence de types n'est pas du typage faible. Oui, elle rend les programmes plus lisibles. Évalué à 5. Dernière modification le 21 novembre 2018 à 23:10.
Dans l'absolu, ce n’est pas une mauvaise pratique de mettre les signatures car, pour moi au moins, elles font partie de la documentation.
Cependant, selon le code sur lequel l’on travaille et pendant la phase « brouillon » du code, mettre systématiquement des signatures reviendrait à toujours rouler sur un vélo la tête dans le guidon. En effet, les besoins immédiats ont tendance à faire écrire des signatures (et implémentations) mono-morphiques même là où cela ne comporte aucun avantage. Et plus tard, par exemple, il n’est pas rare de se rendre compte que des implémentations « obtuses » respectivement de type
FooetBaront beaucoup de ressemblances ; on se mettra alors à faire du refactoring a posteriori alors qu’il aurait été inutile si l’on avait écrit une implémentation plus générale du premier coup. Il y a d’autres cas plus gênants, voire limitants, qui peuvent arriver quand on met systématiquement les signatures mais c’est presque toujours lors d’usages avancés de Haskell (donc à un stade où l’on n'a plus besoin des recommandations d’un quidam sur DLFP).En gros, je trouve plus efficace de se défaire des signatures pendant la phase « brouillon » du cycle de vie d’un code et de les mettre au moment où le code passe en mode release. Mes 2$.
[^] # Re: Théorie des patches
Posté par gipoisson . En réponse au journal Pijul 0.11. Évalué à 2.
La théorie est utilisable indépendamment de Darcs. Ce dernier est lui aussi utilisable, mais c’est vrai que certaines de ces commandes sont lentes si elles sont appliquées sur un dépôt très vaste, typiquement des dépôts de la grandeur d’un compilateur grand public ou d’un noyau de même nature. Par contre, sur de petits et moyens dépôts, Darcs est tout à fait rapide. Et quelle que soit la taille des dépôts, ses simplicité et élégance à l’usage sont AMHA des atouts à considérer.
Aussi, la compréhension de la théorie des patches n’est-elle pas nécessaire pour se mettre à Darcs. Ceci est un récent fil de discussion (en anglais) qui comporte des éléments de comparaison entre
Git,MercurialetDarcs. Dans la discussion, Ben Franksen est le nom de la personne qui, à mon avis, en connaît le plus sur leDarcsde ces dernières années que n’importe qui d’autre, le mainteneur officiel du projet inclus.