matplotlib-users Mailing List for matplotlib

Darren Dale wrote:
> On Friday 11 July 2008 04:20:07 am Neil Pilgrim wrote:
>> Lastly, has anyone checked whether 0.98 still has the 'down key' bug for
>> key-press events? (is there a bugzilla/tracker?)
> 
> I'm not familiar with this issue.
I've not used 0.98, and I just noticed that debian etch actually has 
0.87.7, so I'm 'only' using the latter, nothing more recent...
The bug was mentioned in 2005 according to this archived message:
http://osdir.com/ml/python.matplotlib.general/2005-04/msg00118.html
Triggering 'down' key events do not work correctly - I guess only in the 
gtkagg backend. I have reproduced this here.
-- 
Neil

Eli Brosh wrote:
> Thanks Fernando,
> I now tried %who.
> The result was a huge output, apparently containing all the pylab functions.
> This is exactly the thing I was trying to avoid.
> I wanted to use the who command to see only the variables I defined as 
> part of the pylab session.
> 
> Is there a way to do just this ?
Maybe the pylab command does what you want; you have to include the 
trailing parentheses:
efiring@manini:~$ ipython -pylab
[...]
In [2]:x = arange(20)
In [3]:who()
Name Shape Bytes Type
===========================================================
x 20 80 int32
Upper bound on total bytes = 80
Eric

On Fri, Jul 11, 2008 at 12:19 PM, Eli Brosh <eb...@gm...> wrote:
> Thanks Fernando,
> I now tried %who.
> The result was a huge output, apparently containing all the pylab functions.
> This is exactly the thing I was trying to avoid.
> I wanted to use the who command to see only the variables I defined as part
> of the pylab session.
>
> Is there a way to do just this ?
Yes, update ipython :) The problem you mention is fixed in the
current version already:
maqroll[books]> ipython -pylab
Python 2.5.2 (r252:60911, May 7 2008, 15:19:09)
Type "copyright", "credits" or "license" for more information.
IPython 0.9.0.bzr.r1016 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.
 Welcome to pylab, a matplotlib-based Python environment.
 For more information, type 'help(pylab)'.
In [1]: %who
Interactive namespace is empty.
In [2]: a = 1
In [3]: %who
a
In [4]:
regards
f

Thanks Fernando,
I now tried %who.
The result was a huge output, apparently containing all the pylab functions.
This is exactly the thing I was trying to avoid.
I wanted to use the who command to see only the variables I defined as part
of the pylab session.
Is there a way to do just this ?
thank
Eli Brosh
On Fri, Jul 11, 2008 at 3:10 PM, Fernando Perez <fpe...@gm...>
wrote:
> On Fri, Jul 11, 2008 at 12:02 PM, Eli Brosh <eb...@gm...> wrote:
>
> > In [1]: a=2
> >
> > In [2]: who
> > a
> >
> > In [3]: from pylab import *
> >
> > In [4]: who
> > Out[4]: <function who at 0x0141FAF0>
>
>
> > Why is this happening?
>
> Because pylab provides its own who _function_, which overrides the
> ipython command ('magic function', in ipythonese).
>
> > Is there a way to use the who command with pylab ?
>
> Try
>
> %who
>
> instead. The '%' disambiguates and tells ipython that you are
> explicitly after the magic function, not any other python fuction
> currently available.
>
> Regards,
>
> f
>

On Fri, Jul 11, 2008 at 12:02 PM, Eli Brosh <eb...@gm...> wrote:
> In [1]: a=2
>
> In [2]: who
> a
>
> In [3]: from pylab import *
>
> In [4]: who
> Out[4]: <function who at 0x0141FAF0>
> Why is this happening?
Because pylab provides its own who _function_, which overrides the
ipython command ('magic function', in ipythonese).
> Is there a way to use the who command with pylab ?
Try
%who
instead. The '%' disambiguates and tells ipython that you are
explicitly after the magic function, not any other python fuction
currently available.
Regards,
f

Hello,
I am trying to use pylab interactively from the Ipython shell with the
-pylab option on windows.
Normally, the Ipython shell has the nice "who" command that enables one to
see only the variables defined by him,
rather than the many non-relevant output produced by the python dir()
function.
for example:
I*n [1]: a=2
In [2]: who
a*
Now, with the pylab option, this command does not work. It gives the output:
*In [4]: who
Out[4]: <function who at 0x0141FAF0>
*
The same thing happens when I do not use the Ipython -pylab option but just
import pylab from Ipython:
*In [1]: a=2
In [2]: who
a
In [3]: from pylab import *
In [4]: who
Out[4]: <function who at 0x0141FAF0>*
Why is this happening?*
Is there a way to use the who command with pylab ?*
Thanks
Eli Brosh

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

i forgot two imports.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
import math
import gc
import pylab as PL
def looptest():
 while(1):
 fig=PL.figure(1)
 ax=fig.add_subplot(211)
 ax.set_position((0,0,0.9,0.45))
 ax1=PL.twinx(ax)
 t=range(1000)
 st=[math.sin(x*0.01) for x in t]
 ax.plot(t,st)
 fig.clf()
 PL.close(1)
 gc.collect()
 print "GC"
 print len(gc.get_objects())
 print len(gc.garbage)
looptest()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2008年7月11日 laurent oget <la...@og...>:
> I think i narrowed down the memory leak i have been chasing for a while.
> If i remove the call to twinx i get a slow leak, which would cause me
> trouble
> after a very long time. With the call to twinx, however i am losing
> thousands of objects
> at each loop.
>
> Thanks,
>
> Laurent
>
>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> import pylab as PL
> def looptest():
> while(1):
> fig=PL.figure(1)
> ax=fig.add_subplot(211)
> ax.set_position((0,0,0.9,0.45))
> ax1=PL.twinx(ax)
> t=range(1000)
> st=[math.sin(x*0.01) for x in t]
> ax.plot(t,st)
> fig.clf()
> PL.close(1)
> gc.collect()
> print "GC"
> print len(gc.get_objects())
> print len(gc.garbage)
> looptest()
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>

