The Boston Diaries

Thursday, Debtember 13, 2018

This reminder is to remind you of the reminder

So I received this in email today:

From

Chevrolet <XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX>

To

sean@conman.org

Subject

Sean, employee pricing is back on most Chevy cars, trucks and SUVs

Date

Thu, 13 Dec 2018 17:11:46 -0800 (PST)

This is plain text, with a line break:
Next new line

And the thing that I immediately thought of were old IBM manuals that would have a page with the following text:

This page intentionally left blank.

No it's not. It should have read:

This page intentionally left blank, except for this line of text.

At least this email from Chevrolet is more accurate than the old IBM manuals. But then again, I wonder what Chevrolet was trying to sell me.

I changed the image on my homepage. Normally, I wouldn't comment on this, but this time? This time I had to track down a sixteen year old bug in code I wrote in a language that makes COBOL look terse that manages the non-bloggish part of the website. All because I broke from twenty-one years of tradition and used a different image size! (It's a really good picture a friend took and it really benefits from the non-traditional size)

I had thought the code I wrote would deal with the non-traditional size and yes, it picked up on the new size, but that size was then used for every self-portrait on the site.

It's also been ten years since I last dealt with the code, and even then, it was just to get it running under a newer version of the language. This time, I had to figure out what the hell I was doing sixteen years ago. From various timestamps, I can tell it only took about an hour to track down the bug and fix it (eight new lines of code, mostly under 140 characters in length—sigh) but it certainly felt longer.

This is one of those situations where the language is ugly, the solution aggravating to maintain and yet, it works, and for what I want it's still the best solution to the problem of maintaining a static website.

Sigh.

Hopefully, I can go another ten years before the next bug manifests itself.

Thoughts at the edge of boredom

Years ago in college, I worked in the auditorium as part of the stage crew and one of the many jobs was running the spot light during shows. There was one two hour show I worked where the spot light would only be used for about fifteen minutes about half-way through the show. This meant I had to sit next to the spot light for nearly an hour, do the fifteen minutes of work, then sit there for another hour until the show was over.

As I sat there waiting for my cue, my mind wandered. I'm about twenty to thirty feet above the audience, I thought. This platform is suspended from the ceiling and held into place with those four bolts. I wonder when was the last time they were checked? What would I do if they failed? Could I grab and hold onto something? What could I grab? What was that creak? Oh, part of the show, okay. How much does that spot light weigh? I sure hope these bolts hold for another 98 minutes …

I was reminded of this today as I sat in our daily, thrice-weekly standup scrum meeting. Our acting manager and a team leader from another team were going back and forth about an overscoped and time deficient schedule when my mind wandered again. Staring out the window, I was watching the sun behind a hazy layer of clouds. At our latitude, I thought, we're moving at 940 mph towards the east. The earth itself is moving at 67,000 mph around the sun, and the sun itself is moving our entire solar system at 514,000 mph. All of this is held together by the force of gravity, a force so weak that a kitchen magnet can overcome it. It's a wonder everything doesn't just fly apart. I sure hope those bolts hold for another— “Huh? What?”

“I asked what have you done in the past 48 hours since our last daily, thrice-weekly standup scrum meeting?”

“Oh, just pondering the ridiculous speed we're hurling through space as we're held together with four small bolts.”

“Are you okay, Sean?”

Thursday, Debtember 06, 2018

The process of our process is to process the process to ensure the process has processed the process

Bunny was helping me with my “self-review” since I was at a total loss of what to even say. “You aren't built for dealing with bureaucratic processes, are you?” she asked.

“No,” I said. “I'm not. I never have been. I remember back in fourth grade—”

“No! I don't want to hear it!”

“And then there was that time in middle school—”

“I'm not listening!”

“So I guess you don't want to hear about high school then?”

“La la la la la la la la la!”

Yeah, my rage against the bureaucratic process goes back a long time.

