cells-devel September 2006

cells-devel@common-lisp.net

6 participants
12 discussions

[cells-devel] Celtk: Added new cell slot to class window: decoration
by Frank Goenninger 28 Sep '06

28 Sep '06

Hi all: I just committed to CVS a small addition to the window class: Decoration. Setting this slot to :none creates a window without a title bar and without any borders. Useful to create Splash screens or to create windows for tooltips ... Enjoy! Regards Frank

1 0

[cells-devel] assertion failure in c-pulse-update (CVS latest)
by Jack Unrue 13 Sep '06

13 Sep '06

I've upgraded to the latest CVS version of Cells and have encountered the following assertion failure: *** - (>= CELLS::*DATA-PULSE-ID* (CELLS::C-PULSE CELLS::C)) must evaluate to a non-NIL value. which had not occurred previously (I can't say what version, but I would say more than a couple months ago). I believe the key is that I'm calling cells:cells-reset and then attempting to invoke an accessor on a model object that existed prior to the cells-reset call. This used to work OK, but perhaps I've been getting away with something I shouldn't have been? Here's the relevant part of the stack trace (this is CLISP 2.39 btw): <13> #<COMPILED-FUNCTION SYSTEM::SIMPLE-ASSERT-FAILED> <14> #<COMPILED-FUNCTION CELLS::C-PULSE-UPDATE> <15> #<COMPILED-FUNCTION CELLS::ENSURE-VALUE-IS-CURRENT> <16> #<COMPILED-FUNCTION CELLS::MD-SLOT-VALUE-7> frame binding variables (~ = dynamically): | ~ CELLS::*DEFER-CHANGES* <--> NIL frame binding variables (~ = dynamically): | ~ CELLS::*UNFINISHED-BUSINESS* <--> NIL frame binding variables (~ = dynamically): | ~ CELLS::*WITHIN-INTEGRITY* <--> NIL <17> #<COMPILED-FUNCTION CELLS::CALL-WITH-INTEGRITY> <18> #<COMPILED-FUNCTION CELLS::MD-SLOT-VALUE> <19> #<COMPILED-FUNCTION #:|68 86 (CELLS:DEFMODEL FSM-MODEL NIL ...)-9-4-4-1-1-1 |> <20> #<STANDARD-GENERIC-FUNCTION JDUSOFT.MUSIC-TRAINER::CURRENT-STATE> <21> #<COMPILED-FUNCTION JDUSOFT.MUSIC-TRAINER::SUBMIT-EVENT> SUBMIT-EVENT is a function in my code, and the first thing it does is call CURRENT-STATE which is an accessor for a rule slot. There is also an observer declared for this same slot. Any ideas? Am I right about the continued use of a model object after cells-reset being the culprit? -- Jack Unrue

2 3

Re: [PyCells] [cells-devel] Call for comment on Prospect of Lazy Cells Not Propagating Either
by Ken Tilton 13 Sep '06

13 Sep '06

On 9/11/06, Ryan Forsythe <ryan(a)pdxcb.net> wrote: > > On Sep 11, 2006, at 9:42 AM, Ken Tilton wrote: > > > btw, I should have mentioned that one obvious option is to simply > > make this > > a new attribute or variant of the lazy attribute, maybe "super-lazy". > > Which is what I would vote for. "Really Always Lazy"? "Always (no I > really mean it this time) Lazy"? I forsee some possible confusion > between super- and always-lazy. My guess is that if always-lazy cells (as we understand them now) sometimes should propagate and sometimes should not (ie, if we cannot come up with One Right Answer) then it should be a new attribute, in which case it should be two new attributes (lazy-calculate and lazy-propagate) replacing lazy. That certainly would give developers all the options in the world (I really do not think a third "lazy-observe" attribute would be appropriate given the meaning of "observe" <g>). But... ...I really hate introducing things without Use Cases to focus the mind. To a degree we are compromising the data integrity by letting values go out of synch with each other. Yes, they pop back into synch when read, but what about observers? If A is eager and depends on B and A has an observer that really really wants to stay on top of reality.... at this point the developer is responsible for keeping the world in order. That is not necessarily a bad thing, unless it is unnecessary and can be handled automatically with more effort on the design side. Jes thinkin out loud. kt

2 3

Re: [cells-devel] Call for comment on Prospect of Lazy Cells Not Propagating Either
by Ken Tilton 11 Sep '06

11 Sep '06