I think i narrowed down the memory leak i have been chasing for a while.
If i remove the call to twinx i get a slow leak, which would cause me
trouble
after a very long time. With the call to twinx, however i am losing
thousands of objects
at each loop.
Thanks,
Laurent
>>>>>>>>>>>>>>>>>>>>>>>>>
import pylab as PL
def looptest():
 while(1):
 fig=PL.figure(1)
 ax=fig.add_subplot(211)
 ax.set_position((0,0,0.9,0.45))
 ax1=PL.twinx(ax)
 t=range(1000)
 st=[math.sin(x*0.01) for x in t]
 ax.plot(t,st)
 fig.clf()
 PL.close(1)
 gc.collect()
 print "GC"
 print len(gc.get_objects())
 print len(gc.garbage)
looptest()
>>>>>>>>>>>>>>>>>>>>>>>>>>>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 10 July 2008 18:50:12 you wrote:
> James K. Gruetzner wrote:
> >>> I'm running Fedora 8, python 2.5.1, and matplotlib 0.91.2-1.fc8 from
> >>> the yum repository. Backend is set to GTKAgg in my matplotlibrc file.
> >>
> >> (On this list top-posting is frowned upon -- it makes the conversation
> >> difficult to follow.)
> >
> > I understand. Sorry. Each list is different: I'm new here, and will
> > try remember.
>
> No problem. Also, don't forget reply-to-all, so that the whole of the
> list can chime in here. :)
Arrrgh!!!! Almost all my other lists have that as default, so I'm out of the 
habit of checking.
> >> Your analysis is correct, the call to show() activates the GUI mainloop
> >> and does not return until the window is closed. Within ipython there is
> >> some magic that occurs that runs the mainloop in a separate thread.
> >> What do you need to do after the call to show()?
> > In my current situation, I need to extract and display data (images)
> > independently from several different files as part of debugging a larger
> > application. (I'm really not reading a file into the original array, but
> > running some shell commands using os.popen2(...) to eventually populate
> > the array: that part works.) The upshot is that in the course of a
> > few hours, I may have to display (and kill) a large number of images.
> > The current "hang" means that I have an effective memory leak, and I'd
> > have to keep track of Process IDs and manually kill them every so often. 
> > Were the pylab.show() command to return after closing the window
> > (clicking on the X), then a backgrounded or daemon process should
> > terminate. But it doesn't. This seems to be the same problem causing
> > Dragan S.'s problem.
> > I'm not sure if this is a bug or a feature, but would assuredly like to
> > find a way to kill the leak.
> I'm not sure about the lack of returning after the call show(), though
> it does sound like a bug. What I *do* know is that multiple calls to
> show() is frowned upon (if not just completely unsupported). What you
> probably want to look at is the dynamic_image_gtkagg.py example (in the
> examples/ directory). Since you're already using GtkAgg, it should be
> *really* easy to adapt the example to fit your needs. I've personally
> adapted it to do a live data display of a simulation run. 
I don't really need any live interaction or a live data display; I just want 
the thang to stop running (i.e., the process to terminate) when the figure 
window is closed. 
Unfortunately, the 
 dynamic_image_gtkagg.py
example has the same problem. It's final line is "show()". When run as a 
background process, everything displays well --- but when the window is 
closed (click on X), the process fails to terminate. So . . . the root 
cause is that show() does not return when the shown image is closed. 
> If you *need* it to wait for user interaction before continuing, there might
> be a little bit more work, but I don't think it'd be much. You could
> probably instead look at some of the Matplotlib UI widgets, like in the
> buttons.py example.
I really don't need user interaction per se, I may have to go that route an 
establish some sort of "close window and exit" event. Hmmm: another 
learning opportunity . . . . :-) 
The show() function is defined in
 .../matplotlib/backends/backend_gtk.py
and looks to be calling gtk.main(), which, according to 
 .../gtk-2.0/gtk/__init__.py
appears to be deprecated in favor of mainloop().
And that's as far as I can go in this: I'm not graphics whiz, and, in fact, 
having reached somewhat beyond my skill level, can't even figure out how to 
trace the mainloop call back further. 
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.
> Ryan
>
> --
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
Thanks again for your help thus far.
 James
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFId5ChxOXthSHeGJIRAqj4AKDG8RGxoQYl5va2olVUV2WQ1zjyOQCeImlr
AT+d5Fl2FuF9yWxLaJWbjEg=
=wZPg
-----END PGP SIGNATURE-----

KURT PETERS wrote:
> Thanks, that's exactly what I would like to do. I'll take a look.
> Regards,
> Kurt
> 
Kurt: I just added a "tissot" method to Basemap that does this (so you 
won't have to extend the Basemap class in the next version). The 
plot_tissot.py example has been updated to do this. Here's the method:
 def tissot(self,lon_0,lat_0,radius_deg,npts):
 """
 create list of ``npts`` x,y pairs that are equidistant on the
 surface of the earth from central point ``lon_0,lat_0`` and form
 an ellipse with radius of ``radius_deg`` degrees of latitude along
 longitude ``lon_0``.
 The ellipse represents a Tissot's indicatrix
 (http://en.wikipedia.org/wiki/Tissot%27s_Indicatrix),
 which when drawn on a map shows the distortion
 inherent in the map projection."""
 g = pyproj.Geod(a=self.rmajor,b=self.rminor)
 az12,az21,dist = g.inv(lon_0,lat_0,lon_0,lat_0+radius_deg)
 seg = [self(lon_0,lat_0+radius_deg)]
 delaz = 360./npts
 az = az12
 for n in range(npts):
 az = az+delaz
 # skip segments along equator (Geod can't handle equatorial 
arcs)
 if np.allclose(0.,lat_0) and (np.allclose(90.,az) or 
np.allclose(270.,az)):
 continue
 else:
 lon, lat, az21 = g.fwd(lon_0, lat_0, az, dist)
 x,y = self(lon,lat)
 # add segment if it is in the map projection region.
 if x < 1.e20 and y < 1.e20:
 seg.append((x,y))
 return seg
