matplotlib-users Mailing List for matplotlib (Page 9)

I am puzzled. Wasn't the whole point of close() to avoid memory leaks?

Laurent

2008/7/15 Michael Droettboom <md...@st...>:

> Yes, as of r5747 twinx (well, shared axes specifically) no longer leaks.
>
> Manuel has discovered a seemingly generic leak that occurs when
> pyplot.close() is called and running a GUI backend.  I can confirm his
> results with the script he last sent.
>
> Cheers,
> Mike
>
> Manuel Metz wrote:
> > John Hunter wrote:
> >> On Mon, Jul 14, 2008 at 3:05 PM, Michael Droettboom <md...@st...>
> >> wrote:
> >>> I can confirm this.
> >>>
> >>> Commenting out "del Gcf.figs[num]" in Gcf.destroy (in
> >>> _pylab_helpers.py)
> >>> also seems to resolve the leak.  But I have no idea why, so I won't
> >>> commit it just yet.  I don't have much time to look deeper now.  Does
> >>> anyone (who probably understands figure management better than me) have
> >>> an idea what might cause this?
> >>
> >> Can you post the script you are using to test -- I am a little
> >> confused from reading this thread by whether or not twinx is
> >> implicated.  Also, I saw that you committed some changes vis-a-vis the
> >> twinx leak
> >>
> >>   r5747 | mdboom | 2008-07-11 13:21:53 -0500 (Fri, 11 Jul 2008) | 2
> >> lines
> >>
> >>   Fix memory leak when using shared axes.
> >>
> >> so I thought that part was resolved already...
> >>
> >> JDH
> >
> > I use a modified version of the script Laurent Oget posted (see
> > attachment). Here is the output if I don't comment out PL.close(1).
> >
> > ~/python/test$ python looptest.py -dGTK
> > 0 GC 69354 69354 0 13854
> > 100 GC 84354 150 0 15163
> > 200 GC 99354 150 0 16306
> > 300 GC 114354 150 0 17364
> > 400 GC 129354 150 0 18576
> > ~/python/test$ python looptest.py -dTK
> > 0 GC 69521 69521 0 14065
> > 100 GC 84521 150 0 15444
> > 200 GC 99521 150 0 16581
> > 300 GC 114521 150 0 17719
> > 400 GC 129521 150 0 18715
> > ~/python/test$ python looptest.py -dPS
> > 0 GC 59307 59307 0 7705
> > 100 GC 59307 0 0 8037
> > 200 GC 59307 0 0 8038
> > 300 GC 59307 0 0 8038
> > 400 GC 59307 0 0 8038
> >
> > (so for the window-less backend PS no objects are left)
> >
> > And now I commented out the line PL.close(1):
> >
> > ~/python/test$ python looptest.py -dGTK
> > 0 GC 69379 69379 0 13855
> > 100 GC 69379 0 0 14253
> > 200 GC 69379 0 0 14253
> > 300 GC 69379 0 0 14253
> > 400 GC 69379 0 0 14252
> >
> > Manuel
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Hi Darren,

Thanks for helping with this problem.

I have investigated further this issue and here is what I have found out:

I have traced the errors themselves back to two functions in texmanager.py
(matplotlib.texmanager), make_dvi and make_png. Most of the errors seem to
mention 'Stale NFS file handles' and crop up at a variety of different
places throughout these functions. I guess this is because on our clusters
/home/[username] is not a local directory, we have seen issues before with
other code if a lot of nodes try to access the same directory on the NFS
file system simultaneously. I tried altering the __init__.py to force the
code to put the .matplotlib directory on filesystems local to each node.
Moving the .matplotlib directory to a local drive solves almost all of these
errors.
One error that remained was the one about file opening
fh = file(outfile)
I added a 'w' to this and this seemed to solve this problem, I also
commented out some of the verbose generating commands (specifically
fh.read() was causing a problem (probably expected with 'w')) within these
functions and the errors go away. I guess 'a' would be better but the
commands only seem to be called if the file doesn't exist?

As we have a lot of users running this code a solution like this is
unworkable (as a lot of our users are unfamiliar with python/Linux and want
to run a simple command). Do you have any ideas of how we could solve this
issue?

Thanks again for your help

Ian Harry

2008/7/10 Darren Dale <dsd...@gm...>:

> On Thursday 10 July 2008 10:48:01 am you wrote:
> > Hi Darren,
> >
> > I have tried rerunning our code with the change you suggested in the
> > make_dvi and make_png functions. I am still noticing failures however. I
> > put these at the bottom of this message. Strangely enough, these errors
> > don't seem to occur when there are a lot of files in my tex.cache
> > directory. For example, I ran the code (consisting of ~40 codes all
> making
> > ~10-20 plots each), successfully 3 times (the OSError wasn't raised at
> all,
> > I used a print statement to check). I realised after this that a lot of
> > temp files were in my tex.cache directory, so I emptied it and then I
> > noticed that a lot of failures occured when I ran the code the next time
> > (the OSError I showed previously was raised as well as the error messages
> > shown below). It seems weird that it should run fine when a lot of files
> > are left in my temp directory and not when it is empty?
>
> Most of those files are not temporary files, but cached files. The error
> you
> reported only occurs when a required file does not already exist in the
> cache, and like you said, it appears to be the case that two jobs are
> trying
> to add the same file to the cache at the same time, and one job is failing
> because the other deletes a temporary file that is being used by both. I
> guess.
>
> > Here are the error messages that are occuring now:
> >
> > Traceback (most recent call last):
> >   File
> >
> "/home/spxiwh/ihope/852450000-852700000/nsbhinj_summary_plots/../executable
> >s/plotinspmissed", line 625, in ?
> >     savePlot( opts, filename, titleText)
> >   File
> >
> "/home/spxiwh/ihope/852450000-852700000/nsbhinj_summary_plots/../executable
> >s/plotinspmissed", line 108, in savePlot
> >     dpi_thumb=opts.figure_resolution)
> >   File
> >
> "/home/spxiwh/lscsoft/executables/cbc_s5_1yr_20070129/pylal//lib64/python2.
> >4/site-packages/pylal/InspiralUtils.py", line 54, in savefig_pylal
> >     fig.savefig(filename, dpi=dpi)
> >   File "/home/spxiwh/test/matplotlib/figure.py", line 682, in savefig
> >     self.canvas.print_figure(*args, **kwargs)
> >   File "/home/spxiwh/test/matplotlib/backends/backend_agg.py", line 456,
> in
> > print_figure
> >     self.draw()
> >   File "/home/spxiwh/test/matplotlib/backends/backend_agg.py", line 392,
> in
> > draw
> >     self.figure.draw(renderer)
> >   File "/home/spxiwh/test/matplotlib/figure.py", line 544, in draw
> >     for a in self.axes: a.draw(renderer)
> >   File "/home/spxiwh/test/matplotlib/axes.py", line 1063, in draw
> >     a.draw(renderer)
> >   File "/home/spxiwh/test/matplotlib/axis.py", line 595, in draw
> >     self.label.draw(renderer)
> >   File "/home/spxiwh/test/matplotlib/text.py", line 340, in draw
> >     bbox, info = self._get_layout(renderer)
> >   File "/home/spxiwh/test/matplotlib/text.py", line 187, in _get_layout
> >     w,h = renderer.get_text_width_height(
> >   File "/home/spxiwh/test/matplotlib/backends/backend_agg.py", line 240,
> in
> > get_text_width_height
> >     Z = texmanager.get_rgba(s, size, self.dpi.get(), rgb)
> >   File "/home/spxiwh/test/matplotlib/texmanager.py", line 334, in
> get_rgba
> >     pngfile = self.make_png(tex, fontsize, dpi, force=False)
> >   File "/home/spxiwh/test/matplotlib/texmanager.py", line 255, in
> make_png
> >     fh = file(outfile)
> > IOError: [Errno 2] No such file or directory:
> >
> '/home/spxiwh/.matplotlib/tex.cache/fb2014e54961855bd04020b61190867c.output
> >'
>
> That doesnt make any sense to me. file defaults to open a file in append
> mode,
> it doesnt matter if a file exists or not. Maybe you could try to figure out
> why that fails and report back.
>
> > And once I noticed:
> >
> > Traceback (most recent call last):
> >   File
> >
> "/home/spxiwh/ihope/852450000-852700000/allinj_summary_plots/../executables
> >/plotinspmissed", line 661, in ?
> >     dpi_thumb=opts.figure_resolution)
> >   File
> >
> "/home/spxiwh/lscsoft/executables/cbc_s5_1yr_20070129/pylal//lib64/python2.
> >4/site-packages/pylal/InspiralUtils.py", line 54, in savefig_pylal
> >     fig.savefig(filename, dpi=dpi)
> >   File "/usr/lib64/python2.4/site-packages/matplotlib/figure.py", line
> 682,
> > in savefig
> >     self.canvas.print_figure(*args, **kwargs)
> >   File
> > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_agg.py",
> > line 456, in print_figure
> >     self.draw()
> >   File
> > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_agg.py",
> > line 392, in draw
> >     self.figure.draw(renderer)
> >   File "/usr/lib64/python2.4/site-packages/matplotlib/figure.py", line
> 544,
> > in draw
> >     for a in self.axes: a.draw(renderer)
> >   File "/usr/lib64/python2.4/site-packages/matplotlib/axes.py", line
> 1063,
> > in draw
> >     a.draw(renderer)
> >   File "/usr/lib64/python2.4/site-packages/matplotlib/text.py", line 340,
> > in draw
> >     bbox, info = self._get_layout(renderer)
> >   File "/usr/lib64/python2.4/site-packages/matplotlib/text.py", line 187,
> > in _get_layout
> >     w,h = renderer.get_text_width_height(
> >   File
> > "/usr/lib64/python2.4/site-packages/matplotlib/backends/backend_agg.py",
> > line 240, in get_text_width_height
> >     Z = texmanager.get_rgba(s, size, self.dpi.get(), rgb)
> >   File "/usr/lib64/python2.4/site-packages/matplotlib/texmanager.py",
> line
> > 330, in get_rgba
> >     X = readpng(os.path.join(self.texcache, pngfile))
> > RuntimeError: _image_module::readpng: file not recognized as a PNG file
>
> No idea, sorry.
>
> Darren
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>



-- 
---------------------------------------------------------------------------
Ian Harry
School of Physics & Astronomy
Queens Buildings, The Parade
Cardiff, CF24 3AA
Email: Ian...@as...
Phone: (+44) 29 208 75120
Mobile: (+44) 7890 479090
---------------------------------------------------------------------------

On Tue, Jul 15, 2008 at 8:39 AM, James K. Gruetzner <jk...@sa...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Monday 14 July 2008 21:22:31 you wrote:
>> >>> I would think that the gtk mainloop would terminate when the window
>> >>> closes (which termination should propagate back up the stack), but
>> >>> apparently that doesn't happen.
>> >>
>> >> I'm not sure I'm following you at the moment.  Are you calling show()
>> >> once and closing the figure doesn't cause it to return?   or are you
>> >> trying to call show() multiple times from a single script and subsequent
>> >> calls to show() fail to return?
>> >
>> > Hi, Ryan,
>> >
>> > Thanks for your continued help.
>> >
>> > I am calling show() once, and closing the figure doesn't cause it to
>> > return? I've verified the lack of return using debug  sys.stderr.write()
>> > statements, as well as by following  show()  with a sys.exit() command.
>>
>> (Getting this back on the full list...)
>>
>> This sounds like a bug to me, specific to your set up.  I just ran a
>> script (for my own sanity) and closing the figure, resulted in the
>> script exiting and returning to the command prompt.  Do you happen to
>> have a small complete example that replicates your problems that you
>> could post here?
>>
>> Also, what are your versions of matplotlib and PyGtk (you are using
>> GtkAgg, right)? Also, what OS are you running?
>>
>> Devs, what do you think?
>>
>> Ryan
>> --
>> Ryan May
>> Graduate Research Assistant
>> School of Meteorology
>> University of Oklahoma
>
> Thanks, Ryan,  The requested info is below.
> Thanks again.

I am not seeing any problems on the 91 branch or the 98 trunk.  Below
is my command and output (the shell returns when I close the window
with a click)

johnh@flag:svn> python ~/test.py --verbose-helpful -dGTKAgg
$HOME=/home/titan/johnh
CONFIGDIR=/home/titan/johnh/.matplotlib
matplotlib data path
/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/mpl-data
loaded rc file /home/titan/johnh/.matplotlib/matplotlibrc
matplotlib version 0.91.4
verbose.level helpful
interactive is False
units is False
platform is sunos5
numerix numpy 1.2.0.dev5410
Using fontManager instance from /home/titan/johnh/.matplotlib/fontManager.cache
backend GTKAgg version 2.6.0
Begun.Done.johnh@flag:svn>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 14 July 2008 21:22:31 you wrote:
> >>> I would think that the gtk mainloop would terminate when the window
> >>> closes (which termination should propagate back up the stack), but
> >>> apparently that doesn't happen.
> >>
> >> I'm not sure I'm following you at the moment.  Are you calling show()
> >> once and closing the figure doesn't cause it to return?   or are you
> >> trying to call show() multiple times from a single script and subsequent
> >> calls to show() fail to return?
> >
> > Hi, Ryan,
> >
> > Thanks for your continued help.
> >
> > I am calling show() once, and closing the figure doesn't cause it to
> > return? I've verified the lack of return using debug  sys.stderr.write()
> > statements, as well as by following  show()  with a sys.exit() command.
>
> (Getting this back on the full list...)
>
> This sounds like a bug to me, specific to your set up.  I just ran a
> script (for my own sanity) and closing the figure, resulted in the
> script exiting and returning to the command prompt.  Do you happen to
> have a small complete example that replicates your problems that you
> could post here?
>
> Also, what are your versions of matplotlib and PyGtk (you are using
> GtkAgg, right)? Also, what OS are you running?
>
> Devs, what do you think?
>
> Ryan
> --
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma

Thanks, Ryan,  The requested info is below.
Thanks again.
    James

- ----- SMALL COMPLETE EXAMPLE CODE FOLLOWS -------------
#!/usr/bin/python
#  File:  test.py

import os,sys
import pylab as PL
import numpy as N

def main():
  fig = PL.figure(1)
  x = N.arange(120.0)*2*N.pi/120.0
  x = PL.resize(x, (100,120))
  y = N.arange(100.0)*2*N.pi/100.0
  y = N.resize(y, (120,100))
  y = N.transpose(y)
  z = N.sin(x) + N.cos(y)
  PL.imshow( z , cmap=PL.cm.jet)#, interpolation='nearest')
  sys.stderr.write("Begun.")
  PL.show()
  sys.stderr.write("Done.")
  sys.exit(0)

if __name__ == "__main__":
- ---- END OF SAMPLE CODE -------------------

Sample output:
- ------- BEGIN --------------
$ ./test.py
Begun.
- ------- COMMENTS: --------------
              The image displays.
               I click on the X; the image disappears.
              Nothing happens in the terminal output. 
              In the terminal window I type <ctrl>C.
- ------- BEGIN --------------
^CTraceback (most recent call last):
  File "./test.py", line 59, in <module>
    main()
  File "./test.py", line 25, in main
    PL.show()
  File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
line 71, in show
    gtk.main()
KeyboardInterrupt
$
- ------ END OF OUTPUT CODE ----------

The same behavior occurs when run from within an interactive session.

python version:  2.5.1 (4251:54863, Jun 15 2008, 23:59:20)
Matplotlib version:  0.91.2
PyGTK version:  2.12.0-2.fc8
In ~/.matplotlib/matplotlibrc:   backend      : GTKAgg
OS:  Fedora 8
Linux kernel:  2.6.25.6-27.fc8




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFIfKh4xOXthSHeGJIRAvbzAKCF9U7EJ4oM2JyQjKokOBZAv6PSlwCfZV3t
I5jSycQj8dAqI0QGkewAw3o=
=vdPu
-----END PGP SIGNATURE-----

On Tuesday 15 July 2008 09:22:10 am David Kaplan wrote:
> Hi,
>
> I guess the problem was mostly mine.  To my eyes, the Bitstream Vera
> Serif doesn't look very "serif" to me (figure attached), but I am
> probably just not used to that font.  Changing font.serif as suggested
> produced much more similar output.  Thanks and sorry for the unnecessary
> confusion.
>
> However, this brought me to another strange problem.  When I added a
> matplotlibrc file to ~/.matplotlib/ and ran ipython -pylab, none of my
> graphic screens appear (i.e., figure() produces no visible window).
> Plotting works and I can save figures, but they just are not visible.
> It makes no difference what is in the matplotlibrc, an empty file
> produces the same result as a file with directives in it.  Removing
> matplotlibrc allows me to see the plot window.  Does this make any
> sense?

Agg appears to be your default backend. You can set a GUI backend in your 
matplotlibrc and then you will get your windows back.

Darren

On Tue, Jul 15, 2008 at 2:37 AM, Angela Rivera Campos <riv...@in...> wrote:

> matplotlib version 0.90.1
> numerix numpy 1.0.3

your numpy and matplotlib versions are pretty old.  Any chance you can
upgrade to numpy 1.1 and matplotlib 98.1?

JDH

Hi,

I guess the problem was mostly mine.  To my eyes, the Bitstream Vera
Serif doesn't look very "serif" to me (figure attached), but I am
probably just not used to that font.  Changing font.serif as suggested
produced much more similar output.  Thanks and sorry for the unnecessary
confusion.

However, this brought me to another strange problem.  When I added a
matplotlibrc file to ~/.matplotlib/ and ran ipython -pylab, none of my
graphic screens appear (i.e., figure() produces no visible window).
Plotting works and I can save figures, but they just are not visible.
It makes no difference what is in the matplotlibrc, an empty file
produces the same result as a file with directives in it.  Removing
matplotlibrc allows me to see the plot window.  Does this make any
sense?  

Just in case it matters, I am currently using the svn trunk of
matplotlib.

Cheers,
David


 
On Tue, 2008-07-15 at 08:06 -0400, Michael Droettboom wrote:
> I thought you said the normal text looked sans-serif.  The debugging 
> output seems to suggest otherwise.  Maybe you can send me the generated 
> plot as well.
> 
> The default serif font, Bitstream Vera Serif, is not an identical match 
> to the STIX fonts.  The STIX fonts are designed to match Times.  If you 
> have Times (or Times New Roman) installed on your system you can set 
> "font.serif" to "Times" in your matplotlibrc.  That may help the fonts 
> match better.
> 
> Cheers,
> Mike
> 
> David Kaplan wrote:
> > Hi,
> >
> > The output from using debug-annoying is attached.  It all looks
> > relatively normal to me, but perhaps you will see something I don't.  I
> > am thinking that the problem is the difference between Bitstream Serif
> > and the STIX fonts - they are just different.  Perhaps you can suggest a
> > way to change say the fontfamilies that will make them agree.
> >
> > Thanks,
> > David
> >
> >
> >
> >   
> 
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

I thought you said the normal text looked sans-serif.  The debugging 
output seems to suggest otherwise.  Maybe you can send me the generated 
plot as well.

The default serif font, Bitstream Vera Serif, is not an identical match 
to the STIX fonts.  The STIX fonts are designed to match Times.  If you 
have Times (or Times New Roman) installed on your system you can set 
"font.serif" to "Times" in your matplotlibrc.  That may help the fonts 
match better.

Cheers,
Mike

David Kaplan wrote:
> Hi,
>
> The output from using debug-annoying is attached.  It all looks
> relatively normal to me, but perhaps you will see something I don't.  I
> am thinking that the problem is the difference between Bitstream Serif
> and the STIX fonts - they are just different.  Perhaps you can suggest a
> way to change say the fontfamilies that will make them agree.
>
> Thanks,
> David
>
>
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Yes, as of r5747 twinx (well, shared axes specifically) no longer leaks.

Manuel has discovered a seemingly generic leak that occurs when 
pyplot.close() is called and running a GUI backend.  I can confirm his 
results with the script he last sent.

Cheers,
Mike

Manuel Metz wrote:
> John Hunter wrote:
>> On Mon, Jul 14, 2008 at 3:05 PM, Michael Droettboom <md...@st...> 
>> wrote:
>>> I can confirm this.
>>>
>>> Commenting out "del Gcf.figs[num]" in Gcf.destroy (in 
>>> _pylab_helpers.py)
>>> also seems to resolve the leak.  But I have no idea why, so I won't
>>> commit it just yet.  I don't have much time to look deeper now.  Does
>>> anyone (who probably understands figure management better than me) have
>>> an idea what might cause this?
>>
>> Can you post the script you are using to test -- I am a little
>> confused from reading this thread by whether or not twinx is
>> implicated.  Also, I saw that you committed some changes vis-a-vis the
>> twinx leak
>>
>>   r5747 | mdboom | 2008-07-11 13:21:53 -0500 (Fri, 11 Jul 2008) | 2 
>> lines
>>
>>   Fix memory leak when using shared axes.
>>
>> so I thought that part was resolved already...
>>
>> JDH
>
> I use a modified version of the script Laurent Oget posted (see 
> attachment). Here is the output if I don't comment out PL.close(1).
>
> ~/python/test$ python looptest.py -dGTK
> 0 GC 69354 69354 0 13854
> 100 GC 84354 150 0 15163
> 200 GC 99354 150 0 16306
> 300 GC 114354 150 0 17364
> 400 GC 129354 150 0 18576
> ~/python/test$ python looptest.py -dTK
> 0 GC 69521 69521 0 14065
> 100 GC 84521 150 0 15444
> 200 GC 99521 150 0 16581
> 300 GC 114521 150 0 17719
> 400 GC 129521 150 0 18715
> ~/python/test$ python looptest.py -dPS
> 0 GC 59307 59307 0 7705
> 100 GC 59307 0 0 8037
> 200 GC 59307 0 0 8038
> 300 GC 59307 0 0 8038
> 400 GC 59307 0 0 8038
>
> (so for the window-less backend PS no objects are left)
>
> And now I commented out the line PL.close(1):
>
> ~/python/test$ python looptest.py -dGTK
> 0 GC 69379 69379 0 13855
> 100 GC 69379 0 0 14253
> 200 GC 69379 0 0 14253
> 300 GC 69379 0 0 14253
> 400 GC 69379 0 0 14252
>
> Manuel

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,

The output from using debug-annoying is attached.  It all looks
relatively normal to me, but perhaps you will see something I don't.  I
am thinking that the problem is the difference between Bitstream Serif
and the STIX fonts - they are just different.  Perhaps you can suggest a
way to change say the fontfamilies that will make them agree.

Thanks,
David



-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France

Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

First of all, thank you all for the help.

 > My guess is there is something triggered by a pylab
 > numpy/numerix/Numeric import, but w/o kjnowing more about your
 > matplotlib and other software versions is it difficult to guess.
 > Could you put these lines into a test script and run them with
 >
 >> python myscript.py --verbose-debug
 >
 > and paste the output.

Here's the output for my dummy script. I'm using pylab functions: show, 
figure and bar, though just importing pylab without actually using the 
functions produces the same problems, that's why at first I thought the 
problem is related with something in the import.

-----------
matplotlib data path usr/lib/python2.5/site-packages/matplotlib/mpl-data
$HOME=/home/myhome
CONFIGDIR=/home/myhome/.matplotlib
loaded rc file /home/myhome/.matplotlib/matplotlibrc
matplotlib version 0.90.1
verbose.level debug
interactive is False
units is True
platform is linux2
loaded modules: ['pylab', 'distutils.distutils', '_bisect', 
'__future__', 'copy_reg', 'sre_compile', 'distutils', 'itertools', 
'_hashlib', '_sre', '__main__', 'site', '__builtin__', 'datetime', 
'distutils.re', 'matplotlib.re', 'matplotlib.tempfile', 'encodings', 
'encodings.encodings', 'shutil', 'distutils.string', 'dateutil', 
'matplotlib.datetime', 'posixpath', '_random', 'tempfile', 'errno', 
'matplotlib.warnings', 'binascii', 'encodings.codecs', 'sre_constants', 
're', 'matplotlib.md5', 'os.path', 'pytz.sys', '_codecs', 
'distutils.sysconfig', 'pytz.sets', 'math', 'fcntl', 'stat', 
'zipimport', 'string', 'warnings', 'encodings.types', 'UserDict', 
'encodings.utf_8', 'matplotlib', 'distutils.os', 'sys', 'pytz.tzinfo', 
'pytz', 'pytz.datetime', 'matplotlib.__future__', 'codecs', 
'matplotlib.sys', 'matplotlib.pytz', 'types', 'md5', '_types', 
'matplotlib.dateutil', 'hashlib', 'matplotlib.os', 'thread', 'bisect', 
'matplotlib.distutils', 'signal', 'distutils.errors', 'random', 
'linecache', 'matplotlib.shutil', 'posix', 'encodings.aliases', 'sets', 
'exceptions', 'sre_parse', 'pytz.bisect', 'distutils.sys', 'os', 'strop']
numerix numpy 1.0.3
font search path 
['/usr/lib/python2.5/site-packages/matplotlib/mpl-data/fonts/ttf', 
'/usr/lib/python2.5/site-packages/matplotlib/mpl-data/fonts/afm']
trying fontname 
/usr/lib/python2.5/site-packages/matplotlib/mpl-data/fonts/ttf/VeraMoIt.ttf
trying fontname 
/usr/lib/python2.5/site-packages/matplotlib/mpl-data/fonts/ttf/cmmi10.ttf
trying fontname 
/usr/lib/python2.5/site-packages/matplotlib/mpl-data/fonts/ttf/VeraSeBd.ttf
trying fontname 
/usr/lib/python2.5/site-packages/matplotlib/mpl-data/fonts/ttf/cmsy10.ttf
trying fontname 
/usr/lib/python2.5/site-packages/matplotlib/mpl-data/fonts/ttf/VeraIt.ttf
trying fontname 
/usr/lib/python2.5/site-packages/matplotlib/mpl-data/fonts/ttf/VeraMoBd.ttf
trying fontname 
/usr/lib/python2.5/site-packages/matplotlib/mpl-data/fonts/ttf/cmex10.ttf
trying fontname 
/usr/lib/python2.5/site-packages/matplotlib/mpl-data/fonts/ttf/cmtt10.ttf
trying fontname 
/usr/lib/python2.5/site-packages/matplotlib/mpl-data/fonts/ttf/Vera.ttf
loaded ttfcache file /home/riveraca/.matplotlib/ttffont.cache
backend GTKAgg version 2.10.3
PROTON DOSE SPECTRUM
(0.0, 0.0, 0.0, 616.0, 24.0, 616.0) <type 'tuple'> <type 'float'>
(0.0, 0.0, 0.0, 28869.0, 169.0, 28869.0) <type 'tuple'> <type 'float'>
(0.0, 0.0, 0.0, 13900.0, 117.0, 13900.0) <type 'tuple'> <type 'float'>
(0.0, 0.0, 0.0, 6896.0, 83.0, 6896.0) <type 'tuple'> <type 'float'>
(0.0, 0.0, 0.0, 3749.0, 61.0, 3749.0) <type 'tuple'> <type 'float'>
	findfont failed Bitstream Vera Serif, New Century Schoolbook, Century 
Schoolbook L, Utopia, ITC Bookman, Bookman, Nimbus Roman No9 L, Times 
New Roman, Times, Palatino, Charter, serif
Could not match Bitstream Vera Serif, New Century Schoolbook, Century 
Schoolbook L, Utopia, ITC Bookman, Bookman, Nimbus Roman No9 L, Times 
New Roman, Times, Palatino, Charter, serif, normal, normal.  Returning 
/usr/lib/python2.5/site-packages/matplotlib/mpl-data/fonts/ttf/Vera.ttf
-----------
> 
> 
> Florian Koelling recently reported a problem that sounded very similar
> under the heading "mad interference between matplotlib and openbabel".
>  Apparently some pylab import is doing something funky with some third
> party libs.
> 
> Could you test just the numpy imports to see if that makes a
> difference.  Ie, instead of importing pylab before your module code,
> do the following:
> 
> import numpy
> import numpy.fft
> importnumpy.random
> import numpy.linalg
> 
> and let us know if you see similar problems.
> 
> JDH
> 

I've tried with just these imports and there's no problem with that, 
everything runs ok, it's when I add the pylab imports when everything 
goes wrong. I've tried with these three posibilities and the result is 
always the same:

import pylab

from pylab import *

from pylab import figure, show, bar


AR

John Hunter wrote:
> On Mon, Jul 14, 2008 at 3:05 PM, Michael Droettboom <md...@st...> wrote:
>> I can confirm this.
>>
>> Commenting out "del Gcf.figs[num]" in Gcf.destroy (in _pylab_helpers.py)
>> also seems to resolve the leak.  But I have no idea why, so I won't
>> commit it just yet.  I don't have much time to look deeper now.  Does
>> anyone (who probably understands figure management better than me) have
>> an idea what might cause this?
> 
> Can you post the script you are using to test -- I am a little
> confused from reading this thread by whether or not twinx is
> implicated.  Also, I saw that you committed some changes vis-a-vis the
> twinx leak
> 
>   r5747 | mdboom | 2008-07-11 13:21:53 -0500 (Fri, 11 Jul 2008) | 2 lines
> 
>   Fix memory leak when using shared axes.
> 
> so I thought that part was resolved already...
> 
> JDH

I use a modified version of the script Laurent Oget posted (see 
attachment). Here is the output if I don't comment out PL.close(1).

~/python/test$ python looptest.py -dGTK
0 GC 69354 69354 0 13854
100 GC 84354 150 0 15163
200 GC 99354 150 0 16306
300 GC 114354 150 0 17364
400 GC 129354 150 0 18576
~/python/test$ python looptest.py -dTK
0 GC 69521 69521 0 14065
100 GC 84521 150 0 15444
200 GC 99521 150 0 16581
300 GC 114521 150 0 17719
400 GC 129521 150 0 18715
~/python/test$ python looptest.py -dPS
0 GC 59307 59307 0 7705
100 GC 59307 0 0 8037
200 GC 59307 0 0 8038
300 GC 59307 0 0 8038
400 GC 59307 0 0 8038

(so for the window-less backend PS no objects are left)

And now I commented out the line PL.close(1):

~/python/test$ python looptest.py -dGTK
0 GC 69379 69379 0 13855
100 GC 69379 0 0 14253
200 GC 69379 0 0 14253
300 GC 69379 0 0 14253
400 GC 69379 0 0 14252

Manuel

>>> I would think that the gtk mainloop would terminate when the window
>>> closes (which termination should propagate back up the stack), but
>>> apparently that doesn't happen.
>> I'm not sure I'm following you at the moment.  Are you calling show()
>> once and closing the figure doesn't cause it to return?   or are you
>> trying to call show() multiple times from a single script and subsequent
>> calls to show() fail to return?
> 
> Hi, Ryan,
> 
> Thanks for your continued help.
> 
> I am calling show() once, and closing the figure doesn't cause it to return?  
> I've verified the lack of return using debug  sys.stderr.write() statements, 
> as well as by following  show()  with a sys.exit() command.
> 
(Getting this back on the full list...)

This sounds like a bug to me, specific to your set up.  I just ran a 
script (for my own sanity) and closing the figure, resulted in the 
script exiting and returning to the command prompt.  Do you happen to 
have a small complete example that replicates your problems that you 
could post here?

Also, what are your versions of matplotlib and PyGtk (you are using 
GtkAgg, right)? Also, what OS are you running?

Devs, what do you think?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi Lubos,

Lubos Vrbka wrote:
>> 1. Would it be possible to do only shallow copy of the arrays that are
>> being plotted so that on redrawing the figure, chanes in the datasets
>> would be picked up automatically? If not, is Line2D.set_data(...) the
>> right approach?
>>     
> isn't this the way how the plotting is done? in my experience (iirc), 
> the following thing works (x, y1, y2 are numpy arrays):
>
> pylab.ion()
>
> a, = pylab.plot(x,y1)
> b, = pylab.plot(x,y2)
> ...
> y1 += 10
> y2 += 20
>
> a.set_ydata(y1)
> b.set_ydata(y2)
> pylab.draw()
>
> y1 += 10
> y2 += 20
> a.set_ydata(y1)
> pylab.draw()
>
> in my experience BOTH plots get updated in this procedure, so i have to 
> do first a deep copy in my case to get rid of these 'unwanted effects'...
>   
If I understand correctly the len of  X and Y will be changing, 
therefore you may have to use set_data() function of Line2D

set_data(self, *args)
Set the x and y data
ACCEPTS: (array xdata, array ydata)

I seem to remember getting a size mismatch if X and Y grew in length and 
I tried to use set_xdata() or set_ydata() separately.

YMMV
Steve

Hi,

Try

 mylines = plot1.get_lines()
 plot2.legend(mylines, [p.get_label() for p in mylines])

When you call the legend method with two arguments, first argument is
a list of lines and second argument is a list of labels. It does not
seem to matter whether lines are from same axes.
Hope this helps.

-JJ



On Mon, Jul 14, 2008 at 12:47 PM, David Lonie <lon...@gm...> wrote:
> I have an application that has 2 subplots, and I'd like to use the second to
> display the legend for the first. For example, for subplots plot1 and plot2:
>
> plot1.plot((1,2,3,4), label='up', color = 'g')
> plot1.plot((4,3,2,1), label='down', color = 'b')
>
> plot2.legend("What can I put here to display a legend for plot1 on
> plot2???")
>
> Can this be done?
>
> Thanks,
>
> Dave
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

On Mon, Jul 14, 2008 at 3:05 PM, Michael Droettboom <md...@st...> wrote:
> I can confirm this.
>
> Commenting out "del Gcf.figs[num]" in Gcf.destroy (in _pylab_helpers.py)
> also seems to resolve the leak.  But I have no idea why, so I won't
> commit it just yet.  I don't have much time to look deeper now.  Does
> anyone (who probably understands figure management better than me) have
> an idea what might cause this?

Can you post the script you are using to test -- I am a little
confused from reading this thread by whether or not twinx is
implicated.  Also, I saw that you committed some changes vis-a-vis the
twinx leak

  r5747 | mdboom | 2008-07-11 13:21:53 -0500 (Fri, 11 Jul 2008) | 2 lines

  Fix memory leak when using shared axes.

so I thought that part was resolved already...

JDH

I can confirm this.

Commenting out "del Gcf.figs[num]" in Gcf.destroy (in _pylab_helpers.py) 
also seems to resolve the leak.  But I have no idea why, so I won't 
commit it just yet.  I don't have much time to look deeper now.  Does 
anyone (who probably understands figure management better than me) have 
an idea what might cause this?

Cheers,
Mike

Manuel Metz wrote:
> Michael Droettboom wrote:
>> Which backend?
>
> GTK, GTKAgg, TK, but not with any backend without a window: Agg, 
> Cairo, PS, PDF, SVG ...
>
> Cheers,
>   Manuel
>
>> Cheers,
>> Mike
>>
>> Manuel Metz wrote:
>>> Michael Droettboom wrote:
>>>> Thanks for the report.  So we can diagnose this, what version of 
>>>> matplotlib are you reporting this for?
>>>>
>>>> Also, you may be interested in the following FAQ (and the one 
>>>> following it):
>>>>
>>>> http://matplotlib.sourceforge.net/faq.html#LEAKS
>>>
>>> Hi,
>>>
>>>   I tested this with the lastest svn, and I do also see a leak. But 
>>> it's not related to twinx, but to pylab.close(). If I just comment 
>>> out this one line, the memleak disappears ...
>>>
>>> Manuel
>>>
>>>> Cheers,
>>>> Mike
>>>>
>>>> laurent oget wrote:
>>>>> i forgot two imports.
>>>>>
>>>>> import math
>>>>> import gc
>>>>> import pylab as PL
>>>>>
>>>>>
>>>>> def looptest():
>>>>>     while(1):
>>>>>         fig=PL.figure(1)
>>>>>         ax=fig.add_subplot(211)
>>>>>         ax.set_position((0,0,0.9,0.45))
>>>>>         ax1=PL.twinx(ax)
>>>>>         t=range(1000)
>>>>>         st=[math.sin(x*0.01) for x in t]
>>>>>         ax.plot(t,st)
>>>>>         fig.clf()
>>>>>         PL.close(1)
>>>>>         gc.collect()
>>>>>         print "GC"
>>>>>         print len(gc.get_objects())
>>>>>         print len(gc.garbage)
>>>>> looptest()
>>>>> 2008/7/11 laurent oget <la...@og... <mailto:la...@og...>>:
>>>>>
>>>>>     I think i narrowed down the memory leak i have been chasing for a
>>>>>     while.
>>>>>     If i remove the call to twinx i get a slow leak, which would 
>>>>> cause
>>>>>     me trouble
>>>>>     after a very long time. With the call to  twinx, however i am
>>>>>     losing thousands of objects
>>>>>     at each loop.
>>>>>
>>>>>     Thanks,
>>>>>
>>>>>     Laurent
>>>>>
>>>>>
>>>>>     >>>>>>>>>>>>>>>>>>>>>>>>>          import pylab as PL
>>>>>     def looptest():
>>>>>         while(1):
>>>>>             fig=PL.figure(1)
>>>>>             ax=fig.add_subplot(211)
>>>>>             ax.set_position((0,0,0.9,0.45))
>>>>>             ax1=PL.twinx(ax)
>>>>>             t=range(1000)
>>>>>             st=[math.sin(x*0.01) for x in t]
>>>>>             ax.plot(t,st)
>>>>>             fig.clf()
>>>>>             PL.close(1)
>>>>>             gc.collect()
>>>>>             print "GC"
>>>>>             print len(gc.get_objects())
>>>>>             print len(gc.garbage)
>>>>>     looptest()
>>>>>     >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------- 
>>>>>
>>>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>>>> Studies have shown that voting for your favorite open source project,
>>>>> along with a healthy diet, reduces your potential for chronic 
>>>>> lameness
>>>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Matplotlib-users mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>   
>>>>
>>>
>>

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> Which backend?

GTK, GTKAgg, TK, but not with any backend without a window: Agg, Cairo, 
PS, PDF, SVG ...

Cheers,
   Manuel

> Cheers,
> Mike
> 
> Manuel Metz wrote:
>> Michael Droettboom wrote:
>>> Thanks for the report.  So we can diagnose this, what version of 
>>> matplotlib are you reporting this for?
>>>
>>> Also, you may be interested in the following FAQ (and the one 
>>> following it):
>>>
>>> http://matplotlib.sourceforge.net/faq.html#LEAKS
>>
>> Hi,
>>
>>   I tested this with the lastest svn, and I do also see a leak. But 
>> it's not related to twinx, but to pylab.close(). If I just comment out 
>> this one line, the memleak disappears ...
>>
>> Manuel
>>
>>> Cheers,
>>> Mike
>>>
>>> laurent oget wrote:
>>>> i forgot two imports.
>>>>
>>>> import math
>>>> import gc
>>>> import pylab as PL
>>>>
>>>>
>>>> def looptest():
>>>>     while(1):
>>>>         fig=PL.figure(1)
>>>>         ax=fig.add_subplot(211)
>>>>         ax.set_position((0,0,0.9,0.45))
>>>>         ax1=PL.twinx(ax)
>>>>         t=range(1000)
>>>>         st=[math.sin(x*0.01) for x in t]
>>>>         ax.plot(t,st)
>>>>         fig.clf()
>>>>         PL.close(1)
>>>>         gc.collect()
>>>>         print "GC"
>>>>         print len(gc.get_objects())
>>>>         print len(gc.garbage)
>>>> looptest()
>>>> 2008/7/11 laurent oget <la...@og... <mailto:la...@og...>>:
>>>>
>>>>     I think i narrowed down the memory leak i have been chasing for a
>>>>     while.
>>>>     If i remove the call to twinx i get a slow leak, which would cause
>>>>     me trouble
>>>>     after a very long time. With the call to  twinx, however i am
>>>>     losing thousands of objects
>>>>     at each loop.
>>>>
>>>>     Thanks,
>>>>
>>>>     Laurent
>>>>
>>>>
>>>>     >>>>>>>>>>>>>>>>>>>>>>>>>          import pylab as PL
>>>>     def looptest():
>>>>         while(1):
>>>>             fig=PL.figure(1)
>>>>             ax=fig.add_subplot(211)
>>>>             ax.set_position((0,0,0.9,0.45))
>>>>             ax1=PL.twinx(ax)
>>>>             t=range(1000)
>>>>             st=[math.sin(x*0.01) for x in t]
>>>>             ax.plot(t,st)
>>>>             fig.clf()
>>>>             PL.close(1)
>>>>             gc.collect()
>>>>             print "GC"
>>>>             print len(gc.get_objects())
>>>>             print len(gc.garbage)
>>>>     looptest()
>>>>     >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> ------------------------------------------------------------------------- 
>>>>
>>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>>> Studies have shown that voting for your favorite open source project,
>>>> along with a healthy diet, reduces your potential for chronic lameness
>>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> _______________________________________________
>>>> Matplotlib-users mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>   
>>>
>>
> 

Which backend?

Cheers,
Mike

Manuel Metz wrote:
> Michael Droettboom wrote:
>> Thanks for the report.  So we can diagnose this, what version of 
>> matplotlib are you reporting this for?
>>
>> Also, you may be interested in the following FAQ (and the one 
>> following it):
>>
>> http://matplotlib.sourceforge.net/faq.html#LEAKS
>
> Hi,
>
>   I tested this with the lastest svn, and I do also see a leak. But 
> it's not related to twinx, but to pylab.close(). If I just comment out 
> this one line, the memleak disappears ...
>
> Manuel
>
>> Cheers,
>> Mike
>>
>> laurent oget wrote:
>>> i forgot two imports.
>>>
>>> import math
>>> import gc
>>> import pylab as PL
>>>
>>>
>>> def looptest():
>>>     while(1):
>>>         fig=PL.figure(1)
>>>         ax=fig.add_subplot(211)
>>>         ax.set_position((0,0,0.9,0.45))
>>>         ax1=PL.twinx(ax)
>>>         t=range(1000)
>>>         st=[math.sin(x*0.01) for x in t]
>>>         ax.plot(t,st)
>>>         fig.clf()
>>>         PL.close(1)
>>>         gc.collect()
>>>         print "GC"
>>>         print len(gc.get_objects())
>>>         print len(gc.garbage)
>>> looptest()
>>> 2008/7/11 laurent oget <la...@og... <mailto:la...@og...>>:
>>>
>>>     I think i narrowed down the memory leak i have been chasing for a
>>>     while.
>>>     If i remove the call to twinx i get a slow leak, which would cause
>>>     me trouble
>>>     after a very long time. With the call to  twinx, however i am
>>>     losing thousands of objects
>>>     at each loop.
>>>
>>>     Thanks,
>>>
>>>     Laurent
>>>
>>>
>>>     >>>>>>>>>>>>>>>>>>>>>>>>>          import pylab as PL
>>>     def looptest():
>>>         while(1):
>>>             fig=PL.figure(1)
>>>             ax=fig.add_subplot(211)
>>>             ax.set_position((0,0,0.9,0.45))
>>>             ax1=PL.twinx(ax)
>>>             t=range(1000)
>>>             st=[math.sin(x*0.01) for x in t]
>>>             ax.plot(t,st)
>>>             fig.clf()
>>>             PL.close(1)
>>>             gc.collect()
>>>             print "GC"
>>>             print len(gc.get_objects())
>>>             print len(gc.garbage)
>>>     looptest()
>>>     >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> ------------------------------------------------------------------------- 
>>>
>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>> Studies have shown that voting for your favorite open source project,
>>> along with a healthy diet, reduces your potential for chronic lameness
>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>   
>>
>

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> Thanks for the report.  So we can diagnose this, what version of 
> matplotlib are you reporting this for?
> 
> Also, you may be interested in the following FAQ (and the one following it):
> 
> http://matplotlib.sourceforge.net/faq.html#LEAKS

Hi,

   I tested this with the lastest svn, and I do also see a leak. But 
it's not related to twinx, but to pylab.close(). If I just comment out 
this one line, the memleak disappears ...

Manuel

> Cheers,
> Mike
> 
> laurent oget wrote:
>> i forgot two imports.
>>
>> import math
>> import gc
>> import pylab as PL
>>
>>
>> def looptest():
>>     while(1):
>>         fig=PL.figure(1)
>>         ax=fig.add_subplot(211)
>>         ax.set_position((0,0,0.9,0.45))
>>         ax1=PL.twinx(ax)
>>         t=range(1000)
>>         st=[math.sin(x*0.01) for x in t]
>>         ax.plot(t,st)
>>         fig.clf()
>>         PL.close(1)
>>         gc.collect()
>>         print "GC"
>>         print len(gc.get_objects())
>>         print len(gc.garbage)
>> looptest()
>> 2008/7/11 laurent oget <la...@og... <mailto:la...@og...>>:
>>
>>     I think i narrowed down the memory leak i have been chasing for a
>>     while.
>>     If i remove the call to twinx i get a slow leak, which would cause
>>     me trouble
>>     after a very long time. With the call to  twinx, however i am
>>     losing thousands of objects
>>     at each loop.
>>
>>     Thanks,
>>
>>     Laurent
>>
>>
>>     >>>>>>>>>>>>>>>>>>>>>>>>>      
>>     import pylab as PL
>>     def looptest():
>>         while(1):
>>             fig=PL.figure(1)
>>             ax=fig.add_subplot(211)
>>             ax.set_position((0,0,0.9,0.45))
>>             ax1=PL.twinx(ax)
>>             t=range(1000)
>>             st=[math.sin(x*0.01) for x in t]
>>             ax.plot(t,st)
>>             fig.clf()
>>             PL.close(1)
>>             gc.collect()
>>             print "GC"
>>             print len(gc.get_objects())
>>             print len(gc.garbage)
>>     looptest()
>>     >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>   
> 

Hello Jeff,

> Timme:  Here's one way to do it
many thanks so far. I still have to inspect and improve my script. But 
at least your code lead me to some contourd surface.

I will come back and tell if it worked. Unfortunately I cannot disclose 
the data nor the results because of copyright issues.

So this mail is just to thank you for your responsiveness to my questions.

Timmie

I have an application that has 2 subplots, and I'd like to use the second to
display the legend for the first. For example, for subplots plot1 and plot2:

plot1.plot((1,2,3,4), label='up', color = 'g')
plot1.plot((4,3,2,1), label='down', color = 'b')

plot2.legend("What can I put here to display a legend for plot1 on
plot2???")

Can this be done?

Thanks,

Dave

Tim Michelsen wrote:
> Hello,
> thanks.
> I checked again from contour_demo.py of the basemap distribution.
>
> There lats, lons are uniquely monoton increasing from 0-360 and from -90 to 90.
> In my case data is written row-by-row:
> * increasing from lowest latitude western most longitude to easternmost
> longitude and then increasing each rows in the same manner to the northermost
> latitude (see below). 
>
> So, as you said, it's a question of re-aranging the data. that it fits the to
> the way m.contour expects the 2-D array.
> Also, since the grid is still coarse, I would need to apply some smoothing
> afterwards. What do you recommend for that?
>   
Timme:  Here's one way to do it

from matplotlib.mlab import load
import matplotlib.pyplot as plt
import numpy as np
data = load("data.txt")
# need to know nlons and nlats beforehand!
nlons = 8; nlats = 25
X = data[0::nlats,0]
Y = data[0:nlats,1]
# data is in nlons,nlats order in file, need to transpose
Z = data[:,2].reshape(nlons,nlats).transpose()
X,Y = np.meshgrid(X,Y)
CS = plt.contourf(X,Y,Z,20)
plt.show()

I don't have any recommendations for smoothing - why don't you plot the 
raw data first and see if you really need it?           
> I don't know how I can do this easily by hand. May you give me some guidance
> here, please?
>
> But I may just convert it to a shape file using GIS then load it with the
> shapefile interface you wrote.
> What would you see as most convenient way?
> If I produce maps with a GIS but want to use matplotlib for the map plotting,
> what would be the preferred export format? Any gdal format?
>   
I prefer netCDF format for gridded data (basemap contains a function for 
reading netCDF files - NetCDFFile).

-Jeff
> Many thanks in advance,
> Timmie
>
> ### data example
>
> Latitude	Longitude	value
> 45	7	7.65251434
> 45	7.25	6.841345477
> 45	7.5	3.923153289
> 45	7.75	3.644313708
> 45	8	3.550977951
> 45	8.25	3.352525137
> 45	8.5	3.080082094
> 45	8.75	2.971992657
> 45	9	2.998723785
> 45	9.25	3.080082094
> 45	9.5	3.185687405
> 45	9.75	3.102075854
> 45	10	3.185687405
> 45	10.25	3.213960325
> 45	10.5	3.32326373
> 45	10.75	3.465643983
> 45	11	3.612980369
> 45	11.25	3.644313708
> 45	11.5	3.701277511
> 45	11.75	3.923153289
> 45	12	3.797848342
> 45	12.25	3.612980369
> 45	12.5	3.435577844
> 45	12.75	3.294210812
> 45	13	3.26536503
> 45.25	7	6.485050223
> 45.25	7.25	6.343081631
> 45.25	7.5	3.856783573
> 45.25	7.75	3.405725407
> 45.25	8	3.550977951
> 45.25	8.25	3.294210812
> 45.25	8.5	3.294210812
> 45.25	8.75	3.185687405
> 45.25	9	3.15761656
> 45.25	9.25	3.213960325
> 45.25	9.5	3.15761656
> 45.25	9.75	3.32326373
> 45.25	10	3.405725407
> 45.25	10.25	3.495925216
> 45.25	10.5	3.465643983
> 45.25	10.75	3.550977951
> 45.25	11	3.465643983
> 45.25	11.25	3.765429652
> 45.25	11.5	3.95669157
> 45.25	11.75	3.797848342
> 45.25	12	3.923153289
> 45.25	12.25	3.733239867
> 45.25	12.5	3.550977951
> 45.25	12.75	3.520306012
> 45.25	13	3.376085288
> 45.5	7	6.383367092
> 45.5	7.25	6.383367092
> 45.5	7.5	6.009422688
> 45.5	7.75	4.679469855
> 45.5	8	3.435577844
> 45.5	8.25	3.435577844
> 45.5	8.5	3.236725042
> 45.5	8.75	3.236725042
> 45.5	9	3.185687405
> 45.5	9.25	3.102075854
> 45.5	9.5	3.102075854
> 45.5	9.75	3.185687405
> 45.5	10	3.352525137
> 45.5	10.25	3.405725407
> 45.5	10.5	3.376085288
> 45.5	10.75	3.612980369
> 45.5	11	3.520306012
> 45.5	11.25	3.352525137
> 45.5	11.5	3.823949103
> 45.5	11.75	3.856783573
> 45.5	12	3.856783573
> 45.5	12.25	3.765429652
> 45.5	12.5	3.669541114
> 45.5	12.75	3.550977951
> 45.5	13	3.435577844
> 45.75	7	5.309043916
> 45.75	7.25	6.057519881
> 45.75	7.5	5.030958443
> 45.75	7.75	4.836570243
> 45.75	8	4.836570243
> 45.75	8.25	2.724965001
> 45.75	8.5	2.607751091
> 45.75	8.75	3.26536503
> 45.75	9	2.898163214
> 45.75	9.25	2.872155245
> 45.75	9.5	1.893252754
> 45.75	9.75	2.043669061
> 45.75	10	1.75488883
> 45.75	10.25	2.004264146
> 45.75	10.5	2.971992657
> 45.75	10.75	1.804949998
> 45.75	11	2.846334614
> 45.75	11.25	5.519419657
> 45.75	11.5	2.517818813
> 45.75	11.75	3.733239867
> 45.75	12	3.376085288
> 45.75	12.25	3.550977951
> 45.75	12.5	3.612980369
> 45.75	12.75	3.520306012
> 45.75	13	3.495925216
> 46	7	5.06399168
> 46	7.25	4.949174095
> 46	7.5	5.266087828
> 46	7.75	5.352298328
> 46	8	4.757472437
> 46	8.25	2.800325674
> 46	8.5	3.612980369
> 46	8.75	3.185687405
> 46	9	2.323282473
> 46	9.25	1.671485743
> 46	9.5	3.856783573
> 46	9.75	4.572079662
> 46	10	4.679469855
> 46	10.25	4.679469855
> 46	10.5	5.309043916
> 46	10.75	3.294210812
> 46	11	3.405725407
> 46	11.25	3.669541114
> 46	11.5	3.495925216
> 46	11.75	4.255093726
> 46	12	3.495925216
> 46	12.25	3.185687405
> 46	12.5	3.213960325
> 46	12.75	3.550977951
> 46	13	3.520306012
> 46.25	7	1.969297411
> 46.25	7.25	4.908706364
> 46.25	7.5	3.052767233
> 46.25	7.75	3.765429652
> 46.25	8	3.95669157
> 46.25	8.25	5.06399168
> 46.25	8.5	5.266087828
> 46.25	8.75	3.669541114
> 46.25	9	3.185687405
> 46.25	9.25	3.797848342
> 46.25	9.5	3.352525137
> 46.25	9.75	5.439709782
> 46.25	10	5.69098301
> 46.25	10.25	4.949174095
> 46.25	10.5	5.736883145
> 46.25	10.75	5.105542055
> 46.25	11	4.255093726
> 46.25	11.25	3.701277511
> 46.25	11.5	4.255093726
> 46.25	11.75	4.572079662
> 46.25	12	3.98369323
> 46.25	12.25	4.148941623
> 46.25	12.5	3.129746478
> 46.25	12.75	3.236725042
> 46.25	13	3.550977951
> 46.5	7	2.872155245
> 46.5	7.25	3.701277511
> 46.5	7.5	3.15761656
> 46.5	7.75	3.765429652
> 46.5	8	5.18951259
> 46.5	8.25	6.105948261
> 46.5	8.5	5.266087828
> 46.5	8.75	5.69098301
> 46.5	9	6.009422688
> 46.5	9.25	5.147381739
> 46.5	9.5	5.829636932
> 46.5	9.75	5.654489904
> 46.5	10	6.243327668
> 46.5	10.25	5.395852976
> 46.5	10.5	5.736883145
> 46.5	10.75	6.057519881
> 46.5	11	5.147381739
> 46.5	11.25	3.520306012
> 46.5	11.5	3.856783573
> 46.5	11.75	4.148941623
> 46.5	12	4.71833512
> 46.5	12.25	4.71833512
> 46.5	12.5	3.701277511
> 46.5	12.75	3.889851131
> 46.5	13	3.32326373
> 46.75	7	1.859766825
> 46.75	7.25	2.198852355
> 46.75	7.5	2.345277833
> 46.75	7.75	2.517818813
> 46.75	8	3.856783573
> 46.75	8.25	3.856783573
> 46.75	8.5	5.06399168
> 46.75	8.75	4.184077131
> 46.75	9	5.829636932
> 46.75	9.25	3.644313708
> 46.75	9.5	3.765429652
> 46.75	9.75	5.309043916
> 46.75	10	6.009422688
> 46.75	10.25	5.147381739
> 46.75	10.5	5.609155594
> 46.75	10.75	5.783100444
> 46.75	11	5.147381739
> 46.75	11.25	3.581868928
> 46.75	11.5	4.908706364
> 46.75	11.75	3.465643983
> 46.75	12	3.465643983
> 46.75	12.25	4.148941623
> 46.75	12.5	3.98369323
> 46.75	12.75	3.581868928
> 46.75	13	3.644313708
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>   


-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

On Mon, Jul 14, 2008 at 9:49 AM, Ben Axelrod <bax...@co...> wrote:
> The RectangleSelector has parameters for the min span in the x and y
> directions of the rectangle.  The units of these are the axes units.  It
> would be nice if there was an additional similar min size requirement, but
> in units of pixels.  This way it would be independent of the axes scale.

Good idea -- I added this to svn r5769.  Here is some example usage:

LS = RectangleSelector(current_ax, line_select_callback,
                       drawtype='box',useblit=True,
                       minspanx=5,minspany=5,spancoords='pixels')

Hello,
thanks.
I checked again from contour_demo.py of the basemap distribution.

There lats, lons are uniquely monoton increasing from 0-360 and from -90 to 90.
In my case data is written row-by-row:
* increasing from lowest latitude western most longitude to easternmost
longitude and then increasing each rows in the same manner to the northermost
latitude (see below). 

So, as you said, it's a question of re-aranging the data. that it fits the to
the way m.contour expects the 2-D array.
Also, since the grid is still coarse, I would need to apply some smoothing
afterwards. What do you recommend for that?

I don't know how I can do this easily by hand. May you give me some guidance
here, please?

But I may just convert it to a shape file using GIS then load it with the
shapefile interface you wrote.
What would you see as most convenient way?
If I produce maps with a GIS but want to use matplotlib for the map plotting,
what would be the preferred export format? Any gdal format?

Many thanks in advance,
Timmie

### data example

Latitude	Longitude	value
45	7	7.65251434
45	7.25	6.841345477
45	7.5	3.923153289
45	7.75	3.644313708
45	8	3.550977951
45	8.25	3.352525137
45	8.5	3.080082094
45	8.75	2.971992657
45	9	2.998723785
45	9.25	3.080082094
45	9.5	3.185687405
45	9.75	3.102075854
45	10	3.185687405
45	10.25	3.213960325
45	10.5	3.32326373
45	10.75	3.465643983
45	11	3.612980369
45	11.25	3.644313708
45	11.5	3.701277511
45	11.75	3.923153289
45	12	3.797848342
45	12.25	3.612980369
45	12.5	3.435577844
45	12.75	3.294210812
45	13	3.26536503
45.25	7	6.485050223
45.25	7.25	6.343081631
45.25	7.5	3.856783573
45.25	7.75	3.405725407
45.25	8	3.550977951
45.25	8.25	3.294210812
45.25	8.5	3.294210812
45.25	8.75	3.185687405
45.25	9	3.15761656
45.25	9.25	3.213960325
45.25	9.5	3.15761656
45.25	9.75	3.32326373
45.25	10	3.405725407
45.25	10.25	3.495925216
45.25	10.5	3.465643983
45.25	10.75	3.550977951
45.25	11	3.465643983
45.25	11.25	3.765429652
45.25	11.5	3.95669157
45.25	11.75	3.797848342
45.25	12	3.923153289
45.25	12.25	3.733239867
45.25	12.5	3.550977951
45.25	12.75	3.520306012
45.25	13	3.376085288
45.5	7	6.383367092
45.5	7.25	6.383367092
45.5	7.5	6.009422688
45.5	7.75	4.679469855
45.5	8	3.435577844
45.5	8.25	3.435577844
45.5	8.5	3.236725042
45.5	8.75	3.236725042
45.5	9	3.185687405
45.5	9.25	3.102075854
45.5	9.5	3.102075854
45.5	9.75	3.185687405
45.5	10	3.352525137
45.5	10.25	3.405725407
45.5	10.5	3.376085288
45.5	10.75	3.612980369
45.5	11	3.520306012
45.5	11.25	3.352525137
45.5	11.5	3.823949103
45.5	11.75	3.856783573
45.5	12	3.856783573
45.5	12.25	3.765429652
45.5	12.5	3.669541114
45.5	12.75	3.550977951
45.5	13	3.435577844
45.75	7	5.309043916
45.75	7.25	6.057519881
45.75	7.5	5.030958443
45.75	7.75	4.836570243
45.75	8	4.836570243
45.75	8.25	2.724965001
45.75	8.5	2.607751091
45.75	8.75	3.26536503
45.75	9	2.898163214
45.75	9.25	2.872155245
45.75	9.5	1.893252754
45.75	9.75	2.043669061
45.75	10	1.75488883
45.75	10.25	2.004264146
45.75	10.5	2.971992657
45.75	10.75	1.804949998
45.75	11	2.846334614
45.75	11.25	5.519419657
45.75	11.5	2.517818813
45.75	11.75	3.733239867
45.75	12	3.376085288
45.75	12.25	3.550977951
45.75	12.5	3.612980369
45.75	12.75	3.520306012
45.75	13	3.495925216
46	7	5.06399168
46	7.25	4.949174095
46	7.5	5.266087828
46	7.75	5.352298328
46	8	4.757472437
46	8.25	2.800325674
46	8.5	3.612980369
46	8.75	3.185687405
46	9	2.323282473
46	9.25	1.671485743
46	9.5	3.856783573
46	9.75	4.572079662
46	10	4.679469855
46	10.25	4.679469855
46	10.5	5.309043916
46	10.75	3.294210812
46	11	3.405725407
46	11.25	3.669541114
46	11.5	3.495925216
46	11.75	4.255093726
46	12	3.495925216
46	12.25	3.185687405
46	12.5	3.213960325
46	12.75	3.550977951
46	13	3.520306012
46.25	7	1.969297411
46.25	7.25	4.908706364
46.25	7.5	3.052767233
46.25	7.75	3.765429652
46.25	8	3.95669157
46.25	8.25	5.06399168
46.25	8.5	5.266087828
46.25	8.75	3.669541114
46.25	9	3.185687405
46.25	9.25	3.797848342
46.25	9.5	3.352525137
46.25	9.75	5.439709782
46.25	10	5.69098301
46.25	10.25	4.949174095
46.25	10.5	5.736883145
46.25	10.75	5.105542055
46.25	11	4.255093726
46.25	11.25	3.701277511
46.25	11.5	4.255093726
46.25	11.75	4.572079662
46.25	12	3.98369323
46.25	12.25	4.148941623
46.25	12.5	3.129746478
46.25	12.75	3.236725042
46.25	13	3.550977951
46.5	7	2.872155245
46.5	7.25	3.701277511
46.5	7.5	3.15761656
46.5	7.75	3.765429652
46.5	8	5.18951259
46.5	8.25	6.105948261
46.5	8.5	5.266087828
46.5	8.75	5.69098301
46.5	9	6.009422688
46.5	9.25	5.147381739
46.5	9.5	5.829636932
46.5	9.75	5.654489904
46.5	10	6.243327668
46.5	10.25	5.395852976
46.5	10.5	5.736883145
46.5	10.75	6.057519881
46.5	11	5.147381739
46.5	11.25	3.520306012
46.5	11.5	3.856783573
46.5	11.75	4.148941623
46.5	12	4.71833512
46.5	12.25	4.71833512
46.5	12.5	3.701277511
46.5	12.75	3.889851131
46.5	13	3.32326373
46.75	7	1.859766825
46.75	7.25	2.198852355
46.75	7.5	2.345277833
46.75	7.75	2.517818813
46.75	8	3.856783573
46.75	8.25	3.856783573
46.75	8.5	5.06399168
46.75	8.75	4.184077131
46.75	9	5.829636932
46.75	9.25	3.644313708
46.75	9.5	3.765429652
46.75	9.75	5.309043916
46.75	10	6.009422688
46.75	10.25	5.147381739
46.75	10.5	5.609155594
46.75	10.75	5.783100444
46.75	11	5.147381739
46.75	11.25	3.581868928
46.75	11.5	4.908706364
46.75	11.75	3.465643983
46.75	12	3.465643983
46.75	12.25	4.148941623
46.75	12.5	3.98369323
46.75	12.75	3.581868928
46.75	13	3.644313708