[cells-devel] Cells: make-kid bypasses dependencies on kids of parent ?!

[Ken Tilton]

Frank Goenninger wrote:
> 
> Am 24.05.2008 um 18:08 schrieb Ken Tilton:
> 
>> Frank Goenninger wrote:
>>
>>> I have the following definition:
>>> ;; A task is a container for ops. A task holds its ops as kids.  So,  
>>> when a
>>> ;;; task is called the task will call its kids.
>>> (defmd task (family)
>>>  (.md-name :accessor id :initarg :id)
>>>  fn-code
>>>  thread
>>>  state
>>>  nr-ops
>>>  :id (c-in (gensym "GNC.APP.TASK-"))
>>>  :fn-code (c-in nil)
>>>  :thread (c-in nil)
>>>  :state (c-in nil)
>>>  :nr-ops (c? (loop for kid in (^kids)
>>>                   counting (eql (type-of kid) 'op) into ops-count
>>>                   finally (return ops-count))))
>>> Now, when I do
>>> > (setq self (make-instance 'task))
>>> TASK1
>>> > (setq my-kid (make-kid 'task))
>>> TASK 2
>>> > (^nr-ops)
>>> 0
>>> ... and this should now be 1, no ? Or what's the right way to add  
>>> kids ?
>>
>>
>> Add them? :) make-kid does not add to the kids of self.
>>
>> (push (make-kid...) (kids self))
> 
> 
> Nope. I knew make-kid doesn't add kids but

But your original report does not show you adding the instance to kids, 
so where you conclude nr-ops should be one I do not see why. Anyway...

> 
> (fm-kid-add self my-kid)
> 
> *does* add the kid. Still no luck. So I change the rule for nr-ops to
> 
>   :nr-ops (c? (loop for kid in (^kids)
>                    counting kid into ops-count
>                    do
>                    (trc "Counting kids" kid ops-count)
>                    finally (return ops-count)))
> 
> ... and I don't get any trace output ...

Is the new kids in the kids slot? Are you occasionally backtracing and 
not doing a cells-reset? ie, is *stop* t?

kt