For the most part, I’ve never been a big believer in bucket lists. At least not the kind you wait until you’re dying to start checking off. In thinking recently, I’ve come to realize that the work I’ve done over the years probably checks those kinds of boxes on my career in software engineering.
Programming
Ever since getting the Raspberry Pi Pico, there have been two experimental projects in the back of my mind.
The first is of course: how to run DooM on the Pico. Based on what I’ve seen, I suspect the main point of suffering would be the limited ram compared to a i486 machine. Most of the console ports back in the day managed to show horn things into fairly modest systems, and I bet the two cores would work great for doing video/controller input on one core while the actual game runs on the other. What I haven’t been able to decide on is what path to take to explore that project. In my mind: I kind of see it as a more “Game Boy” like hand held with a screen and controls than anything else. I certainly don’t want to do ASCII doom over COM port :P. It would also be preferable to have separate storage that can address the storage capacity of WADs without having to cookie cutter a level into available flash, making the hand held style even more appropriate.
Second is building what in essence would be a personal computer. In essence a lot like ’70s kit computers such as the Altair, but imagined through the eyes of a geek that grew up in front of an MS-DOS machine. It’s stuck in my head a while that the Pico is far more powerful than the early CP/M and DOS based systems, and that it isn’t that complicated to connect the pico to external devices. From the prospective of fun, I think it would be neat to design a simple system around the Pico and built out something like a PC around it. On the downside, while creating a disk operating system in the vain of CP/M isn’t that big a stretch: I can’t really say that I fancy bootstrapping a toolchain to write programs for a custom operating system. But it’s an idea that keeps floating around whenever I look at how powerful the Pico is.
As a side note, I kind of wonder how hard it would be to replace the CRT in an old Macintosh SE style case with a similar sized LCD panel. While gutting the rest of the insides, and just using it as the mechanical environment to mount stuff. Really, I’m not sure if that’s brilliant or sacrilegious of such historic machines. Although to be fair, people have done some strange things with the cases of old busted Macs over the years….hehe.
Signs of a simpleton having fun with a new microcontroller:
- Write a program that makes the LED blink like a mother fucker.
- Write a program that spams a hello world to USB serial.
- Write a Read Eval Print Loop over USB serial.
static string evalline(const string& line){if (line.empty())return “”;if (line == “monkey”)return “Willow?”;if (line == “monster”)return “Corky?”;if (line == “sweet”)return “Misty?”;if (line == “help”)return “Try nicknames with fur”;blink(100);blink(100);blink(100);return string(“Unknown command: “) + line;}
Because why not? 😜
Huawei’s HarmonyOS: “Fake it till you make it” meets OS development
Forking Android and launching your own rebranded operating system is totally fine. But be upfront about that. Say “HarmonyOS is a fork of Android” instead of “HarmonyOS is not a copy of Android.” Don’t call HarmonyOS “all-new” when pretty much the opposite is true.
As a young programmer, I think it was probably around 2.4 or 2.2 that I started to use Python. Today it remains one of my favorite languages.
I remember thinking quite highly of the Zen of Python at the time. Much time as gone on since then, and to be frank, I think it even more beautiful and dead on balls accurate today than I did then. The older I get as a programmer the more accurately it reflects the reality.
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Baldur’s Gate 3 devs built a testing AI. Then, they tried to defeat it.
That is kind of neat, and likely worth the effort as it grows more capabilities for abusing the game.
Television, novels, and comics tell us one day the super cool A.I. will be super smart, and may or may not try to kill us all. Personally, I think the future looks more like a series of special purpose constructs aimed to help us with specific tasks. That’s the super-cool A.I. I’m looking forward to, because I’m probably going to be dead decades or centuries before we see anything like Cortana or Jarvis, lol.
New safety rules in C++ Core Check
While the for loop part may be a bit spotty, in the sense you should be paying attention and know which you want when writing the statement. I have to admit I would have liked the auto thing.
I’ve mainly relied on C++14 since about 2016 for my C++ use whenever possible, and sometimes newer because of standard library. While catching up wasn’t as painful as I thought, aside from how long it’s taken for C++17 to trickle through various Linux distributions, there were a few things I found myself watching closer.
One of these was the way auto typing copes with references. I learned pretty quickly to watch my syntax when using auto. If a real warning was available: it would have been much faster to notice the distinction. In my code, you’ll usually see auto used when the type would be redundant salt. But we usually want our sugars to not to have unintended pains, lol.
The code samples on the switch/case part also makes me remember just how verbose C’s simple switch/case statements are by today’s standards. Damn it, now my kind is flashing to SML….lol
My cxxversion and stdheaders
In various bits of code: I’ve been using these headers to solve the “__cplusplus says yeah, but actually compiling says go to hell” problems. Because sometimes the macro tells you one thing and actually trying to preprocess and link makes naughty hand gestures on the systems I encounter.
Finally, I’ve gotten around to sticking these in their own repo.
Which is much nicer than going: “Which project did I last update that in?”
Passing Thoughts: BIMF
Someday someone needs to create a build tool called BIMF: Build It Mother Fucker.
On occasion, I read (and see) things and am amused. The graphic at the end of this nVidia post on Vulkan Memory Management is a key example.