matplotlib-users Mailing List for matplotlib (Page 8)

On Wed, Jul 16, 2008 at 1:25 PM, Oz Nahum <na...@gm...> wrote:
> Ok, I played with it a little bit.
>
> Here is what I know:
> importing the data is not a big issue, I aready wrote a tutorial about it
> here:
> http://www.tabula0rasa.org/?p=21

There are a couple of functions for loading ASCII data so you probably
don't need to role your own unless you have specialized needs.  See
numpy.loadtxt and matplotlib.mlab.csv2rec (example at
http://matplotlib.sf.net/examples/pylab_examples/loadrec.py

JDH

Ok, I played with it a little bit.

Here is what I know:
importing the data is not a big issue, I aready wrote a tutorial about it
here:
http://www.tabula0rasa.org/?p=21

here is a sample code I wrote.
from matplotlib import pyplot as plt
from pylab import *
temperature=[
            [1,3,4],
            [2,4,5],
            [6,3,2]
]

distance = (100,200,300)
depth = (10,30,50)

plt.colorbar()
plt.contourf(distance,depth,temperature)
plt.gca().invert_yaxis()
plt.show()



Can I plot the dots as different series on top of the contours ?

many many 10x.
Oz
On Wed, Jul 16, 2008 at 8:58 PM, Eric Firing <ef...@ha...> wrote:

> Oz Nahum wrote:
>
>> Thanks for the quick answer.
>> So if I have a series of 18 points withe measured distance, and 18 data
>> points with distance, it makes it almost impossible to build the graph ??? I
>> can't type 18^18 points.... I want the computer to plot the points and
>> extrapulate between them...
>>
>
> I'm puzzled.  You said you knew how to read in your data from files, so
> there should be no question of having to type too many numbers.
>
> Eric
>
>>
>> excuse me the possibly dumb question, I am new to sceintific programming
>> and for matplotlib
>>
>> Oz
>>
>> On Wed, Jul 16, 2008 at 7:51 PM, Eric Firing <ef...@ha... <mailto:
>> ef...@ha...>> wrote:
>>
>>    Oz Nahum wrote:
>>
>>        Hi,
>>        I want to draw a contour plot which uses data from files. I know
>>        how to import the files, so it's not the main issue.
>>        Let's say I want to do a profile which has the following data:
>>        distance, depth and some oceanographic data like temp, oxygen
>>        and stuff....
>>
>>        so for simplicity lets say I have:
>>
>>        distance = [1,2,3,4,5,6,7,8,9]
>>        depth = [1,2,3,4,5,6,7,8,9]
>>
>>        temp = [26.5, 26.2, 26.2, 26.0,25, 24, 22, 21, 18]
>>
>>
>>    Too simple.  If your grid has 9 points in distance and 9 in depth,
>>    then you need 81 values of temperature (9 profiles of 9 depths each).
>>
>>    Suppose you have 10 profiles of 8 points each.  Then your
>>    temperature array should have shape (8,10).  Your distance and depth
>>    arrays can either have the same shape as temperature, or both can be
>>    1-D, in which case distance.shape = (10,) and depth.shape = (8,).
>>     Either way, you then use (assuming a current release of mpl)
>>
>>    from matplotlib import pyplot as plt
>>    plt.contour(distance, depth, temperature)
>>    plt.gca().invert_yaxis() # so depth increases down the y-axis
>>    plt.show()
>>
>>    Note that the shape of your temperature array is the transpose of
>>    what one might expect.  This is for matlab compatibility, and goes
>>    with the idea of looking at an array as it is printed, with the
>>    column dimension (second index) increasing across the page.
>>
>>    See the contour_demo.py and contourf_demo.py in the mpl examples.
>>
>>    Eric
>>
>>
>>
>>        how do I produce a countour plot were distanc is X, Y is depth
>>        and the contours are for temp ?
>>
>>        many thanks...
>>        Oz
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> 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
>>
>
>

Oz Nahum wrote:
> Thanks for the quick answer.
> So if I have a series of 18 points withe measured distance, and 18 data 
> points with distance, it makes it almost impossible to build the graph 
> ??? I can't type 18^18 points.... I want the computer to plot the points 
> and extrapulate between them...

I'm puzzled.  You said you knew how to read in your data from files, so 
there should be no question of having to type too many numbers.

Eric
> 
> excuse me the possibly dumb question, I am new to sceintific programming 
> and for matplotlib
> 
> Oz
>               
> 
> On Wed, Jul 16, 2008 at 7:51 PM, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
> 
>     Oz Nahum wrote:
> 
>         Hi,
>         I want to draw a contour plot which uses data from files. I know
>         how to import the files, so it's not the main issue.
>         Let's say I want to do a profile which has the following data:
>         distance, depth and some oceanographic data like temp, oxygen
>         and stuff....
> 
>         so for simplicity lets say I have:
> 
>         distance = [1,2,3,4,5,6,7,8,9]
>         depth = [1,2,3,4,5,6,7,8,9]
> 
>         temp = [26.5, 26.2, 26.2, 26.0,25, 24, 22, 21, 18]
> 
> 
>     Too simple.  If your grid has 9 points in distance and 9 in depth,
>     then you need 81 values of temperature (9 profiles of 9 depths each).
> 
>     Suppose you have 10 profiles of 8 points each.  Then your
>     temperature array should have shape (8,10).  Your distance and depth
>     arrays can either have the same shape as temperature, or both can be
>     1-D, in which case distance.shape = (10,) and depth.shape = (8,).
>      Either way, you then use (assuming a current release of mpl)
> 
>     from matplotlib import pyplot as plt
>     plt.contour(distance, depth, temperature)
>     plt.gca().invert_yaxis() # so depth increases down the y-axis
>     plt.show()
> 
>     Note that the shape of your temperature array is the transpose of
>     what one might expect.  This is for matlab compatibility, and goes
>     with the idea of looking at an array as it is printed, with the
>     column dimension (second index) increasing across the page.
> 
>     See the contour_demo.py and contourf_demo.py in the mpl examples.
> 
>     Eric
> 
> 
> 
>         how do I produce a countour plot were distanc is X, Y is depth
>         and the contours are for temp ?
> 
>         many thanks...
>         Oz
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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

Alex Stapleton wrote:
> 2008/7/16 Jeff Whitaker <js...@fa...>:
>   
>> Alex Stapleton wrote:
>>     
>> Alex:  I don't have the Cairo backend installed, but I bet it would work if
>> you changed resolution='i' to resolution='l'.  Seems like a pretty severe
>> limitation of the backend though.
>>     
> I suppose it's not up to matplotlib to work around silly limits in
> Cairo :)
Slightly OT -- I put the check for the length of the path in there 
because otherwise pycairo/cairo segfaults, and I thought an exception 
would be preferable to a segfault.  That limit was obtained through 
experimentation, and might not be accurate (I couldn't actually find a 
hard limit in the cairo code, it's more likely due to an interaction of 
multiple parts of the code).  This was all true with Cairo 
1.4.10/pycairo 1.4.0.  With other versions this may not be the case, but 
my "catch" happens regardless.  We may want to revisit that if we 
discover that newer versions of Cairo can handle longer paths.

