I've installed CMUCL on a Linux system like described here:
http://www.cons.org/cmucl/install.html
and it looks like it works:
···@it4systems:~$ lisp
CMU Common Lisp 19a, running on it4systems
With core: /usr/local/lib/cmucl/lib/lisp.core
Dumped on: Wed, 2004-07-28 18:51:48+02:00 on lorien
See <http://www.cons.org/cmucl/> for support information.
Loaded subsystems:
Python 1.1, target Intel x86
CLOS based on Gerd's PCL 2004/04/14 03:32:47
* (format t "1+1=~A" (+ 1 1))
1+1=2
NIL
But when I test array bounds, there is no nice error message:
* (aref (make-array 5) 7)
Unable to display error condition:
Error in function CONDITIONS::FIND-SLOT-DEFAULT:
Condition slot is not bound: CONDITIONS::FORMAT-CONTROL
[Condition of type SIMPLE-TYPE-ERROR]
Restarts:
0: [ABORT] Return to Top-Level.
How can I fix this?
And I think I need a site-init.lisp, perhaps someone has a good starting
point. It needs to be safe, with all useful runtime error checkings, not
fast.
--
Frank Bu�, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: Rob Warnock
Subject: Re: cmucl problem: Condition slot is not bound: CONDITIONS::FORMAT-CONTROL
Date:
Message-ID: <N_ydncD0btGQUcTfRVn-tg@speakeasy.net>
Frank Buss <··@frank-buss.de> wrote:
+---------------
| I've installed CMUCL on a Linux system ...
| CMU Common Lisp 19a, running on it4systems
...
| But when I test array bounds, there is no nice error message:
| * (aref (make-array 5) 7)
| Unable to display error condition:
| Error in function CONDITIONS::FIND-SLOT-DEFAULT:
| Condition slot is not bound: CONDITIONS::FORMAT-CONTROL
| [Condition of type SIMPLE-TYPE-ERROR]
+---------------
The problem appears to have been introduced in CMUCL-19a, or rather,
*after* -18e, and is not Linux-Specific -- I see the same things on
FreeBSD:
> (list (software-type) (software-version))
("FreeBSD" "4.10-RELEASE")
> (list (lisp-implementation-type) (lisp-implementation-version))
("CMU Common Lisp" "19a-pre3 02-Jul-2004")
> (aref (make-array 5) 7)
Unable to display error condition:
Error in function CONDITIONS::FIND-SLOT-DEFAULT:
Condition slot is not bound: CONDITIONS::FORMAT-CONTROL
[Condition of type SIMPLE-TYPE-ERROR]
...
Whereas on CMUCL-18e:
> (list (software-type) (software-version))
("FreeBSD" "4.6-RELEASE")
cmu> (list (lisp-implementation-type) (lisp-implementation-version))
("CMU Common Lisp" "18e")
cmu> (aref (make-array 5) 7)
Invalid index 7 in #(0 0 0 0 0)
Restarts:
0: [ABORT] Return to Top-Level.
I get the same results under Red Hat Linux 3.2.3-39 (kernel 2.4.21-15.0.4.EL)
as shown above for both -18e & -19a, so it's not Linux per se.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Kent M Pitman
Subject: Re: cmucl problem: Condition slot is not bound: CONDITIONS::FORMAT-CONTROL
Date:
Message-ID: <uvf6ro2sh.fsf@nhplace.com>
····@rpw3.org (Rob Warnock) writes:
> Frank Buss <··@frank-buss.de> wrote:
> +---------------
> | I've installed CMUCL on a Linux system ...
> | CMU Common Lisp 19a, running on it4systems
> ...
> | But when I test array bounds, there is no nice error message:
> | * (aref (make-array 5) 7)
> | Unable to display error condition:
> | Error in function CONDITIONS::FIND-SLOT-DEFAULT:
> | Condition slot is not bound: CONDITIONS::FORMAT-CONTROL
> | [Condition of type SIMPLE-TYPE-ERROR]
> +---------------
>
> The problem appears to have been introduced in CMUCL-19a, or rather,
> *after* -18e, and is not Linux-Specific -- I see the same things on
> FreeBSD: [...]
>
> Whereas on CMUCL-18e: [...]
>
> I get the same results under Red Hat Linux 3.2.3-39 (kernel
> 2.4.21-15.0.4.EL) as shown above for both -18e & -19a, so it's not
> Linux per se.
I don't have sources to look at, but I know we renamed FORMAT-STRING
to FORMAT-CONTROL when we allowed it to contain a format control
function. Someone could have made the two slots be synonyms in the
object in one direction in one implementation, and either not at all
or in the other direction in another implementation.
I believe the standard only specifies the accessors and not the slots,
so maybe someone is with-slots'ing thinking they can rely accidentally
on the names being chosen in a certain way and then is losing.
I ordinarily wouldn't respond to something this low-level on a large
discussion group, except that I think it's worthwhile to periodically
underscore that safe coding of portable code does not rely on with-slots
working on standard conditions, since I think some implementations
will let this accidentally work and as a consequence some users may
accidentally come to rely on it unwitting that they are outside the
realm of conformance (and hence of portability).