anaseto a écrit 2229 commentaires

Je suis pas trop sûr de comprendre. En pratique (par exemple vu les exemples du journal), les tags ça pourrait être capitales et nom-de-plantes, et puis un tag all qui regroupe tout. Du coup, effectivement, un navigateur devrait pouvoir filtrer par tags ; puis après peut-être raffiner le filtre des cartes ayant ces tags par regexp sur le contenu ou je sais pas quoi pour en choisir une à éditer — c'est le cas d'utilisation que j'avais en tête en parlant de navigateur. Mais le graphe serait souvent vraiment très simple : plus de deux ou trois tags par fait, c'est rare et, par contre, pour une configuration de tags données, il y a par contre beaucoup de faits.

J'avoue que pour l'image, j'ai pas été très pédagogique, capture d'écran direct de ce que j'avais sur le moment :)

Et je n'ai pas pensé à décrire dans le journal le détail de l'interface de morji. Comme l'image le montre, en tapant ? on voit l'aide, et l'aide, c'est juste une liste de raccourcis accompagnés d'une description. Ça donne quelque chose comme :

Keys (on current card): 
  q      show current card question again
  space  show current card answer
  a      grade card as not memorized (again)
  h      grade card recall as hard
  g      grade card recall as good
  e      grade card recall as easy
  E      edit current card
  D      delete current card's fact
Keys: 
  ?      show this help
  N      new card
  t      select tags with glob pattern
  T      deselect tags with glob pattern
  r      rename a tag
  s      show cards scheduled in next days
  S      show statistics
  I      import file of facts with tab separated fields
  Q      quit program

Donc, en particulier, on vote en tapant a, h g ou e, et on affiche la réponse avec la touche espace. Certaines actions sortent des invites de commandes spéciales, comme t et T pour sélectionner ou déselectionner des tags.

Eh bien, pour n'importe lequel des exemples du journal (les capitales ou le cactus), dans le champ Question: on a la question, et dans le champ Answer: on a la réponse. Donc par exemple :

Question: France
>>
Answer: Paris

Le >> suivi de rien correspond à avoir tapé sur «espace» pour afficher la réponse.

Je t'accorde que l'exemple de la nimage est un peu spécial :) Un gismu ça veut dire, grosso-modo, «verbe» en Lojban, et l'exemple correspond à la définition d'un verbe (un peu exotique) dans le champ Question: avec en réponse le mot qui correspond.

Pour l'anecdote, «morji» est un gismu qui signifie «se remémorer» et dont la définition (simplifiée) dans le dictionnaire Lojban ressemble à x1 se souvient de x2 :)

Le but de la manœuvre étant de retenir le contenu des cartes et bien écrire les cartes aide à les mémoriser..

Je ne sais pas trop où tu veux en venir. En effet, en général c'est mieux d'écrire soi-même ses cartes, même si suivant le type de contenu d'autres stratégies peuvent marcher aussi. Mais l'écriture des cartes, c'est la partie apprentissage + compréhension, qui est évidemment nécessaire et c'est celle qui prend le plus de temps. Le logiciel permet ensuite de décider quand réviser cette carte : il se débrouille pour te faire faire un peu plus de 5 révisions sur la première année en moyenne, révisions qui, en moyenne, prennent pas plus de quelques secondes, donc moins d'une minute si on compte l'ensemble des révisions d'une carte. C'est là qu'est tout l'intérêt du logiciel : ne pas perdre du temps à réapprendre ce qui nous a pris du temps à mémoriser initialement.

De la même manière qu'on s'est rendu compte que ceux qui écrivaient leurs notes de cours retenaient mieux le cours par rapport à ceux qui les tapaient sur un ordinateur.

J'ai lu ce genre de choses, mais aussi le contraire, et je pense sincèrement que ça dépend beaucoup du type de contenu à mémoriser (mathématiques, littérature, langues, histoire ?), de la personne et de son affinité avec les deux méthodes et son utilisation correcte des dites méthodes (par exemple, quelqu'un qui passe au clavier parce qu'il avait du mal avec les prises de notes à la main utilisait déjà à la base peut-être de mauvaises techniques et va continuer à en pâtir au clavier), du contexte et des méthodes pédagogiques du prof si c'est un cours (cours parlé, écrit au tableau, slides, rapide ou lent ?), qui peuvent s'avérer plus ou moins adaptées à un type de prise de notes ou un autre, etc.