Cheers,
Mike

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

Thanks for the quick answer.
So if I have a series of 18 points withe measured distance, and 18 data
points with distance, it makes it almost impossible to build the graph ??? I
can't type 18^18 points.... I want the computer to plot the points and
extrapulate between them...

excuse me the possibly dumb question, I am new to sceintific programming and
for matplotlib

Oz


On Wed, Jul 16, 2008 at 7:51 PM, Eric Firing <ef...@ha...> wrote:

> Oz Nahum wrote:
>
>> Hi,
>> I want to draw a contour plot which uses data from files. I know how to
>> import the files, so it's not the main issue.
>> Let's say I want to do a profile which has the following data:
>> distance, depth and some oceanographic data like temp, oxygen and
>> stuff....
>>
>> so for simplicity lets say I have:
>>
>> distance = [1,2,3,4,5,6,7,8,9]
>> depth = [1,2,3,4,5,6,7,8,9]
>>
>> temp = [26.5, 26.2, 26.2, 26.0,25, 24, 22, 21, 18]
>>
>
> Too simple.  If your grid has 9 points in distance and 9 in depth, then you
> need 81 values of temperature (9 profiles of 9 depths each).
>
> Suppose you have 10 profiles of 8 points each.  Then your temperature array
> should have shape (8,10).  Your distance and depth arrays can either have
> the same shape as temperature, or both can be 1-D, in which case
> distance.shape = (10,) and depth.shape = (8,).  Either way, you then use
> (assuming a current release of mpl)
>
> from matplotlib import pyplot as plt
> plt.contour(distance, depth, temperature)
> plt.gca().invert_yaxis() # so depth increases down the y-axis
> plt.show()
>
> Note that the shape of your temperature array is the transpose of what one
> might expect.  This is for matlab compatibility, and goes with the idea of
> looking at an array as it is printed, with the column dimension (second
> index) increasing across the page.
>
> See the contour_demo.py and contourf_demo.py in the mpl examples.
>
> Eric
>
>
>
>> how do I produce a countour plot were distanc is X, Y is depth and the
>> contours are for temp ?
>>
>> many thanks...
>> Oz
>>
>

Oz Nahum wrote:
> Hi,
> I want to draw a contour plot which uses data from files. I know how to 
> import the files, so it's not the main issue.
> Let's say I want to do a profile which has the following data:
> distance, depth and some oceanographic data like temp, oxygen and stuff....
> 
> so for simplicity lets say I have:
> 
> distance = [1,2,3,4,5,6,7,8,9]
> depth = [1,2,3,4,5,6,7,8,9]
> 
> temp = [26.5, 26.2, 26.2, 26.0,25, 24, 22, 21, 18]

Too simple.  If your grid has 9 points in distance and 9 in depth, then 
you need 81 values of temperature (9 profiles of 9 depths each).

Suppose you have 10 profiles of 8 points each.  Then your temperature 
array should have shape (8,10).  Your distance and depth arrays can 
either have the same shape as temperature, or both can be 1-D, in which 
case distance.shape = (10,) and depth.shape = (8,).  Either way, you 
then use (assuming a current release of mpl)

