Subject: [clisp-list] problems bootstrapping SBCL with CLISP

From: William Harold Newman <[email-masked]>
Date: Sun Dec 30 11:28:03 2001

I spent some time in the Atlanta airport this Christmas, which I
can't recommend as a hub except for the relatively high availability
of electrical outlets for laptops. I diverted myself by trying to 
use CLISP
  "2.27 (released 2001-07-17) (built 3215971334) (memory 3215971555)"
under OpenBSD 2.9 on my PIII laptop as a cross-compilation host for
SBCL. I made some progress, but I still couldn't get it to work.

There was a non-ANSI-ism in CLISP that I successfully worked around:
(DOCUMENTATION X) fails when X is a PACKAGE.

There was a problem in SBCL code that CLISP pointed out. Some dead
code for the :SB-SHOW feature was being built even when that feature
wasn't given as a target feature. CLISP complained because the dead
code was defined in terms of a special variable which didn't exist in
that case. I fixed that.

There was what seems to be a problem in CLISP that I gave up on, but
which maybe someone here could help with. To replicate the problem, 
check SBCL out of CVS (since I dunno whether it'd be exactly the 
same in the last release version) and do
  $ sh make.sh clisp
and wade through the output. Find the message
       *** - RENAME-FILE: File #P"/usr/stuff/sbcl/obj/from-host/src/code/show.lisp-obj" already exists
