On Fri, May 04, 2001 at 05:36:29PM +0100, Daniel Barlow wrote:
> I'm afraid it turned out to be a single patch after all. At first I
> tried to separate it into functional chunks, but the prospect of
> making a clean diff out of each (a lot of it is more interdependent
> than i realsied) and waiting three hours a time to see if it built and
> ran was too grim to contemplate. Apologies to anyone who didn't want
> to get 125k of attachments in their mail today.
(meta: When a message exceeds 40 kb, I get a note from Mailman asking
me to approve it. I approved this message, since I figured that this
should be OK for everyone. In general, I expect modern mailers can
handle a stream of patches faster than humans can generate it (and
certainly faster than I can integrate it). But if I'm wrong, and
lengthy patches are a hardship for people reading the list, please let
me know, and I can try to work out some procedure for putting any
future big messages up for anonymous FTP or something like that.)
OK, I'll start looking at The Patch this weekend. My progress toward
releasing 0.6.12 was interrupted by my old cheapo compute server
accelerating its slide into mad computer disease. I accelerated the
purchase of my new laptop, and thus I've been distracted by the joys
of setting up dual boot and dotfiles and ssh and all that good stuff.
Hopefully that won't distract me much longer, though. After that, it
should only require another hour or two of screwing around to release
0.6.12. After that, back to the European invasion of patches. (I've
started to fall behind on Martin's patches again, too!)
Until I spend some time looking at it, I won't have any sort of
reasonable guess as to how long it will take before it appears in the
> The tree from which this patch was generated does also work on x86 - I
> built with cmucl 2.4.19 (debian packages) and ran the tests. It
> won't run on BSD platforms until someone generates the necessary
> x86-bsd-types.lisp file - see below.
> I should point out here that there are still some quite sucky parts in
> this port. Where I've e.g. cut & pasted GC code wholesale from CMUCL
> please don't assume that I have no sense for maintainability and am
> willing to kludge everything in sight; I have a perfectly good sense
> for aesthetics (insofar as this is possible for anyone who's looked at
> the CMUCL runtime), but balanced by a sense that at least the d*mn
> thing works, let's get it into CVS as a baseline, and we can always go
> back and clean it up.
I can sometimes be a sneering aesthete but usually I can also see the
value of having something which works. As long as you avoided mixing
the really questionable duct-tape-and-bubblegum cruft into code which
already worked and used to be relatively clean, I'm sufficiently
psyched about the idea of a new port that I doubt I'll be very picky.
(And the other mailing list denizens are always pretty polite.:-)
If there's something particularly unacceptably nasty, I'll get back to
you.:-| But I doubt it can be much more unaesthetic than the
cut-and-paste job I did in order to get DEF-BOOLEAN-ATTRIBUTE to work
in the brave new SBCL cross-compiling world with its distinct
target-vs.-build-vs.-host names, and which I still haven't gotten
around to cleaning up..
[big, big snip of quoted material]
The explanatory comments you wrote [and I snipped] sounded reasonable
in general. And in particular, I just added the ".x86f"-to-".fasl"
change to the "planned incompatible changes in 0.7.x" section of NEWS
so that it will appear in the 0.6.12 release.
> (As a matter of interest, does anyone other than me on this list
> actually want to use sbcl on an Alpha? Never mind ...)
I'm fairly interested in anything which would offer a substantial
performance improvement. Do you happen to have any benchmark numbers
which show that an Alpha running SBCL or CMU CL substantially
outperforms a comparably expensive X86? (at any point in the price and
performance range, though I'd be pretty surprised if it was for cheap
machines) Otherwise, I'm agnostic. The Alpha architecture has got to
be less godawful than the X86, but there's a lot to be said for
working with an architecture which is nearly universal.
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C