Older blog entries for crhodes (starting at number 96)

Bother. I was going to do a before-and-after comparison of rendering of ties in the Gsharp score editor: before, from when I first implemented ties, and after, when Robert reimplemented them, including the beginnings of support for tie end glyphs, and for adjustment of tie heights for varying widths between tied notes. However, I managed to use the same file name for the latest screenshot as I did for the one almost two years ago (well, yes, ties.png is of course the obvious name for this: so obvious I chose it twice...), so you will just have to take my word for it that the new version is prettier than my hacked up version which just drew lines.

Instead I will just have to provide more evidence of prettiness, and since I have a long-held fondness for the music of Clément Janequin, I give you the beginning of les Cris de Paris, with the beginning of a lilypond version from about 2000 (in an evince window, behind) for a not-quite-fair comparison, and (what is more; see, how generous I am!) a MIDI file from Gsharp, just to prove that I'm not cheating.

Cyrus Harmon has been working on a port of the mostly-copying generational garbage collector in SBCL, based on previous work by Raymond Toy for CMUCL. At the seventh merge candidate, I decided I'd made him suffer enough with my tyrannical requests for whitespace changes and function renamings, so I merged it, having tested on multiple platforms, and went to sleep the sleep of the just.

Sadly, the testing wasn't quite exhaustive enough, and I discovered this morning that we'd managed to kill the overnight automatic build-and-benchmark host run by Andreas Fuchs. Fortunately Cyrus was awake (whether again or still I don't know; for him it was 0300 local time) and diagnosed the problem pretty quickly: we had managed to subvert the garbage collector almost, but not quite, completely on threaded platforms. Interestingly, the system was stable enough to build itself, but benchmarking it (or indeed running the regression tests) exercised different-enough allocation patterns that the existence of the error was pretty obvious.

A simple one-line fix later, and things started working on threaded platforms too.

25 Jan 2006 (updated 25 Jan 2006 at 13:24 UTC) »
John Wiseman wants a workaround installed in SBCL for a buggy, closed OS[*]. If that summary were all that there was to the issue, it certainly wouldn't merit a diary entry, even given the prominence of John's weblog among a section of the Lisp-using public; I don't think it hurts to discuss merits and faults of software out in the open, and of course no publicity is bad publicity.

However, John appears to misunderstand how people work. In particular, he wants to spur SBCL developers to fix the problem he observes for him[**]. Of course, this is a reasonable want, but as children are told, I want doesn't get, and this holds in the adult world too. Those who take out a support contract or similar arrangement have exchanged a quid or 500 for the quo that they then have a right to expect; those who don't must depend on the interests of those who do being aligned with their wants.

Now, here is where it gets interesting. There are all sorts of reasons why depending on the interests of others can work well in the world; after all, there's reasonable agreement over what is undesireable versus what is desireable; what is good vs what is bad. It's not Universal agreement, but it is there, and the more select the community the more likely it is that the agreement within that community is strong. So, for instance, it's clear that reporting a straightforward bug in a Free Software system, without providing a fix, is nevertheless likely to lead to the bug being fixed, as other individuals will weigh up the chance of being hit by the bug in the future against the effort required to fix it now.

What is different in this specific case, then? Why isn't this just a bug report? Well, as a cursory read of the relevant thread on the development mailing list would show, this issue was reported nine months ago, and no real attempt was made then to provide a workaround for the buggy OS vendor's tool. So this weblog posting isn't a bug report, it's an attempt to get other people to reprioritize what they are doing.

However, empirically, this has not bothered other people overmuch over the last nine months: no-one else has voiced a complaint, and no workaround has been written (obviously, since otherwise John would have nothing to complain about). So this might well be one of those cases where one's interests are not aligned closely enough with others; what to do, what to do? Well, one thing that John could do is to attempt to develop and install his own workaround for his situation.

John claims that he "... looked at trying to fix it [him]self, but as a first SBCL hacking project it was a little beyond [him]." This is certainly to be expected if he is deprived of all human contact, but here's where the interests of others can be put back in alignment: it is most certainly in the interests of developers of SBCL to have more people with enough understanding to be able to make non-trivial modifications to the source code. So while John may find that his attempt to spur developers to do his bidding is unsuccessful, he may also find that they are receptive, even without other consideration, to assisting him in solving his own issue.

The general point to make here is that, in at least this little corner of Free Software, where all the labour is volunteer, any user and developer community is an emergent property of individual and small-scale interactions; in this context, it is far from clear that making a loud complaint is productive for any party, whereas attempts to take personal responsibility, even if they ultimately need assistance, are more likely to bear fruit.

[*] All OSes are buggy. Not all of them prevent bug fixes.

[**] To his credit, he also claims to want to document the issue. Why he thinks a weblog post is better than the top hit that Google returns for "SBCL crash reporter", pointing to the mailing list discussion of nine months ago, I don't know.

[ Edited to fix a broken link ]

After a bit more fiddling around, I've merged Alastair Bridgewater's work (referred to in my previous diary entry) into HEAD of SBCL's CVS. This is far from an announcement of official support for SBCL on Windows; there is quite enough that doesn't work (see Alastair's TODO list or mine for ideas of what you could contribute) that interested parties need to fix before we could contemplate treating it as a stable platform.

Still, one step closer to destroying the software industry...

Windows can be made to look similar to Unix, from a suitable vantage point and given sufficient use of green-tinted glasses. (I watched The Muppets' Wizard of Oz yesterday, and oddly enough this seems like a good analogy: we're definitely not in Kansas any more).

The background: SBCL is a lisp environment (native-code compiler plus runtime) which is fairly solidly Unix-centric, and has been for the best part of 20 years or so; at its inception, it also ran on a Mach kernel. Among the Unixisms pervading the code are simple things such as parsing filenames; mild things like having streams associated with fds (rather than HANDLEs); and fairly fundamental differences in signals, exceptions, and handlers. This latter is important because a fair amount of runtime support is implemented in terms of Unix signals: the garbage collection is assisted by a write barrier; the debugger wants to be able to set breakpoints by writing an illegal instruction at the start of a function; and so on.

Why is this relevant? Well, I'm staring at a 65-page diff from Alastair Bridgewater, containing a sufficiently-complete port of SBCL to Windows. ("sufficiently-complete" here means that it self-hosts and mostly doesn't crash-and-burn instantly; it certainly does not mean that it's stable enough to run your mission-critical server on; whether you'd want to do that on Windows in any case I leave open.) This is the second iteration of this patch; Juho Snellman has already blogged about the first iteration, which was eight pages shorter; this was not the direction I hoped the patch would go, but oh well: I am assured that the extra eight pages include extra functionality, and certainly there is a lot less that causes screams of horror.

Alastair's made patch and binaries of the latest attempt available, as well as the beginnings of a TODO list: if there are Lisp-interested Windows hackers out there, more eyes and hands would be very welcome.

We have the beginnings of Climacs/PAIProlog integration. Code and screenshots soon. That is all.

Well, no, that is not at all "all". Work and multiferous other projects also continue to advance, some more glacially than others. Does anyone know where I can buy bottled time?

Paolo Amoroso, in noting the new, different screenshots of Climacs, a Common Lisp implementation of Emacs, says that “not yet ready for prime time”. However, since Paolo and I both reach an audience of Lisp-interested developers, let me emphasize what the casual reader might not have gleaned from that simple statement. It is fair to say that users reporting bugs will largely find their reports dropped on the floor, simply because the developers already know that the functionality isn't there or is already broken; on the other hand, anyone wishing to get their hands even just a little bit dirty will find that there is both a lot of low-hanging fruit and large potential rewards from hacking at the code.

In the meantime, Brian Mastenbrook is at the ILC to present a paper that we wrote (with Robert Strandh) about Climacs' current status and potential. I can't quite say that I regret not being there — perhaps I regret it not being here — but I do wish the “I” in ILC were taken a bit more seriously. (There are rumours to the effect that 2006 may see improvement in this area).

Mustard is surprisingly easy to make: take a random amount of mustard seeds, and grind until it feels too much like hard work. Add a small amount of vinegar (bonus points if it's tarragon vinegar, made by placing fresh tarragon leaves in a bottle of ordinary white wine vinegar) and approximately the same volume of water as mustard seeds. Grind some more, and leave to stand, tasting occasionally: the mixture will thicken and increase in sharpness over time. When it's eyewateringly strong, place in the fridge (or other cool place).

Armed with freshly-made mustard, it was then easy to make mustard mash and sausages in port reduction (non-permalink: 11th May entry); the reduction is made at the last minute, by boiling a splash of port with the cooking juices of the fried sausages.

Oh, yes, I've also fixed a rather difficult-to-diagnose bug in SBCL on Mac OS X:

  * bug fix: dynamically loading (via LOAD-SHARED-OBJECT or similar)
    "frameworks" on Mac OS X no longer causes an EXC_BAD_ACCESS if two
    or more runtime options were provided to the sbcl binary.
Thanks also to Brian Mastenbrook, Michael Hudson and Nikodemus Siivola.

OK, so what were the weasel words in my last entry about Norvig's Prolog implementation? Well, Prolog has a number of control constructs, which look like functors except that their semantics, in one important respect, are not as regular.

(Aside: in many ways, these control constructs of Prolog are similar to Lisp's concept of a special operator; neither Prolog nor Lisp provides for a way to extend the initial set of predefined magical constructs, but Lisp's macros provide sufficient control over evaluation semantics that things which look like special operators can be defined, while I'm pretty sure that unification in Prolog allows for similar implementation of new control constructs.)

Now, the issue with these special operators, and in particular the ->/2 and ->/2 ;/2 ‘if-then’ and ‘if-then-else’[*] control constructs have particular semantics in conjunction with the cut, !/0: the then and then-else portions of those operators are transparent to the cut, meaning that backtracking is inhibited from the predicate which is defined, rather than any notional -> predicate.

This means that any definition of -> as a predicate is doomed to fail. Norvig effectively defines if/2 (corresponding to ->/2 as

(<- (if ?test ?then) (call ?test) (call ?then))
which has the right semantics except when one of ?test or ?then contains a cut.

I have not yet fixed this is my local extension of Norvig's Prolog; I'm pretty sure I know how to do it (my experience of Lisp compiler technology is enough to tell me how to implement special forms; essentially, what needs to be done is to teach the compiler about if-then and if-then-else, and then implement call/1 by requiring it to compile a dummy uninterned predicate), but I've been occupied with parsing ISO prolog instead. One thing which is demotivating me from making this fix is the somewhat lamentable state of the test suites available for ISO Prolog: one from the committee and one from INRIA, neither of which tests any of the difficult cases from the standard. Now I realise how spoilt we in the Common Lisp community are by pfdietz and his test suite.

In case anyone is wondering what the cut is: passing a cut during the execution of a predicate prevents backtracking past that point: any attempt to backtrack will simply cause failure. For more details, see your nearest Prolog tutorial, because my limited experience prevents a good didactic presentation.

[*] these are in fact very bad names.

I've been having adventures in Prolog recently. Fear not, I haven't abandoned Lisp for all that! However, Real Work has its own requirements, and one such was that I get up to speed in Prolog rather rapidly.

So, learn by implementing. Well, Peter Norvig, in his book Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp (buy it, borrow it: run, don't walk) implements a fair proportion of a Prolog engine, including a full (or almost: more on this another day) compiler. Reading the book, and the accompanying code, was both entertaining and educational, and to familiarize myself with bits of Prolog that weren't covered by the book, I found a draft copy of the ISO Prolog standard, and started implementing missing functors.

However, some of the Prolog code I'm working with (ab)uses operator notation: it depends on being able to talk to Matlab and PostgreSQL, and uses operators to indicate with minimal character syntax how to interpret Prolog terms in these contexts (is it a string, a cell array, an mxArray?)

So I also needed to understand how Prolog is parsed. As it happens, I've been looking at the Climacs text editor project for a while; it's been growing a parser framework based on a slight modification of Earley's efficient algorithm (ACM tax required). Armed with this, and liberal amounts of debugging code and beer, yesterday I got it to the point when it could demonstrably parse Prolog text at least semi-reliably. It's not blindingly fast at the moment; removing the debugging code should help, as should hooking into the Climacs framework which allows reparsing only regions which both have changed and are displayed on the screen.

Once the editor support is acceptable, it should be relatively straightforward to finish off the underlying Prolog implementation (I need a parser for read_term/2 and friends); whether anyone else will ever find this useful I don't know, but having a lisp/1 functor as the Prolog's foreign function interface has a certain coolness factor...

87 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!