It might be this week, it might be next week - I'm currently doing some perf tuning for the DLR team and am queueing up a bunch of bugs to fix in a single day or two.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William Reade Sent: Monday, September 29, 2008 10:50 AM To: Discussion of IronPython Subject: Re: [IronPython] blocker: objects deleted when they shouldn't be Thanks Dino :) Can you suggest an approximate ETA for a fix? I don't want to hassle you, but I'm very keen to get numpy matrices working and would really appreciate a guess -- even if it's wildly wrong, it still gives me a framework to work within ;). Cheers William Dino Viehland wrote: > Very cool bug and great analysis - thanks for reporting this. BTW That code > lives in MetaPythonType.Calls now. > > It seems like this logic needs to be moved into PythonType.CreateInstance > instead instead of in the generated rule code. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William Reade > Sent: Monday, September 29, 2008 7:11 AM > To: users@lists.ironpython.com > Subject: [IronPython] blocker: objects deleted when they shouldn't be > > Hi all > > I'm about to file this on Codeplex, but I think I've tracked down a > subtle and nasty bug, which is blocking Ironclad with numpy (it fatally > breaks matrices and masked arrays), and I feel compelled to shout loudly > about it to ensure it doesn't get lost in the noise of the impending 2.0 > release. > > In short, the following code: > ------------------------------------------------------------- > from System import GC > > class C(object): > _instance = None > def __new__(cls): > if C._instance is None: > C._instance = object.__new__(cls) > return C._instance > > def __del__(self): > print 'deleting object with id', id(self) > > c = C() > print 'created a C with id', id(c) > d = C() > print 'created another C with id', id(d) > > for _ in range(3): > GC.Collect() > GC.WaitForPendingFinalizers() > > print id(c), id(d) > print c > print d > ------------------------------------------------------------- > > ...produces the following output: > ------------------------------------------------------------- > C:\dev\ironclad\build>ipy deltest.py > created a C with id 43 > created another C with id 43 > deleting object with id 43 > 43 43 > <C object at 0x000000000000002B> > <C object at 0x000000000000002B> > ------------------------------------------------------------- > > ...and I don't think that the 'deleting...' message should be printed at > that point. > > My suspicion is that c's 'magic_finalization_wossname'* slot is being > overwritten with a new instance after __new__ returns, leaving the > original 'magic_finalization_wossname' unreferenced; in the fullness of > time, that gets finalized and calls c.__del__, even though c itself > still exists. > > Cheers > William > > * This is probably not the actual member name, but I couldn't find the > relevant code today, even though I remember reading it in the past... > hopefully the implementers know what I'm trying to refer to, even if > nobody else does. > _______________________________________________ > Users mailing list > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com