Lmst

I'm on a bit of a roll lately, and have released #iocaine version 2.4.0 just a few moments ago.

This does not bring that many significant changes as 2.3.0 did, but it does introduce #Lua and #Fennel as languages you can script its decision making with, on top of #Roto, which was introduced in 2.2.0.

While these languages run slower than Roto, they're still very fast, and are not going to be a bottleneck - they do provide a more familiar language to write the decision making in!

Oh, and metrics can now be persisted across restarts.

And because I give funny names to my structs, the one dealing with #Fennel is called ElegantWeapons.

After that, I'll try to figure something about how to support #Fennel better, natively. The current idea is to have it exposed as another scripting language, built as a wrapper around the Lua engine, with some additional setup at init time:

Load the fennel compiler from somewhere
Update fennel.path
Run fennel.install()

I could embed the fennel compiler, it is small enough, and releases aren't frequent. So that's an option. I don't want to pull it into the sources, though, so I'd need a way to do grab it during build or something. That's a bit problematic, however.

So the next best thing I could come up with is:

[server.request-handler]
path = "/path/to/some/fennel/code"
language = fennel
options = {
  compiler = "/path/to/fennel.lua"
}

I think I tackled all the weird corner cases and patterns and whatnot. Driving iocaine with Lua feels fine. Driving it through #Fennel feels even better.

Once I get to write documentation, there will be Fennel examples too.

Yup, init works fine too. Neat. So one has to be a little bit careful when writing #Fennel targeted at #iocaine: gotta make sure that the decide function ends up in global scope.

Either by using return decide (or putting the decide function last in the fennel source) and then decide = require("main.lua") in the script given to iocaine, or (tset _G "decide" decide), in which case require("main.lua") will do the right thing.

So, yay, #Fennel code works fine, with a bit of care! But it would be nicer if I could have the compiler run at init time. So I wonder: what would it take to provide fake debug and assert modules? And how badly would I shoot myself in the foot?

Unfortunately, there are gotchas there, too.

(fn decide [request]
  Outcome.not_for_us)

This #fennel code compiles to the following #lua:

local function decide(request)
  return Outcome.not_for_us
end
return decide

The problem here is that I'm not require-ing this file. I maybe should. Without require, that return makes little sense, and the decide function won't be found in the global scope, so...

Error: error converting Lua nil to function

Which makes perfect sense. Except the error message is bad, and needs to be improved.

Today's adventures begin with trying to make #iocaine play well with #Fennel. There's work to be done on this front...

For starters, I don't think I will be able to support running the Fennel compiler as part of the init process. It seems to require debug and assert, which I'm not sure I want to make available to the Lua runtime in iocaine.

debug requires mlua.unsafe_new(), which in turn requires an unsafe block, and I'm not comfortable with that. Not even sure how I can make assert available, mlua doesn't seem to provide that as part of stdlib.

So, next best thing: compiling #Fennel to #Lua ahead of time!

And of course, if I can embed #Lua in iocaine, and it runs at acceptable performance... that means I can use #Fennel too.

Now that would be grand. The first time I thought about adding scripting to iocaine, I imagined a Lisp.

the last missing piece for the new #fennel flow was to tie in patches attached to tickets into the CI pipeline, and with some help from @carlozancanaro I was able to get that working without too much fuss!

a patch attached to this ticket: https://dev.fennel-lang.org/ticket/38

resulted in this build: https://builds.sr.ht/~technomancy/job/1517781

all the code is in a comment on the ticket (32 lines of Python)

(which randomly happened to fail on the fuzzer due to amazingly bad luck)