matplotlib-devel Mailing List for matplotlib (Page 2)

On 12/14/10 11:25 PM, Ludwig Schwardt wrote:
> - The only GUI backends worth building on Mac OS X are TkAgg and the
> native macosx one, in my humble opinion.
wx works just fine on OS-X, though I'm pretty sure it's no longer a 
build-time dependency (no compiled code)
> - I have been successfully using the Apple "system" Python since Mac
> OS 10.5 to run numpy/scipy/matplotlib/ipython and never encountered
> any major build or usage problems. I agree that Mac OS 10.4 and
> earlier needed a Python reinstallation, but do not see why it is
> currently still a strong requirement.
I'm not sure how strong, and I don't know about numpy issues, but there 
are some other key issues:
1) not a native readline
2) Apple has NEVER updated any of their Python installs
3) You can't re-distribute it (py2app)
4) I thought there was a TK issue, but I'm not a TK user.
5) It'll only work on a given OS-X version (i.e. you can't distribute a 
binary that will work on multiple versions of OS-X -- at least not older 
ones)
Anyway, for years, the MacPython community has tried to establish a 
standard for the binaries that people build -- Python on the Mac is 
something of a nightmare, what with Apple's Python, python.org's build, 
fink, macports, etc....
The ONLY reasonable versions to build binaries for are the python.org 
builds, unless you want to build a LOT of different binaries. Note that 
Robin Dunn has managed to build wxPython binaries that work on both 
python.org and Apple pythons -- neat trick, that -- but not many people 
seem to want to do that kludge.
> As improved documentation I can contribute (yet another :-)) tutorial
> for building and installing matplotlib and friends on a clean Mac OS
> 10.6 system, with a minimum of downloaded packages and using the
> standard system stuff as far as possible.
That would still be nice -- I'm still not sure if you can count on X11 
being installed, though -- do you know?
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Hi,
Weighing in on the Mac build issue:
- The only GUI backends worth building on Mac OS X are TkAgg and the
native macosx one, in my humble opinion. Sticking to them will prevent
the kind of pain Kynn described. These backends are autodetected by
default during the build process and you only land in trouble if you
explicitly enable the rest. My suggestion is therefore to do the
default "python setup.py install".
- I have been successfully using the Apple "system" Python since Mac
OS 10.5 to run numpy/scipy/matplotlib/ipython and never encountered
any major build or usage problems. I agree that Mac OS 10.4 and
earlier needed a Python reinstallation, but do not see why it is
currently still a strong requirement. Ben, do you know off-hand what
issues numpy has been having with Apple Python?
As improved documentation I can contribute (yet another :-)) tutorial
for building and installing matplotlib and friends on a clean Mac OS
10.6 system, with a minimum of downloaded packages and using the
standard system stuff as far as possible. I fine-tuned the
instructions on several iMacs at work. I will just check that it still
works with the latest packages.
Regards,
Ludwig
> Message: 4
> Date: 2010年11月18日 16:57:10 -0600
> From: Benjamin Root <ben...@ou...>
>
> There are a variety of issues depending on your Mac system that needs to be
> sorted out to determine the best way to go about installing everything. The
> particular sticking point is that Apple supplied their own interperater
> rather than the standard python interpreater. Unfortunately, this causes
> problems with numpy (and thus matplotlib).

On Tue, Dec 14, 2010 at 5:26 PM, Russell Owen <ro...@uw...> wrote:
> On Dec 14, 2010, at 2:38 PM, Benjamin Root wrote:
>
> On Tue, Dec 14, 2010 at 4:22 PM, Benjamin Root <ben...@ou...> wrote:
>
>>
>>
>> On Tue, Dec 14, 2010 at 4:06 PM, Russell Owen <ro...@uw...> wrote:
>>
>>> On Dec 14, 2010, at 1:50 PM, Benjamin Root wrote:
>>>
>>> On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen <ro...@uw...> wrote:
>>>
>>>> I tried the test script on linux using matplotlib svn trunk rev8840
>>>> (which appears to include your patch) and found a leak that starts out
>>>> small but gets systematically larger. This is with Python 2.6.5 and
>>>> Tkinter built against Tcl/Tk 8.4.13.
>>>>
>>>> Is anyone else seeing this?
>>>>
>>>> time rss memory mem/sec
>>>> (sec) (kb) (kb/sec)
>>>> 0.0 36816 nan
>>>> 5.0 36860 nan
>>>> 10.0 36860 0.0
>>>> 15.1 36860 0.0
>>>> 20.1 36860 0.0
>>>> 25.1 36896 1.8
>>>> ...
>>>> 326.5 36896 0.1
>>>> 331.6 36972 0.3
>>>> ...
>>>> 401.9 36972 0.3
>>>> 406.9 36980 0.3
>>>> ...
>>>>
>>>> 602.8 37684 1.4
>>>> 607.8 37700 1.4
>>>>
>>>> This is different behavior than on Mac OS X, but still alarming.
>>>>
>>>> -- Russell
>>>>
>>>>
>>> Russell,
>>>
>>> I am curious, I recently ran into problems with mixing builds of numpy
>>> and matplotlib at various levels of revisions. I eventually had to do a
>>> complete clean rebuild. Note, what I mean by a complete clean rebuild is
>>> that I removed the numpy and matplotlib source directories and re-checkout
>>> the codes from source and then rebuild. I would be curious if the problem
>>> persists after that.
>>>
>>>
>>> An interesting question. I can say that this was a clean build of
>>> matplotlib since I ran it "in place" (in build/lib.linux-x86_64-2.6/) after
>>> building it rather than installing it in site-packages to avoid messing up
>>> other users (on the linux system this was a shared python). I modified the
>>> script to print matplotlib.__file__ to make sure I was running the right
>>> version. I doubt it was a clean build of numpy. But considering no numerics
>>> are occurring in this example (it is literally just creating an Axes on a
>>> Canvas and calling canvas.draw() repeatedly) do you think numpy could
>>> possibly come into this?
>>>
>>>
>> It is quite possible. Numpy is used extensively throughout the matplotlib
>> system, regardless of whether you are using it or not. Also, the fact that
>> you are on a shared system is interesting. For those situations, try doing
>>
>> "python setupegg.py develop --user"
>>
>> for the build command. What this does is builds everything in-place (the
>> build directory symbolically links to those files), and then uses your
>> ~/.local directory to install an egg.lnk file to point back to the build
>> directory. This should have higher search precedence than the system
>> install of matplotlib and numpy.
>>
>> Note, I had mixed success with this approach on a RHEL (5?) system
>> recently. I don't know how recently ~/.local became widely accepted among
>> various distros.
>>
>>
>>> Might you run the script on your system with the clean build?
>>>
>>> -- Russell
>>>
>>>
>> I will give it a shot (once my other analysis programs are done for the
>> day).
>>
>> Ben Root
>>
>
> I ran your script from the url you posted earlier. My build does not show
> any leak for about a minute. I am fairly certain that what we have here is
> a build mixing issue or an issue with an unknown combination of libraries
> interacting. Could you post your build logs?
>
> Ben Root
>
>
> I tried your suggestion -- installing numpy from scratch (deleting the old
> numpy first) and then building matplotlib fresh. Here are my build logs:
> <http://www.astro.washington.edu/users/rowen/python/numpy_build_log.txt>
> <
> http://www.astro.washington.edu/users/rowen/python/matplotlib_build_log.txt
> >
>
> Much like last time (with a fresh matplotlib) the test program shows no
> leak at first, then it starts growing to alarming levels (though it took
> longer to start leaking this time than it did last time):
>
>
Interesting behavior to report. I did a completely clean rebuild on my
other computer (Ubuntu 10.10) and the first matplotlib-related program that
was used was this memory check program. It exhibited a memory leak for the
very first run. However, after ending that program and starting it back up,
the memory levels were lower and very steady.
I also noticed for the runs where the memory levels were steady, I could
make the memory levels go slightly up if I interacted with the figure window
(moving it and such).
I did do a long run (600+ seconds) and I did get a memory leak at around 600
second mark. I did *not* have the same problem, though, where the next run
exhibits an immediate memory leak. Instead, the memory levels were
consistent with previous runs.
I will take a peek at your build logs tomorrow. There is something fishy
happening, but I am not convinced that it is entirely an issue with
matplotlib (although that first run behavior is bad...).
Ben Root

