diary at Telent Netowrks

I feel like I should be feeling happier about this than I am, but#

Thu, 03 Apr 2003 18:21:23 +0000

I feel like I should be feeling happier about this than I am, but it's worth noting anyway: SBCL thread support has landed in CVS HEAD. It's not enabled by default: you have to create/edit a customize-target-features.lisp file before building

:; cat customize-target-features.lisp
(LAMBDA (LIST) (cons :sb-thread list)) 

In the process I broken all the non-x86 ports, but a further commit fixing the worst of that will be forthcoming as soon as the PPC has finished building it.

I don't know why it feels like a complete anticlimax though. Maybe I need more coffee.

Anyway, feedback (preferably accompanied by bug fixes) to sbcl-devel grudgingly accepted.

And another thing#

Sun, 06 Apr 2003 03:07:57 +0000

And another thing ...

While I'm grousing, I should add that I'm still not convinced the ALU cliki has developed any kind of identity independent of CLiki itself, and I'm really beginning to wonder why I bothered.

Perhaps I should have countered the people who said "CLiki is restricted to free-software projects, and this is a bad thing; there should be a more general forum for all kinds of Lisp users" by saying "so go and make one". You can't advertise Xanalys LispWorks on www.franz.com, why should you expect to be able to advertise Allegro CL on CLiki?

(I should add here that I don't have either of Franz or Xanalys in mind when I say "these people" - they're just the first two proprietary Lisp vendors that come to mind)

Lispers love to talk about their work and their favorite language, to help students, and to give away stuff.
-- http://www.lisp.org/table/community.htm

Ho Fscking Ho.

Proposed UNIX#

Thu, 10 Apr 2003 02:46:52 +0000

Proposed UNIX interface for SBCL

The ads that Sourceforge insert in the footers of messages from the email lists they host are usually both amusing and saddening, and the reason is the same in both cases: their complete inapplicability. In 90% of cases they advertise closed-source development aids for problems that dynamic languages don't even have anyway. "Debugging C/C++ programs can leave you feeling lost and disoriented". So Don't Do That Then ...

Superfluous link to someone's weblog entry#

Tue, 15 Apr 2003 00:42:43 +0000

Superfluous link to someone's weblog entry

So what did I do this weekend?

On Saturday I missed the GLLUG meeting, but turned up to the pub afterwards.

On Sunday I implemented some bits of the SB-POSIX interface. Knowing that comp.lang.lisp posters from time to time complain about the lack of a standard POSIX interface, I also posted its specification there in the hope of stimulating some discussion about whata standard should look like.. Almost all the discussion I managed to stimulate was about the package name, so I'm lacking any real guidance as to whether people think it otherwise (a) sucks ass, (b) is good enough in all other respects not to need comment, or (c) is fundamentally uninteresting. Ho hum. That said, if I had had a bunch of followups saying "this is really great" I wouldn't have been a lot more pleased about it anyway: "this is really great and I'm going to lobby my vendor to implement it", or "this is really great, and I am a vendor so will implement it" is more what I would consider a positive response. Never mind.

And today, in between telephone calls, I figured out most of how to make RPM automatically get package dependency information from the asdf :depends-on options. So far ...

:; ls
clx-0.5-1_circle.i386.rpm
detachtty-7-1_circle.i386.rpm
hemlock-2003.03.06-1_circle.i386.rpm
ilisp-5.12.0.2003.03.22T193233-1_circle.i386.rpm
odcl-1.3.1.20030410T230844-1_circle.i386.rpm
sbcl-0.pre8.54-1_circle.i386.rpm
uncommonsql-1.2.0.20030410T231957-1_circle.i386.rpm
uncommonsql-postgresql-1.2.0.20030410T231957-1_circle.i386.rpm

(All this stuff built with Red Hat 8). I want to add araneida, cliki, and maybe the series library to this. I probably want to make it do Debian packages as well (it sort of does already, but it cheats by using alien, so the dependencies are a bit skewed).

  1. 2: "How do I get my hands on this". A: "send me some money". #3: "isn't that against the principles of free software?" A: "no". Details forthcoming (or send email if you can't wait) but if you're new to Lisp, this stuff will save you more time fiddling with badly documented install procedures than you ever spent trying to configure Wine before giving up and buying Crossover Office.

The default Lisp syntax highlighting in Red Hat 8.0's vim is possibly#

Tue, 15 Apr 2003 19:08:20 +0000

The default Lisp syntax highlighting in Red Hat 8.0's vim is possibly the ugliest thing I have seen on a computer all week.

They say that once you've learnt to ride a bike you never forget#

Fri, 18 Apr 2003 03:50:35 +0000

They say that once you've learnt to ride a bike you never forget. Or is that elephants? I have trouble visualising an elephant riding a bicycle, but suspect it needs one like a woman needs a fish.

Anyway. Um. Not cycling, but I hope some similar law of nature applies to driving a car, because not having sat behind the wheel of one since about 13 months ago, I've rented a vehicle to get me to Milton Keynes on Tuesday.

