Steel Bank Common Lisp

On Sun, May 11, 2003 at 08:17:32PM +0200, Pascal Bourguignon wrote:
> My .sbclrc loads a .common.lisp which loads a package from the file:
> /home/pascal/src/common/lisp/common-lisp/package.lisp
> Here is the beginning of this file:
[...]

I couldn't guess what the cause of your problem is, and I experimented
a little with running your code on my system without finding similar
problems. So I don't have an answer, but I have a few questions.

What version of SBCL are you using? (And: you mentioned that it used
to work a few days ago, so what version were you using then?)

Is it possible to construct a standalone test case demonstrating the
problem, which doesn't involve your .common.lisp and other
.sbclrc-related files? E.g. something along the lines of
        $ cat <<EOF > package-bug.lisp
        (defpackage "BADPACKAGE" (:NICKNAMES "PACKAGE") (:USE "CL"))
        EOF
	$ sbcl --userinit /dev/null --sysinit /dev/null << EOF
        (load "package-bug.lisp")
        (compile-file "package-bug.lisp")
        (load *) ; causes WARNING or whatever
        EOF
Or if the problem only happens with your .sbclrc and other files
(.common.lisp, etc.) could you send copies of them so that we can
experiment with the problem?

-- 
William Harold Newman <william.newman@...>
I'm not claiming I write great software, but I know that when it comes
to code I behave in a way that would make me eligible for prescription
drugs if I approached everyday life the same way.
  -- <http://www.paulgraham.com/hp.html>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C

William Harold Newman writes:
> On Sun, May 11, 2003 at 08:17:32PM +0200, Pascal Bourguignon wrote:
> > My .sbclrc loads a .common.lisp which loads a package from the file:
> > /home/pascal/src/common/lisp/common-lisp/package.lisp
> > Here is the beginning of this file:
> [...]
>=20
> I couldn't guess what the cause of your problem is, and I experimented
> a little with running your code on my system without finding similar
> problems. So I don't have an answer, but I have a few questions.
>=20
> What version of SBCL are you using? (And: you mentioned that it used
> to work a few days ago, so what version were you using then?)

Got from CVS: This is SBCL 0.pre8.104, an implementation of ANSI Common L=
isp.


> Is it possible to construct a standalone test case demonstrating the
> problem, which doesn't involve your .common.lisp and other
> .sbclrc-related files? E.g. something along the lines of
>         $ cat <<EOF > package-bug.lisp
>         (defpackage "BADPACKAGE" (:NICKNAMES "PACKAGE") (:USE "CL"))
>         EOF
> 	$ sbcl --userinit /dev/null --sysinit /dev/null << EOF
>         (load "package-bug.lisp")
>         (compile-file "package-bug.lisp")
>         (load *) ; causes WARNING or whatever
>         EOF

I could not built a reduced  test case, so I'm sending the whole files
used to  compile that  package.lisp plus a  list.lisp "test  case" for
package.lisp.

> Or if the problem only happens with your .sbclrc and other files
> (.common.lisp, etc.) could you send copies of them so that we can
> experiment with the problem?

Ok. Attached a tar.gz containing:

    .common.lisp
    .clisprc.lisp
    .sbclrc
    .cmucl-init.lisp
    src/common/lisp/Makefile
    src/common/lisp/Makefile.rules
    src/common/lisp/common-lisp/Makefile
    src/common/lisp/common-lisp/package.lisp
    src/common/lisp/common-lisp/list.lisp

All these files should be placed in a sand-box HOME directory.

.clisprc.lisp, .cmucl-init.lisp and .sbclrc all load .common.lisp

.common.lisp   loads  package.lisp.    Please  edit   the  DEFCONSTANT
+PJB-LISP+ in there to point to your sand-box HOME directory.

src/common/lisp/common-lisp/Makefile includes ../Makefile.rules to get
common rules to compile lisp files.   You may edit the all:: target in
src/common/lisp/common-lisp/Makefile to  select one or  more compilers
to use: clisp, cmucl or sbcl.

In particular,  if you  put:
   all:: clisp  cmucl=20
instead of:
   all:: clisp sbcl
it compiles correctly.

cd src/common/lisp/common-lisp ; make clean all


.clisprc.lisp and  .cmucl-init.lisp are provided  if you want  to test
the package with  clisp or cmucl. Once succesfullY  compiled, it would
allow to do:

[pascal@... pascal]$ clisp
;; Loading file /home/pascal/.clisprc.lisp ...
;; Loaded file /home/pascal/.clisprc.lisp
[1]> (LOAD (PACKAGE::PACKAGE-PATHNAME 'COM.INFORMATIMAGO.COMMON-LISP.LIST=
))
T
[2]> (SETQ *PRINT-CIRCLE* T)
T
[3]> (COM.INFORMATIMAGO.COMMON-LISP.LIST:LIST-TO-DOUBLE-LINKED-LIST '(A B=
 C D))
#1=3D(A NIL . #2=3D(B #1# . #3=3D(C #2# D #3#)))
[4]> (QUIT)