from matplotlib import pyplot as plt
plt.contour(distance, depth, temperature)
plt.gca().invert_yaxis() # so depth increases down the y-axis
plt.show()

Note that the shape of your temperature array is the transpose of what 
one might expect.  This is for matlab compatibility, and goes with the 
idea of looking at an array as it is printed, with the column dimension 
(second index) increasing across the page.

See the contour_demo.py and contourf_demo.py in the mpl examples.

Eric

> 
> how do I produce a countour plot were distanc is X, Y is depth and the 
> contours are for temp ?
> 
> many thanks...
> Oz

Hi,
I want to draw a contour plot which uses data from files. I know how to
import the files, so it's not the main issue.
Let's say I want to do a profile which has the following data:
distance, depth and some oceanographic data like temp, oxygen and stuff....

so for simplicity lets say I have:

distance = [1,2,3,4,5,6,7,8,9]
depth = [1,2,3,4,5,6,7,8,9]

temp = [26.5, 26.2, 26.2, 26.0,25, 24, 22, 21, 18]

how do I produce a countour plot were distanc is X, Y is depth and the
contours are for temp ?

many thanks...
Oz

On Wed, Jul 16, 2008 at 7:36 AM, Ken Dere <kd...@gm...> wrote:
> I would like to be able to call something like:
>
>> sub = getSub(myImage)
>
> and then click my cursor on two places in an image and have that subregion
> returned as sub.  I would also like to be able to do this with a single
> statement rather doing z=connect('button_press_event',getSub).  Seems like
> something like this should be around.

The RectangleSelector provides something close to this functionality
-- check out http://matplotlib.sourceforge.net/examples/widgets/rectangle_selector.py

I would like to be able to call something like:

> sub = getSub(myImage)

and then click my cursor on two places in an image and have that subregion 
returned as sub.  I would also like to be able to do this with a single
statement rather doing z=connect('button_press_event',getSub).  Seems like 
something like this should be around.

thanks,

Ken

Alex Stapleton wrote:
> 2008/7/16 Jeff Whitaker <js...@fa...>:
>   
>> Alex Stapleton wrote:
>>     
>>> Not sure if this is the right place to send this, can't seem to find a
>>> dedicated bugs list or issue tracker. Or much discussion regarding the
>>> basemap toolkit at all really.
>>>
>>> Trying to savefig some Basemap instances causes the following
>>> exception in the Cairo backend. Seems to work alright using the Agg
>>> backend but the fill doesn't seem to come out properly. The sea gets
>>> colored as well as the continents.
>>>
>>> Traceback (most recent call last):
>>>  File "map.py", line 48, in <module>
>>>    plt.savefig("map.png", dpi=100)
>>>  File "/usr/lib/python2.5/site-packages/matplotlib/pyplot.py", line
>>> 286, in savefig
>>>    return fig.savefig(*args, **kwargs)
>>>  File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line
>>> 1033, in savefig
>>>    self.canvas.print_figure(*args, **kwargs)
>>>  File "/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py",
>>> line 1301, in print_figure
>>>    **kwargs)
>>>  File
>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_cairo.py",
>>> line 406, in print_png
>>>    self.figure.draw (renderer)
>>>  File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line
>>> 833, in draw
>>>    for a in self.axes: a.draw(renderer)
>>>  File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1539, in
>>> draw
>>>    a.draw(renderer)
>>>  File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line
>>> 285, in draw
>>>    renderer.draw_path(gc, tpath, affine, rgbFace)
>>>  File
>>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_cairo.py",
>>> line 140, in draw_path
>>>    raise ValueError("The Cairo backend can not draw paths longer than
>>> 18980 points.")
>>> ValueError: The Cairo backend can not draw paths longer than 18980 points.
>>>
>>> Here's a short reduction
>>>
>>> import matplotlib
>>> matplotlib.use("Cairo")
>>> from mpl_toolkits.basemap import Basemap
>>> import matplotlib.pyplot as plt
>>>
>>> map = Basemap(projection='ortho',
>>>              llcrnrlon=-12.7, llcrnrlat=49,
>>>              urcrnrlon=4.7,  urcrnrlat=61,
>>>              lat_0 = 50, lon_0 = 0,
>>>              lat_ts=50,
>>>              resolution='i')
>>> map.drawcoastlines(linewidth=0.5)
>>> map.drawcountries(linewidth=0.5)
>>> map.drawstates(linewidth=0.5)
>>> map.drawmapboundary()
>>> plt.savefig("map.png", dpi=100)
>>>
>>>
>>>       
>> Alex:  I don't have the Cairo backend installed, but I bet it would work if
>> you changed resolution='i' to resolution='l'.  Seems like a pretty severe
>> limitation of the backend though.
>>
>> -Jeff
>>     
>
> I suppose it's not up to matplotlib to work around silly limits in
> Cairo :) What about the fill issue with the Agg backend when doingfil
> zoomed in ortho maps? Am I doing something wrong?
>   
Alex: I see in the example you sent that the whole map gets filled when 
the fillcontinents method is used.  Is this what you mean?  There's a 
KNOWN_BUGS file with this entry:

* The fillcontinents method doesn't always do the right thing.  Matplotlib
always tries to fill the inside of a polygon.  Under certain situations,
what is the inside of a coastline polygon can be ambiguous, and the
outside may be filled instead of the inside.  To trigger this,
run the garp.py example with lon=-71,lat=-33 (Santiago, Chile).
Workaround - mask the land areas with the drawlsmask method instead of
filling the coastline polygons.

Using the orthographic projection to plot a local region is probably not 
the best idea though - it's really intended for the global domain to 
mimic what a satellite would see.  I'd try the transverse mercator 
('tmerc' - as in the highres.py example), or lambert conformal ('lcc') 
instead. The fillcontinents method does the right thing in both cases 
with your map region.

BTW:  lat_ts doesn't do anything for projection='ortho'.

-Jeff

-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/PSD1        FAX   : (303)497-6449
325 Broadway                Boulder, CO, USA 80305-3328

2008/7/16 Jeff Whitaker <js...@fa...>:
> Alex Stapleton wrote:
>>
>> Not sure if this is the right place to send this, can't seem to find a
>> dedicated bugs list or issue tracker. Or much discussion regarding the
>> basemap toolkit at all really.
>>
>> Trying to savefig some Basemap instances causes the following
>> exception in the Cairo backend. Seems to work alright using the Agg
>> backend but the fill doesn't seem to come out properly. The sea gets
>> colored as well as the continents.
>>
>> Traceback (most recent call last):
>>  File "map.py", line 48, in <module>
>>    plt.savefig("map.png", dpi=100)
>>  File "/usr/lib/python2.5/site-packages/matplotlib/pyplot.py", line
>> 286, in savefig
>>    return fig.savefig(*args, **kwargs)
>>  File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line
>> 1033, in savefig
>>    self.canvas.print_figure(*args, **kwargs)
>>  File "/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py",
>> line 1301, in print_figure
>>    **kwargs)
>>  File
>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_cairo.py",
>> line 406, in print_png
>>    self.figure.draw (renderer)
>>  File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line
>> 833, in draw
>>    for a in self.axes: a.draw(renderer)
>>  File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1539, in
>> draw
>>    a.draw(renderer)
>>  File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line
>> 285, in draw
>>    renderer.draw_path(gc, tpath, affine, rgbFace)
>>  File
>> "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_cairo.py",
>> line 140, in draw_path
>>    raise ValueError("The Cairo backend can not draw paths longer than
>> 18980 points.")
>> ValueError: The Cairo backend can not draw paths longer than 18980 points.
>>
>> Here's a short reduction
>>
>> import matplotlib
>> matplotlib.use("Cairo")
>> from mpl_toolkits.basemap import Basemap
>> import matplotlib.pyplot as plt
>>
>> map = Basemap(projection='ortho',
>>              llcrnrlon=-12.7, llcrnrlat=49,
>>              urcrnrlon=4.7,  urcrnrlat=61,
>>              lat_0 = 50, lon_0 = 0,
>>              lat_ts=50,
>>              resolution='i')
>> map.drawcoastlines(linewidth=0.5)
>> map.drawcountries(linewidth=0.5)
>> map.drawstates(linewidth=0.5)
>> map.drawmapboundary()
>> plt.savefig("map.png", dpi=100)
>>
>>
>
> Alex:  I don't have the Cairo backend installed, but I bet it would work if
> you changed resolution='i' to resolution='l'.  Seems like a pretty severe
> limitation of the backend though.
>
> -Jeff
>

I suppose it's not up to matplotlib to work around silly limits in
Cairo :) What about the fill issue with the Agg backend when doing
zoomed in ortho maps? Am I doing something wrong?

(actually hit reply all this time)

John Hunter wrote:
> On Wed, Jul 16, 2008 at 6:12 AM, Angela Rivera Campos <riv...@in...> wrote:
>> Hi, again
>>
>> I've trying to install everything, from the begining on another machine,
>> this one's running openSUSE 10.3. So I've installed the latest versions of
>> numpy, scipy and matplotlib and I've discovered something new which also
>> happens in the first machine, the one with openSUSE 10.2. The first time I
>> imported pylab this is what I got:
>>
>> ---------------------------------
>>>>> from pylab import *
>> /usr/lib/python2.5/site-packages/gtk-2.0/gtk/__init__.py:69: GtkWarning:
>> could not open display
> 
> If you cannot open the display, most likely it is because either you
> are running as root (bad, bad) or you are running over a remot
> connection (ssh) and do not have X11 forwarding properly enabled or
> configures.  If you want to use mpl with an interactive window, you
> will need to have access to the display.  The fact that you see this
> error only on the first time you import pylab is typical of exceptions
> that are thrown at module import time -- python only tries to import
> once so you see the exception only once.  To solve this, trying
> running as a normal user rather than root or sudo, and if you are on a
> remote machine, try using ssh -X to enable X11 forwarding.  We will
> need to know more about exactly what you are doing to help.

For remote access you also need to allow the remote machine to access 
the display via "xhost +name" on the local machine.

