From: David Steuber
Subject: Bootstrapping SBCL with CLISP on OS X 10.3.1
Date:
Message-ID: <m27k1m212s.fsf@verizon.net>
I have the CVS checkout of SBCL from a few hours ago. I tried to
build it using CLISP from Darwin Ports. It was a no-go. I'm not
sure what to fix or how to fix it. Here is the last bit of output:
Compilation of file /Users/david/usr/src/sbcl/sbcl/src/compiler/generic/genesis.lisp is finished.
The following functions were used but not defined:
SB!FASL::NOTE-LOAD-TIME-CODE-FIXUP
0 errors, 0 warnings
;; Loading file obj/from-host/src/compiler/generic/genesis.lisp-obj ...
;; Loading of file obj/from-host/src/compiler/generic/genesis.lisp-obj is finished.
T
beginning GENESIS, creating headers in "src/runtime/genesis"
*** - DOCUMENTATION: first argument #<PACKAGE SB!WALKER> is illegal, not a symbol
Bye.
//entering make-target-1.sh
//building runtime system and symbol table file
GNUmakefile:73: depend: No such file or directory
gnumake: *** No rule to make target `genesis/*.h', needed by `sbcl.h'. Stop.
I used the 'sh make.sh clisp' command. I am using CLISP from Darwin
Ports:
$ clisp --version
GNU CLISP 2.29 (released 2002-07-25) (built 3276354619) (memory 3276355275)
Features:
(CLOS LOOP COMPILER CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS
GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN GETTEXT UNICODE BASE-CHAR=CHARACTER
UNIX)
I had an older version of SBCL but the upgrade to Panther broke it.
Also, FYI, the link to the CL Hyperspec on
http://sbcl.sourceforge.net/
is broken. I believe I have a copy of the hyperspec from elsewhere,
but the link should still be fixed or removed.
Has anyone built a working binary for Panther on the G4? Or can I
use the Linux (Debian Unstable branch, KRM packages) version to cross
compile from x86 Linux to PPC OS X?
Ideally, what I would like to do is build SBCL with CLISP if possible
and then rebuild it again with the resulting SBCL. Such a process
ought to leave me with a working SBCL like I would have gotten if I
was self-bootstrapping with a running SBCL.
I thought I would try checking out the latest version of CLISP but
CVS doesn't seem to be responding. Or I am too impatient.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber <·············@verizon.net> writes:
> I have the CVS checkout of SBCL from a few hours ago. I tried to
> build it using CLISP from Darwin Ports. It was a no-go. I'm not
> sure what to fix or how to fix it. Here is the last bit of output:
Have you read:
http://www.cs.indiana.edu/~bmastenb/software/SBCL/sbcl-g5-or-panther.html
??
-Doug
David Steuber <·············@verizon.net> writes:
[ You'd probably get a better response posting questions like this to
sbcl-devel instead of cll, and it would have the pleasing side-effect
that the answers would be archived for future generations
> *** - DOCUMENTATION: first argument #<PACKAGE SB!WALKER> is illegal, not a symbol
> Bye.
Dunno offhand where that's coming from. If you want to pursue this,
getting a backtrace would be a first step
> $ clisp --version
> GNU CLISP 2.29 (released 2002-07-25) (built 3276354619) (memory 3276355275)
That's over a year old, fwiw. I have "2.31 (released 2003-09-01)" and
I haven't checked that's even the most recent version
> Also, FYI, the link to the CL Hyperspec on
>
> http://sbcl.sourceforge.net/
Now fixed. Thanks.
> Has anyone built a working binary for Panther on the G4? Or can I
> use the Linux (Debian Unstable branch, KRM packages) version to cross
> compile from x86 Linux to PPC OS X?
In general, I would recommend cross-compilation from SBCL or CMUCL on
some other platform (yes, x86 should be fine) as more likely to work
than building with CLISP, which I don't think any of us regularly use
for this purpose. Note that Panther has special issues, though: see
instructions at
http://www.cs.indiana.edu/~bmastenb/software/SBCL/sbcl-g5-or-panther.html
It doesn't appear (I could be wrong) that this patch has been applied
on 0.8.6, so it's still relevant.
-dan
--
http://web.metacircles.com/ - CL custom development and SBCL support
From: David Steuber
Subject: Re: Bootstrapping SBCL with CLISP on OS X 10.3.1
Date:
Message-ID: <m2ad6hxwi0.fsf@verizon.net>
Daniel Barlow <···@telent.net> writes:
> David Steuber <·············@verizon.net> writes:
>
> [ You'd probably get a better response posting questions like this to
> sbcl-devel instead of cll, and it would have the pleasing side-effect
> that the answers would be archived for future generations
I have some mail issues to get sorted out. Once that is done, I will
join the mail list. Meanwhile, Google should have archived this
entire thread unless people are using the 'X-No-Archive: yes'
header. I hate it when people do that.
> In general, I would recommend cross-compilation from SBCL or CMUCL on
> some other platform (yes, x86 should be fine) as more likely to work
> than building with CLISP, which I don't think any of us regularly use
> for this purpose. Note that Panther has special issues, though: see
> instructions at
>
> http://www.cs.indiana.edu/~bmastenb/software/SBCL/sbcl-g5-or-panther.html
>
> It doesn't appear (I could be wrong) that this patch has been applied
> on 0.8.6, so it's still relevant.
Ok, this looks exactly like what I want. I don't know how I missed
that link. Thanks. I'll let you know how it works out. I would like
to keep current with CVS and learn how a real Lisp implementation
works and perhaps even contribute if I can gain the expertise.
I am also rather interested in writing a Cocoa bridge for SBCL if
that is possible to do and if no one else has done so yet. Don't let
this stop anyone from getting started on that ;-). (Actually, if a
Cocoa bridge can be written that is reasonably portable using UFFI,
that would be even better.) I don't know what sort of spanner
Objective-C throws into the works over standard C calling.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber wrote:
> Daniel Barlow <···@telent.net> writes:
>
>
>>David Steuber <·············@verizon.net> writes:
>>
>>[ You'd probably get a better response posting questions like this to
>>sbcl-devel instead of cll, and it would have the pleasing side-effect
>>that the answers would be archived for future generations
>
>
> I have some mail issues to get sorted out. Once that is done, I will
> join the mail list. Meanwhile, Google should have archived this
> entire thread unless people are using the 'X-No-Archive: yes'
> header. I hate it when people do that.
>
>
>>In general, I would recommend cross-compilation from SBCL or CMUCL on
>>some other platform (yes, x86 should be fine) as more likely to work
>>than building with CLISP, which I don't think any of us regularly use
>>for this purpose. Note that Panther has special issues, though: see
>>instructions at
>>
>>http://www.cs.indiana.edu/~bmastenb/software/SBCL/sbcl-g5-or-panther.html
>>
>>It doesn't appear (I could be wrong) that this patch has been applied
>>on 0.8.6, so it's still relevant.
>
>
> Ok, this looks exactly like what I want. I don't know how I missed
> that link. Thanks. I'll let you know how it works out. I would like
> to keep current with CVS and learn how a real Lisp implementation
> works and perhaps even contribute if I can gain the expertise.
>
> I am also rather interested in writing a Cocoa bridge for SBCL if
> that is possible to do and if no one else has done so yet. Don't let
> this stop anyone from getting started on that ;-). (Actually, if a
> Cocoa bridge can be written that is reasonably portable using UFFI,
> that would be even better.) I don't know what sort of spanner
> Objective-C throws into the works over standard C calling.
I'd suggest getting OpenMCL with sources. You can look at the Objective
C bridge that is among the examples in the OpenMCL distribution. The
full source is there, and that should help you figure out how to do
something similar with SBCL.
Randall Beer did the bridge that is in OpenMCL 0.14, and s continuing to
work on it. He says he and Gary are trying to figure out how to make it
look like Objective C objects are instances of some special CLOS class
for better CLOS integration (right now you must use a separate syntax
for defining Objective C classes and methods).
Maybe you could even coordinate and share efforts with him and make the
bridge for SBCL look like the bridge for OpenMCL.
From: David Steuber
Subject: Re: Bootstrapping SBCL with CLISP on OS X 10.3.1
Date:
Message-ID: <m2r7zrsebi.fsf@verizon.net>
mikel <·····@evins.net> writes:
> I'd suggest getting OpenMCL with sources. You can look at the
> Objective C bridge that is among the examples in the OpenMCL
> distribution. The full source is there, and that should help you
> figure out how to do something similar with SBCL.
That sounds like a plan.
> Randall Beer did the bridge that is in OpenMCL 0.14, and s continuing
> to work on it. He says he and Gary are trying to figure out how to
> make it look like Objective C objects are instances of some special
> CLOS class for better CLOS integration (right now you must use a
> separate syntax for defining Objective C classes and methods).
Ideally I would want a CLOS hierarchy that mirrors the Cocoa
hierarchy. I'm going to be doing Objective-C programming and would
like the knowledge of Cocoa to be portable to CLOS. I don't know how
unnatural that would be for CLOS though.
> Maybe you could even coordinate and share efforts with him and make
> the bridge for SBCL look like the bridge for OpenMCL.
I'll see what I can do. I still have a steep learning curve ahead of
me. I good goal would be to have an implementation that is code
portable between SBCL and OpenMCL.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber wrote:
> mikel <·····@evins.net> writes:
>
>
>>I'd suggest getting OpenMCL with sources. You can look at the
>>Objective C bridge that is among the examples in the OpenMCL
>>distribution. The full source is there, and that should help you
>>figure out how to do something similar with SBCL.
>
>
> That sounds like a plan.
>
>
>>Randall Beer did the bridge that is in OpenMCL 0.14, and s continuing
>>to work on it. He says he and Gary are trying to figure out how to
>>make it look like Objective C objects are instances of some special
>>CLOS class for better CLOS integration (right now you must use a
>>separate syntax for defining Objective C classes and methods).
>
>
> Ideally I would want a CLOS hierarchy that mirrors the Cocoa
> hierarchy.
I think Gary and Randall have concluded that's not the right way to go
about, and I agree with them. I think basically you would end up
burnging all your time fixing bugs in the CLOS classes to try to make
them behave like the corresponding Objective C classes.
Instead, what they propose to do is define some combination of classes,
metaclasses, and method combinations such that actual Objective C
objects appear to Lisp code to be Lisp objects, but objects that inherit
from these specially-defined thingies. In other words, instead of making
Lisp objects that shadow the Cocoa classes and methods, they propose to
persuade Lisp that the actual Cocoa classes and methods are in fact Lisp
objects.
I think this is a better idea; if you go this route there is zero work
involved in making your Lisp objects behave like Cocoa objects, because
your Lisp objects *are* the Cocoa objects. The challenge then becomes
all the work you have to do to reconcile the Lisp and Objective C views
of the world, but I think that'a a more tractable task.
> I'm going to be doing Objective-C programming and would
> like the knowledge of Cocoa to be portable to CLOS. I don't know how
> unnatural that would be for CLOS though.
Not unnatural if you think of OBJECTIVE-C-CLASS as a CLOS metaclass that
is the class of Objective C classes (just as STANDARD-CLASS is the class
of most other CLOS classes). Sure, instances of OBJECTIVE-C-CLASS behave
a little differently, but that's the whole point of having metaclasses.
Even now, with the early-days bridge that is available in present-day
openmcl, my own Cocoa knowledge transfers easily to working with
openmcl. Nowadays, in fact, I use Lisp for all my Cocoa programming. The
biggest inconvenience is that Project Builder isn't really any help, so
you have to do a few things (like editing Info.plist and sso on) by hand.
>>Maybe you could even coordinate and share efforts with him and make
>>the bridge for SBCL look like the bridge for OpenMCL.
>
>
> I'll see what I can do. I still have a steep learning curve ahead of
> me. I good goal would be to have an implementation that is code
> portable between SBCL and OpenMCL.
Yeah. I think the OpenMCL code will help.
mikel writes:
[about OpenMCL]
> I think Gary and Randall have concluded that's not the right way to go
> about, and I agree with them. I think basically you would end up
[...]
> objects that inherit from these specially-defined thingies. In other
> words, instead of making Lisp objects that shadow the Cocoa classes
> and methods, they propose to persuade Lisp that the actual Cocoa
> classes and methods are in fact Lisp objects.
Richard "LMI" Greenblatt gave a talk about these issues at ILC
2003. The talk's paper and slides are included in the conference
proceedings available from Franz. The paper is titled "Objective-LISP,
a Proposal". From the abstract:
A new variant of LISP, called Objective-LISP by close analogy to
Objective-C, is proposed. The central objective of Objective-LISP is
to be a "first class language" in a modern, fully developed (or at a
minimum realistically developable), full service window operating
system, such as MAC OS-X (or GNUStep), to be suitable for heavy duty
numeric computations, such as 3D simulations, and to be gracefully
multi-threaded in a multiple processor environment, such as MAC
OS-X.
[...]
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Paolo Amoroso <·······@mclink.it> writes:
> Richard "LMI" Greenblatt gave a talk about these issues at ILC
> 2003. The talk's paper and slides are included in the conference
That should be ILC 2002, sorry.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
David Steuber <·············@verizon.net> writes:
> I have the CVS checkout of SBCL from a few hours ago. I tried to
> build it using CLISP from Darwin Ports.
I understand OpenMCL may be a better bet (and you should read the
page everyone else has been pointing you to:
http://www.cs.indiana.edu/~bmastenb/software/SBCL/sbcl-g5-or-panther.html
You can get a binary there).
Cheers,
mwh
--
I would hereby duly point you at the website for the current pedal
powered submarine world underwater speed record, except I've lost
the URL. -- Callas, cam.misc
David Steuber <·············@verizon.net> writes:
> I have the CVS checkout of SBCL from a few hours ago. I tried to
> build it using CLISP from Darwin Ports. It was a no-go. I'm not
> sure what to fix or how to fix it. Here is the last bit of output:
Thanks for this, but the diagnosis is fairly easy without the output.
I'll point out some problems with what you did, though, that made it
less likely than usual for clisp to bootstrap sbcl successfully:
> I used the 'sh make.sh clisp' command. I am using CLISP from Darwin
Firstly, you need to be aware that clisp (I believe still currently
but definitely in the version you used) starts up by default in a
'non-ANSI' mode, whatever that means. So that's the first problem,
because while SBCL makes an effort to work in ANSI lisps, there's no
such guarantee with non-ANSI lisps. Though...
> Ports:
>
> $ clisp --version
> GNU CLISP 2.29 (released 2002-07-25) (built 3276354619) (memory 3276355275)
> Features:
> (CLOS LOOP COMPILER CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS
> GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN GETTEXT UNICODE BASE-CHAR=CHARACTER
> UNIX)
... I forget if :ANSI-CL here actually means 'ANSI mode', but I'm
really not sure. In any case, version 2.29 is definitely not modern
enough to compile SBCL; there are numerous showstopper bugs that
prevent proper operation, including but not limited to the issue you
saw, namely, that the implementation of DOCUMENTATION was buggy.
> Has anyone built a working binary for Panther on the G4? Or can I
> use the Linux (Debian Unstable branch, KRM packages) version to cross
> compile from x86 Linux to PPC OS X?
Yes, and yes. Other people have already given you specifics as to the
first; as for the second, it is possible, and fairly straightforward,
to compile from any sbcl on any platform to sbcl on any other
platform. There are some instructions on
<http://sbcl-internals.cliki.net/Build>, which may or may not be quite
current, but the basic principle has been followed successfully before.
> Ideally, what I would like to do is build SBCL with CLISP if possible
> and then rebuild it again with the resulting SBCL. Such a process
> ought to leave me with a working SBCL like I would have gotten if I
> was self-bootstrapping with a running SBCL.
In principle, you do not need the second step. The cores won't be
bit-for-bit identical, because some of the source information
(timestamps and the like) will have changed, but otherwise the
binaries should be indistinguishable; in particular, if you can
isolate behaviour that is different between the two, it's a bug and I
very much want to know about it. (One such difference in behaviour
was tracked down during last month's sbcl development cycle, relating
to the use of BOOLE in compiled code).
> I thought I would try checking out the latest version of CLISP but
> CVS doesn't seem to be responding. Or I am too impatient.
I reported the failure of current CLISP to compile current SBCL,
complete with patch, to the clisp maintainers in two messages to the
clisp list:
<http://sourceforge.net/mailarchive/forum.php?thread_id=3338937&forum_id=6767>
<http://sourceforge.net/mailarchive/forum.php?thread_id=3338939&forum_id=6767>
I have not yet had any response to the patch, or even acknowledgment
that I'm right in my surmise (though I strongly suspect so). In any
case, if you were to continue attempting to build from clisp, I would
strongly advise trying my patch before building sbcl.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
From: David Steuber
Subject: Re: Bootstrapping SBCL with CLISP on OS X 10.3.1
Date:
Message-ID: <m2llpzsdqg.fsf@verizon.net>
Christophe Rhodes <·····@cam.ac.uk> writes:
> I have not yet had any response to the patch, or even acknowledgment
> that I'm right in my surmise (though I strongly suspect so). In any
> case, if you were to continue attempting to build from clisp, I would
> strongly advise trying my patch before building sbcl.
Thanks for taking the trouble to respond in such detail. I almost
hate to trim it all to reply.
I haven't installed it yet, but I downloaded the sbcl built for
Panther that several people posted a link to. I will go through the
steps to build the CVS version of sbcl from that. It may be wrong
headed of me, but if clisp is not going to be properly ANSI, then I
don't know if I want to mess with it. Well, not for building another
lisp. There is some value in testing that code works under multiple
lisps, but that is only true so far as they are both ANSI. It will
probably be more interesting to me to have code that compiles and
runs properly under both OS X and Linux.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.