fsmunoz
Joined 11 years ago
Karma
78
Submissions
28
Member since
Dec 28
Recent submissions
Comment · 4 months ago
Shows one-file examples of using Datastar for reactive web development in Common Lisp. Covers the basics but also related topics like CQRS an fat morphing.
Comment · 4 months ago
As a Lem enthusiast and a big fan of Tarkovsky’s Solaris, this is hypnotising - thank you!
What’s the stack behind this?
Comment · 4 months ago
This is one of the demos included in the Datastar SDK for Common Lisp I've been working on. The ideas behind it are also present in the interactive guide here https://lambda-combine.net/hyper-guide - essentially a complement to the Datastar guide in Common Lisp.
This demo specifically shows Datastar being used, with multiple POST commands and one single GET stream - CQRS, as per the Datastar Tao - plus a persistent store using BKNR datastore. The map is based on SVG, which uses morph ("fat" or perhaps with a slightly above average BMI) for updates.
The work around this led me to places I didn't necessarily expect, but a side-effect is that I made a Brotli library for Common Lisp (https://lambda-combine.net/cl-brotli), and the SSE library has support for something I added to Woo (perhaps poorly, but I'll follow that up upstream) to support user channels, and thus allow the event pool to be used for CQRS; in short, making it possible to use Clack+Woo with notifications without blocking the event loop.
This is all WIP in the sense that needs to be tested more. If it breaks, I'll fix it, or do my best at it.
Hope you find it interesting though. I'm out driving down to the Algarve for holidays in hours, so apologies if any possible questions are left unanswered more than they should, I wanted to get this out there since I was in a perpetual improvement loop.
Comment · 5 months ago
An offshoot of my work in SSE and Datastar, and in anticipation of a new rmuch expanded release of the SDK. Brotli brings very good compression rates for the SSE use-case. Comes with a Hunchentoot example (but also works with Clack).
Comment · 10 months ago
An update: I've spent some time taking a much deeper look, and while I can't guarantee it's perfect, I added a different approach for Clack+Woo, documented here: https://github.com/fsmunoz/datastar-cl/blob/main/SSE-AND-WOO...
In short: I've replace the Common Lisp loop (that works for Hunchentoot since it opens threads, but doesn't for Woo since it blocks) with a deeper integration into the event loop:
> And that was the main change: looking at the innards of it, there are some features available, like woo.ev:evloop. This was not enough, and access to the libev timer was also needed. After some work with lev and CFFI, the SDK now implements a Node.js-style approach using libev timers via woo.ev:evloop and the lev CFFI bindings (check woo-async.lisp).
This is likely (almost surely) not perfect or even ideal, but it does seem to work, and I've been testing the demo app with 1 worker and multiple clients.
Comment · 10 months ago
The CL-SPICE library I used, that wraps the SPICE C library through CFFI, doesn't cover the type of SPICE kernel that I wanted to use for the Comms module. I could try and add it, but it could be more involved than what I expected and put the thing on hold.
So I used the FORTRAN SDK for SPICE, since I had used it before, and it's reasonably small and easy. The alternative coud be using the C SDK, but I went with FORTRAN since I already had most of the code from a previous project.
Comment · 10 months ago
Thanks! Yes, I think I will add the Horizons JPL demo there, it's essentially a 20 line file.
Comment · 10 months ago
I haven't tried Wookie, since adding Clack+Woo was already a substantial change. Reading https://fukamachi.hashnode.dev/woo-a-high-performance-common... , where it compares with Wookie, I'm not sure if it would make a difference: it might be wrong, but "it says:
> Of course, this architecture also has its drawbacks as it works in a single thread, which means only one process can be executed at a time. When a response is being sent to one client, it is not possible to read another client's request.
... which for SSE seems to be similar to what the issue is with Woo. I wrote a bit more on it in https://github.com/fsmunoz/datastar-cl/blob/main/SSE-WOO-LIM... , and it can be more of a "me" problem than anything else, but to keep a SSE stream open, it doesn't play well with async models. That's why I added a with-sse-response macro that, unlike with-sse-connection, sends events without keeping the connection open.