Michaël a écrit 2935 commentaires

Très franchement, je n'ai pas tellement envie de me lancer dans ce débat philosophique. Je vais donc lâchement recopier la dernière phrase du bon paragraphe du bon livre (traduction libre):

Porter une responsabilité signifie être obligé à rassembler
suffisamment de connaissances pour justifier une décision.

Markel, Hubert: Wissenschaft, zur Rede gestellt. München 1989 (p. 22)

Ce qui caractérise l'exercise d'une responsabilité, c'est la possibilité qu'il faille se justifier de ses décisions. Les ordinateurs n'ont jamais besoin de se justifier — en tout cas, pas comme les humains.

Ce n'est pas parce que c'est prédit que tu ne fais pas un véritable choix quand tu prends ta décision.

Exactement, la prédiction — on devrait plutôt dire «projection» — est une information comme une autre sur laquelle baser sa décision.

Pour un être humain, décider signifie s'informer, choisir, et être responsable de son choix. Et quoiqu'on en dise, seul les humains peuvent porter une responsabilité, les ordinateurs ne le peuvent pas.

Non car XML permet aussi la validation d'un document contre une DTD, ce qui est totalement absent de LISP.

Mais j'avoue que personnellement, je suis toujours resté septique > par rapport à ce format qu'on m'a toujours vendu comme
universel, car facile à comprendre par l'homme et le machine.

XML n'est pas du tout facile à lire par une machine! En tout cas c'est loin d'être le format le plus facile à lire.

Tout d'abord, un point très important que je n'ai pas vu évoqué ailleurs: XML sert à deux choses:

• D'une part c'est un format d'échange et persistance bien standardisé. C'est la fonction sérialisation.

• D'autre part il permet de valider la donnée en la comparant à une DTD, une définition de document. C'est la fonction validation.

La vaste majorité des parsers XML ne valident pas la donnée et proposent donc la fonction sérialisation de XML sans la validation. Pour la sérialisation, les formats plus efficaces que XML — du point de vue de la machine, car plus faciles à lire — existent par pelletées, certains sont d'ailleurs très anciens.

Un parser même non validant pour XML doit prendre en charge une syntaxe plutôt riche (encodings, namespaces, extensions de la DTD, CDATA, etc.) et ils se contentent en général d'un sous-ensemble. Ce qui en pratique signifie que l'interopérabilité est loin d'être garantie.

Un parser validant est lui, confronté à un problème supplémentaire — mais en fait c'est le seul intérêt de l'XML, en plus de la disponibilité de beaucoup de biliothèques — qui est bien-entendu la validation.

En plus il faut noter que bien définir une DTD pour XML est difficile: il faut bien savoir qu'elle information on veut encoder dans la structure du document. (La problématique est semblable à «quelle informations sur mon programme puis-je encoder dans le système de types?»)

Dans la pratique XML est donc surtout utilisé comme protocole de sérialisation et de façon largement incomplète donc pas nécessairement interopérable. Autrement dit, XML est utilisé pour de mauvaises raisons.

Des formats de persistance nettement plus faciles à lire (pour l'ordinateur) que le XML sont par exemple les property lists et les S-expressions. N'importe quel programmeur peut écrire un parser de S-expressions en une après-midi, même s'il utilise un langage de bas niveau (voire l'assembleur!). De plus, d'après le Bureau des Statistiques Pifométriques, 90% des applications utilisant XML comme format de sérialisation pourraient le remplacer par des S-expressions sans perdre en fonctionnalité.

Voici un exemple de parser validant, en OCaml:

http://www.camlcity.org/archive/programming/pxp.html

C'est une sacrée différence tu ne pense pas ?

C'est une sacrée différence, je n'ai jamais dit le contraire!

Et avoir des pièces/billets dont la valeur change constamment j'ai un poil de mal à voir l'usage réel.

La valeur de tes euros — ou n'importe quel autre devise — change elle aussi constamment. Ce qui ne change pas, c'est la valeur faciale mais il ne représente pas la valeur de l'argent. La différence avec le Bitcoin est probablement la volatilité, i.e. grosso-modo la vitesse à laquelle la valeur change.

ils en avaient marre de voir des gens s'abîmer les doigts avec emacs.

Ça aurait été plus simple de leur faire remarquer qu'ils ont deux mains!

Oui, je me suis pris un sacré coup de vieux! J'ai possédé un Motorola 68000 et un 80286, mais j'avais oublié que c'était il y a si longtemps!

En 30 ans l'évolution informatique a été fulgurante : La fréquence des processeurs a grimpé d'un facteur mille, pour passer du Mega au Giga Hertz

