boubou a écrit 1384 commentaires

Comme ça a déjà été dit, il ne faut pas confondre le format org (qui peut ressembler de loin à du markdown) et org-mode qui est un mode emacs avec toutes les fonctionnalités que cela apporte en général.

Même si on se focalise sur le format, il faut voir que org est facilement extensible avec la notion de propriétés (au sein des drawers) et avec celle de blocs. On peut grosso modo mettre des méta données sur les sections (les propriétés) et définir ses propres blocs. En ce sens, la syntaxe org est beaucoup plus riche que celle de markdown car extensible et avec méta données (deux choses qui ne sont pas possibles en markdown, en tout cas pas simplement). On a aussi une notion de macro très simple à utiliser, et bien d'autres extensions comme des liens typés, etc.

Au niveau du mode lui même, on dispose, comme souvent en emacs, de nombreux points d'entrées qui permettent de gérer les extensions dont je viens de parler, et ce très facilement. Je suis une brêle totale en elisp et j'ai pourtant étendu très facilement org avec des blocs à moi que j'exporte ensuite en HTML toujours à ma sauce. C'est d'une souplesse et d'une puissance très emacsienne.

Bref, aucun rapport à part en surface, en gros.

Macron est l'une des rares personnes a comprendre le fonctionnement de l'économie au gouvernement. Sans vouloir politiser le débat, il serait bien que les décisions politiques soit pesées autrement qu'en terme d'image pour le partie ou de votes pour la prochaine élection.

Ton commentaire est très intéressant car il contient une partie tout à fait vraie selon toute vraisemblance (Macron a une certaine compréhension des différentes théories macro/micro économiques et c'est probablement le seul dans le gouvernement) et il sous entend quelque chose de discutable (voire de faux). En effet, tu sembles dire que la vision néolibérale de l'économie de Macron est justifiée par sa compréhension de l'économie. Or, c'est justement le cœur du débat politique. On sait grosso modo quelles pourraient être les conséquences du politique d'inspiration libérale en France, en gros ça serait l'Allemagne post Schröder, avec une réduction du chômage payée par une grosse casse sociale (retraités pauvres, travailleurs pauvres qui ont deux emplois, etc.). Le choix de cette solution devrait être discuté, argumenté, pondéré. Mais aujourd'hui, on a un gouvernement « de gauche » qui tend vers cette solution (de droite, comme Schröder à l'époque), sans débat et avec un soutien certain dans la population basé sur deux raisons 1) certains croient les promesses des néolibéraux 2) d'autre pensent qu'il faut laisser faire celui qui sait, comme s'il ne faisait pas des choix politiques. Amusant cette confusion entre la connaissance objective et les choix politiques…

C'est super linuxfr en ce moment : d'abord de la pub pour les brigandes et maintenant pour égalité et réconciliation. L'extrême droite identitaire ferait-elle de la propagande même ici ?

Belle illustration du fait qu'on ne puisse pas «convenir» avec toi.

Et paf, les pieds dans le piège à loup. Le meilleur moyen de ne pas avoir une discussion constructive est d'essayer d'interpréter les motivations des gens plutôt que ce qu'ils écrivent. Par exemple, ici, le fait que tu te focalises sur l'Humanité (d'une façon erronée, mais bon…) plutôt que les brigandes pourrais m'amener à essayer d'inférer tes opinions politiques, etc. Mais au fond, 1) je m'en fous, 2) ça n'apporte rien à la discussion.

Et pour y revenir, tu racontes n'importe quoi sur l'exemple de mein kampf et en plus ça n'a pas grand rapport avec le problème de fond qui est de citer un groupe inconnu antisémite comme exemple dans un article technique.

Je te prie d'abord de ne pas penser à ma place et ni de faire de la psychologie à deux centimes du genre « impossible de convenir » (qu'en sais-tu ?). Tu remarqueras que je n'ai pas cédé à ce type d'interprétation à ton sujet alors qu'on pourrait facilement le faire (je te laisse deviner pourquoi).

Et justement, comme je ne m'intéresse pas à tes motivations, que je serai bien en peine de déterminer, ce qui m'intéresse est le résultat. Et juxtaposition est comparaison, que tu le souhaites ou non.

Ce qui me gène sur le fond n'est même pas la comparaison, pour être honnête. On peut bien sur rire de la bêtise crasse des brigandes et de celle de leur suffisants chaperons sur les vidéos, mais leur propos sur la compagnie de jésus relève assez clairement de l'anti-sémitisme. Et que c'est interdit par la loi : on peut aussi débattre de la pertinence de cette interdiction, mais faire de la publicité à ce type de propos est pour le moins discutable, ne serait-ce que d'un point de vue légal.

