2 points par GN⁺ 2024-02-12 | 1 commentaires | Partager sur WhatsApp
  • Aho est une implémentation de Git en AWK, un projet ludique destiné à explorer la structure interne de Git et les nouvelles fonctionnalités de GNU AWK
  • Son objectif n’est pas un usage réel, mais le divertissement et l’apprentissage ; ce n’est pas un projet conçu pour servir d’alternative à Git
  • Son exécution nécessite gawk 5.0 ou supérieur ; pour la compression zlib, il utilise actuellement pigz, et suppose par ailleurs un environnement fourni par GNU coreutils
  • Il peut fonctionner sur la plupart des distributions Linux, mais n’est pas bien adapté aux environnements BSD/Mac
  • Les fonctionnalités implémentées sont init, add/rm, status, commit, config en lecture seule et cat-file ; il n’est pas prévu d’ajouter les fonctions réseau clone et push

Objectif et périmètre d’Aho

  • Aho est un projet qui vise à être « Git implémenté en AWK »
  • C’est un projet ludique destiné à montrer que l’AWK moderne peut faire bien plus que de simples scripts d’une ligne
  • Il se concentre sur l’exploration de la structure interne de Git et des nouvelles fonctionnalités de GNU AWK
  • Il s’agit d’un projet pensé davantage pour le divertissement et l’apprentissage que pour un usage pratique

Environnement d’exécution

  • L’environnement requis est le suivant
    • gawk 5.0 ou supérieur
    • pigz pour la compression zlib
    • GNU coreutils
  • Il peut fonctionner sur la plupart des systèmes Linux, mais n’est pas adapté aux environnements BSD ou Mac

