Lopecode is still horribly difficult to use. One step in the right direction is LSP support. So this sniffs the live runtime for auto-complete information. There are no types to source from, so this is the dynamic language version of it. Quite cool that it can autocomplete on data (it has its disadvantageous too, not sure if I can figure out function arguments dynamically for instance)

Redesigned my website (https://jimmyhmiller.com/). Some of it was out of a design for something a little less programmer minimalism and something that looked a bit more like the blogs I thought looked cool when I was younger. Some of it was to open up more places to put things. With a bit more structured site, adding new content doesn't feel quite as weird. For example, I was able to put my projects https://jimmyhmiller.com/projects in a defined section. These are some of the things I've been playing with lately. I have a few others that will make it there as well. Gives me obvious places to do write ups on them, to ask questions, etc. Going to hopefully do that for the whiteboard soon. (The connection between visuals and simulation is such a hard problem (for me) to solve that I want to write about it).

Hopefully all this means that I'll have some more devlog content in the not too distant future.

Random noodlings that are once again close to our shared interests: what is text?

The never ending editor project continues. I did not achieve my ambitions of writing it in my own language (yet). But I have achieved a different goal, I have been using it for all my personal development. Now (controversially I guess) I don't really do much coding by hand anymore. So this became a bit easier. I do have a built text editor in it. With color syntax and all that. But it is definitely less feature rich and I haven't been using it much. So the main interface (right now) is the terminal which uses libghostty. The whole thing is a bevy app in rust. A bit heavy weight admittedly, but I've found claude to be rather productive with the setup and performance has been pretty darn good.

Yes that is a chess widget in my editor. It does indeed work.

There are a ton of things I need to flesh out, but things are starting to come together. I have the ability to externally add widgets. So llms can add widgets for me. I've got some inference working with deepseek flash working where as I take actions it figures out things like potential widgets to add to to the dashboard, what directory the project is in. I have the starts of an inbox system so I can send requests from one project to fix some bug in a library I am depending on.

One thing I'm super happy with is that I run all the terminal sessions in the background, so even though I don't have hot reloading for the core editor platform, I never lose terminal/process state when it does restart.

Next goals are to work on things like bringing my flamegraph renderer into the system, adding rich support for charts and graphs, viewing diffs, remote operations, whiteboarding features, and the ability to make and visualize ad-hoc workflows.

It's really felt amazing to have something tailored to exactly what I need and the ability to constantly change it as I see fit.

In a throwback to one of the first things I remember wowing me on my first personal computer (compiz on ubuntu), I added a completely unnecessary 3d cube (n-gon) setup for switching projects. It's not quite polished. But it makes me so happy to silly this incredibly silly thing in my editor.
[file 'Screen Recording 2026-06-03 at 5.46.12 PM.mov' too large (136821144b)]

Oh look at that. This post I'm typing right now is immediately below a lil video of Jimmy's editor. It's such a cool lil editor! Wanna learn more about it? You're in some kind of luck! There's a new episode of Feeling Off Computing where we talk about that very editor. Oh, and we also talk about other stuff too. Gat:


<3

ahhhh menu bar. I have abandoned Golden Layout and rebuilt the framing so I can get more control, solve some glitching and adopt theming. Took ages, lopepage-2 module. Nearly every core module has been rebuilt at least once at this point. Other userspace modules can add their own menu items so its programmable. Doubled page load speed.

Renamed a months old blog post from HITL.md to MIRROR.md because oops typing hitl into google is not a conversation starter I want. warrenwhipple.com/mirror
Wrote the first draft of blog post on a QOC/IBIS interaction surface for AI coding I'm working on. github.com/warrenwhipple/decision-flow
Next up push the blog post forward.
Then transform MIRROR.md into an agent skill so it travels better.

Things like System Menus, LLM tools and audio effects should be extendible in userspace for a moldable system. I have done this pattern a few times where functionality provider inject themselves into a reactive variable by the service provider, but it does mean they need a direct reference to the plugin host system. This would quite well, until you go full ship of Theseus and rewrite the service notebooks too (which I do). So coupling the other way is a problem too. So I decide to fix this once and for all with a centralized reactive plugin system. So now everybody has a reference to just that notebook, and hopefully it is so simple and domain agnostic that that can last a few years.
observablehq.com/@tomlarkworthy/plugin-registry
classic service discovery but reactive.

What if annotations themselves are reactive programs, lol (everything should be Turing computable™️)

I am looking for a team member who has some compiler experience for a compiler hackathon in India, someone who have knowledge in memory management and models...

I got the unmodified Claude Code running in a webpage. 5Mb.

poor's man REpl https://github.com/uprun/eval-evil

More applied lens theory. A spreadsheet layout can be a bidirectional projection of a reactive notebook. This is extremely compelling, you can just us d3 for arithmetic and normal named cells for constants and external function, but the UX needs some work. A$1 vs A1 all works by lazily creating the cell "A$1" on the fly, then the normal notebook reactivity engine works... you can actually delete the spreadsheet projection and the code continues to work because the actual cell wiring was lifted into the notebook paradigm as normal cells already. This is my 2nd attempt at a spreadsheet prototype but I think I have got the model right this time (thanks again lens theory). Again its not either/or with notebook format. Its both at the same time.

I've been having a blast building a statically typed "lisp" I'm calling coil. It is very much alpha quality right now. But it lives in a space that no other language I know does and has been quite fun to build things with because of it.




It has the standard things you think of with lisp macros. But where it really becomes powerful is in its "metaprogram" system. Which is a concept I stole from jblows Jai. Though it is a bit different here I'm sure.

A metaprogram is a complete arbitrary computation at compiletime that is fed your whole program. Right now the interface isn't in its final form. But here are some examples of what you can do.



~/Documents/Code/projects/coil-experiments main
❯ cat tests/brainfuck/hello.bf
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.
<<+++++++++++++++.>.+++.------.--------.>+.>.

~/Documents/Code/projects/coil-experiments main
❯ coil run tests/brainfuck/hello.bf --use experiments.brainfuck.lang
Hello World!


The metaprogram here overrides the reader, making it so that bf is completely valid syntax in our language. The resulting program is all coil. No runtime component at all.

I have taken this way further than bf. I made a C metaprogram. Took all of doom, and now doom works in my language. No C at runtime. Only coil. Hopefully soon I'll have some demos to share for all of the amazing things you can do with metaprograms.

been implementing a game engine for a little programming language that I kinda hinted at once upon a time when I talked about kiki

here is a fairy chess implemented in that engine using that language

I've really wanted an easy way to build native gui apps. I've wanted them to feel different. To give me new unique options for designing something that I can customize and that doesn't look like any existing app. I've wanted them to be lightweight, feature rich, and easy to create. I think I've finally gotten something working. Created with pure coil, using metal for shaders and appkit for widgets. I've made a little layout engine and widget setup for building apps.

For the longest time I've wanted dynamic lighting in my UIs. But I never really knew how to make the most of it. A few months ago the idea of using stacked paper as a way of carve out UIs came to me. It offered a way to skeuomorphicly add interesting shapes, textures and lighting that I just really liked. I've finally been able to do it. These examples are of course not real UIs, not useful. But a decent showcase of the kinds of things I was hoping to achieve. This is all real. All native. All written in Coil.

(Yes the UIs are full of AI slop, but hopefully you can see the promise)
[file 'Screen Recording 2026-09-07 at 2.25.13 PM_CLIP_1080p.mp4' too large (5967478b)]