nav_button bug and hook problems
nav_buttons had a bug such that the marks dialog box was not being populated when a leo file was opened. I fixed this on the trunk. While I was investigating this bug I put a trace on the update method and discovered that when I closed the file and reopened it, it was not only receiving hooks that it had registered for, but also for hooks registered by its previous incarnation. Every time I closed the test file and re-opened it , it got an extra set of callbacks. It appears that the references held by the hook manager was keeping the callbacks (and everything THEY referenced) alive after the frame and its commander disposed of. This obviously prevented dead objects being garbage collected and caused dead code to be invoked. In this situation probably none of this really matters but it is obviously undesirable behavior. I have got around this by introducing module level callback for hooks which dispatch to the appropriate per commander controller. Only one set of hook handlers are ever registered. I am not sure how much this problem is worth worrying about, but I thought you ought to be aware of it. A long term solution may be to use pyDispatcher and translate doHook and registerHook calls to this. It should be possible to do this transparently and so without effecting the current api or code. Only code using the hook tables directly would be effected. Bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: nav_button bug and hook problems
On Sun, Apr 13, 2008 at 5:07 AM, bobjack <[EMAIL PROTECTED]> wrote: > > nav_buttons had a bug such that the marks dialog box was not being > populated when a leo file was opened. I fixed this on the trunk. > > While I was investigating this bug I put a trace on the update method > and discovered that when I closed the file and reopened it, it was not > only receiving hooks that it had registered for, but also for hooks > registered by its previous incarnation. > > Every time I closed the test file and re-opened it , it got an extra > set of callbacks. > > It appears that the references held by the hook manager was keeping > the callbacks (and everything THEY referenced) alive after the frame > and its commander disposed of. This obviously prevented dead objects > being garbage collected and caused dead code to be invoked. In this > situation probably none of this really matters but it is obviously > undesirable behavior. > > I have got around this by introducing module level callback for hooks > which dispatch to the appropriate per commander controller. Only one > set of hook handlers are ever registered. > > I am not sure how much this problem is worth worrying about, but I > thought you ought to be aware of it. It's a real problem. Thanks for this report. Iirc, I fixed something similar in a plugin awhile back. I guess I got distracted, because I just fixed it in one place. > A long term solution may be to use pyDispatcher and translate doHook > and registerHook calls to this. It should be possible to do this > transparently and so without effecting the current api or code. Only > code using the hook tables directly would be effected. Interesting. Are you volunteering? BTW, I never heard of pyDispatcher. Time to google... Edward --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: nav_button bug and hook problems
On Sun, Apr 13, 2008 at 4:57 PM, Edward K. Ream <[EMAIL PROTECTED]> wrote: I never heard of pyDispatcher. Time to google... > It looks like pyDispatcher is highly rated. It's definitely worth looking at. It could have even more important uses within Leo: there are many places where a listener/broadcaster framework might simplify event handling. Something I've considered before, and then got distracted :-) EKR --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: nav_button bug and hook problems
> > A long term solution may be to use pyDispatcher and translate doHook > > and registerHook calls to this. It should be possible to do this > > transparently and so without effecting the current api or code. Only > > code using the hook tables directly would be effected. > > Interesting. Are you volunteering? I\ve got my hands full at the moment but I would certainly like to have pyDispatcer availiable in leo and if no one else tackles it I'll start a feature branch in a couple of weeks. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