>> So googling a bit, I've found that to avoid this error an option would be to
>> add, before the pylab import, the following:
>>
>>>>> import matplotlib
>>>>> matplotlib.use('Agg')
>> This way the results floating problem disappears and I've got the correct
>> tuples, though now I can't make my script show the figure I'm trying to
>> plot. Is this related with matplotlibrc configuration? I haven't modified
>> this file and the only lines that are not commented are
>>
>> backend      : GTKAgg
>> numerix      : numpy  # numpy, Numeric or numarray
>>
>> Running my script with and without these lines with --verbose-debug, I've
>> found that when they're written I get: backend agg version v2.2
>> and when they are not: backend GTKAgg version 2.10.6
> 
> This isn't a problem with matplotlib, but with the connection to the
> display as I mentioned above.
> Hopefully once you get the display problem sorted out, all will be
> well.  Let us know.
> 
> JDH
> 
> -------------------------------------------------------------------------
> 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

Alex Stapleton wrote:
> Not sure if this is the right place to send this, can't seem to find a
> dedicated bugs list or issue tracker. Or much discussion regarding the
> basemap toolkit at all really.
>
> Trying to savefig some Basemap instances causes the following
> exception in the Cairo backend. Seems to work alright using the Agg
> backend but the fill doesn't seem to come out properly. The sea gets
> colored as well as the continents.
>
> Traceback (most recent call last):
>   File "map.py", line 48, in <module>
>     plt.savefig("map.png", dpi=100)
>   File "/usr/lib/python2.5/site-packages/matplotlib/pyplot.py", line
> 286, in savefig
>     return fig.savefig(*args, **kwargs)
>   File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line
> 1033, in savefig
>     self.canvas.print_figure(*args, **kwargs)
>   File "/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py",
> line 1301, in print_figure
>     **kwargs)
>   File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_cairo.py",
> line 406, in print_png
>     self.figure.draw (renderer)
>   File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line
> 833, in draw
>     for a in self.axes: a.draw(renderer)
>   File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1539, in draw
>     a.draw(renderer)
>   File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line
> 285, in draw
>     renderer.draw_path(gc, tpath, affine, rgbFace)
>   File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_cairo.py",
> line 140, in draw_path
>     raise ValueError("The Cairo backend can not draw paths longer than
> 18980 points.")
> ValueError: The Cairo backend can not draw paths longer than 18980 points.
>
> Here's a short reduction
>
> import matplotlib
> matplotlib.use("Cairo")
> from mpl_toolkits.basemap import Basemap
> import matplotlib.pyplot as plt
>
> map = Basemap(projection='ortho',
>               llcrnrlon=-12.7, llcrnrlat=49,
>               urcrnrlon=4.7,  urcrnrlat=61,
>               lat_0 = 50, lon_0 = 0,
>               lat_ts=50,
>               resolution='i')
> map.drawcoastlines(linewidth=0.5)
> map.drawcountries(linewidth=0.5)
> map.drawstates(linewidth=0.5)
> map.drawmapboundary()
> plt.savefig("map.png", dpi=100)
>
>   
Alex:  I don't have the Cairo backend installed, but I bet it would work 
if you changed resolution='i' to resolution='l'.  Seems like a pretty 
severe limitation of the backend though.

-Jeff

-- 
Jeffrey S. Whitaker         Phone : (303)497-6313
NOAA/OAR/CDC  R/PSD1        FAX   : (303)497-6449
325 Broadway                Boulder, CO, USA 80305-3328

On Wed, Jul 16, 2008 at 6:12 AM, Angela Rivera Campos <riv...@in...> wrote:
> Hi, again
>
> I've trying to install everything, from the begining on another machine,
> this one's running openSUSE 10.3. So I've installed the latest versions of
> numpy, scipy and matplotlib and I've discovered something new which also
> happens in the first machine, the one with openSUSE 10.2. The first time I
> imported pylab this is what I got:
>
> ---------------------------------
>>>> from pylab import *
> /usr/lib/python2.5/site-packages/gtk-2.0/gtk/__init__.py:69: GtkWarning:
> could not open display

If you cannot open the display, most likely it is because either you
are running as root (bad, bad) or you are running over a remot
connection (ssh) and do not have X11 forwarding properly enabled or
configures.  If you want to use mpl with an interactive window, you
will need to have access to the display.  The fact that you see this
error only on the first time you import pylab is typical of exceptions
that are thrown at module import time -- python only tries to import
once so you see the exception only once.  To solve this, trying
running as a normal user rather than root or sudo, and if you are on a
remote machine, try using ssh -X to enable X11 forwarding.  We will
need to know more about exactly what you are doing to help.

> So googling a bit, I've found that to avoid this error an option would be to
> add, before the pylab import, the following:
>
>>>> import matplotlib
>>>> matplotlib.use('Agg')
>
> This way the results floating problem disappears and I've got the correct
> tuples, though now I can't make my script show the figure I'm trying to
> plot. Is this related with matplotlibrc configuration? I haven't modified
> this file and the only lines that are not commented are
>
> backend      : GTKAgg
> numerix      : numpy  # numpy, Numeric or numarray
>
> Running my script with and without these lines with --verbose-debug, I've
> found that when they're written I get: backend agg version v2.2
> and when they are not: backend GTKAgg version 2.10.6

This isn't a problem with matplotlib, but with the connection to the
display as I mentioned above.
Hopefully once you get the display problem sorted out, all will be
well.  Let us know.

JDH

Not sure if this is the right place to send this, can't seem to find a
dedicated bugs list or issue tracker. Or much discussion regarding the
basemap toolkit at all really.

Trying to savefig some Basemap instances causes the following
exception in the Cairo backend. Seems to work alright using the Agg
backend but the fill doesn't seem to come out properly. The sea gets
colored as well as the continents.

Traceback (most recent call last):
  File "map.py", line 48, in <module>
    plt.savefig("map.png", dpi=100)
  File "/usr/lib/python2.5/site-packages/matplotlib/pyplot.py", line
286, in savefig
    return fig.savefig(*args, **kwargs)
  File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line
1033, in savefig
    self.canvas.print_figure(*args, **kwargs)
  File "/usr/lib/python2.5/site-packages/matplotlib/backend_bases.py",
line 1301, in print_figure
    **kwargs)
  File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_cairo.py",
