Visualizing programs with side-effects in a postfix shell with a live-updating text-mode environment. Built all the way up from machine code without any dependencies (except an x86 processor and Linux kernel).


Project page: github.com/akkartik/mu

More context: mastodon.social/@akkartik/1048

*Editing functions in the Mu shell*


Long delay since my last video. Printing floating-point numbers is *really* hard. I'm still half-assing it.

As a follow-up to merveilles.town/@akkartik/1053, I'm tightening focus to two threads:

a) These Mu shell experiments, and
b) An extremely skeletal OS to drop the Linux kernel dependency.

Deprioritized for now:
a) Other processors: RISCV, ARM, RPi, etc.
b) Graphics, mouse, etc. Device priorities for the OS are disk then ethernet.

*Towards running Mu without Linux*

All Mu really needs so far is to print to screen and read from the keyboard. Here's a 2-minute video about achieving that:


It seems such a small thing. But I needed lots of help, as you can see from the additions to my credits: github.com/akkartik/mu/compare

Merry Christmas to all! What a beautiful world.

Project page: github.com/akkartik/mu

More context: mastodon.social/@akkartik/1048

*Switching gears to pure graphics*

Until now Mu has followed classic Unix: stdin, stdout, pure text mode.

But giving up an OS kernel requires controlling the screen myself. Which requires various complicated probing for hardware. Then programs handling various screen sizes.

Easier: just always assume some common graphics mode. Say 1024x768 with 256 colors.

Interestingly, the default palette has far fewer than 256 colors. (Pic: 1024 cols each contain color `col%256`.)


*2020: Flood-filling the Mu computer*

A year ago I had a prototype of a C-level programming language mapping 1:1 to Assembly that I _thought_ could be type-safe.

Since then, I:

* wrote an academic paper on it
* made it type-safe
* began a high-level language atop it
* got into video, with 15 2-minute screencasts
* and ran programs written in it on bare metal, without an OS, like, 5 years before I expected to.

❤️ to everyone who inspired, taught, debated, encouraged.


*Rendering text atop baremetal*

Mu can now render text atop baremetal x86.

Try clicking around from akkartik.github.io/mu/html/bar

The boot-up machine code reads a few sectors from disk, configures a keyboard handler, and loads a bitmap font (2KB for ASCII, with the option for more).

I use GNU Unifont. I believe that means Mu is now GPL v2. So stated. IANAL and I try not to think about software IP. But a font? Copyright seems reasonable there.

Next up: a text editor!


*A more international interface for rendering text*

New 2-minute video: archive.org/details/akkartik-2

You get just one fixed screen resolution: 1024x768, 256 colors. Widely available on modern machines, no drivers needed.

You get just one fixed-width bitmap font. No bold/italics, no anti-aliasing.

BUT it won't make assumptions about English and left-to-right order. I eventually want anybody to be able to customize it to their language.

Main project page: github.com/akkartik/mu

I've been trying to visualize the default 256-color palette I get on baremetal.


To my eyes it looks like I can/should just live in the first 128 colors.

I built a game of "snakes", but it came out more like an etch-a-sketch 😄


Play it on any non-windows:

git clone github.com/akkartik/mu
cd mu
./translate_mu_baremetal_emulated baremetal/ex7.mu
qemu-system-i386 disk.img

h/j/k/l to draw

It took a while, but I've finally ported a pre-existing Mu program to baremetal: an RPN calculator.

This was _hard_, purely because of cursor management. I have a greater appreciation for everything that display hardware and terminal emulators provide for text mode. Mu so far puts the onus on the programmer.


In the end it's interesting to visualize the changes I had to make:

vim -d apps/rpn.mu baremetal/rpn.mu

They're entirely in `main`; the rest is unchanged.

I've been reimplementing my from-scratch live-updating postfix shell to _really_ from scratch (no more OS kernel), while at the same time rewriting the prototype with lots of tests and actually giving the language some sort of rigorous basis. No demos yet, but in the meantime here's Conway's Game of Life running on baremetal Mu.


