I'll believe it when I see it.

In both cases the hard part, porting the garbage collector
is yet to come. Basically, any work done without having
ported the gc is likely to be wasted. To create reliable
gc it is likely that you will have to modify fundamental
data structures ( remember you will have to take
into account interactions with dll ).

I think anyone porting either compiler is not going to
be successful. It's better to examine the gc and determine
what is needed to get it to work and make detailed
notes. That way if you give up, at least someone else
can grab your notes and pick up where you left off.

Sorry, Mr Coward, but that's simply not true. At least Alastair Bridgewater has a working GC: it must be, because the build completes — and we know how consy the sbcl compiler is.

Where did you get your misinformation, anyway?

>At least Alastair Bridgewater has a working GC:
>it must be, because the build completes
Please clarify. It seems to me that
the GC compiiling just indicates there are
no compilation errors. It doesn't
guarantee that the GC is correct.
To see that you need to get past the first GC.
Even that is not enough. A GC might corrupt
memory and the program still runs. It's a while after
the first GC, or even the second GC that you can
be sure.

I got the info by scanning through the changes. I didn't
see any significant changes to the GC. Perhaps I missed
it, so you can point out where the changes to the GC are?

Mr Coward,

I wasn't referring to compilation of the GC indicating that the GC works, obviously. When the SBCL system is built (in the phase known as "target-2"; see http://sbcl-internals.cliki.net/Build and links therefrom), several components (including PCL, the tracer, the profiler, the inspector, and DOCUMENTATION support) are built by the newly-born lisp, running the newly-built runtime, including the garbage collector. Of the order of fifty or so garbage collection cycles occur during this phase of the compilation, every one of them in the new GC.

So, while this is by no means enough to state that the GC port is bug-free, it does meet your "a while after the first GC" criterion.

I've only got two Linux boxes, and one is dual boot
mostly on Windows. The other is a local file server
and print server. I can develop on it, but I usually
need to move stuff around to make room.

As a result I haven't yet had a chance to build it
precisely because you build it on a Linux box. As is
stated in Bridgewater's post to the sbcl-devel list.

> Thus far, all compilation has been done using a mingw cross-
> compiler (gcc 3.3.1) on a Linux box and sbcl 0.8.5. You may
> need to modify the Config file for the runtime to suit the
> compiler you end up using.

So he is cross compiling on a Linux box.
So the GC that he is testing is the GC on the Linux version of
SBCL not the Windows version. We already know that works.

If you know how to build it on Windows let me know. Reading
code will get you there, but playing with the executable often
gets you there faster.

Mr Coward, you're beginning to get boring.

He may be mostly cross-compiling on a Linux box, but, as I have said, and will say one more time for the clearly hard of comprehension: several components (including PCL, the tracer, the profiler, the inspector, and DOCUMENTATION support) are built by the newly-born lisp, running the newly-built runtime, including the garbage collector. If Alastair has managed to remove this requirement, he's done something that is technically much more challenging than a simple port to Windows. I'm pretty sure he hasn't, so what he means by the statement you quoted was that the host compiler he used was a Linux binary of sbcl 0.8.5; which is fine, but during the build of a new sbcl the new runtime gets involved a long way before the end. Please believe me on this one.

As for building on windows, it ought to be possible to use clisp (a win32 version) as a cross-compiler. You'll also need a C development environment, of course; mingw seems like the most likely candidate. The catch is that clisp developers have the habit (not intentional, of course) of destroying clisp's ability to build sbcl's lisp code. Try the latest release (2.33.2) and mail sbcl-devel if you have problems.