I mean, I understand that processes are at times required. There can be good reasons to have a process so everybody knows what to expect and get consistent results. But this “self-review” is just not one of them. I eventually spent over eight hours trying to say enough to avoid the “rejected due to cursory responses” (never mind them being “meaty enough” and I still don't know if I succeeded at it). And the weird thing is, the majority of the “goals” didn't even apply to what I do! They were more geared towards a manager than a programmer.

Sigh.

This is almost making me want to work with the Protocol Stack From Hell again.

Almost.

Wednesday, Debtember 05, 2018

Charlie Foxtrot is alive and well

It's been an interesting week, in the Chinese sense of “interesting.” First was the grueling deployment to production that ended at 6:00 am, followed by a mandatory all-day meeting starting at 11:00 am and that was just Tuesday! Today was another mandatory all-day meeting, followed by a trivial but show-stopping bug (read “rookie mistake” made by yours truly) being found in production and the subsequent six hours to get a patched version installed (it took less than 10 minutes to reproduce the bug, find the root cause, and fix it) because most of the operations team (who do the actual deployments) were flying back to The Corporation Headquarters in Seattle, having attended the said two-day mandatory meeting here at The Ft. Lauderdale Office of The Corporation.

Then my “self-review” (which was designed solely as some abstract HR process, despite the protestations of upper management of Our Corporate Overlords of the Corporation) was rejected as not being “meaty enough” (what ever that means) and I'm like … yeah … about that flair … (it only took Bunny two hours to talk some sense into me).

Monday, Debtember 03, 2018

It actually looks like one can construct a computer keyboard out of Lego and have it work

Last month I mentioned a Commodore-64 designed out of Lego. Back then, it was just a design, but now it actually exists! There are two keyboards—one where a real Commodore-64 keyboard has the keycaps swapped out for Lego keycaps, and the second keyboard is a fully mechanical Lego design.

I think it would be possible to use the pure Lego keyboard on a real computer, but it would probably require a custom PCB to handle the different mechanical action. Size wise, it's a perfect fit though. And boy, does it have that sweet clicky sound of a mechanical keyboard.

Friday, November 23, 2018

The Season of the Enlightened Trees

The day after Thanksgiving. It can mean only one thing—

[Santa is huge this time of year. No, really, he is. That tree next to him? It's easily a 10 foot Spruce tree.]

It's time to go out and buy a tree!

On the way back to Chez Boca, Bunny (who was driving) took a detour to see if The House On The Corner™ had swapped out their Thanksgiving display for their Christmas Extravaganza!

[``This one and then that and this and then still another, and on up and around, three lights here, seven lights still higher, a dozen clustered beyond, a hundred, five hundred, a thousand lights lit ... '']

They had. And that's just a small portion of the Christmas Extravaganza! Multiple homes are involved in this seasonal display of lights.

And of course they had the music! I wouldn't expect anything else.

Wednesday, November 21, 2018

A world of message-oriented programming languages

Ted Kaminski just asked, “What would a message-oriented programming language look like?” to which I answer, “any language with functions, which is to say, just about all computer languages.” Ted's answer is a bit different, but let me explain mine (and I've been meaning to write about this for fifteen years now—sigh).

Digression the First

In the programming language C, pointers and arrays are often conflated. They're declared differently:

int  array[10];
int *pointer_a;

But their use is similar:

int x = array[3];
int y = pointer_a[3]; // assuming pointer_a points to an array

I'm not going to go deep into the differences, but do note that array is a sequence of 10 integers, and pointer_a is the address of one or more integers.

Structures and pointers are not conflated to the same degree, mainly because they have different usage syntax (that I find annoying in my opinion):

struct foo
{
  int a;
  int b;
  int c;
};

struct foo  structure;
struct foo *pointer_s;

structure.a    = 3;

pointer_s->a   = 3; // assuming pointer_s points to a structure
  /* or */
*(pointer_s).a = 3; // assuming pointer_s points to a structure

The reason for the difference comes from very early C compilers where the fields in a structure declaration were considered offsets and not fields! So the following code:

struct foo
{
  int a;
  int b;
  int c;
};

struct bar
{
  char *x; // can't be a because that would conflict with above
  char *y; 
  char *z;
};

struct foo *pfoo; // assuming pfoo points somewhere valid

pfoo->a = 4;
pfoo->y = "hello";

was legal C code! Thankfully, it no longer is, but we still live with this in POSIX where field names for various structures all have a prefix, like struct stat { off_t st_size; ... } and struct timespec { time_t tv_sec; ... }.

Also, while nothing I see in the C standard seems to invalidate this assumption:

int array[3];

struct foo
{
  int a;
  int b;
  int c;
};

sizeof(array) == sizeof(struct foo);

it still seems like it goes against the standard to cast a pointer between the two types all willy-nilly. Just an observation.

Digression the Second

In C, you have arrays and structures. An array is a sequence of values of the same type, stored consecutively in memory. The individual elements are indexed by a number indicating its position in the array (C numbers the first element as 0; other languages such as Lua or Pascal start with 1).

A structure is a portion of memory with a particular layout of types. The individual elements are indexed by a name and appear in order, although not necessarily right next to each other (in other words, there may be what's called “padding” between fields of different types due to machine architecture restrictions). Then there's the concept known as a “tuple.” This is a cross between the array and structure. Like the structure, the individual elements may be of different types and sizes, but they are referenced like an array—an index into its position within the tuple. This is a type that doesn't exist in C, but it does exist in other, more dynamic languages like Python.

Digression the Third

My first real exposure to message passing as a concept was with the Amiga. It was your standard type of message passing, create or find a port, then you can send or receive messages. Messages themselves were a block of memory with a fixed header and a message-specific portion, and they could be sent synchronously (where the sending task was blocked waiting for a reply) or sent asynchronously (the message is sent, but the task continues to run, to possibly wait for a reply at a later time). Messages and message ports were used for all sorts of things on the Amiga, interacting with devices or the GUI, receiving signals, all sorts of stuff.

My second exposure to message passing was with QNX. Unlike the Amiga, there were no message ports—instead you passed messages to a given process. Messages themselves had no fixed structure, it was just a blob of memory being copied from one process space to another. And message passing was purely synchronous. You could do asynchronous message passing, but it required multiple threads to do so.

And it was here that I learned that neither one was more “primitive” than the other—you could always simulate one with the other.

Digression the Fourth

There are two orthogonal axes upon which you can implement message passing. The first axis is “synchronous/asynchronous”—is the task sending stopped or can it continue? The other axis is “reference/value”—does the task send a reference to the data or does it need to copy the data? In the case of QNX, it's a “synchronous, by-value” message passing paradigm. For the Amiga, it can send either synchronously and asynchronously, but in both cases, the data is sent by reference.

Digression the Fifth

Over the years I've programmed under a few windowing systems. Not much, but just enough to get a feeling for it. On the Amiga, you filled in a rather lengthy structure, then pass this to a function to open a new window.

On X Windows, you call one of two functions—one just takes a large number of paramters, the other one takes a large number of paramters, one of which is a rather lengthy structure.

I recall little of Windows and OS/2 (being way back in the early 90s) but I think they were a bit worse than X Windows—a large number of parameters, several of which were rather lengthy structures.

But for all of them, you sat in a so called “event loop”—waiting for events from the GUI, then went off and handle the message. On the Amiga, events were received from a message port. On X, it was a function that returned a structure representing the event. Windows and OS/2 you supplied a function that received four parameters that comprise the event—you were not in control of the main event loop.

Digression the Sixth

So a while back, I was studing the VAX architecture, like you do, when I came across the CALLG and CALLS instructions. Both are used to call a function. CALLG requires the address of the argument list to be passed in:

	<data section>
ARGLIST:	.LONG	2	; argument count
		.LONG	600	; first argument
		.LONG	84	; second argument

	<code section>

		CALLG	ARGLIST,FOOBAR

FOOBAR is called with two arguments. For the CALLS instruction, you push the arguments onto the stack:

	<code section>

		PUSHL	#84
		PUSHL	#600
		CALLS	#2,FOOBAR

Again, FOOBAR is called with two arguments. FOOBAR itself does not have to care how it was called—it receives a pointer to the argument list in register R12 (aka the AP register). It was then I had an epiphany.

The Epiphany

So, in the case of FOOBAR, one way of calling it could look like:

struct foobar_data
{
  int a;
  int b;
};

foobar_data fdata = { .a = 600 ; .b = 84 }
foobar(&foobar_data);

But another way of calling it could look like:

foobar(600,84);

Really, all CALLS is doing is initalizing a temporary structure whose fields are otherwise known as “parameters” and passing this structure to the operand, in this case FOOBAR. The parameter list to a function can be viewed as a structure. And all of the examples I've seen of message passing is just passing along data, usually structured as a structure (sorry) or a tuple (depending upon language).

And then the ephiphany! Calling a function with parameters is just another form of synchronous message passing, either by-reference or by-value (this is either an unusual or obvious thought, but it took me a while to reach it if it was obvious). That nasty Windows call to create a window? Just pass a really large structure or “message.” And that's really what's happening under the hood of X Windows—a message is being passed from the X client to the X server.

And this does leave me to wonder at times what the semantics of an asynchronous function call would (or could) be.

But yes, we already have message-oriented programming languages—if you squint the right way …