On rackmount displays

I've had a project to work on a Go utility to display information on the SSD1306 displays for the Raspberry Pis in my rack.

This Pi rackmount (a UCTRONICS 6246) fits 5 Pi 3/4s. It's the similar to the Pro version [1], except that it doesn't support SSDs and fits five instead of four Pis. Currently, it houses:

• butler, my gokrazy server used to run pure Go services and as a serial console for an SC131 CP/M computer.
• callisto, an unused Ubuntu 22.04 machine that I'm still bringing up.
• hermes, my server for running things that don't work on gokrazy, and also used for building and packaging software for arm64.
• bastion: a tailscale entrypoint into my network.

Each of these sleds has a 128x32 SSD1306 display; bastion is currently running some C code to display stats. However, butler won't run C code, so I thought I'd try to build out a sled display program in Go using periph.io.

First, writing code in Go again has been... annoying, something I didn't think I'd say. It feels clumsy and awkward, mostly around the build tooling and mechanics of writing code. I'm constantly having go mod complain at me, it runs into issues formatting or syncing code, etc. I actually prefer CMake and C++ at this point, I think.

Second, it doesn't work. For whatever reason that I haven't worked out yet, it doesn't display text correctly. I haven't even gotten the periph test programs working. This has been frustrating.

I'm going to put this back on the shelf for now, and maybe pick it up again later. It was just supposed to be a quick program and it's currently turning into a bog.

On text editors

Thinking about kge, I thought about how this should be architected [2]:

This is a rough overview of the major pieces. There's six major pieces:

• Buffer the core of the editor part. This is what holds the actual data being edited, with facilities for managing names and file paths and whatnot.
• A File is a concrete interface into file on disk. Not every Buffer is backed by a file: a new file, e.g. one that didn't exist when the buffer was opened, won't have a file yet; it will be given on once written. You can also have "virtual" buffers, which aren't backed by files at all.
• The Frame manages all the Buffers open in the editor, figuring out which one is active.
• The UI is a bridge between the user and buffers.
• Input handles raw input, turning them into input events: whether raw text to be entered into the buffer or control codes (like C-s to save files).
• Plugin allows interacting with other functionality, such as formatting or invoking a compiler.

Right now, I have basic versions of Buffer, File, and Frame. Next, I need to write a basic UI to start interacting with the buffers, and then work on some input mechanism.

On finding lost repos

Amazingly, while reading through old posts to clean up formatting, I found the lost repo pious!