(Car hire companies all seem to have this bizarre rule that you can't hire a car until your driving license is at least a year old. Makes no sense to me, but never mind)

So I've been working a little more on this packaging lark, trying to beat ilisp into the kind of shape that it will install and do anything useful without requiring the services of an emacs guru. Which involved what looks suspiciously like an emacs bug. (Phoenix 0.5 users are cautioned against clicking on that link: at least on my machine, it hangs the browser). I'm being continually reminded that there's lots of stuff that I as a relatively seasoned lisp user don't usually even notice, but which would probably cause the newbie to reach for his support line. Or (which is probably just as bad) cause him to develop a tolerance for random spewage which would lead to his missing messages that actually are important.

Anyway, now you can type circle at a shell prompt, and it updates your .emacs file, launches emacs, starts sbcl, that kind of stuff. And so we edge gradually closer to something that's actually usable.

And fixed a few random SBCL threading bugs. I still need to muck around with the wait queues a little, and probably to export the symbols from timer-related functions, but I think we're at the point where we could usefully put out pre-release binaries to pick up a slightly wider test audience. (I believe that Debian unstable users can do this already, thanks to kmr: apt-get install sbcl-mt. If they are doing, though, they aren't reporting bugs)

There's a lesson here about the dangers#

Sat, 19 Apr 2003 20:44:13 +0000

There's a lesson here about the dangers of sloppy text parsing.

Sigh#

Sun, 20 Apr 2003 17:48:48 +0000

Sigh. I checked my mail this afternoon to find that judging by the number of bounces in it, someone is spamming with my name in the From address. If you have mail from me that doesn't look like something I would typically have sent, look at the headers. Unless it was sent from 81.103.195.118 or 64.49.254.81, it probably wasn't anything I wrote.

I guess it's time to start routinely GPG-signing all the email I send. 1024 bit DSA key, id 75908913, accept no substitutes.

After testing SBCL/threaded on a real SMP system, I quite rapidly#

Sun, 20 Apr 2003 22:29:38 +0000

After testing SBCL/threaded on a real SMP system, I quite rapidly (well, rapidly after adding appropriate debugging cruft to stop all the threads as soon as any of them fails an assertion) found several places it really could have used locks and didn't have. So now it has, and I'm looking for weirdness in the decide-when-to-gc code. More precisely, I'm typing this while watching it rebuild after having removed a lot of cruft in the decide-when-to-rebuild code. If it's still broken after doing this, at least it'll be more obvious how.

I think we're probably going to do a 0.pre8 release at or around the end of the month so that a slightly wider audience can bang on it.

So you may have seen this elsewhere already, but the Unix-Haters Handbook is now online#

Thu, 24 Apr 2003 11:38:40 +0000

So you may have seen this elsewhere already, but the Unix-Haters Handbook is now online. After reading Donald Norman's foreword, I went to look for the article he cites:

Norman, D. A. The Trouble with Unix: The User Interface is Horrid. Datamation, 27 (12) 1981, November. pp. 139-150. Reprinted in Pylyshyn, Z. W., & Bannon, L. J., eds. Perspectives on the Computer Revolution, 2nd revised edition, Hillsdale, NJ, Ablex, 1989.

eventually finding it it in a shar archive in a message in a unix-wizards archive in Google cache. To make it slightly easier to index in future, here's a link to the unpacked messages. rumor.shrink is the original article, it appears.

Oh, two hundred and something miles later and still alive, yes. I didn't mention to the care hire company that I hadn't driven since passing my test a year ago, it wouldn't have been kind.

If I can't remember much of what I did this weekend, that might#

Mon, 28 Apr 2003 01:55:57 +0000

If I can't remember much of what I did this weekend, that might suggest that it was too boring to be worth writing about. On the other hand, it might suggest that I should write down what little of it I canremember, so that I have some record of it in future times. Very well then. On Friday more Milton Keynes fun, which of course involved more zipping around the countryside to get there and back. On Saturday I had to get up early (ish. early for a Saturday, at any rate) to return the car, then took the last few weeks (or more likely, months) collection of empty bottles to the bottle bank, then came home and fell asleep until lunchtime. Substantial portions of afternoon/evening then spent talking to Christophe on IRC trying to find why SBCL was allocating without setting the pseudo-atomic flag first. Eventually found a piece of code that was at least likely to be the place where the problem occurred (gdb is sometimes imperfect when it comes to debugging code that doesn't use the C calling convention) and found that it was using the unithread pseudo-atomic setup, not the threaded one. So, blamed it on stale fasls.

Subsequently, Christophe indeed found one or more stale fasls: sh clean.sh appears to have made the problem go away

Today I've been looking for GC bugs. These aren't the usual unfriendly bugs which are probably somewhere else altogether and only manifest during gc because that's when we next scan the heap and actually notice it has seven kinds of memory corruption in it. This is simply that gc is not actually running as often as we'd really like it to, so by using enough threads and making them allocate fast enough we can run the system out of virtual memory.

Part of the problem is that there are all kinds of situations in which GC is disabled and a call to the collector returns immediately - pseudo-atomic, WITHOUT-GCING, and recursive entry to the collector are just three of them. The other part is that GC is actually done by signalling the GC thread, and this allows the potential for all kinds of interesting behaviour if it's already doing something when we signal.

Found an intersting LWN article which kind of suggests not only that we can co-exist reasonably happily with NPTL, but that, come the revolution, we can use the "Wine" GDT entry instead of having to muck around with LDTs and therefore limit ourselves to only 8192 threads