The Mandelbear's Musings

\begin{rant}

If you look at Done Since 2024-01-21 and scroll down to Friday (or search for "0126Fr"), you'll find an uncharacteristically-long log item that starts out "contact liberatormedical.com Customer Service"... followed by a series of '->' items. When you see this sort of thing, it's often a sign that Someone (or more likely some company) is WRONG on the Internet.

This has gotten long, so I'm putting it under a ( cut tag. )

\end{rant}

A rather mixed bag of things that, arguably, I should have written about a week ago.

1: the Let's Encrypt root certificate.

Hopefully this won't affect you, but if your browser starts complaining about websites suddenly being untrusted, you need to upgrade. The problem is that Let's Encrypt's root certificate is expiring, and will be replaced by a new one (see the link above for details). Starting October 1^st, browsers and other programs that rely on the old cert will have problems if they haven't been upgraded in the last year.

You keep your OS and your browser up to date, right? There are some old apps and operating systems that are no longer receiving upgrades, and so won't know about the new root cert. Specifically, if you're using one of these products:

OpenSSL <= 1.0.2, Windows < XP SP3, macOS < 10.12.1, iOS < 10 (iPhone 5 is the lowest model that can get to iOS 10), Android < 7.1.1 (but >= 2.3.6 will still mostly work), Mozilla Firefox < 50, Ubuntu < 16.04, Debian < 8, Java 8 < 8u141, Java 7 < 7u151, NSS < 3.26, Amazon FireOS (Silk Browser).

Possibly, Cyanogen > v10, Jolla Sailfish OS > v1.1.2.16, Kindle > v3.4.1, Blackberry >= 10.3.3, PS4 game console with firmware >= 5.00, IIS

