boubou a écrit 1384 commentaires

Ouai donc tu es entrain de dire qu'utiliser *make c'est mal, mais qu'en fait toi tu t'en sert et tu préfère utiliser latexmk pour pallier aux faiblesses du compilateur latex.

Non, je dis simplement qu'on ne peut pas gérer les passes de latex par un makefile, pas que c'est mal.

Je ne sais pas quel problème tu prétends résoudre avec ton outil. En revanche, le problème que tu sembles décrire est celui de la recompilation automatique d'un fichier latex quand cela doit être fait en raison d'une modification de quelque chose (sources latex, images, etc.). Or, ton outil ne résout pas ce problème parce qu'il faut écrire les dépendances la main et parce qu'il ne peut pas déterminer automatiquement le nombre de passes à faire. Et je soupçonne que cette tâche est en fait impossible à réaliser efficacement avec un outil de build généraliste (encore une fois, je n'en suis pas certain, c'est juste le fruit de 20 ans d'expérience).

En revanche, et je ne vois là aucune contradiction, il parfaitement possible et utile d'intégrer un outil qui résout bien ce problème dans un makefile. D'ailleurs, latexmk produit un fichier de dépendances qui peut être récupéré dans le makefile (moyennant une transformation) pour gérer partiellement la tâche en question au niveau de l'outil généraliste (le nombre de passes étant toujours du ressort de latexmk).

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.

Concernant les dates, la confusion entre instant de compilation et instant d'écriture est consternante. Et c'est bien tout l'intérêt de gitinfo2 (ou des solutions comparables pour d'autres gestionnaires de version, chacun ses vices) de ne pas faire cette confusion. Et bien sûr, on peut intégrer ce qu'on veut dans le nom du pdf avec un makefile bien construit.

Ça marche très bien au contraire.

Ce que j'appelle marcher/fonctionner, c'est qu'une fois la commande lancée, je suis certain d'obtenir un pdf final avec le bon nombre de passes. Le fait d'avoir à gérer les dépendances à la main est une première limite évidente : si j'ajoute une image et que j'oublie de l'inclure dans les dépendances, c'est mort. Ce n'est pas de que j'appelle fonctionner (en tout sûrement pas très bien).

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

Le nombre de passe doit être déterminé par surveillance des messages émis par latex, c'est le seul moyen. En fonction de la source des modifications, latex doit faire plus ou moins de passes (par exemple, un ajout de référence engendre plus de passes qu'une modification du fichier bibtex). Il n'y aucun moyen simple de prévoir ce qui va se passer, notamment en raison des ajustements fins réalisés par certains packages (longtable en co) qui peuvent avoir des effets sur la table des matières. Ba oui, latex c'est compliqué. Et donc, le nombre de passes ne peut pas être fixé. Et donc, ça ne marche pas.

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?

Je ne suis pas certain de bien comprendre la question. Je soupçonne que tu demandes comment intégrer latexmk dans un makefile. Si c'est le cas, je ne vois pas bien la difficulté, notamment parce que la compilation latex arrive toujours en dernier. Tu peux donc faire tout ce que tu veux avant, puis appeler latexmk. Cerise sur le gâteau, la compilation du document ne sera faite que si les éléments inclus (figure par exemple) ont vraiment été modifiés (au sens du contenu, pas de la date de modification). Il a aussi une fonctionnalité évoluée de latexmk qui lui permet d'intégrer des règles de transformation de documents voués à être inclus dans un source latex. 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).

Pour le reste, sur make/bmake/gnumake je remarque au contraire de toi que la plupart des langages de programmation contemporains (scala, ruby, etc.) ont leur propre système de build pour plein de raisons : gestion complexe de dépendances, extensibilité dans le langage, etc. Mais tout ceci est totalement orthogonal au fait que ça fait au moins 20 ans (et oui) que je fais du latex et qu'on me montre des makefile divers et variés dont aucun ne résout efficacement le problème compliqué de la compilation du latex, alors que c'est le cas de latexmk. Encore une fois, je ne remets pas en question l'intérêt général de bmake, bsd owl ou tout ce que tu veux (je me tamponne, pour être honnête), je dis juste que ça ne peut pas marcher pour latex. C'est une question de modèle : latex n'est pas un pipeline source -> pdf/ps, il a des passes dynamiques. À ma connaissance, aucun builder généraliste n'est prévu pour ce genre de chose (je dis bien à ma connaissance).

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

