[cells-devel] Current DP ... not GE pulse ... of cell ...?

[Ken Tilton]

[ccing cells-devel because usefully on topic]

Peter Hildebrandt wrote:
>> Me, too. The question is why can't you just abort the backtrace, fix the
>>mistake, and re-run. You mentioned you had to restart Lisp, obviously a bad
>>thing, but not my case so I am wondering ...well, I'll keep reading.
> 
> 
> So what happens is, I get an error, like this:
> New as of Cells3: parent must be supplied to make-instance of SYMBOL kid ME
>    [Condition of type SIMPLE-ERROR]
> 
> Restarts:
>  0: [ABORT] Return to SLIME's top level.
>  1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {B183A51}>)
> 
> --> so all I can do is ABORT.  (SBCL is not so generous with the restarts)
> 
> Then I drop to the repl, and do a cells-reset, which releases the
> stop.  Then sooner or later I run into something like:
> 
> Current DP 1 not GE pulse 4194 of cell (#1=(#2=BN344)
>                                         . <vld>)<4194:A
> PARENT-NODES/#2#BN345 = #1#>
>    [Condition of type SIMPLE-ERROR]
> 
> Restarts:
>  0: [CONTINUE] Retry assertion.
>  1: [ABORT] Return to SLIME's top level.
>  2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {B183A51}>)
> 
> CONTINUE won't help (the assertion obviously keeps failing), and if I
> ABORT and go to the repl, I keep getting similar errors whenever I do
> something cellsy.
> 
> At this point I usually restart the lisp process to clear things up --
> which is ugly and annoying ;-)
> 

...snip...

> 
>>Or is GTk still talking to the old Lisp model via callbacks? Or... <g>
> 
> 
> This could indeed be true.  Generally the old application is still
> hanging around after a failure (frozen while i'm at the repl) and
> comes back to live when i run a new instance.  Then of course there is
> this zombie window out there talking to gtk ... that might be an
> issue.

I can kinda guarantee that old state is still in play. There is nothing 
fancy going on with these DPs. If you were off by one and only after a 
backtrace I would think /maybe/ there was some interaction, but that 
just sounds like old state. btw, I only see this if I run and forget to 
take down the prior window (perhaps with the backtrace still active, but 
either way). The prior window gets events (Tcl sees nothing of the 
backtrace) and goes to work but the single global DP has been reset.

To confirm, if like me you have a root instance, you might give it a 
gensym as the md-name and then, when you backtrace compare (md-name (u^ 
<root-class>)) with the name of the root most recently created.

Hopefully that confirms the problem and then you really know on what you 
are working, always helps.

> 
> Maybe after all what i need to do is play with handlers and unwind
> protects in cells-gtk to get it to clean up in case of an error.

That might work. This glue business (to other worlds) always gets tricky 
at the edges.

You might consider extending cells-gtk-reset (if there be such a thing, 
if not make one) to look around for the Undead and clean up at that 
point, if automatic cleanup will make debugging hard.

kt