From franks-muc at web.de Sun Sep 3 10:53:34 2006 From: franks-muc at web.de (franks-muc at web.de) Date: Sun, 03 Sep 2006 12:53:34 +0200 Subject: [cells-devel] feedback and question Message-ID: <186276517@web.de> This is a feed back (with quetions) on my first experiments with cells/celtk on mswindows and acl 7 trial. - asdf installation of the lisp files is straight forward. - Of course, I had to install tcl and other software I did not know before (e.g. darcs). The togl.dll took me some time, but I had the spinning gears demo running after about 4 hours. I was so happy! - Documentation for cells exists and is helpful !! After a study of ltktest-ci.lisp it was easy to do my own sample GUI with buttons, radios and labels. - I never did a gui before. I only went through the interface builder demo of allegro a while ago and my impression was: I don't want to do that and avoid it as long as possible. Now I'm completely surprised how easy it is to set up a gui, and the automatic actions and updates made by cells are pure fun. - The only problem I encountered so far is with the text entry widget: alphanumeric key strokes get through to the entry field only occasionally. May be only one of about five key strokes is shown in the entry field. Backspace and cursor left/right work correctly, however. This also happens in the moire demo of ltktest-ci.lisp. What can I do to improve this ? Summarized: celtk is great, and I would be happy about some help on my last item above. Frank Schorr __________________________________________________________________________ Erweitern Sie FreeMail zu einem noch leistungsst?rkeren E-Mail-Postfach! Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131 From kentilton at gmail.com Sun Sep 3 12:21:59 2006 From: kentilton at gmail.com (Ken Tilton) Date: Sun, 3 Sep 2006 08:21:59 -0400 Subject: [cells-devel] feedback and question In-Reply-To: <186276517@web.de> References: <186276517@web.de> Message-ID: On 9/3/06, franks-muc at web.de wrote: > > > This is a feed back (with quetions) on my first experiments with > cells/celtk > on mswindows and acl 7 trial. > > - asdf installation of the lisp files is straight forward. Wow, you may be the first to have done it, other than me and Frank, the developers. I usually warn people away from even trying. :) - Of course, I had to install tcl and other software I did not know before ( > e.g. darcs). > The togl.dll took me some time, but I had the spinning gears demo > running after > about 4 hours. I was so happy! Yeah, OpenGL is great fun, altho challenging. - Documentation for cells exists and is helpful !! > After a study of ltktest-ci.lisp it was easy to do my own sample GUI > with buttons, radios > and labels. Wow again. :) - I never did a gui before. I only went through the interface builder demo > of allegro a while ago > and my impression was: I don't want to do that and avoid it as long as > possible. > Now I'm completely surprised how easy it is to set up a gui, and the > automatic > actions and updates made by cells are pure fun. Yep. It would be even more fun if you had done a GUI before and knew what a pain it was once things start to get complicated. I find I make fancier (and easier for the user) GUIs just because Cells makes it easy. - The only problem I encountered so far is with the text entry widget: > alphanumeric key strokes get through to the entry field only > occasionally. > May be only one of about five key strokes is shown in the entry field. > Backspace and cursor left/right work correctly, however. > This also happens in the moire demo of ltktest-ci.lisp. > What can I do to improve this ? I remember something like this happening, but forget the details. I will fire up that demo and see what I can see. It may be a while because my (win32) system seems close to a hard drive failure today (one blue screen already). kt -------------- next part -------------- An HTML attachment was scrubbed... URL: From kentilton at gmail.com Sun Sep 3 13:57:35 2006 From: kentilton at gmail.com (Ken Tilton) Date: Sun, 3 Sep 2006 09:57:35 -0400 Subject: [cells-devel] feedback and question In-Reply-To: References: <186276517@web.de> Message-ID: > > - The only problem I encountered so far is with the text entry widget: > > alphanumeric key strokes get through to the entry field only > > occasionally. > > May be only one of about five key strokes is shown in the entry field. > > Backspace and cursor left/right work correctly, however. > > This also happens in the moire demo of ltktest-ci.lisp. > > What can I do to improve this ? > > > I remember something like this happening, but forget the details. I will > fire up that demo and see what I can see. It may be a while because my > (win32) system seems close to a hard drive failure today (one blue screen > already). > When I ran the demo in ltktest-ci just now, I got the same (mis)behavior, only in my case it was only one in twenty keystrokes that got thru. At the same time, the entry widget in the lotsa-widgets demo worked fine. Enabling some print statements in the entry widget, what I saw was that key events such as keypress and keyrelease were working fine, but that only occasionally a "trace" virtual event came thru. The key events would not help much since the entry field itself was not getting the keystrokes (and we still let Tk handle the actual input). Anyway, while fussing with this the ltktest-ci demo entry field just started working pretty much by itself. I was poking around, but on unrelated stuff trying to make the demo shutdown not crash on a late timer message. (That required a small extension to the Cells API.) Anyway, it will be interesting to see if your entry field (and your ltktest-ci execution) work given the new code in Cells and Celtk. If not or if the problem comes back I think a question to the Tcl/Tk list will be in order as to when keyevents can happen but not get seen by the widget as evidenced by the widget text and (reasonably enough) "trace write"s. kt -------------- next part -------------- An HTML attachment was scrubbed... URL: From kentilton at gmail.com Sun Sep 3 19:48:31 2006 From: kentilton at gmail.com (Ken Tilton) Date: Sun, 3 Sep 2006 15:48:31 -0400 Subject: [cells-devel] feedback and question In-Reply-To: <186645585@web.de> References: <186645585@web.de> Message-ID: Try this: (mk-entry :id :my-entry :md-value (c-in nil)) ;; instead of (c-in "abc") Have not investigated why, but with (c-in "abc") I did not get many keystrokes either, but changing to (c-in nil) seems to have done the trick. Next task would be to figure out how to initialize an entry widget to something other than nil, which is a requirement of such widgets. First let's find out if (c-in nil) gets the keystrokes recognized. kt On 9/3/06, franks-muc at web.de wrote: > > > > > > Anyway, it will be interesting to see if your entry field (and your > ltktest-ci execution) work given the new code in Cells and Celtk. If not or > if the problem comes back I think a question to the Tcl/Tk list will be in > order as to when keyevents can happen but not get seen by the widget as > evidenced by the widget text and (reasonably enough) "trace write"s. > > > > > > I downloaded the new tarball, deleted all binaries, started fresh. > > The behaviour of ltktest-ci is unchanged. May be the success rate of 1/5 > was too optimistic in my > first post, but it is better than 1/20. It appears to be completely > random. Sometimes two > successive key strokes get through. > > My sample model as attched here has a success rate which is much less than > 1/20. > > (defmodel my-test (window) > ((my-mode :accessor my-mode :initform (c? (evenp (selection (fm! > :my-selector)))))) > (:default-initargs > :id :my-test-id > :kids (c? (the-kids > (mk-stack ("stack" :packing (c?pack-self "-side bottom") > :relief 'ridge) > (mk-entry :id :my-entry > :md-value (c-in "abc")) > (mk-row ( "row" #| :packing (c?pack-self "-side > bottom") |# :relief 'ridge) > (mk-label :text (c? (format nil > "selection: ~a" (selection (fm^ :my-selector))))) > (mk-label :text "Labeltext") > (mk-button-ex ("Reset" (setf (selection > (fm^ :my-selector)) 1))) > (mk-stack ((c? (format nil "current > selection: ~a" (^selection))) :id :my-selector :selection (c-in 1) :relief > 'ridge) > (mk-radiobutton-ex ("selection 1" > 1)) > (mk-radiobutton-ex ("selection 2" > 2)) > (mk-radiobutton-ex ("selection 3" > 3)) > (mk-radiobutton-ex ("selection 4" > 4))) > (mk-label :text (c? (format nil "selection: > ~a" (selection (fm^ :my-selector))))) > )))))) > > (defobserver my-mode ((self my-test) new-value old-value > old-value-bound-p) > (format t "~% mode changed from ~a to ~a" old-value new-value)) > > (run-window 'my-test) > > > > _______________________________________________________________________ > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kentilton at gmail.com Mon Sep 4 05:16:08 2006 From: kentilton at gmail.com (Ken Tilton) Date: Mon, 4 Sep 2006 01:16:08 -0400 Subject: [cells-devel] feedback and question In-Reply-To: References: <186725349@web.de> Message-ID: On 9/3/06, Ken Tilton wrote: > > Sorry, this was incoherent: > > On 9/3/06, Ken Tilton 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From franks-muc at web.de Mon Sep 4 08:30:31 2006 From: franks-muc at web.de (franks-muc at web.de) Date: Mon, 04 Sep 2006 10:30:31 +0200 Subject: [cells-devel] feedback and question Message-ID: <186983023@web.de> > 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 From kentilton at gmail.com Mon Sep 4 12:10:50 2006 From: kentilton at gmail.com (Ken Tilton) Date: Mon, 4 Sep 2006 08:10:50 -0400 Subject: [cells-devel] feedback and question In-Reply-To: <186983023@web.de> References: <186983023@web.de> Message-ID: On 9/4/06, franks-muc at web.de wrote: > > > > 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). Yeah, I think any vale that low is effectively zero because it is below some minimum granularity. Also, my guess is that you are now locked out of the ACL IDE while a Celtk window is open. That could make debugging pretty hard. A number of solutions occur to me, including adjusting the delay intelligently when the TK window loses the "focus" aka deactivates, or even just a whole new approach to the event loop. Unfortunately I will not be able to explore these until my own project demands it, but I might poke around a little now and again, and I will be happy to help anyone else with ideas if they choose to explore. The new event loop approach is probably the only way to avoid pegging the CPU. I forget what happens if we just give the whole event loop to Tcl and settle for callbacks. Possibly we are looking at hogging the CPU during development, then switching to a different approach for delivered apps, all controlled by conditional compilation. kt ps. Cells fans, sorry for the spam; if the Celtk traffic keeps up I will look at getting a new project, or moving Celtk from Cells to Cello and supporting it fromt here. kt -------------- next part -------------- An HTML attachment was scrubbed... URL: From fgoenninger at prion.de Tue Sep 5 17:35:53 2006 From: fgoenninger at prion.de (Frank Goenninger) Date: Tue, 5 Sep 2006 19:35:53 +0200 Subject: [cells-devel] Cello/cl-magick: Still having texture problems... Graphic card capabilities Message-ID: 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 From kentilton at gmail.com Wed Sep 6 18:12:46 2006 From: kentilton at gmail.com (Ken Tilton) Date: Wed, 6 Sep 2006 14:12:46 -0400 Subject: [cells-devel] Re: [PyCells] caching in models In-Reply-To: References:

Message-ID: 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kentilton at gmail.com Wed Sep 6 23:33:33 2006 From: kentilton at gmail.com (Ken Tilton) Date: Wed, 6 Sep 2006 19:33:33 -0400 Subject: [cells-devel] Re: [PyCells] caching in models In-Reply-To: References:

Message-ID: On 9/6/06, Andrew Dalke 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kentilton at gmail.com Mon Sep 11 16:12:13 2006 From: kentilton at gmail.com (Ken Tilton) Date: Mon, 11 Sep 2006 12:12:13 -0400 Subject: [cells-devel] Call for comment on Prospect of Lazy Cells Not Propagating Either Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kentilton at gmail.com Mon Sep 11 16:42:45 2006 From: kentilton at gmail.com (Ken Tilton) Date: Mon, 11 Sep 2006 12:42:45 -0400 Subject: [cells-devel] Call for comment on Prospect of Lazy Cells Not Propagating Either In-Reply-To: <1FA94C5D-CAAE-49ED-A1A4-7064A6416BCE@mac.com> References: <1FA94C5D-CAAE-49ED-A1A4-7064A6416BCE@mac.com> Message-ID: On 9/11/06, Frank Goenninger 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kentilton at gmail.com Mon Sep 11 18:00:44 2006 From: kentilton at gmail.com (Ken Tilton) Date: Mon, 11 Sep 2006 14:00:44 -0400 Subject: [PyCells] [cells-devel] Call for comment on Prospect of Lazy Cells Not Propagating Either In-Reply-To: <3F3EA016-2CB7-4C3C-9D30-C3EB9DC41B2E@pdxcb.net> References: <1FA94C5D-CAAE-49ED-A1A4-7064A6416BCE@mac.com> <3F3EA016-2CB7-4C3C-9D30-C3EB9DC41B2E@pdxcb.net> Message-ID: On 9/11/06, Ryan Forsythe 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" ). 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kentilton at gmail.com Mon Sep 11 19:33:40 2006 From: kentilton at gmail.com (Ken Tilton) Date: Mon, 11 Sep 2006 15:33:40 -0400 Subject: [PyCells] [cells-devel] Call for comment on Prospect of Lazy Cells Not Propagating Either In-Reply-To: References: <1FA94C5D-CAAE-49ED-A1A4-7064A6416BCE@mac.com> <3F3EA016-2CB7-4C3C-9D30-C3EB9DC41B2E@pdxcb.net> Message-ID: kt wrote: If A is eager and depends on B and A has an observer that really really > wants to stay on top of reality.... > I just had Cells4 kinda thought: what if all Cells are (in some new respect) lazy unless observed (directly or indirectly thru someone that is observed)? btw, as radical as that change sounds, I am not sure it really rises to the level of "Cells4" -- I am suggesting this only because I think it is equivalent to Cells3 (assuming one is sane enough not to have side-effects inside rules) and merely automates the identification of which cells can be lazy (or looked at another way, automates the detection of the need for eagerness. Then the explicit thing becomes supporting a new class of much rarer (methinks) "lazy" observer whose existence would not trigger eagerness. It would be interesting to see how much laziness ends up being deduced by this approach. The indirect eagerness (I am not observed, but I am called/used by someone who is) could get interesting. Jes thinkin out loud. kt -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at naunton.us Wed Sep 13 00:20:48 2006 From: michael at naunton.us (Michael Naunton) Date: Tue, 12 Sep 2006 20:20:48 -0400 Subject: [PyCells] [cells-devel] Call for comment on Prospect of Lazy Cells Not Propagating Either In-Reply-To: References: <1FA94C5D-CAAE-49ED-A1A4-7064A6416BCE@mac.com> <3F3EA016-2CB7-4C3C-9D30-C3EB9DC41B2E@pdxcb.net> Message-ID: <1158106848.5844.33.camel@linux.site> On Mon, 2006-09-11 at 15:33 -0400, Ken Tilton wrote: > kt wrote: > > If A is eager and depends on B and A has an observer that > really really wants to stay on top of reality.... > > I just had Cells4 kinda thought: what if all Cells are (in some new > respect) lazy unless observed (directly or indirectly thru someone > that is observed)? I was using Cells4 today :) So, all cells are lazy. Check. Unless observed. Check. Observed = I ask for a cells value explicitly (in which case it is transiently observed,) or a GUI, etc, subscribes to it. This makes the implementation really easy: class Cell: def invalidate( self ): if self.state != INVALID: if self.subscibed(): invalidationSet.add( self ) self.state = INVALID for x in self.dependents: x.invalidate() def set( self, v ): self.invalidate() self.val = v # dispatch invalidateSet stuff at some transactional boundary > > btw, as radical as that change sounds, I am not sure it really rises > to the level of "Cells4" -- I am suggesting this only because I think > it is equivalent to Cells3 (assuming one is sane enough not to have > side-effects inside rules) and merely automates the identification of > which cells can be lazy (or looked at another way, automates the > detection of the need for eagerness. Yep. No side-effects, and life is simple. Eagerness is just: class Cell: def value( self ): inputs = [ x.value() for x in self.inputs ] self.val = self.calc( *inputs ) self.state = VALID return self.val > Then the explicit thing becomes supporting a new class of much rarer > (methinks) "lazy" observer whose existence would not trigger > eagerness. Ah, but once you've eliminated side-effects, lazy observers become easy to write and really useful. Consider a tabbed panel GUI on an object with same panel 1 = basic info, and panel 2 = expensive to compute stuff. The panels subscribe to the cells they care about, but when the observer callbacks are called, they do something like: class GuiElem: def myVal( self ): return self.myCell.value() def draw( self ): self.widget.draw( self.myVal() ) def callback( self, aCell ): if self.isVisible(): self.draw() def onActivate( self ): self.draw() Lovely, no? Maximal laziness - the only cost is establishing the cell dependencies. > It would be interesting to see how much laziness ends up being deduced > by this approach. The indirect eagerness (I am not observed, but I am > called/used by someone who is) could get interesting. > > Jes thinkin out loud. You just keep thinking, Butch. That's what you're good at. -- mmn From jdunrue at gmail.com Wed Sep 13 03:04:14 2006 From: jdunrue at gmail.com (Jack Unrue) Date: Tue, 12 Sep 2006 21:04:14 -0600 Subject: [cells-devel] assertion failure in c-pulse-update (CVS latest) Message-ID: 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> # <14> # <15> # <16> # 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> # <18> # <19> # <20> # <21> # 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 From kentilton at gmail.com Wed Sep 13 07:47:53 2006 From: kentilton at gmail.com (Ken Tilton) Date: Wed, 13 Sep 2006 03:47:53 -0400 Subject: [cells-devel] assertion failure in c-pulse-update (CVS latest) In-Reply-To: References: Message-ID: On 9/12/06, Jack Unrue wrote: > > 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? I think the deal is this (you are right): 1. Cells-reset has always reset the vital *data-pulse-id* to 0 2. Old model object cells still in use when cells-reset was invoked thus have always had DPs (datapulses) greater than *data-pulse-id*, obviously benignly so in your application. 3. I have an insanely high degree of confidence that the assertion above was inserted in the past month after I debugged a tough problem in which an object DP got moved backwards. (This had to do with another new mechanism,integrity bubbles, which I happen to plan to back out.) So...you can: 1. chop the assertion 2. suggest a new cells-reset-a-little, or a cells-reset parameter which says "I want to reset this but not that" Re the latter, i admit Cells are a little un-Lispy in that I have not worked much on restarts. But the function cells-reset is meant to truly reset the cells mechanism, so as you surmised I am surprised you got away with it at all. I almost think then that, in your testing, you might want to simply arrange things so that cells-reset does not get called unless you are truly reinitializing your own application -- that is the spirit of cells-reset.* kt * uh-oh, now I am in a panick over someday doing persistent cells again. :) look for datapulse-id to become: (+ (* 10000 (get-internal-real-time) (incf "oldskool-dp*)) Where *oldskool-dp* gets zeroed when g-i-r-t changes. kt -------------- next part -------------- An HTML attachment was scrubbed... URL: From kentilton at gmail.com Wed Sep 13 08:25:28 2006 From: kentilton at gmail.com (Ken Tilton) Date: Wed, 13 Sep 2006 04:25:28 -0400 Subject: [PyCells] [cells-devel] Call for comment on Prospect of Lazy Cells Not Propagating Either In-Reply-To: <1158106848.5844.33.camel@linux.site> References: <1FA94C5D-CAAE-49ED-A1A4-7064A6416BCE@mac.com> <3F3EA016-2CB7-4C3C-9D30-C3EB9DC41B2E@pdxcb.net> <1158106848.5844.33.camel@linux.site> Message-ID: On 9/12/06, Michael Naunton wrote: > > On Mon, 2006-09-11 at 15:33 -0400, Ken Tilton wrote: > > kt wrote: > > > > If A is eager and depends on B and A has an observer that > > really really wants to stay on top of reality.... > > > > I just had Cells4 kinda thought: what if all Cells are (in some new > > respect) lazy unless observed (directly or indirectly thru someone > > that is observed)? > > I was using Cells4 today :) > > So, all cells are lazy. Check. > Unless observed. Check. > Observed = I ask for a cells value explicitly (in which case it is > transiently observed,) or a GUI, etc, subscribes to it. I do not know about your C4, but no: Observation is not reading. Observation is an explicit declaration that one needs certain code to run when a cell changes value, and these explicit declarations are needed because the cells engine runs around changing values willy-nilly so there is no way for a programmer to handle those changes unless we create a mechanism dedicated to that express purpose. aka "observing". But we really need these observers to run. An observer might propagate the state "stop!!!" to an anti-lock brake system (via its own API). We have other code that reads Cells inside Cell rules and outside them in imperative code kicked off, say, by OS events. Imperative code (again, event-handlers are an example) reads what it reads. Cells guarantees they will get accurate "current" values. But there is no need for a Cell to ensure (and in fact it would be inappropriate) such event-handling code runs because some cell-mediated state gets read during event handling. Reads from Cell rules are not interesting to rerun until somehow somewhwere we come to an Observer trying to stop a car or launch a missile or whatever. kt -------------- next part -------------- An HTML attachment was scrubbed... URL: From kentilton at gmail.com Wed Sep 13 16:12:46 2006 From: kentilton at gmail.com (Ken Tilton) Date: Wed, 13 Sep 2006 12:12:46 -0400 Subject: [cells-devel] assertion failure in c-pulse-update (CVS latest) In-Reply-To: References: Message-ID: On 9/13/06, Ken Tilton wrote: > > > > Re the latter, i admit Cells are a little un-Lispy in that I have not > worked much on restarts. But the function cells-reset is meant to truly > reset the cells mechanism, so as you surmised I am surprised you got away > with it at all. > I take it back. Assuming you did not backtrace and cause the global *stop* to get set, re-running cells-reset and moving the DP back to zero would (absent the new assertion, of course) merely cause some cells to re-run their rules unnecessarily one time (and then recompute the same value anyway). No big deal at all. kt -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdunrue at gmail.com Wed Sep 13 16:30:32 2006 From: jdunrue at gmail.com (Jack Unrue) Date: Wed, 13 Sep 2006 10:30:32 -0600 Subject: [cells-devel] assertion failure in c-pulse-update (CVS latest) In-Reply-To: References: Message-ID: On 9/13/06, Ken Tilton wrote: > > On 9/12/06, Jack Unrue wrote: > > > > *** - (>= CELLS::*DATA-PULSE-ID* (CELLS::C-PULSE CELLS::C)) must evaluate > to a > > non-NIL value. > > > > [snip] > > I think the deal is this (you are right): > > 1. Cells-reset has always reset the vital *data-pulse-id* to 0 > 2. Old model object cells still in use when cells-reset was invoked thus > have always had DPs (datapulses) greater than *data-pulse-id*, obviously > benignly so in your application. > 3. I have an insanely high degree of confidence that the assertion above was > inserted in the past month after I debugged a tough problem in which an > object DP got moved backwards. (This had to do with another new > mechanism,integrity bubbles, which I happen to plan to back out.) OK thanks for explaining. Just to elaborate, my app basically runs through a series of brass instrument fingering exercises. For each one, the user presses key combinations representing what they think is the correct fingering in response to the current clef, key signature, and note. During each test run, the student can interrupt the test and start over. So there are two models, one of which holds the current test run's state (and hence is what needs to be cleared/reset); the other is a FSM that processes key events to translate them into instrument fingerings, and this model conceptually doesn't need to be reset. > So...you can: > > 1. chop the assertion > 2. suggest a new cells-reset-a-little, or a cells-reset parameter which says > "I want to reset this but not that" I'm happy to change my app to conform. I don't think my scenario warrants changing Cells, because I don't think I have a strong enough use-case for (2) and you didn't put the assertion in there for the fun of it :-) > Re the latter, i admit Cells are a little un-Lispy in that I have not worked > much on restarts. But the function cells-reset is meant to truly reset the > cells mechanism, so as you surmised I am surprised you got away with it at > all. I almost think then that, in your testing, you might want to simply > arrange things so that cells-reset does not get called unless you are truly > reinitializing your own application -- that is the spirit of cells-reset.* Understood. Thanks again, Kenny! -- Jack Unrue From frgo at mac.com Thu Sep 28 21:08:48 2006 From: frgo at mac.com (Frank Goenninger) Date: Thu, 28 Sep 2006 23:08:48 +0200 Subject: [cells-devel] Celtk: Added new cell slot to class window: decoration Message-ID: <3D87D7EA-76CC-4A38-BDF0-25A3A9AF7DF9@mac.com> 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