On 9/11/06, Frank Goenninger <frgo(a)mac.com> wrote: > > > Am 11.09.2006 um 18:12 schrieb Ken Tilton: > > > OK, two prospects: first, move the lazy attribute to the root Cell > > class so input Cells can be lazy. > > Good. I'd buy in to this. > > > Hmmm, does this mean we should make it a slot attribute? > > Yes, IMHO. It is an interesting question because one can achieve the same end by being consistent with the Cell spec itself (and that is not too onerous, I think). Then the question is, why add an unnecessary restriction? OTOH, when would one vary the laziness of some attribute? Maybe wait for more experience. Hopefully tfb will have some good input. > Anyway, now here is the real interesting change I am looking at: > > > > The domain is Cells with lazy attributes of t, :always, or :once- > > asked. > > > > Currently, such lazy Cells, once they do get recalculated on being > > queried, propagate immediately to callers aka dependents. And have > > their observers invoked. > > > > The proposed change is not to propagate to callers, but to still > > invoke observers. I think observers cannot be very observant if > > they are not notified of changes as they happen.* > > > > Comments? Question? > > I'd go along the principle that a cell should propagate the fact of > being queried or changed asap. Note however the clash with "ASAP" and lazy. :) The problem arises at the boundary of eager and lazy cells, and then the question is "what do we mean by lazy?" Just lazy to change, or also lazy to change others? I might author an eager Cell with a rule that reads a lazy Cell and be totally OK with its laziness, where I mean by "totally": I will read you when I have to based on other things changing (or me being read again). btw, I should have mentioned that one obvious option is to simply make this a new attribute or variant of the lazy attribute, maybe "super-lazy". kt

1 0

[cells-devel] Call for comment on Prospect of Lazy Cells Not Propagating Either
by Ken Tilton 11 Sep '06

11 Sep '06

OK, two prospects: first, move the lazy attribute to the root Cell class so input Cells can be lazy. Hmmm, does this mean we should make it a slot attribute? Anyway, now here is the real interesting change I am looking at: The domain is Cells with lazy attributes of t, :always, or :once-asked. Currently, such lazy Cells, once they do get recalculated on being queried, propagate immediately to callers aka dependents. And have their observers invoked. The proposed change is not to propagate to callers, but to still invoke observers. I think observers cannot be very observant if they are not notified of changes as they happen.* Comments? Question? kt * I was amused to see a long comment explaining why I was moving caller/dependent notification in front of observer invocation, when in fact the caller notification then was being placed on a queue and then the observers were invoked immediately. Of course observers, where they perturb the model, are supposed to enqueue themselves cooperatively, but still. :) kt

1 0

[cells-devel] Re: [PyCells] caching in models
by Ken Tilton 06 Sep '06

06 Sep '06

On 9/6/06, Andrew Dalke <dalke(a)dalkescientific.com> wrote: > > Me [Andrew Dalke]: > > I developed a simple dependency system which I've used for several > > clients. The 2nd one was simpler because no modifications occurred > > after a property was set or computed. The heart was something like > > this > > One thing it couldn't handle is query optimization. > > In two cases I computed properties using an external program. > If I wanted property A it took 1 minute, if I wanted property B > it took 1 minute, if I wanted properties A and B computed at the > same time then it took 1 minute 30 seconds. > > My system was all lazy. Set it up with the rules and ask for > the desired properties. But that meant asking for them one-at-a-time. > There was no way to figure out that the user wanted A and B so go ahead > and do the combined request instead of 2 separate requests. > > I don't think PyCells can do this either. It's a hard problem > without explicit knowledge of the dependencies. The way I would phrase it is not that PyCells can or cannot do something, rather: Right, PyCells cannot help with any dependency it does not "see". And all that means is that, right, Cells/PyCells is not a free lunch after all; we must work around the things it can do to get what we want, and I must say I spent quite a while learning to think fluently in the dataflow paradigm, and even now hard problems (the ones involving events) I have to think pretty hard to come up with declarative solutions. The only saving grace is that it is that fun kind of hard thinking. My solution is to provide a hint - when I know I'll do something > which needs A+B I'll look up a special property which computes > A+B and then sets A and B. That would work. Or buy into the apparent potential for composite queries lock stock and barrel, by creating an "and" operator in your burgeoning language and encouraging users to divide-and-conquer queries as much as possible to get re-use. This might mean moving the query-result cache out into a separate supervisory class. Then you have a query class that gets a pointer to the supervisor to see the search space and cache. Queries can be atomic (A, B) or "operation queries" which have an opcode "+" and so many "opnd" queries as an attribute. Hopefully you can figure out how to cache composites as well as atomics if the operations themselves are expensive enough (and reuse of those is to be expected). Then you are not doing anything special to cache subqueries. hth,kt

