SBCL, SLIME and C-c (abort)

Hi,

I am trying to find out how to abort a calculation in SBCL (1.0.12.0),
running inside SLIME (20071202). When I press C-c to interrupt
something, I get

Interrupt from Emacs
[Condition of type SIMPLE-ERROR]

Restarts:
0: [CONTINUE] Continue from interrupt.
1: [ABORT] Return to SLIME's top level.
2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "new-repl-
thread" {C07F3F1}>)

but neither 1 nor 2 will abort the calculation.

Thanks,

Tamas

On Jan 16, 8:18*pm, Tamas <tkp...@gmail.com> wrote:
> Hi,
>
> I am trying to find out how to abort a calculation in SBCL (1.0.12.0),
> running inside SLIME (20071202). *When I press C-c to interrupt
> something, I get
>
> Interrupt from Emacs
> * *[Condition of type SIMPLE-ERROR]
>
> Restarts:
> *0: [CONTINUE] Continue from interrupt.
> *1: [ABORT] Return to SLIME's top level.
> *2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "new-repl-
> thread" {C07F3F1}>)
>
> but neither 1 nor 2 will abort the calculation.
>
> Thanks,
>
> Tamas

If this was compiled with multithreading, this is a known feature.
What sometimes works for me is to redefine one of the functions that
is being executed by adding a bug so that when SBCL evaluates the
revised function in the runaway process it stops and throws an error
on the bug. If that makes sense. Doesn't always work.

vanekl <vanek@acd.net> writes:

> On Jan 16, 8:18*pm, Tamas <tkp...@gmail.com> wrote:
> > Hi,
> >
> > I am trying to find out how to abort a calculation in SBCL (1.0.12.0),
> > running inside SLIME (20071202). *When I press C-c to interrupt
> > something, I get
> >
> > Interrupt from Emacs
> > * *[Condition of type SIMPLE-ERROR]
> >
> > Restarts:
> > *0: [CONTINUE] Continue from interrupt.
> > *1: [ABORT] Return to SLIME's top level.
> > *2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "new-repl-
> > thread" {C07F3F1}>)
> >
> > but neither 1 nor 2 will abort the calculation.
>
> If this was compiled with multithreading, this is a known feature.

I don't think so. This sounds like a bug. The OP should send a more
detailed mail to the development list of Slime.

-T.

On Jan 17, 1:07*am, "Tobias C. Rittweiler" <t...@freebits.de.invalid>
wrote:
> vanekl <va...@acd.net> writes:
> > On Jan 16, 8:18*pm, Tamas <tkp...@gmail.com> wrote:
> > > Hi,
>
> > > I am trying to find out how to abort a calculation in SBCL (1.0.12.0),
> > > running inside SLIME (20071202). *When I press C-c to interrupt
> > > something, I get
>
> > > Interrupt from Emacs
> > > * *[Condition of type SIMPLE-ERROR]
>
> > > Restarts:
> > > *0: [CONTINUE] Continue from interrupt.
> > > *1: [ABORT] Return to SLIME's top level.
> > > *2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "new-repl-
> > > thread" {C07F3F1}>)
>
> > > but neither 1 nor 2 will abort the calculation.
>
> > If this was compiled with multithreading, this is a known feature.
>
> I don't think so. This sounds like a bug. The OP should send a more
> detailed mail to the development list of Slime.
>
> * -T.

This is known. See
http://www.cliki.net/SLIME%20Features

vanekl <vanek@acd.net> writes:

> On Jan 17, 1:07*am, "Tobias C. Rittweiler" <t...@freebits.de.invalid>
> wrote:
> > vanekl <va...@acd.net> writes:
> > > On Jan 16, 8:18*pm, Tamas <tkp...@gmail.com> wrote:
> > > > Hi,
> > > >
> > > > I am trying to find out how to abort a calculation in SBCL (1.0.12.0),
> > > > running inside SLIME (20071202). *When I press C-c to interrupt
> > > > something, I get
> > > > ....
> > > > but neither 1 nor 2 will abort the calculation.
> > >
> > > If this was compiled with multithreading, this is a known feature.
> >
> > I don't think so. This sounds like a bug. The OP should send a more
> > detailed mail to the development list of Slime.
> >
> > * -T.
>
> This is known. See
> http://www.cliki.net/SLIME%20Features

I fail to see where this describes that this is actually desired
behaviour, nor where an explanation is given on a putative inevitability
of this state.

-T.

