> > 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 _______________________________________________ cells-devel site list [email protected] http://common-lisp.net/mailman/listinfo/cells-devel
