From marcoxa at cs.nyu.edu Tue May 6 13:22:49 2008 From: marcoxa at cs.nyu.edu (Marco Antoniotti) Date: Tue, 6 May 2008 15:22:49 +0200 Subject: [cells-devel] test: please ignore Message-ID: ... told ya! -- Marco Antoniotti From kennytilton at optonline.net Wed May 7 06:25:06 2008 From: kennytilton at optonline.net (Ken Tilton) Date: Wed, 07 May 2008 02:25:06 -0400 Subject: [cells-devel] Not a test -- don't ignore (Hi, Marco!) Message-ID: <48214B42.3070007@optonline.net> I just added a simplistic new namespace mechanism to Cells that probably will need refinement, but will certainly work for its simplistic design goals: If your sougth (formerly by fm-other) stuff will Just Be There during a datapulse, and be named uniquely and absolutely (no path relative stuff where two things have the same name but are differentiated by being nearer (in some sense) to the seeker) then you can just look them up by name. This arose because I got into a cycle seeking X from Y. I quickly saw that Cells could trivially support "if this cycles return X (in this case nil works)" -- and tho I did not go for it for this time I expect Cells to go there soon -- but then next I saw the problem only arose because I had gotten lazy and structured things unusually such that a namespace search had gone so high..well, it's complicated, but I saw that unlazying my code would probably eliminate the cycle, but one Design Principle of Cells is "Hey, this is supposed to make programming easier, that does not happen if I have to sweat these things I would naturally code." and I have been regularly solving these things by unlazying my code but damnit Lisp is all about being lazy so I thought let's see if there is something still sensible that lets me keep my lazy structuring. And of course the bizarritude of fm-other and its ilk begged to be challenged, because they blindly sail all over the hierarchy looking for things and this invites cycles because rules determing the populations of models may well kick off these searches -- hello cycle! And that was what was happening here so if I could find things without blindly traversing the hierarchy life would be good. Peter Hildebrandt has been working on a more sophisticated alternative scheme to namespacing, but I am in Just Ship! mode and I saw that in my case I did not need cells-ish dependency -- X and Y came into existence during the same datapulse, so a simple registration at make-instance time would work fine, and that is what I did. I think searching the source on "register" will return the unsurprising details. kt From achambers.home at googlemail.com Thu May 8 22:07:40 2008 From: achambers.home at googlemail.com (Andy Chambers) Date: Thu, 8 May 2008 23:07:40 +0100 Subject: [cells-devel] openair project created Message-ID: Hi Everyone, The openair project has now been setup. Sign up to the mailing list here: http://common-lisp.net/mailman/listinfo/openair-devel The (sparse) project home page is here: http://common-lisp.net/project/openair/ -- Andy From kennytilton at optonline.net Thu May 8 22:24:18 2008 From: kennytilton at optonline.net (Ken Tilton) Date: Thu, 08 May 2008 18:24:18 -0400 Subject: [cells-devel] openair project created In-Reply-To: References: Message-ID: <48237D92.1030600@optonline.net> Awesome. I can't wait for "hello world" to stabilize so I can start playing again. I also see myself as a user once I get going on the Algebra application and its web page. Glad to see the tarball option as well on gitorious, not that the git commands were that onerous. One less thing to learn, tho. kt From larry at theclapp.org Sat May 10 21:23:39 2008 From: larry at theclapp.org (Larry Clapp) Date: Sat, 10 May 2008 17:23:39 -0400 Subject: [cells-devel] Cells cvs does not compile out of the box on Lispworks for Linux 5.1 Message-ID: <20080510212339.GA4705@santa.theclapp.org> 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 From kennytilton at optonline.net Sat May 10 21:29:20 2008 From: kennytilton at optonline.net (Ken Tilton) Date: Sat, 10 May 2008 17:29:20 -0400 Subject: [cells-devel] Cells cvs does not compile out of the box on Lispworks for Linux 5.1 In-Reply-To: <20080510212339.GA4705@santa.theclapp.org> References: <20080510212339.GA4705@santa.theclapp.org> Message-ID: <482613B0.2090403@optonline.net> Larry Clapp wrote: > 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. Try: (push :iamnotkenny *features*) I'll change that shortly. Anyway, anything like that that still falls out can safely be commented out. kt From larry at theclapp.org Sat May 10 22:13:19 2008 From: larry at theclapp.org (Larry Clapp) Date: Sat, 10 May 2008 18:13:19 -0400 Subject: [cells-devel] Cells cvs does not compile out of the box on Lispworks for Linux 5.1 In-Reply-To: <482613B0.2090403@optonline.net> References: <20080510212339.GA4705@santa.theclapp.org> <482613B0.2090403@optonline.net> Message-ID: <20080510221319.GB4705@santa.theclapp.org> On Sat, May 10, 2008 at 05:29:20PM -0400, Ken Tilton wrote: > Larry Clapp wrote: > >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. > > Try: > > (push :iamnotkenny *features*) Yes, that did it. Silly me. Thanks. -- L From kennytilton at optonline.net Sat May 10 22:22:52 2008 From: kennytilton at optonline.net (Ken Tilton) Date: Sat, 10 May 2008 18:22:52 -0400 Subject: [cells-devel] Cells cvs does not compile out of the box on Lispworks for Linux 5.1 In-Reply-To: <20080510221319.GB4705@santa.theclapp.org> References: <20080510212339.GA4705@santa.theclapp.org> <482613B0.2090403@optonline.net> <20080510221319.GB4705@santa.theclapp.org> Message-ID: <4826203C.2020007@optonline.net> Larry Clapp wrote: > On Sat, May 10, 2008 at 05:29:20PM -0400, Ken Tilton wrote: > >>Larry Clapp wrote: >> >>>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. >> >>Try: >> >> (push :iamnotkenny *features*) > > > Yes, that did it. Silly me. Thanks. > haha, well the silliness is obviously on my side, but that came up when I was trying to focus on my own work and not so much open source and things were quiet anyway, one or two users. I decided a compromise would be to still share improvements to Cells but leave other folks a little work. Now with Cells-Gtk ported to the latest version of Cells and OpenAIR potentially bringing in a lot more users I better clean that up. cheers, kt From larry at theclapp.org Sun May 11 01:24:22 2008 From: larry at theclapp.org (Larry Clapp) Date: Sat, 10 May 2008 21:24:22 -0400 Subject: [cells-devel] Cells cvs does not compile out of the box on Lispworks for Linux 5.1 In-Reply-To: <4826203C.2020007@optonline.net> References: <20080510212339.GA4705@santa.theclapp.org> <482613B0.2090403@optonline.net> <20080510221319.GB4705@santa.theclapp.org> <4826203C.2020007@optonline.net> Message-ID: <20080511012422.GC4705@santa.theclapp.org> On Sat, May 10, 2008 at 06:22:52PM -0400, Ken Tilton wrote: > Now with Cells-Gtk ported to the latest version of Cells and OpenAIR > potentially bringing in a lot more users I better clean that up. Well, while you're at it, some things you might want to clean up: - http://www.tilton-technology.com/cells_top.html still points to http://www.tilton-technology.com/01-Cell-basics.lisp and should probably point to http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/doc/01-Cell-basics.lisp?rev=1.6&root=cells&view=auto. - The project page at common-lisp.net ("The repository of all other Cells code (including Cello) ...") points to the repository at http://common-lisp.net/cgi-bin/viewcvs.cgi/cell-cultures/?cvsroot=cells, but should probably point to http://common-lisp.net/cgi-bin/viewcvs.cgi/?root=cells (but that doesn't include Cello, so maybe not). In any case, the link doesn't work. - The project page also says "In there you will find the Cells code itself here" and points to http://common-lisp.net/cgi-bin/viewcvs.cgi/cell-cultures/cells/?cvsroot=cells but should be http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/?root=cells. These were stumbling blocks in my Cells odyssey this evening. Thanks for your help. FWIW, I was not aware of the OpenAIR project, I just thought it was time I took a look at Cells. -- Larry From peter.hildebrandt at gmail.com Thu May 15 16:15:42 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Thu, 15 May 2008 18:15:42 +0200 Subject: [cells-devel] Current DP ... not GE pulse ... of cell ...? Message-ID: <7758b2680805150915i75c3aad3p77eba03e639da99c@mail.gmail.com> 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 :) From kennytilton at optonline.net Thu May 15 16:32:38 2008 From: kennytilton at optonline.net (Ken Tilton) Date: Thu, 15 May 2008 12:32:38 -0400 Subject: [cells-devel] Current DP ... not GE pulse ... of cell ...? In-Reply-To: <7758b2680805150915i75c3aad3p77eba03e639da99c@mail.gmail.com> References: <7758b2680805150915i75c3aad3p77eba03e639da99c@mail.gmail.com> Message-ID: <482C65A6.1020606@optonline.net> Peter Hildebrandt wrote: > 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 have not put any thought into recovery. We could certainly do something primitive like simply not make such a big fuss over the error, either allowing the setf with a big noisy warning about "don't think you just triggered some dataflow", or /not/ allowing the setf (and warning to that effect) but not do the *stop* thing. I guess you could also do (setf cells::*stop* nil) and see what happens. That *stop* stuff is the only way to stop Lisp applications being fed events by a GUI library, and I went thru this twice with two different OSes/window managers so it's a solid problem... hmmm, I have never messed with fancy restarts, but that is a possibility. One problem is that we set *stop* precisely to stop Cells machinery from running, so a lot of things happen that do not get handled. Just clearing the *stop* does not get those things handled. But it sounds like you have a case where you have a long-enough running process that you cannot just restart /and/ you feel you could just carry on... well, maybe the above has you reconsidering. > > 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. Ah, you have to restart the Lisp? Is this because of what I see on the Windows side: if I close my Gtk window I lock up my Lisp? For me it is just abort/fix/rerun. If /that/ is the problem, to tell you the truth I would not rest until I could get Gtk to come down without taking my Lisp with it. It ain't just Lisp if it isn't interactive (by which I mean I should be able to run, crash, and start over at will. ie, The Real Problem may be this Gtk vs Lisp thing. Lemme know. kt From peter.hildebrandt at gmail.com Thu May 15 16:46:29 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Thu, 15 May 2008 18:46:29 +0200 Subject: [cells-devel] Current DP ... not GE pulse ... of cell ...? In-Reply-To: <482C65A6.1020606@optonline.net> References: <7758b2680805150915i75c3aad3p77eba03e639da99c@mail.gmail.com> <482C65A6.1020606@optonline.net> Message-ID: <7758b2680805150946p56483c4dq4b47e425dc0cb7b7@mail.gmail.com> Ken, thanks for the quick response. > I have not put any thought into recovery. We could certainly do something > primitive like simply not make such a big fuss over the error, either > allowing the setf with a big noisy warning about "don't think you just > triggered some dataflow", or /not/ allowing the setf (and warning to that > effect) but not do the *stop* thing. I guess you could also do (setf > cells::*stop* nil) and see what happens. Maybe that'd help, maybe we could have a debug mode in which such stuff only triggers big and ugly warnings, but goes through. I tend to do silly things frequently. > That *stop* stuff is the only way to stop Lisp applications being fed > events by a GUI library, and I went thru this twice with two different > OSes/window managers so it's a solid problem... hmmm, I have never messed > with fancy restarts, but that is a possibility. I'm not quite sure whether I'm following you. The question is (for me) *why* do we need to stop everything? Maybe I'm missing the obvious, but couldn't cells just keep on working as if nothing happened, and keep processing GUI events? > One problem is that we set *stop* precisely to stop Cells machinery from > running, so a lot of things happen that do not get handled. Just clearing > the *stop* does not get those things handled. But it sounds like you have a > case where you have a long-enough running process that you cannot just > restart /and/ you feel you could just carry on... well, maybe the above has > you reconsidering. Hm, so you're saying that the state is so messed up after a cells stop that I won't do any good to work on? > > 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. > > > > Ah, you have to restart the Lisp? Is this because of what I see on the > Windows side: if I close my Gtk window I lock up my Lisp? Not quite sure whether this is related. What do you mean by lock up? It does not return to the repl? I might have fixed that a while ago, definitely in cells-gtk3. Or you cannot open another window from the same lisp instance? Or what is going on? For me what happens is: - I do something in my GUI app - this triggers an illegal cells operation (usually a setf) - i get to the debugger - i drop to the repl - i do (cells-reset) - i fix some stuff - i restart my app ---> Boom, DP error shows up ... so how do I tell cells to discard all state and start from scratch then? > For me it is just abort/fix/rerun. If /that/ is the problem, to tell you > the truth I would not rest until I could get Gtk to come down without taking > my Lisp with it. It ain't just Lisp if it isn't interactive (by which I mean > I should be able to run, crash, and start over at will. Well, I think I *can* do this with GTK -- I just can't figure out how to tell cells to let me rerun. Peter From peter.hildebrandt at gmail.com Thu May 15 16:48:21 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Thu, 15 May 2008 18:48:21 +0200 Subject: [cells-devel] Current DP ... not GE pulse ... of cell ...? In-Reply-To: <482C674A.6020600@optonline.net> References: <7758b2680805150915i75c3aad3p77eba03e639da99c@mail.gmail.com> <482C65A6.1020606@optonline.net> <482C674A.6020600@optonline.net> Message-ID: <7758b2680805150948u6246f22by2eff65383d2868d3@mail.gmail.com> On 5/15/08, Ken Tilton 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 > > From kennytilton at optonline.net Thu May 15 18:27:05 2008 From: kennytilton at optonline.net (Ken Tilton) Date: Thu, 15 May 2008 14:27:05 -0400 Subject: [cells-devel] Current DP ... not GE pulse ... of cell ...? In-Reply-To: <7758b2680805151109m33366ab9l6c678d778008494f@mail.gmail.com> References: <7758b2680805150915i75c3aad3p77eba03e639da99c@mail.gmail.com> <482C65A6.1020606@optonline.net> <7758b2680805150946p56483c4dq4b47e425dc0cb7b7@mail.gmail.com> <482C6E0E.8050104@optonline.net> <7758b2680805151109m33366ab9l6c678d778008494f@mail.gmail.com> Message-ID: <482C8079.3040401@optonline.net> [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 (#) > > --> 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) > . )<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 (#) > > 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... > > > 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^ )) 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 From larry at theclapp.org Sun May 18 20:17:52 2008 From: larry at theclapp.org (Larry Clapp) Date: Sun, 18 May 2008 16:17:52 -0400 Subject: [cells-devel] How does cells deal with in-place modification of slot values? Message-ID: <20080518201752.GF4210@santa.theclapp.org> 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* # CELLS 12 > (setf (car (a *a*)) 'd) D CELLS 13 > *a* # 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* # CELLS 35 > (perturb-test *a* 'e) E CELLS 36 > *a* # -- Larry From kennytilton at optonline.net Sun May 18 20:31:27 2008 From: kennytilton at optonline.net (Ken Tilton) Date: Sun, 18 May 2008 16:31:27 -0400 Subject: [cells-devel] How does cells deal with in-place modification of slot values? In-Reply-To: <20080518201752.GF4210@santa.theclapp.org> References: <20080518201752.GF4210@santa.theclapp.org> Message-ID: <4830921F.704@optonline.net> Larry Clapp wrote: > 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* > # > > CELLS 12 > (setf (car (a *a*)) 'd) > D > > CELLS 13 > *a* > # > > 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. Ah, now it is really tough. If it was my code accessing my internal structure I would Just Create the Glue to drive the Cells engine (eg. Peter Hildebrandt is playing with some glue to make hash tables Cellsy), but if some else is mutating an object /and not telling me/ I am stuck unless I can find some way to hook into that process. Cells is more about me making /my/ model work automatically and also does well working with external libs with callback schemes or something like Tcl/Tk does something similar linking state but also gives me a hook so I can propagate into Cells-land. But if you have an external library mutating state you care about but there is no way normally for you to know... well, what would you do anyway? Poll the state? If so, that is where I would put a hook to feed the Cells beast with dataflow. Beating a dead horse: When dealing with OS events, it gives me an event and that is it, it does not change that event afterwards in ways that would matter to me, for obvious reasons. hth, kenny > > "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* > # > > CELLS 35 > (perturb-test *a* 'e) > E > > CELLS 36 > *a* > # > > -- Larry > > _______________________________________________ > cells-devel site list > cells-devel at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-devel > From peter.hildebrandt at gmail.com Mon May 19 07:56:33 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Mon, 19 May 2008 09:56:33 +0200 Subject: [cells-devel] How does cells deal with in-place modification of slot values? In-Reply-To: <20080518201752.GF4210@santa.theclapp.org> References: <20080518201752.GF4210@santa.theclapp.org> Message-ID: <7758b2680805190056w7675a948r4c49a01317541863@mail.gmail.com> On Sun, May 18, 2008 at 10:17 PM, Larry Clapp wrote: > 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))) ... > (defun perturb-test (self y) > (prog1 > (setf (car (^a)) y) > (incf (^a-changed)))) Interesting side note: This is exactly how the cells-store (the cellsy hash table) works. If you can live with the hackish nature of it, it will probably work fine. If you have access to the way some-other-package is compiled, you could try and shadow car/cdr so that they trigger an appropriate update. Peter From peter.hildebrandt at gmail.com Mon May 19 10:59:33 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Mon, 19 May 2008 12:59:33 +0200 Subject: [cells-devel] Re: [cells-gtk-devel] cells-gtk3 without libcellsgtk / threads In-Reply-To: <1139838947@web.de> References: <1139838947@web.de> Message-ID: <7758b2680805190359v999a477pcf4e3f57f817cb06@mail.gmail.com> 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 at 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 at 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: #: 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 From kennytilton at optonline.net Mon May 19 11:25:56 2008 From: kennytilton at optonline.net (Ken Tilton) Date: Mon, 19 May 2008 07:25:56 -0400 Subject: [cells-devel] How does cells deal with in-place modification of slot values? In-Reply-To: <20080518201752.GF4210@santa.theclapp.org> References: <20080518201752.GF4210@santa.theclapp.org> Message-ID: <483163C4.6040105@optonline.net> Larry Clapp wrote: > 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* > # > > CELLS 12 > (setf (car (a *a*)) 'd) > D > > CELLS 13 > *a* > # > > 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)))) [Sorry, I did not even read this far last time because I thought I understood what you were asking.] If this last bit is an option, ie, if /I/ am the one setf-ing the car, then we do not have the case I feared of the foreign package mutating state behind my back, and in fact this problem arises even without a foreign object: I would have the same problem any time I was mutating state in a slot of even a vanilla Cells-powered class. So... It does not come up a lot, so I Just Do Not Go There -- I am careful to recons the list. This flies in the face of a Cells design imperative (no exposed wiring) but like I said, it does not come up much. Usually the kids slot of a GUI composite widget, where I really do not want to regenerate all the sub-widgets just to add/remove one. Then I map over the .cache (this usually being in a Cell rule for kids) making a new list but generally keeping the car of each cons copied. I think if it /did/ become a problem I would jazz up Cells with a cells-aware accessor (^elt? ^nth?) to read and write elements of a list/sequence, leaving elt and nth (and (setf car)) as backdoors. Not as transparent as shadowing CAR, but the self-documentation quality is a nice compensation for that, and shadowing CAR scares me performance-wise and in general. Even then I think there would be an inefficient (but ineluctable) dependency not on the car per se but on any change to the list. What if the case were CADDR instead of CAR? Now there are dependencies on two CDRs and one CAR, yes? Because if I, say, (rplacd X (cddr X)), then the result of (caddr X) is different and anyone accessing that cellsily will need to recalculate. Hmmm. I am reminded why I do not address these things until an application forces me to. :) kenny From kennytilton at optonline.net Mon May 19 12:45:59 2008 From: kennytilton at optonline.net (Ken Tilton) Date: Mon, 19 May 2008 08:45:59 -0400 Subject: [cells-devel] Cells stats just posted to CLL under "I never did this before" Message-ID: <48317687.9010009@optonline.net> 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 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 From larry at theclapp.org Tue May 20 13:30:29 2008 From: larry at theclapp.org (Larry Clapp) Date: Tue, 20 May 2008 09:30:29 -0400 Subject: [cells-devel] How does cells deal with in-place modification of slot values? In-Reply-To: <483163C4.6040105@optonline.net> References: <20080518201752.GF4210@santa.theclapp.org> <483163C4.6040105@optonline.net> Message-ID: <20080520133029.GN4210@santa.theclapp.org> On Mon, May 19, 2008 at 07:25:56AM -0400, Ken Tilton wrote: > It does not come up a lot, so I Just Do Not Go There -- I am careful to > recons the list. Okay, thanks, that works. -- L From peter.hildebrandt at gmail.com Wed May 21 10:50:38 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Wed, 21 May 2008 12:50:38 +0200 Subject: [cells-devel] Added an eval-now! to defmodel to suppress SBCL warnings Message-ID: <7758b2680805210350h184fb56cw3a936ade094fa738@mail.gmail.com> 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 From kennytilton at optonline.net Wed May 21 11:36:12 2008 From: kennytilton at optonline.net (Ken Tilton) Date: Wed, 21 May 2008 07:36:12 -0400 Subject: [cells-devel] Added an eval-now! to defmodel to suppress SBCL warnings In-Reply-To: <7758b2680805210350h184fb56cw3a936ade094fa738@mail.gmail.com> References: <7758b2680805210350h184fb56cw3a936ade094fa738@mail.gmail.com> Message-ID: <4834092C.9000707@optonline.net> Peter Hildebrandt wrote: > 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. Cool, I have been meaning to track that down, I get it, too, with ACL. I believe I reintroduced relativley recently when I casually switched to prog1 to get the class returned by defmodel, instead of using progn and then ending with find-class on the new class, just cuz prog1 seemed more elegant. Probably a better fix would be to refactor so any (^macros) (which is where I get my warnings, when they appear in rules supplied as defaults with the class definition) are defined first so they will be available: (progn (prog1 References: <7758b2680805210350h184fb56cw3a936ade094fa738@mail.gmail.com> <4834092C.9000707@optonline.net> Message-ID: <7758b2680805210443uc932773rfbca0ec6091b9653@mail.gmail.com> > Probably a better fix would be to refactor so any (^macros) (which is where > I get my warnings, when they appear in rules supplied as defaults with the > class definition) are defined first so they will be available: > > (progn (prog1 Another thing I want to do is change those (^macros) to be ^macros (symbol > macros expanding to the same thing) now that they are zero-argument macros Thought about that, too. But ... > Anyway, I have an app to write, this interim patch is fine. exactly :-) > ps. What /were/ the style warnings? k Real warnings, actually they were, one per slot plus one for the shared-initialize, telling me that there are methods specializing on an unknown class. I tend to take those seriously, because usually they point to a typo somewhere. So does SLIME by highlighting the defmd form in red everytime I compile for the first time. Now I get style warnings for redefining stuff (probably the eval-now! executes stuff twice), but it is much easier to ignore those than the real warnings about an undefined class. Peter From larry at theclapp.org Wed May 21 18:37:26 2008 From: larry at theclapp.org (Larry Clapp) Date: Wed, 21 May 2008 14:37:26 -0400 Subject: [cells-devel] Added an eval-now! to defmodel to suppress SBCL warnings In-Reply-To: <4834092C.9000707@optonline.net> References: <7758b2680805210350h184fb56cw3a936ade094fa738@mail.gmail.com> <4834092C.9000707@optonline.net> Message-ID: <20080521183726.GV4210@santa.theclapp.org> On Wed, May 21, 2008 at 07:36:12AM -0400, Ken Tilton wrote: > Another thing I want to do is change those (^macros) to be ^macros > (symbol macros expanding to the same thing) now that they are > zero-argument macros -- they once were much different beasts. My two cents on this: I like the ^accessor style, but don't always use "self", e.g. in a method with two objects of the same time. Any chance you could make the macro take an optional argument and use it instead of "self" if supplied? -- L From frgo at mac.com Sat May 24 15:45:02 2008 From: frgo at mac.com (Frank Goenninger) Date: Sat, 24 May 2008 17:45:02 +0200 Subject: [cells-devel] Cells: make-kid bypasses dependencies on kids of parent ?! Message-ID: <7408F023-D25A-458D-A837-22BB21AE65F7@mac.com> 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 From kennytilton at optonline.net Sat May 24 16:08:53 2008 From: kennytilton at optonline.net (Ken Tilton) Date: Sat, 24 May 2008 12:08:53 -0400 Subject: [cells-devel] Cells: make-kid bypasses dependencies on kids of parent ?! In-Reply-To: <7408F023-D25A-458D-A837-22BB21AE65F7@mac.com> References: <7408F023-D25A-458D-A837-22BB21AE65F7@mac.com> Message-ID: <48383D95.6020404@optonline.net> 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 From frgo at mac.com Sat May 24 16:18:30 2008 From: frgo at mac.com (Frank Goenninger) Date: Sat, 24 May 2008 18:18:30 +0200 Subject: [cells-devel] Cells: make-kid bypasses dependencies on kids of parent ?! In-Reply-To: <48383D95.6020404@optonline.net> References: <7408F023-D25A-458D-A837-22BB21AE65F7@mac.com> <48383D95.6020404@optonline.net> Message-ID: <308DB6F5-ACD6-4B5A-A51E-0B2B1A060C18@mac.com> 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 From frgo at mac.com Sat May 24 16:35:11 2008 From: frgo at mac.com (Frank Goenninger) Date: Sat, 24 May 2008 18:35:11 +0200 Subject: [cells-devel] Cells: make-kid bypasses dependencies on kids of parent ?! SOLVED! In-Reply-To: <308DB6F5-ACD6-4B5A-A51E-0B2B1A060C18@mac.com> References: <7408F023-D25A-458D-A837-22BB21AE65F7@mac.com> <48383D95.6020404@optonline.net> <308DB6F5-ACD6-4B5A-A51E-0B2B1A060C18@mac.com> Message-ID: <7F127121-0BF3-4C23-B9EC-986B1CB452E0@mac.com> 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/ ! 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 From kennytilton at optonline.net Sat May 24 17:00:54 2008 From: kennytilton at optonline.net (Ken Tilton) Date: Sat, 24 May 2008 13:00:54 -0400 Subject: [cells-devel] Cells: make-kid bypasses dependencies on kids of parent ?! In-Reply-To: <308DB6F5-ACD6-4B5A-A51E-0B2B1A060C18@mac.com> References: <7408F023-D25A-458D-A837-22BB21AE65F7@mac.com> <48383D95.6020404@optonline.net> <308DB6F5-ACD6-4B5A-A51E-0B2B1A060C18@mac.com> Message-ID: <483849C6.8010702@optonline.net> 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 From achambers.home at googlemail.com Sat May 24 22:08:23 2008 From: achambers.home at googlemail.com (Andy Chambers) Date: Sat, 24 May 2008 23:08:23 +0100 Subject: [cells-devel] dependancy problem (I think) Message-ID: (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 From peter.hildebrandt at gmail.com Sun May 25 10:36:19 2008 From: peter.hildebrandt at gmail.com (Peter Hildebrandt) Date: Sun, 25 May 2008 12:36:19 +0200 Subject: [cells-devel] Cells: make-kid bypasses dependencies on kids of parent ?! In-Reply-To: <483849C6.8010702@optonline.net> References: <7408F023-D25A-458D-A837-22BB21AE65F7@mac.com> <48383D95.6020404@optonline.net> <308DB6F5-ACD6-4B5A-A51E-0B2B1A060C18@mac.com> <483849C6.8010702@optonline.net> Message-ID: <7758b2680805250336k335cd3es5cbdd00cc146dfc5@mail.gmail.com> 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 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 at common-lisp.net > http://common-lisp.net/mailman/listinfo/cells-devel >