hocwp a écrit 331 commentaires

Oui, c'est ce qui est mis en place sur SourceHut.

Mille mercis pour le partage !

Oui embarqué avec support+consulting pour MPE.
GreenArrays est à un tout autre niveau : la boite a été créée par Charles Moore, l'inventeur du Forth. Ils développent leur propre stack hardware basée sur des mini ordinateurs en parallèle, qui consomment très peu, programmés en colorForth.

Si on en croit ce que disent les personnes de chez MPE, oui il semble utilisé : https://www.mpeforth.com/sample-page/46-2/ et https://www.mpeforth.com/sample-page/about-forth-2/
GreenArrays a toujours l'air vivant https://www.greenarraychips.com/index.html
Et des fois il y a des descendants du Forth qui sortent du garage. Comme Factor par exemple https://factorcode.org/. (juste un cas au hasard)

Ce colorForth est un fork de celui là. Je l'étend au grès des envies. Ce que je trouve sympa c'est qu'il tourne aussi bien sur un PC 64 bits que sur Arduino, sous DOS ou sur le web en webAssembly. J'ai encore quelques idées à mettre dedans avant de le considérer comme fini (au moins la partie centrale).

Désolé pour le 0 manquant. Il est très discrètement mis au début sur le screencast.

Et oui, avec un Forth standard, la définition courante est insérée avec le mot ;.
Le colorForth utilisé ici est 'tail call' optimisé. C'est pour ça qu'il faut commencer par garder l'ancienne référence two au 2 d'origine.
Écrire :2 ^2 ; ~2 fait partir en boucle infinie (qui n'explose pas le stack). Mais c'est volontaire d'avoir ce type de récursion.

Une interrogation que j'ai à propos du Forth (ou des logiciels maison en général) est de savoir à quel point on doit / peut communiquer dessus.
Ce Forth est tellement custom et adapté à ce que je recherche que je ne suis pas sûr qu'il convienne à quelqu'un d'autre ou que ça vaille le coup d'en parler.
D'un autre côté j'ai été super content d'avoir trouver la version d'Esr35 : c'était la version minimale d'un colorForth en C sur laquelle je suis tombé.
Il y a sûrement un juste milieu à trouver (ici mettre les sources sous licence libre).

Je suis aussi un grand fan de Forth sous toutes ses formes depuis de nombreuses années. Je pense aussi, comme totof2000 au dessus, qu'il a eu une grande influence sur ma manière de coder. Méthode très bien résumée ici Forth Methodology Applied to Programming. Comme dans le livre Thinking Forth.

Le Forth est un vrai terrier de lapin (en bon français) : on trouve toujours des choses super intéressantes dans les différentes implémentations (Gforth, pForth, zForth, retroForth, eForth, Dragon Forth et j'en passe d'autres milliers).
La dernière en date pour ma part étant Forsp qui mêle le Forth, le Lisp et le Lambda-calcul en ~700 lignes de C. Impressionnant !

De même que ce port d'eForth sur une machine SUBLEQ à 1 seule instruction. Ce qui prouve que le Forth peut vraiment tourner sur n'importe quelle machine ! Certain (ici présent) en ont même fait un OS bootable sur un vrai PC.

J'aime bien aussi la blague de 2 + 2 = 5 :

2 2 + . => 4
: 2 dup 2 = if 3 else 2 then ;
2 2 + . => 5

Ou dans une version en colorForth custom :

Ce qui est rigolo avec le Forth c'est qu'on peut le transformer à sa manière. On veut des coroutines, il suffit de les ajouter. Des quotations (une forme de lambdas en Forth), pareil, quelques lignes.

Bref d'énormes possibilités d'exploration. Toujours un truc à trouver !

Et évidement, ton sel doit être vide pour ne pas casser les mots de passes déjà générés.
Avec un commentaire qui incite à le modifier (ou pas) si on duplique la page sur un autre site.

Merci beaucoup pour l'idée ! J'étais à la recherche d'une telle solution.
Comme remarque, peut-être ajouter un sel global :

sha256(globalSalt + domain.value + "|" + password.value + "\n");

Comme ça chacun peut reprendre le code et changer le sel. Les mots de passes générés par ton site ne seront pas les mêmes sur les autres sites. Et chacun peut héberger sa page de génération de mots de passes.
Aussi mettre une licence sur le code pour lever les ambiguïtés.
Encore merci pour l'idée !

Et peut-être aussi doom-emacs : https://github.com/hlissner/doom-emacs/

C'est par exemple possible aussi avec les Shells d'Emacs :

Et vu que les images sont considérées comme des caractères, on peut les placer où on veut. C'est le cas du dernier exemple.
M'enfin c'est une chose dont je n'avais jamais eu besoin avant de lire le commentaire au dessus :-)

Je ne suis pas sûr : "Parce que cela permet d'écrire un bout de code, de compiler la fonction, et de la tester de suite."

Au passage merci à l'auteur pour le lien. Ce n'est pas encore hyper facile de le compiler mais le premier ressenti est vraiment sympa. Reste plus qu'à coder un adblock rapidement.

Hé hé ça a un goût de diner de con. Bon je me tais sinon je vais laisser aucun doute. :-)