(where of course the absolute filenames will be different on your
system depending on where you're building SBCL). I think this means
that CLISP considers it a fatal error that the target file exists when
it does RENAME-FILE. I don't think this is coming from an actual
RENAME-FILE call in my code, since I tried to protect those with
preceding #+CLISP (DELETE-FILE ...) operations and that didn't fix the
problem. I don't really understand the BACKTRACE from the point of the
error,
    Compilation of file /usr/stuff/sbcl/src/code/show.lisp is finished.
    0 errors, 0 warnings
    *** - RENAME-FILE: File #P"/usr/stuff/sbcl/obj/from-host/src/code/show.lisp-obj" already exists
    1. Break SB-COLD[8]> backtrace
    EVAL frame for form 
    (FUNCALL LOAD-OR-CLOAD-STEM STEM :IGNORE-FAILURE-P
     (FIND :IGNORE-FAILURE-P FLAGS))
    EVAL frame for form 
    (UNLESS (FIND :NOT-HOST FLAGS)
     (FUNCALL LOAD-OR-CLOAD-STEM STEM :IGNORE-FAILURE-P
      (FIND :IGNORE-FAILURE-P FLAGS)))
    EVAL frame for form 
    (LET
     ((STEM (FIRST #:STEM-AND-FLAGS-5802)) (FLAGS (REST #:STEM-AND-FLAGS-5802)))
     (UNLESS (FIND :NOT-HOST FLAGS)
      (FUNCALL LOAD-OR-CLOAD-STEM STEM :IGNORE-FAILURE-P
       (FIND :IGNORE-FAILURE-P FLAGS))))
    EVAL frame for form 
    (TAGBODY #:G5804 (IF (ENDP #:G5803) (GO #:G5805))
     (SETQ #:STEM-AND-FLAGS-5802 (CAR #:G5803))
     (LET
      ((STEM (FIRST #:STEM-AND-FLAGS-5802)) (FLAGS (REST #:STEM-AND-FLAGS-5802)))
      (UNLESS (FIND :NOT-HOST FLAGS)
       (FUNCALL LOAD-OR-CLOAD-STEM STEM :IGNORE-FAILURE-P
        (FIND :IGNORE-FAILURE-P FLAGS))))
     ...)
but my guess the failure might be from a RENAME-FILE call within
     (COMPILE-FILE SRC :OUTPUT-FILE :TMP-OBJ).
My impression from the ANSI specification of RENAME-FILE is that it
shouldn't be signalling an error when the target filename already
exists (at least unless there's a permission problem which stops
the rename operation from continuing) but YMMV. Meanwhile, whatever
way CLISP deals with this situation, if anyone who knows
more about the CLISP debugger could tell me more about where and
why the error is happening, I could try to tweak the SBCL build process
to work around the problem.
    
There's also a remaining non-ANSI-ism in CLISP which has historically
caused problems in SBCL bootstrapping, even though I didn't run into
it this time: (FUNCTION (SETF SYMBOL-FUNCTION)) doesn't work (signals
an error).

Also, CLISP's non-ANSI-compliant FORMAT strings (no support for the
post-CLTL1 "~_" directive) caused problems when I tried to build
another application under CLISP. I use "~_" directives a lot in my
debugging and error messages in any Lisp code, including SBCL, so that
might become a nuisance as further progress is made in SBCL
bootstrapping. It should be straightforward to work around that with
#-CLISP/#+CLISP code, but it would be nice not to have to.

-- 
William Harold Newman <[email-masked]>
HAPPY HACKING TO ALL, AND I'LL BE BACK NEXT YEAR!
  -- http://www.yetanother.org/damian/diary_December_2001.html#day_24
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C

---

From: lin8080 <[email-masked]>
Date: Tue Jan 1 15:12:02 2002

Hallo

Now I test and test and find something that works. So is there a better
way to do it ? 
This is because I'm new to CL (Version: "2000-03-06 (March 2000)" on
win98).

The code is:
---------------------
(setq sysdat (make-array '(6 3)))

...
(setf (aref sysdat 5 1) 'load)
...

(defun o ()
(eval (list (aref sysdat 5 1) "test.lisp"))
)
-------------------

Usually I named my new coding file "test.lisp". So now I typed in (o)
instead of (load "test.lisp"). The backtrace and redo function is not so
often in use, but the abort, to reach the toplevel. So, what is your
method testing new code ? Are there any tips ?

stefan

---

From: Sam Steingold <[email-masked]>
Date: Tue Jan 1 19:40:17 2002

> * In message <[email-masked]>
> * On the subject of "[clisp-list] problems bootstrapping SBCL with CLISP"
> * Sent on Sun, 30 Dec 2001 13:17:16 -0600
> * Honorable William Harold Newman <[email-masked]> writes:
>

this was built in the end of November 2001 from quite old sources.
you should use the CVS sources as many things (like MAKE-LOAD-FORM,
FORMAT ~_ &c) have been added.

> (DOCUMENTATION X) fails when X is a PACKAGE.

this is a known deficiency: DOCUMENTATION still has CLtL1 implementation.
patches are welcome.

>      (FIND :IGNORE-FAILURE-P FLAGS))

what's the value of the variable LOAD-OR-CLOAD-STEM?
it is the function which generates the error.

>      (COMPILE-FILE SRC :OUTPUT-FILE :TMP-OBJ).

:TMP-OBJ is not a valid arg to :OUTPUT-FILE.
(compile-file "d:/sds/lisp/init.lisp" :output-file "c:/tmp/tmp.fas")
works just fine for me.

> it this time: (FUNCTION (SETF SYMBOL-FUNCTION)) doesn't work (signals

hmmm - didn't know about this bug.
I will look into this.

> post-CLTL1 "~_" directive)

this has been added some months ago.
please use the CVS version.

-- 
Sam Steingold (http://www.podval.org/~sds)
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
Perl: all stupidities of UNIX in one.

---

From: Sam Steingold <[email-masked]>
Date: Tue Jan 1 19:41:22 2002

---

From: William Harold Newman <[email-masked]>
Date: Wed Jan 2 12:43:06 2002

> FORMAT ~_ &c) have been added.

Good.
 
> this is a known deficiency: DOCUMENTATION still has CLtL1 implementation.

Right.
 
> :TMP-OBJ is not a valid arg to :OUTPUT-FILE.

That was a typo in my previous message. It's actually TMP-OBJ, a variable
holding an arbitrary filename. (One which for weird historical reasons
doesn't end either in ".fas" or in ".lib", but in something like 
".lisp-obj".)

Incidentally, I've since rediscovered that CLISP uses two files to
represent compiled files. The SBCL build process -- for more weird
historical reasons -- relies on moving the file created by
COMPILE-FILE to a new location. How important is the second file
created by CLISP's COMPILE-FILE? Is the SBCL build process going to
fail because it only moves part of the output of COMPILE-FILE?

> please use the CVS version.

I just tried that. I checked out a fresh copy of the source a few hours
ago onto my old RedHat Linux machine, 6.2 IIRC,
  $ uname -a
  Linux lightning.localdomain 2.2.14-5.0 #1 Tue Mar 7 20:53:41 EST 2000 i586 unknown
I did
    8  ./configure
    9  cd src
   10  makemake  --with-readline --with-gettext --with-dynamic-ffi > Makefile
   11  ./makemake  --with-readline --with-gettext --with-dynamic-ffi > Makefile
   12  make config.lisp
   13  make
It failed. The tail of the output from "make" looks like this:
  gcc -g -O2 -I. -I../../sigsegv ../../sigsegv/test3.c -x none -o test3  ./.libs/libsigsegv.a
  ./test1
  ./test2
  ./test3
  Starting recursion pass 1.
  Stack overflow 1 caught.
  Starting recursion pass 2.
  Stack overflow 2 caught.
  Test passed.
  make[1]: Leaving directory `/usr/local/src/clisp/src/sigsegv'
  make[1]: Entering directory `/usr/local/src/clisp/src/sigsegv'
  if [ ! -d /usr/local/src/clisp/src ] ; then mkdir /usr/local/src/clisp/src ; fi
  /bin/sh ./libtool --mode=install /usr/bin/install -c -m 644 libsigsegv.la /usr/local/src/clisp/src/libsigsegv.la
  /usr/bin/install -c -m 644 .libs/libsigsegv.lai /usr/local/src/clisp/src/libsigsegv.la
  /usr/bin/install -c -m 644 .libs/libsigsegv.a /usr/local/src/clisp/src/libsigsegv.a
  ranlib /usr/local/src/clisp/src/libsigsegv.a
  chmod 644 /usr/local/src/clisp/src/libsigsegv.a
  libtool: install: warning: remember to run `libtool --finish /usr/local/lib'
  if [ ! -d /usr/local/src/clisp/src ] ; then mkdir /usr/local/src/clisp/src ; fi
  /usr/bin/install -c -m 644 sigsegv.h /usr/local/src/clisp/src/sigsegv.h
  make[1]: Leaving directory `/usr/local/src/clisp/src/sigsegv'
  gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -fomit-frame-pointer -Wno-sign-compare -O2 -fexpensive-optimizations -DUNICODE -DDYNAMIC_FFI -c spvw.c
  In file included from lispbibl.d:1751,
                   from spvw.d:21:
  unix.d:874: conflicting types for `iconv'
  /usr/include/iconv.h:45: previous declaration of `iconv'
  In file included from spvw.d:21:
  lispbibl.d:7039: warning: register used for two global register variables
  spvw.d: In function `main':
  spvw.d:1705: warning: variable `argv_memneed' might be clobbered by `longjmp' or `vfork'
  make: *** [spvw.o] Error 1

-- 
William Harold Newman <[email-masked]>
"Our users will know fear and cower before our software! Ship it! Ship
it and let them flee like the dogs they are!" -- Klingon programmer
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C

---

From: Todd Sabin <[email-masked]>
Date: Wed Jan 2 19:20:01 2002

William Harold Newman <[email-masked]> writes:

>[...]

I'm seeing the same thing with the latest cvs on RH 6.2.  The problem
is that ICONV_CONST isn't being set properly.  I commented out the
three iconv decls in unix.d and it built ok afterwards.  No idea how
to fix the configure script.

The latest cvs builds fine on my RH 7.2 box.

Todd

---

From: Paolo Amoroso <[email-masked]>
Date: Thu Jan 3 04:25:03 2002

> created by CLISP's COMPILE-FILE? Is the SBCL build process going to

I include below a reply by Bruno to a similar question I asked a while back
to the list.

Paolo

-------------------------------------------------------------------------
~To: Multiple recipients of list <[email-masked]>
~Subject: Re: What's the purpose of .lib files?
~From: Bruno Haible <[email-masked]>
~Date: Thu, 24 Sep 1998 09:55:03 -0700 (PDT)

Paolo Amoroso <[email-masked]> asks:
> What is the purpose of the .lib files generated by the compiler?

The .lib files contain definitions that may be needed for compiling other
files.

Suppose you have a file A.lsp, defining functions, macros, constants etc.
And you have a file B.lsp, which contains a  (require 'A)  statement,
because it uses some things defined by A.lsp. Then compilations of B.lsp
will profit from a file A.lib, generated by a previous compilation of
A.lsp.
The benefit is threefold:

  - You don't need to have A loaded in order to compile B. If memory
    is tight, and if A contains only few inline functions, macros or
    constants, this is a space and time saver. If A.lsp does a lot
    of initializations or side effects when being loaded, this is
    important as well.

  - You don't need to have A loaded in order to compile B. You don't
    even have to *think* about A when loading or compiling B.

  - Suppose A.lsp is changed rarely, and B.lsp is changed frequently.
    It would be a waste of time to compile both A and B every time.
    The .lib file ensures that A is compiled only when needed.

Bruno
-------------------------------------------------------------------------

-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]

---

From: Sam Steingold <[email-masked]>
Date: Sun Jan 6 12:20:26 2002

> it this time: (FUNCTION (SETF SYMBOL-FUNCTION)) doesn't work (signals

(SETF SYMBOL-FUNCTION) is a macro, not a function in CLISP.
I don't think that ANSI requires it to be a function.

wrt (FUNCTION macro) ANSI says:

| It is an error to use function on a function name that does not denote
| a function in the lexical environment in which the function form
| appears. Specifically, it is an error to use function on a symbol that
| denotes a macro or special form . An implementation may choose not to
| signal this error for performance reasons, but implementations are
| forbidden from defining the failure to signal an error as a useful
| behavior.

I just fixed CLISP so that (FDEFINITION (SETF foo)) work even when (SETF
foo) is a macro, not a function.

thanks for your bug reports!

-- 
Sam Steingold (http://www.podval.org/~sds)
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
There is Truth, and its value is T.  Or just non-NIL.  So 0 is True!

---

From: William Harold Newman <[email-masked]>
Date: Sun Jan 6 13:31:02 2002

> | forbidden from defining the failure to signal an error as a useful

I was very surprised at this (that #'(SETF SYMBOL-FUNCTION) isn't
conforming code). At first I agreed with you anyway, but I've since
concluded that it's a (natural) misreading of the spec. I'll explain...

I looked for quite a while without finding anything in the ANSI spec
to contradict you. The page defining the symbol SYMBOL-FUNCTION says
that SYMBOL-FUNCTION itself is an "accessor". And the glossary
definition of "accessor" says it's an operator which reads or writes,
and the glossary definition of "operator" says it's either a function
or a macro. So it looks as though SYMBOL-FUNCTION itself can be a
macro, so (SETF SYMBOL-FUNCTION) can presumably be a macro too.

However, even though the spec seemed to agree with you, I wondered
whether we were reading the spec right. ANSI uses the terminology
"accessor" in the definitions of various function-ish things,
including CAR and FIND-CLASS. Is it really true that
  (mapcar #'car expressions)
and 
  (find class class-names :key #'find-class)
aren't portable code because a conforming ANSI CL implementation might
define CAR and FIND-CLASS as macros instead of functions? I found that
weird, enough so that I was skeptical about the (admittedly natural)
reading of the Hyperspec above.

Thus, I looked harder. Eventually, I found support for the behavior I
expected, in "1.4.4.14 The ``Name'' Section of a Dictionary Entry". It
says
    This section introduces the dictionary entry. It is not explicitly
  labeled. It appears preceded and followed by a horizontal bar.
    In large print at left, the defined name appears; if more than one
  defined name is to be described by the entry, all such names are
  shown separated by commas. 
    In somewhat smaller italic print at right is an indication of what
  kind of dictionary entry this is. Possible values are: 
    Accessor 
      This is an accessor function. 
    [etc.]
So: I think when you see "accessor" at the head of an entry in the
symbols dictionary, it is to be interpreted as "accessor function".
(And yes, this *does* seem like a remarkably indirect and confusing
way to specify the function-not-macro-ness of things like CAR.)

> foo) is a macro, not a function.

Thank you.

(And please be patient about the SBCL/CLISP porting stuff, since I'm
still flailing at other sbcl problems.)

---

From: Kaz Kylheku <[email-masked]>
Date: Sun Jan 6 13:58:03 2002

On Sun, 6 Jan 2002, William Harold Newman wrote:

> conforming code).

I'd be surprised if anything other than #'function-name or
#'(lambda ... expression) is conforming code.

 At first I agreed with you anyway, but I've since
> that SYMBOL-FUNCTION itself is an "accessor". 

That is completely irrelevant. The special operator called ``function''
receives its parameter unevaluated. So in the expression

    (function (setf ...))

the operator simply receives the list (setf ...).  The operator
understands only two things: a function name, or a lambda expression.
It will ``curry'' either of these into a funcall-able object.

In order for (function (setf ...)) to do anything useful, the setf form
would have to be considered a lambda expression.  This is not the case;
a lambda expression is a list object whose first element is the symbol
lambda.

> And the glossary

It's only an accessor when it's evaluated, not when it's part of a
dead list that is passed unevaluated to an operator.

If you want to turn the form 

    (setf (symbol-function some-symbol) new-value)

into a funcallable object which takes new-value as a parameter, wrap it
in a lambda expression:

    #'(lambda (new-value) (setf (symbol-function some-symbol) new-value))

There you go, now you can funcall this with one argument, new new value
to be stored in the symbol's function cell.

---

From: "Thomas F. Burdick" <[email-masked]>
Date: Sun Jan 6 14:14:02 2002

> #'(lambda ... expression) is conforming code.

Maybe you should have looked in the spec before reacting in surprise :)

 > It will ``curry'' either of these into a funcall-able object.

No, the FUNCTION special operator takes a "function name" as its
argument.  From the glossary:

  function name n. 1. (in an environment) A symbol or a list (setf
  symbol) that is the name of a function in that environment. 2. A
  symbol or a list (setf symbol).

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'

---

From: "Thomas F. Burdick" <[email-masked]>
Date: Sun Jan 6 14:18:02 2002

> argument.  From the glossary:

Er, I meant to say that FUNCTION takes either a lambda expression or a
"function name"

---

From: Sam Steingold <[email-masked]>
Date: Sun Jan 6 17:46:01 2002

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] problems bootstrapping SBCL with CLISP"
> * Sent on Sun, 6 Jan 2002 15:19:53 -0600

I would greatly appreciate it if you asked this on comp.lang.lisp.
#'(setf car) is the same as rplaca, so there is no problem there, but
with other macros, it _IS_ an issue.

You are basically telling me that for each macro I must provide a
function definition which would work the same way as the macro does.

I don't think this is a valid requirement.

-- 
Sam Steingold (http://www.podval.org/~sds)
Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp>
Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/>
Sufficiently advanced stupidity is indistinguishable from malice.

---

From: William Harold Newman <[email-masked]>
Date: Sun Jan 6 21:10:01 2002

[...]
> You are basically telling me that for each macro I must provide a
                                    ^^^^^^^^^^^^^^
> function definition which would work the same way as the macro does.

Well, no, not for DEFMACRO, DEFINE-SETF-EXPANDER, LOOP, and so forth.
The symbols dictionary lists those as macros, not accessors, and 
so AFAIK the special meaning of "accessor" in the context of the symbol
dictionary has nothing to do with them.

What I do believe is that when something is labelled an "accessor" in
the symbols dictionary, it means "accessor function". If the HyperSpec
is as systematically organized as it looks, then all the relevant
operators should be in these sections:
  HyperSpec/Body/acc_aref.html
  HyperSpec/Body/acc_bitcm_sbit.html
  HyperSpec/Body/acc_carcm_cdr_darcm_cddddr.html
  HyperSpec/Body/acc_charcm_schar.html
  HyperSpec/Body/acc_compiler-_cro-function.html
  HyperSpec/Body/acc_elt.html
  HyperSpec/Body/acc_fdefinition.html
  HyperSpec/Body/acc_fill-pointer.html
  HyperSpec/Body/acc_find-class.html
  HyperSpec/Body/acc_firstcm_s_inthcm_tenth.html
  HyperSpec/Body/acc_get.html
  HyperSpec/Body/acc_getf.html
  HyperSpec/Body/acc_gethash.html
  HyperSpec/Body/acc_ldb.html
  HyperSpec/Body/acc_logical-p_translations.html
  HyperSpec/Body/acc_macro-function.html
  HyperSpec/Body/acc_mask-field.html
  HyperSpec/Body/acc_nth.html
  HyperSpec/Body/acc_readtable-case.html
  HyperSpec/Body/acc_rest.html
  HyperSpec/Body/acc_row-major-aref.html
  HyperSpec/Body/acc_subseq.html
  HyperSpec/Body/acc_svref.html
  HyperSpec/Body/acc_symbol-function.html
  HyperSpec/Body/acc_symbol-plist.html
  HyperSpec/Body/acc_symbol-value.html
  HyperSpec/Body/acc_values.html
Thus portable code can count on AREF, SBIT, CHAR, LDB, REST,
SYMBOL-VALUE, and so forth being implemented as functions, not macros.

Note that the symbols in this category are more like CAR (where, as you
say, a functional form is obvious) than like LOOP (where a functional
form might be even more baroque than the macro).
 
> I don't think this is a valid requirement.

If you mean "requiring a function corresponding to LOOP is not valid",
then I agree with you. If you mean "requiring that the operators CAR
and SVREF and GETHASH (and for that matter (SETF CAR) and (SETF SVREF)
and (SETF GETHASH)) be implemented as functions is not valid", then I
disagree.

---

From: Christophe Rhodes <[email-masked]>
Date: Mon Jan 7 02:18:04 2002

On Sun, Jan 06, 2002 at 08:42:51PM -0500, Sam Steingold wrote:
> > [ section 1.4.4.14 of the HyperSpec]
> >
> >     Accessor 

I think that what the standard requires is that symbols that are
labeled as accessors in the CLHS have functional definitions for both
SYMBOL and (SETF SYMBOL), that are returned by FUNCTION and
FDEFINITION, and may be called to have the relevant effect.

References:

<http://www.xanalys.com/software_tools/reference/HyperSpec/Body/acc_symbol-function.html>
<http://www.xanalys.com/software_tools/reference/HyperSpec/Body/sec_1-4-4-14.html>
<http://www.xanalys.com/software_tools/reference/HyperSpec/Body/glo_f.html#function>
<http://www.xanalys.com/software_tools/reference/HyperSpec/Body/glo_f.html#function_name>

Cheers,

Christophe
-- 
Jesus College, Cambridge, CB5 8BL                           +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/                  (defun pling-dollar 
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)