On Dec 14, 2010, at 2:38 PM, Benjamin Root wrote:
> On Tue, Dec 14, 2010 at 4:22 PM, Benjamin Root <ben...@ou...> 
> wrote:
>
>
> On Tue, Dec 14, 2010 at 4:06 PM, Russell Owen <ro...@uw...> wrote:
> On Dec 14, 2010, at 1:50 PM, Benjamin Root wrote:
>
>> On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen <ro...@uw...> 
>> wrote:
>> I tried the test script on linux using matplotlib svn trunk rev8840
>> (which appears to include your patch) and found a leak that starts 
>> out
>> small but gets systematically larger. This is with Python 2.6.5 and
>> Tkinter built against Tcl/Tk 8.4.13.
>>
>> Is anyone else seeing this?
>>
>> time rss memory mem/sec
>> (sec) (kb) (kb/sec)
>> 0.0 36816 nan
>> 5.0 36860 nan
>> 10.0 36860 0.0
>> 15.1 36860 0.0
>> 20.1 36860 0.0
>> 25.1 36896 1.8
>> ...
>> 326.5 36896 0.1
>> 331.6 36972 0.3
>> ...
>> 401.9 36972 0.3
>> 406.9 36980 0.3
>> ...
>>
>> 602.8 37684 1.4
>> 607.8 37700 1.4
>>
>> This is different behavior than on Mac OS X, but still alarming.
>>
>> -- Russell
>>
>>
>> Russell,
>>
>> I am curious, I recently ran into problems with mixing builds of 
>> numpy and matplotlib at various levels of revisions. I eventually 
>> had to do a complete clean rebuild. Note, what I mean by a 
>> complete clean rebuild is that I removed the numpy and matplotlib 
>> source directories and re-checkout the codes from source and then 
>> rebuild. I would be curious if the problem persists after that.
>
> An interesting question. I can say that this was a clean build of 
> matplotlib since I ran it "in place" (in build/lib.linux- 
> x86_64-2.6/) after building it rather than installing it in site- 
> packages to avoid messing up other users (on the linux system this 
> was a shared python). I modified the script to print 
> matplotlib.__file__ to make sure I was running the right version. I 
> doubt it was a clean build of numpy. But considering no numerics are 
> occurring in this example (it is literally just creating an Axes on 
> a Canvas and calling canvas.draw() repeatedly) do you think numpy 
> could possibly come into this?
>
>
> It is quite possible. Numpy is used extensively throughout the 
> matplotlib system, regardless of whether you are using it or not. 
> Also, the fact that you are on a shared system is interesting. For 
> those situations, try doing
>
> "python setupegg.py develop --user"
>
> for the build command. What this does is builds everything in-place 
> (the build directory symbolically links to those files), and then 
> uses your ~/.local directory to install an egg.lnk file to point 
> back to the build directory. This should have higher search 
> precedence than the system install of matplotlib and numpy.
>
> Note, I had mixed success with this approach on a RHEL (5?) system 
> recently. I don't know how recently ~/.local became widely accepted 
> among various distros.
>
> Might you run the script on your system with the clean build?
>
> -- Russell
>
>
> I will give it a shot (once my other analysis programs are done for 
> the day).
>
> Ben Root
>
> I ran your script from the url you posted earlier. My build does 
> not show any leak for about a minute. I am fairly certain that what 
> we have here is a build mixing issue or an issue with an unknown 
> combination of libraries interacting. Could you post your build logs?
>
> Ben Root
>
I tried your suggestion -- installing numpy from scratch (deleting the 
old numpy first) and then building matplotlib fresh. Here are my build 
logs:
<http://www.astro.washington.edu/users/rowen/python/numpy_build_log.txt>
<http://www.astro.washington.edu/users/rowen/python/matplotlib_build_log.txt 
 >
Much like last time (with a fresh matplotlib) the test program shows 
no leak at first, then it starts growing to alarming levels (though it 
took longer to start leaking this time than it did last time):
matplotlib.__file__= /astro/users/rowen/build/matplotlib-trunk/build/ 
lib.linux-x86_64-2.6/matplotlib/__init__.py
time rss memory mem/sec
(sec) (kb) (kb/sec)
 0.0 36860 nan
 5.1 36904 nan
 10.1 36904 0.0
 15.1 36904 0.0
 20.2 36904 0.0
 25.2 36904 0.0
 30.2 36904 0.0
 35.2 36904 0.0
 40.2 36904 0.0
 45.2 36904 0.0
 50.3 36904 0.0
 55.3 36904 0.0
 60.3 36904 0.0
 65.4 36904 0.0
 70.4 36904 0.0
 75.4 36904 0.0
 80.4 36904 0.0
 85.4 36904 0.0
 90.5 36904 0.0
 95.5 36904 0.0
 100.5 36976 0.8
 105.5 36976 0.7
 110.6 36976 0.7
 115.6 36976 0.7
 120.6 36976 0.6
 125.6 36976 0.6
 130.7 36976 0.6
 135.7 36976 0.6
 140.7 36976 0.5
 145.7 36976 0.5
 150.8 36976 0.5
 155.8 36976 0.5
 160.8 36976 0.5
 165.8 36976 0.4
 170.9 36976 0.4
 175.9 36976 0.4
 180.9 36976 0.4
 185.9 36976 0.4
 190.9 36976 0.4
 196.0 36976 0.4
 201.0 36976 0.4
 206.0 36976 0.4
 211.0 36976 0.3
 216.1 36976 0.3
 221.1 36976 0.3
 226.1 36976 0.3
 231.1 36976 0.3
 236.1 36976 0.3
 241.2 36976 0.3
 246.2 36976 0.3
 251.2 36976 0.3
 256.3 36976 0.3
 261.3 36976 0.3
 266.3 36976 0.3
 271.4 36976 0.3
 276.4 36976 0.3
 281.4 36976 0.3
 286.5 36976 0.3
 291.5 36976 0.3
 296.6 36976 0.2
 301.6 36976 0.2
 306.6 36976 0.2
 311.6 36976 0.2
 316.6 36976 0.2
 321.6 36976 0.2
 326.7 36976 0.2
 331.7 37048 0.4
 336.7 37048 0.4
 341.7 37048 0.4
 346.8 37048 0.4
 351.8 37048 0.4
 356.8 37048 0.4
 361.8 37048 0.4
 366.8 37048 0.4
 371.8 37048 0.4
 376.9 37048 0.4
 381.9 37048 0.4
 386.9 37048 0.4
 391.9 37048 0.4
 397.0 37048 0.4
 402.0 37048 0.4
 407.0 37072 0.4
 412.0 37084 0.4
 417.1 37108 0.5
 422.1 37124 0.5
 427.1 37144 0.6
 432.1 37156 0.6
 437.2 37180 0.6
 442.2 37196 0.7
 447.2 37216 0.7
 452.2 37228 0.7
 457.2 37248 0.8
 462.3 37264 0.8
 467.3 37284 0.8
 472.3 37300 0.8
 477.3 37320 0.9
 482.3 37336 0.9
 487.4 37356 0.9
 492.4 37372 1.0
 497.4 37392 1.0
 502.4 37404 1.0
 507.4 37424 1.0
 512.5 37444 1.1
 517.5 37460 1.1
 522.5 37476 1.1
 527.6 37496 1.1
 532.6 37512 1.2
 537.6 37532 1.2
 542.6 37548 1.2
 547.6 37568 1.2
 552.6 37584 1.2
 557.7 37604 1.3
 562.7 37620 1.3
 567.7 37636 1.3
 572.8 37652 1.3
 577.8 37676 1.3
 582.9 37688 1.4
 587.9 37708 1.4
 593.0 37724 1.4
 598.0 37744 1.4
 603.0 37760 1.4
 608.0 37780 1.5
 613.0 37796 1.5
 618.1 37816 1.5
 623.1 37828 1.5
 628.1 37848 1.5
 633.2 37864 1.5
 638.2 37884 1.5
 643.3 37904 1.6
 648.3 37920 1.6
 653.4 37936 1.6
 658.4 37956 1.6
 663.4 37972 1.6
 668.4 37992 1.6