Peut-être qu'un jour un contributeur zélé réécrira txt2tags en go !

Peut-être :) Ceci dit, c'est pas sûr que le système d'extension par substitutions deviendrait rapide pour autant : outre des questions de langages, c'est le principe en soi qui est problématique, les expressions régulières de Go sont pas plus rapides que celles de Python. Mais je t'accorde que c'est pas du tout ce qui m'a fait écrire frundis qui, au début, a servi à remplacer pandoc et la question de la performance m'était même pas venue à l'esprit et, pourtant, c'était bien plus lent que txt2tags ;) (qui au fond, vu son fonctionnement, est relativement rapide).

Et mes ePUB générés par ce biais seront sans doute plus propre qu'une bonne partie des ePUB commerciaux qui font souvent n'importe quoi.

C'est bien possible, j'avoue ne pas avoir réussi à produire de l'EPUB valide du premier coup, ni du deuxième :) Mais vu que l'EPUB, c'était quand même le format le plus important pour frundis, je voulais pouvoir contrôler le truc et pas dépendre d'un outil tiers comme Calibre ; remarque en passant, Calibre garantit que l'EPUB est correct uniquement si le XHTML source l'est, il faut donc quand même vérifier avec epubcheck après.

Sans doute qu'un script qui analyserait plus finement le texte pour souligner expressément tout ce qui lui semble hors norme.

C'est un peu comme les langages de programmation, d'un côté ceux qui offrent des garanties à la compilation et puis les autres qui se contentent d'heuristiques, donc effectivement, il est un peu question de sensibilité :) Mon impression, c'est que c'est un peu plus dur de tester automatiquement des textes que du code, mais j'avoue ne pas m'être penché sur la question sérieusement ; j'ai bien quelques scripts vite-faits pour détecter des trucs suspects que frundis détecterait pas lui-même —scripts qui ont bénéficié du fait que le langage soit facile à parser—, mais c'est tout.

Toutes, toutes, j'ai pas l'impression, au point que je sais pas par où commencer :)

Déjà, j'ai écrit le fichier suivant (avec des espaces au début pour les headers) :

=Title=                                             

=Title==                                                                                                                                          

A test file with //emphasis.                                                                                                                       

A test file with //emphasis/.                                                                                                                      

A test file with /emphasis//.

Eh bien, j'ai aucun message d'erreur. Tout est correct ! Le premier titre apparaît balisé, le deuxième apparaît tel quel avec les signes =, et dans le texte on a les / tels quels. Même sans imaginer le cas où on utilise plusieurs fois de l'emphase dans un même paragraphe… on est pas sortis de l'auberge pour trouver des erreurs dans un gros document !

Et puis, les extensions du langage, c'est à coup de substitutions… pas étonnant aussi, le langage est implémenté à coup d'expressions régulières ;) Mais ça ne fait que accentuer cette impression qu'on peut pas faire trop confiance au résultat et qu'il faut tout vérifier à la main à chaque changement. Et d'ailleurs, pas étonnant du coup non plus que ça rame un peu. Pour un fichier avec seulement A test file with //emphasis//. répété cent mille fois, c'est 7 secondes, là où pour la même chose frundis fait une demi-seconde ; et il y a des chances que si on se met à utiliser ses propres substitutions par dessus le langage de base, ça ne fasse qu'empirer.

Ceci dit, je suis d'accord qu'il y a des trucs positifs par rapport au markdown, comme pouvoir inclure des fichiers facilement et le fait qu'il n'y a qu'une seule implémentation, donc une seule variante du langage. On dirait que c'est ok aussi niveau dépendances. Mais ça reste un langage « léger », c'est-à-dire un monde à part optimisé pour des usages différents, avec les avantages, mais aussi les inconvénients qui vont avec. Ceux qui me tiennent particulièrement à cœur sont l'absence de messages d'erreurs et la grammaire compliquée et irrégulière ; il en découle aussi qu'en l'absence d'un langage plus formel on se retrouve à inventer des syntaxes ad hoc pour les extensions et la configuration, qui ne simplifient pas spécialement le langage. Enfin, aussi, il y a le coté très « forme mélangée avec le fond » : dans les éléments de balisage par défaut du langage, la plupart s'intéressent à la forme (gras, italique, etc.), ils ne sont pas sémantiques, ça n'encourage pas ni n'aide à faire des documents cohérents d'un point de vue balisage.

