When I do the following, with acl an error occur (which is ok) but I
cannot recover from the error and I have to exit.
USER(1): (lisp-implementation-version)
"5.0 [Linux/X86] (8/29/98 10:57)"
USER(2): (progn (setq *random-state* 'i-should-not-do-that)
(random 100))
Error: Recursive loop in finalize-inheritance
#<STANDARD-CLASS SYNCHRONOUS-OPERATING-SYSTEM-SIGNAL>
[condition type: SIMPLE-ERROR]
Restart actions (select using :continue):
0: Return to Top Level (an "abort" restart)
[1] USER(9): [1] USER(9): :cont 0
Error: Recursive loop in finalize-inheritance
#<STANDARD-CLASS SYNCHRONOUS-OPERATING-SYSTEM-SIGNAL>
[condition type: SIMPLE-ERROR]
Restart actions (select using :continue):
0: Return to Top Level (an "abort" restart)
[changing package from "COMMON-LISP-USER" to "TOP-LEVEL"]
[2] TPL(10):
The same unspecific error message occurs with ACL6.0 but I can recover
from the error.
CL-USER(1): (lisp-implementation-version)
"6.0 [Linux (x86)] (Aug 31, 2001 13:46)"
CL-USER(2): (progn (setq *random-state* 'i-should-not-do-that)
(random 100))
Error: Recursive loop in finalize-inheritance
#<STANDARD-CLASS SYNCHRONOUS-OPERATING-SYSTEM-SIGNAL>
[condition type: SIMPLE-ERROR]
Restart actions (select using :continue):
0: Return to Top Level (an "abort" restart)
1: Abort #<PROCESS Initial Lisp Listener>
[1] CL-USER(3): :cont 0
CL-USER(4):
I think that it's a bug.
CLISP and Lispworks give a correct error message:
[1]> (lisp-implementation-version)
"2000-03-09 (March 2000)"
[2]> (progn (setq *random-state* 'i-should-not-do-that)
(random 100))
*** - RANDOM: the value of *RANDOM-STATE* should be a
random-state, not I-SHOULD-NOT-DO-THAT
1. Break [3]>
Lispworks:
CL-USER 754 > (lisp-implementation-version)
"4.1.20"
CL-USER 755 > (progn (setq *random-state* 'i-should-not-do-that)
(random 100))
Error: Arithmetic error in RANDOM of (100 I-SHOULD-NOT-DO-THAT):
Second argument should be a random-state object.
1 (continue) Return a value to use.
2 (abort) Return to level 0.
3 Return to top loop level 0.
Type :b for backtrace, :c <option number> to proceed, or
:? for other options
CL-USER 756 : 1 >
Thibault Langlois
··@inesc.pt writes:
> When I do the following, with acl an error occur (which is ok) but I
> cannot recover from the error and I have to exit.
It's a well-packaged and clear bug report. And I do agree a problem
like this is frustrating. I suspect Franz may even try to fix it,
at least in their latest system (though you suggest it's not so severe
there). HOWEVER, ...
You should know that in general it is not possible to recover from all
possible user errors and you have an obligation not to try things just
in case there's no way out. In other words, this is not necessarily a
bug--the implementation is permitted to "crash and burn" when it is
YOU who have first violated the contractual constraints between
programmer and implementation. For example, the implementation might
NEED the random number generator itself in order to reach a debugging
prompt or in order to handle the error.
Without a source license, you cannot know what tools will and won't be
needed for safe execution of the Lisp to continue. So when you break
a tool in a system that uses object-oriented (that is, heavily shared)
tools, you should not be surprised if things go downhill quickly.
In general, I recommend that errors like this be reported directly to
the vendor, not to comp.lang.lisp. This is because (1) the vendor may
otherwise accidentaly miss your report and (2) there is nothing the
community here can do about a vendor bug.
> USER(1): (lisp-implementation-version)
> "5.0 [Linux/X86] (8/29/98 10:57)"
> USER(2): (progn (setq *random-state* 'i-should-not-do-that)
> (random 100))
> Error: Recursive loop in finalize-inheritance
> #<STANDARD-CLASS SYNCHRONOUS-OPERATING-SYSTEM-SIGNAL>
> [condition type: SIMPLE-ERROR]
>
> Restart actions (select using :continue):
> 0: Return to Top Level (an "abort" restart)
> [1] USER(9): [1] USER(9): :cont 0
> Error: Recursive loop in finalize-inheritance
> #<STANDARD-CLASS SYNCHRONOUS-OPERATING-SYSTEM-SIGNAL>
> [condition type: SIMPLE-ERROR]
>
> Restart actions (select using :continue):
> 0: Return to Top Level (an "abort" restart)
>
> [changing package from "COMMON-LISP-USER" to "TOP-LEVEL"]
> [2] TPL(10):
>
> The same unspecific error message occurs with ACL6.0 but I can recover
> from the error.
>
> CL-USER(1): (lisp-implementation-version)
> "6.0 [Linux (x86)] (Aug 31, 2001 13:46)"
> CL-USER(2): (progn (setq *random-state* 'i-should-not-do-that)
> (random 100))
> Error: Recursive loop in finalize-inheritance
> #<STANDARD-CLASS SYNCHRONOUS-OPERATING-SYSTEM-SIGNAL>
> [condition type: SIMPLE-ERROR]
>
> Restart actions (select using :continue):
> 0: Return to Top Level (an "abort" restart)
> 1: Abort #<PROCESS Initial Lisp Listener>
> [1] CL-USER(3): :cont 0
> CL-USER(4):
>
> I think that it's a bug.
>
> CLISP and Lispworks give a correct error message:
>
> [1]> (lisp-implementation-version)
> "2000-03-09 (March 2000)"
> [2]> (progn (setq *random-state* 'i-should-not-do-that)
> (random 100))
>
> *** - RANDOM: the value of *RANDOM-STATE* should be a
> random-state, not I-SHOULD-NOT-DO-THAT
> 1. Break [3]>
>
> Lispworks:
> CL-USER 754 > (lisp-implementation-version)
> "4.1.20"
>
> CL-USER 755 > (progn (setq *random-state* 'i-should-not-do-that)
> (random 100))
>
> Error: Arithmetic error in RANDOM of (100 I-SHOULD-NOT-DO-THAT):
> Second argument should be a random-state object.
> 1 (continue) Return a value to use.
> 2 (abort) Return to level 0.
> 3 Return to top loop level 0.
>
> Type :b for backtrace, :c <option number> to proceed, or
> :? for other options
>
> CL-USER 756 : 1 >
>
>
> Thibault Langlois
Kent M Pitman <······@world.std.com> writes:
> Without a source license, you cannot know what tools will and won't be
> needed for safe execution of the Lisp to continue. So when you break
> a tool in a system that uses object-oriented (that is, heavily shared)
> tools, you should not be surprised if things go downhill quickly.
>
I remember what (trace print) did to a Dmachine. I just wish it had
been alive enough at the end of it that I could have got a screen
snapshot...
--tim
Tim Bradshaw <···@tfeb.org> writes:
> Kent M Pitman <······@world.std.com> writes:
>
>
> > Without a source license, you cannot know what tools will and won't be
> > needed for safe execution of the Lisp to continue. So when you break
> > a tool in a system that uses object-oriented (that is, heavily shared)
> > tools, you should not be surprised if things go downhill quickly.
>
> I remember what (trace print) did to a Dmachine. I just wish it had
> been alive enough at the end of it that I could have got a screen
> snapshot...
Heh.
Well, and by contrast, I remember a friend in the VAXLISP group pointing
out to me that VAXLISP had a bullet-proofed TRACE that had its own private
copies of untraceable routines to do the entire action so that you could,
they claimed (and I never got a chance to test it), trace ANYTHING and not
lose. (I assume this was before gray streams. ;-)
So what you get varies vendor-to-vendor.
From: Tim Bradshaw
Subject: Re: ACL: bug in error processing ?
Date:
Message-ID: <ey3y9nvnjn8.fsf@cley.com>
* Kent M Pitman wrote:
> Well, and by contrast, I remember a friend in the VAXLISP group pointing
> out to me that VAXLISP had a bullet-proofed TRACE that had its own private
> copies of untraceable routines to do the entire action so that you could,
> they claimed (and I never got a chance to test it), trace ANYTHING and not
> lose. (I assume this was before gray streams. ;-)
Funnily enough, one of the things I tend to test when trying a new
implementation is whether a few things like tracing PRINT work.
Obviously it doesn't have to work, but it's kind of a good sign if it
does in terms of implementation quality.
--tim (just tried in in ACL and LW, works in both)