matplotlib-users Mailing List for matplotlib

On Jul 15, 2008, at 6:17 PM, Andrea Gavana wrote:

> Hi All,
>
>    I am helping my girlfriend in doing some plots for her thesis (!).
> Normally, matplotlib puts the graph in a box, left y axis, bottom x
> axis, right y axis, top x axis. What she would like to do is to remove
> the right y axis and the top x axis, akin the matlab command "box off"
> (if I remember correctly), leaving just the 2 principal axis in the
> plot.
> I remember seeing something like that done with matplotlib, but
> tonight my google-fu is really bad...
> Is there a way to do what she is asking me to do? ;-)

Hi Andrea,

Here's a class I wrote (see attached) to draw custom frames for  
matplotlib. It defaults to the plot style you describe above. To use  
the frame class, try:

 >>> import pyplot as plt
 >>> from frame import FrameAxes

 >>> plt.subplot(111, projection='frameaxes')

And then plot as you normally would. If you want an example, just run  
the file directly (instead of importing).

I'm playing around with a more flexible implementation where the axes  
can be placed arbitrarily (i.e. not just on the edges of the plot),  
but progress has been slow because of design considerations.

Best,

-Tony

PS: note this requires Matplotlib 0.98

Hi All,

    I am helping my girlfriend in doing some plots for her thesis (!).
Normally, matplotlib puts the graph in a box, left y axis, bottom x
axis, right y axis, top x axis. What she would like to do is to remove
the right y axis and the top x axis, akin the matlab command "box off"
(if I remember correctly), leaving just the 2 principal axis in the
plot.
I remember seeing something like that done with matplotlib, but
tonight my google-fu is really bad...
Is there a way to do what she is asking me to do? ;-)

Thank you in advance for all suggestions.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

I have scatterplots on several axes that are dynamically updated, and
thus I need to keep track of each of the PolyCollection artists that
represent the scattered data. I would like to keep the same
PolyCollection object but update the positions, colors, etc. of the
symbols, possibly changing their total number, something along the
lines of Line.set_data.

Did I miss a method that would do what I want?

I have already looked at removing the collection from the axes and
replotting, but for some reason my axis limits get reset when I do so.

Thanks,
Eric

On Tue, Jul 15, 2008 at 10:48 AM, James K. Gruetzner <jk...@sa...> wrote:

> OTOH, my GTKAgg version is 2.12,0, not 2.6.0.   I'm fairly sure that is where
> the problem lies, or, more likely, in GTK itself, where I have installed:

I just tested on gtk 2.12.0 and did not see the problem with mpl 0.98
and backend gtkagg.  Not sure why you are having these problems...

JDH

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

On Tuesday 15 July 2008 07:48:45 John Hunter wrote:
> 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>

Hi, John,

Here's my equivalent:

$ python ./test.py --verbose-helpful -dGTKAgg
$HOME=/home/jkgruet
CONFIGDIR=/home/jkgruet/.matplotlib
matplotlib data path /usr/lib/python2.5/site-packages/matplotlib/mpl-data
loaded rc file /home/jkgruet/.matplotlib/matplotlibrc
matplotlib version 0.91.2
verbose.level helpful
interactive is True
units is False
platform is linux2
numerix numpy 1.1.0
Using fontManager instance from /home/jkgruet/.matplotlib/fontManager.cache
backend GTKAgg version 2.12.0
Begun.              

  . . . at which point it hangs, even after the window is closed.  

I see that I have a older matplotlib and numpy versions.  Those are the same 
versions as in Fedora 9, so upgrading there won't help.  

OTOH, my GTKAgg version is 2.12,0, not 2.6.0.   I'm fairly sure that is where 
the problem lies, or, more likely, in GTK itself, where I have installed:

gtk+.i386                                1:1.2.10-59.fc8        
gtk2.i386                                2.12.8-2.fc8

This is verified by testing several backends:
  GTKAgg:	fails to return when X is clicked
  GTK:        	fails to return when X is clicked
  GTKCairo:  	fails to return when X is clicked
  WxAgg:  	displays and returns immediately (no need to click any X !!! )
  QtAgg:  		returns when X is clicked; 
  TkAgg:  		returns when X is clicked; 
  FltkAgg:  	"ImportError:  No module named fltk", although fltk is installed
  WX:  		"NotImplementedError" from .../matplotlib/image.py in draw:  
renderer.draw_Image(...)
  
So . . . for my purposes, I think I'll just use QtAgg or TkAgg.

I'm not sure how I would file a bug report against GTK, however, or even *if* 
I should file one given my utter ignorance of gtk.   

I appreciate all the help shown on the list.  Y'all're very kind.  

   James
                          

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

iD8DBQFIfMa9xOXthSHeGJIRApqIAKDi1q+EA7feFvhyhWWlhyUvU0GpugCg3Kx3
+mqZBXBgGVUgtP3Fwr4+POg=
=qkT7
-----END PGP SIGNATURE-----

Hi Ian,

On Tuesday 15 July 2008 10:13:02 am Ian Harry wrote:
> 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.

I suggest you try backing out those changes you just described, and instead 
try setting a MPLCONFIGDIR environment variable to point somewhere on the 
local filesystem. If MPLCONFIGDIR is not defined, we use ~/.matplotlib.

> 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?

Out of curiosity, if you added 'a' instead of 'w', does the error go away?
Either way, please let me know exactly what changes need to be made and I will 
commit the changes to svn.

> 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?

Please try the environment variable I mentioned and let me know what happens.

Darren

Yes, it should be.  I'm further puzzled that removing "del 
Gcf.figs[num]" prevents the memory leak.  There is some side effect that 
happens when all of the figures have been closed (I think it shuts down 
the GUI mainloop), that keeping at least one figure around at all times 
avoids.  But I haven't been able to get to the bottom of that, just a 
half-supported theory at this point.

Cheers,
Mike

laurent oget wrote:
> I am puzzled. Wasn't the whole point of close() to avoid memory leaks?
>
> Laurent
>
> 2008/7/15 Michael Droettboom <md...@st... <mailto: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... <mailto: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=/
>     <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
>     _______________________________________________
>     Matplotlib-users mailing list
>     Mat...@li...
>     <mailto: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

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