loading on SBCL needs improvement
Status: Beta
Brought to you by:
amallavarapu
SBCL signals a condition if a value defined by defconstant is redefined or changed. Since there are a lot of `constants' which are changed downstream, loading (and including) under SBCL should always involve the `continue' restart which is offered in such cases:
(handler-bind ((sb-ext::defconstant-uneql
#'(lambda (c) (invoke-restart 'continue))))
(load "some-file.lisp"))
Logged In: YES
user_id=1729388
Originator: YES
File Added: littleb-load.patch
Patch
Logged In: YES
user_id=870521
Originator: NO
Hi Albert - Thanks for those patches.
I noticed that you changed b::+objects+ to b::*kb-objects*. Was +objects+ causing problems in sbcl?
Also - is this littleb-load.patch cumulative or should the other patches you sent earlier be applied first?
Logged In: YES
user_id=1729388
Originator: YES
My pleasure!
About the +objects+: I was changing this pretty early in my
porting attempts, due to the warings sbcl was giving me. I
forgot to revert these changes once I realized that it's your
coding style, and I should respect that. But I would indeed be
interested in why you're using defconstant in favour of defvar,
as I fail to see the benefits (I blame my limited knowlege of
special/lexical variables for this.)
It's probably a good idea to re-submit my sbcl-porting patches as
a series of patches to newly created bugs. That would give you
better control over the stuff I did, and the patches were
independent of each other.
Logged In: YES
user_id=870521
Originator: NO
Hi Albert,
I tried running the littleb-sbcl-0.3.patch (and others) on CLISP, and found that while example5 still builds correctly, another larger model (not available in the distribution) causes an error. I'm trying to track that down.
Though I think the *kb-objects* change is not the problem, let's keep the changes to a minimum until we get the SBCL port playing nicely with the other implementations.
For the record, I think changing to a var is a good idea. Some of the code you're looking through is very early stuff, developed before a good coding style was established.
Logged In: YES
user_id=870521
Originator: NO
littleb-sbcl-0.3.patch causes an error while loading on Lispworks:
**++++ Error in (PACKAGE "PORTABLE"):
Using package CLOSER-MOP results in name conflicts for these symbols: DEFCLASS DEFMETHOD STANDARD-CLASS DEFGENERIC STANDARD-GENERIC-FUNCTION ENSURE-GENERIC-FUNCTION.
; (TOP-LEVEL-FORM 2)
; *** 1 error detected, no fasl file produced.
Warning: COMPILE-FILE warned while performing #<ASDF:COMPILE-OP NIL 218E255B> on
#<ASDF:CL-SOURCE-FILE "portable-pkg" 217E60B7>.
Warning: COMPILE-FILE failed while performing #<ASDF:COMPILE-OP NIL 218E255B> on
#<ASDF:CL-SOURCE-FILE "portable-pkg" 217E60B7>.
Error: erred while invoking #<ASDF:COMPILE-OP NIL 218E255B> on
#<ASDF:CL-SOURCE-FILE "portable-pkg" 217E60B7>
1 (continue) Retry performing #<ASDF:COMPILE-OP NIL 218E255B> on
#<ASDF:CL-SOURCE-FILE "portable-pkg" 217E60B7>.
2 Continue, treating #<ASDF:COMPILE-OP NIL 218E255B> on
#<ASDF:CL-SOURCE-FILE "portable-pkg" 217E60B7> as having been successful.
3 Try loading ~/code/b1-sbcl/littleb.lisp again.
4 Give up loading ~/code/b1-sbcl/littleb.lisp.
5 Try loading another file instead of ~/code/b1-sbcl/littleb.lisp.
6 (abort) Return to level 0.
7 Return to top loop level 0.
Logged In: YES
user_id=1729388
Originator: YES
D'OH! I used closer to mop in the wrong way. Instead of using both packages, common-lisp and c2mop, the right way would have been to just use #:closer-common-lisp
I think that should fix it.
Logged In: YES
user_id=870521
Originator: NO
Hi Albert -
I noticed the patch removes case constants from print-escaped-name in printer.lisp:
Specifically lines 211-213 and 226-230 which contain code for the :invert and :preserve *print-case* situations. Is this causing problems on SBCL?
I still can't get sbcl to load littleb.lisp. I'm using sbcl 1.0.6 (apt-get on ubuntu). Is this the same version?
It fails while compiling dspec.lisp. When you resubmit a patch, could you ensure a minimal set of changes from the current CVS head? (No code formatting changes, etc.)?
; file: /home/aneil/code/b1-sbcl/src/portable/dspec.lisp
; in: DEFMACRO LOCATION
; DEFMACRO
; --> EVAL-WHEN SB-C::%DEFMACRO LET*
; ==>
; (LET* ()
; (DECLARE (IGNORABLE PORTABLE:DSPEC))
; (BLOCK PORTABLE:LOCATION NIL))
;
; caught STYLE-WARNING:
; declaring unknown variable DSPEC to be ignored
; compiling (DEFMACRO DSPEC ...)
; compiling (DEFUN DESTROY-DSPEC ...)
; compiling (DEFUN DESTROY-SYMBOL ...)
; compiling (DEFUN FIND-DSPEC-LOCATIONS ...)
; compiling (DEFUN LOCATION-REDEFINITION-CHECK ...)
; compiling (DEFUN RECORD-DEFINITION ...)
; compiling (DEFMACRO DEFINE-DSPEC-CLASS ...)
; compiling (DEFMACRO DEFINE-DSPEC-FORM-PARSER ...)
; compiling (DEFMACRO DEFINE-DSPEC-ALIAS ...)
; compiling (DEFCONSTANT *FILE-EXTENSIONS* ...);
; caught STYLE-WARNING:
; defining *FILE-EXTENSIONS* as a constant, even though the name follows
; the usual naming convention (names like *FOO*) for special variables
; compiling (DEFMACRO ALLOWING-REDEFINITIONS ...); in: LAMBDA NIL
; LET*
;
; caught STYLE-WARNING:
; The variable BODY is defined but never used.
; file: /home/aneil/code/b1-sbcl/src/portable/dspec.lisp
; in: DEFMACRO ALLOWING-REDEFINITIONS
; DEFMACRO
; --> EVAL-WHEN SB-C::%DEFMACRO LET*
; ==>
; (LET* ((PORTABLE::BODY (CDR #:WHOLE100)))
; (BLOCK PORTABLE:ALLOWING-REDEFINITIONS))
;
; caught STYLE-WARNING:
; The variable BODY is defined but never used.
; /home/aneil/code/b1-sbcl/src/../bin/Sbcl-1-0-6-Unix/portable/dspec.fasl written
; compilation finished in 0:00:00
WARNING:
COMPILE-FILE warned while performing #<COMPILE-OP NIL {AD78C99}> on
#<CL-SOURCE-FILE "dspec" {AD78D29}>.
STYLE-WARNING:
defining *FILE-EXTENSIONS* as a constant, even though the name follows
the usual naming convention (names like *FOO*) for special variables
debugger invoked on a SB-EXT:DEFCONSTANT-UNEQL in thread #<THREAD "initial thread" {A806779}>:
The constant *FILE-EXTENSIONS* is being redefined (from ("lisp" . "fasl") to
("lisp" . "fasl"))
See also:
The ANSI Standard, Macro DEFCONSTANT
The SBCL Manual, Node "Idiosyncrasies"
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [CONTINUE] Go ahead and change the value.
1: [ABORT ] Keep the old value.
2: [RETRY ] Retry performing #<ASDF:LOAD-OP NIL {AD78D39}> on
#<ASDF:CL-SOURCE-FILE "dspec" {AD78D29}>.
3: [ACCEPT ] Continue, treating #<ASDF:LOAD-OP NIL {AD78D39}> on
#<ASDF:CL-SOURCE-FILE "dspec" {AD78D29}> as having been
successful.
4: Exit debugger, returning to top level.
(SB-C::%DEFCONSTANT
*FILE-EXTENSIONS*
("lisp" . "fasl")
"Filename extensions for Common Lisp. A cons of the form
(Source-Extension . Binary-Extension). If the system is
unknown (as in *features* not known), attempts to discover filetype dynamically."
#S(SB-C:DEFINITION-SOURCE-LOCATION
:NAMESTRING "/home/aneil/code/b1-sbcl/src/portable/dspec.lisp"
:TOPLEVEL-FORM-NUMBER 17
:PLIST NIL))
0] q
debugger invoked on a UNBOUND-VARIABLE in thread #<THREAD "initial thread" {A806779}>:
The variable Q is unbound.
Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT ] Reduce debugger level (to debug level 1).
1: [RETRY ] Retry performing #<ASDF:LOAD-OP NIL {AD78D39}> on
#<ASDF:CL-SOURCE-FILE "dspec" {AD78D29}>.
2: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {AD78D39}> on
#<ASDF:CL-SOURCE-FILE "dspec" {AD78D29}> as having been
successful.
3: Exit debugger, returning to top level.
(SB-INT:SIMPLE-EVAL-IN-LEXENV Q #<NULL-LEXENV>)
0[2] 3
;
; compilation unit aborted
; caught 1 fatal ERROR condition
; caught 6 STYLE-WARNING conditions
; printed 11 notes
All-In-One patch to allow little b to load on sbcl
Logged In: YES
user_id=1729388
Originator: YES
File Added: littleb-sbcl-0.4.patch
Logged In: YES
user_id=870521
Originator: NO
Thanks,
The patches which you submitted allow little b to load on SBCL.
One remaining problems is a package-lock error caused by LISA on SBCl.
A bug report has been submitted:
http://sourceforge.net/tracker/index.php?func=detail&aid=1861981&group_id=12453&atid=112453