[cells-devel] Handling not-to-be'd kids and how to do an input slot for kids

[Peter Hildebrandt]

Ken,

as I said, my cells-tree-view works now -- wonderful.  Gotta get going
with (+ cells-ode open-gl) right away :-)

>  Meanwhile over here working on OpenAIR I ended up trying to read dead
> instances. Have not figured out why, but I have a guess. Still, this comes
> up so often I think we might want to make this less painful for developers.

I see what you mean.  It cost me quite a bit of time to track down
those instances, especially since the problem is mostly transient, i.e
the references to dead objects usually disappear quickly after the
objects itself die.  That's why I suggested the zombie state.  You
talk about it in more detail below, so I will hold my comments until
then.

>  Sure, go for it.

Ok, I created a new module for cells-gtk3 in the cells repository,
called cells-gtk3.  It is up to date, the demo includes the
cells-tree-view and two cairo demos, and it runs fairly stable (i.e. I
did not manage to break it) both in threading and non-threading mode.

>  May I just observe at this juncture that I wish you had chosen a name other
> than observer for this class given that Cells already has the observer name
> in play. :)

Well, it was your suggestion :)  I asked for something "like an
observer on a whole family" a while ago on cells-devel, and you
suggested the family-observer.  In the code, I call it f-observer,
because, well, it is something like an observer, only that it observer
a whole family, not just a single cell.
> > What I'd like to have is
> > - not-to-be being called before the object is declared dead
> > or
> > - another method (last-will?) to be executed right before the kids die
> > or
> > - an interims state (:zombie?) in which cell slots are still
> > accessible with their last cached value
> >
> > Or is the solution to have an observer on the kids slot instead of a
> > not-to-be-method, which does the cleanup work for the kids?
> >
>
>  I used to do that with kids, but not-to-be is a good place for it.

Agreed.  It makes sense for the object to clean up after itself.

> >  I hacked a
> > solution today to the fm-other tree searches which were all over
> > cells-gtk -- now we have with-widget and with-widget-value which do
> > the right thing without kicking off tree searches (I introduced an
> > automatically maintained hashtable of active instances hashing by
> > md-name, like I did in cells-ode).
> >
>
>  haha, almost every day now I think about implementing namespace search that
> way. :) It is kind of cool to have this automatic location-relative search
> that Just Works when we have repeating structures and lots of widgets with
> the same name, but so often a simple hash lookup would suffice.

So I guess we're attacking different problems here.  Both in cells-ode
and in the cells-gtk cases I was dealing with, I do not have equal
names, and the dependencies might very well be wide spread -- in
particular I needed that when I wanted to have primitves in the canvas
slot of the cairo-drawing-area get their parameters from gtk-widgets.
The primitves cannot reside in the kids of the drawing area since
cells-gtk assumes that kids of widgets are widgets, and so the family
structure breaks there.  Maybe I should make the canvas slot :owning
t.   We'll see.

>  Part of the magic of the existing scheme, btw, is that it does not matter
> that some widget might get awakened before the other widget it seeks has
> even been created. The navigation works by hitting kids slots, which get run
> JIT to spawn the thing being looked for.

Yep, we talked about that when tracking down evil failures with (+
cells-gtk cells3).  I figured that on average a hash table look up
will suffice.  My macro handles the case of the target nor exisitng
(or not being initialized) by returning a specified default value.
This way the dependent cell will first default to 0/nil/"" (or
whatever specified), then switch to the "real" value once the
initialization of the source widget is being propagated.

>  When I saw that working without having been planned for I had a feeling I
> had stumbled onto something.

:)

>  Well... I am hesitating. There /is/ an evil variant of corpse access to be
> blocked as an aid to the developer, a form of access wholly unjustifiable. I
> think we need to yell if these happen. As for deferring the death
> certificate, well, what if your not-to-be wants access to a sibling or
> parent or child who is also being interred? Perhaps they get not-to-be'd,
> declared dead, and now it is your turn and you try to read them? We ran but
> could not hide?

Maybe it is a reasonable limitation to limit access in not-to-be to
slots of the passed self object.  I see how one could need to update
other things, but I also see how this could be solved more elegantly
with cells rules (i.e. doing too much in not-to-be looks like
imparative programming through the backdoor -- this is not Java, after
all ;-)).

>  ie, I am not sure then where to put the certification of death, tho it
> occurs to be that the unfinished-business queue (if you have read that far)
> is exactly where this should go, ie we queue instances up for death
> certification to run after full propagation (including not-to-be processing)
> after which point it will be safe to say slot access is an absolute bug.
>
>  The neat thing is that we do have a distinct "awaken" stage in ufb
> processing, why not a distinct "ex-parrot" stage?

Sounds like the ultimate fix (somewhat like the zombie state I
suggested), but I wonder whether it is overkill, given that your fix
just works.

>  Another very quick fix would be simply to do something like with-integrity,
> which explicitly says "I know this may not run right away". We could wrap
> the not-to-be call in a with-post-mortem macro dynamically binding
> *dead-is-cool* to t and then any access anywhere to dead things would be
> allowed. This would avoid the runtime cost of queueing things up for
> annihilation (but then I do  not think that would be a big runtime burden at
> all).
>
>  Anyway, let me implement *dead-is-cool* and have that bound to t before
> calling not-to-be so there is no need to wrap not-to-be code at all and see
> what happens. I'll commit something soon, lemme know if it works. :)

As I wrote before, I fixed one form in ensure-value-is-current, and it
works beautifully :-)

Cheers,
Peter