-Jeff
> ----Original Message Follows----
> From: Jeff Whitaker <js...@fa...>
> To: KURT PETERS <pet...@ms...>
> CC: mat...@li...
> Subject: Re: [Matplotlib-users] scale a circle properly (not from shapefile)
> Date: 2008年7月11日 06:22:08 -0600
>
> KURT PETERS wrote:
> 
>> I am trying to do something similar to the plot_tissot.py example, but am 
>> having some problems.
>>
>> I would like to project a group of circles onto a map projection. Below 
>> is the code I developed, which doesn't work because I get the error:
>> ==========ERROR ====
>> File "C:\Python25\Lib\site-packages\matplotlib\path.py", line 127, in 
>> __init__
>> assert vertices.ndim == 2
>> AssertionError
>> ==========
>>
>> ====CODE =========
>> m = Basemap(llcrnrlon=-180,llcrnrlat=-80,urcrnrlon=180,urcrnrlat=80, 
>> projection='cyl')
>> shp_info = m.readshapefile(r'C:\Documents and Settings\kpeters\My 
>> Documents\basemap-0.99\examples\tissot','tissot',drawbounds=True)
>> ax = plt.gca()
>> coords = 
>> [(116,45),(104,41),(98,37),(88,30),(78,25),(116,-45),(104,-41),(98,-37),(88,-30),(78,-25)]
>>
>> for lon1,lat1 in coords:
>> newverts = []
>> circle = Circle((lon1,lat1),radius=10, facecolor='green')
>> # trans = circle.get_patch_transform()
>> path = circle.get_path()
>> #for jj in path.iter_segments(): #looks like the iterator is 
>> broken???
>> for jj in path.vertices:
>> verts1, verts2 = jj;
>> newverts.append(m(verts1,verts2))
>> print newverts
>> p = PolyCollection(newverts, facecolor='green', zorder = 10)
>> ax.add_collection(p)
>> ==END CODE==
>>
>> Is this a logical/best way to get circles properly projected, or is there a 
>> better way?
>>
>> I looked at "transform_vector" but I'm not too sure what the uin and vin 
>> do. Is there a transform in basemaps that could be passed to a path like 
>> in this thread: "Re: [Matplotlib-users] Drawing filled circles (discs)":
>> "circle = CirclePolygon((x1,y1), r, resolution)
>> trans = circle.get_patch_transform()
>> path = circle.get_path()
>> transpath = path.transformed(trans)"
>>
>> It should be noted that I also tried:
>> ===code dif===
>> for lon1,lat1 in coords:
>> newverts = []
>> circle = Circle((lon1,lat1),radius=10, facecolor='green')
>> path = circle.get_path()
>> #for jj in path.iter_segments(): #looks like the iterator is 
>> broken???
>> for jj in path.vertices:
>> verts1, verts2 = jj;
>> newverts.append(m(verts1,verts2))
>> print newverts
>> # newcircle = Circle(m(lon1,lat1),radius=10, facecolor='green')
>> p = Polygon(newverts, facecolor='green', zorder = 10)
>> ax.add_patch(p)
>> ===========
>> but that doesn't seem to display anything (I suspect the right radius isn't 
>> being used). Note, that the "newcircle" line that is commented out, puts 
>> circles on the map, they're just not transformed right.
>>
>> Regards,
>> Kurt
>>
>>
>> 
>
> Kurt: Sounds like what you want is to create a set of points that is 
> equidistant on the surface of the earth from a given central point. I've 
> cobbled something together to do this using the Geod class that is part of 
> the pyproj module (http://code.google.com/p/pyproj) used by basemap. Here 
> it is:
>
> import numpy as np
> import matplotlib.pyplot as plt
> from mpl_toolkits.basemap import Basemap
> from mpl_toolkits.basemap import pyproj
> from matplotlib.patches import Polygon
>
> # Tissot's Indicatrix (http://en.wikipedia.org/wiki/Tissot's_Indicatrix).
> # These diagrams illustrate the distortion inherent in all map projections.
> # In conformal projections, where angles are conserved around every 
> location,
> # the Tissot's indicatrix are all circles, with varying sizes. In equal-area
> # projections, where area proportions between objects are conserved, the
> # Tissot's indicatrix have all unit area, although their shapes and
> # orientations vary with location.
>
> class Basemap2(Basemap):
> def circle(self,lon_0,lat_0,radius_deg,npts):
> # create list of npts lon,lat pairs that are equidistant on the
> # surface of the earth from central point lon_0,lat_0
> # and has radius along lon_0 of radius_deg degrees of latitude.
> # uses the WGS84 ellipsoid (a=6378137.0,b=6356752.3142).
> # points are transformed to map projection coordinates.
> g = pyproj.Geod(ellps='WGS84')
> az12,az21,dist = g.inv(lon_0,lat_0,lon_0,lat_0+radius_deg)
> seg = []
> delaz = 360./npts
> az = az12
> for n in range(npts):
> az = az+delaz
> lon, lat, az21 = g.fwd(lon_0, lat_0, az, dist)
> seg.append(m(lon,lat))
> return seg
>
> # create mercator Basemap instance with WGS84 ellipsoid.
> m = Basemap2(llcrnrlon=-180,llcrnrlat=-70,urcrnrlon=180,urcrnrlat=70,
> projection='merc',lat_ts=20,rsphere=(6378137.0,6356752.3142))
> ax = plt.gca()
> # draw "circles" at specified longitudes and latitudes.
> for parallel in range(-60,61,30):
> for meridian in range(-165,166,30):
> seg = m.circle(meridian,parallel,6,101)
> poly = Polygon(seg,facecolor='green',zorder=10)
> ax.add_patch(poly)
> # draw meridians and parallels.
> m.drawparallels(np.arange(-90,91,30),labels=[1,0,0,0])
> m.drawmeridians(np.arange(-180,180,60),labels=[0,0,0,1])
> m.drawcoastlines()
> m.fillcontinents()
> plt.title('Tissot Diagram - Mercator')
> plt.show()
>
> Let us know if you have questions about what is going on here.
>
> -Jeff
>
>
>
> --
> Jeffrey S. Whitaker Phone : (303)497-6313
> NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
> 325 Broadway Boulder, CO, USA 80305-3328
>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Sorry -- I forgot to mention that you need to put the verbose.level 
argument in your matplotlibrc file -- it can't be changed once 
matplotlib has been imported.
Thanks,
Mike
David M. Kaplan wrote:
> Hi,
>
> I gave this a shot, but it didn't print anything out. Attached is an
> example of a plot where the fonts don't match.
>
>
> In [4]: rcParams['verbose.level']='debug-annoying'
>
> In [5]: rcParams['mathtext.fontset'] = 'stix'
>
> In [6]: rcParams['font.family'] = 'serif'
>
> In [7]: plot(arange(10))
> Out[7]: [<matplotlib.lines.Line2D object at 0x92b162c>]
>
> In [8]: text(1,7,r'1ドル \alpha$')
> Out[8]: <matplotlib.text.Text object at 0x8f047cc>
>
> In [9]: text(1,3,'1 alpha')
> Out[9]: <matplotlib.text.Text object at 0x92c4c0c>
>
> In [10]: savefig('test.eps')
>
>
> Thanks,
> David
>
>
> On Fri, 2008年07月11日 at 09:35 -0400, Michael Droettboom wrote:
> 
>> This works for me. Could you set the rcParam verbose.level to 
>> debug-annoying and send the output -- that will print some information 
>> about where it's looking for fonts and what it can and can not find.
>>
>> Cheers,
>> Mike
>>
>> David M. Kaplan wrote:
>> 
>>> Hi,
>>>
>>> Thanks for the suggestions. I have stopped using the usetex option. To
>>> make math and normal text match, I tried the following:
>>>
>>> rcParams['font.family'] = 'serif'
>>> rcParams['mathtext.fontset'] = 'stix'
>>>
>>> This didn't make them match - normal text looked to me like it was still
>>> sans-serif, while mathtext was with serif. Is there something else I
>>> should be doing to make this happen?
>>>
>>> Thanks again for your help.
>>>
>>> Cheers,
>>> David
>>>
>>>
>>> On Thu, 2008年07月10日 at 11:52 -0400, Darren Dale wrote:
>>> 
>>> 
>>>> Hi David,
>>>>
>>>> On Thursday 10 July 2008 11:15:37 am David M. Kaplan wrote:
>>>> 
>>>> 
>>>>> 2) I have noticed that the font used for the xticklabels and the font
>>>>> used for the xlabel and contour labels appears to be different (example
>>>>> attached). One appears to be serif and the other sans-serif. This
>>>>> seems to be due to using tex for text rendering. I am not sure if this
>>>>> also occurred before the update, but I didn't notice it previously.
>>>>> 
>>>>> 
>>>> It has always been this way. We tried a workaround once a couple years back 
>>>> and it turned into a real mess.
>>>>
>>>> 
>>>> 
>>>>> Looking at the properties of the different text objects, it isn't
>>>>> apparent that there should be a difference - both have font properties
>>>>> that indicate sans-serif, but the text of tick labels appears to be
>>>>> surrounded by $'s forcing it through the text parser, while that of the
>>>>> contour labels is not. Is this difference normal or expected? Is there
>>>>> a way around this? In particular, I would like to use sans-serif for
>>>>> everything - is this possible while still using tex?
>>>>> 
>>>>> 
>>>> I think there is a package, sansmath or something like that, that will allow 
>>>> latex to use sans-serif fonts in math mode. You could try adding it to the 
>>>> text.latex.preamble rc setting, but that option is not officially supported.
>>>>
>>>> If you don't like the limitations of latex, you might want to turning off 
>>>> usetex and just use matplotlibs mathtext, which recently got a significant 
>>>> rewrite and is now quite capable thanks to Mike Droettboom. Here's some 
>>>> documentation too:
>>>> http://matplotlib.sourceforge.net/doc/html/users/mathtext.html
>>>>
>>>> Darren
>>>> 
>>>> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
I gave this a shot, but it didn't print anything out. Attached is an
example of a plot where the fonts don't match.
In [4]: rcParams['verbose.level']='debug-annoying'
In [5]: rcParams['mathtext.fontset'] = 'stix'
In [6]: rcParams['font.family'] = 'serif'
In [7]: plot(arange(10))
Out[7]: [<matplotlib.lines.Line2D object at 0x92b162c>]
In [8]: text(1,7,r'1ドル \alpha$')
Out[8]: <matplotlib.text.Text object at 0x8f047cc>
In [9]: text(1,3,'1 alpha')
Out[9]: <matplotlib.text.Text object at 0x92c4c0c>
In [10]: savefig('test.eps')
Thanks,
David
On Fri, 2008年07月11日 at 09:35 -0400, Michael Droettboom wrote:
> This works for me. Could you set the rcParam verbose.level to 
> debug-annoying and send the output -- that will print some information 
> about where it's looking for fonts and what it can and can not find.
> 
> Cheers,
> Mike
> 
> David M. Kaplan wrote:
> > Hi,
> >
> > Thanks for the suggestions. I have stopped using the usetex option. To
> > make math and normal text match, I tried the following:
> >
> > rcParams['font.family'] = 'serif'
> > rcParams['mathtext.fontset'] = 'stix'
> >
> > This didn't make them match - normal text looked to me like it was still
> > sans-serif, while mathtext was with serif. Is there something else I
> > should be doing to make this happen?
> >
> > Thanks again for your help.
> >
> > Cheers,
> > David
> >
> >
> > On Thu, 2008年07月10日 at 11:52 -0400, Darren Dale wrote:
> > 
> >> Hi David,
> >>
> >> On Thursday 10 July 2008 11:15:37 am David M. Kaplan wrote:
> >> 
> >>> 2) I have noticed that the font used for the xticklabels and the font
> >>> used for the xlabel and contour labels appears to be different (example
> >>> attached). One appears to be serif and the other sans-serif. This
> >>> seems to be due to using tex for text rendering. I am not sure if this
> >>> also occurred before the update, but I didn't notice it previously.
> >>> 
> >> It has always been this way. We tried a workaround once a couple years back 
> >> and it turned into a real mess.
> >>
> >> 
> >>> Looking at the properties of the different text objects, it isn't
> >>> apparent that there should be a difference - both have font properties
> >>> that indicate sans-serif, but the text of tick labels appears to be
> >>> surrounded by $'s forcing it through the text parser, while that of the
> >>> contour labels is not. Is this difference normal or expected? Is there
> >>> a way around this? In particular, I would like to use sans-serif for
> >>> everything - is this possible while still using tex?
> >>> 
> >> I think there is a package, sansmath or something like that, that will allow 
> >> latex to use sans-serif fonts in math mode. You could try adding it to the 
> >> text.latex.preamble rc setting, but that option is not officially supported.
> >>
> >> If you don't like the limitations of latex, you might want to turning off 
> >> usetex and just use matplotlibs mathtext, which recently got a significant 
> >> rewrite and is now quite capable thanks to Mike Droettboom. Here's some 
> >> documentation too:
> >> http://matplotlib.sourceforge.net/doc/html/users/mathtext.html
> >>
> >> Darren
> >> 
> 
-- 
**********************************
David M. Kaplan
Assistant Researcher
UCSC / Institute of Marine Sciences
Ocean Sciences
1156 High St.
SC, CA 95064
Phone: 831-459-4789
Fax: 831-459-4882
http://pmc.ucsc.edu/~dmk/
**********************************

