🐰 chee cherries quiet party

twtw5/twtw9

There was a telephone call this week, that started out planning a trip together and ended maybe we’ll never talk to each other again. Well, what’s going on with my gals and in some cases boys? Do you ever lie to yourself? The biggest lie I tell myself is “I’ll remember this”. Or maybe it’s “i don’t care”. Remember that time a dog got into the school? Damn. I’d love a day like that again. The word “astrobleme” still makes my heart skip a beat. Jennifer imagined me beside her on the porch while she back and forth in a rocking chair. I spent the weekend, and I spent some of the evenings too. There was one of the evenings I went out to the bar near the Financial Times office to say hello to some people I used to work with at the Financial Times. It was nice to see them. I think I was annoying but I’m really so very not used to socializing with people who aren’t the computer at the moment. There were a lot of times this week when I wanted to drink tequila but none of them were the time I was at the bar. During the evenings I have been working on Littlebook 3.0. Or, 1, as the case may be. I’ve tried a few different systems for Littlebook3 so far. The first one I tried, (the pic last week), was very much a proof of concept. It was nice, but very rough and I need it to work in a web browser too. The second thing I tried was esoteric and fun, everything in pure js with no build step. Runtime reflection by parsing function.toString() with acorn. Grabbing the place lb.defineCommand() was called from by inspecting (new Error).stack. Doc strings inside the function, like lisp and python, by including a template string as the first line in the function. That was converted on the fly to markdown, and displayed together helpfully (“xyz is an interactive command defined at xyz.js:10:2” then the doc string) just like emacs. Once i started writing with it, i learned that it would feel as though i were operating the computer through a big pool of honey. All heavy, all sticky, all weighed down and slow. The third attempt seems very promising. It’s kind of crazy, you should see my whiteboard. But I think it will be very cool. It took me all weekend to get it working, but I was able to edit the text editor using itself tonight before bed and that’s how you know you’re living. The part I was building this weekend is the bootstrapping system (which i call bookstrap, or littlebootstraps). You see it’s an important design goal that you should be able to completely change the editor if you want, you need access to the code that powers it and the power to change it. That’s in addition to making an explorable system that teaches you while you learn it and change it. Some more rewrites are needed there, and more prototyping (building more custom code in it so i can see how it feels, and improving how it feels over time). Here’s how the bootstrapping works:

  1. You load up Littlebook (in the browser, or the one on your computer)
  2. bookstrap kicks in and detects your “native file system” — that’s opfs:// on the web version and file:// when you’re using Littlebook Desktop
  3. bookstrap creates a library for each of the local filesystem protocols you have available
  4. The install phase grabs all the source code and puts it somewhere you can change it — on the web it puts it in opfs:///littlebook/system/, and on desktop it puts it in ~/.local/share/littlebook/
  5. The install phase makes you a user directory (opfs:///littlebook/user, ~/.config/littlebook/)
  6. The User/early-init.js script is executed (as a non-esm script)
  7. The install phase passes off to the bundleworker, which creates an esbuild worker
  8. The bundleworker is set up to be able to resolve imports in your opfs:/// or file:/// system, using the fs api that bookstraps prepared. As well as importmaps.
  9. The bundleworker loads System/entrypoint.ts, compiles it, bundles it, evals it.
  10. The runtime system initializes the core editor things: events, surfaces, surface layers, views, protocol handlers and their defaults
  11. The system then dynamically imports your User/init.ts file where you can add new events, surfaces, surface layers, protocol handlers and views

I believe that this is a powerful enough system to build an even more powerful system with. All the steps before bundleworker (including early-init.js) are executed as regular scripts, so they can even help build the importmap. Everything about the system (apart from bookstrap and bundleworker) is replaceable, it’s all in the hands of the user.

The “grabs all the source code” from step 4 is entertaining. On desktop mode it’s pretty normal, the source code is embedded in the .app and it’s extracted out to your local share dir. On the web, it’s slightly sillier. The opfs worker fetches a file called /system.json which contains a virtual file tree of the entire system, and it creates a file in opfs for each entry. Surprisingly that takes only about 100ms to do. My plan for the reflection is to analyze the sourcemaps generated by esbuild (they’re made available to the user too), and combine that with some of the error parsing code i threw away from attempt 2 (wednesday). The settings & commands system is important for being able to build UIs and electric help. I’ll be reading my emacs manual.

I have to go.