PS: j'ai pas vu d'export EPUB, donc je suppose qu'il faudrait d'abord exporter vers autre chose puis utiliser un deuxième outil. Un peu étonnant, parce que quand on sait faire de l'html, il n'y a plus grand chose à faire pour produire de l'EPUB.

Il me semblait avoir vu passer ça, mais sur le moment j'ai cru que c'était un peu trop bas niveau. En fait, il me semble qu'il y a à peu près tout ce dont j'aurais besoin. Ceci dit, vu que j'ai l'export vers mom déjà pour les cas où TeX Live n'est pas installé, ça refroidit un peu mon enthousiasme :) Un autre détail, c'est que ça s'éloigne peut-être un peu de la philosophie du langage, qui est d'exporter vers d'autres langages et permettre à l'utilisateur, s'il connaît le langage cible, de pouvoir peaufiner. Mais je vais y penser, merci du pointeur !

Question classique en effet :) Et pas forcément facile, tellement il y a d'arguments d'ordres différents, allant du technique au subjectif et parfois les deux en même temps, un peu comme pour les langages de programmation !

Ceci dit, un point de départ pour comprendre les spécificités de frundis, c'est qu'initialement l'objectif étant de pouvoir exporter des romans à la fois en LaTeX et EPUB, il fallait surtout ceci :

• Des tags sémantiques spécifiques à un projet : DocBook est très centré documentation uniquement ; là il fallait pouvoir définir facilement des tags pour nom de lieu, pensée, nom de plante, etc. Pas forcément beaucoup d'éléments sémantiques pour un document donné, mais pas évidents à prévoir. Du coup, en frundis on écrit une espèce de feuille de style simplifiée pour chaque format d'export.
• J'avais par contre besoin aussi de poèmes, et DocBook faisait pas ça la dernière fois que j'ai regardé.
• Personaliser facilement et finement les exports LaTeX et EPUB, c'est-à-dire pouvoir donner soi-même facilement des commandes pour un préambule LaTeX ou les fichiers d'en-tête EPUB au besoin, tout en fournissant des trucs raisonnables par défaut également. Pour le coup, je sais pas si avec asciidoc/DocBook on peut faire ça, peut-être, pas vérifié vu qu'il manquait d'autres trucs.
• Macros textuelles et variables, surtout pour éviter certaines redites, partager et structurer des choses entre divers documents ; mais macros limitées : pas de macros qui définissent des macros ou d'autres horreurs du style, parce que ça rend moins accessibles les messages d'erreurs et le langage en soi ; bon, « horreur », c'est relatif, mais pour mes utilisateurs actuels ça le serait :)

Et puis, arguments techniques ou subjectifs, ou les deux, je sais pas :

• Langage simple. Au sens, la documentation complète doit être accessible (donc aussi suffisamment courte) à quelqu'un qui connait un peu LaTeX et HTML, mais ne sait pas forcément programmer ni a de connaissances techniques poussées. Il ne faut donc pas que le langage définisse des éléments spécifiques de base : à chacun de définir ceux dont il a besoin pour son projet ; du coup, ça veut dire que ça doit être facile à faire, sinon c'est raté.
• Gestion des erreurs de syntaxe intuitive, rapide et qui nous protège d'erreurs non intentionnelles. Il s'agissait donc un peu de la philosophie opposée à markdown, où tout fichier texte est valide : avec frundis il s'agit d'avoir des garanties que les éléments sont correctement fermés, etc., pas de typos qui gâche un paragraphe sans faire exprès : vérifier un texte court, ça va, mais vérifier tout un roman à la main, ça fait un peu plus peur ;)
• Rapide : utile pour refaire tous les fichiers HTML d'une page web et avoir un retour immédiat. Aussi quand on exporte vers LaTeX : on a les messages d'erreurs avant, ça évite d'essayer de compiler avec LaTeX quand c'est perdu d'avance parce que frundis à râlé ; enfin, frundis fait de son mieux pour corriger et produire des trucs corrects même quand le fichier source ne l'est pas.
• Facile à installer : pas de dépendances (je me répète un peu avec le journal).
• Documenté avec le langage mdoc pour faire des pages man que j'adore ! (d'ailleurs on sent un tout petit peu l'influence dans frundis…)

…Et puis sans doute d'autres trucs auxquels je pense pas de suite, moins importants ou que je sais pas comment dire.