1 0

[cells-devel] Re: [PyCells] caching in models
by Ken Tilton 06 Sep '06

06 Sep '06

Sorry, the Python was so hard for me to read that I punted on the original query. [Lispniks: the idea is to have a counter object that counts and caches counts of a substring in a text object known to the counter, and for the count cache to get cleared when the text known to the counter gets changed. Do we do it in a bogus cell and rule that watches the text cell and imperatively clears the countcache (a non-cell) or do we do it in an observer on the text? Andrew, the OP, did not like the bogus cell/rule, but also did not like defining the observer separately from the counter (a more general observation on observers)] One cutesy approach would be to make count_cache a cell and (in Lisp): :count_cache (c? (when (text self) (make-hash-table))) Or if it really seems faster to save the dictioanry: :count_cache (c? (when (text self) (if .cache (clrhash .cache) ;; clrhash returns its input (make-hash-table)))) I use the self-deprecating "cutesy" above because what we are doing here is achieving an imperative effect using our understanding of how the declarative cells engine works, so it is a little non-obvious, aka "cutesy". Okay, the conditional "when" (a one-branch IF for you Pythonistas) is a tad bogus. Like the original code (not shown, Lispniks) it could have just been an unused read of the text slot just to get the dependency. With Andrew I hate myself in the morning after writing code like that. :) That said, the more I use Cells for real-world application stuff the more I appreciate the net win of the declarative paradigm, even when I have to think a little harder to get imperative behavior ("hey, the text is changing, clear the cache") out of it. I also would not feel guilty about writing ugly code like that because, hey, the cache is an optimization, optimizing always leads to ugly code. And, speaking of unnecessary optimization, why not just make a new LetterCounter for the new text? Too easy? Or do not even use Cells to clear the cache, just create a function to set the text that first clears the cache. But this last brings me back to preferring ugly Cells code to clean otherwise code: having a fishy rule that clears the cache at least keeps all the important code in one place, and to the extent that the code gets complicated (not this simple case) it does guarantee correctness, whereas without Cells someonbe might set the text directly instead of going thru the bottleneck function which also clears the cache. That last bit argues against using the observer at all. In a sense, the count_cache is indeed a function of the search text, whether one wants its existence to depend on the text, or its mutable contents to. And the "WHEN" can be defended as "hey, there is no text so there are no counts cached". I agree this is best represented as an empty dictionary so other code can just look things up without worrying about whether the dictionary exists, but then we come to a new issue: Cells do not really work well with mutable contents. But we could write: :count_cache (c? (if (text self) (if .cache (clrhash .cache)(make-hash-table)) (make-hash-table))) Bit of a waste, but if one is really worried about there always being a dictionary, there ya go. Now this may look like a top-post, but it is not...... On 9/6/06, Ryan Forsythe <ryan(a)pdxcb.net> wrote: > > On Sep 5, 2006, at 6:57 PM, Andrew Dalke wrote: > > Is the above the right way to do that? It feels somewhat wrong > > because the returned result is never used. Though it does work. > > I hesitate to call any solution "wrong," but here's a version with as > few changes as possible that uses an observer: > > ---- > class LetterCounter(cells.Model): > text = cells.makecell(value="") > case_sensitive = cells.makecell(value=False) > > @cells.fun2cell(celltype=cells.AlwaysLazyCell) > def _text(self, prev): > if not self.case_sensitive: > return self.text.lower() > return self.text > > def count(self, s): > try: > count = self._count_cache[s] > print "Returned from cache" > return count > except KeyError: > if not self.case_sensitive: > s = s.lower() > i = self._text.count(s) > self._count_cache[s] = i > print "Computed and saved in cache" > return i > > def __init__(self, *args, **kwargs): > self._count_cache = {} > cells.Model.__init__(self, *args, **kwargs) > > @LetterCounter.observer("_text") > def cache_clearer(model): > model._count_cache.clear() > ---- > > >>> lc = LetterCounter() > >>> lc.text = "Now is the time for all good men to come to the aid > of their country" > >>> lc.count("the") > Computed and saved in cache > 3 > >>> lc.count("o") > Computed and saved in cache > 9 > >>> lc.text = "Life! Don't talk to me about life!" > >>> lc.count("life") > Computed and saved in cache > 2 > >>> lc._count_cache > {'life': 2} > > So, the observer needs to be added to the model after it's built. > I've never been totally satisfied with the way this works, but it > seems to more closely match how Lisp Cells works than having a > mechanism to add an observer within a class def. I do not do it much any more, but Lisp supports dispatch on multiple arguments, and early on I defined quite a few observers that specialized on things other than the class of the instance, or in addition to the class of the instance. That said... Perhaps it'd be good to have it available both ways? Sure. That actually satisfies better the ideal of having everything in one place. To keep things simple, maybe forget the Lisp Cells approach and just make it part of the class defintion (I guess also changing the implementation mechanics so it can happen along with the class definition). > I tried > > > > @_text.observer() > > def _reset_count_cache(self): > > ... > > This does seem really natural. I will keep thinking about this, but FWIW I think this would be a fine divergence for PyCells from Cells. I might even look at adding similar syntactic sugar to Lisp Cells for those many cases where it could usefully be defined along with the slot. OK, here is one new thought. In LispCells, if observers are define for a slot for classes X and SubclassOfX, both observers run for instances of the subclass. Well, I guess that is the same issue either way. Never mind. :) kt

