Nothing profound here. But sometimes the internet collective can still be surprising.
Apparently, you can already cross-compile Zig (at least the basic stuff) for plan9.
Now this is fun!
Also, a note to self more than anything: while zig itself is simple and quick to take in, the built-in build system takes a bit to get used to, but it’s slowly starting to make sense. Especially since discovering you can use it to compile C/C++ code too.
The time when some thought should be given to something other than just random projects is approaching. For whom does the sysbell rings?
So why not sharpen the brain with a simple exercise? A “cold open” so to speak. A quick “hello” run through the current popular (and STRONGLY recommended) system programming languages. See what we remember and how easy the easiest example is, and then do the easiest example the “hard” way (communing with the system directly).
Throw together some code, and to avoid making the grave mistake of having an opinion on programming languages on the net, print out some metrics:
In the context of my bias toward embedded and/or system development, an interesting pattern emerges. Zig and Odin produce the least amount of code.
This is not an exhaustive or balanced test by any means. But let’s explore this further. How about a popular microcontroller (it can’t get more popular than Arduino on avr, right)?
In the case of toggling a value in a register (and thus blinking the Arduino Nano onboard LED), Zig and C are neck and neck. Using the avr-gcc version of the compiler and included libraries or manually writing the needed parts from scratch in Zig took about the same effort (as in no time at all). Interestingly, by using Zig one could also compile C code directly (though linking and packing are still better done with avr-gcc for now).
Some more exploring needs to be done on this.
Is anyone else familiar with the feeling when something fun becomes work?
Like when your favorite game gets an update with loot boxes (apologies; surprise mechanics) and grind. Or a quick task that will knock an item off a list and give you some motivation and momentum that turns into a rabbit hole of chores (Malcolm in the Middle was a GREAT show).
So has turned this fun adventure with the bme680 environmental sensor into a bottomless pit of miniature “ok, to make that work, I first need to completely reverse engineer this thing” soul-sucking jobs. Don’t misunderstand me; I love a challenge! But this whole thing was started to learn new things, not to become an expert in the field on this one thing. I have done enough academic research in my time to know how to pick these kinds of battle wisely.
I have countless ideas (that can be revisited later). From decompiling the library (not the first time) and reverse engineering the algorithm to simulating all possible variations of temp/press/hum/gas parameters and creating an ML model to learn its secrets (also not the first time).
But right now, I need a break from the “break” and to do some new fun things.
For example, how is it like updating the 9front install? While in the “sensor hole”, there was apparently a new release of 9front. The answer: suprisingly easy! Well, it’s easy compared to projects like LFS or archlinux.
Yes, you have to compile it yourself and copy the kernel manually, but the update process is really smooth. And it came with quite a few improvements.
The system doesn’t just feel faster; it actually is faster:
Let’s throw in some CSS tweaks as well, and the site is fun to work on again.
While we’re updating everything, how about some hardware updates?
Let’s add a homemade I2C bus break board for the Raspberry Pi with the worst soldering ever:
Since I discovered that pictures add a certain flair to these posts, a thermal check how the previous Raspberry Pi overclocking is holding up:
And to continue the update streak, why not finally figure out how to resize the hjfs partition.
It actually worked:
All of this got me interested in what else in the plan9 / 9front world got updated. If nothing else, I see the new drawterm now has a window bar under Wayland. It’s amazing that this part of the computing world is still kicking so much. Brings back some motivation for my own projects.
And we’re back on track.
I have come to a realization: coding for Arduino is like coding with ChatGPT.
Both are very useful tools. Spectacular if you’re learning, experimenting, or quickly prototyping with stuff. In other words, it is best when used to do something that has been done to death before. Venture out of this realm and you better be worth “your salt” (electrolytes are important for proper brain function).
Now, I’m not beyond ducking up royally:
Let’s file this one under “Rust wouldn’t fix this (TM)”.
So it’s good to validate your code/design/results/… against something known. And having finally gotten new bme680 sensors, it was time to do just that. And what a quicker and easier way than to slap it on an Arduino and compare results.
Yeah, it’s never that easy. The original Bosch library doesn’t work on the Arduino at hand (using precompiled blobs), and the DFRobot library from the manufacturer has nothing exposed.
Well fork, let’s do it ourselves and expose the raw data from the sensor.
And no, even that was not enough to figure out that one last discrepancy.
Let’s file this one under “Trust nothing (TM)”.
Now, regarding developing structures, let’s talk about balancing trees.
Sometimes it is not just a problem of a difference in proportion of branches, but an unsuitable root node. So, what to do?
First, prepare a replacement root node.
Link the new root node to the tree structure.
Make sure all the connections are updated.
Do proper testing and inspection. Multiple tests over time are preferred.
There’s nothing wrong with some application of exception handling.
The goal is for the new root node to properly support the structure and handle the load.
Today’s lesson, or more accurately a rant, on the topic of developing services and products leveraging usage of trees.
Tree structures are great! Efficient at traversing and storing. Not to mention representing hierarchical structure.
But there is a risk when implementing trees. The bugs are hard to find.
It is specially important to debug your trees early in development or the bugs might grow exponentially.
On a tangent, it is downright annoying when you find a bug in a random number generator.
If the last joke did not register, I suggest reading The Botany of Desire, to get a better understanding of the world of random mutations, specially regarding apple related development.