From: Dave M. <da...@id...> - 2001-08-16 04:30:31
|
The CLISP maintainers have recently added MAKE-LOAD-FORM, so I've tried over the last couple of days to get it to compile SBCL. I've encountered a number of problems, but compilation gets further than when Martin Atzmueller last reported his progress. However, CLISP still cannot complete the make-host-1.sh script. The problems that I encountered: - some uses of DEFCONSTANT should be inside (EVAL-WHEN (:compile-toplevel) ...) forms, since the constant is used in reader macros later on - keywords are not accepted in DEFSTRUCT :include forms for the names of inherited slots. e.g. (defstruct (derived (:include struct-with-slot-named-variable (:variable 'new-default)))) ^^^^^^^^^ should be (defstruct (derived (:include struct-with-slot-named-variable (variable 'new-default)))) ^^^^^^^^ I think CLISP conforms to ANSI on this. - CLISP doesn't like the idiom where DEFSTRUCT slot-initforms reference bindings defined in the constructor declaration. e.g. (defstruct (test (:constructor make-test (vara))) vara (varb (+ vara 10))) should be re-written as the more portable (defstruct (test (:constructor make-test (vara &aux (varb (+ vara 10))))) vara varb) Thanks to Kent Pitman for pointing to this portable alternative. - the reader macro issue that Martin mentioned is because SBCL reader macro functions return two values, but ANSI says they should return 0 or 1 value. The macros in src/code/backq.lisp return two values. The second value doesn't seem to be used in SBCL's reader, so I changed them. I got past all of these problems. I haven't tried recompiling SBCL (using SBCL) yet, but I think the changes I made so far should be OK as they are. I'll do the recompile and send a diff in the next couple of days. Two more serious problems: - CLISP doesn't implement PPRINT-LOGICAL-BLOCK. So far, I have been able to ignore this problem by setting *{load,compile}-{verbose,print}* to nil, thereby avoiding the need to attempt a call to this undefined function. - CLISP generates the following error: Compiling file /home/dave/packages/sbcl-work1/src/code/force-delayed-defbangstructs.lisp ... Compilation of file /home/dave/packages/sbcl-work1/src/code/force-delayed-defbangstructs.lisp is finished. 0 errors, 0 warnings ;; Loading file obj/from-host/src/code/force-delayed-defbangstructs.lisp-obj ... *** - VECTOR-PUSH-EXTEND works only on adjustable arrays, not on #(#<UNKNOWN-TYPE NULL> #<ARRAY-TYPE SIMPLE-STRING>) From stepping through sb!kernel::force-delayed-def!structs, I know that the error is generated when processing the PRIM-OBJECT-SLOT structure, but I don't know why it happens. I'm not sure whether SBCL or CLISP is to blame, and I'm at a loss about how to debug further. -Dave |
From: William H. N. <wil...@ai...> - 2001-08-16 13:45:12
|
On Thu, Aug 16, 2001 at 12:30:20AM -0400, Dave MacDonald wrote: > The CLISP maintainers have recently added MAKE-LOAD-FORM, so I've > tried over the last couple of days to get it to compile SBCL. I've > encountered a number of problems, but compilation gets further than > when Martin Atzmueller last reported his progress. However, CLISP > still cannot complete the make-host-1.sh script. > [various problems and fixes] I stalled on the CLISP port because I got impatient with some strange problem building on OpenBSD. But even if I never fix that problem, I still have an (old and slightly flaky) machine running Linux, so I could just stop messing with porting CLISP itself and do a little work with porting SBCL. > - CLISP doesn't implement PPRINT-LOGICAL-BLOCK. So far, I have been > able to ignore this problem by setting > *{load,compile}-{verbose,print}* to nil, thereby avoiding the need > to attempt a call to this undefined function. So far I've been successful working around unimplemented i/o stuff in cross-compilation. CMU CL didn't -- and maybe still doesn't -- do PRINT-OBJECT or READ-SEQUENCE correctly, and it was still manageable to build under CMU CL by avoiding those operations. > - CLISP generates the following error: > > Compiling file /home/dave/packages/sbcl-work1/src/code/force-delayed-defbangstructs.lisp ... > > Compilation of file /home/dave/packages/sbcl-work1/src/code/force-delayed-defbangstructs.lisp is finished. > 0 errors, 0 warnings > ;; Loading file obj/from-host/src/code/force-delayed-defbangstructs.lisp-obj ... > *** - VECTOR-PUSH-EXTEND works only on adjustable arrays, not on #(#<UNKNOWN-TYPE NULL> #<ARRAY-TYPE SIMPLE-STRING>) > > From stepping through sb!kernel::force-delayed-def!structs, I know > that the error is generated when processing the PRIM-OBJECT-SLOT > structure, but I don't know why it happens. I'm not sure whether > SBCL or CLISP is to blame, and I'm at a loss about how to debug > further. I'd guess that the vector that VECTOR-PUSH-EXTEND is failing on was created by a MAKE-ARRAY form which didn't explicitly give it a fill pointer, but did give it some other non-simple property. IIRC SBCL, like CMU CL, has only one flavor of non-simple array, so if you specify any form of non-simplicity, you get a fill pointer. Perhaps some code has come to rely on this. The fixes you describe sound reasonable. Would you like to send them in as patches? -- William Harold Newman <wil...@ai...> "Three hours a day will produce as much as a man ought to write." -- Anthony Trollope PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Dave M. <da...@id...> - 2001-08-16 18:55:47
|
William Harold Newman <wil...@ai...> writes: > > > > From stepping through sb!kernel::force-delayed-def!structs, I know > > that the error is generated when processing the PRIM-OBJECT-SLOT > > structure, but I don't know why it happens. I'm not sure whether > > SBCL or CLISP is to blame, and I'm at a loss about how to debug > > further. > > I'd guess that the vector that VECTOR-PUSH-EXTEND is failing on was > created by a MAKE-ARRAY form which didn't explicitly give it a fill > pointer, but did give it some other non-simple property. IIRC SBCL, > like CMU CL, has only one flavor of non-simple array, so if you > specify any form of non-simplicity, you get a fill pointer. Perhaps > some code has come to rely on this. Good call! I'm past this problem, so I'll continue until I hit a roadblock (or CLISP compiles SBCL successfully). > The fixes you describe sound reasonable. Would you like to send them > in as patches? Certainly; at the next roadblock I hit, I'll take the time to send in a nice patch. -Dave |