#1's definitely our bug. We're caching the lookup of __init__ from Real and invoking that instead of doing the lookup each time. It should be easy enough to fix. I've opened a bug (23555 - http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=23555)
#2 I'd guess could be either that for some reason we're failing to detect the presence of __del__ or that when we run the finalizer cleanup that we believe it's part of cyclic trash and don't think we should cleanup. Of those I'd think it'd be the cyclic trash detection that'd be most likely to go wrong. I'd suggest putting a break point or some logging in PythonOps.InitializeForFinalization and in WeakRefTracker's finalizer and see what's happening there. As for CodePlex I guess you can't even open a bug to complain to CodePlex :(. If you want to send us your browser/OS info we could open a bug for you against CodePlex. You could also try the old heavy hammer of clearing cookies as maybe CodePlex has built up some bad browser state. You could also try using TeamExplorer to open the bugs but I'm not sure if you'll have permissions there to do that or not. > -----Original Message----- > From: users-boun...@lists.ironpython.com [mailto:users- > boun...@lists.ironpython.com] On Behalf Of William Reade > Sent: Monday, July 20, 2009 9:38 AM > To: Discussion of IronPython > Subject: [IronPython] object lifecycle issues > > Hi all > > I have two problems that are at least somewhat related: > > +++ Issue 1 (probably your bug): > > --------------------------------------------------------------- > C:\dev\ironclad - Copy>ipy y.py > real new > stub new > real init > real del > > C:\dev\ironclad - Copy>python y.py > real new > stub new > stub init > real del > --------------------------------------------------------------- > > I freely admit that the attached code is pretty weird, but I really do > need to do stuff like this in Ironclad. The difference in behaviour may > or may not be responsible for certain failing numpy/scipy tests -- I'm > not sure how to tell -- but I'd enormously appreciate a fix. > > I'd report the issue on Codeplex, but trying to visit the issue tracker > just leaves my browser spinning forever. Speaking of which: is there > any alternative way of reporting bugs that doesn't make me feel as if > I'm spamming the list with out-of-band noise? I'm pretty sure that a > few bugs have just dropped off my stack in the last few months, just > because I got tired of waiting for Codeplex to start working. > > +++ Issue 2 (almost certainly my bug): > > In a nearly identical* situation -- close enough that I can't say how > it's actually different -- f will never get its __del__ method called > (the object is destroyed -- a WeakReference to it knows it's dead -- > but the __del__ call never happens). > > For context: I have *very* similar classes, whose instances are > constructed in exactly the weird way demonstrated in the attached file, > and which work fine. The only difference between the cases that work > and the cases that don't is that the broken cases multiply inherit from > ipy types which wrap CLR types (int and float (and maybe str, although > I haven't tested that one)), while the working cases have simple chains > of single inheritance from user-defined types all the way up to object. > However, the attached repro doesn't show my problem, so it's clearly > not > *just* to do with multiply inheriting from CLR types. > > Does anyone have any idea what I might be doing wrong? I know this is a > vague request, but I'm running out of ideas, and I'd really appreciate > some input from someone who understands precisely what all those ipy > MetaFoo classes are doing. > > Cheers > william > > > * the attached file started life as an attempt to repro the __del__ > issue, and I incidentally noticed the __init__ issue. _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
