Peter Hildebrandt wrote:
Every now and then I do something silly (like setf'ing a cell w/o initializing it as c-in, and I run into a cells-stop.
What is the correct way to recover from this?
I have not put any thought into recovery. We could certainly do something primitive like simply not make such a big fuss over the error, either allowing the setf with a big noisy warning about "don't think you just triggered some dataflow", or /not/ allowing the setf (and warning to that effect) but not do the *stop* thing. I guess you could also do (setf cells::*stop* nil) and see what happens.
That *stop* stuff is the only way to stop Lisp applications being fed events by a GUI library, and I went thru this twice with two different OSes/window managers so it's a solid problem... hmmm, I have never messed with fancy restarts, but that is a possibility.
One problem is that we set *stop* precisely to stop Cells machinery from running, so a lot of things happen that do not get handled. Just clearing the *stop* does not get those things handled. But it sounds like you have a case where you have a long-enough running process that you cannot just restart /and/ you feel you could just carry on... well, maybe the above has you reconsidering.
I used to do a (cells-reset), but all too often the next cells operation runs into something like that:
Current DP 28 not GE pulse 1160 of cell
... and somehow I don't get anything done until I restart lisp.
Ah, you have to restart the Lisp? Is this because of what I see on the Windows side: if I close my Gtk window I lock up my Lisp?
For me it is just abort/fix/rerun. If /that/ is the problem, to tell you the truth I would not rest until I could get Gtk to come down without taking my Lisp with it. It ain't just Lisp if it isn't interactive (by which I mean I should be able to run, crash, and start over at will.
ie, The Real Problem may be this Gtk vs Lisp thing.
Lemme know.
kt