Sources: akkartik.github.io/mu/html/bar

Main project page: github.com/akkartik/mu

The Mu shell is now off Linux


Starting point for the sources: akkartik.github.io/mu/html/bar

The architecture is now much cleaner. Functions contain lines, lines contain words, words contain gap buffers. Rendering a thing renders its constituent things. Render takes a top-left coordinate and returns a bottom-right coordinate. Each thing knows which constituent thing has its cursor, shows its cursor when rendering, redirects incoming keystrokes to it.


An experimental way to do control flow in the postfix Mu shell

The screenshot below shows an idea I've been playing with.

The conventional way Forth does control flow is a little confusing with words like `if` and `then` showing up at the end.

Factor uses quotations to put code blocks on the stack. But then you see a potentially complex chunk of code executing "all at once".

Main project page: github.com/akkartik/mu

Drilling into computations on the Mu shell

This was one of the more difficult things I've built, and yet all I've gotten working so far is some rudimentary tokenization. The reason is one little feature.. well, take a look for yourself.

archive.org/details/akkartik-2 (video; 2 mins)

As always, built all the way up from machine code, and designed primarily to be easy to build, easy to run, comprehensible to others. Also this time with lots of tests


Today was documentation day

Primitives available in the Mu computer when running without an OS: github.com/akkartik/mu/blob/ma

Primitives available when running on Linux: github.com/akkartik/mu/blob/ma

For starters I focused just on making things more discoverable. These files are optimized for opening in your text editor, jumping to definitions to see type signatures, etc. See github.com/akkartik/mu/blob/ma for a ctags configuration for Mu and SubX programs.

Main project page: github.com/akkartik/mu

Mu can now read from an ATA (IDE) disk drive on Qemu.


It wouldn't have been possible without the lovely folks over on . And the inspiration of ColorForth (merveilles.town/@akkartik/1059), though I still don't understand how that driver works.

The Mu computer now has drivers for disk and mouse.

Still extremely klunky. IDE disk drives only, and the mouse driver uses polling because configuring IRQ 12 is still beyond me.

Example programs (as usual memory safe and translating 1:1 to x86 machine code)

Disk: akkartik.github.io/mu/html/ex9

Mouse: akkartik.github.io/mu/html/ex1

Here's video of the mouse example. There's no pointer so you have to imagine me moving the mouse around.

Like I said. Klunky.

Main project page: github.com/akkartik/mu

What should the signature of a program look like?

Typed languages have a fixed signature for function `main`. A list of strings, a window context, or an IO monad.

Here's the signature on the Mu computer:

fn main screen: (addr screen), keyboard: (addr keyboard), data-disk: (addr disk)

A rudimentary, hokey capability system. No mouse yet. 'screen' is only used for text; pixel graphics currently go around it. 'data-disk' can't access code, and will eventually include finer-grained restrictions.

Mu's HLL is now Turing-complete, I think.

Things to notice:
* Wordstar-style menu at the bottom.
* List of available primitive functions in bottom left.
* List of globals on the left side that updates as I add definitions.
* Matching parens highlighted as I type.
* Drilling down into the trace to understand how the program was evaluated.


Main project page: github.com/akkartik/mu

Prototyping on the Mu computer

A 3-minute video showing what it's currently like to prototype programs on the Mu computer. There are lots of limitations. It's slow, and it can only handle short runs.

While these limitations will be relaxed over time, the goal is partly to nudge people to throw the prototype away once they know what they want, and rewrite it one level down. Therefore: encourage people to write lots of tests.


Main project page: github.com/akkartik/mu

Managing side-effects on the Mu computer

archive.org/details/akkartik-m (video; 2 minutes)

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: github.com/akkartik/mu

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

archive.org/details/akkartik-m (video; 6 minutes)

Main project page: github.com/akkartik/mu

Collaborating on a problem from Advent of Code in Mu