Ah ba non, bien sûr, je ne lis surtout pas ce que je commente. C'est plus pratique pour dire n'importe quoi.

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.

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

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.

C'est exactement la même chose avec gitinfo2 mais avec la garantie induite par l'utilisation du gestionnaire de version de pouvoir revenir à la version concernée.

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. Je n'ai rien contre BSD Owl, juste pour être clair : ça ne marche pas non plus avec gnu Make. Qu'est-ce qui ne marche pas ?
1. la gestion des dépendances qui est manuelle dans ces solutions : on est en 2014 !
2. le choix du nombre de passes qui est aussi manuel alors qu'il doit être adaptatif en latex (index, biblio, packages tordus, etc.)

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.

Je ne dirai pas ce que je pense vraiment de l'horodatage pour les versions, histoire de rester poli. 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.

Ou pour être plus efficace, d'utiliser une solution qui crypte sur le client directement donc seafile ou sparkleshare (de façon native) ou git-annex avec une remote de type gcrypt (http://git-annex.branchable.com/tips/fully_encrypted_git_repositories_with_gcrypt/). Syncany fait ça aussi, mais à mon avis, ce n'est pas assez stable. En outre le choix de ne pas utiliser de serveur rend le design fragile (en terme de système réparti c'est un vrai challenge de réussir une exclusion avec un stockage idiot comme unique support).

Comme je l'ai dit au dessus, il me semble entendre une différence. Je n'ai jamais prétendu que j'étais sûr de moi sur ce point et, bien entendu, il faudrait faire ça en ABX (je pense d'ailleurs que la différence vient essentiellement d'une difficulté à ajuster les niveaux entre les deux dac). Cependant, les spécifications techniques des dac de mes deux appareils, données par le constructeur, sont différentes, par exemple en terme de rapport signal à bruit. Il y a donc un support physique à une possible différence. De plus, il est prouvé que l'instabilité des horloges (le jitter) est perceptible (http://en.wikipedia.org/wiki/Comparison_of_analog_and_digital_recording#Jitter). Quand je compare ma squeezebox et mon onkyo, je passe de toute manière par l'amplification de l'onkyo et mes enceintes. En revanche, le jitter n'est potentiellement pas le même entre les deux dac et encore une fois, cela fait une source possible de différences perceptibles. Sean Adams, le concepteur de la squeezebox, a énormément bossé sur la réduction du jitter de celle-ci, en travaillant notamment sur l'alimentation (et en utilisant des mesures objectives du jitter avec du matériel dédié). Bref, tout ce que je veux dire est qu'il y a quelques explications plausibles pour une éventuelle différence de rendu sonore entre deux dac accord que sur des longueurs de câble standard, il n'y aucune explication plausible pour une différence de rendu entre deux câbles pas trop merdiques.

Et je n'ai jamais dit qu'un dB d'écart masquait les différences, mais qu'il fallait au moins calibrer à 1 dB. Mieux on calibre, mieux c'est.

Deux points importants :
1) est-ce qu'une personne dans la même pièce que toi (ou qui te parlait) savait quelle était la configuration du système ? Si c'est le cas, ne cherche pas, toute la procédure en double aveugle a été conçue en raison de l'influence possible (et mesurée) des expérimentateurs sur les cobayes. De même si tu pouvais ne serait-ce que voir le système un peu ou les manipulations, c'est mort.
2) beaucoup plus important : est-ce que le niveau sonore était exactement le même (à un dB près au plus dans la bande 2 à 5 kHz qui est normalement la plus sensible) au moment de la reproduction entre les différents systèmes ? Si vous n'avez pas réglé ce niveau sonore, la comparaison n'a aucun sens, c'est démontré assez clairement dans la littérature scientifique.