J'avais vu passer le truc, par contre merci pour le lien, je savais pas que le sujet avait été débattu aussi longuement, en prenant compte des stats d'utilisation des différents paths et tout :) Ceci dit, je vais laisser les instructions telles quelles pour le moment, go 1.8 date à peine d'il y a quelques mois.

J'ai par contre maintenant une explication : ça n'arrive uniquement avec le build par défaut, qui est prévu pour débugger. Si on active les optimisations, on obtient 1 sans erreurs.

En fait non, ce n'est pas dû au .unwrap() (64 parse bien), mais bien à l'overflow, comme le précise le message d'erreur.

$ awk 'BEGIN{print(rshift(1,64))}'
1
$ perl -E 'say 1 >> 64'
0
$ tclsh8.6
% expr {1 >> 64}
0
$ cat main.go
package main

import "fmt"

func main() {
        fmt.Println(1 >> 64)
}
$ go run main.go
0

rust se démarque un peu : il n'en veut pas.

$ cat main.rs
fn main() {
    println!("{}", 1 >> 64);
}
$ rustc main.rs
error: bitshift exceeds the type's number of bits, #[deny(exceeding_bitshifts)] on by default
 --> main.rs:2:20
  |
2 |     println!("{}", 1 >> 64);
  |                    ^^^^^^^

error: aborting due to previous error

Et si on lui passe un nombre non constant qu'il peut pas prévoir, on a un crash.

$ cat main.rs
use std::env;

fn main() {
    let args: Vec<_> = env::args().collect();
    let n: i64 = args[1].parse().unwrap();
    println!("{}", 1 as i64 >> n);
}
$ rustc main.rs
$ ./main 64
thread 'main' panicked at 'attempt to shift right with overflow', main.rs:6
note: Run with `RUST_BACKTRACE=1` for a backtrace.

C'est curieux, parce que j'ai l'impression que tous les points que tu mentionnes s'appliquent uniquement à de la pub officielle ou au minimum plus ou moins directement par un candidat, ce qui n'est pas le cas dans ce journal : il dit qu'il est pas content, et savait pas quoi voter ou juste pas voter, ce qui semble le genre de question qu'on a le droit de poser le jour de réflexion (jour un peu absurde d'ailleurs en un certain sens, parce que ça laisse sous-entendre qu'on a pas trop réfléchi avant, comme si un jour de réflexion en plus était censé changer quelque chose). Donc si les articles disent vraiment juste ce qu'il y a dans ces points là, j'ai l'impression qu'on vient d'avoir un cas d'auto-censure inutile.

En l'occurrence, je pense qu'ici, dans tous les cas, le comportement est bien défini par tous les langages du fil (par exemple si awk renvoit 4 c'est parce qu'il utilise la fonction de la libc standard strtod pour produire un nombre à partir d'une chaîne, c'est documenté dans le manuel). Le message d'erreur et son style par contre peuvent dépendre dans une plus ou moins grande mesure du compilateur (par exemple gcc vs clang pour le C/C++).

J'avais pas bash chez moi, donc je pouvais pas tester, et sur le moment j'avais en fait cru à un poisson :) Et puis non, c'est juste que t'avais oublié les guillemets (c'est censé être une erreur de syntaxe ^^). Du coup, j'ai découvert qu'on pouvait spécifier la base avec $((1 + 2#11)) qui renvoit 4 ;)

Eh bien, faut pas chercher un truc très profond. Ce qui est intéressant, c'est qu'observer la réaction d'un langage sur cette simple opération en dit pas mal sur ses particularités : typage statique ou non, typage fort ou faible (tous vs C/C++), style objet, système de type à la fonctionnelle ou typage plus simple (par exemple Ruby vs Haskell vs Go), surcharche d'opérateur ou non, opérateur qui coercitionne les arguments en fonction de la valeur de retour ou choisit la valeur de retour en fonction de ceux-ci (Perl vs Javascript), qui essaye de deviner ou non ("3a" vs "3") (awk vs lua), stacktrace par défaut ou non (sbcl vs guile), messages d'erreurs pensés pour débutants ou connaisseurs, etc.

Rust n'est pas un langage très simple, mais il me semble (je suis juste un peu de loin le langage) qu'ils sont en train de faire des efforts pour le rendre plus accessible (dans la limite du possible avec un langage aussi ambitieux, bien sûr). En cherchant rapidement, je suis tombé sur un article Shape of errors…, donc peut-être que les messages d'erreurs sont plus amicals maintenant (ma version de rust doit dater de mi-2016).

1 + 3a: valeur trop grande

Haha, j'adore !

Par contre, sous OpenBSD, km/h c'est 10 m, pas le truc fantaisiste que t'obtiens. Et le calcul est simple : km/h == 1000 * m / 100 :)