Pour ceux qui n'aurait pas suivit et qui aurait tiqué sur le ton du début de journal : je suis l'auteur de la 1ère version de TapTempo en Clojure et de celle en Forth.
Je ne me permettrais pas de dénigrer de cette manière du code autre que le mien. Mais ces versions ne respectaient en rien le cahier des charges du journal initial (méa culpa). Ça m'apprendra à ne pas bien lire les specs… La version 2 me semble plus cohérente dans ce sens. On ne pouvait pas en rester à la 1ere version.

Je trouve génial toutes les versions qui ont fleuries sur github. C'est vraiment sympa d'avoir un programme un peu plus évolué qu'un 'hello world' avec toutes les fonctionnalités attendu.
Du coup un simple git clone et les explications pour compiler et on a un template pour un programme connu dans un langage qu'on ne maîtrise pas.

Oui, la version précédente était vraiment trop simpliste.

Les test unitaires sont exécutés à part avec la ligne de commande lein test (il faut que je le rajoute dans le README).
Pour le fonctionnement, la fonction is attend que tous les tests en argument soient vrais.

Donc par exemple pour :

(is (= (calc-tempo [60000 0]) [1N 2]))

L'appel à (calc-tempo [60000 0]) doit être égal à [1N 2]. C'est à dire 1 bpm avec 2 samples en entrées.
Si ce n'est pas le cas, le test ne passe pas.

Les premiers tests sont ceux attendu théoriquement. Les suivants sont de vrais échantillons (tu dois pouvoir voir l'heure à laquelle ils ont été pris :-) ).

Il faut bien que quelqu'un dise qu'Emacs le fait depuis des lustres.
Donc, c'est ce que font un shell ou un eshell et la fonction toggle-truncate-lines
Et au passage, c'est aussi valable pour les autres type de buffers.

Héhé en relisant ma page perso, je me suis souvenu qu'on peut faire des choses assez terribles en Forth : http://hocwp.free.fr/fex/

Pour résumer, les balises d'un document sont du Forth et quand ils sont évalués produisent le document.
C'est l'inverse du Lisp où Code is Data. En Forth Data is Code.

M'enfin ça ne sert à rien actuellement avec le markdown et consorts. :-)

Oui c'est voulu pour permettre de lisser les calculs du tempo sur 6 battements.

Pour le côté cryptique, c'est pas bien de ma part : je n'ai pas documenté l'usage du tas.

Mais en gros, au début on a le temps de départ et le compteur sur le tas.
A chaque itération de la boucle on diminue le compteur.
Quand il atteint 0, on calcule le tempo :

steps 60 1000 1000 * * * s>f => on place le numérateur steps*60*1000*1000 sur le tas des flottants.
drop => on enlève le compteur du tas
now => on place le temps actuel sur le tas
swap => on inverse le temps de départ et le temps actuel
- => on calcule la différence
s>f => on place le dénominateur sur le tas des flottants
f/ => on effectue la division

Merci à toi pour l'idée d'origine et aux auteurs pour les autres langages.
C'est vraiment fun de comparer les langages avec chacun sa culture !

Pour le parefeu, je sais pas mais pour l'audio bongo est vachement bien !

Cool : c'est le moment de mettre à jour son OS.
Merci pour la dépêche.

Tout pareil !

Il est présent pourtant, non ? J'ai répondu 'Le terminal par défaut de mon système d'exploitation'.
Perso eshell et des fois shell ou ansi-term (Les shell d'emacs).

Suffit d'utiliser emacs daemon / emacsclient. Mais il faut penser à redimensionner le serveur dans ce cas.
Oops pas pu attendre vendredi -> []

Si tu n'as pas besoin d'isoler ton programme des autres, tu peux utiliser stow. Il permet d'installer un programme dans un répertoire et de créer des liens dans /usr/local pour qu'il fonctionne correctement.
Sinon des fois, j'utilise un truc maison.

C'est une tuerie ce eev. Merci pour la découverte !