[cells-gtk-devel] lots of circular cells in cells-gtk3?

[Peter Hildebrandt]

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 <kennytilton at optonline.net> 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))
>        , at 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
>