Thanks, that's exactly what I would like to do. I'll take a look.
Regards,
Kurt
----Original Message Follows----
From: Jeff Whitaker <js...@fa...>
To: KURT PETERS <pet...@ms...>
CC: mat...@li...
Subject: Re: [Matplotlib-users] scale a circle properly (not from shapefile)
Date: 2008年7月11日 06:22:08 -0600
KURT PETERS wrote:
>I am trying to do something similar to the plot_tissot.py example, but am 
>having some problems.
>
> I would like to project a group of circles onto a map projection. Below 
>is the code I developed, which doesn't work because I get the error:
>==========ERROR ====
> File "C:\Python25\Lib\site-packages\matplotlib\path.py", line 127, in 
>__init__
> assert vertices.ndim == 2
>AssertionError
>==========
>
>====CODE =========
>m = Basemap(llcrnrlon=-180,llcrnrlat=-80,urcrnrlon=180,urcrnrlat=80, 
>projection='cyl')
>shp_info = m.readshapefile(r'C:\Documents and Settings\kpeters\My 
>Documents\basemap-0.99\examples\tissot','tissot',drawbounds=True)
>ax = plt.gca()
>coords = 
>[(116,45),(104,41),(98,37),(88,30),(78,25),(116,-45),(104,-41),(98,-37),(88,-30),(78,-25)]
>
>for lon1,lat1 in coords:
> newverts = []
> circle = Circle((lon1,lat1),radius=10, facecolor='green')
># trans = circle.get_patch_transform()
> path = circle.get_path()
> #for jj in path.iter_segments(): #looks like the iterator is 
>broken???
> for jj in path.vertices:
> verts1, verts2 = jj;
> newverts.append(m(verts1,verts2))
> print newverts
> p = PolyCollection(newverts, facecolor='green', zorder = 10)
> ax.add_collection(p)
>==END CODE==
>
>Is this a logical/best way to get circles properly projected, or is there a 
>better way?
>
>I looked at "transform_vector" but I'm not too sure what the uin and vin 
>do. Is there a transform in basemaps that could be passed to a path like 
>in this thread: "Re: [Matplotlib-users] Drawing filled circles (discs)":
>"circle = CirclePolygon((x1,y1), r, resolution)
>trans = circle.get_patch_transform()
>path = circle.get_path()
>transpath = path.transformed(trans)"
>
>It should be noted that I also tried:
>===code dif===
>for lon1,lat1 in coords:
> newverts = []
> circle = Circle((lon1,lat1),radius=10, facecolor='green')
> path = circle.get_path()
> #for jj in path.iter_segments(): #looks like the iterator is 
>broken???
> for jj in path.vertices:
> verts1, verts2 = jj;
> newverts.append(m(verts1,verts2))
> print newverts
># newcircle = Circle(m(lon1,lat1),radius=10, facecolor='green')
> p = Polygon(newverts, facecolor='green', zorder = 10)
> ax.add_patch(p)
>===========
>but that doesn't seem to display anything (I suspect the right radius isn't 
>being used). Note, that the "newcircle" line that is commented out, puts 
>circles on the map, they're just not transformed right.
>
>Regards,
>Kurt
>
>
Kurt: Sounds like what you want is to create a set of points that is 
equidistant on the surface of the earth from a given central point. I've 
cobbled something together to do this using the Geod class that is part of 
the pyproj module (http://code.google.com/p/pyproj) used by basemap. Here 
it is:
import numpy as np
import matplotlib.pyplot as plt
from mpl_toolkits.basemap import Basemap
from mpl_toolkits.basemap import pyproj
from matplotlib.patches import Polygon
# Tissot's Indicatrix (http://en.wikipedia.org/wiki/Tissot's_Indicatrix).
# These diagrams illustrate the distortion inherent in all map projections.
# In conformal projections, where angles are conserved around every 
location,
# the Tissot's indicatrix are all circles, with varying sizes. In equal-area
# projections, where area proportions between objects are conserved, the
# Tissot's indicatrix have all unit area, although their shapes and
# orientations vary with location.
class Basemap2(Basemap):
 def circle(self,lon_0,lat_0,radius_deg,npts):
 # create list of npts lon,lat pairs that are equidistant on the
 # surface of the earth from central point lon_0,lat_0
 # and has radius along lon_0 of radius_deg degrees of latitude.
 # uses the WGS84 ellipsoid (a=6378137.0,b=6356752.3142).
 # points are transformed to map projection coordinates.
 g = pyproj.Geod(ellps='WGS84')
 az12,az21,dist = g.inv(lon_0,lat_0,lon_0,lat_0+radius_deg)
 seg = []
 delaz = 360./npts
 az = az12
 for n in range(npts):
 az = az+delaz
 lon, lat, az21 = g.fwd(lon_0, lat_0, az, dist)
 seg.append(m(lon,lat))
 return seg
# create mercator Basemap instance with WGS84 ellipsoid.
m = Basemap2(llcrnrlon=-180,llcrnrlat=-70,urcrnrlon=180,urcrnrlat=70,
 projection='merc',lat_ts=20,rsphere=(6378137.0,6356752.3142))
ax = plt.gca()
# draw "circles" at specified longitudes and latitudes.
for parallel in range(-60,61,30):
 for meridian in range(-165,166,30):
 seg = m.circle(meridian,parallel,6,101)
 poly = Polygon(seg,facecolor='green',zorder=10)
 ax.add_patch(poly)
# draw meridians and parallels.
m.drawparallels(np.arange(-90,91,30),labels=[1,0,0,0])
m.drawmeridians(np.arange(-180,180,60),labels=[0,0,0,1])
m.drawcoastlines()
m.fillcontinents()
plt.title('Tissot Diagram - Mercator')
plt.show()
Let us know if you have questions about what is going on here.
-Jeff
--
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

This works for me. Could you set the rcParam verbose.level to 
debug-annoying and send the output -- that will print some information 
about where it's looking for fonts and what it can and can not find.
Cheers,
Mike
David M. Kaplan wrote:
> Hi,
>
> Thanks for the suggestions. I have stopped using the usetex option. To
> make math and normal text match, I tried the following:
>
> rcParams['font.family'] = 'serif'
> rcParams['mathtext.fontset'] = 'stix'
>
> This didn't make them match - normal text looked to me like it was still
> sans-serif, while mathtext was with serif. Is there something else I
> should be doing to make this happen?
>
> Thanks again for your help.
>
> Cheers,
> David
>
>
> On Thu, 2008年07月10日 at 11:52 -0400, Darren Dale wrote:
> 
>> Hi David,
>>
>> On Thursday 10 July 2008 11:15:37 am David M. Kaplan wrote:
>> 
>>> 2) I have noticed that the font used for the xticklabels and the font
>>> used for the xlabel and contour labels appears to be different (example
>>> attached). One appears to be serif and the other sans-serif. This
>>> seems to be due to using tex for text rendering. I am not sure if this
>>> also occurred before the update, but I didn't notice it previously.
>>> 
>> It has always been this way. We tried a workaround once a couple years back 
>> and it turned into a real mess.
>>
>> 
>>> Looking at the properties of the different text objects, it isn't
>>> apparent that there should be a difference - both have font properties
>>> that indicate sans-serif, but the text of tick labels appears to be
>>> surrounded by $'s forcing it through the text parser, while that of the
>>> contour labels is not. Is this difference normal or expected? Is there
>>> a way around this? In particular, I would like to use sans-serif for
>>> everything - is this possible while still using tex?
>>> 
>> I think there is a package, sansmath or something like that, that will allow 
>> latex to use sans-serif fonts in math mode. You could try adding it to the 
>> text.latex.preamble rc setting, but that option is not officially supported.
>>
>> If you don't like the limitations of latex, you might want to turning off 
>> usetex and just use matplotlibs mathtext, which recently got a significant 
>> rewrite and is now quite capable thanks to Mike Droettboom. Here's some 
>> documentation too:
>> http://matplotlib.sourceforge.net/doc/html/users/mathtext.html
>>
>> Darren
>> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
Thanks for the suggestions. I have stopped using the usetex option. To
make math and normal text match, I tried the following:
rcParams['font.family'] = 'serif'
rcParams['mathtext.fontset'] = 'stix'
This didn't make them match - normal text looked to me like it was still
sans-serif, while mathtext was with serif. Is there something else I
should be doing to make this happen?
Thanks again for your help.
Cheers,
David
On Thu, 2008年07月10日 at 11:52 -0400, Darren Dale wrote:
> Hi David,
> 
> On Thursday 10 July 2008 11:15:37 am David M. Kaplan wrote:
> > 2) I have noticed that the font used for the xticklabels and the font
> > used for the xlabel and contour labels appears to be different (example
> > attached). One appears to be serif and the other sans-serif. This
> > seems to be due to using tex for text rendering. I am not sure if this
> > also occurred before the update, but I didn't notice it previously.
> 
> It has always been this way. We tried a workaround once a couple years back 
> and it turned into a real mess.
> 
> > Looking at the properties of the different text objects, it isn't
> > apparent that there should be a difference - both have font properties
> > that indicate sans-serif, but the text of tick labels appears to be
> > surrounded by $'s forcing it through the text parser, while that of the
> > contour labels is not. Is this difference normal or expected? Is there
> > a way around this? In particular, I would like to use sans-serif for
> > everything - is this possible while still using tex?
> 
> I think there is a package, sansmath or something like that, that will allow 
> latex to use sans-serif fonts in math mode. You could try adding it to the 
> text.latex.preamble rc setting, but that option is not officially supported.
> 
> If you don't like the limitations of latex, you might want to turning off 
> usetex and just use matplotlibs mathtext, which recently got a significant 
> rewrite and is now quite capable thanks to Mike Droettboom. Here's some 
> documentation too:
> http://matplotlib.sourceforge.net/doc/html/users/mathtext.html
> 
> Darren
-- 
**********************************
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
**********************************
-- 
**********************************
David M. Kaplan
Assistant Researcher
UCSC / Institute of Marine Sciences
Ocean Sciences
1156 High St.
SC, CA 95064
Phone: 831-459-4789
Fax: 831-459-4882
http://pmc.ucsc.edu/~dmk/
**********************************