(control-C to stop it)
Also like last time (though I did not report this before since I had 
not yet discovered it) once this has occurred the honeymoon is over. 
Leakage is high right from the beginning. It appears that something is 
being cached that causes trouble, but I have no idea what. Here is a 
log from a run immediately after the previous run:
-bash-3.2$ python matplotlibMemoryLeak.py
matplotlib.__file__= /astro/users/rowen/build/matplotlib-trunk/build/ 
lib.linux-x86_64-2.6/matplotlib/__init__.pyc
time rss memory mem/sec
(sec) (kb) (kb/sec)
 0.0 33892 nan
 5.0 34168 nan
 10.1 34188 4.0
 15.1 34228 6.0
 20.1 34248 5.3
 25.1 34284 5.8
 30.2 34300 5.2
 35.2 34320 5.0
 40.2 34400 6.6
Might you try running your test for much longer to see if the program 
starts leaking for you?
-- Russell

On Tue, Dec 14, 2010 at 4:22 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Tue, Dec 14, 2010 at 4:06 PM, Russell Owen <ro...@uw...> wrote:
>
>> On Dec 14, 2010, at 1:50 PM, Benjamin Root wrote:
>>
>> On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen <ro...@uw...> wrote:
>>
>>> I tried the test script on linux using matplotlib svn trunk rev8840
>>> (which appears to include your patch) and found a leak that starts out
>>> small but gets systematically larger. This is with Python 2.6.5 and
>>> Tkinter built against Tcl/Tk 8.4.13.
>>>
>>> Is anyone else seeing this?
>>>
>>> time rss memory mem/sec
>>> (sec) (kb) (kb/sec)
>>> 0.0 36816 nan
>>> 5.0 36860 nan
>>> 10.0 36860 0.0
>>> 15.1 36860 0.0
>>> 20.1 36860 0.0
>>> 25.1 36896 1.8
>>> ...
>>> 326.5 36896 0.1
>>> 331.6 36972 0.3
>>> ...
>>> 401.9 36972 0.3
>>> 406.9 36980 0.3
>>> ...
>>>
>>> 602.8 37684 1.4
>>> 607.8 37700 1.4
>>>
>>> This is different behavior than on Mac OS X, but still alarming.
>>>
>>> -- Russell
>>>
>>>
>> Russell,
>>
>> I am curious, I recently ran into problems with mixing builds of numpy and
>> matplotlib at various levels of revisions. I eventually had to do a
>> complete clean rebuild. Note, what I mean by a complete clean rebuild is
>> that I removed the numpy and matplotlib source directories and re-checkout
>> the codes from source and then rebuild. I would be curious if the problem
>> persists after that.
>>
>>
>> An interesting question. I can say that this was a clean build of
>> matplotlib since I ran it "in place" (in build/lib.linux-x86_64-2.6/) after
>> building it rather than installing it in site-packages to avoid messing up
>> other users (on the linux system this was a shared python). I modified the
>> script to print matplotlib.__file__ to make sure I was running the right
>> version. I doubt it was a clean build of numpy. But considering no numerics
>> are occurring in this example (it is literally just creating an Axes on a
>> Canvas and calling canvas.draw() repeatedly) do you think numpy could
>> possibly come into this?
>>
>>
> It is quite possible. Numpy is used extensively throughout the matplotlib
> system, regardless of whether you are using it or not. Also, the fact that
> you are on a shared system is interesting. For those situations, try doing
>
> "python setupegg.py develop --user"
>
> for the build command. What this does is builds everything in-place (the
> build directory symbolically links to those files), and then uses your
> ~/.local directory to install an egg.lnk file to point back to the build
> directory. This should have higher search precedence than the system
> install of matplotlib and numpy.
>
> Note, I had mixed success with this approach on a RHEL (5?) system
> recently. I don't know how recently ~/.local became widely accepted among
> various distros.
>
>
>> Might you run the script on your system with the clean build?
>>
>> -- Russell
>>
>>
> I will give it a shot (once my other analysis programs are done for the
> day).
>
> Ben Root
>
I ran your script from the url you posted earlier. My build does not show
any leak for about a minute. I am fairly certain that what we have here is
a build mixing issue or an issue with an unknown combination of libraries
interacting. Could you post your build logs?
Ben Root

On Tue, Dec 14, 2010 at 4:06 PM, Russell Owen <ro...@uw...> wrote:
> On Dec 14, 2010, at 1:50 PM, Benjamin Root wrote:
>
> On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen <ro...@uw...> wrote:
>
>> I tried the test script on linux using matplotlib svn trunk rev8840
>> (which appears to include your patch) and found a leak that starts out
>> small but gets systematically larger. This is with Python 2.6.5 and
>> Tkinter built against Tcl/Tk 8.4.13.
>>
>> Is anyone else seeing this?
>>
>> time rss memory mem/sec
>> (sec) (kb) (kb/sec)
>> 0.0 36816 nan
>> 5.0 36860 nan
>> 10.0 36860 0.0
>> 15.1 36860 0.0
>> 20.1 36860 0.0
>> 25.1 36896 1.8
>> ...
>> 326.5 36896 0.1
>> 331.6 36972 0.3
>> ...
>> 401.9 36972 0.3
>> 406.9 36980 0.3
>> ...
>>
>> 602.8 37684 1.4
>> 607.8 37700 1.4
>>
>> This is different behavior than on Mac OS X, but still alarming.
>>
>> -- Russell
>>
>>
> Russell,
>
> I am curious, I recently ran into problems with mixing builds of numpy and
> matplotlib at various levels of revisions. I eventually had to do a
> complete clean rebuild. Note, what I mean by a complete clean rebuild is
> that I removed the numpy and matplotlib source directories and re-checkout
> the codes from source and then rebuild. I would be curious if the problem
> persists after that.
>
>
> An interesting question. I can say that this was a clean build of
> matplotlib since I ran it "in place" (in build/lib.linux-x86_64-2.6/) after
> building it rather than installing it in site-packages to avoid messing up
> other users (on the linux system this was a shared python). I modified the
> script to print matplotlib.__file__ to make sure I was running the right
> version. I doubt it was a clean build of numpy. But considering no numerics
> are occurring in this example (it is literally just creating an Axes on a
> Canvas and calling canvas.draw() repeatedly) do you think numpy could
> possibly come into this?
>
>
It is quite possible. Numpy is used extensively throughout the matplotlib
system, regardless of whether you are using it or not. Also, the fact that
you are on a shared system is interesting. For those situations, try doing
"python setupegg.py develop --user"
for the build command. What this does is builds everything in-place (the
build directory symbolically links to those files), and then uses your
~/.local directory to install an egg.lnk file to point back to the build
directory. This should have higher search precedence than the system
install of matplotlib and numpy.
Note, I had mixed success with this approach on a RHEL (5?) system
recently. I don't know how recently ~/.local became widely accepted among
various distros.
> Might you run the script on your system with the clean build?
>
> -- Russell
>
>
I will give it a shot (once my other analysis programs are done for the
day).
Ben Root

