Fork me on GitHub

I'd like to announce the availability of a new CLJC statecharts library (similar to clj-statecharts). I would have loved to have contributed to the expansion of the existing one, but for various reasons it was not going to meet my needs. This version supports history (deep and shallow), has protocols for defining all of the significant subsystems from the code execution model (e.g. you could use CLJC functions, SCI interpretation, or even Javascript eval), the state-local data model (e.g. could use a durable database), event queue, and even the algorithm semantics. It is structured so that it can support the invoke concept from SCXML to run/cancel external processes in an abstract way while being able to pass events between the running statechart and that external statechart/service (that still needs further refinement). The built-in processor follows the SCXML (minus the XML requirement 😄) standard (in structure and semantics as far as they are defined in, and is intended to be structured for use in a distributed and durable environment (e.g. able to save/load a session, use a durable event queue, etc.) All that said, it does come with predefined and simple elements for all of those components, so it is easy to get started with, especially if you just wanted it for short-term in-memory programming. I will be using it in a distributed durable environment in production in short order, so the API is pretty stable, and any bugs will get worked out quickly.

👍 19
👀 6
bellissimo 1

@U0CKQ19AQ that’s awesome to see! Do you have any plans on a visualizer for this? I’ve been using XState in a CLJS codebase with good success and mostly picked it over clj-statecharts due to the visualizer feature which I just find very useful and well executed. The other day I even visualized a running statechart inside a node process, which was easier than expected.


I saw that as well and would love it, but it is very very low on my priority list. I think a JSON <-> Xstate converter would be easier, and then you could just use their tools 😄

👍 2

I'm much more interested in some full stack things, like running charts over a long time (persisted in a database) and having charts that can cross-communicate full-stack, etc. Being able to version and persist the chart definitions themselves is also interesting to me as a software evolution path, which is why I abstracted away the execution model, so you are not stuck with embedded code on a machine def that becomes non-portable. Imagine a machine that can move from VM to VM (e.g. JVM <-> browser <-> node, etc). All sorts of possibilities, but mine are mainly focused around building stuff that has a distributed, cross-communication, long-lived aspect to it (payment/subscription system for a business is where I'm using it first).


But I also see some really cool ways to build complete Fulcro apps with it, where the abstracted data model and cross-env messaging could integrate very well with FUlcro's full-stack story.

Lucy Wang04:12:21

Glad to see another statecharts library! During the last two years I find statecharts more and more convenient in all kinds of frontend & backend projects!

Shantanu Kumar10:12:49

Cambium has a new release including Logback security-fix w.r.t. LOGBACK-1591:

👍 7
Lukas Domagala12:12:49

that looks nice! is it ok if I ask what the conceptual difference would be between this and using mulog with an slf4j adapter?

Shantanu Kumar13:12:10

@U02EMBDU2JU AFAIK (in my very limited reading) mulog is mainly for observability and metrics whereas Cambium is for SLF4j based data-oriented logging. Cambium has also been used to log metrics to ELK stacks though. As per there doesn't appear to be a mulog SLF4j adapter. For more discussion please feel free to ping in the #cambium channel.


Released symspell-clj 0.2.4, a spell checker library for Clojure. It is based on a Java port of SymSpell spell checker, a fast spell checker using pre-calculated typos.

🎉 7

Earlier this week we released Clerk io.github.nextjournal/clerk {:mvn/version "0.4.305"}, the biggest update since it’s initial release. 🔗 Highlights include: • Ⓜ️⬇️ Markdown support for prose-heavy docs • 👁️ New viewer api with and open transform & fetching behavior to allow fetching anything from the JVM, see🪄 clerk-eval to call back into the JVM from viewers, see🙈 controlling code cell visibility, see 📺 Also, my was released yesterday. Along with it, we’ve created a repo of I recommend checking out. Spreading the word is very much appreciated. 🙌 🙏

❤️ 8
🎉 14
👏 8

Just a sense-check - we could use clerk to compose in emacs, check source into git, and then have clerk render pages within our own Ring server, inside our own platform, right? As an internal documentation system?


checking into git very much. Regarding the rendering, do you even need a server? is just served from a github page but you can serve it from anything, also a S3 or Google Cloud Bucket. Or even have a single html file with everything in it like on


thanks @U5H74UNSF - mainly it's about access control. could we put it in our app where we have all that figured out already? it's looking like 'yes'! 🙂


clerk + ns = live repl env -> output html with js = 'reader'. the output has a way to update when the live repl env tells it to. right?


this is insanely cool btw


like my brain is struggling to grasp just how game-changing this is


good thing i've got 3 weeks of downtime to play in 😅


yep, also works in both directions


so if you’d like to serve it inside your app you could: have a set of notebooks that you turn into edn files, via


theoretically also possible to emit the html directly rather than dumping on disk and then serving that disk file via e.g. io/resource right


bril, that gives me what i need. thanks Martin!


great. Also have some ideas around supporting the code browser / living docs use case better


plugging this in behind our access control and into our datomic database (which is has data going back to 2013) is going to be so fun


live 'ADRs', data migration analysis, so much potential


i'll be sure to take notes about any frictions i encounter!

🙏 1