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 ?
Thx for feedback!
Best, Frank
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))
kt
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
(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 ...
???
Thx!
frgo
Was a lisp image problem ... Had to restart my lisp session. Now things are working. It wasn't a cells problem ...
Note: I changed the loop stuff into a simple (c? (length (^kids))) because I have to count everythÃng in there. Now a task can have a task instance as a kid.
hmm - that makes a task tree or, in other words, a /program/ ! <g> Cells is just beautiful. I even don't have to see what part of the "program" has to be re-executed because the "program" or any content (= variables) have been changed...
Frank
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
I dealt with something slightly related recently and simply wrote an md-awaken :after method containing
(bwhen (p (^fm-parent)) (with-integrity (:change :add-to-parent) (push self (kids p))))
Worked like a charm :-)
Peter
On Sat, May 24, 2008 at 7:00 PM, Ken Tilton kennytilton@optonline.net wrote:
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 _______________________________________________ cells-devel site list cells-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/cells-devel
-
Frank Goenninger -
Ken Tilton -
Peter Hildebrandt