Not a terribly successful week, code-wise#

Sun, 03 Feb 2002 05:12:17 +0000

Not a terribly successful week, code-wise.

SBCL Alpha 0.7 has a bug whereby setf of (get 'nil 'anything) will cause all error reporting henceforth to break, which apart from anything else means it can't be used to build itself. Discovered this when attempting to rebuild with -dynamic so that I could use clg with it.

SBCL PPC (still 0.6.13) doesn't build itself either, blowing up in second genesis when it attempts to load a specialised array with an element size of 0. I suspect we may still be having byte ordering issues.

Raymond Wiker's CLX for SBCL works nicely, though. It had most of a working set of dependencies for db-sockets already, so sent him some code to open the stream to $DISPLAY and thereby remove its foreign code dependency.

ftx13, out now#

Mon, 04 Feb 2002 13:20:19 +0000

ftx13, out now.

One down#

Mon, 04 Feb 2002 23:07:47 +0000

One down.

While I'm here i think I might have a look at some of the other outstanding Alpha bugs. (sqrt single-float-positive-infinity) is, bizarrely, 0.0. I suspect the floating point traps are more than a little b0rked too

Completely b0rked, yup#

Wed, 06 Feb 2002 02:17:57 +0000

Completely b0rked, yup. It's using the #defines for IEEE rounding/trap/exception settings, but attempting to set the hardware fpcr with them directly instead of using ieeesetfp_control() and friends. Not surprisingly, this doesn't work. Nor does it work in CMUCL for Linux/Alpha (at least, on my computer). I'm at a loss to see how it could have worked on OSF1^WDigital Unix^W^WTru64 either, but I think we just trust that it did.

The man at the guitar shop phoned yesterday, so I went round to visit today. It looks like this; up close, bits of it look like this, this, and this. Now all I have to do is learn to play it. Easy.

OK, so suddenly everybody has an opinion on .NET; it seems like I may as well give you mine too. Here goes

• Copying an MS API gives me the creeps. It feels like Open Source is playing perpetual catchup with Redmond's Moving Goalposts, and I'm not totally convinced that this time the target is firmly planted. But I don't have any actual evidence that it won't be, so perhaps I had better Just Get Over It.