On Jan 17, 2:45*am, "Tobias C. Rittweiler" <t...@freebits.de.invalid>
wrote:
> vanekl <va...@acd.net> writes:
> > On Jan 17, 1:07*am, "Tobias C. Rittweiler" <t...@freebits.de.invalid>
> > wrote:
> > > vanekl <va...@acd.net> writes:
> > > > On Jan 16, 8:18*pm, Tamas <tkp...@gmail.com> wrote:
> > > > > Hi,
>
> > > > > I am trying to find out how to abort a calculation in SBCL (1.0.12..0),
> > > > > running inside SLIME (20071202). *When I press C-c to interrupt
> > > > > something, I get
> > > > > * *....
> > > > > but neither 1 nor 2 will abort the calculation.
>
> > > > If this was compiled with multithreading, this is a known feature.
>
> > > I don't think so. This sounds like a bug. The OP should send a more
> > > detailed mail to the development list of Slime.
>
> > > * -T.
>
> > This is known. See
> >http://www.cliki.net/SLIME%20Features
>
> I fail to see where this describes that this is actually desired
> behaviour, nor where an explanation is given on a putative inevitability
> of this state.
>
> * -T.

I don't see that either. All I said is that this behavior is known.

Tamas <tkpapp@gmail.com> writes:

> Hi,
>
> I am trying to find out how to abort a calculation in SBCL (1.0.12.0),
> running inside SLIME (20071202). When I press C-c to interrupt
> something, I get
>
> Interrupt from Emacs

If you have started the calculation with C-x C-e from some Lisp buffer, you
should be able to interrupt it with C-c C-b from inside this buffer. At
least, that works for me.

Nicolas

On Jan 16, 8:07 pm, "Tobias C. Rittweiler" <t...@freebits.de.invalid>
wrote:
> I don't think so. This sounds like a bug. The OP should send a more
> detailed mail to the development list of Slime.

I tracked down (and solved) the issue, and I am not sure it is a bug.
What happened is that I calculated a large sparse matrix and performed
operations on it, using cl-sparsematrix, which is extremely fast
because it uses hash tables. But when the last of the operations
completed, it returned the result, and the REPL wanted to print it.
It had approx 4000 x 4000 elements, so even if it appeared in the
little area below the Emacs modeline, and only partially, the whole
bloody thing was generated and that was the process eating the CPU. I
had hard time debugging this issue, because the actual operation was
performed in a blink of an eye (0.05s) and sb-sprof:with-profiling
showed nothing, and the pretty-printing started after the profiler
stops, and took about 5s.

So I am not sure that not being able to terminate something that is
not the operation executing but the REPL pretty-printing is a bug,
those operations are not supposed to take ages anyhow, my case was an
exception.

Thanks for all the help,

Tamas

Den Thu, 17 Jan 2008 08:07:18 -0800 skrev Tamas:

> I tracked down (and solved) the issue, and I am not sure it is a bug.
> What happened is that I calculated a large sparse matrix and performed
> operations on it, using cl-sparsematrix, which is extremely fast because
> it uses hash tables. But when the last of the operations completed, it
> returned the result, and the REPL wanted to print it. It had approx 4000
> x 4000 elements, so even if it appeared in the little area below the
> Emacs modeline, and only partially, the whole bloody thing was generated
> and that was the process eating the CPU. I had hard time debugging this
> issue, because the actual operation was performed in a blink of an eye
> (0.05s) and sb-sprof:with-profiling showed nothing, and the
> pretty-printing started after the profiler stops, and took about 5s.
>
> So I am not sure that not being able to terminate something that is not
> the operation executing but the REPL pretty-printing is a bug, those
> operations are not supposed to take ages anyhow, my case was an
> exception.

Then it was probably not SBCL being busy, but emacs and/or emacs + swank
transferring and formatting the output. Those kinds of lockups are in
general hard to deal with, in the best case, if emacs is unresponsive,
you can C-g it and it stops. In the worst case, you can do exactly
nothing but wait.

Cheers,
Maciej

On Jan 17, 5:07*pm, Tamas <tkp...@gmail.com> wrote:
> On Jan 16, 8:07 pm, "Tobias C. Rittweiler" <t...@freebits.de.invalid>
> wrote:
>
> > I don't think so. This sounds like a bug. The OP should send a more
> > detailed mail to the development list of Slime.
>
> I tracked down (and solved) the issue, and I am not sure it is a bug.
> What happened is that I calculated a large sparse matrix and performed
> operations on it, using cl-sparsematrix, which is extremely fast
> because it uses hash tables. *But when the last of the operations
> completed, it returned the result, and the REPL wanted to print it.
> It had approx 4000 x 4000 elements, so even if it appeared in the
> little area below the Emacs modeline, and only partially, the whole
> bloody thing was generated and that was the process eating the CPU. *I
> had hard time debugging this issue, because the actual operation was
> performed in a blink of an eye (0.05s) and sb-sprof:with-profiling
> showed nothing, and the pretty-printing started after the profiler
> stops, and took about 5s.
>
> So I am not sure that not being able to terminate something that is
> not the operation executing but the REPL pretty-printing is a bug,
> those operations are not supposed to take ages anyhow, my case was an
> exception.
>
> Thanks for all the help,
>
> Tamas

I am working on a project in which deep and sometimes cyclic data
structures are being pretty-printed. At the beginning of each
development session I evaluate the following code:

(setq *print-pretty* t ; initial value not specified by the standard
*print-circle* t
*print-length* 20
*print-level* 5)

Hope that helps in one way or another...