[cells-devel] assertion failure in c-pulse-update (CVS latest)

[Jack Unrue]

On 9/13/06, Ken Tilton <kentilton at gmail.com> wrote:
>
> On 9/12/06, Jack Unrue <jdunrue at 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):
>
>  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.)

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:
>
> 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"

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