• The CLR is a nice virtual machine, if for some reason you need a virtual machine. Certainly beats the JVM (not, I grant you, that that's very hard). Most of the missing stuff in, say, CL (multimethods, a proper numeric tower, symbols, keyword arguments, etc) can be implemented on top of it

• The problem is that the CLR is also supposed to be a common interface language. If I'm programming in some putative Common Lisp .NET, any of my interfaces which use multimethods, arbitrary-sized numbers, symbols, or flexible argument list processing are not going to be available (or at least, meaningful) to users of other .NET-enabled languages. So, I can't use many of the natural idioms of my language in anything which is going to be exported. I'm going to take a guess that users of other "esoteric" (I say "high level") languages are in a similar situation; any general-use libraries in .NET are going to be either mostly written in C#, or mostly written in some arbitrary C#-like subset of whatever language they are in.

• I don't actually have a solution to this. I'm not sure there is one; I think it's a very hard problem. This is why it annoys me to read claims that Microsoft have found it.

The Deblog seems to be offline, so I replaced it with lemonodor - which I've been meaning to link to for a while, but was looking for another word to add to the first sentence.

Well, let's see#

Sat, 09 Feb 2002 03:28:57 +0000

Well, let's see. Now we're using the software fpcontrol register, with ffi calls to read and write it using ieee[sg]etfpcontrol(). We've lost the ability to set the rounding mode, but the evidence so far available suggests that only insane people want to do that anyway. The rest appears to be working, except that in sigfpe-handler we're using the current fpcontrol instead of the one in the sigcontext. This is because (according to grep *.[chS], anyway) the kernel appears not to ever fill in the scfp_control slot in the sigcontext. The one I looked at certainly didn't seem to contain the right answer.

OK, so we have more-working-than-it-was Alpha floating point, at least. In fact, as we actually look up which trap went off when we get a SIGFPE, we presently have more featured fp support on Alpha than we do on x86. Someone who cares can fix up x86 equivalently.

The Phoenix was showing Spinal Tap last night. Definitely worth watching

Last Monday (i.e two days following the previous entry here) I had#

Wed, 20 Feb 2002 11:21:25 +0000

Last Monday (i.e two days following the previous entry here) I had a sufficiently unpleasant experience trying to port a package with a homebrew system definition utility that I vowed to finish asdf - or at least, to get it to the point where it actually does anything useful. A week and a bit later, and here we almost are. It has a (minimal) test suite and everything. Look also at my proposed ASDF System standard, which I'm trying to get the cCLan guys to adopt for the next version of cCLan. It uses tar files It's really good!

The only real system it's been tried with is db-sockets, which is probably not the simplest system ever to have started with (foreign objects and some weird pre-processing needed). But it appears that pretty much everything I've written in CL that actually works requires db-sockets, so there wasn't a lot of option.

What else? Not a lot. Christophe got SPARC SBCL working and Bill Newman got it merged, so I'm lagging there as PPC is still 0.6.13-based and still has whatever that odd build problem was. Also haven't sent patches for the Alpha fp fixes yet. If anyone other than me is actually using SBCL on an Alpha, this would be a good time for him/her to apply peer pressure.

Oh, and Araneida in fact didn't have a file descriptor leak. The leak in that application turned out to be in the cheesy SMTP client code it also uses. Yay. Don't need to restart that every three weeks any more, then.

Not really getting on too well with this "Finish things"#

Mon, 25 Feb 2002 13:17:09 +0000

Not really getting on too well with this "Finish things" resolution, as asdf is now lingering around while I occupy my time with something else. My excuse for this is that asdf tickles a bug in clisp so we can reasonably wait for that to get fixed first. Actually, my real excuse is that GnuCash is now really annoying me and I need to replace it with something I understand, that doesn't keep adjusting the values in my split transactions, and that has more support for VAT. The thought of tying my invoicing and accounting together with something stronger than shell scripts is also kind of appealing.

I'm also looking into WAP. 4 lines of text is an information-poor channel; when considering that in any situation where one might visit a WAP site one could instead, say, make a voice call and have a much better user experience, it's going to be hard to make a sufficiently compelling application. Anyone have any worthwhile WAP sites they can recommend to me? The nearest thing I've found is the Railtrack site, which on a good day is marginally faster than phoning the enquiries line might have been.

Or was, anyway. Since my phone came back from the repair shop with all its bookmarks erased, I can't find the URL for the Railtrack site any more - it seems to be registration-only now. Bad Kizoom

Everyone else has already linked to this, but never mind. JavaLobby has an article on .NET which echoes fairly well my own position. They have included rather more pro-java partisan arguing than I would have liked, but to their credit they do seem to have coined the term ``skinnable language''

Note: In countries where the use of Bluetooth#

Mon, 25 Feb 2002 16:31:16 +0000

Note: In countries where the use of Bluetooth wireless technology is not allowed, you must ensure that the Bluetooth function is set to Off.

Ericsson Mobile Phone T39m User's Guide. Well, it made me laugh

Everyone knows that accountancy is dull#

Tue, 26 Feb 2002 11:47:08 +0000

Everyone knows that accountancy is dull. That notwithstanding, writing Rosemary (working title for my bookkeeping system which is clearly not Sage) over the last few days has been real fun. It's a rare opportunity to write a real Lisp program without having to worry about whether it will run on clisp.

The magic part of programming is when you make a change, run it, and see it do something that it didn't last time. All the specifications and test cases in the world are just nowhere near as compelling as actual running code. Programming. It's Better than Text.

This instant gratification is one of the reasons that I like Lisp: I can write a function and call it. No test harnesses or stubs, no compilation waits, no having to restart the session from the beginning and go through all the same steps as last time to recreate the bug. Interactive development is the future (and the present, and for some lucky people that never shut up about it, also the distant past)

And if it doesn't work, or it's ugly (and the first few drafts probably will be, unless you're superhuman), or you see a better way to do it - you revise it. This is reason #2: Lisp does not get in your way when you change your mind after the fact - and when you learn to relax and take advantage of that, instead of feeling guilty for not getting it right the first time, that's when you start to Win Big.

Here endeth the lesson. I'll save the lectures on macros and CLOS for another time.