<br><br><div><span class="gmail_quote">On 6/23/06, <b class="gmail_sendername">Thomas F. Burdick</b> <<a href="mailto:tfb@ocf.berkeley.edu">tfb@ocf.berkeley.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

On 6/23/06, Ken Tilton <<a href="mailto:kentilton@gmail.com">kentilton@gmail.com</a>> wrote:<br>> Oh, yeah. I finally fixed defclass. There is now an abbreviated defmodel,<br>> DEFMD:<br>><br>> (defmd defmd-test (md-test-super)

<br>>     (aaa :cell nil :initform nil :initarg :aaa :accessor aaa) ;; defmd would<br>> have written the same on just "aaa"<br><br>FIXED?!?!<br><br>Aren't a lot of problems with Cells traceable to using :cell nil,

</blockquote><div> Wouldn't know; never use it. :)  Well, I found a few. The keyboard accelerator for a widget. God help the user if those start changing according to program state. Also a cache of the window at the top of the gui hierarchy. It's a pretty quick trip up the tree to do that functionally, but why not save the result? Make it a cell and it has to be an input, dependencies pop up all over.

<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">because either someone thought "okay this one is an exception" or as

<br>an efficiency hack?  Certainly accidentally non-Cell slots have caused<br>me no end of grief when I run into them.</blockquote><div><br>Amazing. I never had a problem.  What happens  is that I finally try to  apply a cell to one and the internals say, "what are you doing? I see a cell initializer for a non-cell slot." (Not sure that safeguard is still in there tho.)

<br><br>To the extent my bet was correct ("who would ever want to use a cell for /this/?!") the risk of accidentally trying to use a cell goes down commensurately.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

I've gotten to the point of viewing :cell nil as a hack that's<br>occasionally necessary when either (a) I'm not able to fit some<br>behavior into the Cells model, or (b) the Cells model turns out to<br>have a shortcomming that needs to be fixed, but in the meantime we

<br>have a work-around.  Given that, I'm not supporting :cell nil at all<br>in C4 (and C4-other-lisps); </blockquote><div><br>Question: do you even /look/ at Cells code any more? <br><br>

Phillip Eby over on PyCells is now fleshing out his dataflow package, and we unearthed another Pythonista who had some DF code but got motivated by Cells to formalize it into a proper package. My other question: what do we call the annual conference, and where do we hold it? Dataflow 2007? Gotta get the KR and COSI people, too. I propose not having any talks, so there is more time for drinking. Maybe we could label the clusters of drinkers as to the dataflow topic they happen to be on. Need some electronic signage....

<br><br>kt<br></div><br></div><br>