Hi,
Thanks for the suggestions. I have stopped using the usetex option. To
make math and normal text match, I tried the following:
rcParams['font.family'] = 'serif'
rcParams['mathtext.fontset'] = 'stix'
This didn't make them match - normal text looked to me like it was still
sans-serif, while mathtext was with serif. Is there something else I
should be doing to make this happen?
Thanks again for your help.
Cheers,
David
On Thu, 2008年07月10日 at 11:52 -0400, Darren Dale wrote:
> Hi David,
> 
> On Thursday 10 July 2008 11:15:37 am David M. Kaplan wrote:
> > 2) I have noticed that the font used for the xticklabels and the font
> > used for the xlabel and contour labels appears to be different (example
> > attached). One appears to be serif and the other sans-serif. This
> > seems to be due to using tex for text rendering. I am not sure if this
> > also occurred before the update, but I didn't notice it previously.
> 
> It has always been this way. We tried a workaround once a couple years back 
> and it turned into a real mess.
> 
> > Looking at the properties of the different text objects, it isn't
> > apparent that there should be a difference - both have font properties
> > that indicate sans-serif, but the text of tick labels appears to be
> > surrounded by $'s forcing it through the text parser, while that of the
> > contour labels is not. Is this difference normal or expected? Is there
> > a way around this? In particular, I would like to use sans-serif for
> > everything - is this possible while still using tex?
> 
> I think there is a package, sansmath or something like that, that will allow 
> latex to use sans-serif fonts in math mode. You could try adding it to the 
> text.latex.preamble rc setting, but that option is not officially supported.
> 
> If you don't like the limitations of latex, you might want to turning off 
> usetex and just use matplotlibs mathtext, which recently got a significant 
> rewrite and is now quite capable thanks to Mike Droettboom. Here's some 
> documentation too:
> http://matplotlib.sourceforge.net/doc/html/users/mathtext.html
> 
> Darren
-- 
**********************************
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
**********************************

KURT PETERS wrote:
> I am trying to do something similar to the plot_tissot.py example, but am 
> having some problems.
>
> I would like to project a group of circles onto a map projection. Below 
> is the code I developed, which doesn't work because I get the error:
> ==========ERROR ====
> File "C:\Python25\Lib\site-packages\matplotlib\path.py", line 127, in 
> __init__
> assert vertices.ndim == 2
> AssertionError
> ==========
>
> ====CODE =========
> m = Basemap(llcrnrlon=-180,llcrnrlat=-80,urcrnrlon=180,urcrnrlat=80, 
> projection='cyl')
> shp_info = m.readshapefile(r'C:\Documents and Settings\kpeters\My 
> Documents\basemap-0.99\examples\tissot','tissot',drawbounds=True)
> ax = plt.gca()
> coords = 
> [(116,45),(104,41),(98,37),(88,30),(78,25),(116,-45),(104,-41),(98,-37),(88,-30),(78,-25)]
>
> for lon1,lat1 in coords:
> newverts = []
> circle = Circle((lon1,lat1),radius=10, facecolor='green')
> # trans = circle.get_patch_transform()
> path = circle.get_path()
> #for jj in path.iter_segments(): #looks like the iterator is broken???
> for jj in path.vertices:
> verts1, verts2 = jj;
> newverts.append(m(verts1,verts2))
> print newverts
> p = PolyCollection(newverts, facecolor='green', zorder = 10)
> ax.add_collection(p)
> ==END CODE==
>
> Is this a logical/best way to get circles properly projected, or is there a 
> better way?
>
> I looked at "transform_vector" but I'm not too sure what the uin and vin do. 
> Is there a transform in basemaps that could be passed to a path like in 
> this thread: "Re: [Matplotlib-users] Drawing filled circles (discs)":
> "circle = CirclePolygon((x1,y1), r, resolution)
> trans = circle.get_patch_transform()
> path = circle.get_path()
> transpath = path.transformed(trans)"
>
> It should be noted that I also tried:
> ===code dif===
> for lon1,lat1 in coords:
> newverts = []
> circle = Circle((lon1,lat1),radius=10, facecolor='green')
> path = circle.get_path()
> #for jj in path.iter_segments(): #looks like the iterator is broken???
> for jj in path.vertices:
> verts1, verts2 = jj;
> newverts.append(m(verts1,verts2))
> print newverts
> # newcircle = Circle(m(lon1,lat1),radius=10, facecolor='green')
> p = Polygon(newverts, facecolor='green', zorder = 10)
> ax.add_patch(p)
> ===========
> but that doesn't seem to display anything (I suspect the right radius isn't 
> being used). Note, that the "newcircle" line that is commented out, puts 
> circles on the map, they're just not transformed right.
>
> Regards,
> Kurt
>
> 
Kurt: Sounds like what you want is to create a set of points that is 
equidistant on the surface of the earth from a given central point. 
I've cobbled something together to do this using the Geod class that is 
part of the pyproj module (http://code.google.com/p/pyproj) used by 
basemap. Here it is:
import numpy as np
import matplotlib.pyplot as plt
from mpl_toolkits.basemap import Basemap
from mpl_toolkits.basemap import pyproj
from matplotlib.patches import Polygon
# Tissot's Indicatrix (http://en.wikipedia.org/wiki/Tissot's_Indicatrix).
# These diagrams illustrate the distortion inherent in all map projections.
# In conformal projections, where angles are conserved around every 
location,
# the Tissot's indicatrix are all circles, with varying sizes. In 
equal-area
# projections, where area proportions between objects are conserved, the
# Tissot's indicatrix have all unit area, although their shapes and
# orientations vary with location.
class Basemap2(Basemap):
 def circle(self,lon_0,lat_0,radius_deg,npts):
 # create list of npts lon,lat pairs that are equidistant on the
 # surface of the earth from central point lon_0,lat_0
 # and has radius along lon_0 of radius_deg degrees of latitude.
 # uses the WGS84 ellipsoid (a=6378137.0,b=6356752.3142).
 # points are transformed to map projection coordinates.
 g = pyproj.Geod(ellps='WGS84')
 az12,az21,dist = g.inv(lon_0,lat_0,lon_0,lat_0+radius_deg)
 seg = []
 delaz = 360./npts
 az = az12
 for n in range(npts):
 az = az+delaz
 lon, lat, az21 = g.fwd(lon_0, lat_0, az, dist)
 seg.append(m(lon,lat))
 return seg
# create mercator Basemap instance with WGS84 ellipsoid.
m = Basemap2(llcrnrlon=-180,llcrnrlat=-70,urcrnrlon=180,urcrnrlat=70,
 projection='merc',lat_ts=20,rsphere=(6378137.0,6356752.3142))
ax = plt.gca()
# draw "circles" at specified longitudes and latitudes.
for parallel in range(-60,61,30):
 for meridian in range(-165,166,30):
 seg = m.circle(meridian,parallel,6,101)
 poly = Polygon(seg,facecolor='green',zorder=10)
 ax.add_patch(poly)
# draw meridians and parallels.
m.drawparallels(np.arange(-90,91,30),labels=[1,0,0,0])
m.drawmeridians(np.arange(-180,180,60),labels=[0,0,0,1])
m.drawcoastlines()
m.fillcontinents()
plt.title('Tissot Diagram - Mercator')
plt.show()
Let us know if you have questions about what is going on here.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

Hi Neil,
On Friday 11 July 2008 04:20:07 am Neil Pilgrim wrote:
> I'm not a regular 0.98 user right now (using debian stable 0.91 or
> similar in a python app) but was investigating the new documentation at
> http://matplotlib.sourceforge.net/doc/html/index.html and noticed a few
> things (typos?) which I wanted to check. It does look good - ReST?
Yes, we are in the process of converting old and adding new documentation. We 
are using ReST and Sphinx.
> - in artists.html, an 'ax' variable is first created, then after
> "Continuing with our example:" the plot command is run on 'ax1' (bug/typo?)
> - just after this, there is "it creates a Line2D instance and adds it
> the the Axes.lines list." (typo? 'to the'?)
ok, thanks.
> Lastly, has anyone checked whether 0.98 still has the 'down key' bug for
> key-press events? (is there a bugzilla/tracker?)
I'm not familiar with this issue.
Darren

Hi,
I'm not a regular 0.98 user right now (using debian stable 0.91 or
similar in a python app) but was investigating the new documentation at
http://matplotlib.sourceforge.net/doc/html/index.html and noticed a few
things (typos?) which I wanted to check. It does look good - ReST?
- in artists.html, an 'ax' variable is first created, then after
"Continuing with our example:" the plot command is run on 'ax1' (bug/typo?)
- just after this, there is "it creates a Line2D instance and adds it
the the Axes.lines list." (typo? 'to the'?)
Lastly, has anyone checked whether 0.98 still has the 'down key' bug for
key-press events? (is there a bugzilla/tracker?)
Thanks,
-- 
Neil

James K. Gruetzner wrote:
>>> I'm running Fedora 8, python 2.5.1, and matplotlib 0.91.2-1.fc8 from
>>> the yum repository. Backend is set to GTKAgg in my matplotlibrc file.
>> (On this list top-posting is frowned upon -- it makes the conversation
>> difficult to follow.)
> 
> I understand. Sorry. Each list is different: I'm new here, and will try 
> remember. 
No problem. Also, don't forget reply-to-all, so that the whole of the 
list can chime in here. :)
>> Your analysis is correct, the call to show() activates the GUI mainloop
>> and does not return until the window is closed. Within ipython there is
>> some magic that occurs that runs the mainloop in a separate thread.
>> What do you need to do after the call to show()?
> 
> In my current situation, I need to extract and display data (images) 
> independently from several different files as part of debugging a larger 
> application. (I'm really not reading a file into the original array, but 
> running some shell commands using os.popen2(...) to eventually populate the 
> array: that part works.) The upshot is that in the course of a few hours, 
> I may have to display (and kill) a large number of images. 
> 
> The current "hang" means that I have an effective memory leak, and I'd have to 
> keep track of Process IDs and manually kill them every so often. Were the 
> pylab.show() command to return after closing the window (clicking on the X), 
> then a backgrounded or daemon process should terminate. But it doesn't. 
> This seems to be the same problem causing Dragan S.'s problem. 
> 
> I'm not sure if this is a bug or a feature, but would assuredly like to find a 
> way to kill the leak.
> 
I'm not sure about the lack of returning after the call show(), though 
it does sound like a bug. What I *do* know is that multiple calls to 
show() is frowned upon (if not just completely unsupported). What you 
probably want to look at is the dynamic_image_gtkagg.py example (in the 
examples/ directory). Since you're already using GtkAgg, it should be 
*really* easy to adapt the example to fit your needs. I've personally 
adapted it to do a live data display of a simulation run. If you *need* 
it to wait for user interaction before continuing, there might be a 
little bit more work, but I don't think it'd be much. You could 
probably instead look at some of the Matplotlib UI widgets, like in the 
buttons.py example.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma