[cells-devel] not-to-be and owning slots

[Peter Hildebrandt]

> > Sounds good.  I wasn't sure as to whether I understood what I was
> > doing.  I just saw that not-to-be did not propagate to kids *at all*
> > if I did it the way I suggested.
>
>  OK.

That was with test-gtk -- my favorite test case.  Upon a not-to-be on
test-gtk nothing gets propagated.  the class hierarchy is
test-gtk->gtk-app->window->container->widget->gtk-object->family.
But, no, there is no kids slot redefined anywhere.
> > Hold on, one idea:  Maybe the problem is with
> >
> > (get (type-of fm) :ownings), i.e. this only picks up the owning
> > defined on the actual class of fm, not the inherited ones?
> >
> > To be honest, I am just doing wild guesswork here, so I better shut up :-)
> >
>
>  No, you are hot on the trail. I have code which tries to propagate the
> :owning declaration up and down the class hierarchy, so I wager there is a
> bug in there. And having revisited this, I find myself not liking the idea
> of propagating a slot attribute that way, tho I guess propagating down is
> what other slot attributes do when a slot is reiterated but with some
> attributes not specified. I may ask the c.l.l yobbo language lawyers what
> they think.

Sounds like the sensible thing to do (for I have no idea what is the
right way to do this.  Traversing the whole hierarchy every time a
not-to-be is called in order to collect the list of slots seems wrong
;-))

> > Hope you guys had a good time in Amsterdam.  Hopefully next year I
> > will actually make it :-)
> >
>
>  Everything but the talk itself was a blast. It is so great hanging out with
> Lispers in large quantities. As for the talk, I am tempted to set up my
> camcorder and do the talk again for YouTube.

That'd be great :-)

> :( But based on post-talk
> reaction at least I was understood. A Lispworks guy wanted to talk about how
> hard it must be to debug the damn things. I said, No and yes, the yes being
> that I have always antancipated that as non-experts get involved better
> diagnostics/debug/trace tools would be needed.

Agreed.  It took me a while to make sense of the cells heavy
backtraces I get if I make a silly mistake in a cells rule.  OTOH,
trc/wtrc do a good job for me (I learned programming ona Commodore 64,
so I don't mind print statements as my prime debugging tool.  I still
maintain that a sensible number of print statements is often a better
debugging tool than all the stuff the IDE has to offer -- that is, my
emacs/slime/sbcl yobbo IDE ;))

>  I'll be revising the not-to-be thing and look at why kids did not get
> handled -- good to have a smoking gun to debug. Oh, wait -- what was the
> class? My guess is one that reiterated the kids slot instead of just
> supplying a default initarg.

As I said before, I did not see anything like that between family and
test-gtk.  Hmmm.

I'll try and single out a test case.

Thanks,
Peter