Rust, the language, has been moving ever deeper into infrastructure development. Rust is being used to write new code (see the drama going on within the Linux kernel developer community as an example). Rust is also being used to replace existing infrastructure, a prime example being the Rust Coreutils being written to replace the GNU Coreutils. The biggest draw to use Rust is its promise of safer memory usage compared to either C or C++ (and yes, they are separate languages and should not be called C/C++). Another draw appears to be better performance between equivalent versions of the same tools, with the performance lead going to the Rust-based rewrites. The biggest draw is that it’s fired up the imaginations of a new generation (if you will) of software developers. It’s all good, even for a very old dog such as myself.

An important re-write in, or migration to, Rust is the fish shell. The fish development team announced in 2024 that they would be migrating to Rust with the version 4 release of fish in 2025. They’ve now reached the point where they announced their first beta release of the shell. I cloned their Github repository and quickly compiled a local copy of the beta release to experiment with. So far, based on my admittedly limited testing, they’ve done an excellent job. Being a beta release I’m sure there are obscure corner cases where this new and major port will have some bugs, but for day-to-day use, so far, the Rust-based beta is indistinguishable from the older C++-based release.

Links

fish — https://fishshell.com

fish on github — https://github.com/fish-shell/fish-shell/

I re-installed System 76’s Cosmic Desktop Alpha 2 into a virtual machine tonight. I know I was a little harsh about Alpha 1, and accused the system of not properly handling keyboard input. It turns out that the problem was actually with QEMU/KVM itself, because the keyboard input problem affected all the virtual machines I have installed on this system. That problem seems to have mysteriously fixed itself (probably with an update), so that keyboard input is acting normal again.

I’ve managed to install Hack Nerd Fonts and the PowerLine packages for both the bash shell as well as vim. I also grabbed and installed fastfetch from the fastfetch git repo. You’ll note that fastfetch shows the desktop is Cosmic under the Wayland graphics subsystem. The overall Cosmic desktop environment alpha 2 has shown solid improvement over alpha 1. I won’t go over any specifics as there’s already plenty written on this releases new and improved features. Rather this is a personal validation of the glowing praise I’ve read so far. It does live up to the praise it’s receiving right now.

Is it good enough to use as a daily driver? For me, not yet. For anyone else, that’s something they’re going to have to determine on a case-by-case basis. Even if it is an alpha, it’s good enough to begin that consideration for many.

Rust 1.78 is available for this platform, so we’ll build Deno from its sources via Rust.

