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
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
ftx13, out now#
Mon, 04 Feb 2002 13:20:19 +0000
ftx13, out now.
Mon, 04 Feb 2002 23:07:47 +0000
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
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
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.