I think there’s safety in saying that this year’s Microblogvember was tough, what with all the travelling and inability to come up with something decent for the prompt. While it was fun, I think I need the break. Until next year. π #mbnov
I usually eat two or three cans of tuna for lunch a week. And yet, I still donβt really consider myself a fish eater. Why? What needs to change before I can tell myself that yes, I eat fish? Do I have to eat actual fish? Must I eat fish for dinner? What are the rules here? #mbnov
Flight home from the US is next week. I’m hoping for an uneventful trip. The news is not cooperating though. π

I use to be quite religious in putting two spaces after a full stop. The only exception was when Iβm writing on Micro.blog, since it keeps the character count down. But now, Iβve been noticing this trend extend to other time I need to write in a web browser. #mbnov
Dynamo-Browse Running With iSH
Bit of a fun one today. After thinking about how one could go about setting up a small dev environment on the iPad, I remembered that I actually had iSH installed. I’ve had for a while but I’ve never really used it since I never installed tools that would be particularly useful. Thinking about what tools I could install, I was curious as to whether Dynamo-Browse could run on it. I guess if Dynamo-Browse was a simple CLI tool that does something and produces some output, it wouldn’t be to difficult to achieve this. But I don’t think I’d be exaggerating if I said Dynamo-Browse is a bit more sophisticated than your run-of-the-mill CLI tool. Part of this is finding out not only whether building it was possible, but whether it will run well.
Answering the first question involves determining which build settings to use to actually produce a binary that worked. Dynamo-Browse is a Go app, and Go has some pretty decent cross-compiling facilities so I had no doubt that such settings existed. My first thought was a Darwin ARM binary since that’s the OS and architecture of the iPad. But one of the features of iSH is that it actually converts the binary through a JIT before it runs it. And it turns out, after poking around a few of the included binaries using file
, that iSH expects binaries to be ELF 32-bit Linux binaries.
Thus, setting GOOS
to linux
and GOARCH
to 386
will produced a binary that would run in iSH:
GOOS=linux GOARCH=386 go build -o dynamo-browse-linux ./cmd/dynamo-browse/
After uploading it to the iPad using Airdrop and launching in in iSH, success!

So, is runs; but does is run well? Well, sadly no. Loading and scanning the table worked okay, but doing anything in the UI was an exercise in frustration. It takes about two seconds for the key press to be recognised and to move the selected row up or down. I’m not sure what the cause of this is but I suspect it’s the screen redrawing logic. There’s a lot of string manipulation involved which is not the most memory efficient. I’m wondering if building the app using TinyGo would improve things.
But even so, I’m reasonably impress that this worked at all. Whether it will mean that I’ll be using iSH more often for random tools I build remains to be seen, but at least the possibility is there.
Update: While watching a re:Invent session on how a company moved from Intel to ARM, they mentioned a massive hit to performance around a function that calculates the rune length of a Unicode character. This is something that this application is constantly doing in order to layout the elements on the screen. So I’m wondering if this utility function could be the cause of the slowdown.
Update 2: Ok, after thinking about this more, I think the last update makes no sense. For one thing, the binary iSH is running is an Intel one, and although iSH is interpreting it, I canβt imagine the slowdowns here are a result of the compiled binary. For another, both Intel and ARM (M1) builds of Dynamo-Browse work perfectly well on desktops and laptops (at least on MacOS systems). So the reason for the slowdown must be something else.
I heard the best way to get motivated to do something is to say to yourself βdo it for five minutes and if it isnβt working out, you can stop.β Iβve tried it and it works. Sure, you may stop, but usually youβll just carry on with the task. #mbnov
State election today. Number of people making their commitment to the process quite early. #mbnov

Massive delay to my flight on the weekend. What was originally a morning departure is now an evening one. But I think the new itinerary actually works out better than what it was so I’m actually quite happy about it.
Revived my silly little online finska scorecard and gave it a new domain name: finska.fun. This is in preparation for the summer, where playing a game or two of finska is becoming a bit of a ritual. #mbnov
I’ve been approaching Microblogvember by taking the prompt and writing a post around it, which results in posts that are a bit forced. A better way might be to write a regular post that includes the prompt. That way I retain my usual relaxed attitude towards posting here. #mbnov
You’d think I’d have a post with the word update in it. I use “update” at work all the time: apply this update to update the database and push the update. But racking my brain over the last hour or so, I couldn’t come up with an update with an “update”. #mbnov
πΊ The Computer Programme (1982)
Discovered from reading this Ars Technica article about the history of ARM. Was commissioned by the BBC in the early 1980’s to teach the British public about home computers. Found it to be quite charming.
Back home from Canberra. But only for a few days and then Iβm off to the US. Should be good but Iβm not looking forward to that 14 hour flight across the Pacific.
I hate days that involve airports or air travel in any capacity. Not so much the actual flying part; that’s all fine. It’s just all the things around timing or rendezvous that give me such anxiety. Very tricky thinking about anything else.
Typing in “graze” into Google Photos returned this photo. Conveniently, this was taken six months ago to the day. #mbnov