First, if you haven’t already, install Rust following the very simple directions on the Rust website ( https://www.rust-lang.org/learn/get-started ). Be advised that you’ll need to install curl and protobuf-compiler; the first to handle the installation of Rust, and the second to handle the build of deno. You should install these two packages before installing Rust and then using Rust to build deno.

After installing the two packages mentioned earlier and then installing Rust, perform cargo install deno and then go away for about 45 minutes until it’s done.

Why do it this way? First because you should install Rust, and install it locally to your login account, not globally. Second, because once again if you use apt to install rust, you only get version 1.74, not the current 1.78 stable release. When you install rust using the website’s method, you also get rustup, which allows you to keep your copy of Rust up-to-date. And if you want to do any kernel development you’ll need an up-to-date kernel (which you do have) and versions of Rust greater than or equal to version 1.77. Third, when you build deno yourself you get a whole slew of Rust crates that you can tinker with in other projects. Finally, you should use deno over node.js because the same creator of node, Ryan Dahl, is also the creator of deno; deno is far more robust and secure than node.js.

Finally, to learn more about deno and how to use it, go to https://docs.deno.com/runtime/manual and have at it.

I have been working with Rust for a few years now, primarily during my retirement. I’ve authored a few personal tools with it, and I’ve come to prefer working with it rather than the latest C++ compilers from GCC or Clang/LLVM. I find it expressive in ways that C++ isn’t. But Rust, like C++, isn’t perfect and it does have its quirks.

One of those quirks I first encountered involved an easy way to access elements in the Cargo.toml file within the Rust application itself. As I moved deeper into Rust I turned to a number of books on the language. One of those books showed how Rust worked by re-writing certain Unix/Linux command line tools in Rust. A subset of that book was command line argument processing, such as passing a version flag to the utility to check the version of the tool. I quickly noticed that the example Rust code duplicated information that was also defined in the toml file, such as the application’s name, version, author(s), and description. From decades of prior software experience the last thing you want to do is duplicate information/data between different files. Instead you want to define data in one location, in one file, and then reference that everywhere in the application and system where you need it. After a bit of searching I found one way to reference that toml information; see listing 1 above referencing the first four definitions in listing 2’s [package] section.

There’s probably a better way to reference toml information, but I used Rust’s built-in environment macros to reference this data because I learned that when you run a Rust application, that toml information is placed in the running Rust application’s environment as environmental variables. For me this is good enough.

By the way, this post marks my use of the Visual Studio Code plugin CodeSnap to create a visual snapshot of code. I’ve grown tired of trying to use WordPress’ built-in code support. The reference page for how to use it has disappeared, and even when I have used it, I can’t get decent code syntax highlighting. So this is probably what I’ll use from now on.

Links

Rust Environmental Variables — https://doc.rust-lang.org/cargo/reference/environment-variables.html

Environment: Ubuntu 23.10 on a Raspberry Pi 5 8 GiB with the full Rust toolchain installed.

I’ve been exploring the world of Rust recently. Rust isn’t just a language, it also seems to be an environment for nurturing interesting creativity. I’ve been working with products of that Rust-inspired creativity: zellij, bat, and dust.

zellij ( https://zellij.dev/ ) is an alternative to tmux ( https://github.com/tmux/tmux/wiki ). I’ve begun to use it here, with nvim, as a very lightweight alternative to full blown Visual Studio Code for rust development. I can also use it to quickly cobble together a set of views in one terminal to keep track of multiple tools looking at a wide range of system statuses. Having it all fit in multiple zellij panes is easier on the resources than having multiple independent terminals I have to keep track of on the desktop. I personally find zellij easier to use than tmux. In the first screen capture, I’ve got neofetch, btop, and duf in three individual panes in a single terminal instance. Installation is cargo install zellij.

I’m contrasting bat ( https://github.com/sharkdp/bat ) with nvim to show how close, yet how different they are visually. I prefer bat over cat, and have cat aliased to bat in my environment. Sometimes all I want to do is just read a text file, and bat does it so well. Installation is cargo install bat.

Finally there’s the Rust version of du, dust ( https://github.com/bootandy/dust )With dust I get a much clearer view of disk usage at any point in the filesystem. Regular du only provides byte sizes, while dust gives you a relative size graph to the right and a partial tree along with the space usage in each branch of the tree. And dust is fast. It’s the fastest utility of its type I’ve ever used. I won’t say it’s fast because of Rust, but probably a combination of clever design, coding, and Rust. Installation is cargo install du-dust.

I’m no Rust language expert. But I am growing to appreciate it as a personal tool builder as well as the foundation for excellent command line tools. I am exploring more every day as I grow to trust the current batch I’ve got installed on all my systems, both Linux and macOS.

It’s been a while since I built Deno via Rust’s cargo. Once it’s installed you can run deno upgrade and it will pull down the latest release and install it for you. That works pretty well for any supported environment, unless you’re using Ubuntu 23.10 on a Raspberry Pi 5. If you try to install Deno the officially documented way, you get the following:

Error: Official Deno builds for Linux aarch64 are not available.

Which means you’re going to build it from source. Fortunately Rust is available for this environment or else this post wouldn’t be here.

While building Deno I did run into one significant problem. The build failed right in the middle:

A little bit of search led me to install protoc via sudo apt install protobuf-compiler. Once installed I followed the directions about setting CARGO_TARGET_DIR and restarted the build, which then went on to build successfully. I checked for life:

$ which deno/home/pi/.cargo/bin/deno$ deno --versiondeno 1.40.2 (release, aarch64-unknown-linux-gnu)v8 12.1.285.6typescript 5.3.3

And now I’m the proud “owner” of Deno on this Raspberry Pi 5. By the way, if you want to see how the Raspberry Pi handled the task, here’s a taste of it via btop:

You’ll note that all four cores on the processor are running 100%, yet the temperature was around 60°C. This shows how well the active cooling is working on the Raspberry Pi 5.

I have moved away from Node to Deno in part because I can clone the entire Deno source tree and play around in it, and in part because over time I’ve grown tired of Node and its various peculiarities. I can do this because I’m retired, but if I ever decided to venture out back into the world I sincerely doubt that my Deno skills would be consider an asset; the world seems to run overwhelmingly on Node.

While I was tinkering with Deno I kept wondering where its name came from. As I sat staring at the screen, I noticed that Deno has the same four letters as Node, and that Deno is spelled in alphabetical order. That’s when I suddenly tried this:

Both Node and Deno will evaluate the same JavaScript function on the command line, which is: split the string ‘node’ into a list of individual ASCII characters, sort the list, then join the sorted list back into a string. I have no idea if this is what Ryan Dahl did, but it seems a simple enough thing to do.

Embedded development goes back as far as regular computing, at least to when the first mini-computers were released, because mini-computers were small enough and inexpensive enough (relative to mainframes) to be purposed towards specific tasks and then left alone to run unattended. As the computers continued to shrink in size and grow in capability, embedded system design leveraged those advances, including when Ethernet first showed up on systems. Why networked embedded systems suddenly became the Internet of Things makes no sense, considering that networked embedded systems began to appear when DEC (Digital Equipment Corporation) began to ship VAXen with DECnet Phase IV, going back to the early 1980s. While VAXen were rather large, there were microVAXes and smaller PDP-11/44s in particular that wound up in unattended control systems.

The real advances began with VME (1979) and other “big board” systems. As for me, the really interesting and affordable evolution began with PC/104 in the early 1990s. Boards got a lot smaller and more capable, while older designs kept getting cheaper. That evolution continued relentlessly until today, when I can go onto Amazon or Adafruit and purchase single board computers about the size of a pack of chewing gum with embedded 32-bit SoCs for anywhere from US$4 up to around US$25. Today I work with Raspberry Pi Picos as well as a number of Espressif ESP32-S3 and ESP32-C3 developer boards.

What’s key about these little boards is how they communicate with personal computers. They’ve standardized on using USB as the method for communicating with a host computer. All of my boards show up on my systems (macOS, Linux, and Windows) as a terminal device. For example, on Linux one of the devices might show up as /dev/ttyACM0, another as /dev/ttyUSB0, and so forth. I need to know the device ID so I can open up those devices and work with them, whether I’m using something like screen, or programming tools such as Thonny or the Arduino IDE.

Life is simple when you only have one device plugged in. It’s real obvious what the device is. Life gets more complicated when you have more than one. At one time I had eight plugged in and running, and I can assure you that trying to keep them all straight came to be a challenge. To start I wrote a very small bit of shell script to search for any and all connected boards:

alias devices='ll /dev/tty[A,U]*'

When I typed devices at a shell prompt, I’d get the following:

crw-rw---- 1 root dialout 166, 0 Dec 31 17:27 /dev/ttyACM0crw-rw---- 1 root dialout 188, 0 Dec 21 21:00 /dev/ttyUSB0crw-rw---- 1 root dialout 188, 1 Dec 23 11:37 /dev/ttyUSB1crw-rw---- 1 root dialout 188, 2 Dec 21 21:00 /dev/ttyUSB2crw-rw---- 1 root dialout 188, 3 Dec 25 20:06 /dev/ttyUSB3

Looks good, except for one small problem. What is actually attached to each port? I know through experience that the ACM0 port is connected to a Raspberry Pi Pico W. The other four are Espressif ESP32 developer boards. The Pico is running CircuitPython 8 beta 6. The ESP32 developer boards are running diverse software loads, only one of which is Micropython, while the other three are C++ applications I’ve compiled with the ESP-IDF and flashed on the various boards. So I decided to document which boards were on which port in a small spreadsheet. Worked good until one day, when I’d unplugged one of the boards to add some components to it, Duke Energy decided to drop power to the house. When power returned and I plugged the developer board back in, all the Espressive ports had been scrambled. What used to be on USB0 was on USB2, USB1 had dropped down to USB0, etc, etc. So I went looking deeper into the Linux kernel and how it manages serial devices, and learned that all those USB devices were listed down /dev/serial/by-id. So here’s what a full directory listing looks like:

lrwxrwxrwx 1 root root 13 Dec 31 17:27 usb-Raspberry_Pi_Pico_W_E6614C311B633831-if00 -> ../../ttyACM0lrwxrwxrwx 1 root root 13 Dec 21 21:00 usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_7eab1642dbfaeb1198773ca4c6d924ec-if00-port0 -> ../../ttyUSB2lrwxrwxrwx 1 root root 13 Dec 21 21:00 usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_8698c1b85519ec11982039bff95a09b1-if00-port0 -> ../../ttyUSB3lrwxrwxrwx 1 root root 13 Dec 23 11:37 usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_d0ed30374c18ec1199b543103803ea95-if00-port0 -> ../../ttyUSB1lrwxrwxrwx 1 root root 13 Dec 21 21:00 usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_e08d862b0867ec118f12a17089640db2-if00-port0 -> ../../ttyUSB0

Note that those are symlinks to the devices. So now I had an idea for a utility to write.

I’ve spent the last few weeks tinkering with three different languages to create a small utility to list the information out of /dev/serial/by-id, and process the output as strings to list in a cleaner way. I also wanted to get that information to create some simple data structures, especially the long hexadecimal ID which does not change. The terminal devices may change, but the hex IDs remain the same.

Here’s the first utility I wrote in Python. Took me about an hour of tinkering (where I was interrupted by Life a few times; remember I’m retired and this is supposed to be a hobby).

#!/bin/env python3import os, reDEVICE_PATH = '/dev/serial/by-id/'devices = {}for device in os.listdir(DEVICE_PATH):link_name = os.path.basename(os.readlink(DEVICE_PATH + device))re_result = re.search(r'_[0-9A-Fa-f]+-', device)interface_name = device.split(re_result[0])[0].replace('usb-','').replace('_',' ')hex_str = re_result[0].lstrip('_').rstrip('-')item = [interface_name, hex_str]devices[link_name] = itemfor device in sorted(devices.keys()):values = devices[device]print("{}, {}, {}".format(device, values[0], values[1]))

And here’s the output it produces when it’s run on my system.

ttyACM0, Raspberry Pi Pico W, E6614C311B633831ttyUSB0, Silicon Labs CP2102N USB to UART Bridge Controller, e08d862b0867ec118f12a17089640db2ttyUSB1, Silicon Labs CP2102N USB to UART Bridge Controller, d0ed30374c18ec1199b543103803ea95ttyUSB2, Silicon Labs CP2102N USB to UART Bridge Controller, 7eab1642dbfaeb1198773ca4c6d924ecttyUSB3, Silicon Labs CP2102N USB to UART Bridge Controller, 8698c1b85519ec11982039bff95a09b1

You can see how I reordered the data as well as cleaned up the device names by replacing all the underscores with white space. I’m not about to present this little Python utility as perfect idiomatic Python. I’m not interested in being called out over how this or that isn’t truly Pythonic. Python is, for me, a very easy prototyping language, a tool to make tools.

Having created a tool to give me the gist of what I wanted, I could have gone further in Python and added more features. Instead, I decided to implement the same functionality in C++ and Rust. Let it be known that I was going to implement it first in Rust and then C++, but I ran into so may problems trying to research what was Rust’s “simple” way to manipulate strings that I gave up in frustration and turned to C++. Here’s the C++ equivalent.

#include <string>#include <array>#include <map>#include <algorithm>#include <iostream>#include <filesystem>#include <regex>using std::string;using std::replace;using std::cout;using std::filesystem::directory_iterator;using std::filesystem::path;using std::filesystem::read_symlink;using std::regex;using std::regex_search;using std::smatch;using std::map;using std::array;using std::pair;void split(const string &subj, const regex &rgx, array<string, 2> &vars) {  smatch match;  regex_search(subj, match, rgx);  vars[0] = subj.substr(0, match.position(0));  replace(vars[0].begin(), vars[0].end(), '_', ' ');  vars[1] = match.str(0).erase(0,1);  vars[1].erase(vars[1].end()-1);}int main() {  const string DEVICE_PATH{"/dev/serial/by-id/"};  map<string, array<string,2>> devices;  regex hregex{"_[0-9A-Fa-f]+-"};  for (const auto &entry : directory_iterator(DEVICE_PATH)) {if (entry.is_symlink()) {  string slink = read_symlink(entry).stem().generic_string();  string sname = entry.path().stem().generic_string().erase(0,4);  array<string, 2> results;  split(sname, hregex, results);  devices[slink] = results;}  }  for (auto [device, values] : devices) {cout << device << ", " << values[0] << ", " << values[1] << "\n";  }  return 0;}

Lots of C++ code. Considerably many more lines of C++ than Python. If you’re going to get shocked about how much longer it is, don’t. To start with, there’s 11 lines of book keeping code (lines 9 to 20) that I prefer to use instead of a blanket using std that I’ve seen at the beginning of too much C++ source code. So I create a list of explicit usings in order to explicitly list everything individually. I have never cared for C++’s namespace notation, so explicit listing is a compromise for me. When run it produces the same results as the Python version.

One appreciated C++ map container feature is that the entries are stored pre-sorted. When I read them out I don’t have to explicitly pull out the keys, sort them, and then read the values from the map using the sorted keys.

Now we come to the Rust version. Let’s list it out for all to see.

use std::io;use std::fs;use regex::Regex;use std::collections::HashMap;fn main() -> io::Result<()> {const DEVICE_PATH : &str = "/dev/serial/by-id/";let hregex = Regex::new("_[0-9A-Fa-f]+-").unwrap();let trimchars: &[_] = &['_', '-', '.', '/'];let mut devices: HashMap<String, [String; 2]> = HashMap::new();for entry in fs::read_dir(DEVICE_PATH)? {// Split the extraction of file_name from path.// Combine the two, as you might naturally think to do in// another language, and you'll generate an error saying that// entry.path() creates a temporary that is freed while still// in use, meaning down the chain after the call to path().// This is a bug, not a feature.//let path = entry?.path();let device = path.read_link().unwrap();let device = device.to_str().unwrap().trim_matches(trimchars);// To give credit where credit is due:// Question: How do I print an OsStr without the quotes?// https://stackoverflow.com/questions/70266860/how-do-i-print-an-osstr-without-the-quotes// Who would have thought this was the answer to how// to extract the string from the file name?//let filename = path.file_name().unwrap().to_str().unwrap();let filename = filename.trim_start_matches("usb-");let caps = hregex.captures(filename).unwrap();let mut hexval = caps.get(0).unwrap().as_str();hexval = hexval.trim_matches(trimchars);let mat = hregex.find(filename).unwrap();let filename = filename.split_at(mat.start()).0;let filename = filename.replace("_", " ");devices.insert(device.to_owned(),   [filename.to_owned(), hexval.to_owned()]);}let mut sorted: Vec<_> = devices.iter().collect();sorted.sort_by_key(|a| a.0);for (device, values) in sorted.iter() {println!("{}, {}, {}", device, values[0], values[1]);}Ok(())}

The shine has gone off Rust (no pun intended), at least for me. I got caught up in the hype, but this little exercise (and it is a little exercise) has pretty much sand blasted that away. It took me about an hour to write the Python version of this utility, and then a day for the C++ version. It took me nearly a week to learn everything I needed to write it in rust, even though the number of source lines is about half-way between the Python version and the C++ version. Why?

1. Rust is constantly evolving, which isn’t necessarily a bad thing. It gets bad, if not worse, because the documentation and examples aren’t keeping up with the evolution. For example, see the declaration of the HashMap on line 10. The documentation says that all I have to do is declare just the HashMap, and that the compiler will determine the necessary types for the HashMap when you perform an insert into the HashMap. Nope. I had to explicitly declare it with the key and values to get it to compile. This is just one of many little documentation gotchas I kept running into.
2. I don’t know who came up with the design, but having to get the string value for a directory path by using “.unwrap().to_string().unwrap()” is all sorts of wrong. I left a comment right above that section of code, along to where I found a solution for it. Other languages manage to offer a simple convenience function, usually called to_string() or toString(), that will return the string representation of the class or structure. But not in Rust, it would appear.
3. Function chaining is a powerful feature, supported by all languages I know of. Unfortunately it doesn’t work all the time for Rust. The Rust designer(s) seem obsessed with “ownership” above all else, which seems to break the expected feature of function chaining. Start reading my comment from line 13 on down to the code. This fits in with (2) above, it would seem.
4. The odd difference between tuple indexing (.#) vs regular indexing ([#]). I used both, and I still don’t know why I couldn’t use just one indexing form throughout.

I will say that I appreciate some of the string manipulation functions, such as trim_matches(…) … once you get a string out to work with. Sorting a map’s keys and then reading out the (key, value) pairs is a bit odd (line 42).

At this point I think I’ll stick with Python and C++ (using the C++17 and C++20 standards), and let Rust continue to evolve for a while. Right now, as far as I’m concerned, Rust looks to be little more than C++ poorly implemented.

The Commodore 64, or C64 from here on out, was worth every penny. I had enough money left in my budget to purchase one Commodore 1541 floppy disk drive to go along with the C64. It was either that or else use a cassette tape recorder, and I’d come to absolutely loathe using cassettes for external storage due to my exposure to them with the TI 99/4a. If I’d tried to purchase the functional equivalent in Apple hardware it would have set me back between two and three times as much as I spent on Commodore equipment.

I didn’t purchase my C64 for games. I purchased it to act as a development system for other 6502-based DIY computer designs. To support development I wire-wrapped an external expansion board for my C64 that would program EPROMs and implement a real serial RS-232 interface. That board consisted of two MOS 6522 Versatile Interface Adapters (VIA) and an MOS 6551 Asynchronous Communications Interface Adapter (ACIA). I used an ACIA because I was absolutely horrified by the bit-banging the C64 used to do serial communications; the ACIA guaranteed serial communications to at least 19.2 kbits/s. While I started utility programming with the built-in C64 Basic, I quickly transitioned to a 6502 macro assembler for both utility tools native to the C64, and then later to do programming for my other 6502 DIY designs.

I purchased my C64 and 1541 in March of 1982. By the end of that summer I’d finished my C64 expansion board for programming EPROMs and had begun to development on the board you see below.

The design you see now is what’s left of a five year on-and-off evolution, before I stopped to work on other paying designs and began to pull parts off that board to support those paying designs. At the height of its operational glory my 6502 board had two RS-232 serial ports, 48K of static RAM, and space for 11K of EPROM. There’s 1K of the address space set aside for all the peripheral chips on the board. Before I explain how I did that, let’s go through a list of the components on the board.

• W65C802P-4 — A Western Design Center 65C802 at 4 MHz. This chip replaced the original NMOS chip I started with back in 1982. The manufacture date is 8542, so this chip was made in 1985, which fits with the time I purchased and installed it on the board. It was my intention with the original board to push the CPU clock as much as I could. I never went any faster than 4 MHz.
• R65C22P2 — A Rockwell 65C22 VIA chip. I swapped this in for the original MOS device to correct a logic bug with the original MOS 6522.
• WD1770 — A Western Digital single-chip floppy disk controller. The disk interface connector is on the far left edge. I managed to write 6502 assembly routines that could read and write MS-DOS formatted 3.5″ 720K floppy disks. The VIAs above the 1770 provided additional drive selection and control. I pulled the 1770 for another project where I built a stand-alone prototype 3.5″ floppy controller board using a Motorola 68HC11 micro controller for a customer.
• SCC2692 — A Signetics Dual Asynchronous Receiver/Transmitter, or DUART. It replaced an MOS 6551 ACIA. It came with two serial channels with on-chip ring buffers that could go up to 115 kbit/s. There were also some GPIO pins as well on the chip.
• HM6264 — An Hitachi Memory 6264 organized as 8k x 8. I had six to start with that ran contiguously from 0x0000 to 0xBFFF.
• DS1225 — Dallas Semiconductor 1225 non-volatile memory organized as 8k x 8. I used two to replace the Hitachis from 0x8000 to 0xBFFF. The monitor I’d written would take S-record files from the RS-232 port, convert them to binary, and store them at the starting address defined in each S-record. I used those to store my version of Commodore Basic I’d disassembled to source from the C64. Once the source was assembling to matching binary in the C64, I modified the source to call my hardware I/O routines, and was able to program my board in C64 Basic.
• TBP28L22 — Texas Instruments TBP28L22 programmable read-only memory organized as 256 x 8. I programmed a bit pattern that would produce a single high bit output dependent on the address input. It was my I/O device address decoder. The three highest address bits of the 6502 were decoded with a 74F139, giving me 8 x 8K regions. The 28L22 decoded all the I/O on the lowest seven output bits, with the highest bit being the final address decode for an EPROM that started at address 0xD000.
• HN462532 — Hitachi HN462532 EPROM organized as 4K x 8. I originally had four but pulled one for another project. The highest 8K was the full monitor and DOS, while additional applications were in the 7K that started at 0xD000. I’d intended to program my hacked C64 Basic into that 7K area, but never got around to it.

As I wrote earlier, all of this was started back in 1982. According to what notes I still have, I stopped completely around early 1988. My C64 along with my hand-built EPROM programmer was stolen Christmas 1984 while my wife and I were living in a rental in downtown Orlando. I’d gone out of town on business and my wife drove up to see her mother in Ocala. I eventually rebuilt my 6502 programming environment around a DEC Rainbow under MS-DOS. I purchased a commercial EPROM programmer which I used for nearly a decade and now sits on a closet shelf (how I wound up with a DEC Rainbow is a story for another time).

At this point in my life I’m still building embedded systems, but instead of a 4 MHz 8-bit microprocessor I’m working with ARM, Tensilica, and RISC-V 32- and 64-bit embedded MCUs running at hundreds of MHz; instead of EPROMS all of my development boards come with megabytes of reprogrammable FLASH and megabytes of external SRAM. And instead of assembly, I’m programming them in Micro/Circuit Python, C/C++, and Rust. Each MCU comes equipped with I/O, timers, ADCs and DACs, and so much more. I’m glad for my 6502 experiences from the 1980s, but I have absolutely no desire to try and bring any of that back up again. In 1982 I’d have given my right arm to have 1/10 the capabilities I currently have with today’s low-cost boards, which run from $4 for the M0/RP2040-based boards to $10 for RISC-V-based boards, to $20 for the dual core LX7-based boards and M7-based boards.

There is no going back for me, technically nor romantically.

If you’re interested in Rust and Python like I am, then you may reach a point where the two combine. In this instance I wanted to see if anyone was attempting to implement the Python language interpreter in Rust, and after a quick search, I found the project RustPython on Github ( https://github.com/RustPython/RustPython ).

I cloned a local copy of the source to my Windows 10 Pro itty bitty computer (a Minis Forum UM250 with an AMD Ryzen 5 quad-core CPU, 16GiB, 512GiB SSD). I also have Rust 1.55.0, the current latest release, installed. I followed the directions on the README and it compiled without errors. Unfortunately when it tried to execute it crashed out complaining it couldn’t find ‘encodings,’ and did I have RUSTPYTHONPATH defined. The RUSTPYTHONPATH message stopped me for a moment, as there was nothing in the readme about it. A quick search on Google found the solution.

So, here’s what I’ve discovered so far on Windows 10:

• You need to set $RUSTPYTHONPATH to the full path to the project’s Lib directory. On my machine I do all my work in C:\Develop, and I have cloned Rust Python into C:\Develop\Rust\RustPython. The Lib folder is thus C:\Develop\Rust\RustPython\Lib, and I execute $env:RUSTPYTHONPATH=C:\Develop\Rust\RustPython\Lib. A quick alternative is to cd into the Lib folder and execute $env:RUSTPYTHONPATH=$PWD from the command line if all you want to do is test within that window.
• The README says to execute cargo with the release flag to avoid crashing out due to stack overflow. You don’t need to do that anymore. I accidentally forgot to include the release flag in one run, and Rust dutifully built the debug version and ran it without incident.

I’m very impressed with this Rust implementation of Python. I’m no Python expert, but it has so far run a number of my scripts correctly. I am trying to determine how I might meaningfully contribute to the project. I doubt I could write decent Rust source for them, so I may just be on the sidelines watching. I just hope that this project continues on and doesn’t die a slow death like many other past open source projects that showed promise.

I’m dipping back into my past Flickr photos and pulling one out to talk about it. This is the first of I don’t know how many, but there may be a few. I’m doing this because I got pulled into looking at my past work, and discovering that I still liked what I had produced 10 years ago.

This photo was taken December 2011 of a three-year-old Ruby on the left and her companion, eleven-year-old Max on the right. Max left us in 2015, after a long and robust fifteen years with us (he was rescued by us in January 2000, and he was already six months old at the time). The story behind this photo is that I had a very rough night and had crashed out on the old La-Z-Boy sofa in the TV room so I wouldn’t bother my wife. The Labs, of course, saw an opportunity to spend that night with one of their favorite persons, so they wound up sleeping right up there with me. When I got up in the morning, they stayed up on the sofa, picking spots comfortable to them. When I came back in there they both sat. Fortunately I had a camera close to hand to capture this moment.

I just like the composition. Both of them are exuding personality, especially Max. It reminds me how much I’ve missed him these past six years. Ruby is still with us, and she’s still my sweatie.

The camera used is the Olympus E-P2, with its ‘mere’ 12MP sensor, along with the m.Zuiko 2.8/17mm. This was during my ‘dark black-and-white’ period, where I was post-processing the hell out of everything because I thought it would look more artistic that way. The only saving grace is that I used a sepia tone which helped to bring up the highlights a bit and added a bit of texture to their coats.

I’ve been wrestling with building Deno on my Jetson Xavier NX running Nvidia’s version of Ubuntu 18.04.2 as part of L4T, or Linux For Tegra (although I tend to think of ‘T’ for Tensorflow). Deno is a reimplementation, if you will, of NodeJS in Rust, attempting to correct many of the bad design decisions that went into Node over time. Deno was created by Ryan Dahl, the original creator of NodeJS, so he should know where the skeletons of Node are buried.

The problem with installing and working with Deno on the Xavier is that it’s Arm-based, whereas all the other environments are x86-based. You can thus download and update (deno upgrade) Deno natively, whereas on the Xavier you need to install a native distribution of Rust, then build deno on the platform with cargo build deno. This worked for all of deno versions up to 1.6.7, then 1.7 was released and building deno on Arm failed repeatedly due to a failure to build librusty_v8. I filed a bug report over two weeks ago, and then, three days ago, I got a response from one of the devs telling me that there was “no pre-built 0.17.0 static library for aarch64 but there is one if you upgrade to 0.20.0.” Sure enough, when I re-ran cargo build deno and watched the task pull and build all the libraries, it pulled librusty_v8 version 0.20.0, which successfully built along with everything else. I have since closed the bug (see https://github.com/denoland/rusty_v8/issues/630 ).

The big draw for me is Deno’s experimental support for WebGPU API. I ran the example given in the release notes ( https://deno.land/posts/v1.8 ) and copied the results into the top of this post. I doubt that JavaScript running on Deno will replace Python as the front-end for ML running on the Jetson Xavier, but I can see it supporting Python, especially with web-based development. I am no fan of Python’s web frameworks, and I’ve lost my disdain for JavaScript over the past 12 months due to another task that showed I could use minimal JavaScript to cleanly solve a knotty problem. Deno also gives me plenty of powerful examples of programming in Rust, so there’s that angle.

Since retirement I’ve explored more interesting languages and their uses than I ever did in the last five years of my regular employment. It wasn’t so much ageism as it was my employer’s adamant insistence that development was their way or the highway. I’m now free to follow my own path(s) and finding what I’m learning to be new, interesting, and challenging in a good way.