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).
- 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