En fait tout ça a été pas mal étudié, jusqu'à produire le protocole A/B/X (http://en.wikipedia.org/wiki/ABX_test) qui est probablement la seule façon de tester vraiment les différences entre le matériel.

Sur le fond, je suis totalement d'accord qu'on peut entendre facilement une différence sur les DAC. J'ai comparé très basiquement le DAC interne de mon ampli Onkyo avec celui de ma squeezebox et il me semble entendre assez clairement une différence. Vu les traitements effectués et les puces très différentes, c'est plausible. En revanche, pour les câbles c'est du pipeau intégral. Penser qu'on peut entendre une différence, c'est comme penser que l'homéopathie peut soigner (au delà de l'effet placebo), c'est juste une impossibilité physique sur de telles longueurs.

C'est, dans mon cas, pour insister sur le caractère « exceptionnel » du personnage, à la fois en jouant sur l'incongru anglicisme au milieu d'un texte en français, mais aussi en utilisant le fait qu'en anglais, l'usage est encore plus emphatique qu'en français. Voilà, voilà…

Ouai, même subsurface le logiciel de gestion d'ordinateurs de plongée développé par Linus himself est en train de passer à Qt (alors que l'ami Linus n'est pas le plus grand fan de C++ de la terre).

C'est vraiment que c'est énorme de longueur ;-) Plus sérieusement, il y a des moments de bravoure, par exemple la première « histoire » (Père Paul Duré et les cruciformes, c'est exceptionnel) mais aussi des parties que j'ai trouvé très très longues (et chiantes) comme la quatrième « histoire » (Sol et sa fille Rachel). J'ai du mal à voir le rapport avec Dune, ceci dit. Je ne l'ai pas relu depuis longtemps mais ça m'avais semblé très politique et beaucoup plus profond qu'Hyperion qui reste pour moi un roman plus classique.

Y a-t-il une source, ou un moyen de vérifier que Microsoft utilise encore une couche TCP/IP BSD?

PasBillPasGates, qui bosse chez MS, a écrit ici des dizaines de fois que MS n'utilise pas la couche TCP/IP de BSD (et ne l'a jamais utilisé). Il y a une confusion (semble-t-il) autour de l'utilisation de code BSD dans certains utilitaires (cf http://www.everything2.com/index.pl?node=BSD%20Code%20in%20Windows). Une histoire de cette confusion : http://www.kuro5hin.org/story/2001/6/19/05641/7357. Je ne sais pas quel crédit apporter à ces témoignages, mais dès qu'on cherche un peu, on trouve d'un côté comme unique preuve les strings de quelques utilitaires et de l'autre diverses personnes de MS qui affirment que leur pile TCP/IP est bien totalement indépendante de celle des BSD. Il y a eu des analyses (type reverse engineering) qui tendaient à aller dans le sens de MS (cf par exemple http://seclists.org/fulldisclosure/2005/Mar/884). Bref…

XeTeX et LuaTeX ne sont pas des surcouches de TeX mais de nouvelles implémentations du moteur TeX. Pour savoir où tout ceci se dirige, cf cet excellent article de Frank Mittlebach : http://latex-community.org/know-how/latex/55-latex-general/475-e-tex

Si comme moi vous n'appréciez pas gnome shell, unity, cinnamon et autres machins du même genre, mais que vous aimez un peu de bling, Cairo-Dock est une excellente alternative. Ça donne l'impression d'être plus léger que les autres bureaux bling (je n'ai pas fait de tests précis, mais c'est vraiment beaucoup plus réactif chez moi) tout en étant très configurable. J'utilise ça avec une session gnome pour avoir accès à tous les services (comme le keyring, etc.) sans me compliquer la vie. En modifiant un peu le thème par défaut, j'ai quelque chose qui respecte mes habitudes issues de gnome 2, et ça, ça n'a pas de prix :-). J'ai testé quelques jours xfce, mais je n'en ai retenu que le « lanceur » (xfce4-appfinder), pas assez de bling pour le reste pour moi (l'absence d'animation lors des transitions quand on passe d'un bureau à l'autre me gène pas mal, par exemple).

