Ken, thanks for shadding some light on the issue.
I think I found a decent solution to the problem by abusing (what a contradiction) the rule for the id slot and dropping in my two lines: #+libcellsgtk (gtk-signal-connect-swap id "configure-event" (cffi:get-callback 'reshape-widget-handler) :data id) (gtk-signal-connect-swap id "delete-event" (cffi:get-callback 'delete-widget-handler) :data id) This way I can use id -- the local lexical variable holding the brand new id -- and work with it without any cells dependency. And one could argue that I do the required stuff right where it belongs. Cheers, Peter On Mon, Apr 14, 2008 at 6:57 PM, Ken Tilton <[EMAIL PROTECTED]> wrote: > Peter Hildebrandt wrote: > > > As you saw in my other mail, I found the intermediate cause of the > > problem: I had included a reference to (id self) in > > initialize-instance of widget. For some reason that causes the > > circularity detection to raise its voice. > > > > What I don't understand, however, is why a reference to the slot in > > initialize-instance :after brings out circularity. > > > > For now, I moved the stuff into the rule for the id slot itself, so > > when the id is calculated, I use it right away, and don't have to > > worry about cell access. slot-value would have been another option, I > > suppose. > > > > But still: why??? > > > > Recently some evil programming took forever to debug because I was > re-entering a rule without realizing it. After figuring out that that was > happening and fixing the cause of that, I looked to see why rule re-entrance > had not been detected, which I seemed to recall it always had been. > > Turns out the rule began with without-c-dependency as a trick to run only > once. That macro simply: > > `(let ((cells::*call-stack* nil)) > ,@body) > > And that worked because the dependent cell was always identifed as (car > cells::*call-stack*). > > Well, I like early bug detection you may have noticed recently <g>, so I > decided the macro without-c-dependency should leave the *call-stack* intact > and instead bind a separate new *depender* special to nil, with *depender* > being the, well, depender honored by the Cells machinery. > > You should not have been doing cells-y stuff in i-i, but you got away with > it because of the old without-c-dependency behavior, so... > > ...congratulations, you are the first victim to fall into my new bug trap. > :) > > kt > _______________________________________________ cells-gtk-devel site list cells-gtk-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/cells-gtk-devel