Des processeurs cadancés à 1Mhz, c'était pas plutôt il y a 15 ans?

D'ailleurs j'ai lu ça cet après-midi, sur PSX: http://programmers.stackexchange.com/questions/49758/is-ocaml-any-good-for-numerical-analysis/223595#223595

sachant que je change souvent celles-ci

Donc dans ton cas la liste n'est pas stable! Une solution automatique de type makedepend est effectivement à envisager.

Si tu as des problèmes avec BSD Make, n'hésite pas! :D

Et bonne chance pour ta thèse, après c'est que des bons souvenirs!

Donc il faut inventer un nom, c'est à mon sens une limitation.

Pas forcément c'est just un exemple. Ce qui compte c'est d'avoir une idée claire de ce qu'on veut pour pouvoir l'implémenter — c'est pour ça que j'ai choisi un exemple. Mon but est plutôt d'expliquer la partie make.

Donc il faut que le programme parse le document racine à la recherche d'inclusions vers d'autres documents.

Il y a mille façons de régler ça. Moi, ça ne me dérange pas d'écrire la liste de mes sources TeX à la main dans le Makefile et c'est facile. Une solution automatique pourait par exemple parser le log du job TeX — si c'est trop difficile on peut redéfinir la primitive input pour qu'elle écrive le nom du fichier de façon facile à reconnaître.

Donc tu dois spécifier les dépendances à la main, alors que certaines commandes pourraient les gérer d'elles mêmes.

Encore une fois c'est juste un exemple, et mon but est plutôt d'expliquer la partie make. Si makedepend_blender peut calculer une partie des dépendance, pas de raison de s'en priver.

Ceci dit, écrire les dépendances à la main est en général peut contraignant — si on écrit la liste une seule fois à un seul endroit — car il s'agit d'une liste stable et cela permet d'avoir cette liste sous les yeux pour déboguer.

Ta solution est beaucoup trop compliquée!

Pour tirer parti correctement de make tu as besoin de préciser correctement tes dépendances et de tenir compte des timestamps. Comme tu sais programmer des dæmons en Python, je suppose que des programmes plus simples sont également à ta portée.

Voici ce que je propose:

Pour commencer, on définit une commande TeX MyFancyGraphic qu'on utilise comme suit:

\begin{MyFancyGraphic}{filename}
calcul_vecteurs_mouvements(resize((800, 600), rendu_video_blender(scene.blend, start_frame=0, end_frame=12, resolution=(800, 600), samplesPerPixels=12, materials=('red', 'blue'))))
\end{MyFancyGraphic}

Dont l'effet est d'inclure l'image filename et de poubelliser (ignorer) le reste.

Ensuite on écrit un programme makedepend_blender — en OCaml, mais on s'en cogne ;) — qui prépare les dépendances. Il lit tes fichiers TeX et écrit un fichier .depend_blender contenant des lignes du type

# DRAFT vaut no quand on prépare la version finale du document et yes
#    autrement.
DISTCLEANFILES+= filename.in
REALCLEANFILES+= filename.png
filename.png:   filename.in
    sh ./call_blender.sh -D ${DRAFT} -o filename.png filename.in

(Si les fichiers image ont d'autres dépendances, il faut trouver une convention pour les ajouter dans MyFancyGraphic et demander à makedepend_blender d'écrire leurs noms à droite de filename.in.)

De plus makdepend_blender écrit aussi le contenu de l'appel à la commande dans le fichier filename.in — mais ne réécrit pas le fichier si le contenu n'a pas changé, ce qui évite de changer inutilement le timestamp.

Finalement, côté Makefile cela donne:

DOC=    these
SRCS=   macros.tex
SRCS+=  chaptitre3.tex

.include "latex.doc.mk"

.if exists(.depend_blender)
.include .depend_blender
.endif

depend: .depend_blender

.depend_blender: ${SRCS}
    makedepend_blender ${SRCS} > ${.TARGET}

REALCLEANFILES+= .depend_blender

Et voilà. :)

J'ai bien aimé le TL;DR! :-)

Je ne connais ni rubber ni latexmk donc je ne peux pas trop comparer à ce que j'ai écrit.

Écrire des macros pour make c'est la même chose que de la programmation en shell à ceci près que la logique du traitement n'est pas exprimée par des procédure mais par des recettes et des dépendances. On explique seulement à make les étapes élémentaires de la construction et make se débrouille pour constuire un plan d'action.

Pour ta question précise, j'ai une réponse précise, en trois étapes:

1. On spécifie clairement le problème.
2. On résout le problème dans le shell.
3. On intègre le point 2 dans le workflow de make.

Voilà la spécification que je propose: je suppose que tu as une macro plopfizz qui prend en argument les paramètres de ton image et fait deux choses. Premièrement elle écrit ces paramètres dans un fichier id.plopfizz ou id caractérise l'appel. Deuxièmement elle regarde si l'image id.png résultat du traitement existe déjà pour éventuellement l'inclure dans le document. Ce n'est certainement pas exactement ta situation, mais probablement assez similaire.

On prépare une routine shell, disons process-plopfizz.sh qui lit un fichier id-plopfizz et prépare l'image id.png. La prépration d'un document ressemble donc à

$ pdflatex galley.tex
$ sh ./process-plopfizz.sh -o id1.png id1.plopfizz
$ sh ./process-plopfizz.sh -o id2.png id2.plopfizz
$ pdflatex galley.tex

Maintenant on peut intégrer dans le workflow de make. Pour cela, comme make se fie aux timestamp d'un fichier pour savoir s'il a été modifié, il faut être un peu sioux et améliorer la macro TeX plopfizz pour qu'elle lise le fichier id.plopfizz s'il existe et n'en écrive un nouveau que si les paramètres ont changé.

À la fin, le fichier Makefile ressemblerait à

DOC= galley.tex
.include "latex.doc.mk"

${COOKIEPREFIX}galley.pdf.aux: id1.png id2.png

id1.png: id1.plopfizz
     sh ./process-plopfizz.sh -o id1.png id1.plopfizz

id2.png: id2.plopfizz
     sh ./process-plopfizz.sh -o id2.png id2.plopfizz

CLEANFILES+= id1.png id2.png
DISTCLEANFILES+= id1.plopfizz id2.plopfizz

La ligne

${COOKIEPREFIX}galley.pdf.aux: id1.png id2.png

est l'incantation vaudou qui insère notre solution dans le workflow de make. Les déclarations suivantes sont des recettes make standard et les deux dernières lignes ajoutent les produits aux listes de fichiers à effacer, avec make clean où make distclean. La forme make distclean efface moins de fichiers que make clean. Ici les images sont conservées mais pas les fichiers intermédiaires plopfizz, ce qui facilite la préparation d'une archive qu'on envoie à son éditeur par exemple.

On voit bien que la préparation des images pourrait être améliorée en introduisant des règles génériques ou des variables, mais j'ai pensé qu'on pouvait dans un premier temps se contenter d'une solution “bébête” qui n'aie pas l'air artificiellement compliquée.

Bien-sûr c'est garanti sans test, mais c'est la route à suivre.

P.S.: Si tu prépares un use case ou bien une use story un peu plus précis, je peux te donner plus de détails! L'idéal serait quelque chose que je puisse incorporer au source dans le dossier test.

Ma première réponse est simplement que j'ai commencé à écrire ces macros en 2000, époque à laquelle omake n'existait probablement pas.

J'ai commencé à travailler avec GNU Make, je peux donc par contre détailler les raisons qui m'ont motivé à changer.

