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?