Posts

Es werden Posts vom 2010 angezeigt.

Pinned Post

OpenSpec UI: ein Live-Dashboard für deine Specs

Bild
OpenSpec UI: ein Live-Dashboard für deine Specs Wer mit einem KI-Agenten und OpenSpec arbeitet, kennt das Bild. Im Projekt wächst ein Verzeichnis openspec/ heran: Changes mit proposal.md , design.md , tasks.md und ihren Delta-Specs, daneben die kanonischen Specs der einzelnen Capabilities. Die Absicht hinter dem Code steht damit endlich geschrieben, statt sich in ihm zu verstecken. Nur verteilt sie sich über Dutzende Markdown-Dateien, und der Editor zeigt eben Dateien. Was er nicht zeigt, ist der Zustand. Woran arbeitet der Agent gerade? Welcher Task ist der nächste offene? Und was hat sich verändert, während ich zehn Minuten woanders hingeschaut habe? Genau diese Lücke füllt OpenSpec UI , ein kleines Phoenix-LiveView-Dashboard, das lokal neben deinem Projekt läuft und den OpenSpec-Workspace im Browser zeigt — live, während gearbeitet wird. Der Code liegt offen auf GitLab: https://gitlab.com/public_elixir/openspec_ui Ein Blick statt Datei-Hopping Du startest den Server, gibst d...

Erlang Code Loading

Um geänderte Module neu zu laden, kann man entweder die VM neu starten oder aber nur die Module neu laden, die sich geändert haben. Die erste Methode kennt bestimmt jeder, aber die zweite vielleicht nicht. Ich benutze diese zweite Methode in meinem Continuous Integration Prozess, indem ein Prozess die geänderten Sourcen aus SCM lädt, baut und dann die Nachricht an den sogenannten code_reloader schickt, damit dieser die geänderten Module neu laden soll. Wie funktioniert das im Detail? Zunächst einmal ermitteln wir alle Module, die z.Z. geladen sind. code:all_loaded() Diese Funktion gibt uns eine voll qualifizeirte Liste aller geladenen Module zurück. Wir könnten nun über die Liste iterieren und einfach alle Module neu laden, aber das wäre langweilig. Deswegen überprüfen wir zunächst, ob es sich bei der Datei um ein beam File handelt. Das ist für unsere späteren Schritte wichtig. Um das zu überprüfen schaun wir nach, ob die zu überprüfende Datei Metadaten besitzt. file:re...

Verteiltes Erlang

Bild
Systemarchitektur - IMac mit OSX - PS3 mit Yellow Dog Linux 6.2 - Erlang Vorbereitungen Die PS3 und der IMac müssen sich kennen. Das kann man sehr einfach mit einem ping Rechnernamen überprüfen. Sollte das nicht funktionieren, so fügt man die IP Addresse und den Hostnamen der jeweiligen /etc/hosts hinzu. Also, in die /etc/hosts des IMac fügt man die IP Addresse und den Hostnamen der PS3 hinzu und umgekehrt. Bespiel IMac:     192.168.2.34    ps3.localdomain.de Auf der PS3 und dem IMac muß Erlang installiert sein. Node Namen Damit wir eine Verbindung zwischen den beiden Erlang Instanzen herzustellen, starten wir die Erlang Nodes mit dem Parameter name (Langname des Rechners. Hier z.B. ps3.localdomain.de)     erl -name ps3.localdomain.de Den Namen der Node kann man in der Shell mit     node(). abfragen. Möchte man alle Nodes ermitteln, die mit einer Node verbunden sind, so kann man...

Beliebte Posts aus diesem Blog

Splitting an ML model and a web app across two BEAM nodes — the technical blueprint

Jido in Practice: Agents in Elixir as Composable Actions

A Foundation Model in the BEAM: On-Chain Anomalies with Google TimesFM in Elixir