anaseto a écrit 2229 commentaires

Il y a un « ajouter des tag arbitraires" » avec un " au lieu d'un *, ce qui fait qu'une phrase part en italique… si un modérateur veut bien corriger, je lui en serai reconnaissant !

Et de deux le mail c'est juste horrible à administrer, entre les whitelist/greylist/backlist, les anti-spam à configurer et le fait que du jour au lendemain tu peux te retrouver dans un liste de spam type spamhaus et consort à cause d'un faux positif.

Perso, j'ai jamais eu aucun problème avec le mail : d'abord avec postfix, maintenant avec OpenSMTPD (conf d'une dizaine de lignes qui n'a jamais changé). Je fais rien pour le spam (j'en reçois vraiment très rarement), et je n'ai pas l'impression d'avoir été blacklisté nulle part jusqu'à présent. Je me demande si j'ai juste eu beaucoup de chance jusqu'à présent (plus de deux ans), ou si c'est qu'il y a moins de spam ces dernières années, mais le mail c'est vraiment pas ce qui me cause le plus de soucis.

C'est juste qu'il ne me trouve pas certains includes comme (clang 3.5), je ne pense pas que ce soit un bug. J'ai jamais fait de C++ sur OpenBSD, mais je suppose que pour quelqu'un qui sait, ça doit être juste lancer make avec un flag en plus.

Bon, j'ai compris pourquoi, finalement : la version de clang d'openbsd vient sans la libc++, tout simplement !

Surprenant, parce que l'auteur indique que clang est supporté (mais peut-être ta version est-elle trop vieille?). Quels étaient tes messages d'erreur?

C'est juste qu'il ne me trouve pas certains includes comme <cstdint> (clang 3.5), je ne pense pas que ce soit un bug. J'ai jamais fait de C++ sur OpenBSD, mais je suppose que pour quelqu'un qui sait, ça doit être juste lancer make avec un flag en plus.

Quel fichier, pour quel include? Il devrait être possible de faire ça plus proprement et de soumettre un patch.

Non, ça c'est dans file.cc, où une façon non portable pour récupérer le chemin de l'exécutable est utilisée, mais c'est pas un bug : c'était prévu pour lancer une erreur si l'OS n'est pas Linux, Cygwin ou OSX. Comme j'avais pas envie de réfléchir à comment on peut faire sur OpenBSD ça facilement, je l'ai mis en dur. A priori j'aurai pensé à argv pour ce genre de choses.

Ce que tu décris est plutôt une problématique d'encodage amha.

Pas vraiment, qu'un éditeur (ou langage) supporte utf8 pour beaucoup d'opérations ne veut pas dire que ça va être aussi le cas de ses expressions régulières, elles travaillent probablement au niveau des "bytes" sans se soucier d'encodage.

Ah, effectivement, merci du conseil ! Sur vim je n'y avais pas fait attention, parce que, même si l'affichage était retardé, c'était comme si c'était juste l'affichage.

Pas mal le clang.kak !

Je sens que je vais continuer à utiliser kakoune, au moins de temps en temps, puis je m'y mettrai peut-être vraiment à un moment si j'ai un peu de temps. D'ailleurs, les plugins ont l'air plus faciles à faire qu'avec vimscript, et j'aime bien la philosophie assez minimaliste de kak, et le fait que kakoune n'est pas un monstre de quelques centaines de milliers de lignes, contrairement à vim.

Ahh, alors pour inverser le sens, c'est alt-f et alt-t. F et T vont étendre la sélection (d'une manière générale, les commande majuscules étendent la sélection plutôt que la remplacer, W par exemple étend la sélection jusqu'au début du prochain mot)

Ah, cool.

Au passage, l'utilisation de alt (plutôt que ctrl) est due au fait que ctrl ne supporte ni les majuscules, ni toutes les touches (dans un terminal j'entends).

En plus, ctrl est moins accessible. J'aurai plutôt pensé à une combinaison de deux touches normales (comme pour les g*).

Puisque j'en suis à décrire mon expérience, un autre détail que j'ai remarqué : quand j'écris du texte, puis fais <esc>, il y a un petit timeout (normal), mais si j'écris rapidement d'autres lettres après <esc> sans attendre un minimum, celles-ci sont interprétées dans le mode insertion et insérées dans le texte, et pas interprétées dans le mode normal après le <esc> (c'est pas comme ça dans vim).