Flux d’utilisation de base

  • Après avoir préparé l’environnement avec source ./modpath, exécuter aho init initialise un dépôt Git vide dans le répertoire .aho
  • aho add -v . ajoute les fichiers et affiche des éléments comme .gitignore, LICENSE, README.md, aho, aho.awk, include/*.awk
  • Après avoir créé un nouveau fichier, exécuter à nouveau aho add -v . ajoute également ce fichier
  • Sous .aho/, une structure similaire à celle de Git est créée
    • branches
    • config
    • description
    • HEAD
    • index
    • objects
    • refs/heads
    • refs/tags
  • Un exemple est fourni montrant que l’outil Git peut lire les entrées d’index du dépôt .aho avec GIT_DIR=.aho git ls-files --stage

Fonctionnalités implémentées et travail restant

  • Fonctionnalités terminées
    • init
    • add/rm
    • status
    • commit
    • config en lecture seule
    • cat-file
  • Fonctionnalités pas encore terminées
    • reset
    • branch
    • switch
    • ls-files

Les fonctionnalités réseau sont exclues

  • Il n’est pas prévu d’ajouter des fonctionnalités réseau
  • Même s’il est possible d’implémenter des fonctionnalités réseau en GNU AWK, il n’est pas prévu d’intégrer clone ou push à Aho
  • Les contributions apportant des retours utiles pour améliorer la connaissance d’AWK ou de Git sont bienvenues

1 commentaires

 
GN⁺ 2024-02-12
Avis Hacker News
  • Awk est génial. Sur les systèmes de type Unix, c’est un langage de programmation complet qu’on trouve presque partout, mais dans les faits il semble surtout servir à écrire des commandes d’une ligne pour extraire des morceaux de texte depuis une sortie standard chaînée par pipe.
    Pourtant, Awk peut aussi servir de langage de script généraliste, et dans cet usage il est meilleur que Bash à bien des égards. Je me demande pourquoi on ne voit pas plus souvent de scripts Awk dans la nature. C’est peut-être lié au fait que Perl a essayé de réunir dans un seul langage les points forts du shell, d’Awk et de sed, puis que les gens ont fini par voir Perl d’un mauvais œil et s’en sont détournés.
    [1] Extrait arbitraire du code source de NetBSD : https://github.com/NetBSD/src/blob/trunk/sys/dev/eisa/devlis...

    • C’est juste. Perl a remplacé Awk, mais dans beaucoup de cas cela a eu un effet contre-productif. Il n’y avait pas de manière simple et largement comprise d’écrire du code Perl facile à lire pour d’autres programmeurs et extensible jusqu’à des programmes moyens ou grands.
      Cela ne veut pas dire que personne n’y soit jamais bien arrivé, mais le taux de réussite dans l’ensemble du secteur était faible, ce qui a valu à Perl une assez mauvaise réputation.
      J’aimerais voir Awk revenir. Awk est moins facile à étendre fortement, donc le risque qu’un projet commencé comme un petit script Awk soit transmis à la personne suivante sous forme d’une base de code Awk de plusieurs milliers de lignes est plus faible. À la place, on finit assez tôt par le réécrire dans un langage plus extensible et plus maintenable.
    • Peu m’importe ce que les gens en pensent, j’ai découvert que j’aimais Perl. Mon dernier projet est un éditeur de partitions programmable. C’est un peu comme vider des partitions avec sfdisk, mais je voulais faire plus qu’une simple suppression, et je voulais combiner des tables de partitions MBR et GPT pour créer un hybride.
      C’était amusant, et je réutiliserai Perl. Maintenant que j’ai vu qu’Awk était aussi cool que ça, je l’utiliserai peut-être un jour aussi.
      [1] https://github.com/csdvrx/hdisk/
    • Awk est incroyablement utile. Cette semaine, j’ai écrit un script pour parser des logs Postgres de plusieurs dizaines de Go afin de répondre à la question : « quels utilisateurs lançaient le plus de requêtes pendant les quelques minutes juste après chaque heure pile ? »
      Quelques fonctions, un peu plus de 20 lignes de code au total, et quelques pipes vers sort et uniq ont suffi, et c’était assez rapide. Encore plus rapide, surtout, en préfixant avec LC_ALL=C.
      [0] : Si vous demandez pourquoi l’observabilité n’était pas suffisamment en place pour éviter ce genre de tâche, vous n’avez pas tort, mais il faut parfois vivre avec la réalité telle qu’elle est.
      [1] : Je sais que gawk peut produire des listes en effectuant un tri unique. C’était la fin d’une intervention sur incident, j’étais fatigué, et | sort | uniq -c | sort -rn était beaucoup plus facile à retenir.
      [1].a : Je sais aussi que sort a une option -u. Elle ne fournit pas le comptage, et sa déduplication est aussi nettement plus lente que l’implémentation de uniq.
    • Le jugement selon lequel Perl serait mauvais est un moteur important de la renaissance d’Awk. Les développeurs qui n’ont pas appris Perl dès le départ veulent quelque chose pour combler le vide entre le shell et Python, et il y a aussi des développeurs comme moi qui ont abandonné Perl à contrecœur.
      Comme les gens dans le goût de HN ont considéré Perl comme « pas cool », Perl et tout le code écrit en Perl ont désormais, en quelque sorte, une date de péremption. Mais Awk est un standard POSIX, donc ces gens ne peuvent pas le faire disparaître.
    • J’aime AWK. Son typage centré sur les chaînes ferait rougir un programmeur Javascript. 0, "" et l’absence réelle de quoi que ce soit sont tous la même valeur fausse.
      Les nombres ne sont pas distincts des chaînes qui représentent des nombres, comme en Lua. Et pourtant, bizarrement, cela ne me dérange pas. Si vous devez absolument conserver les nombres comme nombres et les chaînes comme chaînes, il suffit d’ajouter un marqueur comme # ou $ devant la valeur, puis de le retirer plus tard avec substr().
  • The AWK Programming Language, Second Edition est sorti en septembre 2023.
    https://awk.dev
    La première édition a été publiée en 1988 et peut être consultée ici : https://archive.org/details/pdfy-MgN0H1joIoDVoIC7
    Discussion : https://news.ycombinator.com/item?id=13451454

    • Cet intervalle de 35 ans est une bonne anecdote à raconter quand un éditeur demande : « Alors, où en est la deuxième édition ? »
    • Brian Kernighan est aussi de la partie. C’est le « K » de K&R C, et la figure de bien d’autres légendes d’Unix.
  • Quand on voit du code comme function read_objfile(obj, objpath, bytes, end_of_header, header, end_of_type, type, size, bytes_after_header), les paramètres après le grand espace sont des variables locales. On peut leur passer des valeurs, mais ce n’est pas l’usage prévu.
    J’ai écrit un patch pour GNU Awk ajoutant une instruction let qui lie de vraies variables lexicales, afin de pouvoir écrire quelque chose comme function read_objfile(obj, objpath) { @let (bytes, end_of_header, header, end_of_type, type, size, bytes_after_header) { } }.
    Malheureusement, le projet l’a refusé et m’a conseillé de créer un fork de GNU Awk sous un autre nom, ce que j’ai fait.
    https://www.kylheku.com/cgit/egawk/about/

    • Je trouve que leur décision se défend. gawk diffère déjà beaucoup trop d’awk. Si l’on ajoute une syntaxe encore plus distincte, autant en faire un fork et lui donner un autre nom.
  • Quand on me demande pourquoi je dis que la ligne de commande Linux est le meilleur environnement de développement, l’un des outils que je cite souvent est Awk. Même en ne connaissant que les bases d’Awk, on peut faire beaucoup avec peu, et un IDE peut même commencer à paraître lourd
    Si vous voulez apprendre Awk et que les cours magistraux vous conviennent, j’ai enregistré sur YouTube une présentation que j’avais faite il y a quelques années pour Linux Fest Northwest : https://youtu.be/E5aQxIdjT0M

    • En même temps, la prise en charge d’Unicode n’a été ajoutée que très tard, probablement il y a environ deux ans. Comme avec d’autres outils shell, il y a aussi des cas limites quand on envoie du contenu à Awk via un pipe
      Des séquences similaires à CTRL+D peuvent couper l’entrée, et il existe sans doute des dizaines d’autres cas limites que je ne connais pas, qui vous mordront au pire moment
      Awk est un outil impressionnant, mais le mettre sur un piédestal masque ses faiblesses. Pour un travail sérieux, il vaut peut-être mieux passer à des outils plus spécialisés, modernes et adaptés à la tâche
    • En quoi Awk remplace-t-il un IDE ? J’aime Awk, et je sais qu’il devient puissant si l’on prend le temps de l’apprendre, mais sans IDE ma productivité aurait beaucoup chuté
      La majeure partie de ce que fait un IDE n’est pas de l’édition de texte, mais d’aider à comprendre et à modifier le code. Je ne dis pas que c’est faux ; je suis curieux de comprendre le point de vue derrière cette affirmation
  • Au début, je pensais que ce nom venait de l’argot japonais aho (アホ), qui signifie « idiot », puis je me suis souvenu qu’Alfred Aho est le a de awk. Peut-être les deux ?

    • Probablement les deux. « Git » était déjà un mot d’argot pour dire « personne stupide », donc c’est un nom plein d’esprit
    • Je l’ai entendu récemment dans Reservation Dogs : https://en.wiktionary.org/wiki/aho#Navajo
    • Probablement les deux. C’est un jeu de mots vraiment malin
  • Excellent projet et bonne idée. Comprendre les bases donne une autre perspective sur d’autres projets et problèmes
    Il y a quelque temps, j’ai créé un wiki web en Awk. La raison était que j’utilisais un routeur Linksys avec très peu de mémoire
    C’était idéal pour apprendre à la fois comment fonctionne un wiki et ce qu’on peut faire avec Awk. Comme il n’y avait pas de bibliothèques sur lesquelles s’appuyer, il fallait implémenter soi-même les fondamentaux, ce qui m’a permis de vraiment comprendre

  • Il est dit : « Je ne prévois pas d’ajouter de fonctionnalités réseau ici. Bien sûr, ce serait possible, mais il n’y aura pas de clone ni de push » ; pourtant, on peut faire un git clone depuis un dépôt situé dans un autre répertoire du même ordinateur, et aussi faire des push

    • Exact. Mais avec des branches, le besoin de créer des clones locaux diminue dans une certaine mesure. En pratique, j’utilise rsync pour dupliquer des dépôts git locaux. La question est de savoir quelle est la meilleure approche
    • C’est tellement évident, et pourtant en dix ans d’utilisation de git, je n’ai jamais pensé à essayer
  • Je garde l’idée qu’avec quelques utilitaires et programmes GNU, et sans doute pas grand-chose de plus, on pourrait créer une base de données et un outil de traitement tout-puissants dépassant les outils spécialisés en performances comme en fonctionnalités. Suis-je le seul à avoir cette impression ?

  • Peut-être lié
    sed-chess : https://news.ycombinator.com/item?id=37896854
    awk-raycaster : https://github.com/TheMozg/awk-raycaster

  • S’il avait utilisé cppawk, qui n’existait pas encore au moment du développement, il aurait pu utiliser #include. Cela fonctionne bien avec des chemins relatifs au fichier et ne nécessite pas AWKPATH
    On peut aussi « construire » le programme prétraité en un seul fichier, ce qui évite ensuite d’avoir besoin de cppawk
    https://www.kylheku.com/cgit/cppawk/about/