Clojurians Log v2

Har gjort nøyaktig det allerede.

Deler snart.

Gøy! Gleder meg.

Prøver to forskjellige tilnærminger. For Eido er det et frittstående Zig bibliotek som Clojure prater med.

Den andre er Zig i Clojure/REPL.

Begge bruker Project Panama.

Det jeg fortsatt ikke har funnet ut av helt er hvordan man kan pakke et Zig bibliotek i/sammen med et Clojure bibliotek, slik at det blir helt selvstendig. Enn så lenge må man installere Zig separat og manuelt slik at det er på path. Årsaken er et Zig med in-line C og Assembly må kompileres for hver enkelt plattform. Det er OK for Eido, hvor Zig-komponenten er ekstern, men er litt lame for det andre eksperimentet hvor Zig «er en del av» Clojure biblioteket på en måte. Tror løsningen er at Clojure biblioteket da må bruke Project Panama for å finne ut hvilken arkitektur brukeren kjører på, for deretter å laste ned en pre-compiled binary for den plattformen. Men det føles ikke spesielt pent heller. Det er den biten jeg prøver å finne ut av nå. Men selve developer experience i REPL er mer eller mindre på plass allerede.

jeg skjønte ikke helt forskjellen på de to; er 2 at du kan kompilere Zig-kode fra Clojure-prosessen?

Ja, du trenger forskjellige binaries for hver plattform i Jar-en

Jeg begynte å lese på det for lenge siden, men kom ikke i mål med noe fornuftig på den tiden jeg satte av.

Ja, jeg er inne på samme spor.

Det eneste som er litt kjipt er at biblioteket blir ganske stort fordi det bundler Zig for alle plattformer. Et alternativ er smart logikk som laster ned korrekt binary når en henter/installerer Clojure biblioteket. Men da har man brått en avhengighet på nettverk som suger litt.

Et annet alternativ er å ha en JAR per plattform som bundler korrekt Zig binary. Men det er også litt stygt synes jeg.

jeg skjønte ikke helt forskjellen på de to; er 2 at du kan kompilere Zig-kode fra Clojure-prosessen?Per nå sheller den ut til zig Men, ja, tanken er å gjøre den in-process etter hvert. Har ikke funnet ut av det enda.

Den nye utgaven av "motoren" til Eido er helt frakoblet Clojure. MEN! Den "prater" EDN. Så det er på en måte et EDN-basert språk for å generere grafikk. Så har den en custom 2D/3D grafikkmotor skrevet i ren Zig, som er lynrask og mer fleksibel enn Java2D uten avhengigheter til f.eks. OpenGL, WebGPU, Vulkan, etc.

Clojure er jo den beste måten å generere EDN på. Så "Clojure bindings for Eido" er bare EDN/alminnelige Clojure datastrukturer.

Det betyr at den også funker med Babashka, ClojureScript, etc.

> Et annet alternativ er å ha en JAR per plattform som bundler korrekt Zig binary. Men det er også litt stygt synes jeg. (edited) Jaaa, det tror jeg er riktig tilnærming. En plattform-uavhengig Eido-jar som trenger noe plattformavhengig.

Japp! Pluss at det allerede finnes mange EDN libs for andre språk.

Clojure er jo den beste måten å generere EDN på. Så "Clojure bindings for Eido" er bare EDN/alminnelige Clojure datastrukturer. (edited)Hvis du skal shelle ut eller sende meldinger på en socket eller noe, må du serialisere EDN til tekst. Hvis det er en stor EDN, blir det en kostnad.

Så Clojure er "bare" én (den beste 🙂) "front-enden."

Per nå gjør den re-render av hele datastrukturen hver gang. Litt som Replicant.

Men tanken er å kunne gjøre smartere delta greier hvis det blir nødvendig.

Jeg har også laget en native GUI app prototype på toppen.

Så man har noe lignende Adobe Illustrator.

uavhengig avveining — på clojure-siden kan du oppdatere datastrukturen raskere (speedupen fra persistent data structures over copy on write). Hovedpoenget i ting som tech.ml.dataset er at den raske implementasjonen under panseret ikke kopierer. Chris Nuernberger omtaler det som zero copy. Så det er liksom en stige, 1. Gå via tekst-serialisering 2. Sikre byte-likhet, så du kan gjøre en batch byte/copy uten EDN 3. zero copy

Men veldig kult! Ikke meningen å komme å være kverulant. Jeg vil gjerne ha bedre tools for GUI i Clojure, og noe Zig-basert er kjempespennende. Masse jeg har lyst til å sette meg inn i selv her!

Alle innspill tar jeg med stor takk og glede! Det er disse chattene med deg som har inspirert/fått meg til å tenkte på (eller ikke klare å slutte å tenkte på 🙂) disse tingene i utgangspunktet.

Jeg blir inspirert av å se hva du får til selv! Du har faktisk gjort det ekte 😊

Vel, det er mye AI i bildet her altså. Jeg har skrevet svært lite kode for hånd.

Jeg har brukt mye tid på å tenke på og skrive ned brukeropplevelsen og hvordan det kunne sett ut rent konseptuelt.

Også har jeg brukt mye tid på å lære meg hvordan jeg kan bruke AI noenlunde effektivt, lage "skill systemer," etc.

Har også brukt ganske mye tid på å sette meg inn i Zig-økosystemet for å forstå mulighetsrommet og begrensningene, og sammenligne med Hare, C3, og Odin.

