Alright, a writeup.
First week back at work after holiday so things have slowed down again.
The solution I came up with for caching generated results of the FFI was NOT LIKED haha so that didn’t get in. Part of it was me misusing the build system, so that response was totally understandable (and fixable). The other part was that one of the devs disagreed with the entire premise that shipping the resulting
.so files was a good idea and thinks that all lisp devs (who want to use a project using a C library) should also have a working C compiler set up on their machine. This is just so far from my understanding that I barely known how to respond. I mean python and rust can both do this without the world coming apart, and package managers haven’t opened the gates to hell... anyway it didn’t go over well.
But luckily lisp has no concept of
internal so I can move my work to another package and carry on using it just fine. Should take me an hour to get that done so that will be fine.
Next I finished a project that had been lingering for ages. I wanted to what functions in lisp were pure and which weren’t. So I made a little emacs script that took a list of function names and opened the documentation page for that function. I was then prompted to press 'y' or 'n' to say whether it was true or not. Then I just had to go through 750ish names :p. It was grunt work but easy, so an hour or so later I had a first pass. I went through the results a couple of times and feel ok about my results.
The result is that now I can make a lisp package that is just like regular lisp but pure (within some measure of pure I dictate). I started an neglected this project ages back so it feels good to bring it nearer to a close.
I also have been reading up on promises and realising that the most popular formulation (from JS) really doesn’t feel good when messing with threads. You really need to be sure that the
then code for the promise is fine whatever thread it runs on (which is icky).
Clojure's approach is safe but I think they should have used a different name as it does not behave like JS promises at all. Promise is just a messed up term at this point
Next up I wanted to make a tooling layer to help with making games. Kind of like inspectors you find in other systems but hopefully stand-alone.
Currently I've been pondering threading. I want my tooling layer to run in a separate thread, this clearly means the inspector can't just look at live objects and display the values of their fields as the game thread might be writing to them. Blocking also seems like a good way to ruin performance so we need to look at some kind of copying.
This is interesting as we might not want to allocate fresh objects all the time as we put an extra load on the GC. So we are probably going to be looking at pre-allocating some instances/memory and copying values into that, and then hand this over to the tool thread in a safe way. First I'm going to knock up a safe but wasteful version so I can work out the api and then deep dive into a better solution,
Quick note, this may be overkill but I've never had a threading related project without a deadline, this makes this a really good excuse to learn more about the topic.
That's all for now,