On Dec 14, 2010, at 1:50 PM, Benjamin Root wrote:
> On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen <ro...@uw...> wrote:
> I tried the test script on linux using matplotlib svn trunk rev8840
> (which appears to include your patch) and found a leak that starts out
> small but gets systematically larger. This is with Python 2.6.5 and
> Tkinter built against Tcl/Tk 8.4.13.
>
> Is anyone else seeing this?
>
> time rss memory mem/sec
> (sec) (kb) (kb/sec)
> 0.0 36816 nan
> 5.0 36860 nan
> 10.0 36860 0.0
> 15.1 36860 0.0
> 20.1 36860 0.0
> 25.1 36896 1.8
> ...
> 326.5 36896 0.1
> 331.6 36972 0.3
> ...
> 401.9 36972 0.3
> 406.9 36980 0.3
> ...
> 602.8 37684 1.4
> 607.8 37700 1.4
>
> This is different behavior than on Mac OS X, but still alarming.
>
> -- Russell
>
>
> Russell,
>
> I am curious, I recently ran into problems with mixing builds of 
> numpy and matplotlib at various levels of revisions. I eventually 
> had to do a complete clean rebuild. Note, what I mean by a complete 
> clean rebuild is that I removed the numpy and matplotlib source 
> directories and re-checkout the codes from source and then rebuild. 
> I would be curious if the problem persists after that.
An interesting question. I can say that this was a clean build of 
matplotlib since I ran it "in place" (in build/lib.linux-x86_64-2.6/) 
after building it rather than installing it in site-packages to avoid 
messing up other users (on the linux system this was a shared python). 
I modified the script to print matplotlib.__file__ to make sure I was 
running the right version. I doubt it was a clean build of numpy. But 
considering no numerics are occurring in this example (it is literally 
just creating an Axes on a Canvas and calling canvas.draw() 
repeatedly) do you think numpy could possibly come into this?
Might you run the script on your system with the clean build?
-- Russell

On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen <ro...@uw...> wrote:
> I tried the test script on linux using matplotlib svn trunk rev8840
> (which appears to include your patch) and found a leak that starts out
> small but gets systematically larger. This is with Python 2.6.5 and
> Tkinter built against Tcl/Tk 8.4.13.
>
> Is anyone else seeing this?
>
> time rss memory mem/sec
> (sec) (kb) (kb/sec)
> 0.0 36816 nan
> 5.0 36860 nan
> 10.0 36860 0.0
> 15.1 36860 0.0
> 20.1 36860 0.0
> 25.1 36896 1.8
> ...
> 326.5 36896 0.1
> 331.6 36972 0.3
> ...
> 401.9 36972 0.3
> 406.9 36980 0.3
> 411.9 37004 0.4
> 417.0 37016 0.4
> 422.0 37040 0.4
> 427.0 37052 0.5
> 432.0 37076 0.5
> 437.1 37088 0.5
> 442.1 37112 0.6
> 447.1 37124 0.6
> 452.1 37148 0.6
> 457.2 37160 0.7
> 462.2 37184 0.7
> 467.2 37196 0.7
> 472.2 37220 0.8
> 477.3 37232 0.8
> 482.3 37256 0.8
> 487.3 37268 0.8
> 492.3 37292 0.9
> 497.3 37304 0.9
> 502.3 37328 0.9
> 507.4 37340 1.0
> 512.4 37360 1.0
> 517.4 37376 1.0
> 522.4 37396 1.0
> 527.5 37412 1.1
> 532.5 37432 1.1
> 537.5 37448 1.1
> 542.5 37472 1.1
> 547.6 37488 1.2
> 552.6 37504 1.2
> 557.6 37516 1.2
> 562.6 37540 1.2
> 567.6 37556 1.2
> 572.7 37576 1.3
> 577.7 37592 1.3
> 582.7 37612 1.3
> 587.7 37628 1.3
> 592.7 37648 1.3
> 597.8 37664 1.4
> 602.8 37684 1.4
> 607.8 37700 1.4
>
> This is different behavior than on Mac OS X, but still alarming.
>
> -- Russell
>
>
Russell,
I am curious, I recently ran into problems with mixing builds of numpy and
matplotlib at various levels of revisions. I eventually had to do a
complete clean rebuild. Note, what I mean by a complete clean rebuild is
that I removed the numpy and matplotlib source directories and re-checkout
the codes from source and then rebuild. I would be curious if the problem
persists after that.
Ben Root

I tried the test script on linux using matplotlib svn trunk rev8840 
(which appears to include your patch) and found a leak that starts out 
small but gets systematically larger. This is with Python 2.6.5 and 
Tkinter built against Tcl/Tk 8.4.13.
Is anyone else seeing this?
time rss memory mem/sec
(sec) (kb) (kb/sec)
 0.0 36816 nan
 5.0 36860 nan
 10.0 36860 0.0
 15.1 36860 0.0
 20.1 36860 0.0
 25.1 36896 1.8
...
 326.5 36896 0.1
 331.6 36972 0.3
...
 401.9 36972 0.3
 406.9 36980 0.3
 411.9 37004 0.4
 417.0 37016 0.4
 422.0 37040 0.4
 427.0 37052 0.5
 432.0 37076 0.5
 437.1 37088 0.5
 442.1 37112 0.6
 447.1 37124 0.6
 452.1 37148 0.6
 457.2 37160 0.7
 462.2 37184 0.7
 467.2 37196 0.7
 472.2 37220 0.8
 477.3 37232 0.8
 482.3 37256 0.8
 487.3 37268 0.8
 492.3 37292 0.9
 497.3 37304 0.9
 502.3 37328 0.9
 507.4 37340 1.0
 512.4 37360 1.0
 517.4 37376 1.0
 522.4 37396 1.0
 527.5 37412 1.1
 532.5 37432 1.1
 537.5 37448 1.1
 542.5 37472 1.1
 547.6 37488 1.2
 552.6 37504 1.2
 557.6 37516 1.2
 562.6 37540 1.2
 567.6 37556 1.2
 572.7 37576 1.3
 577.7 37592 1.3
 582.7 37612 1.3
 587.7 37628 1.3
 592.7 37648 1.3
 597.8 37664 1.4
 602.8 37684 1.4
 607.8 37700 1.4
This is different behavior than on Mac OS X, but still alarming.
-- Russell
In article <4D0...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:
> If you're able to try this with the 1.0.x SVN branch or the SVN trunk 
> (plus my text patch) let me know. I am not able to reproduce any sort 
> of memory leak with these newer versions, but I am able to with 1.0.0 as 
> released (with or without my text patch). This is with or without the x 
> axis limits updating you suggested. I believe there have been other 
> memory leak fixes since the 1.0.0 release.
> 
> Cheers,
> Mike
> 
> On 12/13/2010 08:35 PM, Russell E. Owen wrote:
> > I also wanted to say:
> > - Thank you for the patch. I appreciate the chance to try a fix.
> > - I doubt the issue is related to text because my scripts shows a memory
> > leak even if the displayed text is never updated (comment out the line
> > that modifies the x axis limits to see what I mean; though I confess I
> > did not try that with the trunk matplotlib, only with 1.0.0).
> >
> > -- Russell
> >
> > In article<4D0...@st...>,
> > Michael Droettboom<md...@st...>
> > wrote:
> >
> > 
> >> I think I'm on to something -- it seems that text layout information has
> >> a cyclical reference that prevents the Text object from being freed.
> >>
> >> Can you apply the attached patch and let me know if it solves your issue?

