Weeknotes 2022 W44: Burn

October 31​–​November 6, 2022
1100 words

Find me on Mas­to­don: @denis@chaos.social.

I’m also on ruby.social as @denis@ruby.social. I’m not sure whether it makes sense to have two Mas­to­don accounts. I’m inclined to move everything over to the ruby.social one. After all, I’m primarily active in the Ruby community, so it makes more sense to have a presence there. We’ll see!

I burnt my arm on a very hot oven tray on Wednesday. I went to my GP for it, who apparently thinks it’s fine, despite the nasty-looking wound.

This happened while making lunch while I was pulled into an urgent meeting, and that just caused too much distraction for me to focus properly on dealing with stuff that’s about 200 °C (~ 400 °F).

At the same time, I also let the food in one my pans burn to a crisp, so that was not a very good lunch.

Just say no to lunchtime meetings, I suppose?

Ahh, gremlins! After the upgrade to macOS Ventura, plenty of third-party applications are now “damaged” and can no longer be opened. That’s not supposed to happen, is it?

More gremlins, I suppose: On Saturday, I realised that my entire Homebrew installation was still all compiled for Intel, rather than Apple Silicon. uname -m returned x86_64, rather than arm64. That was confusing, but at least it explains why recompiling everything made it recompile it for x86, which my Mac thought was the native architecture.

Presumably, this happened because I use fish installed via Homebrew as my shell, and that one runs in Rosetta. Running uname -m runs within fish, and also runs in Rosetta, so it returns x86_64. That is how it works — I think. I’m still confused.

I nuked my Homebrew setup and reinstalled it, and now everything is freshly compiled for arm64. The process is pretty smooth, if not time-consuming:

  1. brew bundle dump
  2. Uninstall Homebrew
  3. Reinstall Homebrew
  4. brew bundle

Step 1 creates a Brewfile containing all the installed packages, and in step 4 that file is used to reinstall everything to the exact state of step 1.

Have I already mentioned that Homebrew is fantastic?

On Apple Silicon (arm64), Ruby does not compile out of the box. I had inadvertently been running Ruby in x86 mode (see above), and because I wanted native binaries, I trashed ~/.rubies and attempted to reinstall the Rubies I had before. But oh, problems ahead:

Undefined symbols for architecture arm64:
  "_rb_arithmetic_sequence_extract", referenced from:
      _arith_seq_s_extract in extract.o

The fix, according to nice people on the Internet, is to pass --enable-shared when building Ruby. With ruby-install, that looks like this:

% ruby-install ruby 3.1.2 -- --enable-shared

I won’t pretend to understand why this makes it works, but all I care about is that I have a working Ruby installation — which I now do!

I spent a bit more time playing around with creating that budgeting app prototype. I converted the app to React (from Elm).

I also attempted to get it integrated into Electron, but after hours of frustration I gave up. I stumbled on Tauri and gave it a try, and I’m impressed! The out-of-the-box development experience is fantastic, and the resulting executable is tiny and runs very fast:

Tauri gives me another reason to dive into Rust. Some of the background data processing will be significant, I imagine, so using Rust for that will be appropriate.

I started playing around with Tauri when this app was still written in Elm, and I was surprised how well Tauri integrates with existing projects. I had a very shabby build system cobbled together for various bits of this Elm project, and I got Tauri to work with it without having to modify anything.

I also made a cute little icon. The piggy bank symbol comes from Bootstrap Icons. Also, the icon is teal. Teal: it’s the color of serious finance.

To be clear, this is me playing around, without the intention of ever publishing this app, or even finishing it. It’s for fun! Can’t I just have fun?!

On the Nanoc side of things, more performance improvements are being made.

PR #1609 yields a significant speedup. The source of slowness addressed by this PR didn’t quite show in the CPU profiles, but my sneaking suspicion turned out to be correct after finishing up the implementation. This change isn’t released yet, but will soon. CPU profilers are great, but this is an example where it really helps to think about a system holistically.

In addition to using CPU profiling, I also ran a couple of benchmarks on the implementation of the ItemRepIgnorableIterator class introduced in the aforementioned PR. It turns out that Array#dup + Array#shift is very fast, and that #loop is slow. This lead to PR #1610, which makes the iterator much faster, and makes the code a lot cleaner. Lesson learnt: don’t make performance decisions without benchmarking.

Lastly, there’s issue #1605, on which I have made some progress, but more is to come. It’s been bending my brain a lot.

Next week at work, I will be giving a tech talk about writing parsers and interpreters. My plan is to create a tiny new language with accompanying interpreter in about 30 minutes.

I’ve written so many parsers and interpreters by now that I can pretty much do it in my sleep. This time, however, I will be doing it while wide awake.

Entertainment:

Links:

You can reply to this weeknotes entry by email. I’d love to hear your thoughts!
If you like what I write, stick your email address below and subscribe. I send out my weeknotes every Sunday morning. Alternatively, subscribe to the web feed.
Incoming links: Gremlins, Weeknotes 2022 W45: Burn II.