Re: [matplotlib-devel] Sourceforge status

2010-12-14 Thread Michael Droettboom 
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
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Sourceforge status

2010-12-14 Thread Benjamin Root 
Thanks!

Ben

On Tue, Dec 14, 2010 at 9:44 AM, Michael Droettboom  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 
> [email protected]://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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] memory leak in canvas.draw() in TkAgg

2010-12-14 Thread Michael Droettboom 
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<[email protected]>,
>   Michael Droettboom
>   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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] memory leak in canvas.draw() in TkAgg

2010-12-14 Thread Russell E. Owen 
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 
 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 memorymem/sec
(sec) (kb)  (kb/sec)
   0.027676   nan
   5.028980   nan
  10.129084  20.6
  15.129172  19.0
  20.129268  19.1
  25.229368  19.3
  30.229464  19.2
  35.229564  19.4
  40.229660  19.3
  45.229764  19.5
...
1521.658248  19.3
1526.658348  19.3

self.subplot.set_xlim(tMin, tMax)
self.subplot.clear()
self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time   rss memorymem/sec
(sec) (kb)  (kb/sec)
   0.027696   nan
   5.129012   nan
  10.229152  27.5
  15.229292  27.7
  20.229436  28.0
  25.329580  28.1
  30.429728  28.3
  35.429876  28.5
  40.530024  28.6
  45.530160  28.4
  50.630308  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 memorymem/sec
(sec) (kb)  (kb/sec)
   0.027664   nan
   5.028864   nan
  10.028880   3.2
  15.128884   2.0
  20.128896   2.1
  25.128908   2.2
  30.128916   2.1
  35.128928   2.1
  40.228940   2.2
  45.228948   2.1

self.subplot.set_xlim(tMin, tMax)
self.subplot.clear()
self.canvas.draw()
time   rss memorymem/sec
(sec) (kb)  (kb/sec)
   0.027684   nan
   5.128856   nan
  10.128856   0.0
  15.128856   0.0
  20.128864   0.5
  25.228872   0.8
  30.228880   1.0
  35.228884   0.9
  40.228892   1.0
  45.228900   1.1
  50.228920   1.4
  55.328924   1.4
  60.328932   1.4
  65.328940   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 memorymem/sec
(sec) (kb)  (kb/sec)
   0.027656   nan
   5.028852   nan
  10.128864   2.4
  15.128876   2.4
  20.12   2.4
  25.128908   2.8
  30.128916   2.6
  35.128924   2.4
  40.228936   2.4
...
 803.130296   1.8
 808.130304   1.8
...
2625.133628   1.8
2630.133640   1.8
...
4186.136476   1.8
4191.236488   1.8
...
6228.940228   1.8
6233.940236   1.8

self.subplot.set_xlim(tMin, tMax)
self.subplot.clear()
self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time   rss memorymem/sec
(sec) (kb)  (kb/sec)
   0.027652   nan
   5.028836   nan
  10.028852   3.2
  15.128852   1.6
  20.128872   2.4
  25.128880   2.2
  30.128900   2.6
  35.128904   2.3
  40.228912   2.2
  45.228920   2.1
  50.328928   2.0

# self.subplot.set_xlim(tMin, tMax)
# self.subplot.clear()
self.canvas.draw()
rowen:Python bugs rowen$ python matplotlibMemoryLeak.py 
time   rss memorymem/sec
(sec) (kb)  (kb/sec)
   0.027636   nan
   5.028832   nan
  10.028840   1.6
  15.128840   0.8
  20.128852   1.3
  25.128860   1.4
  30.128868   1.4
  3

Re: [matplotlib-devel] memory leak in canvas.draw() in TkAgg

2010-12-14 Thread Russell E. Owen 
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 memorymem/sec
(sec) (kb)  (kb/sec)
   0.036816   nan
   5.036860   nan
  10.036860   0.0
  15.136860   0.0
  20.136860   0.0
  25.136896   1.8
...
 326.536896   0.1
 331.636972   0.3