Et bien sûr, rien ne t'obligeais à mettre des exemples (personne n'est profondément débile ici, on comprend sans exemple), ni à les choisir comme ça.

Suis-je le seul à être surpris (voir choqué) de la comparaison implicite entre l'humanité et les brigandes ? Parce que d'un côté on a un journal relativement sérieux, qui peut parfois avoir des positions outrées (comme le figaro ou valeurs actuelles pour prendre des exemples de droite) alors que de l'autre on a un groupuscule chrétien identitaire et intégriste, dont les délires sur les jésuites (par exemple) sont clairement antisémites, sans parler de la « chanson » sur le remplacement. J'imagine que c'est de la provocation à deux balles…

En plus, je ne sais pas qui est allé pêcher les brigandes, mais il semble bien qu'elles ne soient connues que dans la sphère identitaire et super réactionnaire, avec quelques mentions chez Dieudonné. Bravo donc à linuxfr pour cette petite publicité…

Loin de moi l'idée de défendre Science et vie en général, mais pour le cas spécifique de la mémoire de l'eau de Benveniste, le journal a attaqué dès le début les conneries publiées dans Nature (cf Mémoire de l'eau). Il a même été condamné pour diffamation, n'ayant pas pu prouver leur affirmation que Benveniste avait triché sur les résultats. En revanche pour la Fusion froide, le journal a en effet été assez sensationnaliste, au moins au début des conneries de Fleischmann et Pons.

On t'a déjà répondu en dessous, mais j'en rajoute une couche.

euristiques liées à ton processeur qui deviendront fausse dès la prochaine génération

Mais non !

1) c'est stable depuis des années (cf en dessous). Le coût de la mémoire cache rapide est délirant contrairement à celui de la mémoire lente. C'est très bien expliqué dans l'article de Drepper.
2) les méthodes dont je parle sont « cache oblivious » c'est-à-dire qu'elles travaillent sur le principe de la hiérarchie mémoire, pas sur les valeurs fines des caches
3) pour les bibliothèques open source, les réglages fins sont faits à la compilation (cf atlas). Pour les bibliothèques propriétaires (genre MKL intel), il a plusieurs versions. Matlab intègre par exemple ces bibliothèques super optimisées.
4) la prédiction de branchement n'a pas grand impact sur les codes intensifs en calcul. En outre, son amélioration est impossible sans introspection. Il faut faire tourner le code de base instrumenté, puis donner le résultat au compilateur pour qu'il améliore le code par la suite. C'est ce que fait la JVM et c'est expliqué pour le C dans l'article de Drepper.

des algo compréhensible par les compilateurs de façon à se qu’ils optimisent

Ceci me semble bien naïf. Un compilateur compile, il ne comprend rien. Surtout si c'est du C qui est un langage peu structuré que les compilateurs ont beaucoup de mal à optimiser (comparé à du fortran, par exemple). Et à ma connaissance, aucun compilateur ne tient compte aujourd'hui des schémas d'accès à la mémoire, au moins pour les langages de bas niveau. En revanche, le C++ et ses expressions templates ou scale et ses DSL permettent de faire ça. Il faut bien sûr se pogner la bibliothèque de bas niveau qui fait ça.

De plus, tu occultes le fait que tout le monde n’a pas une puce Intel et que dans ce cas, il faut aussi optimiser pour AMD, faire un algo spécial pour chaque ARM, etc.

Non, cf le code d'Atlas (qui a exactement été conçu pour résoudre ce problème, il y a plus de 10 ans).

C’est envisageable quand tu fais de l’embarqué, que tu connais ta cible pour de l’applicatif PC, c’est de la masturbation intellectuelle. C’est ce que je disais dans un autre commentaire, c’est intéressant pour le sport, pour le défi, mais ça n’a aucune importance pour ça.

Mais bien sûr. Je te suggère d'en discuter avec des développeurs de jeu dont l'influence sur le hardware est considérable (pas de jeu, pas de cartes Nvidia qui crachent du teraflop/s). Et plus généralement, qui de sérieux peut cracher sur un facteur 10 ?

Pour produire des trucs hyper spécifiques comme une bibliothèque de calcul matriciel, ok, c’est envisageable d’investir sur plusieurs CPU, faire différents codes, analyser les performances… mais pour de l’applicatif, ce n’est pas généralisable.

