(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.
(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.
You can draw various graphics and edit text in arbitrary grid layouts, all on a pannable, zoomable infinite surface.
(I started Wart in 2010, Mu1 in 2014 and Mu in 2017.)
I reimplemented my little box model atop a foundation of an infinite 2D surface that can be panned and zoomed.
And my note-taking app. One thing I did recently: a move command that moves columns (analogous to browser tabs) to the left, while continually truncating columns on the right beyond some limit. The combination of these two has changed how I work, from messes all over the surface to much more localized access patterns where I live near the top left and move things over to it as I need them. (It's not a catastrophe if I lose a tab because on-disk search is working well.)
“When printing meant writing some Postscript it was a little work, but doable. Getting it onto a printer through a modern printer API is essentially impossible.”
"Hi, Creator here. Loved your previous episode, Beautiful Equations of Reality. Glad you like my game.
"I actually started out using lots of different equations. Regimes for small scales, large scales, Seattle, Wednesdays. But there were too many interactions and bugs. So we switched to a single set of equations. It's a little inefficient but reliable. Now all I do is say no to feature requests."
#microfiction
Doesn't save what you type in yet. This is just a demo for playing with.
I have no idea what attributes to include besides fg/bg/margin. So get in touch if this sparks ideas/suggestions.
:exploding_head:
A constant trickle of disk reads replaces an unbounded amount of stuff hanging around in memory.
This is a data-oriented solution in the footsteps of Mike Acton. I'm not removing fields from structs or switching to SoAs, but I am trying now to manage my caches.
GC is missold as "automatic memory management". All memory management is manual (you have to be careful about nulling references out); GC just simplifies freeing memory.
When something new pops up, a queue continues what they were doing. A stack switches.
Obviously this is a spectrum, but I find it very easy to rationalize that the new tasks are "quick".
Anyway, being a stack is hard with a new project. Every 2 minutes I discover something broken, and now I have to resist working on it.
Notation:
Implementation:
Render:
Is there a better name for this than "DOM"? A notation for a tree of rectangles, often containing text, to be rendered to screen and united with mouse events.
Rects contain either text or rows/cols of other rects. Other attributes: fg, bg, margin. Margin is margin-top or margin-left depending on whether the rect contains rows or cols.
No inline styling yet (bold, span, etc.), that feels like a separate concern.
Does it make sense why the top graph when averaged 10x yields the bottom?! Sure doesn't to me.