La documentation de GNU Make est essentiellement réduite à son manuel de référence. Ce manuel est très complet (à l'époque il faisait plus de 200 pages) mais c'est un manuel de référence: le but de ce document est de décrire très précisément tous les aspects du logiciel, mais pas du tout d'expliquer comment on résout des problèmes avec le logiciel.

Ces dernières explications sont habituellement contenues dans des introductions, des tutoriels, ou des fiches de recette, comme on peut les appeler. À l'époque je n'avais pas trouvé de tutoriel satisfaisant.

Finalement, la troisième source d'information sont les exemples. J'avais trouvé très difficile de trouver des exemples intéressants, le gros des Makefile étant généré par automake et pas du tout typique de ce qu'on peut écrire à la main.

Du côté de BSD Make, que j'avais à disposition puisque j'ai commencé à utiliser FreeBSD à cette époque, la situation est bien différente puisque:

• Il existe un tutoriel de référence écrit par Adam de Boor, et faisant partie de la documentation standard du système. C'est un document d'excellente qualité qui commence par le b-a ba et montre progressivement comment utiliser variables et macros pour raccourcir et assouplir ses Makefile en introduisant de nouvelles abstractions. C'est aussi un document court et accessible, dont on fait le tour en moins d'une demi-journée.

• La page de manuel make(1) tient lieu de manuel de référence, elle faisait et fait toujours dans les 8 pages: le logiciel est certe plus simple que la version GNU, mais on trouve rapidement toute l'information! Alors qu'avec le manuel du programme de GNU, j'étais toujours à la recherche de la description de ceci ou de cela, et du passage pas dans l'index deux pages avant…

• Il existe une abondante littérature de Makefile dans laquelle puiser des idées: la compilation du système FreeBSD est gérée par make, j'avais donc sous la main beaucoup d'exemples à étudier. Et cela prouve au passage qu'en s'y prenant bien—c'est à dire, en faisant comme dans les exemples—on peut organiser des tâches extrêmement complexes avec make.

Alors oui, le make de FreeBSD est très certainement bien plus primitif que celui de GNU, mais les trois points ci-dessus font bien plus que contrebalancer cette différence technologique. Après tout, l'apparition de C++ n'empêche pas que chaque jour des programmes nouveaux soient écrits en C, une technologie pourtant inférieure sur le papier (que sait faire C que ne sait pas faire C++?). Les raisons à cela sont très certainement (en partie) celles de ma liste: C est à la fois plus simple que C++, bien éprouvé, et les exemples ne manquent pas.

J'ai passé un peu de temps à regarder omake — que j'ai redécouvert, puisque je me souviens l'avoir vu il y a quelques années — c'est un logiciel très prometteur qui semble très puissant. La documentation est cependant un problème: comme manuel de référence elle semble très complète, mais un examen rapide me laisse penser qu'il n'y a pas d'exemple simple, un exemple simple sans macro, sans fonction sans rien, juste un

module.obj: module.c module.h
    cc -c module.c

De plus je n'ai pas vraiment réussi à comprendre — dans le temps imparti! — le statut du shell dans omake. Dans make c'est très clair, si je sais faire quelque chose dans mon shell, je n'ai qu'à le recopier à la fin de mon Makefile en ajoutant une ligne spécifiant les dépendances: c'est à la fois facile à retenir car cela ne fait intervenir que des concepts de base du programme — c'est quelque chose qu'on sait faire même si on s'est arrêté au premier exemple du tutoriel d'Adam de Boore! — et facile à mettre en œuvre car cela s'appuie directement sur le shell.

Je le confesse, c'était une vanne. Mais bon, venant de quelqu'un d'autre ç'aurait pu être une vraie question! :-)

Qu'est-ce que ça veut dire, 36 15?

Je pense qu'on se fait noyauter!

Ton commentaire m'a ouvert les yeux sur beaucoup de choses, grâce à toi j'ai découvert de nouveaux horizons et des portes insoupçonnées vers une sagesse qui m'était auparavant étrangère.

OSX n'etant pas libre, le site linuxfr n'est pas forcement le meilleur endroit pour en parler

Les meilleurs sites dédiés à Linux ont aussi des sections pour d'autres systèmes de type Unix, dont celui d'Apple!

https://linuxfr.org/sections/apple

Le plus dur c'est de passer de l'allemand à l'anglais et vice-versa il me faut un temps d'adaptation.

J'avais ça au début quand j'ai commencé à devoir utiliser trois langues dans la même journée, mais au bout de quelques semaines on s'habitue! :-)

La langue que je préfère à l'écoute, le bon allemand, je trouve quel sonne bien à l'oreille.

Je les trouves toutes les trois jolies, mais l'anglais un peu moins que les autres.

Il manque l'option 5 qui consiste à avoir fait des exposés scientifiques à des séminaires et des publications (ça c'est pour l'anglais) et l'option 6 qui consiste à vivre dans le pays depuis 5 ans (ça c'est pour l'allemand).

Je suis obligé de tomber sur des photos dégueu en lisant Linuxfr? Je suis une âme sensible.

Bah moi je comprends que si on ramène le volume des océans à une « pseudo surface » (ie : un volume avec une profondeur négligeable)

La seule information contenue dans ces 98% est que

 \[
 \lim_{\epsilon\to 0} {A + V/\epsilon\over V/\epsilon} = 1
 \]

pourvu que V non nul. C'est pas faux, mais ça n'a rien à voir avec la Terre et ses océans.

Je dois donc être aveugle pour n'en avoir jamais vu. Et je dois être sourd pour n'en avoir jamais entendu parler.

Le monde est grand. Il paraît qu'en Amérique du Sud OS/2 est toujours relativement populaire dans certaines industries. C'est le genre de chose dont on entend pas forcément parler.

Venons-en aux faits s'il vous plaît: Si demain je veux voir un (vieil) unix propriétaire toujours en service, je vais où?

Dans n'importe quelle grosse organisation qui existe depuis plus de 20 ans? Dans certaines banques par exemple on utilise toujours SUN Solaris. :)