Je ne comprends pas ta remarque dans le contexte de ngix, par exemple.

Je suis d’accord avec toi que ce genre d’article est intéressant pour le garder à l’esprit. Mais il ne faut pas tomber dans le travers inverse à chasser la dernière ns en dépensant 30 jours de développement.

Ah, le bon vieil homme de paille… Je ne parle pas de ça, nom de dieu ! Je parle d'un facteur 10 !!!!

Je vois que tu es universitaire d’après ton lien page perso. Ce qui explique cela. Dans l’industrie, le but est d’atteindre un objectif quantifiable et donc chiffrable en €. Le but n’est plus le sport intellectuel, bien que je le regrette parfois ;-)

Si tu veux faire intervenir la personnalité de ton interlocuteur dans une discussion, ce qui frise à mon avis l'ad hominem et donc n'apporte rien, autant te renseigner sur le dit interlocuteur. Et plus généralement sur l'université. Par exemple, j'ai fait ma thèse dans l'industrie en contribuant (modestement) à l'amélioration d'un radar de Thalès (Thomson CSF à l'époque, ma barbe est grise). J'encadre des doctorants en CIFRE dans des minuscules startup comme Lokad, dans des entreprises moyennes comme Viadeo ou dans des grands groupes comme Orange et Snecma. Nos travaux sur le machine learning dans le cloud, sur l'amélioration de l'estimation des performances d'algorithmes de recommandation, sur l'exploration de grandes bases de données clients ou sur le monitoring des moteurs d'avions sont tous appliqués à des problèmes concrets. Ils sont passés en production dans certains cas. Je pratique aussi la masturbation intellectuelle en faisant des preuves de convergence pour certains algorithmes d'apprentissage automatique. Mais bon, tout ça on s'en fout car ça n'a rien à voir avec la discussion sur l'optimisation de code ! Mais c'est sûr qu'avec une telle mentalité, tu risques de ne pas suivre ce qui se fait en recherche et conserver des habitudes de programmation complètement dépassées.

En général, on optimise pour atteindre un objectif. Si c’est juste pour le sport (passer 1 mois à gagner 3 requêtes par seconde), le code devient crade.