Par curiosité, quels plugins vim te manquent ?

Eh bien, je n'ai pas vu de choses comme ultisnips (celui-là je l'aime bien), ou syntastic (mais ça je peux m'en passer la plupart du temps, à part pour faire du OCaml, où j'aime bien). C'est peut-être facile à faire, j'ai pas trop étudié la question. Après, dans les trucs plus particuliers, j'ai pas trouvé par exemple de coloration pour Perl (mais j'avoue que ça ne doit pas être très amusant à faire).

aller jusqu'au prochain char existe, et c'est comme vim (f et t). À moins que tu fasse reference à une autre fonctionalité ?

Oui, quand j'ai écrit je ne me souvenais plus trop, mais ce qui marche pas (mais j'ai peut-être pas trouvé, et il y a un équivalent), c'est "F" et "T", pour faire dans l'autre sens (j'ai l'impression que ça fait la même chose que sans majuscules), et ";" pour répéter au cas où on cherche la deuxième occurrence.

En tous cas, malgré ces petits détails, je trouve ton éditeur de texte très original, et plus accessible que vim grâce à son côté intéractif, et les commandes "g*" sont plus faciles à utiliser (avec vim j'ai tendance à avoir des trous de mémoires pour faire certaines de ces choses), même si je me plante et j'utilise le dollar quand il faut pas, par habitude.

Bonne chance pour la suite !

En tous cas, il faut une version de gcc assez récente. Je l'ai compilé sur OpenBSD et j'ai du installé le gcc des ports (en même temps, sur OpenBSD de base ils n'actualisent plus les versions gcc depuis longtemps). J'ai pas réussi avec Clang, par contre, mais vu que j'y connais très peu, c'était peut-être juste qu'il manquait le bon flag. Sinon, j'ai du faire aussi un hack tout moche dans un des fichiers source (mettre un chemin en dur), mais ça devrait pas être nécessaire sous Linux.

Mon impression est que c'est original, le langage est vraiment orthogonal, et le fait de pouvoir splitter une sélection avec une expression régulières en plein de petites sélections est pas mal du tout. Après, en pratique, je ne trouve pas que ça change tant que ça, c'est juste un peu plus intéractif (donc sans doute plus facile à apprendre, parce qu'on voit la sélection à laquelle on applique la commande). L'aide intéractive pour les commandes est pas mal au début… mais je me demande si à la longue c'est pas lourd (c'est pas très discret), et j'ai pas vu comment la désactiver. Un vrai inconvénient, c'est qu'il manque encore beaucoup de choses pour que ce soit utilisable pour tous les besoins : les expressions régulières, par exemple, sont un peu basiques (. ne matche pas un caractère utf8, mais un byte, ils ont déjà un tiquet sur ça : j'espère qu'ils iront vers du pcre ou quelque chose de mieux), il manque des petites commandes typiques que j'utilise en vim couramment (aller jusqu'à tel ou tel caractère et des choses comme ça), et pour les plugins c'est un peu dans les débuts. Les performances sont correctes, il me semble (mais j'ai pas fait de vrai test pour comparer avec vim). J'ai pas remarqué de bugs flagrants, à part une assertion ou quelque chose comme ça qui a raté à un moment avec un petit panneau d'erreur, mais j'ai pas réussi à reproduire ensuite (j'ai pas trop fait attention sur le moment à ce que je faisais, vu que je testais un peu au pif).

Il y a un truc que j'aime pas trop, c'est que certains raccourcis passent par alt (ce qui a le mauvais goût d'entrer en conflit avec mon gestionnaire de fenêtres), mais bon, c'est possible de remapper, donc pas vraiment un problème, a priori.

J'ai pas non plus beaucoup testé, il manque trop de plugins dont j'ai besoin, mais le concept est décidément original (même si je ne suis pas sûr personnellement de préférer autant d'intéractivité par rapport au mode ex de vim).

Ce n'est qu'une solution qui doit être mise en synergie avec d'autres, puisque la méthode ultime n'existe pas (foutu théorème de Rice).

On peut s'en approcher, par exemple, si on réussit à programmer et prouver en Coq 99% (pourcentage à la louche) du programme dans les restrictions imposées par un langage non Turing-complet. Il restera, bien sûr, toujours un 1% où d'autres méthodes seront nécessaires. Après, je ne pense pas qu'il y ait beaucoup de programmes en dehors des systèmes vraiment critiques pour lesquels une telle approche soit raisonnable.

Surtout que du reste ils donnaient l'air assez professionnel. Un indice de trop, peut-être ? Ça me rappelle le coran oublié dans la fourgonnette lors des attentats de Madrid.

Eh bien je pense que Zenitram a raison sur le problème d'appartenance à un groupe. Le fait de vouloir appartenir à un groupe (quel qu'il soit, religieux, politique, équipe de foot, etc.), c'est la peur de devoir assumer ses propres opinions, et de mon point de vue c'est ce qui cause le plus de soucis à l'humanité depuis des millénaires. Après, si la spiritualité en question est purement personnelle, plus en lien avec des principes issus de réflexions personnelles auxquelles on attache de l'importance, c'est autre chose, en effet.

ces langages de markup diminuent considérablement l'expressivité pour de la facilité.

En même temps, les langages de markup qui produisent du LaTeX visent d'habitude un sous-ensemble de types de documents, à la manière d'un DSL, donc c'est normal que l'expressivité soit sacrifiée pour l'accessibilité et la facilité. Mais il n'y a pas que ça : ils sont aussi souvent pensés pour produire d'autres formats comme html, donc ce n'est pas vraiment comparable. Exporter de LaTeX vers autre chose c'est tout sauf évident, et le résultat n'a aucune chance d'être optimal (de loin), car c'est difficile de conserver la sémantique.

Bref, je suis peut-être subjectif vu que j'ai fait un langage de markup produisant du LaTeX moi-même, mais je ne trouve pas que ce soit forcément une mauvaise solution pour un bon panorama de documents et, même, au contraire, ça donne la possibilité d'avoir une sémantique plus riche à la fin lors de l'export vers d'autres formats (bon, pour markdown ce n'est pas le cas, je te l'accorde). Après, LaTeX reste irremplaçable pour beaucoup de documents, je suis d'accord (même si souvent troff pourrait être utilisé a la place, mais je ne sais pas trop si c'est vraiment plus accessible, pour le coup).

il n'y a pas de tables

Finalement j'ai rajouté un support basique pour les tables. Au passage, j'ai corrigé quelques erreurs dans les pages mans, la page de titre automatique et les tables de matières en epub.

Je ne vois pas trop pourquoi, frundis n'a pas l'intention de devenir un quelconque standard : il a été conçu pour des besoins assez spécifiques, puis j'ai juste pensé que, au cas où ça pourrait être utile à d'autres, j'allais partager. Je dirais qu'au contraire, frundis ne réinvente pas trop la roue : il se contente d'être, pour certains types de documents, un bon langage source pour exporter vers des formats qui eux sont assez standard, et le script perl en question fait même pas trois mille lignes (bon, il y a les tests et les pages man aussi), et ça m'a pris tout juste un peu plus de deux semaines de travail.

En effet, que le code source ressemble au résultat ne fait pas partie des objectifs de frundis, ça aurait rendu impossible certaines choses à moins de compliquer énormément l'analyse du programme (le parseur de frundis est très simple, et rapide à l'exécution) et l'apprentissage du langage, alors j'ai préféré utiliser une syntaxe qui a déjà fait ses preuves, et dans laquelle la différence entre le texte et les commandes est la plus claire possible, donc de ce point de vue c'est assez à l'opposé du markdown, tout à fait. Ceci dit, la plupart du texte d'un roman écrit en frundis ne diffère du markdown que par le fait que les lignes blanches contiennent .P ou .D au début.

Je suis curieux de savoir quelles sont les limites de Markdown rencontrées.

Je crois qu'on a écrit en même temps, et que mon message du dessus répond (au moins en partie), à ta question ;)

Du coup, je ne comprend pas cette phrase :

Par cette phrase j'entendais que pour écrire du "pur" markdown tu n'as pas besoin de connaître le langage cible. Avec frundis tu définis dans le préambule des tags (en pur frundis), dans lesquels tu dois préciser l'élément html ou la commande LaTeX qui sera utilisée pour le rendu, puis tu l'utilises ensuite en pur frundis, sans avoir à répliquer pour les différents formats. Et puis, frundis permet aussi de distinguer l'epub de l'export en html, et d'inclure certaines choses que pour l'un ou l'autre.

En fait, il y a plusieurs raisons.

Tout d'abord, les objectifs ne sont pas vraiment les mêmes : groff et ses macro-packages sont plus à comparer avec TeX et LaTeX, c'est un programme complexe, qui fait un excellent travail pour produire un document final de bonne qualité typographique. Tout comme LaTeX, c'est difficile à apprendre, il y a énormémement de pages de man, des commandes pour contrôler le moindre espace, etc, mais pour l'export html (ou epub) beaucoup de ces choses ne sont pas utilisées, et ce n'est pas évident à partir du code groff de prévoir à quoi va ressembler le html produit. Ce qui aurait du sens serait d'exporter de frundis vers groff pour produire une sortie ps ou pdf, mais vu qu'exporter vers LaTeX remplit des objectifs similaires, ce n'est pas trop une priorité. Et un avantage de frundis pour la sortie html, c'est qu'il ne doit pas passer par un de ces gros programmes.

frundis de son côté est un langage sémantique qui permet de prévoir exactement comment seront le html et le LaTeX produits : quelles commandes seront utilisées, quelles classes, etc.. frundis se limite à être un langage intermédiaire plus dans l'esprit de markdown, mais avec la possibilité d'ajouter des infos sémantiques arbitraires : par exemple, dans le Cycle de Shaedra, il y a des tags spécifiques pour les dialogues mentaux, les noms de lieux, les noms de livres, les noms des chansons, les phrases dans une autre langue, etc. et dans le préambule frundis il y a une définition explicite de comment seront rendus ces tags en latex et xhtml, ce qui permet pour ce dernier de faire un css qui tienne compte de ces différences.

Je pense que ce qui se rapprocherait le plus de frundis, ce serait d'écrire directement en html ou un format xml inventé, et d'exporter vers les différents formats cible avec des feuilles de style. Ceci dit, frundis permet d'inclure dans le fichier lui-même des informations pour dire que telle ou telle macro ne doit s'utiliser que pour un certain format, ainsi que de définir des macros, et le langage est moins lourd à l'écriture.

Ensuite, je l'ai aussi fait parce que ça m'amusait ;)

Ce que je trouve, c'est qu'avec haskell, il y a beaucoup de choses simples dans d'autres langages qui sont enrobées de choses compliquées, et pas forcément faciles à retenir au début. Et puis certaines choses qu'on estime de base, pour lesquelles on a des syntaxes spéciales dans d'autres langages (tableaux, chaînes de caractères et tables de hachages) ne sont pas plus pratiques à utiliser que des choses moins courantes. En fait, la seule structure de base vraiment pratique à utiliser en Haskell, c'est les listes chaînées.

Mais le plus gênant, c'est quand tu crois que tu commences à connaître le langage et que tu tombes sur du code qui utilise des Lens, Arrows ou autre et tu t'aperçois qu'en fait, non :)

et probablement moins efficace que d'utiliser substr et des indices

Bon, test sur un roman de plus de trois cent pages, j'obtiens :

0m0.55s real     0m0.53s user     0m0.01s system (version récursive)
0m0.55s real     0m0.54s user     0m0.02s system (version python du journal)
0m0.47s real     0m0.45s user     0m0.02s system (ta version)

Comme quoi, ça change pas grand chose, et dans tous les cas, c'est clair que les langages de script sont pas fait pour travailler sur du texte caractère à caractère.

ensuite je me demande si on peut pas de faire a coup de regex récursive ;)
(t)ru(C) => C(r)(u)t => Curt, à rechercher du coté de la recherche des palindromes (du point de vu de la logique)

Je vois pas trop comment on pourrait s'en sortir avec des regexps récursives, car elles servent uniquement à matcher. Peut-être en utilisant des blocs ?{...} pour insérer du code dans la regexp. Par contre, on peut s'en sortir en faisant une fonction récursive :

#!/usr/bin/perl
use strict;
use warnings;
use open qw(:std :utf8);

sub zorglangize {
    my $text = shift;
    if ($text =~ /(\p{Alphabetic})(\p{Alphabetic}*)(\p{Alphabetic})/) {
        my ($first, $middle, $last) = ($1, $2, $3); 
        return (($first =~ /\p{upper}/) ? (uc $last) : (lc $last))
            . zorglangize($middle)
            . (($last =~ /\p{upper}/) ? (uc $first) : (lc $first));
    } else {
        return $text;
    }
}

while (<>) {
    s/(\p{Alphabetic}+)/zorglangize($1)/xeg;
    print;
}

mais c'est un peu tordu… et probablement moins efficace que d'utiliser substr et des indices. Mais c'est marrant quand même :)

On a un changement des majuscules interne au mot, ce n'est donc pas équivalent au code initial

Pas faux, j'avais pas pensé que les majuscules à l'intérieur des mots étaient à prendre en compte de cette façon.

Pareil (si je dis pas de bêtises), mais sans boucle :)

#!/usr/bin/perl
use strict;
use warnings;
use open qw(:std :utf8);

while (<>) {
    s|(\p{Alphabetic})(\p{Alphabetic}*)|
        my ($first, $rest) = ($1,$2);
        ($first =~ /\p{upper}/)
            ? (ucfirst reverse $rest) . (lc $first)
            : (reverse $rest) . $first
    |xeg;
    print;
}

Hum.. je me trompe si je dis que ce que tu dis n'est valable que pour l'option {} si l'on utilise \; et non + en fin de commande?

Disons qu'en pratique le cas \; correspond à -n 1 et le cas \+ à ne pas mettre d'option. Ce n'est pas tout à fait exact, mais dans \+ de toutes façons, seul le dernier {} est pris en compte. Après avec -I il y a des limites de longueur à prendre en compte, en plus. Il n'y a pas une traduction parfaite entre les deux commandes non plus, c'est juste qu'en pratique on peut faire avec l'une ce qu'on veut faire avec l'autre, normalement.

J'ai un peu lu au sujet de IFS, mais il semble que cette variable ne s'applique qu'a la fonction read, les autres outils utilisant indiféremment -f, -F, ou rien du tout (le plus souvent?).

IFS est aussi utilisé pour la substitution de variables, mais je ne sais pas si ça t'aide.

Pour répondre au reste, je ne suis pas sûr de comprendre exactement ce qui te gêne, mais personnellement je n'aurais pas de scrupules pour utiliser un « autre langage » comme awk, sed ou perl quand ça m'a l'air plus adapté, je ne fais jamais du traitement de données non trivial purement en shell (et j'avoue que pour ça j'aurais besoin de consulter mes pages mans et réfléchir un moment). En plus le résultat a toutes les chances d'être plus lent et plus complexe au final, vu que ces autres langages sont pensés et optimisés pour ce genre de problèmes.

Eh bien xargs dans l'idée c'est juste d'utiliser stdin comme source d'arguments pour une commande. Par défaut les séparateurs c'est les espaces/tabs et retours à la ligne :

$ echo '1
> 2 3
> 4' | xargs echo
1 2 3 4

équivalent à un echo 1 2 3 4. Tu peux limiter le nombre d'arguments avec l'option -n pour qu'il exécute plusieurs fois echo.

$ echo "1 2 3 4" | xargs -n 2 echo
1 2
3 4

Et l'option -I de xargs, par exemple, permet de faire la même chose que le {} du -exec de find.

$ echo "1 2 3 4" | xargs -I XXX -n 2 echo XXX XXX
1 2 1 2
3 4 3 4

qui remplace XXX par la ligne d'arguments.

Bref, xargs peut faire la même chose que -exec, mais est plus général (peut se combiner avec d'autres commandes).

Là où le bât blesse, c'est que pour les fichiers c'est pas idéal (ils peuvent contenir des espaces), donc par défaut xargs n'est pas bon pour utiliser la sortie de find. C'est pour ça que find a une option -print0 pour mettre des \0 entre les noms de fichiers plutôt, et xargs une option -0 qui définit le séparateur comme \0 aussi, et du coup ils peuvent travailler ensemble de façon sûre.