Il y avait un petit bug dans la version 3.2.0 qui donnait des affichages très étranges sous emacs, suite à un problème de pilote de carte graphique, mais comme l'option associée a été désactivée par défaut dans la version 3.2.1, c'est de nouveau nickel.

Bref, un super projet, bravo et merci à l'équipe !

C'est à prendre pour ce que c'est mais pour m'être amusé à comparer, je n'ai jamais vu de différences entre le RGBM de mon vyper air et des Uwatec par exemple. le seul élément qui diffère, c'est que sur le Suunto tu fais +3min dans le palier obligatoire.

Ça dépend quand même du modèle et de ton historique récent de plongées (genre la veille). Je me suis régulièrement retrouvé avec 5 (+3) minutes de palier alors que certaines personnes de la palanquée n'avaient rien du tout sur leur vieil aladin, par exemple. Ceci dit, le planificateur de Suunto (sorti en même temps que le Helo) donne des profils très proches du buhlman + GF sur des plongées sans helium et oui, c'est parfait pour le runtime. C'est d'ailleurs l'inclusion du planificateur dans subsurface qui m'intéresse le plus : plus besoin d'un windows dans virtualbox pour faire tourner le bousin de Suunto :-)

Je t'avoue que je me demande bien comment le RGBM est réellement implémenté, parce que cet algorithme a évolué énormément, passant de profils farfelus (et dangereux) à un truc assez conservateur (cf http://www.divernet.com/other_diving_topics/tek_diving/160874/bubbles_gone_bad.html par exemple). Ils sont allés jusqu'à bidouiller le truc pour introduire les paliers profonds, ça laisse rêveur (et ça ne donne pas envie).

Ceci dit, à titre personnel, je préfère ne pas faire de plongée avec paliers sans planification sérieuse (et le matériel approprié) donc sur des vraies grosses plongées je suis toujours en accord avec mon binôme (pas de palanquée dans ce cas), vu qu'on plonge essentiellement au run time. Je ne dis pas qu'on ne triche pas à la fin si on a fait du multi-niveau et que les deux ordinateurs (et les backups au cas où) sont d'accord pour dire qu'on peut sortir avant les indications du run time, mais on ne s'amuse jamais à être en retard sur le run time.

Ouaip et je ne comprends pas pourquoi Suunto s'obstine à sortir des machins bling bling en titane plutôt que de passer enfin à l'OLED (ou au moins à un LCD IPS), sans compter les controverses sur le RGBM versus VPM ou le bon vieux Bühlmann avec les GF).

L'éclairage OLED des HW (ou des shearwater) n'est comparable à rien. J'ai plongé avec des gars équipés avec ce type d'ordinateurs, c'est juste incroyable. Au palier, à 5 mètres de ton binôme, tu peux lire clairement les indications de son ordinateur (et donc comparer les profils de déco, d'ailleurs). En speleo, ça fait une quatrième lampe ! Quand je regarde le pauvre écran LCD minuscule et tout pourri de mon vytec, je me dis qu'il est grand temps que je change :-)

Je suis tout à fait d'accord avec la nécessité d'avoir un ordinateur, mais ta justification me semble plus conduire à la conclusion de changer de moniteur que d'acheter un ordinateur, comme tu le dis toi même. C'est d'ailleurs à mon avis quelque chose qui manque dans la formation : on devrait t'expliquer clairement les comportements inacceptables des moniteurs avec les plongeurs non autonomes (genre ne pas te demander ton niveau d'air, te laisser t'éloigner, etc.) et t'inciter ainsi à un minimum de réflexion critique. Comme je suis N3 et que la carte est un passe partout amusant à l'étranger, il m'arrive souvent de traîner volontairement à l'arrière des groupes dans les plongées guidées. Je vois des comportements de moniteur qui me donnent le bourdon… D'un autre côté, personne ne m'emmerde, ce qui n'est pas mal non plus :-)