Je ne parle pas de ça, je parle de facteurs 10 à 30. Dans un code intensif en mémoire, c'est-à-dire dès que les données ne tiennent pas dans les caches, le schéma d'accès à la mémoire a une influence cruciale sur les performances. Alors que la puissance normale d'un cœur intel est de l'ordre de 6 Gflop/s (une addition et une multiplication par cycle d'horloge), un code naïf sur l'accès mémoire récupère au mieux du 600 Mflop/s, voire seulement 200 Mflop/s. C'est pourquoi il est indispensable pour du code numérique d'utiliser une implémentation compliquée. Dans un langage de très haut niveau comme le C++, tout est caché dans des expressions templates, ce qui permet de faire du calcul matriciel lisible à très hautes performances. Dans des langages de très bas niveau comme le C, il faut faire les optimisations à la main, ce qui rend les bibliothèques très difficiles à lire.

Dans le contexte du web, on peut aussi gagner des facteurs de l'ordre de 10. Par exemple Varnish utilise des techniques sophistiqués pour faire ça, cf l'article de ACM queue à ce sujet.

Le fond de l'histoire est que pour utiliser vraiment bien le matériel moderne, il faut modifier les algorithmes pour qu'ils respectent les caches, ce qui rend les programmes plus complexes directement au niveau algorithmique, sans parler de l'implémentation.

C'est aussi vrai pour le multithread : pour avoir des structures de données efficaces en multithread, il faut des algorithmes d'une sophistication assez effrayante. Et de nouveau, on n'est pas dans l'optimisation d'une requête de plus ou de moins, mais bien d'un facteur 10. Je conseille vivement à ce sujet le bouquin the art of multiprocessor programming écrit par des pontes du sujet.

C'est marrant, c'est un gros reproche qui est fait à OpenSSL, notamment par l'équipe OpenBSD.

Ba oui et c'est aussi un reproche qu'ils font à ngix, si j'ai bien compris.

Mais un code ne peut pas être « trop » optimisé, dans le sens où une optimisation qui provoque des résultats incorrects n'en est pas une, par définition.

Certes, mais ce n'est pas ce qu'ils disent, comme tu le résumes bien, d'ailleurs. Ils parlent bien sûr de code compréhensible.

As-tu déjà lu un code de calcul matriciel optimisé ? Le produit de deux matrices, c'est vraiment le code plon plon par excellence : une bête triple boucle, rien de plus simple. Sauf que pour que ça fonctionne efficacement, il faut respecter les caches, ce qui demande de faire du « blocking ». En gros, tu calcules le produit des matrices par sous-blocs, ce qui rend le programme nettement moins clair. Ensuite, on ajoute du respect de l'alignement, celui de la TLB (voire de NUMA), les threads, les instructions SSE et autres, et ça devient incompréhensible. L'excellent article de Drepper à ce sujet est plein d'exemples édifiants : le code standard en page 49 et celui un peu optimisé en page 50, puis la version hardcore en page 97. Les écarts de performances entre la version simple et la version optimisée sont incroyables.

Je ne sais pas si ngix utilise du code optimisé à ce niveau de sophistication, mais si c'est le cas, je comprends la frousse des gars d'OpenBSD et l'idée que c'est trop optimisé. Les algos qui respectent les caches sont souvent impanables, ce qui pourrait bien être une source de complexité parmi d'autres dans ngix.

Mouai, sauf que « translation d'adresse », ça veut bien dire (NAT)[https://fr.wikipedia.org/wiki/Network_address_translation] ici, non ? Si c'est le cas, c'est bien une transformation d'une adresse en une autre, pas un déplacement de quelque chose. Et donc dans le contexte, c'est bien traduction qu'il faut mettre.

Deux exemples : ngix utilise un gestionnaire d'allocation mémoire spécifique et n'utilise pas directement (ou pas du tout) la libc pour certaines fonctionnalités. Ça veut dire que l'équipe d'OpenBSD devrait auditer un allocateur mémoire et des fonctions de type libc dont les versions standards dont déjà auditées. Ça ajoute un surcoût et OpenBSD optimise en général pour la sécurité/simplicité plutôt que pour les performances/fonctionnalités (quand la question d'un compromis se pose, je ne dis pas qu'OpenBSD est lent et qu'il manque de fonctionnalités).

Concernant ngix et sa future suppression, il y a une explication du développeur de httpd ici. En gros, l'équipe ne reproche rien de particulier à ngix mais trouve que le code est trop optimisé et loin de leurs pratiques pour qu'ils le maîtrisent. D'où httpd qui est beaucoup mieux intégré au reste du code.

La stratégie de bsdowl consistant à faire un nombre prédéterminé de compilations n'est pas à des années-lumières.

Je t'invite à relire mon message expliquant l'impact d'avoir trop de compilations en terme de perte de temps et donc de tentation pour les utilisateurs d'en faire moins, exactement comme tu le préconises plus haut (une seule compilation avant la phase « finale »).

Et on attend toujours un exemple de document “de la vraie vie” (par exemple une référence sur arXiv.org) qui est bien compilé en 3 ou 4 passes mais mal compilé en 5 passes.

Car bien sûr, j'ai dit que ça existait. J'ai toujours parlé de faire le nombre optimal, je n'ai jamais indiqué qu'il ne fallait pas en faire trop pour des raisons de correction. Le problème est l'efficacité.

d'autant que la discussion ne semble pas vraiment possible.

Certes, cf au dessus.

un aspirant champion du monde en poids et haltères, exhibitionniste, vouant par réflexe un mépris affiché à toutes les approches qui ne sont pas les siennes.

Et est-ce qu'il mange des chats, le mathématicien en question ? Ça manque quand même, sinon.

Pour la petite histoire, la prise de conscience de l'existence de ce stéréotype et du fait qu'il en était lui-même devenu un parfait stéréotype l'ont amené à pratiquement renoncer à sa carrière prestigieuse pour se rapprocher de la générosité et de la curiosité qu'il avait délaissées pendant de nombreuses années, comme il le raconte dans son livre.

Et c'est sûrement par générosité qu'il refuse qu'on publie ses résultats et tout ce qu'il a fait depuis qu'il vit dans une grotte (ou presque).

Et sinon, le rapport avec les makefiles ?

Et en plus, je mange des chats.

Sommaire

• Qu'est que fonctionner dans le contexte ?
• Pas d'automaticité
• Optimalité ou correction, il faut choisir
• L'horodatage est une mauvaise idée
• Conclusion : ça ne marche pas bien

Tu sais, que tu peut défendre l'idée que latexmk est mieux sans dire que le reste c'est de la merde ?

Je me permets de te faire remarquer que je n'ai jamais écrit ça. Tu ne fais peut être pas la différence « truc ne marche pas » et « truc est de la merde », moi si. Mais passons.

Qu'est que fonctionner dans le contexte ?

Je reprends donc depuis le début. Ma compréhension de la dépêche est que l'auteur propose un outil qui aurait deux fonctions. La première est d'assurer la production d'un pdf/ps à partir (notamment) d'un fichier latex maître et de toutes ses dépendances. La deuxième est de faciliter l'interaction avec des personnes qui n'utilisent pas un gestionnaire de version (ou pas le même que l'auteur) grâce à un mécanisme d'horodatage des fichiers compilés qui permettrait de retrouver les sources utilisées pour produire la version partagée. J'affirme que la solution proposée ne fonctionne pas dans des cas classiques et ne lutte pas contre les erreurs humaines classiques (notamment en tournant le dos aux bonnes pratiques en développement logiciel). Mes arguments sont simples et classiques pour quelqu'un qui connaît bien latex. Ce n'est probablement pas le cas de l'auteur qui me présente ensuite comme arrogant quand je lui dis. (mais bon, on s'en fout, l'important c'est que ça ne fonctionne pas).

Je vais d'abord parler de la production automatique du document pdf (pour simplifier, je dirai juste pdf, mais ça pourrait être ps, voire d'autres choses). Mais pour ça, je dois préciser ce que je veux dire par production automatique d'un pdf. Mon point de vue est que je dois pouvoir taper quelque chose comme make toto.pdf et obtenir totalement automatiquement le bon fichier toto.pdf à la fin de l'exécution de la commande. J'insiste sur le fait que ça doit être automatique à chaque fois, quelles que soient mes modifications sur l'ensemble des sources. Et j'insiste sur le fait que ça doit être le bon fichier, pas un machin qui ne tiendrait pas compte de certaines de mes modifications. Et je veux en plus que ça soit fait de façon optimale en temps de calcul. Car latex reste lent : je pense qu'on tourne autour de 50 pages à la seconde sur un PC classique. Si on doit faire 3 ou 4 passes sur une thèse de 200 pages, ça fait 15 secondes, c'est quand même chiant pour juger les effets de la modification d'un paramètre de présentation, par exemple. Et c'est sans packages évolués comme tikz et ses amis avec lesquels on peut descendre à beaucoup moins que 50 pages par seconde.

Si j'insiste sur ces trois aspects, automaticité, correction et efficacité, c'est que je sais par expérience (plus de 20 ans de latex) qu'un compromis engendre des problèmes. Si le processus n'est pas correct, on peut être amené à diffuser un document incomplet ou incohérent. Si le processus est lent (trop de passes), on va contourner la lenteur en réduisant artificiellement le nombre de passes, ce qui rendra le document incorrect (c'est ce que préconise explicitement l'auteur, ce qui un très mauvais choix dont je constate les effets délétères très régulièrement dans mon travail d'édition scientifique). Enfin, si ce n'est pas automatique, on oubliera un jour d'ajouter des dépendances ou d'en enlever, entraînant des problèmes de correction et/ou d'efficacité (trop de compilation ou pas assez). Si les systèmes de production actuels sont si complexes c'est notamment par ce qu'ils visent exactement ces trois aspects avec en plus la reproductibilité.

Pas d'automaticité

Or, la solution proposée n'est pas automatique : en particulier, elle ne gère pas automatiquement les dépendances. L'auteur repousse ça au futur alors que des solutions existent aujourd'hui (comme latexmk ou d'autres comme arara ou Rubber). Au delà du problème classique évident que ça pose dans tout contexte de dépendances entre objets, il y a des cas un peu spécifiques à latex. Prenons un fichier maître comme suit monlatex.tex :

\documentclass{article}
\begin{document}
\include{bla1}
\include{bla2}
\end{document}

et deux fichiers inclus bla1.tex :

\section{Bla 1}
Mon bla 1.

et bla2.tex :

\section{Bla 2}
Mon bla 2.

Avec une gestion de dépendances (automatique ou non), monlatex.pdf dépend évidemment de monlatex.tex, bla1.tex et bla2.tex. Maintenant, imaginons que les deux parties soient volumineuses et donc longues à compiler. Il est classique dans cette situation d'utiliser la commande latex \includeonly qui permet de restreindre la compilation en n'incluant que les parties qu'on souhaite (c'est un peu plus subtil que cela, mais peu importe). J'ajoute par exemple avant le \begin{document} l'instruction \includeonly{bla1} et je recompile (avec latexmk, bien sûr). Comme la mise à jour des dépendances est automatique, celle à bla2.tex est supprimée et aucune modification du fichier ne produit de mise à jour de monlatex.pdf. Au contraire, dès que j'enlève l'appel à \includeonly, la dépendance revient, ce qui est exactement ce qu'on veut. En particulier (et c'est la subtilité au dessus), les labels et autres objets du même type définis par bla2.tex qui étaient conservés et utilisés lors de la compilation réduite à l'inclusion de bla1.tex sont mis à jour automatiquement (donc avec le bon nombre de passes) si besoin est (notamment si bla2.tex a été modifié). Impossible d'avoir ce type de comportement avec la solution proposée.

Optimalité ou correction, il faut choisir

Passons maintenant à l'optimalité. Il faut savoir qu'en latex le nombre de passes nécessaires à l'obtention d'un document correct n'est pas borné à priori. Il existe en fait des documents qui ne sont pas compilables de façon stable. Par exemple (issu de stackexchange) :

\documentclass{article}

\pagenumbering{Roman}
\begin{document}

a\clearpage b\clearpage c\clearpage

\begin{figure}[!t]
\framebox(200,430){}
\caption{a figure to take up space}
\end{figure}


Some interesting text about  something in Section \ref{x},
which starts on page \pageref{x}.

\section{zzz\label{x}}
The text of an interesting section.
\end{document}

Au delà des cas pathologiques, il faut bien comprendre qu'il est impossible de savoir combien de passes seront nécessaires à obtenir un document correct en se basant seulement sur la liste des fichiers modifiés dans l'ensemble des dépendances. En effet, la nature des modifications induit des besoins différents au niveau des passes et des outils. Prenons un exemple simple. Je modifie monlatex.tex en

\documentclass{article}
\begin{document}
\include{bla1}
\include{bla2}

\bibliographystyle{plain}
\bibliography{mabib.bib}
\end{document}

et j'ajoute donc un fichier bibtex (tient une nouvelle dépendance à ajouter à la main… ou pas avec latexmk) :

@Book{RobertBozo2014,
  author =   {Bozo, Robert},
  title =    {Oui Oui fait du latex},
  publisher =    {Bozo Inc.},
  year =     2014}

Quand je lance latexmk, j'obtiens les passes suivantes :
1) pdflatex monlatex.tex : détection de la nouvelle dépendance mabib.bib ;
2) bibtex monlatex : bug car pas de citation, mais latexmk s'en fout, il connaît cette erreur et sait que ce n'est pas un vrai problème. Il découvre quand même le fichier monlatex.bbl (vide ou presque) qui devient une nouvelle dépendance (on sait jamais, je pourrai vouloir le modifier à la main) ;
3) pdlfatex monlatex.tex : normal car le bbl a été produit et il faut l'intégrer.

