Incoming!

One of the things that stops me trying out all sorts of new features and fixes in Gratian is the fact that it updates the Canon Lore site directly.  Obviously, if I’ve done something wrong, this could cause the site to die in various dull or spectacular ways.  So to make it easier to test things without breaking the real site, I’ve finally gotten around to setting up a dummy version.  If you check out batpup.com/canon, you’ll see what looks like the Canon Lore site, with a slightly out-of-date database.  As I make fixes to Gratian (usually on the bus to and from work) I’ll set it to update there instead of the main site.  Gods willing, this will mean I’ll have a working version of Gratian ready for Canon Herald, before too much longer.

If you’re reading this, you already know that Canon Lore is the website of the Canon Herald of the kingdom of Lochac, and holds all knowledge of the awards received by the kingdom’s citizens or given by the kingdom’s royalty. You also know that Gratian is the windows-based software used by Canon to update the site.

This blog is maintained by Mortar Herald, Baron Karl Faustus von Aachen, who also maintains the software behind Canon Lore and Gratian. Canon Herald, Mistress Bethan of Brockwood, will be given the keys to this particular kingdom as well, although it’s entirely up to her whether she chooses to use it. If she had free time on her hands, they never would have made her a Pelican.

The other thing you’ll know is that Gratian isn’t fully functional yet. It’s mostly feature-complete, but some of the features are so bug-ridden that they’ve been disabled to prevent possible death and mutilation of its users. Similarly, the Canon Lore site has some flakey moments, although it’s a lot better than Gratian, having been developed a lot longer ago. The rule of thumb is this: if something isn’t working, it’s because Mortar stuffed up; if something is working, it’s because Canon fixed it. This is close enough to the truth that you can rely on it.

Now, an anecdote. One of the things Gratian does is organise the Order of Precedence, the list of all award recipients in order of rank: Dukes first, then Counts, then other peers, and so on down to the lowest of the low, the people who have no armigerous awards at all. When my (Karl’s) predecessor as Canon Herald produced the rather primitive WebCanon, which Canon Lore inherits nothing at all from, she chose an order like this:

1. The person with the highest-ranking award comes first.
2. Where two people have the same rank, the person who received the award first comes first.
3. Where two people received their highest-ranking award on the same day, toss a coin.

I felt that this algorithm lacked intellectual rigour, so I changed it thus:

1. The person with the highest-ranking award comes first.
2. Where two people have the same rank, the person who received the award first comes first.
3. Where two people received their highest-ranking award on the same day, start from step #1 with their second-highest award, and so on down their respective lists.
4. Where one person runs out of awards first in this comparison process, the other person (the one with more awards) comes first.
5. Where two people have identically-ranked awards given on the same days, compare their SCA names; the one closest to the front of the alphabet comes first.

This system has the advantage that it is at least predictable.

However… I was having trouble with the OP calculator function. It appeared that the QuickSort function built into my programming language was in error! Given a list of valid people, it would apparently insert a null person into the list, somewhere near Ulric Johannson for some reason. I examined the code in detail, but it seemed fully functional. And, to make matters worse, the problem appeared only when I was running in debug mode, and disappeared in production mode. This is referred to as a Heisenbug, and is a royal pain in the arse.

This morning I finally tracked it down. Have a look at this bit of code and see if you can see the problem:

1. if Person1 = Person2 then:
    Result := 0
    exit function

2. if Person1.AwardsReceived is 0 and Person2.AwardsReceived is not 0 then:
    Result := +1
    exit function

3. if Person1.AwardsReceived is not 0 and Person2.AwardsReceived is 0 then:
    Result := -1
    exit function

4. for each award up to the smaller of Person1.AwardsReceived and Person2.AwardsReceived:
    Result := the award rank comparison for that pair of awards
    if Result is not 0 then:
        break out of loop

5. if Result is still 0 then
    Result := comparison of the number of awards each person has

6. if Result is still 0 then
    Result := comparison of the alphabetical order of each person's name

See the bug? Don’t worry, I didn’t for a stupidly long time. It’s this: after step 3, I don’t set a default value for Result. If there are no awards in a person’s file, step 4 won’t set Result either, because the loop never gets used. Then, steps 5 and 6, which assume Result is already set to zero if nothing else, will behave more or less randomly, according to whatever random bits happened to be stored in memory before the function was called. As a result, the QuickSort function becomes unstable, and All Bets Are Off.

So it’s fixed now. One less hurdle on the long run to completion.

Fun, eh?