cells-devel May 2008

cells-devel@common-lisp.net

6 participants
13 discussions

[cells-devel] Cells: make-kid bypasses dependencies on kids of parent ?!
by Frank Goenninger 25 May '08

25 May '08

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

3 5

[cells-devel] dependancy problem (I think)
by Andy Chambers 24 May '08

24 May '08

(defmd page (html) (xdefs (c? (fm-collect-if self (lambda (k) (not (eq (find-class 'text) (class-of k)))))))) (xhtml (c? (with-output-to-string (s) (with-html-output (s nil :prologue t :indent t) (:html (:head (:title (str (^title))) (:script :type "text/javascript" :src "/js/jquery.js") (:script :type "text/javascript" :src "/js/openair.js") (:script :type "text/javascript" (format t "defs = { ~{~a~} }; " (loop for def in (^xdefs) collect (format t "~s: ~s" (md-name def) (xhtml def))))) (:style :type "text/css" :href (^style))) (:body (:div :id "banner" (:h1 (str (^title)))) (:div :id "content" (str (apply #'concatenate 'string (loop for k in (^kids) collecting (without-c-dependency (xhtml k))))))))))))) Adding the xdefs rule above makes cells ask me to "see listener for cell rule cycle diagnostics". What does this mean? Is there another way of writing this rule to avoid this? I get the same error if I wrap the rule in a without-c-dependancy but I'm not sure what this means anyway. Cheers, Andy -- ---- Andy Chambers Formedix Ltd

1 0

[cells-devel] Added an eval-now! to defmodel to suppress SBCL warnings
by Peter Hildebrandt 21 May '08

21 May '08

SBCL kept bugging me with style-warnings when compiling defmd/defmodels for the first time. Wrapping the defclass part of defmodel in an eval-now! fixes it nicely: ; ------- defclass --------------- (^slot-value ,model ',',slotname) (eval-now! ;; suppress style warning in SBCL, ph (prog1 (defclass ,class ,(or directsupers '(model-object)) ;; now we can def the class I committed that to CVS today. Lemme know whether anything breaks. Peter

3 3

[cells-devel] How does cells deal with in-place modification of slot values?
by Larry Clapp 20 May '08

20 May '08

See subject. In other words, say I have a class with two slots, a and b, with b sort-of dependant on a: (defmodel test () ((a :initarg :a :initform (c-in (list 'a)) :accessor a) (b :initarg :b :initform (c? (car (^a))) :accessor b))) (defmethod print-object ((self test) stream) (print-unreadable-object (self stream :type t :identity t) (format stream "a: ~S, b: ~S" (^a) (^b)))) (setf *a* (make-instance 'test)) CELLS 11 > *a* #<TEST a: (A), b: A 22ED4D93> CELLS 12 > (setf (car (a *a*)) 'd) D CELLS 13 > *a* #<TEST a: (D), b: A 22ED4D93> Slots a and b are now out of sync. What's the ideo-cells-ic way to do this? What I'm really trying to do is wrap a class around somebody else's object. The internal state of the object changes, and I'd like to figure out some way to make the Cells system aware of the change. "Native" use of the object is something like this (some-other-package:perturb-test self) Do I need to wrap perturb-test too? e.g. (defmodel test () ((a :initarg :a :initform (c-in (list 'a)) :accessor a) (a-changed :initform (c-in 0) :accessor a-changed) (b :initarg :b :initform (c? (and (^a-changed) (car (^a)))) :accessor b))) (defmethod print-object ((self test) stream) (print-unreadable-object (self stream :type t :identity t) (format stream "a: ~S, b: ~S" (^a) (^b)))) (setf *a* (make-instance 'test)) (defun perturb-test (self y) (prog1 (setf (car (^a)) y) (incf (^a-changed)))) CELLS 34 > *a* #<TEST a: (D), b: D 200A742F> CELLS 35 > (perturb-test *a* 'e) E CELLS 36 > *a* #<TEST a: (E), b: E 200A742F> -- Larry

3 4

[cells-devel] Cells stats just posted to CLL under "I never did this before"
by Ken Tilton 19 May '08

19 May '08

Traversed a real world (look it up) Cells model (pretty much a control bar, two list boxes with a total of less than 20 items, then a display of sixteen algebra problems with <gasp> each algebraic node implemented by its own model (cells-powered class) instance) [such that 2+4 would be four clos instances counting a top-level container I use] culling stats: Surprisingly few instances: 438, and a little more than half of those to cover the math nodes. Hmm, just realized that might make this model unrepresentative -- or will any big, realistic model involve half the instances being from one small but vital subtree of the overall OO hierarchy? As predicted, the silver bullet: an average of 1-2 (I had guessed 2-3, but on reflection that sounds right) dependencies per ruled cell (the silver bullet being natural decomposition of what Brooks took to be ineluctable (his word was "intrinsic") complexity arising from exponentially climbing interdependence as kinds of states grew). Cells created: 7000 Ruled cells: 5800 Input cells: 1200, a shocker, but 1000 are kludges to avoid insane dependency on the mouse position that is trivial to handle imperatively (well, by an observer on the mouse position cell) and another hundred are similarly multitudes of OS-event hooks used so not everyone ends up sitting there waiting on (and processing) every click event. Ruled cells optimized away (no dependencies found): 2000 No surprise there, always had big savings from cell optimization. Intriguing histogram of length of dependency chain (ignore column one, my trace function does something with real time): time count length of dependency chain 18569 ... 1 ... (:DEP-DEPTH 39) 18570 ... 1 ... (:DEP-DEPTH 40) 18572 ... 2 ... (:DEP-DEPTH 36) 18575 ... 3 ... (:DEP-DEPTH 35) 18578 ... 3 ... (:DEP-DEPTH 41) 18586 ... 8 ... (:DEP-DEPTH 22) 18594 ... 8 ... (:DEP-DEPTH 25) 18602 ... 8 ... (:DEP-DEPTH 28) 18610 ... 8 ... (:DEP-DEPTH 31) 18618 ... 8 ... (:DEP-DEPTH 30) 18635 ... 17 ... (:DEP-DEPTH 34) 18655 ... 20 ... (:DEP-DEPTH 21) 18677 ... 22 ... (:DEP-DEPTH 18) 18699 ... 22 ... (:DEP-DEPTH 37) 18723 ... 24 ... (:DEP-DEPTH 33) 18751 ... 28 ... (:DEP-DEPTH 27) 18787 ... 36 ... (:DEP-DEPTH 24) 18843 ... 56 ... (:DEP-DEPTH 32) 18903 ... 60 ... (:DEP-DEPTH 17) 18964 ... 61 ... (:DEP-DEPTH 15) 19029 ... 65 ... (:DEP-DEPTH 38) 19094 ... 65 ... (:DEP-DEPTH 12) 19172 ... 78 ... (:DEP-DEPTH 19) 19251 ... 79 ... (:DEP-DEPTH 9) 19331 ... 80 ... (:DEP-DEPTH 14) 19413 ... 82 ... (:DEP-DEPTH 20) 19501 ... 88 ... (:DEP-DEPTH 23) 19591 ... 90 ... (:DEP-DEPTH 29) 19683 ... 92 ... (:DEP-DEPTH 26) 19811 ... 128 ... (:DEP-DEPTH 6) 19997 ... 186 ... (:DEP-DEPTH 11) 20214 ... 217 ... (:DEP-DEPTH 16) 20524 ... 310 ... (:DEP-DEPTH 8) 20921 ... 397 ... (:DEP-DEPTH 13) 21329 ... 408 ... (:DEP-DEPTH 5) 21936 ... 607 ... (:DEP-DEPTH 10) 22553 ... 617 ... (:DEP-DEPTH 4) 23295 ... 742 ... (:DEP-DEPTH 7) 24101 ... 806 ... (:DEP-DEPTH 3) 27277 ... 3176 ... (:DEP-DEPTH 2) I like the outliers at some of the depths, again probably because of the (unusual?) distribution of instance classes. Anyway... Maximum dependency chain is 41 which is kinda inconceivable to me (who was strangely too lazy to print the chain out-- well, I actually was gunshy because of a fascinating problem here: traversing the dependency graph "the other way" (from user to used) was computationally ridiculous! I had to do some memoizing! Yet going the other way (propagating from basically OS event forward to dependents) is crazy fast. Clearly a Message From God, just not sure what. Anyway...) I mean, yeah, it (the chain of 41) is GUI-geometry related and I guess comes from the position of some high-level container being dependent (eventually) on the font metrics of the denominator of the fraction in the product in the sum on the right side of the equation... Buddha covered this, the universe being one vast web of cause and effect amongst universally interconnected stuff -- anyway, looks like some simple lockdowns could reduce that a lot, but the app is pretty snappy as is. Calling up the sixteen problems (going from a list item not implemented so it shows zero problems) shows that cost in isolation (timing columen deleted this time): 308 ... (:MD-AWAKEN) Those are new model instances coming to life, mostly math 2321 ... (:C-AWAKEN) Cells needed by those instances to mediate their slots. Again, probably 900 low-functionality input cells as an optimization trick. 5927 ... (:MD-INSTALL-CELL) Hang on, that is the real cell count. Oh, OK. the count :c-awaken gets hit during md-awaken only if a scan of the slots of a new instance finds a nascent cell. Cells can be awakened JIT if some other new cell asks for them and this happens roughly 3606/5927th of the time. 665 ... (:C-OPTIMIZED) Take away the input cells (they cannot be optimized away) and we are looking at 40% optimization of ruled Cells into fixed values. 3911 ... (:CPROPAGATE) 16148 ... (:ENSURE-VALUE-IS-CURRENT) That be the dataflow. Lots of ensure current, but you wanted data integrity, right? kt

1 0

[cells-devel] Re: [cells-gtk-devel] cells-gtk3 without libcellsgtk / threads
by Peter Hildebrandt 19 May '08

19 May '08

Ingo, thanks again for the patch. I it is now in CVS. > 1. If libcellsgtk is not used (gtk-init...) never seems to be called. Yep, stupid typo of mine. Sorry about that. > 2. Also if used in a single threading environment (like clisp) > (g-thread-init...) and (gdk-threads-init) do get called which > results in an error. Hmm, I never changed that, I think. They were always called in cells-gtk if IIRC. However, if it does no harm to leave them out, then that seems the right thing to do. Are you on windows or linux? I'm just guessing, but it might be the case that it is a GTK issue and not a cells-gtk issue whether to call them: On linux GTK supports threads, so it might be necessary to call those (even if you don't use threads yourself). On windows it doesn't, so maybe you can't call them. In this case, we should condition on :unix vs. :windows. But again, I'm just guessing. If you're on linux, then forget everything I said. As to the call-next-method thing, the background is this: Cells uses progn method combination for observers, which is not available on clisp (or at least, used to not be available on clisp). Therefore cells needed to imitate it by using standard method combination and (call-next-method) in every method. You see a lot of these calls in cells-gtk: fritz@babyfoot:~/cells-gtk3/cells-gtk$ grep clisp *.lisp actions.lisp: #+clisp (call-next-method)) buttons.lisp: #+clisp (call-next-method)) buttons.lisp: #+clisp (call-next-method)) ... However, I see that cells3 only uses this imitation on corman lisp now: fritz@babyfoot:~/lisp/cells3.cvs$ grep progn cells.lisp (:method-combination progn)) (defmethod slot-value-observe #-(or cormanlisp) progn So maybe this means that clisp now supports progn method combination, which the error message suggests: #<STANDARD-GENERIC-FUNCTION SLOT-VALUE-OBSERVE>: CALL-NEXT-METHOD is invalid within PROGN methods Than it would be time to remove all those calls to call-next-method from cells-gtk. I'd suggest you just go ahead and deactivate all those calls (e.g by conditioning on :no-progn-combination instead of :clisp), which should remove those warnings. Cheers, Peter

1 0

Re: [cells-devel] Current DP ... not GE pulse ... of cell ...?
by Ken Tilton 15 May '08

15 May '08

[ccing cells-devel because usefully on topic] Peter Hildebrandt wrote: >> Me, too. The question is why can't you just abort the backtrace, fix the >>mistake, and re-run. You mentioned you had to restart Lisp, obviously a bad >>thing, but not my case so I am wondering ...well, I'll keep reading. > > > So what happens is, I get an error, like this: > New as of Cells3: parent must be supplied to make-instance of SYMBOL kid ME > [Condition of type SIMPLE-ERROR] > > Restarts: > 0: [ABORT] Return to SLIME's top level. > 1: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {B183A51}>) > > --> so all I can do is ABORT. (SBCL is not so generous with the restarts) > > Then I drop to the repl, and do a cells-reset, which releases the > stop. Then sooner or later I run into something like: > > Current DP 1 not GE pulse 4194 of cell (#1=(#2=BN344) > . <vld>)<4194:A > PARENT-NODES/#2#BN345 = #1#> > [Condition of type SIMPLE-ERROR] > > Restarts: > 0: [CONTINUE] Retry assertion. > 1: [ABORT] Return to SLIME's top level. > 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {B183A51}>) > > CONTINUE won't help (the assertion obviously keeps failing), and if I > ABORT and go to the repl, I keep getting similar errors whenever I do > something cellsy. > > At this point I usually restart the lisp process to clear things up -- > which is ugly and annoying ;-) > ...snip... > >>Or is GTk still talking to the old Lisp model via callbacks? Or... <g> > > > This could indeed be true. Generally the old application is still > hanging around after a failure (frozen while i'm at the repl) and > comes back to live when i run a new instance. Then of course there is > this zombie window out there talking to gtk ... that might be an > issue. I can kinda guarantee that old state is still in play. There is nothing fancy going on with these DPs. If you were off by one and only after a backtrace I would think /maybe/ there was some interaction, but that just sounds like old state. btw, I only see this if I run and forget to take down the prior window (perhaps with the backtrace still active, but either way). The prior window gets events (Tcl sees nothing of the backtrace) and goes to work but the single global DP has been reset. To confirm, if like me you have a root instance, you might give it a gensym as the md-name and then, when you backtrace compare (md-name (u^ <root-class>)) with the name of the root most recently created. Hopefully that confirms the problem and then you really know on what you are working, always helps. > > Maybe after all what i need to do is play with handlers and unwind > protects in cells-gtk to get it to clean up in case of an error. That might work. This glue business (to other worlds) always gets tricky at the edges. You might consider extending cells-gtk-reset (if there be such a thing, if not make one) to look around for the Undead and clean up at that point, if automatic cleanup will make debugging hard. kt

1 0

Re: [cells-devel] Current DP ... not GE pulse ... of cell ...?
by Peter Hildebrandt 15 May '08

15 May '08

On 5/15/08, Ken Tilton <kennytilton(a)optonline.net> wrote: > Ken Tilton wrote: > > > > For me it is just abort/fix/rerun. > > Me too -- unless cells gets into this Current DP is not GE pulse business -- then I can't figure out how to fix that. Peter > I meant "with Celtk". > > kt > >

1 0

[cells-devel] Current DP ... not GE pulse ... of cell ...?
by Peter Hildebrandt 15 May '08

15 May '08

Every now and then I do something silly (like setf'ing a cell w/o initializing it as c-in, and I run into a cells-stop. What is the correct way to recover from this? I used to do a (cells-reset), but all too often the next cells operation runs into something like that: Current DP 28 not GE pulse 1160 of cell ... and somehow I don't get anything done until I restart lisp. So, what is the right way to deal with this? Thanks, Peter PS. The cells-store is working fine in my app, getting close to be ready for general use. I committed a store-items to cells-store.lisp recently. And one day I will rewrite it using proper cells wiring and not my own dirty little glue :)

2 2

[cells-devel] Cells cvs does not compile out of the box on Lispworks for Linux 5.1
by Larry Clapp 11 May '08

11 May '08

Cells cvs does not compile out of the box on Lispworks for Linux 5.1. Is it supposed to? Problems include the lack of the excl and ide.base packages. Thanks for your help. -- Larry Clapp

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

cells-devel May 2008