Pourtant, km marche :

Je pense que c'est parce que «h» c'est pour «hecto» aussi, donc pour les heures c'est «hr» ou «hour». Par exemple units km/hr m/s marche correctement chez moi (avec le units d'OpenBSD, mais j'imagine que ça doit être pareil).

Je sais pas pour vous, mais ces changements de licenses m'inquiètent un peu.

Il n'y a qu'OpenSSL qui veut changer sa licence. Le mail de Theo est une blague qui fait référence à ce mail, où OpenSSL contactait les contributeurs en terminant par cette phrase fantastique : « If we do not hear from you, we will assume that you have no objection. ».

En l'occurrence, de ce que j'ai compris, ce serait plutôt un petit overhead une fois par requête. Ce qui veut dire qu'en pratique, si ton serveur fait des requêtes qui prennent plus de temps que renvoyer un Hello World, la régression est négligeable. En vrai, dans le fil personne ne donne des tests sur des cas plus réalistes, donc c'est difficile d'évaluer vraiment l'impact. Ceci dit, étant donné que les rc de go sont utilisées par google en production pendant plus d'un mois avant, on peut imaginer qu'ils auraient remarqué depuis si la régression impactait en pratique les vrais serveurs, et pas seulement les serveurs de test qui font des Hello World.

Je me suis aperçu que j'utilisais un ksh-isme (il n'y a pas que les bashismes qui existent !). C'est maintenant corrigé dans le dépôt, et les scripts fonctionnent avec bash.

Autre chose : en relisant la description de l'outil fzf que je fais, je me rends compte que je précise pas clairement que fzf est un outil écrit en go interactif (ncurses), qui s'actualise avec la frappe (comme la barre de firefox, ou dmenu, etc.).

ne nécessite pas de remplacer tout usage du cd built-in par le fasd_cd.

En fait, j'arrive pas trop à comprendre comment il obtient l'historique de cd, mais bon, ça marche :)

Edit : en fait, il utilise fc -nl ou history pour reconstruire, on dirait. C'est pas immédiat comme truc.

Je viens de tester, ça a l'air pas mal, en effet. Ceci dit, je crois que je vais rester avec mon d et mon o pour plusieurs raisons.

La principale, c'est que la recherche « intéractive » de fasd n'est pas vraiment intéractive (peut-être l'est-elle avec bash ou zsh, je sais pas, même si j'en doute). Au sens, avec fzf, même avec des dizaines de milliers d'entrées, au fur et à mesure qu'on écrit on a en temps réel instantanément et sans bloquer l'interface (concurrent) une sélection qui se fait en fonction du chemin, pas besoin de taper un un numéro en regardant une liste, ni d'essayer de prévoir à l'aveugle si on a bien intuité le motif qui réduit la recherche (dans fasd comme dans autojump, d'ailleurs). Et même avec des milliers d'entrées, quelques touches suffisent à sélectionner un item en pratique. Et o a l'avantage qu'il ne nécessite pas d'avoir visité quelque chose avant : si c'est un dépôt git, il fera git ls-files, si c'est un dépôt fossil, fossil ls, et sinon il lance ag -g "" (ou find avec de bonnes options si le silver searcher ag n'est pas là) ce qui permet d'éviter quand même pas mal de fichiers qui n'ont pas l'air d'être du texte.

Du coup, en pratique, on fait d jusqu'à un répertoire, puis o pour sélectionner un fichier : en fait, o est parfois même utilisable directement depuis le $HOME avec un disque dur non ssd grâce à la limitation de profondeur de recherche lorsqu'il sent qu'il y en a trop. Avec un disque dur ssd, limite tout ça est presque inutile.

En fait, fzf est tellement fort, qu'il n'a même pas vraiment strictement besoin (même si ça aide) de quelque chose comme o ou d : si locate a sa base de données actualisée, parfois on peut se contenter de fzf uniquement : locate / | fzf ; avec mon ordi pas terrible c'est faisable, même si avec un petit délai : avec plus d'un million de fichiers, en écrivant juste quelques lettres on trouve en fait ce qu'on veut assez vite.

La deuxième raison, moins importante, c'est que d est un peu plus simple et ne nécessite pas de remplacer tout usage du cd built-in par le fasd_cd.