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 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. So, what is the right way to deal with this?
Thanks, Peter
PS. The cells-store is working fine in my app, getting close to be ready for general use. I committed a store-items to cells-store.lisp recently. And one day I will rewrite it using proper cells wiring and not my own dirty little glue :)
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
Ken,
thanks for the quick response.
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.
Maybe that'd help, maybe we could have a debug mode in which such stuff only triggers big and ugly warnings, but goes through. I tend to do silly things frequently.
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.
I'm not quite sure whether I'm following you. The question is (for me) *why* do we need to stop everything? Maybe I'm missing the obvious, but couldn't cells just keep on working as if nothing happened, and keep processing GUI events?
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.
Hm, so you're saying that the state is so messed up after a cells stop that I won't do any good to work on?
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?
Not quite sure whether this is related. What do you mean by lock up? It does not return to the repl? I might have fixed that a while ago, definitely in cells-gtk3. Or you cannot open another window from the same lisp instance? Or what is going on?
For me what happens is:
- I do something in my GUI app - this triggers an illegal cells operation (usually a setf) - i get to the debugger - i drop to the repl - i do (cells-reset) - i fix some stuff - i restart my app ---> Boom, DP error shows up
... so how do I tell cells to discard all state and start from scratch then?
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.
Well, I think I *can* do this with GTK -- I just can't figure out how to tell cells to let me rerun.
Peter
-
Ken Tilton -
Peter Hildebrandt