On Tue, Apr 22, 2008 at 2:33 AM, Ken Tilton kennytilton@optonline.net wrote:
Later on I saw you reporting something weird about .kids not getting reliably handled. I' d like to run down the "weird" rather than just throw in parallel code to make .kids work. After I commit lemme know when the weirdness returns.
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.
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 :-)
Hope you guys had a good time in Amsterdam. Hopefully next year I will actually make it :-)
Cheers, Peter
Peter Hildebrandt wrote:
On Tue, Apr 22, 2008 at 2:33 AM, Ken Tilton kennytilton@optonline.net wrote:
Later on I saw you reporting something weird about .kids not getting reliably handled. I' d like to run down the "weird" rather than just throw in parallel code to make .kids work. After I commit lemme know when the weirdness returns.
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.
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.
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. :( 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.
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.
kt
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
Peter Hildebrandt wrote:
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.
I hacked up not-to-be a little (tho nothing fundamentally different than what I recall of your efforts which I cannot find in my email), moved cells-store out into its own source file (update your asd!), reran the cells regression test and test-gtk -- everything works.
Mind you there may not be a non-.kids owning test anywhere in there, or even anything that verifies that the .kids are getting quiesced, but your report above of "I just saw that not-to-be did not propagate to kids *at all*" does not say /how/ you saw that, so maybe there is still non-propagation which is not being exposed by the test suite and still needs to be cured.
kt
On Tue, Apr 22, 2008 at 1:17 PM, Ken Tilton kennytilton@optonline.net wrote:
Peter Hildebrandt wrote:
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.
I hacked up not-to-be a little (tho nothing fundamentally different than what I recall of your efforts which I cannot find in my email), moved cells-store out into its own source file (update your asd!), reran the cells regression test and test-gtk -- everything works.
Hmmm -- I don't see the new source file anywhere. What's its name? Did you add it to CVS before you did the commit?
Btw, I've updated the cells-gtk3 stuff every now and then -- did you update from CVS recently? I added a bunch of trcs to see what gets quiesced when.
Mind you there may not be a non-.kids owning test anywhere in there, or even anything that verifies that the .kids are getting quiesced, but your report above of "I just saw that not-to-be did not propagate to kids *at all*" does not say /how/ you saw that, so maybe there is still non-propagation which is not being exposed by the test suite and still needs to be cured.
I'd like to provide test cases. Where would be a good place to put them? Then I'd seize the opportunity and merge in my with-assert-observers macrology somewhere :) That would also prove useful to check what gets not-to-be'd.
Thanks, Peter
Ken Tilton wrote:
Peter Hildebrandt wrote:
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.
I hacked up not-to-be a little (tho nothing fundamentally different than what I recall of your efforts which I cannot find in my email), moved cells-store out into its own source file (update your asd!), reran the cells regression test and test-gtk -- everything works.
Mind you there may not be a non-.kids owning test anywhere in there, or even anything that verifies that the .kids are getting quiesced, but your report above of "I just saw that not-to-be did not propagate to kids *at all*" does not say /how/ you saw that, so maybe there is still non-propagation which is not being exposed by the test suite and still needs to be cured.
yep. I think I am seeing it myself. stay tuned.
this is probably, btw, something about load-time vs compile-time, with me propagating :ownings at compile-time and not getting those on a reload... nope, just a total mess from the beginning, hairy rewrite underway.
kt
On Wed, Apr 23, 2008 at 1:45 AM, Ken Tilton kennytilton@optonline.net wrote:
yep. I think I am seeing it myself. stay tuned.
this is probably, btw, something about load-time vs compile-time, with me propagating :ownings at compile-time and not getting those on a reload... nope, just a total mess from the beginning, hairy rewrite underway.
Great, thanks! Btw, I updated the .asd and committed that to CVS. Will work on the test for not-to-be soon.
Peter
Peter Hildebrandt wrote:
On Wed, Apr 23, 2008 at 1:45 AM, Ken Tilton kennytilton@optonline.net wrote:
yep. I think I am seeing it myself. stay tuned.
this is probably, btw, something about load-time vs compile-time, with me propagating :ownings at compile-time and not getting those on a reload... nope, just a total mess from the beginning, hairy rewrite underway.
Great, thanks! Btw, I updated the .asd and committed that to CVS. Will work on the test for not-to-be soon.
Great. The good news is that I accidentally started with a test case: I was having yet another one of those errors I may have mentioned when a math problem step holds the keyboard focus and I delete the problem. I ended up tracing not-to-be and noticed what you had just reported (small world) about not-to-be so took a break to fix that.
Focus problem went away. :)
kt
-
Ken Tilton -
Peter Hildebrandt