🍎 week 11, day 2 - 3d graphics lurking, apple silicon despair

hosted Minimum Viable Code, 10am

I worked through rustwasm book chapter 4.5, adding some Rust-public methods that aren’t exposed to JS and setting up headless testing. Nothing visual to show off here.

Sunni was playing with three.js and made a neat interactive arrangement of spheres scattered at points along a fractal-like contour. There are so many neat 3d graphics explorations in this batch. I’ve been spending most of my time in 2d but want to branch out a little more.

Kevan veered off into micro:bit hardware land and showed us the microbit-dal, or Device Abstraction Layer (DAL) that composes a micro:bit runtime.

Lots of other projects too, a really inspiring range of different topics people have been exploring!

three.js lurking, 12pm

I dropped in to lurk on the threejs-journey study group. It’s a course that costs money, which is why I haven’t casually tried it yet, but people were making some good cases for it. Normally I have zero interest in paid courses that teach you how to use a specific framework, but this one is appealing in the range of stuff it covers. It looks like a sort of holistic, very concrete, web-based 3d graphics speedrun which additionally covers a bit of shaders as well as Blender if you want to build and import 3d models.

• Andy: The teacher is easier to listen to than other video lecturers, and also provides text transcripts if you’re really not into video lectures.
• Ben: 3d graphics is such a broad genre that it feels like being thrown into the deep end. It’s nice to have structure.

three.js has been prominent for over a decade and its power, versatility, and performance never ceases to amaze me. For some reason I haven’t used it a whole lot and I’d like to change that.

(at some point in the past, I took an extremely brief Creative Coding dive into forking their procedural terrain raycaster demo and adding the illusion of microbiomes by coloring the terrain based on heightmap value. demo here. it’s basically a 2d grid of perlin noise values which have been interpreted as “height” for that x,y and then a raycaster is used to render the interpretation.)

Daniel presented an incredible pair of demos. The first appeared to be some kind of hyperspace composed of procedurally generated singing flying donuts. The second was a 3d pinball machine that sang notes when the ball hit the pinball rods. I love the themes here.

Also TIL, in Unity you can just check a box to turn on rigidbody physics.

It was nice and motivating to see the range of different cool projects that people have been working on!

lunch 1-2pm

I went out to spend the rest of the daylight in the backyard because it feels like summer outside and it’s amazing. The local feral tuxedo cat showed up and stared at me.

let myself get derailed by qmk struggs on Apple silicon

Been wanting to change a couple of noncritical macros on my crkbd keyboard but I’ve been procrastinating for a couple of months because I haven’t yet re-set-up my qmk (keyboard firmware) compilation toolchain on my new Apple Silicon laptop.

I successfully managed to force my 2014 laptop to hold out (for some definition of “success”) and didn’t get an Apple Silicon laptop until very recently because I was waiting a minimum of 2 years for developers to get toolchain support for the new chip architecture into a viable state. Hardware/toolchain compatibility actually matter for some of us, LOL.

Anyway, it’s possible to compile qmk on macOS 12 / Apple Silicon, but as with all major changes, some changes are needed.

debugging chronicles: entrypoint

I tried to run a standard qmk command and immediately got a lengthy Python stack trace that would have required me to know a lot about the internal implementation of qmk to understand what was going wrong.

In my experience, any stack trace coming out of a freshly installed executable that requires me to know way too much about that executable for my own good is inevitably a dependency issue 99% of the time, so I didn’t even bother reading most of the stack trace. (In extremely rare cases, it’s a genuine bug that has not been fixed yet in a small project with an extremely small, unpaid volunteer support team.)

x86_64 -> silicon support

arch is a nice terminal utility that lets you run the selected chip architecture of a universal (cross-architecture) binary. I attempted to reinstall qmk via the setup instructions for Apple Silicon, which use arch, and ran into a complaint that I had the wrong chip architecture. Yes I’m aware.

Apple has an environment called Rosetta which does its best (no guarantees, of course) to translate x86_64 instructions so you can run some old binaries on Apple Silicon.

There’s a nice feature in the new macOS where you can check a box to tell any application to run with Rosetta. So I installed Rosetta and made a copy of iTerm so that I could have a separate Silicon instance of iTerm, and a Rosetta instance of iTerm.

Next, I read several suggestions to install two separate instances of homebrew (macOS package manager), an x86_64 version and a silicon version.

Running any two version managers simultaneously, let alone two different instances of the same version manager, seems like a guaranteed recipe for a potential factory-reset-level catastrophe disaster pileup, but to my surprise, this…appears to be a reasonably accepted approach that a lot of people take.

qmk has a lot of low-level dependencies and is thusly rather slow to install but I finally got the qmk CLI working on my apple silicon machine after reinstalling it with x86_64 brew in Rosetta terminal (and fixing misc other qmk dependency issues such as avr-gcc versioning along the way which I was relatively unfazed by because I already went through them the first time I installed qmk on my old machine).

I pulled the upstream qmk_firmware changes but have not recompiled my firmware yet with the changes. It is sure to be a misadventure.