Barton Willis wrote:
Hi,
> Have the Sage developers rejected SBCL + Windows?
Yes. We want a self hosted, compile from scratch lisp, so neither sbcl
nor cmucl fit the bill. If we required a lisp in the first place we
wouldn't be in this pickle, but the concern is that if non-cs people are
required to provide a lisp machine they will likely not use Sage.
> The SBCL + Windows +
> Maxima testsuite runs with no errors in 52 seconds; with GCL, the
> testsuite runs in 43 seconds. But I don't think that the SBCL build
> works for anything but the command line.
>
> SBCL for Windows still has the "kitten of death" warning. And the SBCL
> + Windows is a few versions behind the current version.
Do you mean
http://sourceforge.net/mailarchive/message.php?msg_name=877ifavq4r.fsf%40cantab.net
i.e.
[begin quote]
Well, I'm no Windows expert, but as I understand it, once a shared
library (DLL) is mapped into any process's address space, that shared
library will be mapped at the same address for all processes that use
that DLL. In particular, this can cause the mapping location for
other DLLs to change, depending on what order the programs are started
in.
Certain programs (XEmacs has historically seemed to be quite a
culprit) seem to use DLLs in such a way as to cause some of SBCL's own
DLLs to be mapped at addresses in the middle of the address space
range used for SBCL's Lisp heap. This causes SBCL to fail to start
up.
[end quote]
Sage itself not only loads up to 180 extensions to python at startup,
but can also have GAP, Singular and others running in parallel at some
point. So the chance of hitting the "kitten of death" are quite high
IMHO. We are also porting Sage to MSVC since we want a 64 bit port and I
am not sure if sbcl does that. I would be surprised if they did such a
port, but I hadn't had the time to do any research.
> There are some signs of life for GCL + windows: see
>
> http://lists.gnu.org/archive/html/gcl-devel/2008-04/msg00004.html
> http://ftp.gnu.org/gnu/gcl/
I wouldn't say that this qualifies as sign of life, but the gcl binary
is MinGW. And that despite some effort by the MinGW people is still 32
bits only. While there is some alpha code from MinGW that lets you
compile gmp in 64 bit mode for example I am not quite sure how far that
will take us to a 64 bit g++ for example. The MinGW people would also
have to decide which C++ runtime by MS to support, but this is getting
off topic here, so I won't bother you with the details.
> Binaries for GCL 2.6.7 were posted earlier this year. I don't know if
> Maxima runs OK with GCL 2.6.7.
Sure. But since we want one lisp for all supported platforms and my
build experiences with gcl on OSX Intel, Solaris and even x86-64 were
less than stellar. All those issues can be fixed, but that is not my
job. We had a long drawn out discussion about all this and if anybody
cares I can point them in the right direction.
> Barton
Cheers,
Michael
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>