Michaël a écrit 2935 commentaires

N'importe quel document avec une biblio. Si tu modifies le .bib, il faut en général une seule recompilation (après un bibtex/biber bien senti) […]

Mon approche est plutôt de ne compiler q'une seule fois le document pendant sa période de mise au point puis de le compiler un nombre suffisant de fois lorsque le document est finalisé. Faire le nombre minimum de compilations ne fait pas partie de mes objectifs.

Mon cv inclus ma liste de […] Je t'avoue que les raisons profondes me restent assez mystérieuses…

Je voulais parler d'un exemple avec des sources, que je puisse utiliser. Je ne vois pas pourquoi ce nombre de compilation devrait être aléatoire. On peut obtenir un document équivalent en générant la partie dynamique dans un fichier dédié, donc du point de vue de LaTeX, c'est une source comme les autres.

Parce que ta dépêche, intéressante au demeurant, prétend qu'on peut préparer des documents latex avec ton outil, ce qui est faux. Même pour des documents se contentant d'un format classique avec biblio, ton système ne peut pas déterminer à chaque fois et automatiquement le bon nombre de passes (j'ai l'impression de me répéter), sans parler des dépendances. Et c'est énervant car quand on cherche sur internet, on trouve tout un tas de pseudo-solutions comme la tienne qui ne fonctionnent pas.

Tu as des exemples concrets de documents qui sont mis en défaut par une approche naïve? Ou une méthode pour les produire?

Sous FreeBSD il y a une sorte de SVGALIB (LIBVGL) que reconnaît SDL et qui permet d'utiliser mplayer en ligne de commande, dans les vieilles consoles:

sudo SDL_VIDEODRIVER=vgl mplayer -vo sdl -nofs monfilm.mkv

Cela fait plusieurs années que je n'ai pas essayé, mais ça a eu marché.

Donc, je récapitule, non, on ne peut pas compiler efficacement du latex en gérant ça avec un outil de make généraliste, oui, il existe un outil spécifique qui fait ça très bien et qui est intégrable dans un workflow plus complexe.

Et qu'est-ce qui t'empêche d'écrire ça dans ton premier commentaire? La partie “workflow plus complexe” n'est pas assez mise en avant dans la dépêche?

(je me tamponne, pour être honnête)

Au fait, merci pour cette précision vachement utile!

Je ne suis pas certain de bien comprendre la question. Je soupçonne que tu demandes comment intégrer latexmk dans un makefile.

Pour reprendre la conversation, je propose un outil qui résoud un problème, tu dis que cet outil n'a aucun intérêt parceque latexmk fait déjà tout en mieux… C'est donc normal que je te demande d'expliquer comment traiter avec l'outil que tu proposes, les problèmes que je résous avec le mien.

Au final ce pourrait peut-être intéressant d'utiliser latexmk dans bsdowl mais c'est assez loin de ton discours. En fait non, mais tu sais dire à la fois

C'est marrant comme cette idée de faire des makefiles pour compiler du latex reste ancrée dans les esprits… Et pourtant, ça ne marche pas.

et

Je n'a pas testé et je préfère un makefile dans ce cas là (qui utilise latexmk pour la compilation, bien sûr).

Nous sommes d'accord, mais en quoi ça t'empêche d'utiliser localement celui que tu veux ?

Ça ne m'en empêche pas et c'est ce que je fais. Pour mes collaborateurs, c'est plus intéressant d'avoir une liste de fichiers

article-2014-01-07.pdf
…
article-2014-06-23.pdf

que

article-rf5gbda.pdf
…
article-qpr3rd1.pdf

Une date est une information simple que tout le monde comprend.

C'est marrant comme cette idée de faire des makefiles pour compiler du latex reste ancrée dans les esprits… Et pourtant, ça ne marche pas.

Ça marche très bien au contraire.

1. la gestion des dépendances qui est manuelle dans ces solutions : on est en 2014 !

Ce n'est pas une fatalité! Dans BSD Make il y a un mode meta qui surveille les processus fils pour déterminer la vraie liste de dépendances (tous les fichiers lus). C'est un sujet avancé et avec lequel je n'ai pas encore expérimenté mais c'est prévu pour la version 3.0 de BSD Owl.

1. le choix du nombre de passes qui est aussi manuel alors qu'il doit être adaptatif en latex (index, biblio, packages tordus, etc.)

Dans BSD Owl, c'est ajustable. Chaque passe a un nom, et la variable MULTIPASS énumère les passes à faire:

MULTIPASS= aux ref final

Si ton package nécessite plus de passes, il suffit d'éditer cette variable dans le Makefile:

MULTIPASS= aux ref extrapass final

Les noms des passes sont écrits dans les messages mais n'ont pas d'autre fonction.

Bref, il existe depuis longtemps une solution qui fonctionne parfaitement : latexmk. Et contrairement à ce que son nom pourrait laisser croire, c'est un programme spécifique (en perl) pas un machin basé sur un make généraliste. Il gère les dépendances automatiquement (rapport à être en 2014, hein) en utilisant des hashs pour ne pas recompiler après un simple touch, détermine le nombre de passes nécessaires automatiquement, et est configurable dans tous les sens pour s'adapter à la complexité d'un workflow latex.

