Weeknotes 180

Morning!

On Monday it finally rained big fat hot rain, generating the elusive mega petrichor waft.

After the rain I went to the Royal Festival Hall and saw Warpaint supported by Amie Blu. It was a decent gig despite the large proportion of the audience who enjoy standing up and/or walking around during performances at that venue. The air conditioning was great.

I totally forgot LRUG was also happening that evening. Oops.

I haven’t got around to John Wick: Chapter 4 yet. I did watch Yesterday, a film which combines the screenwriting of Richard Curtis with the songwriting of The Beatles (please draw your own conclusions). But Danny Boyle knows what he’s doing, and I found the bit with Robert Carlyle quite touching.

I rewatched Amadeus for the first time in probably thirty years and thought it held up really well despite (like Mozart) going off the rails a bit in the second half. I don’t think I’ve ever seen the director’s cut but the 161 minutes of the theatrical cut already feels more than long enough, especially in comparison to the canonically correct film length of 90 minutes.

Silo continues to fully commit to its innovative “one thing happens per episode” system of narrative revelation. What next? Alien invasion? Gender reveal? Laundry mistake?

I found time to finish and ship more of the pending changes to my WebAssembly interpreter:

1. I tidied up the tests so they’re a bit less embarrassing. I’m still not using a testing framework but at least my grubby calls to raise are now more coherently organised.

2. I added support for element segment abbreviations to the preprocessor. This is the main change that’s been holding up my stack of branches because it involves several interrelated abbreviations and it’s a bit fiddly to implement them one at a time without breaking or modifying any existing tests. But I eventually settled on an approach and I’m satisfied with how it came out.

3. I could say whatever I like in this bit couldn’t I? Nobody reads this bit.

4. I also added support for inline element segments in table definitions, taking advantage of my language spec fix from a few weeks ago.

It’s pleasing to see more complexity shake out of the parser and interpreter as I continue this work on the preprocessor. I have a few more straightforward abbreviations ready to ship (data segments and global definitions) and then I’ll have to tackle the more difficult problem of desugaring type uses, which are a right nightmare.

My new fan has an infrared remote control and, because I’m lazy, I wanted to be able to control it with HomeKit too. I couldn’t find any genuinely HomeKit-compatible IR blasters so with some trepidation I bought the Broadlink RM4 mini to see if I could cobble something together.

I was glad to find an open source library for talking directly to the RM4 mini without having to install Broadlink’s dodgy-looking iOS app. The bad news is that it’s written in Python, a language which gives me the programming equivalent of seasonal affective disorder whenever I have to use it, but the good news is that it includes a command-line interface so I can shell out to it without having to look directly at the code.

It only took a couple of minutes to train the blaster from the existing remote, and ruby_home made it easy to expose the appropriate CLI invocations as a HomeKit accessory. The remote’s buttons make relative adjustments to the fan state — “toggle power”, “increase speed”, “decrease speed” — rather than set it absolutely, so I had to do a little bit of work to translate a HomeKit message like “set speed to 80%” into an IR command like “increase speed three times”, but that in itself wasn’t difficult.

The main obstacle was that there’s no way to read the fan’s power status and speed over IR, so I have to maintain a guess about the current state and update it over time to reflect the commands I send. But this dead reckoning can easily get out of sync with reality: if the fan misses an IR command, or I use the remote instead of HomeKit, like an animal, I get into a situation where turning the fan off in HomeKit actually turns it on, or I can’t increase the speed because HomeKit thinks it’s already at maximum even though it’s actually only at 50%, or whatever.

I can resync the speed state with reality by intentionally overshooting the extremes (e.g. to set it to 100%, I increase speed ten times regardless of the current guess), but there isn’t a corresponding way to brute-force agreement on power state because the power button is only a toggle, not explicit “on” or “off”. Fortunately it turns out that adjusting the speed also turns the fan on if it isn’t already, which gave me a convoluted way to automatically resync it in code: when trying to turn the fan off, briefly adjust the speed before toggling power; when trying to turn it on, briefly adjust the speed afterwards. So, although my guess about the power state can still get out of sync in the time between changes, the next change always brings it back in line.

Being lazy is a lot of work. Next time I’ll use the remote.

The thing is: I enjoy programming, which is why I don’t think I’ll ever viscerally understand people who are so keen to get a language model to do it for them.

I’ve got no work on for the next few weeks. Part of my brain is already allowing a little of the old economic anxiety to seep back in, but ultimately I’d rather be free so I’m looking forward to some downtime.

One hundred and eighty! 🎯