Tu as raison, j'avais oublié la limite de taille des fichiers (qui est de 4 Go pas de 2). C'est potentiellement chiant pour la vidéo, parce que qu'on crache quand même de l'ordre de 25 Mo par seconde en full hd compressé et que 4go ne font alors que moins de 3 minutes de vidéo. C'est probablement l'argument utilisé par MS pour forcer exFAT dans la norme sxdc…

Toutes les cartes SD haut de gamme (sdxc) sont formatées en exFAT. J'ai cru comprendre que cela faisait partie du standard. On peut bien sûr repasser en FAT, mais exFAT est supposé plus adapté pour la mémoire flash (j'ai quelques doutes…). exFAT supporte beaucoup plus que 2To de données (contrairement à FAT) mais comme les cartes sdxc sont limitées à 2To (justement ;-), le reformatage en FAT ne pose pas de problème. Donc en pratique, MS a réussi à imposer exFAT d'une façon injustifiée techniquement, ce qui provoque une propagation de cette maladie : mon D800 supporte exFAT (et donc j'ai payé indirectement des royalties à MS) car il supporte le format sdxc et que Nikon ne peut pas demander à son utilisateur lambda de reformater en FAT sa carte toute neuve. Et c'est pareil avec tout le matériel qui supporte sdxc. Bien joué MS :-(

Les lois sont amusantes, mais les bouquins d'Asimov sont affreusement mal écrits et semblent destinés pour beaucoup d'entre eux aux adolescents. Le pire, à mon avis, se trouve en dehors des robots et cie dans les fondations VI et V (fondation foudroyée et terre et fondation) : c'est long, c'est chiant, c'est mal écrit, l'horreur. Oui, c'est mal de dire ça, on doit le respect aux anciens ;-)

À titre personnel, je suggère donc de fuir Asimov et certains auteurs que je range dans la même catégorie comme Van Vogt (quand je pense que j'ai presque tout lu de lui…). Aux suggestions diverses sur cette page (j'approuve en particulier à 100% la recommandation de la horde du contrevent qui est un chef d’œuvre littéraire même comparé à des romans plus classiques et hors du ghetto SF), j'ajoute :

