memory leaks, 0.54.1 with .2a modifications

John, I am using pygtk2.2, built and installed from the

    > tarball on top of my existing pygtk2.0, which was installed
    > from rpm.

    > The problem does not seem to be inevitable with pygtk
    > plotting; testing I have done so far with pyStripchart 0.0.7
    > (http://jstripchart.sourceforge.net), also with pygtk2.2,
    > has given no indication of a leak. It is a much more
    > specialized (hence simpler) package, though. It draws
    > directly to a DrawingArea instead of using a Pixmap.

Hi Eric, I spent a good bit of time working on the memory leak
problem. It turns out there were numerous problems in both the
transforms module and the ft2font module, which affect all backends.
I've got the former entirely cleared up, and the latter almost done.
I'm writing some unit tests to check for leaks as I go. In the next
day or so I should have a snapshot ready for you to test.

So while there may still be a small problem with pygtk >2.0, I'm not
aware of it. I think the major problems rest squarely on the
shoulders of yours truly.

I wrote the transforms module using CXX, which is a C++ python
extension building library that handles most of the nasty bits for
you, including reference counting. But I was too reliant on it, and
there were some subtleties that I was neglecting involved with
managing reference counts when new pointers are allocated on the heap
and stored in other classes. Fortunately it was a fairly easy fix and
now the transforms are not leaking any detectable memory.

The ft2font module was another matter, since I had written that by
hand. I decided the best way to get this in tip-top shape was to also
rewrite this using CXX, rather than work out all of the intricacies of
reference counting myself. That was a bit more work, but I'm mostly
done. I found one very small leak in the freetype library itself, but
a little searching on the devel list shows that it is fixed in CVS >2.1.8.
But this is only a few bytes per font instance (which are cached and
reused by matplotlib) so this shouldn't present any troubles.

When I get everything cleaned up I'll put together some before and
after numbers from my unit tests.

Hope all is well at sea!

JDH

John,

Thanks very much. If you would like me to try the new snapshot, and it is ready soon enough, let me know what the email attachment size would be, if it would exceed about 100k. There is a limit on email size going to the ship, but it can be relaxed if I know in advance that something is coming.

I have encountered surprisingly large differences between Numeric and numarray:
  pcolor_demo2.py takes about 3 seconds with Numeric, 80 seconds with numarray.
In tests of non-plotting operations, I have generally found numarray faster.

The cruise is going fine. Weather was a bit rough off New Zealand but I expect it will be fairly smooth from here on. This is a Small Waterplane Area Twin Hull (SWATH) ship, so it rides better than most; it is a little like a catamaran on stilts, with most of the buoyancy in fully submerged pontoons.

Eric
...

···

When I get everything cleaned up I'll put together some before and
after numbers from my unit tests.

Hope all is well at sea!

JDH