Que se passe-t-il maintenant si je modifie bla1.tex ? Tout dépend de la nature de la modification, chose que le système proposé par l'auteur ne peut pas détecter. Si mon nouveau bla1.tex est le suivant

\section{Bla 1}
Mon bla 1 modifié.

alors une seule passe de pdflatex est suffisante (et c'est ce que fait latexmk, bien sûr). En revanche, si mon nouveau bla1.tex est

\section{Bla 1}
Mon bla 1 \cite{RobertBozo2014}.

alors il faut trois passes : un pdflatex, un bibtex et un pdflatex.

Et tout ça n'est qu'un exemple de base absolument standard (comme je le disais plus haut). Dès qu'on commence à utiliser des packages évolués, la situation se complique. On peut voir sur stackexchange des exemples de documents qui nécessitent n passes pour n arbitraire. C'est le cas par exemple de documents produits avec longtable.

La solution proposée par l'auteur est de choisir à la main le nombre de passes. On peut donc choisir entre quelque chose d'inefficace (sachant que pdflatex+bibtex+pdflatex est en gros le minimum pour un document avec des citations, mais ça peut encore être incorrect s'il y a des modifications de la table des matières) ou quelque chose d'incorrect (pas assez de passes dans certains cas). Comme je l'ai dit en introduction, c'est inacceptable, d'autant qu'il existe des solutions qui fonctionnent parfaitement.

En outre, l'auteur ne sait pas (apparemment) que les documents latex sont très dynamiques. Si j'utilise un style de citation qui inclut les noms d'auteurs dans les étiquettes, une modification du fichier bibtex peut entraîner plusieurs recompilations du latex car les étiquettes peuvent changer et donc entraîner des modifications de mise en page. L'exemple de mon cv donné plus haut montre aussi que certains compteurs peuvent être calculés par biber (le remplaçant de bibtex) en fonction du contenu des fichiers bibtex mais aussi en fonction des commandes dans le latex (en gros, biblatex permet la définition de collections dont la taille peut notamment être utilisée dans le latex lui même). Tout ça conduit à des compilations plus ou moins complexes.

Bref, tout ça est connu et archiconnu et c'est pour ça qu'il existe pléthore d'outils de compilation spécifique à latex. On peut voir ça (à juste titre) comme une limitation de latex, mais ça ne change au rien au fait qu'il faut la gérer, ce qu'un système à la make ne peut pas faire simplement.

L'horodatage est une mauvaise idée

Terminons par cette idée d'horodatage. Le cas d'utilisation (partage de documents en dehors d'un gestionnaire de version) est tout à fait réaliste, mais la solution proposée est naïve (c'est globalement le cas de toute la dépêche, d'ailleurs). Elle repose sur la confusion entre instant de compilation et instant de production. Dois-je vraiment expliquer cela ? Si je compile mon latex maintenant et que j'obtiens monlatex-2014-11-01-15-16.pdf, est-ce que ça veut dire que c'est la version des sources du 1er novembre 2015 à 15h16 ? Bien sûr que non ! C'est le moment de la compilation, nom de dieu ! Et quand bien même je compilerais juste après avoir écrit quelque chose, rien ne garantit dans cette solution que je pourrai revenir à la version du 1er novembre 2015 à 15h16 car je ne sais pas si cette version existe dans mon gestionnaire de versions !

Et donc, il ne faut pas faire comme ça. C'est tellement évident d'après toute l'histoire du développement logiciel qu'on se demande comment on peut avoir une telle idée (oui je sais je suis arrogant, c'est ça…). D'autant qu'il existe des solutions simples. D'abord, il faut intégrer dans le pdf lui-même de quoi retrouver la version des sources utilisée pour le produire dans le gestionnaire de version. C'est facile avec gitinfo2 et il y a d'autres packages pour d'autres gestionnaires de version. Ensuite, il faut prévoir un mode de release dans le makefile (ou sous forme d'un hook git, par exemple) qui ne fonctionne que sur une version vraiment existante dans le gestionnaire de version (donc qui refuse de produire le pdf s'il y a des modifications non commitées) et qui utilise dans le nom de fichier la date (et heure) de la version concernée. Encore une fois, ça ne pose pas de problème particulier. Notons que gitinfo2 ne donnera que des informations sur une version existante des sources et n'utilisera donc pas la date de la compilation mais bien celle de la version.

Conclusion : ça ne marche pas bien

Voilà, soyons finalement gentil avec l'auteur, sa solution ne marche pas bien. Elle boite pas mal. Il existe des solutions qui marchent très bien, elles. Elles existent depuis longtemps. Les personnes arrogantes comme moi le savent. Les personnes arrogantes comme l'auteur pensent probablement qu'elles n'ont pas besoin de regarder ce qui se fait pour compiler du latex et qu'elles sont suffisamment compétentes pour faire ça elles-mêmes. Chacun son arrogance.

Tu es vraiment hallucinant d'arrogance! C'est trop drôle!

Je remarque que tu ne réponds toujours rien sur la confusion entre date de compilation et date d'écriture (après des pirouettes du type « ah ouai bibtex, mais moi, tu vois, je ne compile qu'une fois sauf à la fin ») mais que tu préfères m'insulter. Chacun son truc.

Je ne vois pas le rapport avec “compiler plus que nécessaire”. Au contraire ici, il n'a pas assez compilé!

Tu dis que tu compiles une seule fois pendant l'écriture et le bon nombre (ou trop) en production. C'est une mauvaise idée, ça engendre notamment le problème que j'évoque. C'est un cas particulier de l'erreur classique qui consiste à distribuer le code de test au lieu du code de production.

Pour ce qui est de bsdowl les messages de Warning ou Error LaTeX sur les références non définies est transformé en erreur de compilation par bsdowl et une liste récapitulative de tous les Warnings et de tous les Erros est affichée.

Certes, et personne ne les regarde ;-)

Pour la soumission, d'article c'est un peu sa faute s'il ne vérifie pas ce qu'il envoie non? Même avec un système réputé fiable il faut vérifier ce qu'on envoie quand c'est important. Donc ici, c'est une erreur humaine, avant tout.

Et l'un des buts d'un outil automatique bien fait est de limiter ce genre d'erreur humaine, notamment quand on soumet en pleine nuit pour une conf prestigieuse dont la deadline est en pacific time.

C'est justement (pour la deuxième fois) les “Workflow complexes” qui sont mis en avant par la dépêche, et ce que tu dis est écrit noir sur blanc dans la dépêche (par moi):

Dans un workflow complexe, la gestion des dépendances manuelles est une bonne façon de se planter, on tourne en rond.

Il existe un outil qui gère parfaitement les dépendances et le nombre de passes en latex. Tu peux l'intégrer dans ton machin, tu devrais être content. Et non, tu préfères défendre une solution qui ne marche pas toujours. C'est comme l'horodatage à la compilation, c'est une mauvaise idée, ça confond date de compilation et date de production et ça rend donc difficile l'ajustement entre les versions. En plus, ça te permet d'horodater une version qui n'existe pas vraiment dans ton gestionnaire de version et donc de te tirer dans le pied.

Je te laisse t'amuser, je retourne écrire un article et le compiler avec latexmk.

un système plus naïf marche quand même dans beaucoup de cas

Oui, mais l'intérêt d'un makefile, c'est justement de gérer les cas évolués, sinon un (pdf/lua/whatever)latex est largement suffisant. Et surtout, il y a un logiciel libre qui fonctionne et qui est maintenu, quel intérêt de faire moins bien ?

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.

C'est dangereux. Un de mes thésards a un jour soumis un article mal compilé ([?] pour les références) avec de genre de méthode. Et j'ai régulièrement des articles à lire qui présentent des bugs de ce genre. Je ne vois pas l'intérêt d'un makefile si on ne fait pas les choses proprement, mais bon, chacun son truc.

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.

Certes, mais l'amélioration des outils (comme biber/biblatex qui remplacent bibtex) engendre plus d'aspects dynamiques de façon naturelle. De plus, le nombre de compilations n'est bien sûr pas aléatoire, mais il dépend de la nature des modifications effectuées dans les différentes sources qui concourent à produire le document final. Évidemment, si tu ne veux pas obtenir le vrai document final à chaque instant (chacun son truc, encore une fois), alors un makefile est suffisant mais à mon avis sans intérêt : pourquoi taper make plutôt que (pdf)latex ? La logique m'échappe, sauf dans un workflow complexe et là, la gestion manuelle des dépendances est tellement pénible que je ne vois pas non plus l'intérêt de gérer la compilation latex elle-même par le makefile.

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?

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), sauf si la biblio devient plus longue (parce que tu as précisé la référence biblio et qu'elle prend maintenant plus de place). Dans ce deuxième cas, ça peut décaler ce qui vient après la biblio (index, annexe, etc.) d'où la nécessité d'au moins une autre passe pour mettre à jour la table des matières (s'il y en a une). C'est déjà compliqué. Mais si tu modifies le latex lui même, ça peut ou non modifier ce que tu cites, ce qui demande alors au moins une nouvelle compilation pour refaire la biblio, après avoir appelé bibtex. Et hop, retour au problème éventuel de table des matières. C'est tellement chiant qu'il faut parser la sortie du latex pour s'y retrouver.

En ensuite, si tu utilises biblatex et biber (ce qu'il faut faire de nos jours), ça devient assez folklorique. Mon cv inclus ma liste de publications gérée par biblatex. Le nombre de publications par type, en page 2, est calculé automatiquement par biber. Parfois, ça prend 4 passes de compilations, parfois une seule. Je t'avoue que les raisons profondes me restent assez mystérieuses…

Sincèrement tu aurais moins l'impression de te répéter si tu évitait de commencer tes intervention en disant que l'auteur qui est devant toi fait de la merde et en étant dans une approche plus constructive.

J'ai dit que ça ne marchait pas, c'est vrai. J'ai ensuite dit du mal de l'horodatage et je maintiens qu'il est consternant de confondre date de compilation et date d'écriture.

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. Trouver latexmk s'avère presque difficile. Il m'a donc semblé important de rétablir la vérité (ouai, rien que ça). Et si j'ai précisé que bmake etc. ne m'intéressait pas, c'est pour insister sur le fait que je ne critique ni le choix de l'outil, ni le principe de la bibliothèque de makefile, ni rien de tout ça. Simplement l'exemple du latex est mauvais et correspond à une mauvaise connaissance (ou une vision naïve) des problèmes de compilation associés. Ce sont certainement des limitations de TeX, mais on n'y peut pas grand chose pour l'instant, excepter utiliser un outil adapté (et donc pas un make généraliste !).