One consequence/challenge of working with lots of forks: you develop a heatmap of the areas of your code most likely to have merge conflicts. I feel a very tangible pain now any time I have to touch something within 3 lines of the place where I set the window title. Every fork has a different window title, and the idiosyncracies of text-based diff guarantee every fork will flag a spurious conflict.

Hmm, perhaps I should start surrounding such lines with 3 empty lines..

permalink

Ooh, I found a nice meaty Mastodon thread to visualize using my app.

Found a bug in the process.

permalink

Mastodon thread visualizer in LÖVE

It took me a while to get to this, but here it is.

The layout is extremely jank, but it makes up for it somewhat using keyboard navigation. And you can click on any node to copy its URL.

LÖVE doesn't yet support https. The next version should, but I finally lost patience and temporarily put together a Lua+luasec crawler that invokes LÖVE.

Like my last few apps, this one can be edited live without restarting it.

---

Hmm, the second point in the alt-text for the second image requires a correction.

> The current implementation definitely has a bug relative to my intent..

The bug isn't in the implementation but in the algorithm itself. It violates the final constraint I'd set for it.

> cousins never overlap columns

Hmm, time to read the literature.

---

Ah, it only took a slight tweak. This looks much better.

permalink

I just had a fun hour with the kids and this program:

iga: texture synthesis

Based on the Wave Function Collapse algorithm.

We tried out different tiles for a while.

After I got sick of typing out the filenames, I added the ability to drop files on the window.

Then we noticed that some of the tiles are more boring. I hardcoded the starting point near the bottom rather than the top, and that helped.

Finally I had it take the starting point from the place where you drop the file on the window.

permalink

Dealing with failing tests when all you have is a map for code

Mechanisms:

• Highlight tests in green.
• Run all tests on any change.
• Highlight failing test cases in red.
• Turn edges of vision red when there's any failures, just in case failing tests are out of view.
• Hotkey to zoom out over all of current view.
• Same hotkey to restore viewport settings.
• Click anywhere to zoom in.

Check it out in my live-editing programming environment.

(What is a "freewheeling" app?)

permalink

Inspired by a recent blog post by Laurence Tratt, I spent some time kicking the wheels on my code map based programming environment by building a BF interpreter.

Next up: reproducing in Lua Laurence's results regarding the compiler-interpreter spectrum.

Here's the "load screen" for my environment, showing a visual overview of the code I've written.

permalink

A map for code

In this video, I start up in quick succession:

• a simple test app
• the 'driver' programming environment showing the map for the app's code
• the 'meta-driver' programming environment showing the map for the driver's code

On initial load the driver (glitchily) zooms out over the whole codebase before zooming back in to the previous session.

Check it out.

(Inspiration: early side-scrolling videogames that would often start a new level by panning across all of it.)

permalink

This is pretty cool, a blog arranged in a Hilbert curve on an infinite 2D grid.

permalink

I've been live-coding my Lua-based markup language luaML using a driver program. Now I've pulled luaML into the driver program so that I can open multiple buffers, move them around, zoom in, zoom out, etc.

(And yes, you can live-program the driver. Not quite using itself, but by copying it into a "meta driver" and making a handful of edits.)

Compare v1 and v2 of the driver.

permalink

luaML on an infinite surface

You can draw various graphics and edit text in arbitrary grid layouts, all on a pannable, zoomable infinite surface.

Repo

permalink