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