Peut-être que tu pourrais expliquer rapidement comment on utilise latexmk pour compiler un document contenant des figures ou une table générée par un script?

Ceci mis à part BSD Owl est un système de build généraliste qui ne se limite pas du tout aux documents LaTeX. Pour le monde LaTeX on peut aussi s'en servir pour écrire et installer des classes de documents LaTeX avec noewb (un outil de programmation lettrée). On peut aussi s'en servir pour compiler et installer des tas de choses.

Je vis aussi en 2014 et je vois qu'aucun des mille-et-un systèmes de build vachement meilleurs que make ne l'a détrôné. Mon analyse est que pour être vraiment généraliste un système de build doit permettre facilement d'accéder au shell et à ce niveau là, impossible d'être plus fort que make. Ensuite make est utilisé pour le build de systèmes d'exploitation entiers (au moins les BSD) ce qui démontre que le programme est largement utilisable en milieu industriel si on peut dire. Ce qui manque à make est une bilbiothèque de Makefiles portable et flexible, problème que je souhaite résoudre avec BSD Owl.

Je ne dirai pas ce que je pense vraiment de l'horodatage pour les versions, histoire de rester poli.

Bon passons, …

Disons simplement qu'on ne fait généralement pas du latex pour des documents jetables. Alors écrire sa thèse sans utiliser un gestionnaire version, c'est tellement con à pleurer qu'on se demande comment le contenu pourrait être intéressant. Une des bonnes solutions est bien sûr git et gitinfo.

Apparemment tu n'as pas lu le paragraphe Brouillons et traitements multiples.

Dans mon expérience de la recherche et de l'écriture de documents, je suis amené à collaborer avec des personnes qui ne connaissent pas les SCM et ne souhaitent pas forcément apprendre leur fonctionnement. Et puis ceux qui connaissent les SCM ne veulent pas forcément apprendre tous les SCMs du monde.

Dans la pratique quand je montre un travail préliminare à des amis ou des collaborateurs, l'horodatage permet à ces derniers de facilement repérer d'entre plusieurs versions quelle est la plus récente. De mon côté, je peux utiliser la date pour retrouver la version correspondate dans mon SCM.

Qu'est-ce que tu veux installer à la main? Il y a un package bmake dans arch Linux et tu peux donner à tes collègues un petit script d'installation du style

mkdir install-bsdowl
wget https://github.com/michipili/bsdowl/releases/download/v2.2.1/bsdowl-2.2.1.tar.xz
tar tf bsdowl-2.2.1.tar.xz
cd bsdowl-2.2.1
./configure --prefix=/usr/local
bmake -r all
bmake -r install

à éxécuter en root. Si tu es motivé par l'écriture d'un paquet pour Arch, cela devrait être assez facile — en survolant le guide j'ai l'impression qu'il s'agit de quelque chose de pas très bureaucratique.

Merci pour ton enthousiasme! Si tu as des problèmes, n'hésite pas à en parler ici ou sur l'issue tracker du projet!

PS: GNU Make n'est vraiment pas super, à mon sens.

Merci à BAud, palm123, Snark et Benoît Sibaud pour leur aide et leur relecture!

Pourquoi pas, où est-ce qu'il faut regarder? Est-ce que tu as une référence qui décrit bien le calcul que tu veux implémenter?

Salut!

Tout d'abord bravo pour ton projet, c'est un sujet très intéressant. Quand est-ce qu'il y aura Bonn dans ta démo? ☺

Je pense que l'algorithme de recherche de plus court chemin est très éloigné de ce qui est utilisé en réalité. Les algorithmes de type Dijkstra ou A* sont des algorithmes généralistes mais ici notre graphe est assez loin d'être aléatoire, c'est un réseau routier et il y a beaucoup de structures supplémentaires qui ne sont pas forcément faciles à décrire mathématiquement — parceque difficile à identifier — mais dont on peut tirer parti.

À mon avis il est beacoup plus efficace d'essayer d'imiter ce que fait un être humain pour déterminer son trajet face à une carte:

1. On détermine une série d'étapes intermédiaires en les choisissant parmi une liste prédéfinie.

2. On calcule un plus court chemin entre ces étapes.

3. On résout le problème en partant de plus courts chemins reliant ces étapes intermédiaires en utilisant une méthode de simulated annealing pour améliorer la première approximation.

Le 1 correspond assez bien à la façon dont on s'oriente: pour un trajet dans une ville on s'oriente grâce aux grandes avenues et places principales par exemple. Pour ton on exemple, on peut choisir des étapes de référence indépendemment de critères de fréquentation, en prenant un maillage relativement large (par exemple une tous les 1km).

Le 2 est plus rapide entre les étapes intermédiaires parceque on peut abandonner rapidement les recherches infructueuses (si deux étapes sont distantes de 1,5 km et que mon chemin fait plus de 3km je peux l'abandonner — ou le mettre de côté pour l'instant). Comme les étapes sont prédéfinies on peut précalculer certains chemins.