If anybody is into long and rambling 100-minute videos that taper off without a certain conclusion:


Mostly by Sumeet Agarwal (github.com/sumeet)

Here's the working solution if anyone wants to try it out it: akkartik.github.io/mu/html/lin

Main project page: github.com/akkartik/mu

Syntax sugar in the Mu shell

I like Lisp. But I also strongly believe anyone should be able to boot into a computer and immediately type in '1+1'. Get started using the computer as just a calculator. It's surprising how few computers satisfy that property. Now the Mu computer does.

archive.org/details/akkartik-m (video; 8 minutes)

Main project page: github.com/akkartik/mu


Images (kinda) and files (kinda) on the Mu computer

The Mu computer has only 256 colors by default, but approximates arbitrary RGB combinations using dithering.

archive.org/details/akkartik-m (video; 9 minutes)

Main project page: github.com/akkartik/mu

· · Web · 1 · 2 · 8

A network-less, read-only browser built up from machine code

archive.org/details/akkartik-m (video; 5 minutes; includes instructions to try it out)

A lot gets said about simplicity in software, about essential vs accidental complexity. If you really want a simple stack that empowers everyone, it isn't enough to just eliminate accidental complexity (even if we could all agree on what it is). You need to also avoid _other people's_ essential complexity.

Main project page: github.com/akkartik/mu

The Mu computer now loads 140KB of Unicode glyphs from its system font

Unicode blocks now supported: latin, greek, cyrillic, armenian, hebrew, arabic, syriac, thaana, n'ko, indian (ISCII), sinhala, thai, lao, tibetan, myanmar, georgian (< U+1100)

- No support for combining characters yet (en.wikipedia.org/wiki/Combinin) This makes the other languages I know (Hindi, Tamil) well-nigh useless.

- Unifont's glyphs for the non-Latin languages I know turn out to be quite spectacularly ugly.

Hackiest possible support for rendering Unicode combining characters using GNU Unifont

This is the equivalent of backing up a typewriter by one character and overlaying a second letter on the same space.

Main project page: github.com/akkartik/mu

@nasser following up on merveilles.town/@akkartik/1057 from six months ago, I think Mu is now at approximately the level of mediocrity/trashiness of conventional software when it comes to rendering Arabic. Likely still worse, but I mean they probably both suck to you 😄

I have a hazy plan now to construct a trie data structure that maps utf-8 byte prefixes to glyphs (which can have arbitrary-size bitmaps) Read one byte at a time into a buffer, select the glyph for the longest prefix. What do you think?

@akkartik of course until the unicode is displayed it is in a superposition of both Shr00fdinger and Shrödinger

@akkartik That metaphor reminds me of an idea I came up with last year.

The invention of writing has usually involved etching/pushing/brushing pigments upon a substrate. But what if a writing system was invented based on stamps? A scribe might angle and directionally smudge the same stamp in different ways to make different glyphs.

And then maybe they could go back and overlay more stamps on top of what they wrote to encode more detail.

Voila, a writing system with LOD based on overstrike! 🤓

@akkartik i am not sure i follow -- how do utf8 prefixes solve the shaping problem? you have to turn eg the byte sequence (read from right to left)
م ر ح ب ا
when you encounter م how do you know, from prefix alone to render مـ? same for ر being rendered as ـر, and so on?

@nasser Basically unbounded lookahead. I'm wondering if you can just throw more glyphs at the problem for lots more combinations of utf-8 bytes, far more than the usual 4 or 6. If you don't yet know which of n ways to render a glyph, just keep reading.

@nasser In this case I'd have a glyph for

م ر

which looks like


@akkartik I worry that gets you into a situation where you basically need a separate "glyph" for each word? for example
م س ت ق ب ل ن ا
should render as
rendering م on its own is wrong, مس is wrong, مست is also wrong, مستق also wrong... and so on, until I get to the end of the word, which is what needs to be rendered, and if I understand the system correctly there needs to be a single glyph for that. is that accurate? if so then you are facing a combinatorial explosion of "glyphs"

