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