Le 3 permet d'ajuster l'approximation obtenue en 2, le simulated annealing se prête bien à ce genre d'optimisation.

On peut imaginer plein de variantes — par exemple différents niveaux d'étapes intermédiaires correspondant aux échelles du voyage (quartier, ville, région,…), et très certainement c'est une bonne idée de partir de plusieurs approximations initiales.

Et sinon, il ne faut pas hésiter à demander sur le salon IRC qui va bien (#debian-mentors sur OFTC).

Pas facile d'accès…

(11:04:09) You have been kicked by ChanServ: (Invite only channel)

À la fac de maths en 97 j'ai appris le Scheme et le C.

Qu'est ce qui ne te plaisait pas avec Scheme et qui t'a poussé à définir ton propre langage?

• Scheme est un langage simple très adapté à l'apprentissage de l'agorithmique.

• Si tu veux traduire les mots-clefs tu peux probablement le faire avec des macros — mais je ne vois vraiment pas trop l'intérêt, l'anglais s'apprend à l'école et ceux qui ont choisi d'autres langues peuvent bien apprendre 4 mots et demi.

• Si tu veux le faire tourner dans un Browser, il y a déjà des implémentations, comme par exemple BiwaScheme.

C'est en effet un chouia plus déclaratif,

Ça montre en effet assez bien qu'on peut utiliser le shell pour l'init sans manger des tartines comme celles que montre http://forkfedora.org/.

mais ça reste du shell.

Ben oui, forcément! ☺

la possibilité de faire de l'analyse statique. […]

C'est peut-être plus facile de faire ce genre d'analyse avec le fichiers de systemd mais a priori rien n'empêche de faire ce genre d'analyse. Cela demande d'imposer des conditions de forme sur les scripts d'inits, mais si c'est un objectif du projet rien n'interdit de l'implémenter. Un exemple de cette approche est la commande portlint(1) qui analyse les Makefile des ports pour faire de la QA — probablement très élémentaire.

la possibilité de fusionner proprement 2 fichiers. […]

Effectivement. L'approche typique serait probablement de dupliquer et éditer le fichier.

Je rebondis sur ton témoignage, puisque tu as l'air de t'y connaître:

Est-ce que hackintosh est un projet libre et “propre” (pas de backdoor etc.)?

Est-ce que je peux installer dans une VirtualBox?

J'ai repidement regardés quelques tutoriels qui demandent tous d'installer une image “customisée” venant de je-ne-sais-où, préparée par je-ne-sais-qui et contenant je-ne-sais-quoi… Est-ce qu'il y a une méthode pour fabriquer cette image soi-même à partir d'un disque d'installation normal?

Apparemment toi et Albert êtes amis de longue date! =)

T'y va fort sur les procès d'intention.

Un peu oui! Pour détendre l'atmosphère, souvenons-nous de ce sketch des Monthy Pythons!.

est écrit gratuitement, sans sous-entendre "l'autre c'est moins bien", pas du tout.

C'est écrit factuellement, pas gratuitement.

Mais bien sûr…

Ben oui.

Dit-moi donc pourquoi tu as écrit "qui sont donc facile à aménager comme on veut".

Parceque c'est vrai et que la personne qui écrit présente un élément comme un avantage systemd sur sysv qui n'en est pas un, les avantages sont ailleurs.

Je vais te révéler un secret : […]

Sympa. Qu'est-ce qui est faux dans ma déclaration factuelle? Tu semble répondre à une déclaration “systemd c'est caca” que je n'ai pas écrite.

Et systemd se place à ce niveau. Tu peux faire des scripts shells si tu veux, mais le défaut va vers l'industrialisation.

Un peu comme sous FreeBSD, quoi: les scripts d'init sont essentiellement déclaratifs, mais cela reste des scripts shells, qui sont donc facile à aménager comme on veut.

j'ai mieux The Great Wyrm of Space-Time

Hé, on parlait de Nethack! ☺ Dans Nethack le dragon noir est un des meilleurs! Angband je n'ai jamais vraiment beaucoup joué, seulement à ToME 2.X, mais cela ne date pas d'hier — Nethack non plus d'ailleurs!

Ah, ah! As-tu déjà utilisé un dragon noir comme monture? ☺

C'est peut-être une affaire de goût, mais je préfère écrire

return (a > b) - (a < b);

que la version avec l'opérateur ternaire.

Tu as du rater cette passionnante discussion:

https://linuxfr.org/users/chat_de_sorciere/journaux/pourquoi-ecrire-un-package-debian-est-il-si-complique

Oui bien-sûr, je relève simplement que le contenu ne se réduit pas à une insulte, le message dit aussi: «Cette erreur est HÉNAURME.»

Comme je l'ai écrit, je ne suis pas super fan de l'insulte mais je trouve que le message de Linus reste très franchement dans des limites acceptables: ce n'est pas mon caractère mais ça ne me dérange pas de travailler avec des gens qui ont ce caractère.