line 406, in print_png
    self.figure.draw (renderer)
  File "/usr/lib/python2.5/site-packages/matplotlib/figure.py", line
833, in draw
    for a in self.axes: a.draw(renderer)
  File "/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 1539, in draw
    a.draw(renderer)
  File "/usr/lib/python2.5/site-packages/matplotlib/patches.py", line
285, in draw
    renderer.draw_path(gc, tpath, affine, rgbFace)
  File "/usr/lib/python2.5/site-packages/matplotlib/backends/backend_cairo.py",
line 140, in draw_path
    raise ValueError("The Cairo backend can not draw paths longer than
18980 points.")
ValueError: The Cairo backend can not draw paths longer than 18980 points.

Here's a short reduction

import matplotlib
matplotlib.use("Cairo")
from mpl_toolkits.basemap import Basemap
import matplotlib.pyplot as plt

map = Basemap(projection='ortho',
              llcrnrlon=-12.7, llcrnrlat=49,
              urcrnrlon=4.7,  urcrnrlat=61,
              lat_0 = 50, lon_0 = 0,
              lat_ts=50,
              resolution='i')
map.drawcoastlines(linewidth=0.5)
map.drawcountries(linewidth=0.5)
map.drawstates(linewidth=0.5)
map.drawmapboundary()
plt.savefig("map.png", dpi=100)

-- 
Alex Stapleton

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

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


Brilliant! This works perfectly and should be easy to implement on different
systems!


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


No, using 'a' gives the same errors as using 'w' (again in fh.read()). Here
are the changes I made to stop the errors that didn't seem to be due to
'stale NFS file handle':

--snip--

[spxiwh@sugar 07:14 AM matplotlib]$ diff texmanager.py
/usr/lib64/python2.4/site-packages/matplotlib/texmanager.py
248c248
<             fh = file(outfile,'a')
---
>             fh = file(outfile)
252,254c252
<             else:
<               try: verbose.report(fh.read(), 'debug')
<               except: pass
---
>             else: verbose.report(fh.read(), 'debug')
259,261c257,258
<                 else:
<                   try: os.remove(fname)
<                   except: pass
---
>                 else: os.remove(fname)
>
280c277
<             fh = file(outfile,'a')
---
>             fh = file(outfile)
285,287c282
<             else:
<               try: verbose.report(fh.read(), 'debug')
<               except: pass
---
>             else: verbose.report(fh.read(), 'debug')
289,290c284
<             try: os.remove(outfile)
<             except: pass
---
>             os.remove(outfile)
314c308
<             # else: verbose.report(fh.read(), 'debug')
---
>             else: verbose.report(fh.read(), 'debug')

--snip--

Once again, thanks for the help.

Ian



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



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

Hi, again

I've trying to install everything, from the begining on another machine, 
this one's running openSUSE 10.3. So I've installed the latest versions 
of numpy, scipy and matplotlib and I've discovered something new which 
also happens in the first machine, the one with openSUSE 10.2. The first 
time I imported pylab this is what I got:

---------------------------------
 >>> from pylab import *
/usr/lib/python2.5/site-packages/gtk-2.0/gtk/__init__.py:69: GtkWarning: 
could not open display
   warnings.warn(str(e), _gtk.Warning)
/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py:40: 
GtkWarning: gdk_cursor_new_for_display: assertion `GDK_IS_DISPLAY 
(display)' failed
   cursors.MOVE          : gdk.Cursor(gdk.FLEUR),
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/usr/local/lib/python2.5/site-packages/pylab.py", line 1, in 
<module>
     from matplotlib.pylab import *
   File "/usr/local/lib/python2.5/site-packages/matplotlib/pylab.py", 
line 247, in <module>
     from matplotlib.pyplot import *
   File "/usr/local/lib/python2.5/site-packages/matplotlib/pyplot.py", 
line 39, in <module>
     new_figure_manager, draw_if_interactive, show = pylab_setup()
   File 
"/usr/local/lib/python2.5/site-packages/matplotlib/backends/__init__.py", 
line 20, in pylab_setup
     globals(),locals(),[backend_name])
   File 
"/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 10, in <module>
     from matplotlib.backends.backend_gtk import gtk, FigureManagerGTK, 
FigureCanvasGTK,\
   File 
"/usr/local/lib/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
line 40, in <module>
     cursors.MOVE          : gdk.Cursor(gdk.FLEUR),
RuntimeError: could not create GdkCursor object
---------------------------------


So googling a bit, I've found that to avoid this error an option would 
be to add, before the pylab import, the following:

 >>> import matplotlib
 >>> matplotlib.use('Agg')

This way the results floating problem disappears and I've got the 
correct tuples, though now I can't make my script show the figure I'm 
trying to plot. Is this related with matplotlibrc configuration? I 
haven't modified this file and the only lines that are not commented are

backend      : GTKAgg
numerix      : numpy  # numpy, Numeric or numarray

Running my script with and without these lines with --verbose-debug, 
I've found that when they're written I get: backend agg version v2.2
and when they are not: backend GTKAgg version 2.10.6

I've also checked the packages installed but all the requirements seem 
to be OK.

Hope, this helps.

AR

John Hunter escribió:
> 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


OK. I've been upgrading my versions and the output is still the same, no 
proper floating managing. I'm using openSUSE 10.2 and I've installed the 
numpy and scipy rmps from the repositories suggested on the webpage and 
compiled matplotlib from source. This is the output for python verbose mode:

-----------------------
$HOME=/home/myhome
CONFIGDIR=/home/myhome/.matplotlib
matplotlib data path 
/usr/local/lib/python2.5/site-packages/matplotlib/mpl-data
loaded rc file /home/myhome/.matplotlib/matplotlibrc
matplotlib version 0.98.1
verbose.level debug
interactive is False
units is True
platform is linux2
loaded modules: ['pylab', '_bisect', 'numpy.ma.types', 
'numpy.core.info', 'numpy.testing.shlex', 'matplotlib.errno', 'random', 
'heapq', 'numpy.core.defchararray', 'distutils.re', 'numpy.lib.bz2', 
'numpy.lib.inspect', 'xml.sax.os', 'numpy.lib.getlimits', 
'ctypes._endian', 'encodings.encodings', 'pkgutil', 
'numpy.core.numerictypes', 'numpy.testing.sys', 'numpy.random.mtrand', 
'xml', 'numpy.fft.types', 'numpy.ma.operator', 'numpy.ma.cPickle', 
'struct', 'numpy.random.info', 'tempfile', 'mmap', 'pprint', 
'numpy.linalg', 'numpy.testing.operator', 'matplotlib', 'imp', 
'compiler.sys', 'collections', 'numpy.core.umath', 'numpy.lib.pkgutil', 
'unittest', 'md5', 'matplotlib.cbook', 'compiler.ast', 'numpy.ma.sys', 
'zipimport', 'string', 'numpy.testing.os', 'matplotlib.locale', 
'numpy.lib.arraysetops', 'numpy.testing.unittest', 'numpy.lib.math', 
'encodings.utf_8', 'matplotlib.__future__', 'pytz.tzinfo', 
'numpy.ctypeslib', 'numpy.testing.re', 'itertools', 'numpy.version', 
'numpy.lib.re', 'compiler.misc', 'ctypes.os', 'compiler.token', 
'numpy.core.os', 'compiler', 'numpy.lib.type_check', 'httplib', 
'xml.sax.sys', 'matplotlib.os', 'xml._xmlplus', 'bisect', 'signal', 
'compiler.consts', 'numpy.lib._datasource', 'pydoc', 'numpy.ma.extras', 
'token', 'numpy.fft.fftpack_lite', 'encodings.types', 'shlex', 
'numpy.core.multiarray', 'matplotlib.pytz', 'numpy.__builtin__', 'dis', 
'xml.sax.saxexts', 'cStringIO', 'zlib', 'xml.sax.saxutils', 
'numpy.numpy', 'matplotlib.StringIO', 'locale', 'numpy.add_newdocs', 
'distutils.sysconfig', 'xml.sax.urlparse', 'numpy.random.numpy', 
'compiler.transformer', 'xml.sax.saxlib', 'compiler.struct', 
'compiler.parser', 'numpy.lib.sys', 'encodings', 'compiler.symbol', 
'numpy.ma.itertools', 'StringIO', 'dateutil', 'numpy.lib.io', 
'__future__', 'matplotlib.colors', 'numpy.imp', 'matplotlib.warnings', 
'rfc822', 'matplotlib.string', 'numpy.lib.numpy', 'matplotlib.sys', 
're', 'numpy.lib._compiled_base', 'matplotlib.numpy', 'numpy.core.mmap', 
'new', 'numpy.lib.struct', 'glob', 'math', 'numpy.fft.helper', 'fcntl', 
'numpy.ma.warnings', 'compiler.imp', 'matplotlib.pyparsing', 
'distutils', 'UserDict', 'inspect', 'distutils.os', '_ctypes', 
'urllib2', 'exceptions', 'numpy.lib.info', 'numpy.testing', 
'numpy.testing.glob', 'numpy.lib.warnings', 'ctypes.struct', 
'numpy.core.sys', 'numpy.core._sort', 'numpy.os', 'compiler.visitor', 
'numpy.testing.difflib', 'matplotlib.sre_constants', 'numpy.lib.shutil', 
'thread', 'numpy.lib.ufunclike', 'numpy.core.memmap', 'traceback', 
'xml.sax.types', 'numpy.testing.warnings', 'xml.sax.sax2exts', 
'weakref', 'numpy.core._internal', 'numpy.fft.fftpack', 'opcode', 
'numpy.testing.imp', 'numpy.linalg.lapack_lite', 'ctypes', 
'distutils.sys', 'os', 'marshal', 'base64', 'numpy.core.string', 
'matplotlib.copy', 'compiler.cStringIO', 'matplotlib.traceback', '_sre', 
'numpy.lib.gzip', 'codecs', 'numpy.random', 'numpy.linalg.numpy', 
'__builtin__', 'numpy.lib.twodim_base', 'numpy.ma.core', 
'matplotlib.re', 'numpy.core.cPickle', 'operator', 
'numpy.testing.parametric', 'sre_constants', 'distutils.string', 
'ctypes._ctypes', '_heapq', 'ctypes.sys', 'matplotlib.datetime', 
'posixpath', 'numpy.lib.financial', 'numpy.testing.types', 'errno', 
'_socket', 'binascii', 'numpy.lib.compiler', 'numpy.core.arrayprint', 
'datetime', 'compiler.os', 'matplotlib.md5', 'types', 'pytz.sys', 
'tokenize', 'xml.sax.handler', 'xml.sax.xmlreader', 'numpy.core.numpy', 
'numpy', 'numpy.lib.urlparse', 'matplotlib.dateutil', 
'numpy.core.defmatrix', 'compiler.compiler', 'cPickle', 
'matplotlib.xml', 'xml.sax.string', '_codecs', '_locale', 
'numpy.__config__', 'numpy.lib.types', 'pytz', 'compiler.syntax', 
'compiler.copy_reg', 'numpy.ma.numpy', 'copy', 'numpy.core.re', 
'_struct', '_types', 'numpy.core.fromnumeric', 'hashlib', 
'compiler.future', 'numpy.core.copy_reg', 'numpy.lib.scimath', 
'numpy.fft', 'numpy.lib', 'compiler.dis', 'posix', 'encodings.aliases', 
'numpy.lib.function_base', 'fnmatch', 'sre_parse', 'pytz.bisect', 
'matplotlib.tempfile', 'numpy.lib.tempfile', 'numpy.core.ctypes', 
'xml.sys', 'mimetools', 'distutils.distutils', '_xmlplus', 'copy_reg', 
'sre_compile', 'xml.sax', 'numpy.core.scalarmath', '_hashlib', 
'_random', 'parser', 'site', 'numpy.lib.polynomial', 'urllib', 
'numpy._import_tools', 'numpy.glob', 'xml.sax.urllib2', 
'numpy.lib.time', '__main__', 'numpy.fft.info', 'numpy.core.records', 
'shutil', 'numpy.lib.cPickle', 'numpy.sys', 'matplotlib.weakref', 
'_weakref', 'numpy.lib.pydoc', 'numpy.lib.urllib2', 
'numpy.testing.traceback', 'strop', 'compiler.pycodegen', 
'numpy.core.numeric', 'numpy.linalg.info', 'encodings.codecs', 
'pytz.datetime', 'numpy.ctypes', 'matplotlib.matplotlib', 'numpy.core', 
'numpy.testing.info', 'matplotlib.rcsetup', 'matplotlib.time', 
'pytz.sets', '_ssl', 'xml.sax._exceptions', 'xml.sax.codecs', 'stat', 
'compiler.new', 'compiler.pyassem', 'numpy.lib.index_tricks', 
'numpy.testing.utils', 'warnings', 'numpy.lib.utils', 'symbol', 
'numpy.lib.shape_base', 'numpy.core.types', 'numpy.fft.numpy', 'repr', 
'sys', 'numpy.core.warnings', 'socket', 'compiler.types', 
'numpy.core.__builtin__', 'ctypes.ctypes', 'numpy.lib.format', 
'numpy.lib.os', 'numpy.ma', 'matplotlib.fontconfig_pattern', 'os.path', 
'bz2', 'numpy.lib.pprint', 'compiler.symbols', 'sets', 
'matplotlib.distutils', 'numpy.core.cStringIO', 
'numpy.testing.numpytest', 'difflib', 'distutils.errors', 'urlparse', 
'linecache', 'matplotlib.shutil', 'numpy.lib.cStringIO', 'time', 'gzip', 
'numpy.lib.machar', 'compiler.marshal', 'numpy.linalg.linalg', 
'numpy.testing.numpy']
Using fontManager instance from /home/myhome/.matplotlib/fontManager.cache
numerix numpy 1.1.0
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'>
-----------------------

Now I'm using a work around managing the data in a different module, so 
the pylab imports are done after reading the data. But, still, this 
issue is puzzling me.

Thanks,

AR

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