(You can probably uptrade to the newest Firefox or switch to a recent version of Chrome, which will restore your ability to browse the web, but a few other things might still fail. (For example, Firefox will keep working on my ancient Mac Mini, but Safari probably won't.)

The following articles go into a lot more detail; you can get a good overview from the first two:

Smart TVs, fridges and light bulbs may stop working next year: Here's why An Internet of Trouble lies ahead as root certificates begin to expire en masse, warns security researcher • The Register The Impending Doom of Expiring Root CAs and Legacy Clients Let's Encrypt's Root Certificate is expiring! Certificate Compatibility - Let's Encrypt

2. Phillips Respironics CPAP recall:

If you're using a CPAP made by Phillips Respironics, hopefully you've already seen the Recall Notification [PDF]. I missed it, through my habit of ignoring notifications in the Dreamstation app and website. The email I got from Medicare says:

If you own or rent one of the Philips products that was recalled, talk to your doctor as soon as possible about whether to continue using your recalled equipment. If you would like to replace or repair your equipment, the supplier you bought the equipment from is responsible for replacing or repairing rental equipment at no cost to you when the equipment is less than 5 years old.

If, like me, you insist on continuing to use your facehugger, install an antibacterial filter, which will keep little bits of soundproofing foam out of your lungs. This is probably only necessary if you've been using ozone to clean your device, but I decided not to take chances.

3. Chevrolet Bolt EV recall:

If you own a Bolt, you should have received several letters about this recall. Hopefully you haven't been throwing them away unread, but if you have, you'll want to enable "hilltop reserve" to limit your charging to 90%, don't run your battery down below about 70 miles, park outside immediately after charging, and don't leave your Bolt charging indoors overnight. "Experts from GM and LG have identified the simultaneous presence of two rare manufacturing defects in the same battery cell as the root cause of battery fires in certain Chevrolet Bolt EVs." You don't want to take chances with battery fires. They're nasty; lithium is perfectly capable of burning under water.

Be safe out there.

On a more hopeful(? helpful, at least) note, dialecticdreamer has posted Demifiction: Breaking Omaha!, which despite being set in a fictional universe contains a lot of practical advice for disaster preparedness.

If you've been reading this journal for a while, you probably know that I've been taking singing lessons. (Comparatively few of you have heard me sing recently; those who have say that the improvement has been noticable.)

And even if you've only been reading for the last week, you'll know that I've been "socially distancing" myself -- I'm in a high-risk category due to my age, and not going out of the house for anything but medical appointments and food. Singing lessons aren't "essential", so I've stopped going -- and Nancy, my singing teacher, has a huge problem.

So I'm asking the lazy web for help finding a videoconferencing system that can be used for singing lessons. I want Nancy to be able to play something on a MIDI keyboard and hear me singing along with it. That would require suppressing the normal simultaneous monitoring on the teacher's end -- the MIDI should play only on my end, and get mixed with my voice at that point. But when Nancy is using her microphone, the return channel has to be muted. And if she wants to sing along with something she's playing, she needs to hear the keyboard at her end, without the round-trip delay.

I'm beginning to suspect that the only way to get all of this is to write it myself, but I'd love to be proved wrong. Meanwhile, I'd settle for something with extremely low transmission delay; that would mean point-to-point rather than going through a server.

And if any of you are giving lessons remotely, I'd love to hear what works for you.

Today the computer curmudgeon talks about how he blogs.

I think it's widely known that I update this journal (and by that I mean both my Dreamwidth journal, which you are probably reading now, and my Computer Curmudgeon website), using a rickety combination of shell scripts and makefiles called MakeStuff. There are several good reasons for that. (Whether "because I can" is a good reason or not is debatable. There are others.)

A little over a year ago I made a planning post, and the "Where I am now" section remains a pretty good, albeit sketchy, description of the process. There's also an even sketchier one in the README file for MakeStuff/blogging. It had a list of what I wanted to do next, but essentially the only thing I've actually done is posting in either HTML or Markdown.

I have, however, reorganized things a bit, so that all of the relevant scripts are in MakeStuff/blogging -- the last part was moving in the script, now called charm-wrapper, that takes the post's metadata out of its email-like header and turns it into a command line for charm, a livejournal/dreamwidth posting client written in Python. It isn't a very good solution, but it works.

And since I'm running out of time to make a post today, I'm going to start this series with the other utilities in MakeStuff/blogging. And then go add this list to the README.

• check-html is a simple wrapper for html-tidy, a popular HTML syntax checker. Since it's not actually being used to fix syntax, it can play fast-and-loose with things like the header (it's just text) and blog-specific tags like <cut> and <user>. It handles those by putting a space after the "<" character. It would be trivial to add this to the make recipe for post.
• last-post is a site-scraper that returns the URL of your most recent post. It's useful, because charm doesn't return it. (I eventually put that functionality into charm-wrapper, but it's still useful. Eventually it wants to take a date on the command line.
• word-count is what I use to generate the NaBloPoMo statistics at the bottom of posts in November. (In other months, you just get a straight list; you can also get a listing for a whole year.)

NaBloPoMo stats:
     43 2019/11/01--rabbit-rabbit-rabbit.html
   1731 2019/11/02--s4s-memorials.html
   1465 2019/11/03--done-since-1027.html
    145 2019/11/04--i-ought-to-post-something.html
    430 2019/11/05--how-to-makestuff.html
-------
   3814 words in 5 posts this month (average 762/post)
    430 words in 1 post today

Another fine post from The Computer Curmudgeon (also at computer-curmudgeon.com).
Donation buttons in profile.

Part 1: Blockchain

Blockchain is the technology behind Bitcoin and other cybercurrencies. That's about all anyone outside the software industry knows about it; that and the fact that lots of people are claiming that it's going to transform everything. (The financial industry, the Web, manufacturing supply chains, identity, the music industry, ... the list goes on.) If you happen to be in the software industry and have a moderately good idea of what blockchain is, how it works, and what it can and can't do, you may want to skip to Part 2.

Still with me? Here's the fifty-cent summary of blockchain. Blockchain is a distributed, immutable ledger. Buzzword is a buzzword buzzword buzzword? Blockchain is a chain of blocks? That's closer.

The purpose of a blockchain is to keep track of financial transactions (that's the "ledger" part) and other data by making them public (that's half of the "distributed" part), keeping them in blocks of data (that's the "block" part) that can't be changed (that's the "immutable" part, and it's a really good property for a ledger to have), are linked together by hashes (that's the "chain" part, and we'll get to what hashes are in a moment), with the integrity of that chain guaranteed by a large group of people (that's the other half of the "distributed" part) called "miners" (WTF?).

Let's start in the middle: how can we link blocks of data together so that they can't be changed? Let's start by making it so that any change to a block, or to the order of those blocks, can be detected. Then, the fact that everything is public makes the data impossible to change without that change being glaringly obvious. We do that with hashes.

A hash function is something that takes a large block of data and turns it into a very long sequence of bits (which we will sometimes refer to as a "number", because any whole number can be represented by a sequence of binary digits, and sometimes as a "hash", because the data has been chopped up and mashed together like the corned beef hash you had for breakfast). A good hash function has two important properties:

1. It's irreversible. Starting with a hash, it is effectively impossible to construct a block of data that will produce that hash. (It is significantly easier to construct two blocks with the same hash, which is why the security-conscious world moves to larger hashes from time to time.)
2. It's unpredictable. If two blocks of data differ anywhere, even by a single bit, their hashes will be completely different.

Those two together mean that if two blocks have the same hash, they contain the same data. If somebody sends you a block and a hash, you can compare the hash of the block and if it matches, you can be certain that the block hasn't been damaged or tampered with before it got to you. And if they also cryptographically sign that hash, you can be certain that they used the key that created that signature.

Now let's guarantee the integrity of the sequence of blocks by chaining them together. Every block in the chain contains the hash of the previous block. If block B follows block A in the chain, B's hash depends in part on the hash of block A. If a villain tries to insert a forged transaction into block A, its hash won't match the one in block B.

Now we get to the part that makes blockchain interesting: getting everyone to agree on which transactions go into the next block. This is done by publishing transactions where all of the miners can see them. The miners then get to work with shovels and pickaxes big fast computers, validating the transaction, putting it into a block, and then running a contest to see which of them gets to add their block to the chain and collect the associated reward. Winning the contest requires doing a lot of computation. It's been estimated that miners' computers collectively consume roughly the same amount of electricity as Ireland.

There's more to it, but that's blockchain in a nutshell. I am not going to say anything about what blockchain might be good for besides keeping track of virtual money -- that's a whole other rabbit hole that I'll save for another time. For now, the important thing is that blockchain is a system for keeping track of financial transactions by using a chain of blocks connected by hashes.

The need for miners to do work is what makes the virtual money they're mining valuable, and makes it possible for everyone to agree on who owns how much of it without anyone having to trust anyone else. It's all that work that makes it possible to detect cheating. It also makes it expensive and slow. The Ethereum blockchain can handle about ten transactions per second. Visa handles about 10,000.

Part 2: The other blockchain

Meanwhile, in another part of cyberspace, software developers are using another system based on hash chains to keep track of their software -- a distributed version control system called git. It's almost completely different, except for the way it uses hashes. How different? Well, for starters it's both free and fast, and you can use it at home. And it has nothing to do with money -- it's a version control system.

If you've been with me for a while, you've probably figured out that I'm extremely fond of git. This post is not an introduction to git for non-programmers -- I'm working on that. However, if you managed to get this far it does contain enough information to stand on its own,

Git doesn't use transactions and blocks; instead it uses "objects", but just like blocks each object is identified by its hash. Instead of keeping track of virtual money, it keeps track of files and their histories. And just as blockchain keeps a complete history of everyone's coins, git records the complete history of everyone's data.

Git uses several types of object, but the most fundamental one is called a "blob", and consists of a file, its size, and the word "blob". For example, here's how git idenifies one of my Songs for Saturday posts:

git hash-object 2019/01/05--s4s-welcome-to-acousticville.html
957259dd1e41936104f72f9a8c451df50b045c57

Everything you do with git starts with the git command. In this case we're using git hash-object and giving it the pathname of the file we want to hash. Hardly anyone needs to use the hash-object subcommand; it's used mainly for testing and the occasional demonstration.

Git handles a directory (you may know directories as "folders" if you aren't a programmer) by combining the names, metadata, and hashes of all of its contents into a type of object called a "tree", and taking the hash of the whole thing.

Here, by the way, is another place where git really differs from blockchain. In a blockchain, all the effort of mining goes into making sure that every block points to its one guaranteed-unique correct predecessor. In other words, the blocks form a chain. Files and directories form a tree, with the ordinary files as the leaves, and directories as branches. The directory at the top is called the root. Top? Top. For some reason software trees grow from the root down. After a while you get used to it.

Actually, that's not quite accurate, because git stores each object in exactly one place, and it's perfectly possible for the same file to be in two different directories. This can be very useful -- if you make a hundred copies of a file, git only has to store one of them. It's also inaccurate because trees, called Merkle Trees are used inside of blocks in a blockchain. But I digress.

Technically the hash links in both blockchains and git form a directed acyclic graph -- that means that the links all point in one direction, and there aren't any loops. In order to make a loop you'd have to predict the hash of some later block, and you just can't do that. I have another post about why this is a good thing.

And that brings us to the things that make git, git: commits. ("Commit" is used in the same sense, more or less, as it is in the phrase "commit something to memory", or "commit to a plan of action". It has very little to do with crime. Hashes are even more unique than fingerprints, and we all know what criminals think about fingerprints. In cryptography, the hash of a key is called its fingerprint.)

Anyway, when you're done making changes in a project, you type the command

git commit

... and git will make a new commit object which contains, among other things, the time and date, your name and email address, maybe your cryptographic signature, a brief description of what you did (git puts you into your favorite text editor so you can enter this if you didn't put it on the command line), the hash of the current root, and the hash of the previous commit. Just like a blockchain.

Unlike earlier version control systems, git never has to compare files; all it has to do is compare their hashes. This is fast -- git's hashes are only 20 bytes long, no matter how big the files are or how many are in a directory tree. And if the hashes of two trees are the same, git doesn't have to look at any of the blobs in those trees to know that they are all the same.

@ Blockchain 101 — only if you ‘know nothing’! – Hacker Noon @ When do you need blockchain? Decision models. – Sebastien Meunier @ Git - Git Objects @ git ready » how git stores your data @ Git/Internal structure - Wikibooks, open books for an open world @ Why Singly-Linked Lists Win* | Stephen Savitzky

Another fine post from The Computer Curmudgeon (also at computer-curmudgeon.com).

It's been a week. There were some good parts. Music Under the Trees, yesterday at Betsy Tinney's, was one of them, even if we did have to leave early because Colleen was flagging. (I didn't object, because to be honest I'd been dreading driving home in the dark after three nights of not enough sleep. But still.)

Another was getting the rest of the bed box installation done, which happened last Sunday. It's awesome. N got to try it out Saturday night; it was complete enough for sleeping in at that point.

A third good thing wa a very nice visit to the southern end of the Rainbow Caravan, to spend a day with N and the kids. We will get our household back together. It may take a while.

And I got a very preliminary version of my "Consulting business" website done, as a GitHub Pages site. Last week N and I had picked a theme: Read Only, by HTML5 Up. It's cool - big banner across the top of the text, and a neat circular image (which it turned out was masked out by setting the enclosing box's boundary radius to 100%). Only one problem.

GitHub Pages are a snap to set up; you can do it in five minutes if you accept all the defaults. And it uses a nice static site builder called Jekyll which has themes that are pretty easy to set up. The devil's in the details, as usual. Because although we found "Read Only" through a gallery of Jekyll themes, it turned out that it wasn't a theme at all, just a mock-up. And although I eventually found a Jekyll version, it wasn't particularly usable.

I now know how to roll my own Jekyll theme, and I can consider myself an advanced beginner at the – Liquid template language and CSS stylesheets. By the way, the MDN Web Docs (MDN stands for Mozilla Developer Network, BTW) are awesome. They have tutorials on all the important web technologies: HTML, Javascript, and CSS, plus some more obscure ones. And when you get to the edge cases, they have reference docs.

It took me, basically, all week, with a huge amount of frustration along the way.

We appear to be getting into the bad parts of the week, don't we? Right.

I believe I mentioned that I'd been dreading going home from Betsy's late at night (I'm nowhere near as good a driver as I was at 50, and I know it). My guess is that that was at the root of the anxiety attacks I had Saturday and Sunday. (Panic attacks are intense, and supposedly last for only a few minutes to an hour or so. Anxiety attacks can -- and in my case, do -- last all day.

And I have "Trigger finger" in my left thumb. It's been getting worse, not better, in spite of the brace I'm wearing, which incidentally makes it almost impossible to type because my thumb keeps hitting my laptop's trackpad and left button. Anyway.

Aaaaaaand, I've been spending almost all my time grappling with Jekyll and CSS, and not getting any job applications done. Bletch.

( Notes & links, as usual )

Back when smalltalk was sports and the weather, And an object was what you could see, And we watched "Captain Video" in black-and-white, Before there was color TV. -- "When I Was a Lad"

Even if you're not a programmer (and most of the people I expect to be reading this aren't) you've probably heard one of your geek friends mentioning "object-oriented" programming. You might even have heard them mention "functional" programming, and wondered how it differs from non-functional programming. The computer curmudgeon can help you.

If you are a programmer, you probably know a lot of this. You may find a few items of historical interest, and it might be useful explaining things to the non-programmers in your life.

Imperative languages

As you may recall from last month's post on computer languages, the first programming languages were assembly languages -- just sequences of things for the computer to do, one after another (with a few side-trips). This kind of language is called "imperative", because each statement is a command telling the computer what to do next: "load a into register 2!" "add register 2 to register 3!" "roll over!" "sit!" You get the idea.

Most programmers use "statement" instead of "command" for these things even though the latter might be more correct from a grammatical point of view; a "command" is something one types at a terminal in order to run a program (which is also called a "command").

Most of the earlier programming languages (with one notable exception that we'll get to later) were also imperative. Fortran, Cobol, and Algol were the most prominent of these; most of today's languages descend more-or-less from Algol. (By the way, the Report on the Algorithmic Language Algol 60 is something I always point to as an example of excellent technical writing.)

Imperative languages make a distinction between statements, which do things (like "a := 2", which puts the number 2 into a variable called "a"), and "expressions", which compute results. Another way of saying that is that an expression has a value (like 2+2, which has a value of 4), and a statement doesn't. In earlier languages that value was always a number; later languages add things like lists of symbols and strings of characters enclosed in quotes.

Algol and its descendents lend themselves to what's called "Structured Programming" -- control structures like conditionals ("if this then {that} else {something-else}") and loops (for x in some-collection do {something}) let you build your program out of simple sections that nest together but always have a single entrance and exit. Notice the braces around those sections. Programming languages have different ways of grouping statements; braces and indentation are probably the most common, but some languages use "if ... fi" and "do ... done".

Languages also have ways of packaging up groups of statements so that they can be used in different places in the program. These are called either "subroutines" or "functions"; if a language has both it means that a function returns a value (like "sqrt(2)", which returns the square root of 2) and a subroutine doesn't (like "print('Hello world!')", which prints a familiar greeting.) Subroutines are statements, and functions are expressions. The expressions in parentheses are called either "arguments" or "parameters" -- I was bemused to find out recently that verbs have arguments, too. (A verb's arguments are the subject, and the direct and indirect objects.)

Object-oriented languages

As long as we're on the subject of objects, ...

In the mid 1960s Ole-Johan Dahl and Kristen Nygaard, working at the University of Oslo, developed a language called Simula, designed for simulating objects and events in the real world. Objects are things like cars, houses, people, and cats, and Simula introduced software objects to represent them. Objects have "attributes": my car is blue, my cats are both female, my wife has purple hair. Some of these attributes are objects in their own right: a car has wheels, a cat has four legs and a person has two legs and two arms. Some of these are variables: sometimes my driveway has a car in it, sometimes it doesn't, and sometimes it has two or three.

What this means is that objects have state. A car's speed and direction vary all the time, as does the position of a cat's tail. An object is a natural way to bundle up a collection of state variables.

An object also can do things. In a program, objects rarely do things on their own, some other object tells them what to do. This is a lot like sending the object a message. "Hey, car -- turn left!" "Hey, cat! What color are your eyes?" Software objects don't usually have any of their state on the outside where other parts of the program can see it; they have to be asked politely. That means that the object might be computing something that looks to the outside like a simple state variable -- a car computes its speed from the diameter of its tires and how fast its wheels are turning. All these things are hidden from the rest of the program.

An object has to have a method for handling any message thrown at it, so the documentation of most languages refers to "calling a method" rather than "sending a message". It's the same thing in most cases. As seen from the outside, calling a method is just like calling a function or subroutine, except that there's an extra argument that represents the object. If you think of the message as a command -- an imperative sentence -- it has an implied subject, which is the object you're talking to. Inside the little program that handles the method, the object is represented by a name that is usually either "self" or "this", depending on the language.

One natural thing to do with objects is to classify them, so objects have "classes", and classes tend to be arranged in hierarchies. My cats are cats -- we say that Ticia and Desti are instances of the class "Cat". All cats are animals, so Cat is a subclass of Animal, as are Dog and Person. (In programming languages, classes tend to have their names capitalized. Variables (like "x" or "cat") almost always start with a lowercase letter. Constants (like "Pi", "True", and "Ticia") can go either way.)

An object's class contains everything the computer needs to determine the behavior of its instances: a list of the state variables, a list of the methods it can handle, and so on. Now we get to the fun part.

Simula was just objects and methods tacked on to a "traditional" imperative language -- Algol in that case. Most other "object-oriented" languages work the same way -- C++ is just objects tacked on to C; Python and Perl had objects from the beginning or close to it, but they still include a lot of things -- numbers, strings, arrays, and so on, that aren't objects or (like strings in Java) are pretending to be objects. It doesn't have to be that complicated.

Shortly after Simula was released, Alan Kay at Xerox PARC realized that you could design a programming language where everything was an object. The result was Smalltalk, and it's still the best example of a pure object-oriented language. (It inspired C++ and Java, and indeed almost all existing OO languages, but very few of them went all the way. Ruby comes closest of the languages I'm familiar with.) Smalltalk is turtles objects all the way down.

In Smalltalk numbers are objects -- you can add new methods to them, or redefine existing methods. (Your program will eventually stop working if you redefine addition so that 2+2 is 5, but it will keep going for a surprisingly long time.) So are booleans. True and False are instances of different subclasses of Boolean, and they behave differently when given messages like ifTrue: or ifFalse:. (I'm not going to go into the details here; Smalltalk warrants an article all by itself). Loops are methods, too. The trickiest bit, though, is that classes are objects. A class is just an instance of Metaclass, and Metaclass is an instance of itself.

Someone trying to implement Smalltalk has to cheat in a couple of places -- the Metaclass weirdness is one of them -- but they have to hide their tracks and not get caught.

Functional languages

Smalltalk, for all its object orientation, is still an imperative language underneath. A program is still a sequence of statements, even if they're all wrapped up in methods. Objects have state -- lots of it; they're just a good way of organizing it. Alan Kay once remarked that programming in Smalltalk was a lot like training a collection of animals to perform tricks together. Sometimes it's more like herding cats.

But it turns out that you don't need statements -- or even state -- at all! All you need is functions.

About the same time Alan Turing was inventing the Turing Machine, which is basically a computer stripped-down and simplified to something that will just barely work, Alonzo Church was developing something he called the Lambda Calculus, which did something similar to the mathematical concept of functions.

A mathematical function takes a set of inputs, and produces an output. The key thing about it is that a given set of inputs will always produce exactly the same output. It's like a meat grinder -- put in beef, and you get ground beef. Put in pork, and you get ground pork. A function has no state, and no side-effects. State would be like a secret compartment in the meat grinder, so that you get a little chicken mixed in with your ground beef, and beef in your ground pork. Ugh. A side effect would be like a hole in the side that lets a little of the ground meat escape.

Objects are all about state and side effects. You can call a method like "turn left" on a car (in most languages that would look like car.turn(left)) and as a side effect it will change the car's direction state to something 90 degrees counterclockwise from where it was. That makes it hard to reason about what's going to happen when you call a particular method. It's even harder with cats.

Anyway, in lambda calculus, functions are things that you can pass around, pass to other functions, and return from functions. They're first class values, just like numbers, strings, and lists. It turns out that you can use functions to compute anything that you can compute with a Turing machine.

Lambda calculus gets its name from the way you represent functions: To define a function that squares a number, for example, we say something like:

square = λ x: x*x

Now, this looks suspiciously like assigning a value to a variable, and that's exactly what it's doing. If you like, you can even think of λ as a funny kind of function that takes a list of symbols and turns it into a function. You find the value of an expression like square(3) by plugging the value 3 into the function's definition in place of x. So,

square(3)
  → (λ x: x*x)(3)
  → 3*3
  → 9

Most functional languages don't allow you to redefine a name once you've bound it to a value; if you have a function like square it wouldn't make much sense to redefine it in another part of the program as x*x*x. This is vary different from imperative languages, where variables represent state and vary all over the place. (Names that represent the arguments of functions are only defined inside any one call to the function, so x can have different values in square(2) and square(3) and nobody gets confused.)

Lambda calculus lends itself to recursive functions -- functions that call themselves -- and recursion is particularly useful when you're dealing with lists. You do something to the first thing on the list, and then combine that with the result of doing the same thing to the rest of the list.Suppose you have a list of numbers, like (6 2 8 3). If you want another list that contains the squares of those numbers, you can use a function called map that takes two arguments: a function and a list. It returns the result of applying the function to each element of the list. So

map(square, (6, 2, 8, 3))
 → (36, 4, 64, 9)

It's pretty easy to define map, too. It's just

map = λ (f, l):
	if isEmpty(l)
           then l
	   else cons(f(first(l)), map(f, rest(l)))

The cons function constructs a new list that consists of its first argument, which can be anything, tacked onto the front of its second argument, which is a list. Using first and rest as the names of the functions that get the first item in a list, and the remainder of the list after the first item, is pretty common tese days. Historically, the function that returns the first item in a list is called car, and the function that returns the rest of the list is called cdr (pronounced sort of like "could'r").

I know, the classic introduction to recursive functions is factorial. Lists are more interesting. Besides, I couldn't resist an excuse for mentioning "car". We'll see "cat" in a future post when I discuss scripting languages.

We call map a "higher-level" function because it takes a function as one of its arguments. Other useful higher-level functions include filter, which takes a boolean function (one that returns true or false) and flatmap, which takes a function that returns lists and flattens them out into into a single list. (Some languages call that concatmap.) Higher-level functions are what make functional languages powerful, beautiful, and easy to program in.

Now, Church's lambda calculus was purely mathematical -- Church used it to prove things about what kinds of functions were computable, and which weren't, which is exactly what Alan Turing did with the Turing Machine. We'll save that for another post, except to point out that Church's lambda calculus can compute anything that a Turing machine can compute, and vice versa.

But in 1958 John McCarthy at MIT invented a simple way of representing lambda expressions as lists, so that they could be processed by a computer: just represent a function and its arguments as a list with the function first, followed by its arguments. Trivial? Yes. But brilliant. His paper included a simple function called eval that takes a list representing a function and its arguments, and returns the result. Steve Russell realized that it wouldn't be hard to implement eval in machine language (on an IBM 704).

I'll save the details for another post, but the result was a language called Lisp. It's the second oldest programming language still in use. The post about LISP will explain how it works (elsewhere I've described eval as The most amazing piece of software in the world), and hopefully show you why Kanef's song The Eternal Flame says that God wrote the universe in LISP. Programmers may want to take a look at "Sex and the Single Link".

And finally,

I'd be particularly interested in seeing comments from the non-programmers among my readers, if I haven't lost you all by now. Was this post interesting? Was it understandable? Was it too long? Were my examples sufficiently silly? Inquiring minds...

Another fine post from The Computer Curmudgeon.

A few months ago while waiting for a ferry with my sister I mentioned a programming language called Elm, which I've been particularly interested in because it's a functional language that compiles into Javascript. Her response, predictably, was something like "I have no idea what you just said. What does 'compiles' mean?" So I explained the difference between compilers and interpreters, and a few other things about programming languages, and she said that it was the first time anyone had explained how programming languages work in a way that made sense to her. In the back of my mind, I thought it might someday make an interesting blog post. So here it is.

Inside of a computer, everything is a number. These days, these numbers are all represented in binary (base two -- just ones and zeroes), stored in a couple of billion numbered locations each of which holds eight binary digits. (A binary digit is called a "bit", and eight of them together make a "byte", which is the amount of data needed to represent a number between 0 and 255, or a single character in a block of text. Apart from the numerical coincidence, computer bits have nothing to do with the bits that were made by breaking apart "pieces of eight".)

The numbers in the computer's memory are used for three different things. First, some of them are used to represent the data that the computer is going to be working on. Second, some of them represent the location of those data. And finally, some of them are instructions that tell the computer what to do with the data. Those instructions are called "machine language" because they're the only thing the machine actually understands. Nobody writes programs in machine language if they can possibly avoid it.

( the details )

TL;DR: an assembler turns each line in a program directly into a machine-language instruction. A compiler takes a program written in a more complicated (for the computer) but easier to write in (for people) and turns it into a sequence of machine-language instructions, that can then be read back in and run. An interpreter skips that last step -- instead of writing out the machine language instructions, it just does them on the spot.

Teaser: Next time I'll talk about different kinds of programming languages: functional, imperative, object-oriented, and scripting. I'm also open to suggestions -- what would you like me to write about?

It's been just short of a year since I retired, and I don't have a whole lot to show for it in the way of programming, apart from a little work on MakeStuff. OK, a fair amount. And it has an actual user now. But still.

Somewhere around the New Year I started making a(nother) list of potential projects that I wanted to work on in my retirement. As these things do, it got out of hand -- at last count there were 86 unfinished items in it. Time to start something.

There are a few constraints. I can't start any of the woodworking projects yet, because the contents of the garage are in storage waiting for the remodeling to get finished; that includes all of the woodworking tools. So there's that. Same for the recording projects -- my good microphones have either been boxed, or vanished altogether in the last move.

More than half the "projects" on the list are ideas for articles or blog posts -- there are forty or so of those. I should start picking them off, one or two every week, but they're not really projects.

What remains is mostly software: programs (the young people call them "apps" these days) and work on my websites. These are also areas where I have a lot to learn, and where I can develop skills that will be useful if I want -- or need -- to do some consulting. And there's another factor: there's really no difference between a web app and a mobile app! Not any more: with React Native and Electron, one can now build stand-alone cross-platform applications using web front-end frameworks -- they basically bundle a stripped-down browser and a trivial server with your web"site", which is often just a Single-Page Application (SPA). And with languages like Elm that compile into Javascript,...

I can haz apps

One app I want to write will be for managing checklists. (There's an existing app called Checkmate -- my first choice for a name; grumble -- that looks worth mining for ideas.) Beyond being able to have multiple, named lists, I want timing information so that one can ask questions like "how long ago did I last take my pain medication, and is it safe to take another dose?" That needs to work for both scheduled items, and "as-needed", floating items that can start their timer going at any time. More like a combination checklist and reminder system. I'd also like to be able to track the time it takes to go through a checklist, both so that I know when to start if I'm getting ready for something, and so that I know how much I'm improving with practice. Eventually it would be nice to link this to both a website and an Alexa skill -- the website will be easy, since almost the entire app will be usable as the front end.

It would be nice to have a combined lyrics viewer and a setlist planner. (I used to have a setlist planner, but it was in Perl and kept its state in the HTTP query string - bad news for caching and sort of search-engine pessimization.) There would be some overlap with the checklist app, since they both involve going through a list of things in sequence, with associated times. It would be especially useful on a tablet for performances, but it would be most effective combined with a website that hosts lyrics and music, which brings us to...

What a mangled web

Another thing I've been looking at is "Responsive Web Design" -- making websites that adjust smoothly between tiny mobile devices and large-screen desktops. This has long been a design requirement of mine anyway -- almost all my sites do this, but they do it by simply not having much of a layout, and they look bad both on very large screens and very small ones. It's time to take this to the next level by adding responsive CSS and mobile.

There are several websites that need work: lookingglassfolk.com, steve.savitzky.net, Stephen.Savitzky.net, and hyperspace-express.com at least. The first one is by far the simplest; just songs, concerts, (proposed) albums, and a gig schedule. steve.savitzky.net adds writing and software projects, but there's still a lot of overlap.

It would make sense to do the others using different responsive design frameworks, just to get experience with a few of the options. Stephen.Savitzky.net, in particular, is my "portfolio" site; it's also the only one that has a sidebar at the moment. It might be a good idea to turn into a GitHub Pages site. hyperspace-express.com is my "commercial" site, and it would make sense to use a CMS like Joomla or Drupal for it.

(I have some other sites, e.g. rainbows-end.net and thestarport.org, but they're simple enough to simply copy the CSS from one of the others. The Interesting.Places sub-site would be worth some attention.)

Now, here's my plan...

The underlying reason for picking this particular set of projects is to market myself as a blogger, consultant, and developer, in hopes of making a little money on the side. That suggests that I should start with the checklist app, and probably start the site makeovers by moving Stephen.Savitzky.net to a GitHub site (which would give me an obvious home for projects like MakeStuff and my development-focussed blogging). On the other hand, making over steve.savitzky.net would probably teach me more about responsive design, especially if I make S.S.net into a GitHub site. It might make more sense to keep S.S.net as a separate site, and build the GitHub site from scratch.

In any case, my main blogging site will remain here on Dreamwidth; most likely I'll just cross-post development-related blog entries to S.S.net (and GitHub, if it's separate). Or would it make more sense to keep all of the blogging concentrated here?

Comments? Ideas? Suggestions? Over to you folks.

It's been another rough week. This week it's been mostly health care -- I found out Tuesday that Amazon hadn't continued my health care as they said they were going to, so I was unable to order Colleen's humira. (Which, at $1800 for two doses, isn't something one wants to pay for out of pocket.) My HR contact is looking into it, but it took several days to get through; meanwhile I went online and signed up for Medicare Part D and identified a Medigap provider (ExpressScripts and Premera Blue Cross; both for continuity and because they seem to get top reviews. Who knows how long that will last under Trump(Doesn't)Care.)

I know there's something called compassion fatigue. Is despair fatigue a thing? Or is that just another phase of despair? I find myself incapable of being surprised at whatever outrageous thing Trump and the "Republicans" have done each day. (I put "Republicans" in quotes because they are rapidly turning this country into a right-wing dictatorship. I feel powerless to stop them.)

Onward. Had a really good trip with Colleen up to Whidbey Island; we went up the whole length of it and came back by way of Deception Pass. It's been a very long time since Colleen and I went out for a drive that long that was just a drive -- our occasional loop drives along the California coast were probably the last ones. It was a little too long, but it went ok.

I've been spending much of my spare time catching up on my reading. For some reason I'd stopped reading LWN (Linux Weekly News) sometime around the first of the year; in the last two weeks I've completely caught up. You can see the results in the links, most of which came from LWN, or indirectly by way of Sacha Chua's awesome Emacs News. I've also been finding Whidbey-related links. At some point I need to go back through my to.do archives, extract all the links, and aggregate them. They're kind of useless scattered across blog entries the way they are.

I've even done a little walking (not quite every day, and not much because I seem to be walking at about half my old 3mph pace), a little music, and a little hacking (almost entirely cleanup tasks). On the whole, I appear to have been keeping myself busy in a relaxed kind of way, though I haven't yet fallen into any kind of routine. Later, hopefully.

But.

My last few trips down to the house we used to call Rainbow's End (should we call it "Rainbow's Ended" now?) have been increasingly sad and discouraging. We put a lot of ourselves into that house; it was a large part of what we were as a family. Now we're scattered. We'll come back together, mostly, on Whidbey Island in a little over two months; it may very well be wonderful -- I hope it will -- but it won't be the same. I can't keep from thinking of what I might have done differently, over the last few decades(!), that might have made it possible to stay there. Hell, we all made decisions that seemed like the right thing at the time. Can't be fixed.

"I can't fix it!" is probably what I say most often when things are going badly. It always feels like my fault. I don't think I can fix that, either. I should shut up and go for a walk with Colleen.

( Notes & links, as usual )

This post covers most of my week-long vacation, so while it's not quite time for a wrap-up of my goals, I can say that I met about half of them. Which was about what I expected.

The big accomplishment for the week, without a doubt, was posting my one-line Linux setup/configuration package up on GitHub. (I then spent much of the rest of the week debugging and tweaking, but that's also to be expected.) It's called Honu, after the Hawaiian name for the green sea turtle, because a turtle carries its home around with it. The README starts off with this quote from my song, Windward, because I just couldn't resist:

Where the wind takes us next year no turtle can tell
But we'll still be at home, come high water or hell,
Because home is wherever you carry your shell.

The implied puns on $HOME and sh(1) are, of course, entirely intentional.

Honu is meant to be fairly general; it's expected that any user -- including me! -- is going to want to customize the heck out of it. To that end, there's a sample customization package, also on GitHub, called Myrtle. Of course. (My own customization package, which you will not find on GitHub, is called Mathilda, after LookingGlass Folk's name for the narrator of "Windward".)

It hasn't been all roses and rainbows, however. I've spent an inordinate amount of time coping with the bindweed (morning glory's evil twin) that has overgrown the walkway along the south side of the house, sorting a year or two's worth of mail, and recovering from last week's disk crash on the server. I've been doing quite a lot of writing, though a lot of that has been on Quora, so I'm not sure whether that counts toward my daily writing goal, or away from it.

I'll say one thing for Quora, though -- it makes me appreciate my own knowledge and social skills. Being able to answer questions is a real boost to my self-confidence in both those areas. Who knew?

Psychologically, well, ... mixed. I've definitely been less stressed out the last two days of the week than the first two -- I was able to handle a trip downtown that turned out to be a total write-off, due to things being closed/not where I expected, quite calmly and even with a little wry humor. The check from last week's stock sale arrived on Tuesday, which helped. On the other hand, it still apparently doesn't take much frustration to put me back over the edge.

I was a total wreck on Sunday. I seem to handle stress a lot better when I'm by myself. With Colleen around, especially, I get into a horrible feedback loop. By the time I got home I could probably have used an Ativan, but my prescription on those has long since expired. I settled for reading and gin. Low blood sugar may have contributed; I'm not sure I can tell the difference between anxiety and hunger. Alexithymia in action.

I am not ready to go back to work tomorrow. I may never be ready. I'll do it, but it won't be pretty. ( Notes & links, as usual )

Moderately productive. Two "publishing events".

1. Sex and the Single Link is up on my "formal" website, Stephen.Savitzky.net. This is, despite the clickbait title, an article about the joy of singly-linked lists.
2. MakeStuff is up on GitHub. This the first of several projects I intend to put up there; it's the collection of makefiles and scripts that powers all my websites. You can see it in action here.

Apart from that, and a bunch of Quora answers, not a whole lot going on. One my Quora answers led to a good discussion on the comment thread. Fairly prodctive at work, though as usual not quite as much as I wanted to be.

One particularly interesting article for the programmers in the audience, Developer Differences: Makers vs Menders, which seems to describe me fairly well.

Also of note, the first episode of the Lesbian Historic Motif Project Podcast: Ordinary Women by Heather Rose Jones (hrj on LJ) is up.

The only writing I did last week was last Sunday's weekly post. I'll try to do better; hopefully I won't be feeling as harried this week. I did get in some music time -- last Sunday, and yesterday. And some walking with Colleen and Kat, also on Sunday.

Quite a bit of back pain. It's been mostly ok in the morning, but tends to get worse on the way home. Probably something to do with being tired, but also possibly stress. Have I mentioned having trouble identifying my mental state? It's called alexithymia.

The alexithymia also bleeds into problems identifying physical state, because of course they're related. I have trouble distinguishing the physical symptoms of anxiety and hunger, for example. Not to mention distinguishing between wanting food, and needing food. The latter barely registers, and certainly not as hunger, until I suddenly start feeling the symptoms of low blood sugar. Which I have learned to recognize. Or until Colleen notices that I'm starting to snap at people.

Stress is, apparently, another of those states that I don't start noticing until it's been going on too long. And then it bleeds into burnout and depression. (And, no, depression doesn't register as sadness. At all. It's best described as a combination of apathy and despair.) I think I'm noticing a trend here.

I'm getting better at noticing. Look in the notes for an exclamation mark in column 3 -- that means I've actually noticed an emotion while it was happening. They're rare -- the only instance this last week was Sunday.

Speaking of stress, I'm oncall this week. With pages including 6am Tuesday morning -- Prime Day -- and midnight last night. This morning. Whatever. One thing I've noticed is that I don't have enough mental bandwidth. I can't multitask. At all. Period. Things get lost track of.

If a page comes in, I completely lose track of whatever I was doing, including dealing with another page, and it takes me a while to get my context back. Which leads to things like having something like 10 different browser windows open in 8 workspaces, with multiple tabs in each, many of which refer to the same tickets. Because context. And, of course, re-investigating the same thing multiple times because I've forgotten what I was doing an hour ago.

I'm getting a little better at going up to people I don't know and asking for help. But, of course, I'm even worse at remembering names than I am at multitasking, which leads to things like waking the wrong person up at six in the morning. (And forgetting that I had an email in my inbox telling me who the right person would have been. See multitasking.)

(Brief pause -- my desk is being catted on. The absolute best thing I've done for my mental health in years was putting a cardboard box on my desk, attaching it with a couple of screws, and lining it with a towel.)

Back to reaching out and talking to people. I don't think my reluctance to do that has anything to do with what I afraid people will think of me. So, this doesn't seem to have the characteristcs of social anxiety. No, it has more to do with what I think of me, and in particular feeling stupid and at a loss for what to do. Plus total lack of self-confidence, which leads to (or somehow relates to) an unwillingness to "disturb" people.

It's not just at work. Even at home, I take a closed door as a "do not disturb" sign even when I'm pretty certain that the person on the other side (usually N) would be happy to see me. It's hard enough when I know they're expecting me, though I'm getting a little better about that.

In a slightly different direction, some links from ysabetwordsmith about emotional self-care (see Monday, below) proved unexpectedly triggery and anxiety-provoking. So we're talking low self-esteem here, maybe. (Maybe?! Let's get real here.)

It's been a long month this week.

As I mentioned about a week ago, I've been trying to write more. And since my current obsession is a program called xmonad, well, ...

This is incomplete: it's about the first day's worth (I've been trying to write about 500 words per day). Comments and suggestions are, of course, welcome.

My new 27" monitors arrived at work; I took advantage of the change to rearrange my work space. Before, it was the set-up I've had for most of the last three years -- monitor in front on a stand, second monitor on the right, and my laptop on the left. The new laptop, however, has a decent keyboard (with trackpoint and three buttons), and the monitors between them occupy about 2/3 of the desk.

The new arrangement has the laptop dock under the "middle" monitor; the laptop, being a business-class Dell, has both a pointing stick and a middle "mouse" button. The laptop's keyboard is decent enough that it can replace the thinkpad keyboard I've been using for the last couple of years -- it's a high-end Dell, and has both a pointing stick and a middle button. (The middle button has part of the Unix desktop environment since the mid 1980s; it means "paste", and I use it all the time.) The monitors are about 50% bigger, pixel-wise, than the laptop, and are arranged "traditionally" with the laptop on the left.

You can probably see the problem with this arrangement. The total workspace is about 7000 pixels wide, and it's not even arranged in a straight line -- to get from the laptop to the "middle" monitor you have to move the cursor to the right, but the natural direction would be straight up. What's more, when you undock the laptop the whole thing collapses down to a "mere" 1920x1080. It's no wonder that most of the programmers in my team have opted for a single 30" monitor, and keep their laptop (almost invariably a mac) closed while they're using it.

Fortunately, I anticipated this problem months ago, and started using a window manager called xmonad.

One of the things I love most about Linux is the fact that the program that manages the layout of the screen and the behavior and appearance of the windows on it is not part of the operating system. It's a separate program, sensibly called a "window manager", and it runs in user space as a perfectly ordinary application that just happens to have a couple of extra hooks into X, which is the (also ordinary) program that actually controls the display, the keyboard, and the mouse.

Being an ordinary program -- and not even a terribly complicated one -- anybody can write one, and many people have. For a long time I was using one called TWM (Tabbed Window Manager, but the T originally stood for Tom's). Later I started using CTWM (Claude's Tabbed Window Manager), because it introduced the then unfamiliar notion of multiple workspaces. (Before CTWM, these could only be found in an experimental system at Xerox where they were called "rooms". Apple introduced them decades later, as part of MacOS X.)

You've probably heard of Gnome, KDE, and Ubuntu's horrible Unity desktop environments. Down at the bottom, they're just window managers plus a couple of utilities for doing things like putting up the familiar bar (Gnome calls it a "panel") full of menus, launcher buttons, clocks and other widgets. You can, in fact, run gnome-panel under any window manager, and I did for a while. They also include a "session manager", which handles things like starting the panel and making sure that applications get notified when you log out, so that they can save their state and exit cleanly. I've been using Gnome for years, and loved it for its configurability.

But Gnome's configurability comes with a cost -- every time you move to a new computer, you have to spend an hour clicking around in control panels and property windows to get everything set up the way you like it. And every time there's a major upgrade, something is a little different. It's a cost I no longer have to pay.

Part 2

The big news for this week is RainbowCon 1, this coming weekend. But other than that...

Colleen lost her uncle in a car crash. So not exactly a good week. Busy and somewhat rough week at work. Lots of tidying, moving of boxes, and so on. So my back hurt most evenings. Naproxen is my friend.

Finished my taxes, sort of at the last minute. Owed about the same as last year, which was a pleasant surprise, considering that before I started Sunday it was showing about twice that. I could have handled it, but glad I didn't have to.

N and G moved down to their new suite in the basement. It'll be gorgeous when they get moved in. I helped with putting up shelves, but the last two I put up weren't level. Grump.

... and when I couldn't give Naomi a coherently practical reason why I was prioritizing clearing a way to the garage, she said, "Oh. It's an emotional need then. Go ahead." Oh. Yeah; I guess I have emotions these days. And other people can still notice me having them when I can't. Which uttterly fails to surprise me.

Can't think of anything else worthy of mention.

I seem to have mostly switched to xmonad as my window manager. This is a Good Thing -- I seem to be better able to concentrate with a less-cluttered screen. (On the other hand, I'm less productive while I'm still hacking on the configuration. That may be less of a good thing. There are, unfortunately, still a few things that don't work well in it.

Meanwhile, despite being fairly productive at work, I have gotten behind on a couple of longer-term things -- namely taxes, and a presentation that I'm supposed to be giving next Friday. (It's more fun to read Learn You a Haskell for Great Good!.)

It was quite warm several days this week. That is not expected to last, but it does indicate that Spring may be on its way. Not to be confused with the Spring Framework. Which I am not happy with.

I am also starting to do yard work again, after neglecting it for almost all of last year. (Partly because depression; not clear on the rest.)

Sigh. Too many things have fallen by the wayside. I, perhaps, am one of them.

On the health front, I may finally be learning to relax the muscles in my lower back that make it hurt when I walk. Maybe. It also seems to have a lot to do with how heavy my shoulder bag is, so that's going to be an ongoing problem. A backpack would be better, except that it's hard to get off when I take a seat in the bus, and unlike a shoulder bag I can't swing it around when I want to get at something like my wallet.

I've finally started doing some serious system administration/scripting work to get my website working directories the rest of the way under git control. That's done -- I can now say "make deploy" in a web directory and have it committed, pushed to the remote repo, and pulled into the website with no further attention.

In the process, I had to write a script for converting a directory from CVS to git. There are a couple of challenges in that process because the old CVS repositories were in pretty bad shape, with stuff not having been checked in consistently. Not like a well-maintained software project, in other words. Bad bear. No cookie. My websites don't use cookies anyway.

The associated asset archive is going to be harder, because some directories have large media files in them. Like, um... the audio. The goal is to eliminate the use of rsync snapshots for backups (for reasons I will probably go into in more detail in a later post).

Detail in the notes, as usual.

I spent a lot of time yesterday (and today) ripping CDs so that they can be packed. The ones that aren't in FreeDB, and a few of the ones that, for some reason, my Linux box refuses to read, got sent over to the Mac mini; it worked on a lot of them. I'll have to write a script to translate the filenames to match the conventions I'm using on Linux, but that's easy.

We had an electrician come in to look at our fan/lights -- the fans work fine, but the lights don't. Turns out it's not the remote controls, it's the stupid ballasts. I looked at one -- the insulation on the wiring harness is brittle. Should be easy to replace, in that case.

A little random hacking in the makefile templates, prompted by the fact that the Makefiles in theStarport.org are hopelessly out of date.

Some good links in the notes, several of them music-related.

perl -e 'print scalar localtime(1234567890),"\n";'
Fri Feb 13 15:31:30 2009

Adeona: A Free, Open Source System for Helping Track and Recover Lost and Stolen Laptops

Adeona is the first Open Source system for tracking the location of your lost or stolen laptop that does not rely on a proprietary, central service. This means that you can install Adeona on your laptop and go theres no need to rely on a single third party. Whats more, Adeona addresses a critical privacy goal different from existing commercial offerings. It is privacy-preserving. This means that no one besides the owner or an agent of the owners choosing can use Adeona to track a laptop. Unlike other systems, users of Adeona can rest assured that no one can abuse the system in order to track where they use their laptop.

Adeona is designed to use the Open Source OpenDHT distributed storage service to store location updates sent by a small software client installed on an owners laptop. The client continually monitors the current location of the laptop, gathering information such as IP addresses and local network topology that can be used to identify its current location. The client then uses strong cryptographic mechanisms to not only encrypt the location data, but also ensure that the ciphertexts stored within OpenDHT are anonymous and unlinkable. At the same time, it is easy for an owner to retrieve location information.

[...]

Adeona is named after the Roman goddess of safe returns.

(from InfoWorld)

OpenDHT looks very interesting in its own right.

Yes, I definitely seem to have fallen into a modern-day version of The Programmer and the Elves...

...still a lowly programmer -- and is now stuck for the foreseeable future maintaining this horrid crock of a Fortran program, written by elves! After all, nobody else can understand how it works. It has variables named Shamrock and Rainbow and Misty_Morning_Dew, and some of the most ferocious assembly language subroutines to be found outside the jungles of Borneo.

And the moral of the story is: Never do the impossible. People will expect you to do it forever after.

Well, maybe not quite that bad. But it's a horrid crock of a form and workflow system built on top of a beta version of Java that are both 10 years out of date... Somebody upgraded Java, and it broke.

So I commented out the one place where it was using the old, incompatible KeyStore class, and it's back to crashing a lot instead of every damned time. That's an improvement. Of course, now it's only pretending to create and verify DSA signatures. But since you can't fill in a form without logging in to the server with your Unix password, there was never any real reason for the digital signatures in the first place.

This still leaves the uncomfortable question of why a horrid crock of a research experiment written by two people a full decade ago is still better for our lab's workflow than anything we've been able to turn up in the open source world. Suggestions?

Or is there still some research left in that topic? Hmm.

Added short-form track credits to some of the various listing formats. In general, this replaces timings (which mostly aren't all that useful except on places like the tray card) with the name of the songwriter, or lyricist/composer if they're different. You can see the results here, for example.

So now that I have this nifty ogg player, the obvious thing to do is to put the oggs for my album on it so I can listen to them. There are a couple of subtleties to this, since all the soundfiles have uninformative short names that don't sort in proper track order.

The solution was to add a new format to my TrackInfo program that makes symlinks (in a subdirectory) that have proper long names starting with a two-digit track number. Then it's a simple matter of invoking it from the Makefile, and rsync'ing the music player from the subdirectory.

Q.E.F.

BTW, it sounds really good. Clean. Claves don't work in "Daddy's World", though. Sound out of place.

OK, I'm an idiot. But at least I managed to avoid a major embarassment when I decided not to start burning disks last night -- a wise decision, given that it was nearly midnight and I'd already printed a batch of 10 jewelcase inserts upside-down -- and give the CD-ROM part a once-over in the morning. Damned good thing.

In addition to leaving out the copyright license notices on the index page, I had succeeded in leaving out the .ogg and .mp3 files that were the main reason for having the disk in the first place! It took me about three hours to clean up the mess. It's presently held together with spit and baling wire, but somebody reading the CD-ROM in a web browser will at least have valid local links to visit if they start at the top, and somebody browsing the files directly will find the audio in places that at least make sense.

Also discovered that my nice new Plextor drive doesn't seem to want to write any faster than 8x, though it could conceivably have been the media that I did the initial test burns on, or something else I was doing on the machine at the time (since it worked fine at full speed a couple of days ago). OK, I now have two side-by-side boxen in the office, Harmony and Trantor, and they both work.