It's summer. So says my laptop, anyway. I can't remember what timezone this colo box thinks it's in, though.
Spent some time yesterday and today attempting to determine why SBCL unithread-build-of-threaded-code didn't: a variety of silly bugs which nobody is interested in reading about
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.
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
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).
Predicted FAQ #1: "Native threads?" A: "Experimental, but yes".
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. 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 of sloppy text parsing.
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 (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. 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 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