I already posted results using the svn trunk plus the svn trunk with 
your patch (as well as the 1.0.0 release). I updated them today with a 
few more options (such as your patch without setting the x limit -- it 
didn't make any difference) and letting them run longer. Here they are. 
All are from running 
<http://www.astro.washington.edu/users/rowen/python/matplotlibMemoryLeak.
py> with various lines commented out (listed before the output). All of 
these are on Mac OS X using python.org Python 2.6.6 and TkAgg with 
Tcl/Tk 8.4.19.
I have confirmed the leak on linux using matplotlib 1.0.0 (indeed it is 
even worse on linux than on Mac OS X -- closer to 28kb/sec than 20) but 
have not tried building svn versions on linux.
-- Russell
matplotlib 1.0.0
 self.subplot.set_xlim(tMin, tMax)
# self.subplot.clear()
 self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time rss memory mem/sec
(sec) (kb) (kb/sec)
 0.0 27676 nan
 5.0 28980 nan
 10.1 29084 20.6
 15.1 29172 19.0
 20.1 29268 19.1
 25.2 29368 19.3
 30.2 29464 19.2
 35.2 29564 19.4
 40.2 29660 19.3
 45.2 29764 19.5
...
1521.6 58248 19.3
1526.6 58348 19.3
 self.subplot.set_xlim(tMin, tMax)
 self.subplot.clear()
 self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time rss memory mem/sec
(sec) (kb) (kb/sec)
 0.0 27696 nan
 5.1 29012 nan
 10.2 29152 27.5
 15.2 29292 27.7
 20.2 29436 28.0
 25.3 29580 28.1
 30.4 29728 28.3
 35.4 29876 28.5
 40.5 30024 28.6
 45.5 30160 28.4
 50.6 30308 28.5
matplotlib svn trunk rev8836
 self.subplot.set_xlim(tMin, tMax)
# self.subplot.clear()
 self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time rss memory mem/sec
(sec) (kb) (kb/sec)
 0.0 27664 nan
 5.0 28864 nan
 10.0 28880 3.2
 15.1 28884 2.0
 20.1 28896 2.1
 25.1 28908 2.2
 30.1 28916 2.1
 35.1 28928 2.1
 40.2 28940 2.2
 45.2 28948 2.1
 self.subplot.set_xlim(tMin, tMax)
 self.subplot.clear()
 self.canvas.draw()
time rss memory mem/sec
(sec) (kb) (kb/sec)
 0.0 27684 nan
 5.1 28856 nan
 10.1 28856 0.0
 15.1 28856 0.0
 20.1 28864 0.5
 25.2 28872 0.8
 30.2 28880 1.0
 35.2 28884 0.9
 40.2 28892 1.0
 45.2 28900 1.1
 50.2 28920 1.4
 55.3 28924 1.4
 60.3 28932 1.4
 65.3 28940 1.4
After applying Michael Droettboom's patch to svn trunk rev8836:
--- lib/matplotlib/text.py (revision 8819)
+++ lib/matplotlib/text.py (working copy)
@@ -143,6 +143,9 @@
 Handle storing and drawing of text in window or data coordinates.
 """
 zorder = 3
+
+ cached = maxdict(50)
+
 def __str__(self):
 return "Text(%g,%g,%s)"%(self._y,self._y,repr(self._text))
@@ -168,7 +171,6 @@
 """
 Artist.__init__(self)
- self.cached = maxdict(5)
 self._x, self._y = x, y
 if color is None: color = rcParams['text.color']
 # the preferred code
 self.subplot.set_xlim(tMin, tMax)
# self.subplot.clear()
 self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time rss memory mem/sec
(sec) (kb) (kb/sec)
 0.0 27656 nan
 5.0 28852 nan
 10.1 28864 2.4
 15.1 28876 2.4
 20.1 28888 2.4
 25.1 28908 2.8
 30.1 28916 2.6
 35.1 28924 2.4
 40.2 28936 2.4
...
 803.1 30296 1.8
 808.1 30304 1.8
...
2625.1 33628 1.8
2630.1 33640 1.8
...
4186.1 36476 1.8
4191.2 36488 1.8
...
6228.9 40228 1.8
6233.9 40236 1.8
 self.subplot.set_xlim(tMin, tMax)
 self.subplot.clear()
 self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time rss memory mem/sec
(sec) (kb) (kb/sec)
 0.0 27652 nan
 5.0 28836 nan
 10.0 28852 3.2
 15.1 28852 1.6
 20.1 28872 2.4
 25.1 28880 2.2
 30.1 28900 2.6
 35.1 28904 2.3
 40.2 28912 2.2
 45.2 28920 2.1
 50.3 28928 2.0
# self.subplot.set_xlim(tMin, tMax)
# self.subplot.clear()
 self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time rss memory mem/sec
(sec) (kb) (kb/sec)
 0.0 27636 nan
 5.0 28832 nan
 10.0 28840 1.6
 15.1 28840 0.8
 20.1 28852 1.3
 25.1 28860 1.4
 30.1 28868 1.4
 35.1 28876 1.5
 40.1 28888 1.6
 45.1 28908 1.9
...
 447.0 29620 1.8
 452.1 29628 1.8
...
1180.3 30940 1.8
1185.3 30948 1.8
In article <4D0...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:
> If you're able to try this with the 1.0.x SVN branch or the SVN trunk 
> (plus my text patch) let me know. I am not able to reproduce any sort 
> of memory leak with these newer versions, but I am able to with 1.0.0 as 
> released (with or without my text patch). This is with or without the x 
> axis limits updating you suggested. I believe there have been other 
> memory leak fixes since the 1.0.0 release.
> 
> Cheers,
> Mike
> 
> On 12/13/2010 08:35 PM, Russell E. Owen wrote:
> > I also wanted to say:
> > - Thank you for the patch. I appreciate the chance to try a fix.
> > - I doubt the issue is related to text because my scripts shows a memory
> > leak even if the displayed text is never updated (comment out the line
> > that modifies the x axis limits to see what I mean; though I confess I
> > did not try that with the trunk matplotlib, only with 1.0.0).
> >
> > -- Russell
> >
> > In article<4D0...@st...>,
> > Michael Droettboom<md...@st...>
> > wrote:
> >
> > 
> >> I think I'm on to something -- it seems that text layout information has
> >> a cyclical reference that prevents the Text object from being freed.
> >>
> >> Can you apply the attached patch and let me know if it solves your issue?
> >> 
> > ...
> >
> >
> > ----------------------------------------------------------------------------
> > --
> > Lotusphere 2011
> > Register now for Lotusphere 2011 and learn how
> > to connect the dots, take your collaborative environment
> > to the next level, and enter the era of Social Business.
> > http://p.sf.net/sfu/lotusphere-d2d
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
I

If you're able to try this with the 1.0.x SVN branch or the SVN trunk 
(plus my text patch) let me know. I am not able to reproduce any sort 
of memory leak with these newer versions, but I am able to with 1.0.0 as 
released (with or without my text patch). This is with or without the x 
axis limits updating you suggested. I believe there have been other 
memory leak fixes since the 1.0.0 release.
Cheers,
Mike
On 12/13/2010 08:35 PM, Russell E. Owen wrote:
> I also wanted to say:
> - Thank you for the patch. I appreciate the chance to try a fix.
> - I doubt the issue is related to text because my scripts shows a memory
> leak even if the displayed text is never updated (comment out the line
> that modifies the x axis limits to see what I mean; though I confess I
> did not try that with the trunk matplotlib, only with 1.0.0).
>
> -- Russell
>
> In article<4D0...@st...>,
> Michael Droettboom<md...@st...>
> wrote:
>
> 
>> I think I'm on to something -- it seems that text layout information has
>> a cyclical reference that prevents the Text object from being freed.
>>
>> Can you apply the attached patch and let me know if it solves your issue?
>> 
> ...
>
>
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Thanks!
Ben
On Tue, Dec 14, 2010 at 9:44 AM, Michael Droettboom <md...@st...> wrote:
> You need to be granted those permissions in the SourceForge admin
> interface. I've just gone ahead and done so for you.
>
> Mike
>
>
> On 12/13/2010 04:23 PM, Benjamin Root wrote:
>
> Does some other setting needs to be made to allow me to change the status
> of bug reports in sourceforge? I can't close reports or assign them to
> myself.
>
> Thanks,
> Ben Root
>
>
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.http://p.sf.net/sfu/lotusphere-d2d
>
>
> _______________________________________________
> Matplotlib-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> --
> Michael Droettboom
> Science Software Branch
> Space Telescope Science Institute
> Baltimore, Maryland, USA
>
>
>
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

You need to be granted those permissions in the SourceForge admin 
interface. I've just gone ahead and done so for you.
Mike
On 12/13/2010 04:23 PM, Benjamin Root wrote:
> Does some other setting needs to be made to allow me to change the 
> status of bug reports in sourceforge? I can't close reports or assign 
> them to myself.
>
> Thanks,
> Ben Root
>
>
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

I also wanted to say:
- Thank you for the patch. I appreciate the chance to try a fix.
- I doubt the issue is related to text because my scripts shows a memory 
leak even if the displayed text is never updated (comment out the line 
that modifies the x axis limits to see what I mean; though I confess I 
did not try that with the trunk matplotlib, only with 1.0.0).
-- Russell
In article <4D0...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:
> I think I'm on to something -- it seems that text layout information has 
> a cyclical reference that prevents the Text object from being freed.
> 
> Can you apply the attached patch and let me know if it solves your issue?
...

I'm afraid your change didn't help (I only applied the patch to 
lib/matplotlib/text.py; the cbook.py change appeared to only affect 
whitespace).
However, the memory leak is smaller using the svn trunk than in 
matplotlib 1.0.0. Also, calling subplot.clear() makes the leak worse in 
matplotlib 1.0.0 but not on the trunk.
Here are my results in detail. Before each run I show a few lines of 
code from:
<http://www.astro.washington.edu/users/rowen/python/matplotlibMemoryLeak.
py>
MemoryLeaker's _updateTimeAxis method. Note that the third column is a 
measure of the leak rate and I hold off measuring the leak rate for few 
seconds to give the application a chance to fully load.
-- Russell
matplotlib 1.0.0
 self.subplot.set_xlim(tMin, tMax)
# self.subplot.clear()
 self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time rss memory mem/sec
(sec) (kb) (kb/sec)
 0.0 27676 nan
 5.0 28980 nan
 10.1 29084 20.6
 15.1 29172 19.0
 20.1 29268 19.1
 25.2 29368 19.3
 30.2 29464 19.2
 35.2 29564 19.4
 40.2 29660 19.3
 45.2 29764 19.5
 self.subplot.set_xlim(tMin, tMax)
 self.subplot.clear()
 self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time rss memory mem/sec
(sec) (kb) (kb/sec)
 0.0 27696 nan
 5.1 29012 nan
 10.2 29152 27.5
 15.2 29292 27.7
 20.2 29436 28.0
 25.3 29580 28.1
 30.4 29728 28.3
 35.4 29876 28.5
 40.5 30024 28.6
 45.5 30160 28.4
 50.6 30308 28.5
matplotlib svn trunk rev8836
 self.subplot.set_xlim(tMin, tMax)
# self.subplot.clear()
 self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time rss memory mem/sec
(sec) (kb) (kb/sec)
 0.0 27664 nan
 5.0 28864 nan
 10.0 28880 3.2
 15.1 28884 2.0
 20.1 28896 2.1
 25.1 28908 2.2
 30.1 28916 2.1
 35.1 28928 2.1
 40.2 28940 2.2
 45.2 28948 2.1
 self.subplot.set_xlim(tMin, tMax)
 self.subplot.clear()
 self.canvas.draw()
time rss memory mem/sec
(sec) (kb) (kb/sec)
 0.0 27684 nan
 5.1 28856 nan
 10.1 28856 0.0
 15.1 28856 0.0
 20.1 28864 0.5
 25.2 28872 0.8
 30.2 28880 1.0
 35.2 28884 0.9
 40.2 28892 1.0
 45.2 28900 1.1
 50.2 28920 1.4
 55.3 28924 1.4
 60.3 28932 1.4
 65.3 28940 1.4
After applying your patch to svn trunk rev8836:
--- lib/matplotlib/text.py (revision 8819)
+++ lib/matplotlib/text.py (working copy)
@@ -143,6 +143,9 @@
 Handle storing and drawing of text in window or data coordinates.
 """
 zorder = 3
+
+ cached = maxdict(50)
+
 def __str__(self):
 return "Text(%g,%g,%s)"%(self._y,self._y,repr(self._text))
@@ -168,7 +171,6 @@
 """
 Artist.__init__(self)
- self.cached = maxdict(5)
 self._x, self._y = x, y
 if color is None: color = rcParams['text.color']
 self.subplot.set_xlim(tMin, tMax)
# self.subplot.clear()
 self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time rss memory mem/sec
(sec) (kb) (kb/sec)
 0.0 27656 nan
 5.0 28852 nan
 10.1 28864 2.4
 15.1 28876 2.4
 20.1 28888 2.4
 25.1 28908 2.8
 30.1 28916 2.6
 35.1 28924 2.4
 40.2 28936 2.4
 self.subplot.set_xlim(tMin, tMax)
 self.subplot.clear()
 self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time rss memory mem/sec
(sec) (kb) (kb/sec)
 0.0 27652 nan
 5.0 28836 nan
 10.0 28852 3.2
 15.1 28852 1.6
 20.1 28872 2.4
 25.1 28880 2.2
 30.1 28900 2.6
 35.1 28904 2.3
 40.2 28912 2.2
 45.2 28920 2.1
 50.3 28928 2.0
In article <4D0...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:
> I think I'm on to something -- it seems that text layout information has 
> a cyclical reference that prevents the Text object from being freed.
> 
> Can you apply the attached patch and let me know if it solves your issue?
> 
> Mike
> 
> On 12/10/2010 02:19 PM, Russell E. Owen wrote:
> > You may have already seen this in the general mailing list, but I've
> > found what I think is a serious memory leak in matplotlib 1.0.0: it
> > leaks memory every time canvas.draw() is called, at least when using
> > TkAgg on unix and Mac.
> >
> > Admittedly many graphs do not need canvas.draw() to be called repeatedly
> > (which I suspect is how it has survived this long). This came up in the
> > context of a strip chart widget, where I am changing the x/time axis
> > limits regularly and calling canvas.draw() so that the change is visible.
> >
> > I submitted ticket 3124990 with a very simple demo script:
> > <https://sourceforge.net/tracker/?func=detail&atid=560720&aid=3124990&gro
> > up_id=80706>
> > (you can disable the setting the x limits if you want to see the leak in
> > its purest form, but then nothing changes visually on the graph).
> >
> > I just wanted to be sure folks know about it in hopes somebody might
> > have an idea how to fix it. I have not tried any other back ends.
> >
> > -- Russell
> >
> >
> > ----------------------------------------------------------------------------
> > --
> > Oracle to DB2 Conversion Guide: Learn learn about native support for 
> > PL/SQL,
> > new data types, scalar functions, improved concurrency, built-in packages,
> > OCI, SQL*Plus, data movement tools, best practices and more.
> > http://p.sf.net/sfu/oracle-sfdev2dev
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> > 
> 
> 
> -- 
> Michael Droettboom
> Science Software Branch
> Space Telescope Science Institute
> Baltimore, Maryland, USA
> 
> ---------------------------------------------------------------------
> Index: lib/matplotlib/cbook.py
> ===================================================================
> --- lib/matplotlib/cbook.py	(revision 8819)
> +++ lib/matplotlib/cbook.py	(working copy)
> @@ -1109,9 +1109,10 @@
> dict.__init__(self)
> self.maxsize = maxsize
> self._killkeys = []
> +
> def __setitem__(self, k, v):
> if k not in self:
> - if len(self)>=self.maxsize:
> + if len(self) >= self.maxsize:
> del self[self._killkeys[0]]
> del self._killkeys[0]
> self._killkeys.append(k)
> Index: lib/matplotlib/text.py
> ===================================================================
> --- lib/matplotlib/text.py	(revision 8819)
> +++ lib/matplotlib/text.py	(working copy)
> @@ -143,6 +143,9 @@
> Handle storing and drawing of text in window or data coordinates.
> """
> zorder = 3
> +
> + cached = maxdict(50)
> +
> def __str__(self):
> return "Text(%g,%g,%s)"%(self._y,self._y,repr(self._text))
> 
> @@ -168,7 +171,6 @@
> """
> 
> Artist.__init__(self)
> - self.cached = maxdict(5)
> self._x, self._y = x, y
> 
> if color is None: color = rcParams['text.color']
> ---------------------------------------------------------------------
> ------------------------------------------------------------------------------
> Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
> new data types, scalar functions, improved concurrency, built-in packages, 
> OCI, SQL*Plus, data movement tools, best practices and more.
> http://p.sf.net/sfu/oracle-sfdev2dev 
> ---------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Does some other setting needs to be made to allow me to change the status of
bug reports in sourceforge? I can't close reports or assign them to myself.
Thanks,
Ben Root

On Tue, Nov 30, 2010 at 4:53 PM, Benjamin Root <ben...@ou...> wrote:
> On Wednesday, November 17, 2010, Benjamin Root <ben...@ou...> wrote:
> > On Tue, Nov 16, 2010 at 5:20 PM, J P <jp...@gm...> wrote:
> >
> >
> > Hi all, here's my first patch for matplotlib. Someone noticed at Stack
> Overflow that the plot_surface function in mplot3d wasn't especially fast
> for a lot of points (and small rstrides/cstrides) and using shading and a
> single color. I found some parts of the code that weren't vectorized. These
> are my changes so far.
> >
> > Summary of changes:
> > 1. Changed from double looping over aranges to using xrange
> > 2. Made the normalization of the normals and their dot product with the
> vector [-1,-1,0.5] to find the shading a vectorized operation.
> > 3. Changed a list comprehension which calculated the colors using an
> iterative approach to using the already built-in vectorization of the
> Normalization class and using the np.outer function. The result is a numpy
> array rather than a list which actually speeds up things down the line.
> > 4. removed the corners array from plot_surface which wasn't ever used or
> returned. It didn't really slow things down, but I'm thinking that it is
> cruft.
> >
> > For change number two, I made a separate function that generates the
> shades, but feel free to move that around if you prefer.. or maybe it should
> be a function that begins with a _ because it shouldn't be used externally.
> These changes give varying levels of speed improvement depending on the
> number of points and the rstrides/cstrides arguments. With larger numbers of
> points and small rstrides/cstrides, these changes can more than halve the
> running time. I have found no difference in output after my changes.
> >
> > I know there is more work to be done within the plot_surface function and
> I'll submit more changes soon.
> >
> > Justin
> >
> >
> > Justin,
> >
> > Thank you for your efforts to improve the performance of mplot3d. I will
> take a look at the patches you have submitted and test them out. What I am
> probably going to do is break down the patches into smaller pieces and
> incorporate them piece-by-piece.
> >
> > I tried refactoring plot_surface once before to mixed results. The key
> feature I was trying to gain was compatibility with masked arrays. I wanted
> to duplicate the behavior of contourf and pcolor where masked out portions
> of the surface would not be created. I managed to get it to work for that
> particular use-case, but I broke a bunch of other use-cases along the way.
> I am curious to see if your patches make this easier/harder to do.
> >
> > Thank you for your efforts and thank you for using matplotlib!
> >
> > Ben Root
> >
> >
>
> I have looked through the patches, and there are definite
> improvements. I have broken the work into four separate patches. The
> first patch is essentially code cleanup and utilization of xrange
> (plot_surface_cleanup.patch). This patch can be back-ported without
> concern (although it doesn't fix any bug per se).
>
> The second patch does the vectorization of the shades. The original
> patch that was submitted had some edge cases, but I have found that
> just simply converting that for-loop that creates the shades into a
> list comprehension (and then pass into np.array) yielded almost
> identical speedups without changing the current code path. (Note: I
> am a minimalist when it comes to patches). This is in
> plot_surface_vectshading.patch.
>
> The third patch improves the calculation of the normals in
> plot_surface by pre-allocating the arrays for calculating the vectors
> and doing a final call to np.cross rather than appending on a list. I
> deviated slightly from the original patch by calling "which" as
> "which_pt", adding a couple of comments, and also added an else
> condition to create a "normal" with an empty list. This last part is
> to keep the code path as similar as it was before. It was
> theoretically possible to utilize a variable called normal elsewhere
> without all the same conditions holding, so this guarantees that
> normal exists, which was the case before. This patch is
> plot_surface_vectnorm.patch.
>
> Finally, the fourth patch utilizes numpy array functionality for
> calculating the vertexes. This patch also forgoes the use of
> transposed arrays. I took the original patch a step further and
> eliminated the array transpose line earlier in the plot_surface
> function. The array transpose was not being properly utilized here,
> and I saw no speed penalty/speedup either way, so in favor of simpler
> code, I eliminated its use. This patch is
> plot_surface_vectvertex.patch.
>
> Of the four patches, the speedups are in mostly found in the second
> patch (100% speedup). The first patch does provide noticeable
> improvements. There is also a slight improvement with the third
> patch. I am up in the air regarding speed improvements with the
> fourth patch, but I wonder if there might be some memory improvements
> here, or if any speedup is being hidden by the for-loop that the
> vectorization is done in.
>
> I will let these patches be mulled over before applying them. Thanks
> to JP for submitting the original patch.
>
> Ben Root
>
Re-pinging, as I haven't heard any opinions on this. The key question is
should any of these patch be put into the maintenance branch or should it
only be in the development branch?
Thanks,
Ben Root

I believe this was recently introduced when I refactored the annotation code.
Attached is a preliminary fix. So, please test it if you can.
Since the change during the refactoring was rather significant, I'm
not 100% sure if this will restore the old behavior without affecting
the new functionality. The examples I tried (including yours) seem to
work fine. I'll test this myself a few more days, and commit to the
svn.
I personally think it is better to use "offset points" for these cases
which makes the internal logic much simpler.
Regards,
-JJ
On Sat, Dec 11, 2010 at 6:07 AM, Stan West <sta...@nr...> wrote:
> Hi. The docs for Annotation [1] say that negative coordinates given for [
> figure | axes ] [ points | pixels ] xycoords are to be interpreted relative
> to the top-right corner, but I found that they act relative to the
> bottom-left corner as for positive coordinates. This can be seen in the
> attached script and in the annotation_demo.py example [2], where the string
> "bottom right (points)" bleeds off the left edge of the figure.
>
> [1]
> http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.text.Annotation
>
> [2]
> http://matplotlib.sourceforge.net/examples/pylab_examples/annotation_demo.html
>
> ------------------------------------------------------------------------------
> Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
> new data types, scalar functions, improved concurrency, built-in packages,
> OCI, SQL*Plus, data movement tools, best practices and more.
> http://p.sf.net/sfu/oracle-sfdev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Hello all,
I finally, after much pain and anguish, succeeded at compiling MPL with
GTKAgg on windows and I thought people might be interested to know how I
managed it. Of course, your mileage may vary...
 1. Install Python (I used the Python (x,y) distribution of 2.6:
 http://code.google.com/p/pythonxy/wiki/Downloads
 2. Install the GTK bits and pieces. For some reason using the newest
 ones causes some problems with paths. I can confirm that this set works on
 at least two computers:
 Glade3.6.7withGTK+.exe<http://ftp.gnome.org/pub/GNOME/binaries/win32/glade3/3.6/glade3-3.6.7-with-GTK+.exe>
 (Install this to c:\GTK so that MPL build can find it without playing with
 paths)
 pygtk-2.12.1-3.win32-py2.6.exe<http://ftp.gnome.org/pub/GNOME/binaries/win32/pygtk/2.12/pygtk-2.12.1-3.win32-py2.6.exe>
 pycairo-1.4.12-2.win32-py2.6.exe<http://ftp.gnome.org/pub/GNOME/binaries/win32/pycairo/1.4/pycairo-1.4.12-2.win32-py2.6.exe>
 pygobject-2.14.2-2.win32-py2.6.exe<http://ftp.gnome.org/pub/GNOME/binaries/win32/pygobject/2.14/pygobject-2.14.2-2.win32-py2.6.exe>
 3. Install libpng<http://downloads.sourceforge.net/gnuwin32/libpng-1.2.37-setup.exe>and
 freetype <http://gnuwin32.sourceforge.net/downlinks/freetype.php> using
 the installers (also includes the zlib dll). They will default to install
 to c:\Program Files\GnuWin32 . This is fine, but note the location.
 4. Either checkout the MPL source from subversion, or download a
tarball<http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/?view=tar>and
unpack it
 5. Download the win32_static
files<http://matplotlib.sourceforge.net/win32_static_vs.tar.gz>,
 and unpack them to the place where your MPL source is, you should then have
 a folder in the MPL source folder called win32_static
 6. Open the file setupext.py in the MPL source folder
 7. Edit line 51 (or so) to read:: 'win32' : ['win32_static','c:\\Program
 Files\\GnuWin32']
 8. Install Visual Studio 2008
Express<http://www.microsoft.com/express/Downloads/#2008-Visual-CPP>if
you do not have a version of Visual Studio 2008 on your computer
 9. Open a console and type:: python setup.py build --compiler=msvc
 bdist_wininst
 10. Wait for it to finish, then:: python setup.py install to install MPL
 11. If everything worked right, you should be able to open a python shell
 and type
 >> import matplotlib
 >> matplotlib.use('GTKAgg')
 >> import pylab
 >> pylab.plot(0,4,'s')
 >> pylab.show()
 12. And you should see a GTK rendered plot window with a small square in
 the center hopefully
Improvements to this procedure would be greatly appreciated - but this
finally seems to work..
Regards,
Ian
----
Ian Bell
Graduate Research Assistant
Herrick Labs
Purdue University
email: ib...@pu...
cell: (607)227-7626

import matplotlib.pyplot as plt
fig = plt.figure()
axes = fig.add_subplot(1, 1, 1)
for x in (12, -12):
 for y in (12, -12):
 axes.annotate('X', (x, y), xycoords='axes points', 
 color='r', ha='center', va='center')
plt.show()

On 12/9/10 11:57 PM, Ludwig Schwardt wrote:
> This patch reminded me to ask why the builtin libpng, zlib and
> libfreetype on Mac OS 10.5 and later are not used to build Matplotlib,
It may be because we still want to support OS-X 10.4 .
Also, not everyone has X11 installed (or does everyone now?)
I also notice that they are in: MacOSX10.4u.sdk (under X11) -- so maybe 
the static libs in there could be used.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

I think I'm on to something -- it seems that text layout information has 
a cyclical reference that prevents the Text object from being freed.
Can you apply the attached patch and let me know if it solves your issue?
Mike
On 12/10/2010 02:19 PM, Russell E. Owen wrote:
> You may have already seen this in the general mailing list, but I've
> found what I think is a serious memory leak in matplotlib 1.0.0: it
> leaks memory every time canvas.draw() is called, at least when using
> TkAgg on unix and Mac.
>
> Admittedly many graphs do not need canvas.draw() to be called repeatedly
> (which I suspect is how it has survived this long). This came up in the
> context of a strip chart widget, where I am changing the x/time axis
> limits regularly and calling canvas.draw() so that the change is visible.
>
> I submitted ticket 3124990 with a very simple demo script:
> <https://sourceforge.net/tracker/?func=detail&atid=560720&aid=3124990&gro
> up_id=80706>
> (you can disable the setting the x limits if you want to see the leak in
> its purest form, but then nothing changes visually on the graph).
>
> I just wanted to be sure folks know about it in hopes somebody might
> have an idea how to fix it. I have not tried any other back ends.
>
> -- Russell
>
>
> ------------------------------------------------------------------------------
> Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
> new data types, scalar functions, improved concurrency, built-in packages,
> OCI, SQL*Plus, data movement tools, best practices and more.
> http://p.sf.net/sfu/oracle-sfdev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

You may have already seen this in the general mailing list, but I've 
found what I think is a serious memory leak in matplotlib 1.0.0: it 
leaks memory every time canvas.draw() is called, at least when using 
TkAgg on unix and Mac.
Admittedly many graphs do not need canvas.draw() to be called repeatedly 
(which I suspect is how it has survived this long). This came up in the 
context of a strip chart widget, where I am changing the x/time axis 
limits regularly and calling canvas.draw() so that the change is visible.
I submitted ticket 3124990 with a very simple demo script:
<https://sourceforge.net/tracker/?func=detail&atid=560720&aid=3124990&gro
up_id=80706>
(you can disable the setting the x limits if you want to see the leak in 
its purest form, but then nothing changes visually on the graph).
I just wanted to be sure folks know about it in hopes somebody might 
have an idea how to fix it. I have not tried any other back ends.
-- Russell

Hi,
This patch reminded me to ask why the builtin libpng, zlib and
libfreetype on Mac OS 10.5 and later are not used to build Matplotlib,
removing the need to download these extra libraries. I was pleased to
discover that Snow Leopard shipped with libpng and libfreetype as part
of X11, only to find that even my old Leopard installation had them.
I've been successfully building Matplotlib against them on both
platforms. Besides skipping the download step, these libraries have
the advantage of being correct universal binaries, eliminating another
potential stumbling block. The only problem would be if these
libraries were outdated, but I haven't come across any problems yet.
For the record, I set the following environment variables in
~/.profile on Snow Leopard:
 # These compiler flags ensure 32-bit + 64-bit code generation, as
Snow Leopard produces 64-bit code by default
 export MACOSX_DEPLOYMENT_TARGET=10.6
 export CFLAGS="-arch i386 -arch x86_64 -isysroot
/Developer/SDKs/MacOSX10.6.sdk"
 export LDFLAGS="-arch i386 -arch x86_64
-syslibroot,/Developer/SDKs/MacOSX10.6.sdk"
 export FFLAGS="-m32 -m64"
I then build a Matplotlib egg with:
CFLAGS=${CFLAGS}" -I/usr/X11/include -I/usr/X11/include/freetype2"
LDFLAGS=${LDFLAGS}" -L/usr/X11/lib" python setupegg.py bdist_egg
I've been meaning to publish my installation instructions for
numpy/scipy/matplotlib/ipython on Snow Leopard somewhere for quite a
while, but that will have to wait for another day... I've tried to
trim down my installation procedure to the minimum steps that will
guarantee a working system without introducing extra libraries /
Pythons / etc, so there might be some interest in it.
Ludwig

On 2010年12月09日 23:55:05 +0200, Jouni K. Seppänen <jk...@ik...> wrote:
> Ben Gamari <bg...@gm...> writes:
> 
> > It seems that matplotlib's sphinx extension calls
> > matplotlib.rcdefaults() after rendering each figure, thus resetting
> > examples.download to True (as set in rcsetup.py).
> 
> Right, and it sets figure.figsize after it. I guess you will want to set
> examples.download in the same function.
> 
NAK.
This seems like an _awful_ hack. If the user specifies in matplotlibrc
that they don't want to download sample data (or any preference for that
matter), then they _really_ don't want to download sample data and we
should take their word for this.
It's one-time hacks like this that make matplotlib the nightmare to
package that it is. Wholesale overriding of the user's preferences seems
like a big no-no, even when it comes to generating documentation. If a
particular example _absolutely needs_ to override a specific rc option
then it should modify that option and only that option. After this, the
configuration should be returned to the user's default.
> > The documentation claims that this function will "Restore the default rc
> > params - the ones that were created at matplotlib load time."
> 
> > rcdefaults()'s implementation appears to implement the latter, updating
> > rcParams from rcParamsDefault in rcsetup.py, which appears to describe
> > the factory default values. Perhaps we should
> > rcParamsDefault.update(rcParams) after loading matplotlibrc?
> 
> I think you're better off modifying the sphinx extension. rcdefaults has
> a useful purpose, and the extension is trying to use it for that
> purpose: to avoid having the user's configuration mess up the
> documentation. If you were to update rcParamsDefault with the
> matplotlibrc parameters, you might accidentally change the example
> output.
> 
I'm not sure I understand what this purpose might be. If the user sets a
preference, then they want that preference to be reflected in _all_
matplotlib output, including the examples. By overriding matplotlibrc,
we are doing nothing but setting ourselves up to thoroughly confuse the
user (not to mention lowly packagers like me). If the user takes a block
of code from an example then he expects that the output in ipython will
be identical to that generated in the documentation. If it is not, he's
forced to embark on a wild goose chase through the code looking for the
line where some developer thought their example was too good for my
carefully chosen preferences (or simply give up in frustration).
- Ben