[cells-devel] Cells debugging

Ken Tilton kennytilton at optonline.net
Fri Apr 4 15:18:29 UTC 2008


Another thought and generally useful Cells debugging tips...

Andy Chambers wrote:
> Here's a quick question.  If you want to make the kids of a mk-stack
> dependant on some other field in celtk,
> do you have to explicitly (make-instance 'stack :kids (c? ...) or
> should you still be able to use (mk-stack () ...)


If something is not changing even though I wrote a rule for it, the 
first thing I might do is add a print statement inside the rule itself 
to (a) make sure it runs at least once and then (b) to see if it is 
running even though I thought it was not. Two different investigations 
might get spawned there.

If a rule runs once and does not run again I inspect the instance that 
owns the slot and look to see if the cell struct is in the .cells slot 
or the .cells-flushed slot. If it is in the latter it means that the 
rule did not read any other slot that met all these requirements:

1. it is a cell slot (the default, overridden by saying :cell nil)
2. the slot of the instance read was mediated by a cell which...
3. ...itself had not been flushed.

If a rule does not read any such slot it will never get run again so 
Cells pulls it out of action (but keeps it in the flushed list for 
debugging).

btw, if you inspect a ruled cell you will discover that the code for the 
cell gets captured in a slot of the cell struct, again for debugging 
purposes. You can also inspect the slots for callers and useds (silly 
name, I know, I do that sometimes).

If all is well you should see a cell for the slot .kids in the .cells 
list. That alone tells you it depends on /something/ and is still in the 
game. My next question would be to look at the captured code for the 
rule, and also look to see if the expected used other cell is in the 
useds list.

Other investigations flow from that. If I am flushed, why are the slots 
I used not Cells or why did they get flushed. If I am not flushed and I 
have the right dependencies, why aren't they talking to me? Are /they/ 
changing? Debug observers on input cells can confirm they are changing.

btw, I just thought of something going in the other direction that would 
make things /overactive/: I guess you will be handing a lot of strings, 
and the default "unchanged" test is EQL. You might want to specify:

    :unchanged-if 'string=

...or something.

More as I thnk of it.

kt





More information about the cells-devel mailing list