@akkartik fwiw conventional text shaping avoids a combinatorial explosion by breaking up cursive letters into four forms, initial medial final and isolated. The shaping engine then selects and positions the correct form for each letter based on its position in the word and a state machine that it maintains. ope type has facilities to replace runs of characters with a ligature (which is sort of what your system is doing), but the default shaping algorithm does not depend on this.

@nasser @akkartik i have always wondered if arabic text needed more of an approach like knuth’s metafont- e.g. instead of drawing closed bezier shapes, do more of an actual pen calligraphy simulation, where letter joins happen as a result of virtual pen movement. it’s more complicated but maybe justified complexity?

@zens @akkartik I feel similarly. this is something I've wanted to play around with for a while.

@nasser @zens @akkartik I have seen vistages of this still present in Cairo Vector Graphics. Though now they've fully switched to heavily-optimized character-by-character blitting.

Seems like there needs to be new Arabic font formats for it to be worth sticking with this vector approach...

@alcinnz @nasser @akkartik postscript fonts when they were still a thing were full postscript programs. they could possibly have handled this

@alcinnz @nasser @akkartik at the very least, brush simulation or not, it seems that these scripts require more flexible constraint primitives than mere blitting of precachef shapes could provide

@nasser What about the ambigram examples I've seen? Is that a separate style with its own rules?

@nasser Were the classical printers in merveilles.town/@nasser/105520 falling back on whole words for some cases but mostly doing your state machine approach?

@akkartik @nasser there's some discussion in on libera.chat about this stuff. you may be able to get some more ideas there, or share your own. 🖤

@theruran I'm going to sign up. Too bad I can't read past chat logs!

@theruran How do y'all use IRC vs Discord? I'm already on the Discord which is quite sprawling and hard to keep up with.

@akkartik I don't use Discord. I use IRCCloud.com for IRC :P If you pay for the service it will keep you connected so you can read past chat logs. Some channels post logs somewhere on the Web.

@akkartik more or less, as I understand it. they had blocks for whole words but also blocks for many versions of each letter which they could use to construct new words.

@nasser I love this answer and think there needs to be a team of (non Latin minded) folks replying to all the broken assumptions on language all over the programmer forums with posts like these!

@nasser @zens I see similar artifacts in Tamil as well (which I cannot read). Compare the rendering of a few lines in Mac OS vs Mu. It looks like a circle combiner at the end of a word is supposed to render as a bar.

@akkartik @zens yup. i would ask someone fluent in tamil but if it looks different than eg what osx does its likely wrong. text shaping has a lot of irreducible complexity to it...

@nasser @zens Yeah. Tamil is simple enough that I think Mac gets it right.

@akkartik @zens yup. and don't forget other writing systems need other mechanisms. harfbuzz is open source and definitely required reading here.

@nasser @zens Yeah I found that link via harfbuzz.github.io/what-is-har

What do you think of the Arabic support in Harfbuzz? Is it adequate or does it still require work? If the latter, it seems like the place to improve things is inside the TTF fonts used. Does that seem right?

@akkartik @nasser i cannot speak to its actual quality, but arabic text is its entire reason for existing in the first place: a guy like you two got fed up with bad arabic support in software

@zens @akkartik harfbuzz arabic support is some of the best currently available! the original author is persian so he has intimate knowledge of the arabic script in particular.

I've met him a few times and he said he started the project because he wanted to make a website for persian poetry years ago but it just wasn't possible lol... so he had to spend about a decade writing the best open source text shaping library first, now he can make his website no problem 🙏

Sign in to participate in the conversation

Revel in the marvels of the universe. We are a collective of forward-thinking individuals who strive to better ourselves and our surroundings through constant creation. We express ourselves through music, art, games, and writing. We also put great value in play. A warm welcome to any like-minded people who feel these ideals resonate with them.