[Openmcl-devel] Restart strangeness

Gary Byers gb at clozure.com
Tue Jun 22 23:51:03 UTC 2004

On Tue, 22 Jun 2004, Will wrote:

> Hello,
> Today someone reported problems with restarts and SLIME on freenode's #lisp,
> but it actually looks like a problem with OpenMCL itself.
> will:~/temp will$ openmcl
> Welcome to OpenMCL Version (Beta: Darwin) 0.14.2-p1!
> ? (foo)
> > Error in process listener(1): Undefined function FOO called with arguments () .
> > While executing: "Unknown"
> > Type :GO to continue, :POP to abort.
> > If continued: Retry applying FOO to NIL.
> Type :? for other options.
> 1 > :r
> 0. Return to break level 1.
> 1. #<RESTART ABORT-BREAK #x4B8856>
> 2. Retry applying FOO to NIL.
> 3. Apply specified function to NIL this time.
> 4. Specify a function to use as the definition of FOO.
> 5. Return to toplevel.
> 8. #<RESTART ABORT #x4B8E2E>
> 1 > (:c 8)
> At this point OpenMCL just hangs until interrupted with ^C

That ABORT restart causes the listener thread to exit.  It isn't generally
very useful to invoke this (IIRC, it's basically just there so that calling
ABORT will do something other than complain that "there's no active restart
named ABORT.")

The little menu of restarts that :R presents is generated from the
value returned by COMPUTE-RESTARTS (which, by definition, includes
things that are shadowed by restarts of the same name that have been
established more recently.)  Restart 0 in your test case is also named
ABORT, and it would/should be invoked if you call (ABORT) in the break
loop.  (This would be clearer if the :R menu showed the name of the
restart as well as the description, and the catch-all restarts (7 and
8) should either not be displayed in the menu or given descriptions
that say "you probably don't want to invoke this from a break loop;
doing so will kill the initial listener and leave you in an
environment where the initial thread is looping around wondering why
things have gotten so quiet all of a sudden ...".

> ^CInvoking restart: #<RESTART ABORT #x4B8E2E>
> > Break:
> > While executing: #<Anonymous Function #x612CEFE>
> > Type :GO to continue, :POP to abort.
> > If continued: Return from BREAK.
> Type :? for other options.
> 1 > :b
> (BFFFFB70) : 0 "Anonymous Function #x612CEFE" 120
> (BFFFFBA0) : 2 "Anonymous Function #x60F8DBE" 312
> 1 >
> The same thing happens for restart 7 too.

For the same reason.  If you do

1 > :proc

in this environment, you'll see that the initial process is the only
one that's still running.

> Regards,
> Will

As far as I know, the bug that affects SLIME is in
INVOKE-RESTART-INTERACTIVELY and its ability to recognize restarts set
up by WITH-SIMPLE-RESTART.  (Bryan O'Connor fixed a similar bug in
INVOKE-RESTART a few months ago, but we both missed the fact that the
interactive case had the same problem.)  That should be fixed in CVS
as of this morning.  (There's certainly been a bug in
INVOKE-RESTART-INTERACTIVELY and I -hope- it's been the cause of the
problems with SLIME; I don't use SLIME regularly and haven't tried
to confirm this yet.)

More information about the Openmcl-devel mailing list