From: ·······@my-deja.com
Subject: SBCL, a new free Common Lisp based on CMU CL
Date:
Message-ID: <87nck5$6gh$1@nnrp1.deja.com>
I'm working on SBCL,
http://sbcl.sourceforge.net/
a variant of CMU CL which should be easier to
maintain than CMU CL. Some of the changes involved -- especially
making the system bootstrap itself cleanly -- involved major surgery
on the CMU CL code base, not just local patches, and the result is a
distinct version of the system.
I consider the new release of SBCL (sbcl-0.6.0) to be alpha quality,
unstable but fairly usable.
Some changes in sbcl-0.6.0 relative to CMU CL include:
* The system can bootstrap itself cleanly, unlike CMU CL, whose
bootstrap process involves elements of mutating a running CMU CL
into a new executable. Thus
** Arbitrarily large changes to SBCL can be made without having to
set up special hacks to keep the changes from breaking the
cross-compilation host. (Such bootstrapping issues are a
fertile topic of conversation on the CMU CL list, but should
not be interesting in SBCL.)
** The target system is completely described by the source code
of the current version, without stealth contributions from
the source code from previous versions. (It should not be
interesting to "recompile the system with itself a few times
until things settle down".)
* There are some improvements in ANSI compliance (especially in the
behavior of PRINT-OBJECT and STYLE-WARNING).
* There are various other bug fixes.
* Many non-ANSI extensions have been simplified, e.g. environment
variable handling, options to COMPILE-FILE.
* Many non-ANSI extensions have been cleaned up, e.g. i/o handling in
the debugger.
* Many non-ANSI extensions are no longer supported, e.g. sockets,
X11, and the Hemlock editor.
The SBCL system is smaller than CMU CL, but as of 0.6.0 that doesn't
really show up in the size of compiled code, since the sbcl-0.6.0
core is entirely native code, while CMU CL uses byte compilation for
non-speed-critical code. "Entirely native code" sounds a little like a
feature, but it's really a bug, which will probably be fixed at some
point. Once SBCL can byte compile itself, the compiled code for SBCL
should become significantly smaller than CMU CL.
Version 0.6.0 of SBCL has a number of drawbacks compared to CMU CL:
* It's almost certainly buggier, since it's an alpha release.
* The system only runs on Linux/x86. (This isn't for any
fundamental reason, only because no one has ported it.
Porting SBCL should be comparable in difficulty to porting CMU CL;
porting SBCL to an architecture already supported by CMU CL should
be pretty easy.)
* The documentation is not as good as CMU CL's. In particular, there
is no SBCL user manual yet, only a man page and doc strings, so
if you need user manual information, you have to refer to the
CMU CL user manual.
Besides the particular shortcomings of version 0.6.0, SBCL will
probably always have some drawbacks compared with CMU CL:
* SBCL doesn't try to be backwards compatible with most of the
CMU CL non-ANSI extensions. (However, I have retained the FFI
extensions, which are the fundamental building blocks for most of
the other stuff; and I'd be happy to distribute ports of the other
CMU CL extension packages as contrib/ code if someone else would
like to maintain them. I just don't want to maintain them myself.)
* I've been willing to simplify the system even at some cost to
performance, so SBCL may be slower than CMU CL in some respects.
(E.g.,
I've removed memory pooling in the compiler, so the SBCL compiler
conses
more than CMU CL's; and the SBCL READ-SEQUENCE implementation has
fewer
performance-oriented special cases than CMU CL's (and is hopefully
less buggy, too:-).)
* Despite my desire for simplicity, in some ways the SBCL code is
necessarily more complicated than the CMU CL code, because SBCL
maintains a clean separation between cross-compilation host and
target system instead of sharing things opportunistically between
them. I believe the benefits of this clean separation easily pay
for the costs, but the costs are noticeable. (Common Lisp is not
a cross-compiler-friendly language.:-)
As an aside to anyone who looked at the previous, pre-alpha version
(sbcl-0.5.0):
The bootstrap process in the current version is less of a memory pig
than in 0.5.0. In 0.6.0, bootstrapping takes on the order of 40 Mb
through most of the build phase and peaks at a little under 128 Mb.
The peak usage occurs in the "genesis" phase (static linking, more
or less), which doesn't stress the virtual memory system very hard, so
building the system works fine on my old laptop (P133 with 48 Mb of
RAM and 128 Mb of swap).
SBCL is available at
http://sbcl.sourceforge.net/
This site maintains mailing lists for SBCL, and SBCL-specific
discussion (e.g. "Can I run SBCL on a non-ELF system?" or "When are
you planning to make a user manual?") probably belongs there instead
of comp.lang.lisp.
Bill Newman
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C
Sent via Deja.com http://www.deja.com/
Before you buy.
Very cool work. Hopefully this will increase the number of
people working on free CL implementations.
·······@my-deja.com <·······@my-deja.com> wrote:
[...]
> Porting SBCL should be comparable in difficulty to porting CMU CL;
Why is this? Shouldn't it be easier because of the simplified
bootstrapping? Do you mean that the bootstrapping issues are
insignificant compared to the rest of the port.
Can SBCL be compiled with any CL implementation or does it have
to be compiled with itself?
Neil
Centuries ago, Nostradamus foresaw a time when Neil Schemenauer would
say:
>Very cool work. Hopefully this will increase the number of
>people working on free CL implementations.
Perhaps.
If SBCL is an easier port than CMU CL, this may make it of more
interest. The claim below suggests that this is not the case.
If it is easier to work on than CMU CL, this make it easier for people
to work on it.
Aside from that, if it divides peoples' interests, confusing people as
to whether it is better to work on one or the other, that would *not*
be a good thing. Similarly, if it means that there are two CL
codebases that need maintaining, that is not too much of an
improvement either.
>·······@my-deja.com <·······@my-deja.com> wrote:
>[...]
>> Porting SBCL should be comparable in difficulty to porting CMU CL;
>
>Why is this? Shouldn't it be easier because of the simplified
>bootstrapping? Do you mean that the bootstrapping issues are
>insignificant compared to the rest of the port.
>
>Can SBCL be compiled with any CL implementation or does it have
>to be compiled with itself?
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying
to produce bigger and better idiots. So far, the Universe is
winning." -- Rich Cook
········@ntlug.org- <http://www.ntlug.org/~cbbrowne/lisp.html>
········@news.hex.net (Christopher Browne) writes:
> Aside from that, if it divides peoples' interests, confusing people as
> to whether it is better to work on one or the other, that would *not*
> be a good thing. Similarly, if it means that there are two CL
> codebases that need maintaining, that is not too much of an
> improvement either.
The way you have written this makes it sound as though you are overall
negative about the existence of the SBCL project. Is this a correct
summary, and if so do you have similar opinions regarding, say, NetBSD
vs FreeBSD vs OpenBSD?
Personally I think that the two projects have differing objectives and
development styles, and that people will have little trouble deciding
which to contribute to. I'm sure that code in each will find its way
into the other if it's deemed appropriate.
Another writer writes:
> >Can SBCL be compiled with any CL implementation or does it have
> >to be compiled with itself?
SBCL 0.5.0 could be compiled at least with itself and with CMUCL. I
don't know about 0.6 as I haven't tried it yet, but I believe it to be
a goal that other CLs be able to compile it.
-dan
From: ·······@my-deja.com
Subject: Re: SBCL, a new free Common Lisp based on CMU CL
Date:
Message-ID: <87smaa$t4$1@nnrp1.deja.com>
In article <··············@tninkpad.telent.net>,
Daniel Barlow <···@tninkpad.telent.net> wrote:
> ········@news.hex.net (Christopher Browne) writes:
>
> > Aside from that, if it divides peoples' interests, confusing people
as
> > to whether it is better to work on one or the other, that would
*not*
> > be a good thing. Similarly, if it means that there are two CL
> > codebases that need maintaining, that is not too much of an
> > improvement either.
>
> The way you have written this makes it sound as though you are overall
> negative about the existence of the SBCL project. Is this a correct
> summary, and if so do you have similar opinions regarding, say, NetBSD
> vs FreeBSD vs OpenBSD?
>
> Personally I think that the two projects have differing objectives and
> development styles, and that people will have little trouble deciding
> which to contribute to. I'm sure that code in each will find its way
> into the other if it's deemed appropriate.
Forking has very real drawbacks. I think it makes sense in this case,
but it can certainly be a problem, and I've worried about it.
The existence of SBCL will probably cause some effort to be wasted as
work is duplicated on both branches. This will be bad.
I hope that the existence of SBCL will make it possible to do things
which weren't practical before (because of bootstrapping or other
problems). This will be good.
I also hope that the ease of rebuilding SBCL will attract developers who
would have been turned off by CMU CL. This will be good too.
I think it's reasonable to hope that the good effects will be more
important than the bad ones, but only time will tell.
> Another writer writes:
> > >Can SBCL be compiled with any CL implementation or does it have
> > >to be compiled with itself?
>
> SBCL 0.5.0 could be compiled at least with itself and with CMUCL. I
> don't know about 0.6 as I haven't tried it yet, but I believe it to be
> a goal that other CLs be able to compile it.
As I wrote in another branch of this thread:
with CMU CL: yes
with SBCL itself: yes
with CLISP: no (because CLISP doesn't have MAKE-LOAD-FORM)
with other Common Lisp systems: probably, but untested
As far as I know, the only things needed from the host Lisp, besides the
core ANSI functionality, are ASCIIness of characters and
IEEEness of floats. That could be fixed, but without a non-ASCII or
non-IEEE system to test on, I'm not motivated to fix it.
Bill Newman
Sent via Deja.com http://www.deja.com/
Before you buy.
Centuries ago, Nostradamus foresaw a time when Daniel Barlow would say:
>········@news.hex.net (Christopher Browne) writes:
>> Aside from that, if it divides peoples' interests, confusing people as
>> to whether it is better to work on one or the other, that would *not*
>> be a good thing. Similarly, if it means that there are two CL
>> codebases that need maintaining, that is not too much of an
>> improvement either.
>
>The way you have written this makes it sound as though you are overall
>negative about the existence of the SBCL project. Is this a correct
>summary, and if so do you have similar opinions regarding, say, NetBSD
>vs FreeBSD vs OpenBSD?
>
>Personally I think that the two projects have differing objectives and
>development styles, and that people will have little trouble deciding
>which to contribute to. I'm sure that code in each will find its way
>into the other if it's deemed appropriate.
No, I'm not negative, I'm simply wondering why it is useful to have
both SBCL and CMUCL.
I can't usefully distinguish between them at this point, which is the
"problem" I'm trying to resolve.
The (Net|Free|Open)BSD situation unfortunately shows that the
respective communities of developers *prefer* to be separate; enough
flames emerge to show that the separations are not solely on technical
grounds.
It may be that SBCL will prove to be significantly easier to
maintain/port than CMUCL, or that it will, due to *apparent* ease of
participation, attract significant development efforts. Those would
both be good things, and would be good "excuses" for its existence.
On the other hand, if having SBCL doesn't result in increasing the
number of overall developers working on CL implementations, this is
not an improvement, and could detract from both SBCL and CMUCL. I
would consider that a "negative" thing, unless it had the simultaneous
sideeffect of SBCL being greatly easy to maintain, thus meaning that
equivalent maintenance requires fewer developers.
--
"... the most important thing in the programming language is the name.
A language will not succeed without a good name. I have recently
invented a very good name and now I am looking for a suitable
language." -- D. E. Knuth, 1967
········@ntlug.org- <http://www.ntlug.org/~cbbrowne/lisp.html>
········@news.hex.net (Christopher Browne) writes:
> I can't usefully distinguish between them at this point, which is the
> "problem" I'm trying to resolve.
Well there is at least one useful distinction between them at this
point (in fact there are a few more): SBCL is vastly more
experimental and fluid than CMUCL, which has it's positive and
negative implications: As it stands SBCL and it's implementor(s) are
at liberty to diverge from decades-old implementation and interface
decissions, that maintainers of CMUCL would find it hard to do.
This allows SBCL to be cleaned up quite a lot, and by the shaking up
of the code base, a number of benefits might follow. Or then again
they might not follow. One doesn't know in advance, so the only
possibility of finding that out is to try it out, since there is no
practical possibility of doing the SBCL project inside the CMUCL
main-branch of development (it would also be totally confusing to
suddenly have two CMUCL's which are quite incompatible).
> The (Net|Free|Open)BSD situation unfortunately shows that the
> respective communities of developers *prefer* to be separate; enough
> flames emerge to show that the separations are not solely on technical
> grounds.
But project organization and communities are never about technical but
always about social issues. There are no "technical" reasons for not
merging all Unix-like OS's into one. But there are social, economic
and practical reasons for not wanting to do that.
> On the other hand, if having SBCL doesn't result in increasing the
> number of overall developers working on CL implementations, this is
> not an improvement, and could detract from both SBCL and CMUCL. I
> would consider that a "negative" thing, unless it had the simultaneous
> sideeffect of SBCL being greatly easy to maintain, thus meaning that
> equivalent maintenance requires fewer developers.
I don't quite agree with this. One possible outcome of the SBCL
project might be that the "technology" and work behind SBCL will prove
sufficiently useful that it will be readopted/merged back into CMUCL,
thereby rejuvenating CMUCL and increasing CMUCL developer
productivity.
Or a number of other possible outcomes might ensue. Let's wait and
see...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: ·······@my-deja.com
Subject: Re: SBCL, a new free Common Lisp based on CMU CL
Date:
Message-ID: <87s37e$hcl$1@nnrp1.deja.com>
In article <······················@news1.rdc1.ab.home.com>,
········@enme.ucalgary.ca (Neil Schemenauer) wrote:
> Very cool work. Hopefully this will increase the number of
> people working on free CL implementations.
>
> ·······@my-deja.com <·······@my-deja.com> wrote:
> [...]
> > Porting SBCL should be comparable in difficulty to porting CMU
CL;
>
> Why is this? Shouldn't it be easier because of the simplified
> bootstrapping? Do you mean that the bootstrapping issues are
> insignificant compared to the rest of the port.
That's basically it. Not only is the rest of the port a lot of work, but
this is a situation where CMU CL has a standard way of resolving the
bootstrapping issues (changing the compiler backend on the fly by
tweaking the *BACKEND* variable which is there for just this purpose) so
the bootstrapping issues are relatively small in this case.
> Can SBCL be compiled with any CL implementation or does it have
> to be compiled with itself?
sbcl-0.6.0 should be compilable with any ANSI Common Lisp as long as it
uses ASCII characters and IEEE floating point. The ASCII and IEEE
dependencies should be fixable without too much trouble, but I haven't
been motivated to try since I don't have non-ASCII or non-IEEE system to
test it on.
I have only tested bootstrapping on CMU CL, CLISP, and SBCL itself. SBCL
itself works, of course. CMU CL works, although for the current version
because the SBCL sources have to use some #+CMU patches to work around
lack of PRINT-OBJECT support and a bug in READ-SEQUENCE. CLISP doesn't
work, because there's no way to work around its lack of support for
ANSI's MAKE-LOAD-FORM.
Bill Newman
I hope this message comes out to be less ugly than the announcement. The
announcement had a lot of hard newlines in it (created in emacs then
pasted into the Deja "Type your Message here" box), and although it
looked fine on the Deja preview feature, it ended up looking rather
nasty when I asked Deja to view it as an ordinary article..
Sent via Deja.com http://www.deja.com/
Before you buy.
From: Andrew Cooke
Subject: Re: SBCL, a new free Common Lisp based on CMU CL
Date:
Message-ID: <87s674$jee$1@nnrp1.deja.com>
In article <············@nnrp1.deja.com>,
·······@my-deja.com wrote:
> I'm working on SBCL,
[...]
I guess you've got your reasons, but...
...WOT NO SOCKETS?!
Surely sockets are becoming more and more important as networking
becomes a bigger and bigger part of computing. Is this for portability?
Is it possible to improve CMUCL's portability without removing such
major features?
Andrew
http://www.andrewcooke.free-online.co.uk/index.html
Sent via Deja.com http://www.deja.com/
Before you buy.
From: ·······@my-deja.com
Subject: Re: SBCL, a new free Common Lisp based on CMU CL
Date:
Message-ID: <87si0h$ssa$1@nnrp1.deja.com>
In article <············@nnrp1.deja.com>,
Andrew Cooke <······@andrewcooke.free-online.co.uk> wrote:
> I guess you've got your reasons, but...
>
> ...WOT NO SOCKETS?!
>
> Surely sockets are becoming more and more important as networking
> becomes a bigger and bigger part of computing.
I threw most of the non-ANSI stuff overboard both for the practical
reason that I was already overwhelmed with stuff to update and maintain
and for the aesthetic reason that I prefer relatively simple core
systems. As I wrote earlier, since I kept the building blocks for it
(the ALIEN and C-CALL packages), it should be straightforward to put
this sort of stuff back in as extensions if someone is motivated to do
so.
Incidentally, I certainly agree connectivity is important: the
application that I work on most limps along connected to a driver
program through *STANDARD-INPUT* and *STANDARD-OUTPUT*, and it's
sometimes a hassle. But I'm not convinced that sockets in general or the
CMU CL sockets library in particular are so clearly the best solution
(what about CORBA? or a port of Perl's socket interface?) that they
should be a mandatory part of the system. And in any case I'm just not
prepared to try to support more stuff.
> Is this for portability?
>
> Is it possible to improve CMUCL's portability without removing such
> major features?
It didn't have much to do with portability -- sockets exist on every
machine that the system is likely to run on in the foreseeable future.
It's just reducing the maintenance burden and core system size.
Bill Newman
Sent via Deja.com http://www.deja.com/
Before you buy.
From: Fernando D. Mato Mira
Subject: Re: SBCL, a new free Common Lisp based on CMU CL
Date:
Message-ID: <38A42F71.698C3FEF@iname.com>
·······@my-deja.com wrote:
> In article <············@nnrp1.deja.com>,
> Andrew Cooke <······@andrewcooke.free-online.co.uk> wrote:
> > I guess you've got your reasons, but...
> >
> > ...WOT NO SOCKETS?!
> >
> > Surely sockets are becoming more and more important as networking
> > becomes a bigger and bigger part of computing.
>
> I threw most of the non-ANSI stuff overboard both for the practical
> reason that I was already overwhelmed with stuff to update and maintain
> and for the aesthetic reason that I prefer relatively simple core
> systems. As I wrote earlier, since I kept the building blocks for it
> (the ALIEN and C-CALL packages), it should be straightforward to put
> this sort of stuff back in as extensions if someone is motivated to do
> so.
>
> Incidentally, I certainly agree connectivity is important: the
> application that I work on most limps along connected to a driver
> program through *STANDARD-INPUT* and *STANDARD-OUTPUT*, and it's
Euh.. Can one use ILISP?
Also, can we get COMPILER-LET? Otherwise, someone will just have to define
a macro that does
the same inside the SERIES code.
Thanks,
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
I've just spent a few hours trying to get SBCL to build and
run under FreeBSD 3.4. Not that I've got anything against Linux, but
I'm quite happy with FreeBSD...
For the lisp runtime "driver", I've stolen FreeBSD-os.[ch] from
the latest CMUCL sources (a couple of patches to FreeBSD-os.c was
required). I also had to patch x86-assem.S to cater for the
fact that FreeBSD 3.x, like Linux, does not prepend an underscore to
external names. I also made a change to genesis.lisp
(lookup-foreign-symbol) for the same reason.
Using the CMUCL snapshot from 1999-12-06, I can easily get as
far as creating cold-sbcl.core, sbcl.h and sbcl. When I try to run
sbcl with cold-sbcl.core, I get a core dump - not exactly what I'm
looking for :-)
The core dump seems to appear just after a call to
mmap - I had an idea that this might be because the mmap call resulted
in a zeroing of program text, so I have played around a bit with the
mappings in x86-validate.h. There may be some settings in a lisp file
that has to be modified similarly; hints, anyone?
Is anybody else working on getting SBCL to work on FreeBSD?
//Raymond.
--
Raymond Wiker
From: ·····@markwatson.com
Subject: Re: SBCL, a new free Common Lisp based on CMU CL
Date:
Message-ID: <889dnv$q8i$1@nnrp1.deja.com>
I found the install and setup for Caldera OpenLinux 2.3 to be easy!
Good job.
BTW, would it be a possibility to get SBCL ported to
WIN32 using the Cygnus development tools?
Thanks,
Mark Watson, author, AI hacker :]
www.markwatson.com
In article <············@nnrp1.deja.com>,
·······@my-deja.com wrote:
> I'm working on SBCL,
> http://sbcl.sourceforge.net/
Sent via Deja.com http://www.deja.com/
Before you buy.
>>>>> "markw" == markw <·····@markwatson.com> writes:
markw> I found the install and setup for Caldera OpenLinux 2.3 to be easy!
markw> Good job.
markw> BTW, would it be a possibility to get SBCL ported to
markw> WIN32 using the Cygnus development tools?
My understanding is that Cygwin does not support everything that CMUCL
needs. This includes mmap and access to the processor context on
interrupts.
So SBCL won't really help in getting CMUCL to run on Windows.
Ray