4-minute video update on my "Emacs for visualizing LÖVE apps": it no longer looks very much like Emacs at all. I think all it shares with Emacs is a flat namespace of handler functions that you can compose to create windows with different experiences around shared data.
As I was trying to build a debugger (well, a frontend to lldb right now) for my language, in my language (beagle), I was getting a weird bug I couldn't figure out. So I decided to build a little compiler explorer tool for it. The left is the code, the middle is my (already register allocated) IR, and the right is the machine code. (Don't look too close, there are some bugs in how I print the machine code like and doesn't apply the shift).
The UI is incredibly ugly, because hopefully this is the last UI I need to build for my language that isn't built in the language itself. Using the UI I was able to figure out the bug. It turns out, if I had a compilation cycle with code > 3 pages of memory, I wasn't doing the accounting properly and writing the over existing code. Ironically, the way I built this tool meant, I saw my code was right, but the code I was stepping into the debugger was wrong. So the tool showed me the bug by the absence of the bug...
Now I'm continuing on to building the debugger in itself. Having a real application is helping me realize features I need and forcing me to think about what I want my language to feel like to program.
What does the red mean? Is it showing you which IR and machine code instructions correspond to the highlighted code in green?
Silly screenshot excluded my mouse. I am hovering over the green highlighted token there. And the red is IR and machine code that is produced for that part of the ast.
Compiler explorer is quite handy. I’ve extended it in the past as well for similar IR inspection. 🙂
I added the missing ability to upload File Attachments into the HTML bundle thing (this also adds the ability to add local files to Observable notebooks as its all userspace).
I am somewhat at a fork in the road about what to do about state. I prototype a cell mutating itself, and now I also have the ability to programmatically write binary blobs into itself. IndexDB is not so relevant here because every time you fork, you lose that kind of browser state as the domain switches).
So should I use cells to store state? they are cool because they are reactive and programmable, or do I use files to store state? Files are a bit more classic, maybe a bit easier to eject and upload into a different notebook. I think I lean towards files as the long term data store, seems like it would be easier to interop with other systems.
+1 to files as storage, easier to reason about statefulness in a pipeline of files than a dataflow of cells
A program on my phone with a custom debug UI.
Pretty hilarious. After spending a week creating spaces for custom debug UIs, I realize a different fork can already do all that. On my phone. By repurposing a script I wrote a year ago.
I did deliberately design screens in Lua Carousel to support sharing and exchanging data. But I didn't appreciate all the benefits.
I'm tinkering on a little sand experiment with @Elliot. Without dipping too far into spoilers, you have a small selection of tools you can use to fill the screen with grains of sand and then move them around, with brushes (of a sort) that each have a bit of logic (eg: scatter the sand randomly, push the sand downwards, merge sand grains together). What's fun about these brushes (of a sort) is that they apply some behaviour that feels like a computation. So you sort of brush your computation over some data (sand).
One possibility I've been mulling, that I'd love to hear some ideas for, is a brush that does cellular automata. The brush might use some global grid (discrete) or sense of proximity (continuous), and apply some CA-esq rules depending on the density of the sand. Then you'd just brush that computation onto the sand to advance the state of the CA. Maybe each brush stroke advances the CA one step wherever you apply it, or maybe the CA runs continuously but only where you're brushing. The thing I'm presently brainstorming is… how might one specify the CA-esq rules just using sand and brushes?
📝 Elliot (@vez@mathstodon.xyz)
Attached: 1 image
sand letters
I can't immediately think of anything. I assume the obvious approach is one brush per rule set, but yeah in that case how might you create a new brush? 🤔
Yeah exactly. Or parameterize a brush, where the relevant parameter here is, like, a graphical rewrite rule.
I like this space of materializing the presence or action of CA execution as paint. Like you say – imagining that each “coat” of paint you lay down advances the CA one step, or imagining that the presence of “CA paint” persistently makes a CA run in a given place – but if you can push the paint around it will make the CA run in different places? Or even continuous gradients – the CA runs “more” in some places than others? (Does that mean faster? Or that behavior is interpolated between being stationary and being CA-driven?)
Yes Josh, that's precisely the good shit I came here for! Full size!
I've heard people say "rules should be defined in the same place they're executed", but I don't think I've seen anyone do it yet. Like, Lu Wilson talked about something this with respect to CellPond, for insty. Rather than paddles down the left of the screen, you'd… uh… not have them there.
I'm not sure about CA rules, but simple replacement rules seem do-able, perhaps. Maybe a pair of brushes that let you capture a "before" and "after" that recognize some changing qualities of the captured sand, and a brush to apply that change.
I wonder if there's something about little grains of sand that might make this all more feasible. Sand is basically 1-bit graphics without the pixel grid. It's like the second most constrained kind of graphics possible, surely.
Maybe some Viewpoint vibes here.
If the paint controls time, then you could keep your “before” and “after” swatches in a safe (or unsafe) corner as a persistent rule set, AgentSheets-style.
(I haven’t used CellPond :face_with_peeking_eye:, so I don’t know if that’s what paddles do.)
I do like the idea that the before and after are just, like, the bottom left and right corner of the screen. If you mess those up while applying the rule, welp… like sands through the hourglass …
I wonder how the before/after scheme could be adapted to free floating particles... here's a sketch off the top
agentsheets has the rules in a separate layer, same as cellpond. to make them happen in the same layer you need some way of "quoting" areas, lisp-style. i don't think it's that hard, it's just that no one has bothered yet
this is something that dave ackley does for his current brain project in the t2 tile work
With 💬 #devlog-together@2025-01-16 on my mind, here's an example single-file html with some support for annotation. Save it locally, swap out the text with some stuff to read, take notes on it as you read, save your notes locally. Thanks @Eli Mellen and Tom Larkworthy in particular for the inspiration. Based on Cristóbal Sciutto's note example. Suggestions and feature ideas welcome.
Oh awesome! Welcome to the dark side. You can make the main text editable with "contenteditable="true"" on the TD, still saves!
Very cool! This reminds me a lot of Webstrates, in praticular MyWebstrates based on Automerge.
That's the first example of this kind that I might actually use. Put differently, the use case is a good fit for the various technical trade-offs.
Kartik Agaram something you may run into with the single-file HTML/JS approach to be aware of is that some devices won’t execute JS, or will only execute a subset of JS when reading the file directly from the file system as opposed to through a web server. This is a security measure to prevent folks from being able to easily embed and run malicious JS in all kinds of files (like PDFs :melting_face:)
it runs JS fine, its just file:// is considered its own origin so it can't do cross origin requests... e.g. fetching an external image. The security context is different than normal. There are work arounds because JS can manufacture in-memory URLs that are, by construction, in the same origin. But yeah, you are in heavy yak shaving territory at that point, and you need a good mental model of the security model to work around those limitations if you need to.
Tom Larkworthy I ran with your suggestion to enable contenteditable on the left side, and made some changes to the UI to go with that. Thanks a lot for the suggestion! It also validates now, with many thanks to @Eli Mellen.
On my Android phone the core pieces all work, though there is some jank with the small screen size. The browser doesn't support saving the current page, but the save button works for me, though I had to iron out some issues so there may be more issues lurking for others.
On SeaMonkey the save button doesn't work, but I can save using the browser's shortcut! So this is looking pretty cross-platform now!
yeah looking cool! Quite neat. I think the saving to a file workflow suits a forking history. Like maybe you have base note you open, modify and save. You Downloads soon filllup with similarly sounding filenames. For lopecode I use the DOM title for the base name, and then append the timestamp so its orders sanely in the filesystem. Probably I use too much precision in the timestamp now I look at it closely, lol. So I think you need a way to set the title of the note, and the timestamp trick to be naturally filename collision avoidant.
I am begging to think about what is history in this model. You could generate a UUID every save and include the prior version to form a linked list, but this seems kinda fragile if you lose a file in the middle. Or maybe keep a list of content hashes within the file so the history is inside the doc, but you might not necessary have hard copies of everything (but you can search your filesystem for those hashes perhaps), or maybe you really keep all the operations for full replayability (could be nasty size wise if we consider a file upload as a recorded operation), nice thing with keeping the operations is you can make a cool animation of the evolution over time. Should it just have git in there so we don't reinvent the the wheel and allow merging across different histories?
One nice thing about building out a custom debug UI as I'm writing a program: it turns into an explorable explanation by the time I have a working program. Here's a (silent) explorable explanation for a simple program that I nonetheless struggled to get right.
Each screen is a hundred lines beyond Lua Carousel (which has existed before this whole idea of debug UIs was a twinkle in my eye)
Debugging and explaining are the same task, just in different contexts.
What you describe is exactly the experience that convinced me of moldable development.
Added a context menu so it was a bit more obvious how to add new cells. hosted page is here. Maybe this is enough webpage stuff for now and I should start porting my notebooks. Its getting a bit laggy now as well which I think is because the reactivity is not fine grained for most of the UI (underlying calculations are though).