• Neal Stephenson dont je trouve l’œuvre majeure, avec des monuments comme Le Samouraï virtuel (dystopie dans un futur proche avec de virus mentaux, de la nanotech, etc.), L'Âge de diamant (nanotech à fond) et, incontournable, Cryptonomicon (uchronie sur la seconde guerre mondiale et crypto moderne) ;
• de Beauverger, je conseille très vivement le déchronologue qui est merveilleusement écrit (presque aussi bon que Damasio dans la horde du contrevent) et très intelligent. Ça parle de pirates confrontés à des phénomènes temporels mystérieux ;
• j'ai beaucoup aimé Des milliards de tapis de cheveux de Andreas Eschbach dont la narration, sans atteindre la déconstruction de Beauverger, est assez originale pour de la SF. L'écriture est un peu étrange (probablement à cause de la traduction, mais je ne lis pas l'allemand), mais c'est assez saisissant : sur une planète perdue, des hommes tissent des tapis avec les cheveux de leur femme et concubines…
• dans le même style de pirouette narrative, j'ai bien aimé me faire manipuler par Christopher Priest dans le Monde Inverti. Tous les lecteurs n'adhèrent pas et l'écriture de la fin aurait pu être meilleure, mais c'est quand même bien fichu. Je colle la citation obligatoire : J’avais atteint l’âge de 1000 Km.
• dans les français, je recommande aussi Pierre Bordage. Malgré quelques aspects cucul la praline je trouve Les Fables de l'Humpur vraiment excellent, dans l'écriture et dans le récit (des hybrides homme/animaux). Et bien sûr, je conseille vivement Les Guerriers du silence, un space opera très impressionnant, un peu long par moment, mais assez exceptionnel d'imagination et de noirceur (même si le cucul-la-pralinisme de Bordage se retrouve vers la fin). Cerise sur le gâteau : c'est délicieusement anti-religion.

Le kecak est une danse de Bali et en Indonésien le c se prononce effectivement tch. Comme c'est une ancienne colonie des Pays-Bas, il y a peut être un lien. Mais deux c au milieu ça fait douter…

Petite question ; ton serveur se fait « hacker » parce que tes utilisateurs ont des mots de passe trop faibles ou parce tu es victime d'un 0 day quelconque ?

En fait, l'utilisabilité, tout le monde se déclare expert quand un point l'ennuie.

Mais non, c'est toi qui nous parle de science pour nous clouer le bec. Voilà, moi, personnellement, ça me fait chier de ne plus avoir le choix entre éteindre et les deux niveaux de mise en veille de façon simple et directe. Je ne prétends pas être expert, je dis juste que ça me fait chier. C'est pas compliqué à comprendre, si ? Je veux simplement qu'on arrête de me dire que je suis un vieux con qui ne veut pas changer parce que ce choix de me fait chier. Et je n'ai pas non plus envie que quelques développeurs qui ne connaissent pas un dixième de ce que je connais en ihm et en évaluation viennent me faire une grande leçon sur le génie scientifique qui a conduit à virer cette option que je trouvais, personnellement, pratique. Je veux juste qu'on me dise clairement qu'il ne faut pas que j'utilise le shell (ou unity, poua) et qu'on ne me dise poliment, c'est-à-dire sans avoir des prétentions pseudo-scientitiques. Et je pourrais ensuite dire tout le mal que je veux du shell et d'unity, sans prétendre que j'ai raison scientifiquement.

Le fait qu'on ne comprenne pas beaucoup de choses, qu'on aie encore des erreurs énormes n'implique pas que ce ne soit pas une science.

Tu remarqueras que j'ai écrit « on est bien loin de ce que tu racontes » pas que la démarche des gens en ihm et visualisation n'était pas scientifique. En revanche, ce n'est pas encore vraiment une science au sens de la physique car il n'y a pas encore beaucoup de lois établies de la nature en ihm (excepté peut être la loi de Fitts). En outre, certaines expériences très bien faites, comme celles de Cleveland et McGill sur la perception des camemberts sont remises en question par des expériences de plus grande envergure récentes. Il se trouve que dans le séminaire que j'ai co-organisé à Dagstuhl, on a passé plusieurs heures à discuter de ça et plus généralement de la difficulté qu'on a évaluer la qualité d'une visualisation, en présence de certains de plus grands spécialistes mondiaux du domaine (pas moi, hein ;-). Bref, tu confonds démarche scientifique (indéniable pour les chercheurs en visualisation/ihm) et science.

Quand les égyptiens ont décidé que le rapport entre un diamètre et la circonférence d'un cercle était de 3,25, ils se trompaient. Pourtant, c'était de la science.

Les mathématiques ne sont pas une science, c'est un langage. On ne prouve rien expérimentalement en maths, alors que c'est la base de la démarche scientifique. Les égyptiens ont bien eu une vague science expérimentale, comme les grecs, les romains, etc. et ils ont eu aussi des embryons de maths. Mais il a fallut attendre Hilbert et des gens comme ça pour qu'on comprenne vraiment la différence entre les maths et le reste. Les égyptiens avaient donc une démarche scientifique et avait prouvé une loi, le lien entre la circonférence de ce qu'ils appelaient un cercle et son diamètre. Les erreurs de mesure aidant, ils avaient trouver expérimentalement pi et ils avaient raison physiquement sur le fond (le lien linéaire entre la circonférence et le diamètre). Il a fallut attendre les maths les vraies pour qu'on donne un sens logique à tout ça et qu'on prouve une propriété mathématique sur l'objet abstrait cercle qui mathématise l'objet physique.

Mais je ne vois pas le rapport avec les ihm, pour être honnête… Et le problème de fond est l'incohérence du discours, genre nous on a raison parce qu'on est scientifique et oui, bon, c'est vrai, on fait ça à la va comme je te pousse…