Working Notes: a commonplace notebook for recording & exploring ideas.
Home. Site Map. Subscribe. More at expLog.

2024-01-14

A fairly long week; I haven't been able to spend as much time learning new things as I would like; and I really need to start structuring these notes better.

Tweaked the CSS to enable text-size-adjust, which makes this website significantly easier to read on mobile -- I'd been wondering what I was missing compared to expLog.

/proc tricks

The Linux Debug filesystem is one of my favorite things: it's a ridiculously convenient way to explore, offers a lot of affordance and is something you can play with live.

/proc/$pid/environ can be very useful at times, and it contains a \0 separated list of the environment the process was started with.

I've actually used it twice recently, and I thought I'd record the tricks:

1. Sometimes programs will unset environment variables they were started with before handing over control, eg. LD_LIBRARY_PATH. I parsed /proc/$pid/environ to recreate the original environment (split by \0 and put it into a map), and then exec'd into the process I needed with that environment. It works surprisingly smoothly.

2. I was writing bash scripts I needed to be configurable, so I had three layers of configuration:

   • A set of default environment variables
   • Config files that could be sourced and used to override these
   • The ability to set the variables at the CLI while running to override both of these.

   Now this becomes tricky because variables set in the parent environment are generally the first to be overridden. /proc/$pid/environ to the rescue again: after sourcing the passed in config file, I would read the environ file and pull out the config variables I cared about and explicitly source them.

   Part of this was inspired from how Bash Idioms deals with configurations (including self-documenting code).

Marimo

Marimo is a beautiful new Python notebook that I wish I'd built. Someday I'm sure I'll try and build my own -- almost certainly with HTMX and even more minimalism.

Implementation details

• Tornado, React
• Mix of http & sockets

Features I really liked

• vim bindings out of the box
• a fresh, lightweight design
• seeing errors disappear as I fix imports live was excellent
• autocomplete is... interesting. I couldn't get copilot to work

Data format

The generated notebook is an executable script that relies heavily on decorators (app.cell) -- which is a significantly more elegant approach than json. Of course, that also means that no notebook outputs or state is ever persisted to disk.

Threading behavior

I'm always curious about how notebook desigers implement something like async tasks; asyncio itself seems to be slightly hard to use in these notebooks -- there's no default event loop, and I couldn't quite get it to make one for me to run background tasks.

Then I tried explicitly creating a thread: this doesn't actually print anywhere and instead prints to stdout. I expect this is something that'll get fixed in the future.

Reactivity

While I think this is a very nice way to build applications, I'm not yet sure if I'd like to use this approach to build "notebooks" for exploration.

I'm also going to be spending some time exploring more industrial strength visualization tools to handle exploring and visualizing much more complex data.

Are.na

I also decided to try out are.na to maintain notes on LLMs -- as a complement to these letters. Unfortunately I'm probably too used to being able to customize my workflows to stick with it.

Books

While reading tremendous amounts of fiction, I stumbled onto Master of Change by Brad Stulberg -- which has been surprisingly soothing and engrossing. There are also some extraordinary quotes in there:

“It seems that all true things must change and only that which changes remains true.”

• Carl Jung

Which is quoted in How to Skate.

— Kunal