Jun 13, 2021
One idea that got dropped on the editing floor for this post: the long shadows cast over our lives by the very first systems we program on.

I started programming (in undergrad) on an IBM PC descendant running DOS. I moved on to more sophisticated systems, but over a period of decades keep returning to seemingly little things about that first system that I could never replicate. Little things I turn out to be willing to give up big things for.

For others, it was some game console. NES, GBA, etc. I wonder how common it is to actually escape the gravitational pull of our first systems, how much of the differences between our projects stems from having our brains colonized by different first systems.

permalink

* *
Jun 9, 2021
Some live-coding in my programming environment, running on my computing stack built up from scratch.

https://archive.org/details/akkartik-mu-2021-06-09 (video; 6 minutes)

Snapshot of a session within the Mu computer's prototyping environment running on Qemu. There's a REPL sandbox on the right, a few function definitions on the left, a list of available primitives for reference on the bottom left, and a list of available keyboard shortcuts along the bottom.

Main project page: https://github.com/akkartik/mu

permalink

* *
May 31, 2021
Managing side-effects on the Mu computer

https://archive.org/details/akkartik-mu-2021-05-31 (video; 2 minutes)

Screenshot of the Mu prototyping environment running in a Qemu window. There's a code editor on the left and a REPL on the right. The REPL can show prints to a picture-in-picture fake screen. It also permits drilling down into the execution of a run to understand or debug what the computer did.

The Mu computer's prototyping environment uses traces to explain and debug programs. But traces are expensive to compute and made the environment slow and laggy.

I fixed things by collecting only a shallow trace at first, and iteratively deepening on demand by rerunning programs. This only works because it's safe to rerun functions. There are no side-effects in Mu.

Main project page: https://github.com/akkartik/mu

permalink

* *
May 20, 2021
The Mu shell's error handling is now much improved. Errors in programs you typed in were already showing up consistently in a trace without crashing the computer. However, _writes to the trace_ could cause it to crash in cryptic ways. No more.

Now I'm back to my long-term plan: a prototyping environment that nudges people to write tests, so that it's easier to throw away the prototype and rewrite it from scratch. Making codebases rewrite-friendly.

Main project page: https://github.com/akkartik/mu

permalink

* *
May 17, 2021
Using Mu to play with some ideas from Hest by Ivan Reese

https://archive.org/details/akkartik-mu-2021-05-17 (video; 3.5 minutes)

Mysterious picture showing a few squares connected by red and orange edges. There's a counter ticking off instants of time on the top right.

Putting more animation and control of time into the debugging experience.

More info on Hest: https://ivanish.ca/hest-podcast

Main project page for Mu: https://github.com/akkartik/mu


I was just reminded of the existence of an idea called double-buffering.

It's easy to add.

The current implementation is quite naive. Copies one byte at a time, makes several redundant copies per byte. In spite of all that, it makes a huge difference in video quality.

permalink

* *
May 15, 2021
The Mu computer now dumps a snapshot of the call stack when it fails catastrophically

The Mu computer running on Qemu, showing a session of the Lisp-based shell that has failed catastrophically. On the top left it prints out, all in a pinkish red, an error message and dumps the function calls in the call stack at the time of the error.

This was not fun. And the debug information in the second half of the code disk is now larger than the code itself.

On the other hand, I hope debugging will now be more fun!

permalink

* *
May 9, 2021
Zooming into the Mandelbrot set on the Mu computer

Apologies for the garish colors. Still a work in progress.

I recorded this on Qemu on a Mac, then sped it up 8x. I estimate that makes it 3x slower than Qemu on my Linux computer accelerated with KVM.

Sources

Main project page: https://github.com/akkartik/mu


Same video but replacing floating point numbers with fixed-point (8 bits of fractional precision)

Sources

permalink

* *
May 8, 2021
Playing with the kids on a Saturday morning

A full-circle rainbow in Mu running on Qemu.

Slowly drawing many full-circle rainbows all in a jumble.

A

Chessboard pattern on Qemu, 256 pixels to a side.

(Much faster on Linux, thanks to -enable-kvm.)

git clone https://github.com/akkartik/mu
cd mu
dd if=/dev/zero of=data.img count=20160
dd of=data.img conv=notrunc < shell/data.limg
./translate shell/*.mu  # gen code.img
qemu-system-i386 -enable-kvm -m 2G -hda code.img -hdb data.img

permalink

* *
May 7, 2021
The Mu computer now has Lisp macros

Here's the Bresenham algorithm for drawing circles using a few macros. My current style is to keep line width to 41 characters and lay out two columns of functions.

Bresenham's circle algorithm implemented using 2 macros:

  (when cond body) = (if cond body ())
  (let x val body) = ((fn (f) body) val)

Caveats:

  • No nested backquotes yet.
  • I can't draw circles too far down the screen due to a strange error.
  • In general, error messages have been a mess ever since I stopped relying on Linux. A heavy exercise in humility.

Main project page: https://github.com/akkartik/mu

permalink

* *
May 5, 2021
I've been noodling on sandboxing models

Robert Frost:

"Before I built a wall I'd ask to know
What I was walling in or walling out"
(https://www.poetryfoundation.org/poems/44266/mending-wall)

With computers, this strategy doesn't work. Inside and outside have a way of switching places.

In Unix, the crown jewels were the root user; other user accounts were sandboxed. Code (in C) ran all types erased.

Time passed. Root grew vestigial, people stopped sharing computers. The crown jewels moved to user accounts.

Some possible lessons to draw from these sample points.

Sandboxing isn't about a single boundary. When designing VMs for adoption, build for isolation within the VM in addition to the boundary. Allow people to collaborate and run untrusted code within a single sandbox.

Oh, and don't erase types.

permalink

* *
archive
projects
writings
videos
subscribe
Mastodon
RSS (?)
twtxt (?)
Station (?)