While composing this  message, I found a smaller  test case: just load
again package.lisp.

[pascal@... pascal]$ sbcl
This is SBCL 0.pre8.104, an implementation of ANSI Common Lisp.
[...]
More information about SBCL is available at <http://sbcl.sourceforge.net/=
>.
; in: LAMBDA NIL
;     (AREF PACKAGE COM.INFORMATIMAGO.COMMON-LISP.PACKAGE::FROM-SRC)
; --> LET* SB-KERNEL:HAIRY-DATA-VECTOR-REF MULTIPLE-VALUE-BIND=20
; --> MULTIPLE-VALUE-CALL=20
; =3D=3D>
;   (SB-KERNEL:%DATA-VECTOR-AND-INDEX ARRAY SB-INT:INDEX)
;=20
; note: unable to
;         optimize
;       due to type uncertainty:
;         The first argument is a BASE-STRING, not a SIMPLE-ARRAY.
; compilation unit finished
;   printed 2 notes
* (load "package:com;informatimago;common-lisp;package.lisp")
WARNING:
   COM.INFORMATIMAGO.COMMON-LISP.PACKAGE used to use the following packag=
es:
  (#<PACKAGE "COMMON-LISP">)
; in: DEFMACRO WHILE
;     (COM.INFORMATIMAGO.COMMON-LISP.PACKAGE::CONDITION
;    COM.INFORMATIMAGO.COMMON-LISP.PACKAGE::&BODY
;    COM.INFORMATIMAGO.COMMON-LISP.PACKAGE::BODY)
;=20
; caught COMMON-LISP:STYLE-WARNING:
;   undefined variable: &BODY
;=20
; caught COMMON-LISP:STYLE-WARNING:
;   undefined variable: BODY



--=20
__Pascal_Bourguignon__                   http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.

Pascal Bourguignon <pjb@...> writes:

> [pascal@... pascal]$ sbcl
> This is SBCL 0.pre8.104, an implementation of ANSI Common Lisp.
> [...]
> More information about SBCL is available at <http://sbcl.sourceforge.net/>.
> ; in: LAMBDA NIL
> ;     (AREF PACKAGE COM.INFORMATIMAGO.COMMON-LISP.PACKAGE::FROM-SRC)
> ; --> LET* SB-KERNEL:HAIRY-DATA-VECTOR-REF MULTIPLE-VALUE-BIND 
> ; --> MULTIPLE-VALUE-CALL 
> ; ==>
> ;   (SB-KERNEL:%DATA-VECTOR-AND-INDEX ARRAY SB-INT:INDEX)
> ; 
> ; note: unable to
> ;         optimize
> ;       due to type uncertainty:
> ;         The first argument is a BASE-STRING, not a SIMPLE-ARRAY.
> ; compilation unit finished
> ;   printed 2 notes
> * (load "package:com;informatimago;common-lisp;package.lisp")
> WARNING:
>    COM.INFORMATIMAGO.COMMON-LISP.PACKAGE used to use the following packages:
>   (#<PACKAGE "COMMON-LISP">)
> ; in: DEFMACRO WHILE
> ;     (COM.INFORMATIMAGO.COMMON-LISP.PACKAGE::CONDITION
> ;    COM.INFORMATIMAGO.COMMON-LISP.PACKAGE::&BODY
> ;    COM.INFORMATIMAGO.COMMON-LISP.PACKAGE::BODY)
> ; 
> ; caught COMMON-LISP:STYLE-WARNING:
> ;   undefined variable: &BODY
> ; 
> ; caught COMMON-LISP:STYLE-WARNING:
> ;   undefined variable: BODY

(DEFVAR *BUILT-IN-PACKAGES*
  (MAPCAN (LAMBDA (PACK)
            (CONS (PACKAGE-NAME PACK) (PACKAGE-NICKNAMES PACK)))
          (LIST-ALL-PACKAGES)))

You are destructively changing the package-nicknames list of PACK.
Don't do that.

Changing this to 
  (defvar *built-in-packages*
    (mapcan (lambda (pack)
              (cons (package-name pack) 
                    (copy-list (package-nicknames pack))))
            (list-all-packages)))
makes the problem go away.

Cheers,

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)

Christophe Rhodes writes:
> Pascal Bourguignon <pjb@...> writes:
>=20
> (DEFVAR *BUILT-IN-PACKAGES*
>   (MAPCAN (LAMBDA (PACK)
>             (CONS (PACKAGE-NAME PACK) (PACKAGE-NICKNAMES PACK)))
>           (LIST-ALL-PACKAGES)))
>=20
> You are destructively changing the package-nicknames list of PACK.
> Don't do that.
>=20
> Changing this to=20
>   (defvar *built-in-packages*
>     (mapcan (lambda (pack)
>               (cons (package-name pack)=20
>                     (copy-list (package-nicknames pack))))
>             (list-all-packages)))
> makes the problem go away.

Indeed!  That worked before I  switch from (flatten (mapcar to (mapcan
because my flatten function did all the consing.=20

Thank you very much!=20


--=20
__Pascal_Bourguignon__                   http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.