Jeg skammer meg for min AI-bruk hver gang jeg ser @christian767 og andre flinke folk sine reaksjoner og posts på LinkedIn når jeg spiser frokost, hehe. Men heldigvis har jeg mye trening i å håndtere indre konflikt og skam fra min tid som aspirerende pastor i pinsemenigheten, samt fra reisen ut av det miljøet 😂

Men heldigvis har jeg mye trening i å håndtere indre konflikt og skam fra min tid som aspirerende pastor i pinsemenigheten 😂

Jeg synes det er helt ålreit å bruke AI til sånt. Hvis jeg skulle lært meg C i dag, hadde jeg brukt en masse AI. rant fra i går om akkurat det: https://2.teod.eu/d/16/neophiliacs-withered-technology-literature-study Når vi argumenterer synes jeg vi kan snakke om hva vi konkret liker eller misliker. Et konkret argument som har vært på banen er at teorien i koden svinner hen. Teorien i koden kan svinne hen med menneskeskrevet kode, og den kan bevares etter AI-involvering, men det krever innsats. For deg er jo alt dette avveining og valg. Du lærer deg en haug med ting over tid, og etter hvert som du får brukt greiene dine, vet du tydeligere hva du vil ha ut av lavnivåkoden.

Jeg har gjort https://github.com/leifericf/clj-zig, hvis du vil sjekke det ut. @teodorlu 👀

Eido engine er ikke public enda.

Jeg klarte å fucke' opp Clojars releasen min da. Helt selv, uten AI 😛 Prøver å fikse det nå.

Første gang jeg tester Clojars.

Spennende! Forstår jeg det rett i at å evaluere (defnz f [,,,] ,,,) da gjør hele zig-kompileringen, og gir deg tilbake en vanlig clojure-var du kan kalle?

Jepp, basically.

Støtter disse (ref. https://github.com/leifericf/clj-zig/blob/main/docs/02-interface-design.md):

defn       -> defnz
def        -> defz
defrecord  -> defrecordz
deftype    -> deftypez
defenum    -> defenumz

Holder på med "moduler" nå. Det er ikke støttet enda. Men du kan allerede bruke vanlige .zig filer, og de funker med Clojure namespaces. Prøver å finne en løsning på "moduler" som ikke leder til cache misses, slik at det fortsatt går raskt i REPL.

Kult, det er grensesnittet jeg ville ønsket å bruke!

Er "modul" det zig omtaler som innholdet i en fil? Tenker du at et Clojure-namespace skal bli en modul? Eller skal man sette sammen moduler selv?

Hvis du vil se på Clojure-navnerom som moduler, kan det være nyttig å prøvekjøre Clerk og Clay, de gjør litt det.

Kommer tilbake etter leggetid med guttungen og tur med hunden hvis jeg fortsatt er våken 😅

Men kort fortalt er det én fil = ett navnerom.

En modul er noe man kan importere ved navn.

Moduler har vanligvis en rotfil. Den rotfila kan importere flere andre filer/navnerom (som er mer eller mindre synonymer i denne konteksten).

Og en fil er egentlig bare en struct hvor de ytre klammene er implisitte.

Nå funker Eido med den nye motoren da 🙂

Den nye Zig-motoren er nå 2,6x raskere enn den forrige Clojure/Java 2D-motoren, og det kun med én CPU-kjerne. Java 2D er ikke multi-threaded, men det er neste mål for Zig-motoren, som har working title "Clojo."

Når jeg (kanskje) introduserer GPU-en senere, vil den kunne bli enda raskere. Per nå er Clojo kun CPU. Det er egentlig litt nice, fordi da er den 100% deterministisk og koden er betydelig enklere å forholde seg til. Jeg er ikke helt sikker på om jeg vil introdusere GPU-akselerasjon hvis den blir "rask nok" på CPU. Men det er betydelig enklere i Zig. Tanken var å gå veien via MLIR/LLVM, på samme måte som https://mojolang.org gjør (derav tilnavnet Clojo). Hele greia var inspirert av Mojo/MLIR opprinnelig, men med Zig kan det hende man kan side-steppe hele den pipen der og gjøre alt fra bunnen av selv.

Det første eksperimentet jeg gjorde, før jeg kikket på Zig, var å kompilere Clojure direkte til https://mlir.llvm.org, på samme måte som Mojo (jeg har mailet litt frem og tilbake med Chris Lattner om dette). Men det føltes ikke helt riktig, og det ble en voldsomt komplisert greie. Derav Zig.

For øvrig bruker Eido nå også clj-zig 🙂

Så vurderer jeg å embedde mino i Clojo (hvilket er veldig enkelt fordi Zig kan bruke C-biblioteker direkte), slik at en kan sende Clojure-kode som data inn i selve motoren for dynamiske sanntidsgreier. Men jeg er usikker på om jeg vil gå den veien, fordi da blir Clojo mindre dataorientert, mindre generisk og mindre tilgjengelig for andre konsumenter som ikke kan Clojure.

Så alle prosjektene mine ser ut til å møtes.

Holder også på med et kommersielt produkt ved siden av. Men det holder jeg litt hemmelig enn så lenge 🙂 Det er noe helt annet, men som også bruker Clojure, Zig og clj-zig.

Multi-threaded hjalp litt iaf. Tallene er millisekunder.

Men har ikke nådd gulvet enda. Det er fortsatt mange gains å hente.