...
 401.936972   0.3
 406.936980   0.3
 411.937004   0.4
 417.037016   0.4
 422.037040   0.4
 427.037052   0.5
 432.037076   0.5
 437.137088   0.5
 442.137112   0.6
 447.137124   0.6
 452.137148   0.6
 457.237160   0.7
 462.237184   0.7
 467.237196   0.7
 472.237220   0.8
 477.337232   0.8
 482.337256   0.8
 487.337268   0.8
 492.337292   0.9
 497.337304   0.9
 502.337328   0.9
 507.437340   1.0
 512.437360   1.0
 517.437376   1.0
 522.437396   1.0
 527.537412   1.1
 532.537432   1.1
 537.537448   1.1
 542.537472   1.1
 547.637488   1.2
 552.637504   1.2
 557.637516   1.2
 562.637540   1.2
 567.637556   1.2
 572.737576   1.3
 577.737592   1.3
 582.737612   1.3
 587.737628   1.3
 592.737648   1.3
 597.837664   1.4
 602.837684   1.4
 607.837700   1.4

This is different behavior than on Mac OS X, but still alarming.

-- Russell

In article <[email protected]>,
 Michael Droettboom  
 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<[email protected]>,
> >   Michael Droettboom
> >   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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] memory leak in canvas.draw() in TkAgg

2010-12-14 Thread Benjamin Root 
On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen  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 memorymem/sec
> (sec) (kb)  (kb/sec)
>0.036816   nan
>   5.036860   nan
>  10.036860   0.0
>  15.136860   0.0
>  20.136860   0.0
>  25.136896   1.8
> ...
>  326.536896   0.1
>  331.636972   0.3
> ...
>  401.936972   0.3
>  406.936980   0.3
>  411.937004   0.4
>  417.037016   0.4
>  422.037040   0.4
>  427.037052   0.5
>  432.037076   0.5
>  437.137088   0.5
>  442.137112   0.6
>  447.137124   0.6
>  452.137148   0.6
>  457.237160   0.7
>  462.237184   0.7
>  467.237196   0.7
>  472.237220   0.8
>  477.337232   0.8
>  482.337256   0.8
>  487.337268   0.8
>  492.337292   0.9
>  497.337304   0.9
>  502.337328   0.9
>  507.437340   1.0
>  512.437360   1.0
>  517.437376   1.0
>  522.437396   1.0
>  527.537412   1.1
>  532.537432   1.1
>  537.537448   1.1
>  542.537472   1.1
>  547.637488   1.2
>  552.637504   1.2
>  557.637516   1.2
>  562.637540   1.2
>  567.637556   1.2
>  572.737576   1.3
>  577.737592   1.3
>  582.737612   1.3
>  587.737628   1.3
>  592.737648   1.3
>  597.837664   1.4
>  602.837684   1.4
>  607.837700   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
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] memory leak in canvas.draw() in TkAgg

2010-12-14 Thread Benjamin Root 
On Tue, Dec 14, 2010 at 4:06 PM, Russell Owen  wrote:

> On Dec 14, 2010, at 1:50 PM, Benjamin Root wrote:
>
> On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen  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 memorymem/sec
>> (sec) (kb)  (kb/sec)
>>0.036816   nan
>>   5.036860   nan
>>  10.036860   0.0
>>  15.136860   0.0
>>  20.136860   0.0
>>  25.136896   1.8
>> ...
>>  326.536896   0.1
>>  331.636972   0.3
>> ...
>>  401.936972   0.3
>>  406.936980   0.3
>>   ...
>>
>>  602.837684   1.4
>>  607.837700   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
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] memory leak in canvas.draw() in TkAgg

2010-12-14 Thread Russell Owen 

On Dec 14, 2010, at 2:38 PM, Benjamin Root wrote:

On Tue, Dec 14, 2010 at 4:22 PM, Benjamin Root   
wrote:



On Tue, Dec 14, 2010 at 4:06 PM, Russell Owen  wrote:
On Dec 14, 2010, at 1:50 PM, Benjamin Root wrote:

On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen   
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 memorymem/sec
(sec) (kb)  (kb/sec)
  0.036816   nan
  5.036860   nan
 10.036860   0.0
 15.136860   0.0
 20.136860   0.0
 25.136896   1.8
