I've upgraded to the latest CVS version of Cells and have encountered the following assertion failure:
*** - (>= CELLS::*DATA-PULSE-ID* (CELLS::C-PULSE CELLS::C)) must evaluate to a non-NIL value.
which had not occurred previously (I can't say what version, but I would say more than a couple months ago). I believe the key is that I'm calling cells:cells-reset and then attempting to invoke an accessor on a model object that existed prior to the cells-reset call. This used to work OK, but perhaps I've been getting away with something I shouldn't have been?
Here's the relevant part of the stack trace (this is CLISP 2.39 btw):
<13> #<COMPILED-FUNCTION SYSTEM::SIMPLE-ASSERT-FAILED> <14> #<COMPILED-FUNCTION CELLS::C-PULSE-UPDATE> <15> #<COMPILED-FUNCTION CELLS::ENSURE-VALUE-IS-CURRENT> <16> #<COMPILED-FUNCTION CELLS::MD-SLOT-VALUE-7> frame binding variables (~ = dynamically): | ~ CELLS::*DEFER-CHANGES* <--> NIL frame binding variables (~ = dynamically): | ~ CELLS::*UNFINISHED-BUSINESS* <--> NIL frame binding variables (~ = dynamically): | ~ CELLS::*WITHIN-INTEGRITY* <--> NIL <17> #<COMPILED-FUNCTION CELLS::CALL-WITH-INTEGRITY> <18> #<COMPILED-FUNCTION CELLS::MD-SLOT-VALUE> <19> #<COMPILED-FUNCTION #:|68 86 (CELLS:DEFMODEL FSM-MODEL NIL ...)-9-4-4-1-1-1 |> <20> #<STANDARD-GENERIC-FUNCTION JDUSOFT.MUSIC-TRAINER::CURRENT-STATE> <21> #<COMPILED-FUNCTION JDUSOFT.MUSIC-TRAINER::SUBMIT-EVENT>
SUBMIT-EVENT is a function in my code, and the first thing it does is call CURRENT-STATE which is an accessor for a rule slot. There is also an observer declared for this same slot.
Any ideas? Am I right about the continued use of a model object after cells-reset being the culprit?
On 9/12/06, Jack Unrue jdunrue@gmail.com wrote:
I've upgraded to the latest CVS version of Cells and have encountered the following assertion failure:
*** - (>= CELLS::*DATA-PULSE-ID* (CELLS::C-PULSE CELLS::C)) must evaluate to a non-NIL value.
which had not occurred previously (I can't say what version, but I would say more than a couple months ago). I believe the key is that I'm calling cells:cells-reset and then attempting to invoke an accessor on a model object that existed prior to the cells-reset call. This used to work OK, but perhaps I've been getting away with something I shouldn't have been?
I think the deal is this (you are right):
1. Cells-reset has always reset the vital *data-pulse-id* to 0 2. Old model object cells still in use when cells-reset was invoked thus have always had DPs (datapulses) greater than *data-pulse-id*, obviously benignly so in your application. 3. I have an insanely high degree of confidence that the assertion above was inserted in the past month after I debugged a tough problem in which an object DP got moved backwards. (This had to do with another new mechanism,integrity bubbles, which I happen to plan to back out.)
So...you can:
1. chop the assertion 2. suggest a new cells-reset-a-little, or a cells-reset parameter which says "I want to reset this but not that"
Re the latter, i admit Cells are a little un-Lispy in that I have not worked much on restarts. But the function cells-reset is meant to truly reset the cells mechanism, so as you surmised I am surprised you got away with it at all. I almost think then that, in your testing, you might want to simply arrange things so that cells-reset does not get called unless you are truly reinitializing your own application -- that is the spirit of cells-reset.*
kt
* uh-oh, now I am in a panick over someday doing persistent cells again. :) look for datapulse-id to become:
(+ (* 10000 (get-internal-real-time) (incf "oldskool-dp*))
Where *oldskool-dp* gets zeroed when g-i-r-t changes.
kt
On 9/13/06, Ken Tilton kentilton@gmail.com wrote:
Re the latter, i admit Cells are a little un-Lispy in that I have not worked much on restarts. But the function cells-reset is meant to truly reset the cells mechanism, so as you surmised I am surprised you got away with it at all.
I take it back. Assuming you did not backtrace and cause the global *stop* to get set, re-running cells-reset and moving the DP back to zero would (absent the new assertion, of course) merely cause some cells to re-run their rules unnecessarily one time (and then recompute the same value anyway). No big deal at all.
kt
On 9/13/06, Ken Tilton kentilton@gmail.com wrote:
On 9/12/06, Jack Unrue jdunrue@gmail.com wrote:
*** - (>= CELLS::*DATA-PULSE-ID* (CELLS::C-PULSE CELLS::C)) must evaluate
to a
non-NIL value.[snip]
I think the deal is this (you are right):
- Cells-reset has always reset the vital *data-pulse-id* to 0
- Old model object cells still in use when cells-reset was invoked thus
have always had DPs (datapulses) greater than *data-pulse-id*, obviously benignly so in your application. 3. I have an insanely high degree of confidence that the assertion above was inserted in the past month after I debugged a tough problem in which an object DP got moved backwards. (This had to do with another new mechanism,integrity bubbles, which I happen to plan to back out.)
OK thanks for explaining. Just to elaborate, my app basically runs through a series of brass instrument fingering exercises. For each one, the user presses key combinations representing what they think is the correct fingering in response to the current clef, key signature, and note.
During each test run, the student can interrupt the test and start over. So there are two models, one of which holds the current test run's state (and hence is what needs to be cleared/reset); the other is a FSM that processes key events to translate them into instrument fingerings, and this model conceptually doesn't need to be reset.
So...you can:
- chop the assertion
- suggest a new cells-reset-a-little, or a cells-reset parameter which says
"I want to reset this but not that"
I'm happy to change my app to conform. I don't think my scenario warrants changing Cells, because I don't think I have a strong enough use-case for (2) and you didn't put the assertion in there for the fun of it :-)
Re the latter, i admit Cells are a little un-Lispy in that I have not worked much on restarts. But the function cells-reset is meant to truly reset the cells mechanism, so as you surmised I am surprised you got away with it at all. I almost think then that, in your testing, you might want to simply arrange things so that cells-reset does not get called unless you are truly reinitializing your own application -- that is the spirit of cells-reset.*
Understood. Thanks again, Kenny!
-
Jack Unrue -
Ken Tilton