[cells-devel] the cells way

[Kenny Tilton]

Andy Chambers wrote:
> Hey,
> 
> In openair, I'm getting problems with dead instances.  I think its
> maybe because I'm working against cells.

Maybe, maybe not. I get this all the time, and although many times I can 
find a way to re-express my problem to avoid dead instances I would love 
to make this easier. Naturally and sensibly written code leads to dead 
instances, and we want that kind of code to Just Work, not make the 
programmer stop and scratch their head for an hour working around it. 
But for now....

> 
> What I need to do is keep track somewhere of all the nodes that change
> in response to a request.  Currently, this is done using an "update"
> slot which we setf on an xhtml observer.
> 
> (defobserver xhtml ((self html))
>   (when (and new-value
> 	     (do-send self new-value old-value))
>     (trc "new xhtml" new-value)
>       (setf (update self)
> 	    (format nil "$(\"#~a\").replaceWith(\"~a\")" (md-name self)
> 		    (js-escape new-value)))))
> 
> When a new request comes in, we do the following:
> 
>   - walk the family tree, setting the update slot to nil.
>   - feed the request parameters into the model
>   - walk the family tree looking for places where update is not nil
> and sending it to the browser
> 
> In some cases, that works fine but in others, we find dead cells while
> walking the tree the first time.

(1) Do you mean dead instances or dead Cells?
(2) If instances, and if the tree is a cells-mediated tree, ie 
family/.kids, it is not clear to me how dead children instances would be 
encountered.

What I see a lot is that I have a blinking edit caret watching the 
application focus and then the student quits a quiz and returns to the 
quiz menu. If I do not have code all over the map clearing the 
application focus the edit caret (a global thing, perhaps my real 
problem) ends up looking at a dead instance on the next blink. But that 
is because the application focus is an input Cell setf'ed by application 
code (setf being the root of all evil).

It is not always easy, but have you ever spent an hour trying to figure 
out how this actually happens? Exactly why does the traversal lead to a 
dead instance? Was someone keeping a reference to someone else instead 
of going thru channels (an fm-find)?

Another possibility may have to do with stuff forever coming and going 
as rules re-run and create all new instances even when just a small bit 
of the graph actually needs adding or removing. That /should/ work, but 
if you are keeping references to nodes such churning will break your 
code faster. Here again, tho, the problem would be keeping long-lived 
references vs. always going and looking for stuff such that only current 
instances get encountered.

To summarize, it /is/ a problem in general but I would like to know 
exactly how you hit these dead instances because it will change what I 
recommend.

FYI, one thing I am having luck with is a heavy hammer: md-slot-value 
not returning any value it sees is an MDEAD (sorry, that was just a 
debugging function at first, should be md-dead? or md-deadp) instance 
and returning nil when asked for any slot of an MDEAD instance. But that 
of course wll not always work, so let's not consider these until we 
understand exactly how deads are bein hit.


> 
> Another point to note is that the update slot is specified as :cell
> nil.  Based on its purpose and usage, does that make sense?

Yes.

> 
> Should I be wrapping this traversal in with-integrity or something?
> 

Hmmm. Hang on. Digression: Are you using lazy cells? Sorry, I forgot the 
details. If so, just traversing the tree and reading lazy cells will 
trigger Cells stuff and observers etc etc. Anyway, no, a toplevel model 
perturbation gets silently wrapped in with-integrity. It is necessary 
(as I say, even a read can kick off change) but I managed to hide that 
from the developer. Same goal: Cells should be as easy to live with as 
they are functionally powerful, or we are just replacing one hassle with 
another.

kt