1 0

[cells-devel] Cello/cl-magick: Still having texture problems... Graphic card capabilities
by Frank Goenninger 05 Sep '06

05 Sep '06

Hi Ken, I can't find the email you sent with the parameters of your graphic card. Here are the parameters I get: 0> GL_MAX_LIST_NESTING __ 64 0> GL_MAX_EVAL_ORDER __ 10 0> GL_MAX_LIGHTS __ 8 0> GL_MAX_CLIP_PLANES __ 6 0> GL_MAX_TEXTURE_SIZE __ 16384 0> GL_MAX_PIXEL_MAP_TABLE __ 256 0> GL_MAX_ATTRIB_STACK_DEPTH __ 16 0> GL_MAX_MODEL-VIEW_STACK_DEPTH __ 32 0> GL_MAX_NAME_STACK_DEPTH __ 100 0> GL_MAX_PROJECTION_STACK_DEPTH __ 5 0> GL_MAX_TEXTURE_STACK_DEPTH __ 5 0> GL_MAX_VIEWPORT_DIMS __ 16384 Can't find anything obviously odd but maybe I don't know what to look for... Can you send yours again? Tnx! Another question: Do you do a call-next-method in togl-create-using- class ? I find it useful to do so due to the init done in ix-togl's corresponding method... Likewise for the togl-display-using-class function. Any feedback on this? Thx! Frank

1 0

Re: [cells-devel] feedback and question
by franks-muc＠web.de 04 Sep '06

04 Sep '06

> I am now able to get correct behavior when starting from the repl or by evaluating (run-window 'my-test) in an editor, but only changing this parameter to a lower amt: *event-loop-delay*. The value in CVS is 0.08. I tried 0.02 and got the keystrokes OK, did not experiment further. The problem is that the ACL IDE is then locked out while a Celtk window is open. > > Since entry fields work for me using Run Project in ACL with the *event-loop-delay* parameter at 0.08, I think I will leave it that way since that is how I test anyway. > > Let me know if a lower value for *event-loop-delay* works for you. > > kt > > Reducing *event-loop-delay* is the solution. Already 0.075 let all key strokes show up in the entry field (at 100% CPU usage by acl). It works for me! Frank _______________________________________________________________________ Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos. Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222

2 1

Re: [cells-devel] feedback and question
by Ken Tilton 04 Sep '06

04 Sep '06

On 9/3/06, Ken Tilton <kentilton(a)gmail.com> wrote: > > Sorry, this was incoherent: > > On 9/3/06, Ken Tilton <kentilton(a)gmail.com> wrote: > > > > How do you test? More testing over here reveals the initial value is > > unrelated. If I evaluate (run-window 'my-test) entries do not work well > > > > that is, with or without an initial value such as "abc" for the entry. > I am now able to get correct behavior when starting from the repl or by evaluating (run-window 'my-test) in an editor, but only changing this parameter to a lower amt: *event-loop-delay*. The value in CVS is 0.08. I tried 0.02 and got the keystrokes OK, did not experiment further. The problem is that the ACL IDE is then locked out while a Celtk window is open. Since entry fields work for me using Run Project in ACL with the *event-loop-delay* parameter at 0.08, I think I will leave it that way since that is how I test anyway. Let me know if a lower value for *event-loop-delay* works for you. kt

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

cells-devel September 2006