Nee Audax Toolset
I’ve decided to retire the Audax Toolset name, at least for the moment. It was too confusing to explain what it actually was, and with only a single tool implemented, this complexity was unnecessary.
The project is now named after the sole tool that is available: Dynamo-Browse. The site is now at dynamobrowse.app, although the old domain will still work. I haven’t renamed the repository just yet so there will still be references to “audax”, particularly the downloads section. I’m hoping to do this soon.
I think I’m happy with this decision. It really now puts focus on the project, and removes the feeling that another tool had to be built just to satisfy the name.
Oof, scrum ceremonies really take it out of me. 3.5 to 4 hours of meetings, usually hosted by me and with me doing all the talking. Really kills my voice.
Rocking my super cool hat and jacket ensemble this morning. We’re a couple of weeks from the high UVs of summer so I wear the hat whenever I’m outside. But it’s really cold this morning and the wind feels like ice so the jacket had to come out as well. Trendy. π€ #mbnov

GitHub Actions and the macOS Release
I’m using Goreleaser to build releases of Audax tools, since it works quite well in cross-compiling a Go program to various OS targets in a single run. I use this in a GitHub actions. Whenever I create a tag, the release pipeline will kick-off a run of Goreleaser, which will cross-compile Dynamo-Browse, package it, and publishing it to GitHub itself.
Recently, I found a bug in the MacOS Brew release of Dynamo-Browse. When the user tries to press c to copy the current item, the entire program will crash with a panic. I tracked the cause to the clipboard package that I’m using. Apparently, it requires Cgo to be usable on Darwin, and it will panic if CGO is not enabled1. But the GitHub action I was using was an Ubuntu runner. And since the package required some symbols from Foundation, which was only available on Darwin, I couldn’t just enable CGO.
However, I did learn that GitHub Actions actually supports MacOS runners. I don’t know why I didn’t think they wouldn’t. I guess, much like most of my experience with anything Apple, it would come at some sort of price. So you can imagine my delight in learning about this. And the first thing I did was try to use them in the release pipeline.
I first tried blindly switching from ubuntu-latest
to macos
. Sadly, it didn’t work as expected. It Turns out that the macos
runners do not have Docker installed, which broke a number of the actions I was using. And since the original ubuntu-latest
runner worked well for the Linux and Windows releases, I didn’t want to just junk them.
So what I did was split the release pipeline into three separate jobs:
- The first, running on
ubuntu-latest
, builds Audax tools and runs the tests to verify that the code is in working order. - The second, also running on
ubuntu-latest
, will invoke the Goreleaser action to build the Windows & Linux targets. - At the same time, the third, running on
macos
, will install Goreleaser viabrew
and run it to build the MacOS target.
The resulting pipeline looks a little like this:
name: release
on:
push:
tags:
- 'v*'
jobs:
build:
runs-on: ubuntu-latest
services:
# localstack Docker image
steps:
# Checkout, build test
release-linux:
needs: build
runs-on: ubuntu-latest
steps:
# Checkout
- name: Release
uses: goreleaser/goreleaser-action@v1
if: startsWith(github.ref, 'refs/tags/')
with:
version: latest
args: release -f linux.goreleaser.yml --skip-validate --rm-dist
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
release-macos:
needs: build
runs-on: macos-12
steps:
# Checkout
- name: Setup Goreleaser
run: |
# Can't use goreleaser/goreleaser-action as that requires Docker
# So need to launch it and run it using the shell.
brew install goreleaser/tap/goreleaser
brew install goreleaser
- name: Release
if: startsWith(github.ref, 'refs/tags/')
run: |
goreleaser release -f macos.goreleaser.yml --skip-validate --rm-dist
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
HOMEBREW_GITHUB_TOKEN: ${{ secrets.HOMEBREW_GITHUB_TOKEN }}
I’ve only used this to make a small maintenance release that fixes the clipboard panic problem, and so far it seems to work quite well.
After doing this, I also learnt that there’s actually a Goreleaser Docker image which could theoretically be used to cross-compile with CGO. I haven’t tried it, and honestly it sounds like too much trouble than it’s worth. Rather keep things simple.
-
This is where I complain that the function that is panicing actually returns an
error
type. Instead of panacing and bringing down the whole program, why not just return an error? ↩︎