...
 326.536896   0.1
 331.636972   0.3
...
 401.936972   0.3
 406.936980   0.3
  ...

 602.837684   1.4
 607.837700   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:





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 memorymem/sec
(sec) (kb)  (kb/sec)
   0.036860   nan
   5.136904   nan
  10.136904   0.0
  15.136904   0.0
  20.236904   0.0
  25.236904   0.0
  30.236904   0.0
  35.236904   0.0
  40.236904   0.0
  45.236904   0.0
  50.336904   0.0
  55.336904   0.0
  60.336904   0.0
  65.436904   0.0
  70.436904   0.0
  75.436904   0.0
  80.436904   0.0
  85.436904   0.0
  90.536904   0.0
  95.536904   0.0
 100.536976   0.8
 105.536976   0.7
 110.636976   0.7
 115.636976   0.7
 120.636976   0.6
 125.636976   0.6
 130.736976   0.6
 135.736976   0.6
 140.736976   0.5
 145.736976   0.5
 150.836976   0.5
 155.836976   0.5
 160.836976   0.5
 165.836976   0.4
 170.936976   0.4
 175.936976   0.4
 180.936976   0.4
 185.936976   0.4
 190.936976   0.4
 196.036

Re: [matplotlib-devel] memory leak in canvas.draw() in TkAgg

2010-12-14 Thread Russell Owen 

On Dec 14, 2010, at 1:50 PM, Benjamin Root wrote:


On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen  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 memorymem/sec
(sec) (kb)  (kb/sec)
  0.036816   nan
  5.036860   nan
 10.036860   0.0
 15.136860   0.0
 20.136860   0.0
 25.136896   1.8
...
 326.536896   0.1
 331.636972   0.3
...
 401.936972   0.3
 406.936980   0.3
  ...
 602.837684   1.4
 607.837700   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

--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] memory leak in canvas.draw() in TkAgg

2010-12-14 Thread Benjamin Root 
On Tue, Dec 14, 2010 at 4:22 PM, Benjamin Root  wrote:

>
>
> On Tue, Dec 14, 2010 at 4:06 PM, Russell Owen  wrote:
>
>> On Dec 14, 2010, at 1:50 PM, Benjamin Root wrote:
>>
>> On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen  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 memorymem/sec
>>> (sec) (kb)  (kb/sec)
>>>0.036816   nan
>>>   5.036860   nan
>>>  10.036860   0.0
>>>  15.136860   0.0
>>>  20.136860   0.0
>>>  25.136896   1.8
>>> ...
>>>  326.536896   0.1
>>>  331.636972   0.3
>>> ...
>>>  401.936972   0.3
>>>  406.936980   0.3
>>>   ...
>>>
>>>  602.837684   1.4
>>>  607.837700   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
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] memory leak in canvas.draw() in TkAgg

2010-12-14 Thread Benjamin Root 
On Tue, Dec 14, 2010 at 5:26 PM, Russell Owen  wrote:

> On Dec 14, 2010, at 2:38 PM, Benjamin Root wrote:
>
> On Tue, Dec 14, 2010 at 4:22 PM, Benjamin Root  wrote:
>
>>
>>
>> On Tue, Dec 14, 2010 at 4:06 PM, Russell Owen  wrote:
>>
>>> On Dec 14, 2010, at 1:50 PM, Benjamin Root wrote:
>>>
>>> On Tue, Dec 14, 2010 at 3:18 PM, Russell E. Owen  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 memorymem/sec
 (sec) (kb)  (kb/sec)
0.036816   nan
   5.036860   nan
  10.036860   0.0
  15.136860   0.0
  20.136860   0.0
  25.136896   1.8
 ...
  326.536896   0.1
  331.636972   0.3
 ...
  401.936972   0.3
  406.936980   0.3
   ...

  602.837684   1.4
  607.837700   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/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
happe

Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?

2010-12-14 Thread Ludwig Schwardt 
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: Thu, 18 Nov 2010 16:57:10 -0600
> From: Benjamin Root 
>
> 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).

--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] How to decouple non-GUI stuff from the GUI?

2010-12-14 Thread Christopher Barker 
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

[email protected]

--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel