Re: [Numpy-discussion] Ticket review: #848, leak in PyArray_DescrFromType

2008-07-20 Thread Michael Abbott
Travis, thank you for your encouraging words. On Sat, 19 Jul 2008, Travis E. Oliphant wrote: Really this code grew from a simple thing into a complicated thing as more features were added. This is a common issue that happens all over the place. Aye. The reason I say I'm not sure is that

Re: [Numpy-discussion] Ticket review: #848, leak in PyArray_DescrFromType

2008-07-20 Thread Michael Abbott
On Sun, 20 Jul 2008, Stéfan van der Walt wrote: 2008/7/20 Michael Abbott [EMAIL PROTECTED]: C, then C++ (which I now regard as a serious mistake) and finally shell It's scary how many of us were scarred for life by C++. What's really annoying for me is that my most recent big project (http

Re: [Numpy-discussion] Ticket review: #848, leak in PyArray_DescrFromType

2008-07-19 Thread Michael Abbott
On Fri, 18 Jul 2008, Travis E. Oliphant wrote: It looks like with that added DECREF, the reference count leak is gone. I've looked at the latest head, and I agree that the problem is now solved. There is an important difference from my original solution: typecode is no longer reused after

Re: [Numpy-discussion] Ticket review: #843

2008-07-16 Thread Michael Abbott
On Wed, 16 Jul 2008, Alan G Isaac wrote: On Wed, 16 Jul 2008, Charles R Harris apparently wrote: Michael Abbott actually wrote: Hard tab characters are fortunately relatively rare in numpy source http://www.rizzoweb.com/java/tabs-vs-spaces.html Ha ha ha! I'm not going to rise

[Numpy-discussion] Ticket review: #843

2008-07-15 Thread Michael Abbott
I'm reviewing my tickets (seems a good thing to do with a release imminent), and I'll post up each ticket that merits comment as a separate message. Ticket #843 has gone into trunk (commit 5361, oliphant) ... but your editor appears to be introducing hard tabs! Hard tab characters are

[Numpy-discussion] Ticket review: #848, leak in PyArray_DescrFromType

2008-07-15 Thread Michael Abbott
Only half of my patch for this bug has gone into trunk, and without the rest of my patch there remains a leak. Furthermore, it remains necessary to perform an extra INCREF on typecode before calling PyArray_FromAny ... as otherwise there is the real possibility that typecode will have

[Numpy-discussion] Ticket review #850: leak in _strings_richcompare

2008-07-15 Thread Michael Abbott
This one is easy, ought to go in. Fixes a (not particularly likely) memory leak. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Ticket review #849: reference to deallocated object?

2008-07-15 Thread Michael Abbott
Tenuous but easy fix, and conformant to style elsewhere. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Ticket review: #848, leak in PyArray_DescrFromType

2008-07-15 Thread Michael Abbott
On Tue, 15 Jul 2008, Michael Abbott wrote: Only half of my patch for this bug has gone into trunk, and without the rest of my patch there remains a leak. I think I might need to explain a little more about the reason for this patch, because obviously the bug it fixes was missed the last time

Re: [Numpy-discussion] Missing NULL return checks?

2008-07-12 Thread Michael Abbott
PyArray_DescrFromType can return NULL Yah, you noticed ;) Yet it is unchecked in several places: Pity about that. Easy enough to fix though -- just don't lose track of ref counts. In fact, I've already submitted a patch to this function (but not addressing this issue). static int

Re: [Numpy-discussion] Another reference count leak: ticket #848

2008-07-09 Thread Michael Abbott
There are three separate patches in this message plus some remarks on stealing reference counts at the bottom. On Tue, 8 Jul 2008, Travis E. Oliphant wrote: Michael Abbott wrote: On Tue, 8 Jul 2008, Travis E. Oliphant wrote: The first part of this patch is good. The second is not needed

Re: [Numpy-discussion] Another reference count leak: ticket #848

2008-07-09 Thread Michael Abbott
On Wed, 9 Jul 2008, Michael Abbott wrote: Well then, I need to redo my patch. Here's the new patch for ..._arrtype_new: I'm sorry about this, I posted too early. Here is the final patch (and I'll update the ticket accordingly). commit a1ff570cbd3ca6c28f87c55cebf2675b395c6fa0 Author

[Numpy-discussion] Another reference count leak: ticket #848

2008-07-08 Thread Michael Abbott
Author: Michael Abbott [EMAIL PROTECTED] Date: Tue Jul 8 10:10:59 2008 +0100 Another reference leak using PyArray_DescrFromType This change fixes two issues: a spurious ADDREF on a typecode returned from PyArray_DescrFromType and a return path with no DECREF. diff --git a/numpy/core

[Numpy-discussion] Python ref count leak in numpy

2008-07-04 Thread Michael Abbott
in revision 2575 in June '06, over two years ago -- I'm a little surprised this hasn't been discovered already. commit ea66a7ee65e1ae855bbc432a48eb1f48176a85d9 Author: Michael Abbott [EMAIL PROTECTED] Date: Fri Jul 4 12:08:24 2008 +0100 Fix memory leak in PyArray_CanCoerceScalar

Re: [Numpy-discussion] Python ref count leak in numpy

2008-07-04 Thread Michael Abbott
On Fri, 4 Jul 2008, Pauli Virtanen wrote: Fri, 04 Jul 2008 11:51:19 +, Michael Abbott wrote: I hope this is going to the right place. I've tried to submit a Trac ticket at http://projects.scipy.org/scipy/numpy/ but unfortunately it won't let me log in, even though I've registered

Re: [Numpy-discussion] Python ref count leak in numpy

2008-07-04 Thread Michael Abbott
On Fri, 4 Jul 2008, Charles R Harris wrote: Curiously, you didn't find the root page: http://www.scipy.org/. At the top there are icons that link to all the things you were looking for. I blame Google ;) Ah, yes. That's where the text I was looking for was: You only need to

Re: [Numpy-discussion] Python ref count leak in numpy

2008-07-04 Thread Michael Abbott
On Fri, 4 Jul 2008, Pauli Virtanen wrote: Fri, 04 Jul 2008 20:06:52 +, Michael Abbott wrote: You only need to [register] once (i.e, SciPy and NumPy Developer Pages use the same login/password). Hmm, I'm not sure if I was correct in claiming that two registrations