CPU ⬜ Carré Petit Utile

Extrait de l'émission CPU release Ex0222 : lost + found (rentrée 2025) seconde partie).

Vous vous souvenez d'Hebdogiciel ? Mais si, le Hara Kiri de la micro-informatique des années 1980s, qui a tenté de se suicider en titrant « Désolé, l’informatique c’est de la merde ». C’était à l'été 1985. Hebdogiciel aura duré 2 ans de plus, sans compter le magnifique hommage rendu par ST Magazine avec son hors-série STMagiciel de l'été 1991. Rassurez-vous, ST Mag a tenu jusqu'en 1998 (moi, pas : j'étais passé à l'Amiga).

L'idée n'était pas nouvelle, et je ne parle pas du cuisinier pseudo-animateur télé, ou de l'animateur télé pseudo-gastronome, on n'sait pas, on n'sait plus. In English, Natürlisch, ce sont les fameux articles « XYZ Considered Harmful ».

La mode a commencé en 1968 avec l'article « GOTO Statement Considered Harmful » d'Edsger Dijkstra, et le père Dijsktra, c'était pas Jojo l'clodo (oui j'aime bien me lancer des défis radiophoniques comme tenter de prononcer 2 fois en suivant Dikjsr….) En plus le titre « … Considered Harmful » c'était même pas de lui, c'était une idée de Niklaus Wirth. Le Professeur Wirth était alors éditeur du journal auquel Edsger avait envoyé son article « A Case against the GOTO Statement ». Le Révérend Père Wirth, il était bien content de trouver un supporteur de la programmation structurée qu’il avait créée avec son langage, Pascal. Et maintenant il faut que j’insère un numéro de ligne pour sauter au paragraphe suivant !
C’est une blague de programmeur. Si vous l’avez pas, z’aurez qu’à demander à ChatGemini.

Depuis ces temps glorieux, le wiki originel c2.com, pâlement imité par Wikipedia, recense les « XYZ Considered Harmful », ficelle facile ayant conduit à nombre d'articles parfaitement dispensables… il y a même un « Considered Harmful Considered Harmful ».

[respiration]

N’empêche que… il y a un « Markdown Considered Harmful », ça doit vouloir dire quelque chose ?
Et pas qu’un… je me suis arrêté à 10 résultats de recherche (que vous trouverez dans les notes de l'émission. Oui Da Scritch, je sais pas compter.)

Alors pour ceux qui ne connaissent pas, Markdown c’est du texte brut mis en page façon machine à écrire, par exemple sous les titres on met une ligne de tirets, ça fait un souligné façon ASCII Art. C’est une syntaxe qu’on peut compiler en HTML, en PDF, etc., l’intérêt étant que c’est plus plaisant à écrire que saisir directement du HTML.

Alors, où est-ce que ça a vrillé ?

Pourtant, ils avaient rationalisé tout ça dans CommonMark. Vraiment ? Pardon, Github-Flavored Markdown. Heuuuu. Avez-vous regardé la liste des dialectes supportés par Sundown ? Showdown ? Pandoc ? Ma preview qui marche bien dans Visual Studio Code, est-elle vraiment compatible avec GitHub ? (Spoiler : non.)

Demandons à ChatGPT… pardon, Wikipedia : je cite, https fr.wikipedia.org Markdown # Évolutions, :

Markdown n'a jamais été formellement standardisé, diverses variantes ont été développées par des tiers afin de pallier ce qui était perçu comme des limitations du langage originel.

Il est sérieux lui ?

Évidemment qu'il était séduisant, l'aperçu au rendu impeccable dans Visual Studio Code, mis à jour en temps réel et scrolling synchronisé avec le fichier-source côte à côte. Pis le côté obscur de la force aussi, il était séduisant.

Pourquoi, pourquoi ai-je abandonné AsciiDoc au profit de Markdown ? Il était bogué, c'est un fait. AsciiDoctor alors ? C’était un progrès, mais ça restait page-oriented : 1 fichier source = 1 fichier HTML (ou PDF). Sauf que Markdown aussi.
Au moins, en AsciiDoc ils avaient des includes ! Mais bien sûr, que je peux appliquer un préprocesseur sur chaque fichier Markdown… et ça va marcher par l’opération du Saint-Esprit lors de la preview dans Visual Studio Code ? RHAAAAA

Peut-être qu’ils ont raison les Pythoneux d'écrire en Sphinx. Ou plutôt en ReST (ReStructured Text), ou je-sais-plus-quel acronyme débile ces demeurés ont choisi alors que REST, c'est déjà pris par un concept totalement différent (REpresentational State Transfer), et c'est pas comme si c'était dans un domaine totalement déconnecté du Web Dev !
Mais enfin, je suis plus étudiant ! j'ai passé l'âge de L^aT_eX ! (Cette phrase ne sonne pas du tout comme prévu.)

[Da Scritch] — huu, ça s’écrit latex mais ça se prononce latech
[Mézigues, peinant à garder son calme] — j’ai pas fini ma chronique…

Je fais quoi alors, je reviens à DocBook XML ? J'écris des manpages en roff ? Ah ben non, nroff. Ah ben non, troff. Ah ben non ! Maintenant c'est GNU groff pour les manpages Linux ! J't'en foutrais du groff, GRRRRR !

…Ils peuvent quand même pas être dans l’erreur par millions, les utilisateurs de GitHub ? Ben si. Il n’y a pas d’indice ni d’exposant en Markdown. Pandoc peut le faire, mais c’est incompatible avec les autres dialectes, what-did-you-expect ? AsciiDoc pouvait le faire de base !

Da Scritch, qui est un vrai webdev, pas un guignolo comme moi, me rappelle que techniquement je pourrais utiliser des balises HTML, et c’est vrai ! Le révérend-père Saint-John Gruber l’a dit, verset Inline HTML, et les grands prêtres de l’église du CommonMark l’ont écrit, clause 6.6 HTML brut. D’ailleurs il y avait du Aaron Swartz là-dedans, mais c’est pas parce que le type était un génie qu’on m’empêchera de dire que Markdown, c’est du caca !

Car enfin, si je voulais faire du mark-up, j’utiliserais pas Markdown ! Vous postez sur vos forums en HTML ? Non, vous écrivez en BBcode. Vous écrivez vos pages Wikipedia en HTML ? Non, vous utilisez le langage Wikitext (oui bon ok, Wikipedia dit que Wikitext est un markup… Da Scritch mon petit, la vérité m’oblige à t’le dire : ton markdown commence à me les briser menues.)

L’ironie est que GitHub supporte nativement AsciiDoctor. Le site asciidoc.org a été considérablement modernisé, alors qui sait, leur implémentation de référence est peut-être nettement moins boguée qu’à l’époque où elle avait créé un vide comblé par AsciiDoctor ? Ils ont même un asciidoc.js pour les éditeurs web entièrement client-side. C’est décidé, je retourne à la maison, je ressors mon makefile asciidoc vieux de 10 ans et je n’écrirai plus jamais un seul README.md.

[respiration]

Mais pourquoi je vous parle de ça ? En vrai, comme disent les djeun’z, je voulais juste convertir en HTML mes notes Markdown, il est vrai magnifiquement rendues par ledit Visual Studio Code.

Tout ça en vue de souder un adaptateur de joystick analogique PC vers Atari STe… saisir le schéma d’un harnais de câblage…

EasyEDA, l’éditeur en ligne ou hors ligne de JLCPCB ? Il est dédié à la conception de circuits imprimés, et son catalogue de composants est limité, même si j’ai bien trouvé une prise DA-15 en solder buckets, donc à souder sur des fils volants.

KiCad alors ? Pareil, KiCad c’est pour faire du circuit imprimé. Un circuit imprimé à la fois d’ailleurs… parce que je ne suis évidemment pas le seul à poser la question : quel workflow pour concevoir plusieurs circuits imprimés interconnectés, par exemple une carte-mère, un panneau de façade et quelques connecteurs et interrupteurs volants, reliés par fils ?. Un harnais, quoi.

La réponse ? Tu fais pas. Enfin t'ouvres un nouveau projet KiCad pour chaque carte, et t’assures la cohérence à la main. J’imagine qu’on peut écrire un script Python pour valider la correspondance entre les connecteurs inter-carte… c’est particulièrement croustillant quand on sait que les connecteurs pour câble en nappe comme on avait sur les vieux disques durs, les lecteurs de disquette (voilà, l’icône de sauvegarde - et ma main dans ta face tu la vois ?), ces connecteurs ont été inventés pour interconnecter des circuits imprimés. Et en 2025 on peut toujours pas le faire dans KiCad ? Altium Designer, il peut le faire… si t’as la bonne licence. Annuelle bien sûr parce qu'on est en 2025. Certes, KiCad c’est pas cher, et c’est vraiment pas de la daube, on peut même concevoir des lignes différentielles ultra haute vitesse PCIexpress avec égalisation de longueur et impédance contrôlée… [fade out]

Parmi la masse de réponses mi-figue, mi-raisin sur Stack Overflow et consorts, j’ai découvert un soft tout simple pour noter le câblage de mes connecteurs D-Sub : WireViz. Tutoriel rapide et efficace, entrée en YAML intuitif, sortie en HTML, powered-by-GraphViz, avec en prime génération de la BoM, la Bill of Materials. La liste des composants.

On peut même mettre une image pour chaque connecteur. Faudra que je vous parle de la norme [air quotes] D-Sub ! Vous saviez que dans les connecteurs D-Sub, le numéro de chaque pinouille est moulé dans le plastique en tout petit ? Et des deux côtés ! C'est des génies ! Côté pinouilles, visible capot refermé, et côté soudure ! Des génies qu'on vous dit, pas possible de décaler toutes tes soudures d’une pinouille (cherche pas…)

Direction Wikimedia Commons et hop, une image de connecteur DA-15F et une de connecteur DE-15M.

Pourquoi, oh pourquoi eut-il fallu que je testasse cette fonction ? WireViz marche parfaitement avec les PNG de Wikimedia Commons, mais en toute logique les chiffres sont petits à l’échelle du schéma entier, et comme ce sont des images raster, quand on zoome, c’est flou. Vous qui êtes senior web devs, vous connaissez la solution : SVG.

Ni une, ni deux, j'édite mon YAML pour référencer les SVG à la place des PNG et paf ! GraphViz bombe. Hé bé ? Le paquet MacPorts par défaut n’est pas compilé avec la librsvg. Une ligne de commande plus tard, GraphViz est rebuildé avec support SVG. Sauf que l’API Python utilisée par WireViz ne comprend ni la taille ni l’aspect ratio des SVG, en tout cas de Wikimedia Commons. Epic Fail…

Comme disait monsieur Brochand, bon, on a assez perdu de temps comme ça !

SVG Considered Harmful ?

Cette chronique a été rédigée dans VIM. Faudra que je vous parle de vi et comment il a été amélioré... [fade out]
C’était Benoît pour CPU.PM avec la participation de l’asso Silicium pour la préservation du patrimoine rétro-informatique et vidéo-ludique. Oui oui l’Atari STe, tout ça tout ça. Faudra que je vous parle de l’évolution de l’Atari STf en Atari STe… Da Scritch rends-moi c’micro !

Textes : Ben
Voix complémentaire : Da Scritch
Illustration : Logo du langage MarkDown, CC0 Dustin Curtis, image dramatiquement modifié pour des besoin euh publicitaires ?