Stack: • Lua (12kLoC of C) • LÖVE (5MB download; depends on a minimal graphics stack) • LoveFrames (25kLoC of Lua for a GUI toolkit) • a text editor (5kLoC of Lua) • 500 LoC of live programming infrastructure Properties of this stack: • minimal dependencies • cross-platform; runs on Windows • easy for anyone to modify •

Ok, I may have under-estimated how much work Potluck will be. To build Potluck I need the ability to render tables, and to render tables that I can type into I really need a DOM. Prev-gen GUI toolkits like LoveFrames won't cut it; I need the ability to dynamically adjust dimensions as contents change. Hence this detour. The good news: I don't need much. The format is just literal Lua table syntax. Each node (div) contains either text, a row of nodes, or a column of nodes. Other supported attributes:

fg

,

bg

colors and

margin

that acts like

margin-top

or

margin-left

depending on whether the parent has rows or columns.

On the other hand, when archiving data I definitely do want to follow industry standards.So it's not a question of choosing the better option, but of supporting both.

Box model from scratch #3. I think I'm happy with this one. You can draw various graphics and edit text in arbitrary grid layouts, all on a pannable, zoomable infinite surface. I finally understand how to cleanly update the viewport based on edits within a pane.

The driver program I use to live-edit my Lua+LÖVE apps now also uses the new box model so I can open multiple buffers, move them around, zoom, etc. The stack currently weighs in at: • Text editor (with thorough tests): 5kLoC • Live-programming infrastructure: 500LoC • LuaML box model and driver app: 1kLoC

I've been pushing hard lately on the metaphor of a map for code. In this brief video you see in succession: • a simple test app • the 'driver' programming environment showing the map for the app • the 'meta-driver' programming environment showing the map for the driver When the driver loads it zooms out over the whole codebase before zooming back in to wherever I left off. (For this initial animation I'm inspired by early side-scrolling videogames that would often start a new level by panning across all of it. Since I'm not a game programmer, the animation is currently glitchy af.)

This was surprisingly hard: making the animation smoother by drawing to a texture just once. I learned two things: • Just how slow LÖVE is. On my 1.4GHz (/core) laptop (running Linux) an empty app (just initializing graphics every frame) runs at barely 60fps (15ms/frame). It's very easy to overflow even 30fps. • I don't know if my standards are too high, but the way LÖVE does texture mapping is a little weird: https://codeberg.org/akkartik/driver.love/commit/207ebfae36902cb18a1d2fcf5e31e6301ad5a2e0

I just tried it and yes, the empty app went from 15ms/frame to 0.005ms/frame without vsync! It's a little different from your link in that my CPU doesn't get pegged with vsync. But it does introduce a non-busy wait. Unfortunately this doesn't affect my app's initial animation. If I bump back to before my recent texture-mapping changes and try it with/without vsync, I see no perceptible difference. I might have been able to find an alternative way to speed up the animation, though, if I'd disabled vsync.. I'm going to disable vsync going forward. It seems clear that any drawback stemming from this decision is going to be very obvious, so no reason not to try it.