First screencast on my new project: https://github.com/akkartik/teliva https://archive.org/details/akkartik-2021-11-14 It's been great fun to work with a language implementation as small and elegant as Lua's. The editing environment benefits from runtime information in deciding how to present things to the programmer, and rendering a single function at a time allows me to use a simple, low-featured editor -- which in turn helps keep the implementation small and elegant.

This is really interesting! What happens if you edit something in the data row? What does that look like?

It's just a definition like any other! Usually much shorter since it's just a declaration for a global variable.

Really cool. I like the simplicity, and discoverability levels. You choose edit, you see data and functions (and not files 👌 ) which you can view and modify.

@ogadaki I've been thinking about your comment for the past day. I don't have enough experience with REPLs and Slime-like UIs, so hadn't really explored ideas in the direction of hot restarts. Inspecting runtime state seems definitely doable, but currently the whole process literally restarts (

exec()

) when you switch back to running the app. One question that occurs to me is how valuable the ability to modify runtime state is when the unit of sharing is static code. A Smalltalk-like image is a whole other beast, but with static code it's easy to end up in a state where there are modifications to RAM that don't get persisted to version control. On the other hand, I'm reminded of an old thread with @Jimmy Miller and @Jack Rusher in particular about how they iteratively and interactively develop with Clojure, and I'm very open to ideas from anyone for things to try out.

One question that occurs to me is how valuable the ability to modify runtime state is when the unit of sharing is static code.

Just to quote (emphasis are mine) the first quote in the teliva repo: “Enable all people to modify the software they use in the course of using it.” I'm a user, the app is running, it has a state, and I see some behavior that I would like to change now. I can hit Ctrl-e, make the change, come back to running it with the new behavior with the previous state. Like a chat app, where a discussion is ongoing, but I want to change the display, like adding a view of all users names, and I don't want to loose previous messages when I'm back. Or for live coding. But when I close the app, I'm OK if the state is not persisted. It can be an interesting feature, but another one.

I'm definitely going to be looking for ways to implement hot-patching as I continue to understand the Lua implementation. The point of brutalism is to reduce costs. Here the set of features provided and their complexity. I'm not sure Lua is a good substrate for transparently allowing hot-patching. That might require a Smalltalk. So far my ambition has been just to allow apps to be written in a crash-only manner. For example, build the chat app to frequently save data to disk. When it starts, by default look for data from the previous run to reload. Starting afresh becomes an easy special case there.

Neat project! I like the data/function overview and the general concept. I’ve done live coding performances in Lua before… curious what you think the drawbacks are of hot-patching.

Saving data from the app, is a kind of "VM save". But this is up to the user to define what it means to save the app state. Which is great because: 1. reduce complexity on the teliva side (keep it "brutalist") 2. this "power" is in the user's hand. Maybe Lua already provides some serialization tools?

@Charlie Roberts Mostly just that I don't know how to do it, and how much effort is involved. If you have experience using hot-patching in Lua I'm very interested to pick your brain! Do you happen to have a repo for an old live-coding session lying around, for example?

Sorry I wasn't clear, I was talking about your idea: "build the chat app to frequently save data to disk. When it starts, by default look for data from the previous run to reload. Starting afresh becomes an easy special case there." It is a kind of poor man "VM save" and is up to the user to decide what it really means. And as with this kind of experiment, the idea is to empower the user, it might good enough while keeping things simpler for teliva.

Oh, so no changes needed?! I fear I'm having trouble hearing what you're suggesting because my brain is too full of my own ideas. To answer one previous question, yes I think Lua has good support for serializing arbitrary data. I might package a JSON library by default or something like that.

Yes, it would be nice to provide a way to make it easy for the app dev/user to persist her app state. And maybe with automatic save and restore around any code edit?

@Kartik Agaram I was just thinking with `loadstring`… you lose local scope, but if your data is stored globally I don’t think that would matter. But here’s a paper on a Lua-based creative coding system I was involved with many years ago that called out to Clang, compiled C code (based on data representations provided by the Lua app), and linked the resulting JIT-compiled function back into the running Lua application: https://www.researchgate.net/publication/242725288_LuaAV_Extensibility_and_Heterogeneity_for_Audiovisual_Computing It worked surprisingly well tbh… although I wasn’t involved with that part and it always seemed like deep dark magic to me 🙂

In spite of my concerns that what is saved to disk may diverge from the state when building the program, I'm starting to realize that constantly rebooting the environment is a non-starter when the reboot includes edit state. Currently if I make a mistake when editing one function, running the program causes the whole environment to forget which function I was editing. So I end up back at the top-level hierarchy view. So the current architecture has some fundamental problems. Rebooting programs from scratch only works in Unix because the editor is in a separate process that isn't rebooted.