[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