From: Christophe R. <cs...@ca...> - 2001-03-28 15:33:15
|
I was thinking that I would like to see what sbcl was like; this unfortunately seems harder than it might be. The first hurdle has been passed, in that (as you may have seen on cmucl-imp) safe-expt is now safe on x86. However, when attempting to compile the current CVS source with cmucl-2.5.1, it stops very early in the build process, at compiling compiler/macros.lisp; it looks a bit like: --- begin transcript --- Python version 1.0, VM version Intel x86 on 28 MAR 01 04:28:36 pm. Compiling: /home/csr21/misc-cvs/sbcl/src/compiler/macros.lisp 22 MAR 01 01:03:35 am Compiling DEFTYPE INLINEP: Converted CONVERT-CONDITION-INTO-COMPILER-ERROR. Compiling DEFUN CONVERT-CONDITION-INTO-COMPILER-ERROR: ... Converted PARSE-DEFTRANSFORM. Compiling DEFUN PARSE-DEFTRANSFORM: File: /home/csr21/misc-cvs/sbcl/src/compiler/macros.lisp In: DEFUN PARSE-DEFTRANSFORM (DEFUN PARSE-DEFTRANSFORM (LAMBDA-LIST BODY ARGS ERROR-FORM) (MULTIPLE-VALUE-BIND (REQ OPT RESTP REST KEYP ...) (PARSE-LAMBDA-LIST LAMBDA-LIST) (LET* # ..))) Warning: The result type from previous declaration: LIST conflicts with the result type: (VALUES LIST LIST) Converted DEFTRANSFORM. Compiling DEFMACRO DEFTRANSFORM: ... Converted POSITION-OR-LOSE. Compiling DEFMACRO POSITION-OR-LOSE: Byte Compiling Top-Level Form: File: /home/csr21/misc-cvs/sbcl/src/compiler/macros.lisp In: DEFUN CONVERT-CONDITION-INTO-COMPILER-ERROR #'COMPILER-ERROR Warning: Undefined function: COMPILER-ERROR In: DEFUN PARSE-DEFTRANSFORM (PARSE-LAMBDA-LIST LAMBDA-LIST) Warning: Undefined function: PARSE-LAMBDA-LIST Warning: These functions are undefined: COMPILER-ERROR PARSE-LAMBDA-LIST Compilation unit finished. 4 warnings obj/from-host/compiler/macros.lisp-obj-tmp written. Compilation finished in 0:00:03. deleted "obj/from-host/compiler/macros.lisp-obj-tmp" Error in batch processing: Error in function COMPILE-STEM: FAILURE-P was set when creating "obj/from-host/compiler/macros.lisp-obj". --- end transcript --- Any advice gratefully received. Cheers, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 524 842 (FORMAT T "(~@{~w ~}~3:*'~@{~w~^ ~})" 'FORMAT T "(~@{~w ~}~3:*'~@{~w~^ ~})") |
From: William H. N. <wil...@ai...> - 2001-03-28 17:35:37
|
On Wed, Mar 28, 2001 at 04:32:19PM +0100, Christophe Rhodes wrote: > I was thinking that I would like to see what sbcl was like; this > unfortunately seems harder than it might be. The first hurdle has been > passed, in that (as you may have seen on cmucl-imp) safe-expt is now > safe on x86. However, when attempting to compile the current CVS > source with cmucl-2.5.1, it stops very early in the build process, at > compiling compiler/macros.lisp; it looks a bit like: [snip] > File: /home/csr21/misc-cvs/sbcl/src/compiler/macros.lisp > > In: DEFUN PARSE-DEFTRANSFORM > (DEFUN PARSE-DEFTRANSFORM (LAMBDA-LIST BODY ARGS ERROR-FORM) > (MULTIPLE-VALUE-BIND > (REQ OPT RESTP REST KEYP ...) > (PARSE-LAMBDA-LIST LAMBDA-LIST) > (LET* # ..))) > Warning: The result type from previous declaration: > LIST > conflicts with the result type: > (VALUES LIST LIST) This is a bug in SBCL. Actually, maybe it's two bugs in SBCL, (1) the previous declaration is wrong, and (2) the current CMU CL compiler is smart enough to spot the contradiction but SBCL's compiler isn't. > Any advice gratefully received. Bug #1 is also an old bug in CMU CL. Sometime between the cmucl-2.4.8 vintage code that SBCL was forked from, and my reasonably current cmucl-18c sources, someone deleted the bad declaration. The same fix should work for SBCL. I'll do it in the main sources, probably in sbcl-0.6.11.29. If you're in a hurry, you can do it in your local sources too. (It's the DECLAIM immediately above DEFUN PARSE-DEFTRANSFORM) I'll put bug #2 on the BUGS list. Also, at some point reasonably soon I'll probably upgrade to a newer CMU CL binary, and test building SBCL with it from time to time, so that pioneers like you won't need to be quite so intrepid. I've had Debian cmucl-2.4.19 for an awfully long time, and current CMU CL seems to've diverged enough from that that it's time for me to get more current. Thanks for the report. -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: William H. N. <wil...@ai...> - 2001-04-05 16:12:32
|
On Thu, Apr 05, 2001 at 04:35:48PM +0100, Christophe Rhodes wrote: > On Wed, Mar 28, 2001 at 11:35:01AM -0600, William Harold Newman wrote: > > Also, at some point reasonably soon I'll probably upgrade to a newer > > CMU CL binary, and test building SBCL with it from time to time, so > > that pioneers like you won't need to be quite so intrepid. I've had > > Debian cmucl-2.4.19 for an awfully long time, and current CMU CL seems > > to've diverged enough from that that it's time for me to get more current. > > It's getting further now, but it's not yet there :( > > Firstly, against today's CVS I had to apply this to get > early-extensions to compile (correctness obvious, I hope). > > diff -u -r1.18 early-extensions.lisp > --- src/code/early-extensions.lisp 2001/04/04 19:47:19 1.18 > +++ src/code/early-extensions.lisp 2001/04/05 13:47:28 > @@ -445,10 +445,8 @@ > (declaim (ftype (function (symbol t stream) (values)) > defprinter-prin1 defprinter-princ)) > (defun defprinter-prin1 (name value stream) > - (declare (ignore indent)) > (defprinter-prinx #'prin1 name value stream)) > (defun defprinter-princ (name value stream) > - (declare (ignore indent)) > (defprinter-prinx #'princ name value stream)) > (defun defprinter-prinx (prinx name value stream) > (declare (type function prinx)) Hmm. I neglected to remove the IGNOREs when I removed the corresponding unused arguments. So it's my fault that the system wouldn't build under CMU CL. But the ANSI spec also specifically says Any warning about a ``used'' or ``unused'' binding must be of type STYLE-WARNING, and may not affect program semantics. so maybe it's CMU CL's fault too. Ah well; even if it's unclear who to blame, at least it's easy to assign credit for fixing the problem. Thank you. > And now, when compiling compiler/proclaim.lisp, it's complaining in two > parts: > > In: DEFUN SB-XC:PROCLAIM > (SETF (CLASS-STATE CLASS) :SEALED) > --> LET* MULTIPLE-VALUE-BIND LET FUNCALL C::%FUNCALL > ==> > #:G37 > Warning: Result is a CLASS, not a (VALUES &OPTIONAL SB-XC:CLASS &REST T). > > and > > Warning: These functions are undefined: > COMPILER-ERROR COMPILER-STYLE-WARNING COMPILER-WARNING MAYBE-COMPILER-NOTE > STYLE-WARN > > This one is "fixed" (correctness not very obvious at all...) by > changing 'class to sb-xc:class in the freeze-type case: I think maybe SB!XC:CLASS instead of SB-XC:CLASS. I'll try patching it this way (with SB!XC) and see whether it works. Thanks. > And then it works! Or at least, it's computed (fact 1000) > successfully... Great. I still haven't gotten a new CMU CL, but if it's catching errors that SBCL doesn't, I really should.. -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Christophe R. <cs...@ca...> - 2001-04-06 10:13:11
|
On Thu, Apr 05, 2001 at 11:11:07AM -0500, William Harold Newman wrote: > On Thu, Apr 05, 2001 at 04:35:48PM +0100, Christophe Rhodes wrote: > > This one is "fixed" (correctness not very obvious at all...) by > > changing 'class to sb-xc:class in the freeze-type case: > > I think maybe SB!XC:CLASS instead of SB-XC:CLASS. I'll try patching > it this way (with SB!XC) and see whether it works. Thanks. No problems here rebuilding with sb!xc rather than sb-xc. Now, time to understand what's going on... Cheers, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 524 842 (FORMAT T "(~@{~w ~}~3:*'~@{~w~^ ~})" 'FORMAT T "(~@{~w ~}~3:*'~@{~w~^ ~})") |
From: William H. N. <wil...@ai...> - 2001-04-06 13:22:09
|
On Thu, Apr 05, 2001 at 04:35:48PM +0100, Christophe Rhodes wrote: > diff -u -r1.18 early-extensions.lisp > [..] > diff -u -r1.10 proclaim.lisp > [..] I've put those fixes into sbcl-0.6.11.32 (just checked in). I also installed CMU CL 18c on my machine here and got SBCL to bootstrap from it (adding a workaround for 18c's failure to compile src/code/cross-float.lisp, also in sbcl-0.6.11.32). Now I just need to remember to try bootstrapping from CMU CL 18c again from time to time, and then, I hope, others will not need to overcome as many obstacles as you did. Thanks again. -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |