matplotlib-devel Mailing List for matplotlib (Page 538)

When I run the script below, the range tuple is 
[0.0, 1.0, 0.0, 1.0]
 
but the data has an actual range more like [ 0, 6.8, 0, 1], the plot
looks correct, which is good, but the range tuple is wrong. It seems
to work fine with simple data examples but breaks with this data..
This is with Matplotlib v0.54.2
thanks,
S
#!/usr/bin/env python
import matplotlib
matplotlib.use( 'Agg' )
from matplotlib.matlab import *
x = [0.010331810701842871, 0.021066657441595242, 0.030855574358625324,
 0.040250726568746162, 0.050644838316290561, 0.06189415611955508,
 0.07125403603817515, 0.081941196069626396, 0.090571411794129267,
 0.10290686247291918, 0.11444331944589031, 0.1236257225395061,
 0.13473835780826723, 0.14381271569968049, 0.15290481341399415,
 0.16191929992110601, 0.17121682383712447, 0.18154558306766691,
 0.19166699839060464, 0.20041014147521002, 0.21840114667773247,
 0.22475368329468168, 0.23712042657177207, 0.24150561679187502,
 0.25777416395085717, 0.26370159485599637, 0.27115042730497135,
 0.28646842404763118, 0.2945605476107212, 0.3014844847904839,
 0.32090649437954005, 0.33474756188146532, 0.3463087158021369,
 0.35384920060301411, 0.36174596447259966, 0.37111350597671988,
 0.38500936142234621, 0.39310145975693639, 0.40090051408431981,
 0.41178548112097552, 0.42521787270909123, 0.43091391530572509,
 0.44614791389868291, 0.45494374609978966, 0.46186821556645236,
 0.47731590557971521, 0.48107399513220339, 0.4960609645338554,
 0.50293271758231672, 0.51908955994969641, 0.52754726056509504,
 0.538105663764743, 0.54695915774055104, 0.55445022367222696,
 0.56141617038929059, 0.57715732876336034, 0.58331953613820509,
 0.59203627993390995, 0.61018141394423642, 0.62628626881841487,
 0.63192539107874746, 0.6458016862544731, 0.65418149983636986,
 0.66065035611712197, 0.67079601269616063, 0.69003927324831349,
 0.70370643441733494, 0.71145337333441738, 0.72891863943192814,
 0.73620657868200012, 0.7416812708183288, 0.7543094129509258,
 0.76333622772703824, 0.77279502708216075, 0.78113840195825734,
 0.79518542174128759, 0.80283072754516693, 0.81348359069451792,
 0.82483196143668502, 0.83317823230638111, 0.84262635287300347,
 0.85060271704979107, 0.86622649392165829, 0.87378445858363607,
 0.88564073099481444, 0.89462710396172573, 0.90198905417679853,
 0.91225691885603977, 0.92314275233649545, 0.93022796091666171,
 0.94117604421861889, 0.95082199713874538, 0.96289363701352881,
 0.97353750955077867, 0.98050771299924244, 0.99071041335468191,
 1.0]
y = [
 6.8988430562808141, 6.0199122670123426, 5.4877276439939475,
 5.1709425981970805, 4.987254825650786, 4.7417327487085501,
 4.4978934463413314, 4.3250286563667935, 4.2007265350751535,
 4.0541464163597736, 3.9189273603700538, 3.8235472853454988,
 3.7164102779555512, 3.6445717916889664, 3.5480676732338021,
 3.4444786019802529, 3.3625904441222376, 3.2806471950213569,
 3.2011340640076367, 3.1510030907701263, 3.019839474428009,
 2.9822021628354816, 2.9059803156387574, 2.8856395987093051,
 2.7921865811397399, 2.7589612680359936, 2.7174335309498603,
 2.6324831804685527, 2.5900376295500123, 2.5597848772179619,
 2.4655519919224202, 2.4080342023330061, 2.357560958250656,
 2.3276036195316627, 2.2941290050680068, 2.2529601292610253,
 2.2040744982244793, 2.1752627057435507, 2.1490323132220679,
 2.1143606533996637, 2.0692410113398481, 2.0505144863177676,
 2.0051930431043892, 1.9783735967494613, 1.9567455423743982,
 1.9117142836414112, 1.9015246184270749, 1.8570312324545144,
 1.8373286819197756, 1.7930616898324281, 1.7698772818526114,
 1.7416837457846306, 1.7191776401533563, 1.6985358308203811,
 1.6826034910369574, 1.6460157936833077, 1.6312087148596748,
 1.6120311128551963, 1.5717381767713174, 1.5393408540494826,
 1.5277823839983642, 1.4990255085133, 1.482078897585539,
 1.4703127379153567, 1.4503193917059973, 1.414718900022627,
 1.3902791696828953, 1.3773840753041227, 1.3485627887870608,
 1.3368879344126419, 1.3280498048998697, 1.3087099772217325,
 1.2943614279230125, 1.2807173903668139, 1.2682285769430715,
 1.2471152061484074, 1.2357065246849019, 1.2212562025804223,
 1.2059396101922433, 1.19434578885053, 1.1818376806548032,
 1.1710070331197149, 1.150850866654737, 1.141314474700714,
 1.1268033459945574, 1.1160062947810399, 1.1072603628571882,
 1.0952161339218929, 1.082587112669787, 1.0743414397576259,
 1.0620959689501084, 1.0514270580154892, 1.0383865727621933,
 1.0270434782193152, 1.0198775771453545, 1.009374502605529,
 1.0]
plot(x, y )
print axis() # why does this print [0.0, 1.0, 0.0, 1.0]?
savefig('simple_plot')
		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

On 2004年10月05日 20:14:44 -0500, John Hunter
<jdh...@ac...> wrote:
> The work in progress claim is a bit overstated. If you search the
> user's mailing list for polar, you'll see some code that was posted
> that essentially provides a poorman's polar plot. It makes plot that
> roughly do the right things vis-a-vis polar, but to "do it right (tm)"
> you'll need to implement a polar axis class, derived from the Axis
> base class (eg use patch.Circle to draw the theta axis). A polar
> transform class is defined in the _transforms module. Among the other
> changes, you'll want to set the default transform for polar axes.
Yes, my idea is to do it "properly", but I'm still getting myself
familiar with the code.
My original plan was to create a class PolarSubplot(PolarAxes), in the
same way that Subplot derives from Axes. I would then create the
PolarAxes class, implementing all the necessary methods, like plot(),
imshow(), etc. That's why I mentioned imshow() and pcolor(), because
my idea is to implement not only line plots, but specially pseudo
color plots on the polar axes.
After looking at the code for transforms, though, I'm not sure if all
this is really necessary. It seems to me that I can define a polar
transform, and simply reuse all the methods already defined in the
Axes class to the all the work, is that right? I saw the PolarXY
transform in the _transforms module, but it seems to be just a stub
(matplotlib 0.63.0) -- it has no defined methods.
> If you decide you want to jump in, let me know and I'll write a more
> long winded email about what I think is involved, bearing in mind that
> I haven't actually implemented any of this code so my comments should
> be taken with a grain of salt.
A few more details would be great. As I said, I'm still looking at the
code and getting used to how things work. I would be very happy to
contribute with matplotlib, it's a fantastic work and something that
was missing in the Python world for quite a long time.
Roberto
-- 
Roberto De Almeida <ro...@de...>
this email is: [ ] bloggable [ ] ask first [ ] private [x] nonsense

>>>>> "Roberto" == Roberto De Almeida <ral...@gm...> writes:
 Roberto> Hi, I was wondering about the status of polar plots --
 Roberto> the website says only "work underway" If no one is
 Roberto> working on this, I'm interested on implement polar plots
 Roberto> (and also imshow, pcolor, etc).
The work in progress claim is a bit overstated. If you search the
user's mailing list for polar, you'll see some code that was posted
that essentially provides a poorman's polar plot. It makes plot that
roughly do the right things vis-a-vis polar, but to "do it right (tm)"
you'll need to implement a polar axis class, derived from the Axis
base class (eg use patch.Circle to draw the theta axis). A polar
transform class is defined in the _transforms module. Among the other
changes, you'll want to set the default transform for polar axes.
If you decide you want to jump in, let me know and I'll write a more
long winded email about what I think is involved, bearing in mind that
I haven't actually implemented any of this code so my comments should
be taken with a grain of salt. 
I'm not clear about the context of your mention of imshow and pcolor;
could you elaborate?
JDH

Hi,
I was wondering about the status of polar plots -- the website says
only "work underway" If no one is working on this, I'm interested on
implement polar plots (and also imshow, pcolor, etc).
Roberto
-- 
Roberto De Almeida <ro...@de...>
this email is: [ ] bloggable [ ] ask first [ ] private [x] nonsense

Hello,
I noticed that several of the SVG files installed by
matplotlib version 0.63.4 are marked as executable:
# tar tfvvz matplotlib-0.63.4.tar.gz | grep "rwx.*\.svg"
-rwxr-xr-x jdhunter/members 3064 matplotlib-0.63.4/images/back.svg
-rwxr-xr-x jdhunter/members 14402 matplotlib-0.63.4/images/filesave.svg
-rwxr-xr-x jdhunter/members 3069 matplotlib-0.63.4/images/forward.svg
-rwxr-xr-x jdhunter/members 4888 matplotlib-0.63.4/images/hand.svg
-rwxr-xr-x jdhunter/members 11796 matplotlib-0.63.4/images/home.svg
-rwxr-xr-x jdhunter/members 5906 matplotlib-0.63.4/images/move.svg
-rwxr-xr-x jdhunter/members 8998 matplotlib-0.63.4/images/zoom_to_rect.s=
vg
Probably the executable flag for these files should just
be cleared.
I hope this helps,
Jochen
--=20
http://seehuhn.de/

Yeah, now I remember installing those fonts a while ago so I could put
symbols in my diagrams in inkscape...
For embedding, we need SVG fonts. Would it be kosher to just use this:
http://xml.apache.org/batik/ttf2svg.html
or its equivalent to convert the BaKoMa fonts to SVG, and then include
the resulting SVG fonts in the matplotlib package?
Jared
> Hmm, this is strange and intriguing. I notice that you do not embed
> the fonts in your svg document, which is presumably why most viewers
> can't handle it. I confirmed that librsvg, which gqview uses, can't
> render the fonts either. The question is, why can Inkscape do it? I
> downloaded Inkscape and did a recursive grep through their src as well
> as a find in the root of their src tree and found no references to
> 'computer modern' or cmex, etc.... Did you have to set some path in
> inkscape to see your cm fonts, or did you put them in some standard
> place? Anyone have any ideas how inkscape manages to pull off this
> trick?
> Jared> John, are there any more features still missing from the
> Jared> SVG backend?
> 
> That almost does it. I think we need an option to embed the fonts
> directly into the svg document like we do for PS, because I think
> viewers that have the cm* fonts built in will be the exception rather
> than the rule. Fernando Perez has some colleagues who are interested
> in embedding clickable tags in svg, but I haven't heard much from
> them.
> 
> But overall SVG is in fine shape.

>>>>> "Jared" == Jared Wahlstrand <wah...@um...> writes:
 Jared> Hello, The attached patches implement mathtext for SVG. The
 Jared> output looks pretty good when viewed by Inkscape, but not
 Jared> the Adobe SVG viewer (it shows the wrong symbols and then
 Jared> moments later crashes Mozilla, at least on my system). It
 Jared> hasn't been thoroughly tested for all of the possible
 Jared> symbols.
Hmm, this is strange and intriguing. I notice that you do not embed
the fonts in your svg document, which is presumably why most viewers
can't handle it. I confirmed that librsvg, which gqview uses, can't
render the fonts either. The question is, why can Inkscape do it? I
downloaded Inkscape and did a recursive grep through their src as well
as a find in the root of their src tree and found no references to
'computer modern' or cmex, etc.... Did you have to set some path in
inkscape to see your cm fonts, or did you put them in some standard
place? Anyone have any ideas how inkscape manages to pull off this
trick?
 Jared> I had to add a math_parse_s_ft2font_svg() to mathtext.py,
 Jared> which basically does the same thing as
 Jared> math_parse_s_ft2font() but returns something different. I
 Jared> tried to just modify the latter function to take a
 Jared> "usingSVG=True" argument and ran into all sorts of bizarre
 Jared> problems, probably associated with the caching, and gave
 Jared> up. Perhaps someone can figure out how to do this more
 Jared> elegantly.
Probably the best way to do this is to subclass BakomaTrueTypeFonts
and override the just methods you need.
 Jared> John, are there any more features still missing from the
 Jared> SVG backend?
That almost does it. I think we need an option to embed the fonts
directly into the svg document like we do for PS, because I think
viewers that have the cm* fonts built in will be the exception rather
than the rule. Fernando Perez has some colleagues who are interested
in embedding clickable tags in svg, but I haven't heard much from
them.
But overall SVG is in fine shape.
Many thanks!
JDH

Hello,
The attached patches implement mathtext for SVG. The output looks pretty
good when viewed by Inkscape, but not the Adobe SVG viewer (it shows the
wrong symbols and then moments later crashes Mozilla, at least on my
system). It hasn't been thoroughly tested for all of the possible
symbols.
I had to add a math_parse_s_ft2font_svg() to mathtext.py, which
basically does the same thing as math_parse_s_ft2font() but returns
something different. I tried to just modify the latter function to take
a "usingSVG=True" argument and ran into all sorts of bizarre problems,
probably associated with the caching, and gave up. Perhaps someone can
figure out how to do this more elegantly.
John, are there any more features still missing from the SVG backend?
Cheers,
Jared

My system is set up so that when I am logged into root (via su) the root user 
cannot access the X display. I like this behavior but it means that I cannot 
install matplotlib as the root user (I can use sudo) because setup.py wants 
to import pygtk and wxPython both of which try to connect to the X display.
It seems to me that it is unnecessary to connect to the display to compile the 
matplotlib extensions, rather the import gtk command exists to test to see if 
the pygtk package is installed. If I am wrong then this does not matter. I 
thought that the build procedure would be more robust is it was not necessary 
to import the whole pygtk and wxPython packages in order to test for their 
presence. Is there a standard way to test for the presence of a package 
without actually importing it? I know that I could temporarily export a 
display for the root user - but I don't want to and I don't think it should 
be necessary if it is not required.
I have been thinking about ways to test for packages without importing them. 
Would it be possible to test for the offending packges by importing 
subpackages that do not connect to the X server? For example in the case of 
pygtk 'gobject' can be imported successfully when no X display is available. 
(This works on my system because pygtk-2.0 is part of the python path - I did 
not put it there so I assume that is standard - if not this procedure would 
require that the appropriate directory was appended to then removed from the 
python path.)
The disadvantages that I can see are that it would make the build procedure 
dependant on the naming of subpackages within a package and it would not 
actually check for a working installation just the presence of a certain 
package. I guess it depends how great the demand is to be able to install 
matplotlib from an environment that does not have a X display.
Cheers
Chris

Dear Mr. Horton:
I am investigating options for creating 2D contour plots for the freely
distributable Matplotlib package (http://matplotlib.sourceforge.net/).
The Matplotlib license requires all the software to be free for
noncommercial and commercial distribution.
I had the idea to try to implement marching squares for this package. We
know the marching cubes algorithm is patented, but what about the 2D
marching squares? Can my implementation be used in this freely
distributed package without obtaining a license grant?
Thanks,
Curtis
 * * * * * * * * * * * * * * * * * * * * * * * * * * * *
 * Curtis S. Cooper, Graduate Research Assistant *
 * Lunar and Planetary Laboratory, University of Arizona *
 * http://www.lpl.arizona.edu/~curtis/		 *
 * Kuiper Space Sciences, Rm. 318 *
 * 1629 E. University Blvd., *
 * Tucson, AZ 85721 * * * * * * * * * * * * * * *
 * Wk: (520) 621-1471 *
 * * * * * * * * * * * *

John Hunter <jdh...@ac...> writes:
| 
| Do you have any thoughts on how we might do labels with your code?
2 ways:
1) automatically: define a coarser(user defined coarseness) mesh on
 the function to be labelled, and add the labels in the vertices of
 this mesh. the angle of each label can easily be found from the
 closest contour line segment. this method avoids clusters of labels
 effectively, but will not be good in areas with high variability.
2) manually: let the user point and click on contours, I implemented
 this for use with gist that you could take a look at (clabel below).
 matlab also does this, and I think this is the best way for real
 publication quality. I have never seen automatic routines that do
 labelling well. TECPLOT is close but not quite there.
 I also attached a routine to do this for 2D stretched coordinates (see
 the contour plots with labels on
 http://www.ii.uib.no/~avle/python.html 
 for examples) which is called vclabel
| 
| If we decide to go with your routines, at least for the time being
| until we can "do it right", would you be willing to contribute your
| code to matplotlib under the matplotlib license (PSF inspired, free
| for commercial and noncommercial reuse)?
sure, no problem.
Helge
def clabel(z,clevels,opa=1,col='black',meth='std',digits=1):
 """
 clabel(z,clevels,opa=1,col='black')
 
 At the point where the mouse is clicked, print the contour level
 from clevels that are closest to the interpolated value in this
 point. Meant to be useful for labeling contour lines manually...
 
 optional arguments:
 opa=0 : Transparent text.
 opa=1 : Erase background under label
 col='white' : text color.
 meth= 'std' bilinear interpo on a std grid, might give error near coast
 'grid' values not given cellcentered but on corners of cells. 
 'bigrid' values taken from a bilinearly interpol fine mesh from
	 futil.contour
 'cell' takes value from cell directly
 Helge Avlesen <av...@ii...>
 
 """
 
 print """
 Insert contour levels by left clicking, middle button display
 values, right button finishes.
 """
 
 button=0
 while button<>3: 
 mus=gist.mouse() 
 button=mus[9]
	if meth=='bigrid':
	 i=int(2*mus[0])+1 ; j=int(2*mus[1])+1
	 x=2*mus[0]-i+1 ; y=2*mus[1]-j+1
	elif meth=='std':
	 i=int( mus[0] ); j=int( mus[1] )
	 x=mus[0]-i ; y=mus[1]-j
	elif meth=='grid':	 
	 xm=mus[0]+0.5 ; ym=mus[1]+0.5
	 i=int( xm ); j=int( ym )
	 x=xm-i ; y=ym-j
 elif meth=='cell':
 print mus[0], mus[1]
 i=int(round(mus[0])) ; j=int(round(mus[1]))
 if meth=='cell':
 val=z[i,j]
 print val,i,j
 else:
 # bilinear interpolation to find value 
 a00=z[i,j] 
 a10=z[i+1,j]-a00 
 a01=z[i,j+1]-a00 
 a11=z[i+1,j+1]-(a00+a10+a01) 
 val=a00 + a10*x + a01*y + a11*x*y
 print val,i,j,x,y 
 if button==1: 
 # compare this value to the selected levels
 diff= abs( clevels-val ) 
 # use the closest
 label=fpformat.fix( clevels[ Numeric.argmin(diff) ], digits )
 gist.plt(label, mus[0], mus[1], opaque=opa, tosys=1, \
 height=8, justify="CH", color=col )
def vclabel(z,sx,sy,clevels,opa=1,col='black',digits=1):
 """
 manual(z,clevels,opa=1,col='black')
 
 At the point where the mouse is clicked, print the contour level
 from clevels that are closest to the interpolated value in this
 point. Meant to be useful for labeling contour lines manually...
 sx[i,j],sy[i,j] is the x,z coordinate of point z[i,j]. if [:,1]
 denotes the top layer, [:,kb-1] the bottom (common in
 oceanography) j_is_down will be true. (z is always positive in
 the upward direction, but the indice j may go downwards)
 
 optional arguments:
 opa=0 : Transparent text.
 opa=1 : Use background color for text.
 col='white' : text color.
 digits: number of decimals in label
 Helge Avlesen <av...@ii...>
 
 """
 
 print """
 Insert contour levels by left clicking, middle button display
 depth, right button finishes.
 """
 kb=z.shape[1]
 im=z.shape[0]
 j_is_down=0 
 if sy[0,0]>sy[0,1]:
 j_is_down=1
 
 button=0
 while button<>3:
 mus=gist.mouse()
 button=mus[9]
 
	# bisection search for the indices
 i=hbisect( sx[:,0], mus[0] )
 if i<0 or i>im-1:
 print 'outside:',i
 continue
 
 x=(mus[0]-sx[i,0])/(sx[i+1,0]-sx[i,0])
 
 if j_is_down:
 finn=hbisect( (1.-x)*sy[i,::-1] + x*sy[i+1,::-1] , mus[1] )
 j=kb-2-finn
 if finn<0 or finn>kb-1:
 print 'outside',i,finn
 continue
 
 xa=Numeric.array((sx[i,j+1]+x*(sx[i+1,j+1]-sx[i,j+1]),\
 sy[i,j+1]+x*(sy[i+1,j+1]-sy[i,j+1])))
 
 if mus[1]-xa[1]<0:
 print 'below'
 continue
 
 xb=Numeric.array((sx[i,j]+x*(sx[i+1,j]-sx[i,j]),\
 sy[i,j]+x*(sy[i+1,j]-sy[i,j])))
 
 y=(((mus[0]-xa[0])**2 + (mus[1]-xa[1])**2 )\
 /((xb[0]-xa[0])**2 + (xb[1]-xa[1])**2 ))**0.5
 
 # bilinear interpolation to find value
 
 a1=z[i,j+1] 
 a2=z[i+1,j+1]-a1 
 a3=z[i,j]-a1	
 a4=z[i+1,j]-(a1+a2+a3) 
 val=a1 + a2*x + a3*y + a4*x*y
 else:
 print 'increasing j upwards not yet implemented'
 continue
 
 print 'x,y=',x,y,' i,j=',i,j, 'val=',val
 if button==1: 
 # compare this value to the selected levels
 diff= abs( clevels-val ) 
 # use the closest
 label=fpformat.fix( clevels[ Numeric.argmin(diff) ], 1)
 if opa==1:
 label=' '+label+' '
 gist.plt(label, mus[0], mus[1], opaque=opa, tosys=1, \
 height=8, justify="CH", color=col )

John Hunter schrieb:
>>>>>>"Fernando" =3D=3D Fernando Perez <Fer...@co...> writ=
es:
>=20
>=20
> Fernando> I think we're doing pretty good, except that people can
> Fernando> always kill themselves by running true WX/GTK apps via
> Fernando> @run. IPython is really not made for this, it can only
> Fernando> handle gracefully show() calls from pure matplotlib
> Fernando> scripts, not full-blown GUI apps. But I think we have a
> Fernando> very reasonable environment at this point for most usage
> Fernando> cases.
>=20
> It's looks like about 90% of your problems result from trying to cross
> GUI backends within IPython. Is this fair to say?
Well, not quite. As I mentioned, I put in a matplotlib.use() wrapper whi=
ch=20
traps invalid switches, so it's not a problem if a use() call is made. C=
ould=20
you add such a call to this one please? :
// OK with GTKAgg backend. It needs a use('GTKAgg') call to be safe for o=
ther
backends.
run dynamic_image_gtkagg.py
It's only when native GUI examples are run that things crash badly. Note=
 that=20
some of the segfaults occur from plain python:
// these are OK with gtkagg, but they segfault wxagg. The segfault happe=
ns
from a normal command line as well (no ipython).
run system_monitor.py
run dynamic_demo.py
And I also have these:
// these two run but segfault on exit under ipython. They run OK from a =
cmd line.
run dynamic_demo_wx.py
run dynamic_image_wxagg.py
I suspect these two are messing something up badly enough that if python =
quits=20
right away, you don't see the problem, but since ipython continues to run=
 the=20
interpreter, the problem appears. Since these are segfaults, I'm very mu=
ch=20
willing to blame the wx code in there, and not ipython (which is 100% pur=
e,=20
unpolluted python :)
> As far as I'm concerned I don't have a problem with these cases.
> Caveat emptor -- the user should be forewarned and expect disaster if
> they try and run GUI specific examples from ipython. Perhaps you
> should say pylab only supports pure matlab interface matplotlib at
> this point.
>=20
>>From your end I see why it's a concern - you don't want any run
> command to break or freeze ipython. If you have any ideas on what we
> should do I'll be happy to help on the matplotlib end, but I don't
> have any off the top of my head.
Yes, this is the real nasty. If you think that the ipython+matplotlib=20
combination is going to be a common one in the future for scientists, it =
may=20
be worth protecting the examples against disaster (given they tend to be =
what=20
people run to first). If you are willing to pay the price of 12 lines of=
 code=20
per example, you could put this snippet at the beginning of _every_ embed=
ded=20
example:
# Detect if we are inside IPython and bail if so. Threading problems
# make it very difficult to safely run full GTK/WX apps inside IPython.
try:
 __IPYTHON__
 msg =3D ("This script can NOT be run inside IPython.\n\n"
 "It embeds matplotlib into a complete GUI application, and\n"
 "for a number of reasons this is (and probably will remain)\n=
"
 "unsupported from inside IPython.\n\n"
 "You can run it from the command line as a regular python scr=
ipt.\n")
 raise RuntimeError,msg
except NameError:
 pass
This will make sure that users get a meaningful error message inside ipyt=
hon=20
instead of a bizarre lockup or segfault.
> I'll comment on some of the non cross-GUI problems below....
>=20
> Fernando> // These don't run with LANG=3D=3Dde_DE.UTF-8, but are OK
> Fernando> with en_US.UTF-8 run date_demo_convert.py run
> Fernando> date_demo1.py run date_demo2.py run date_demo_rrule.py
> Fernando> run finance_demo.py
>=20
> Do they run from the shell with LANG=3D=3Dde_DE.UTF-8? Any idea what i=
s
> going wrong?
Yes, the problem has nothing to do with ipython, it also happens with pla=
in=20
python. Note that the broken ones are:
// These don't run with LANG=3D=3Dde_DE.UTF-8, but are OK with en_US.UTF-=
8
run date_demo1.py
run date_demo2.py
run finance_demo.py
I think my original list had more by mistake. Here's a traceback (form=20
ipython, so you get better details):
In [5]: run date_demo1.py
-------------------------------------------------------------------------=
--
ValueError Traceback (most recent call las=
t)
/home/fperez/code/python/pylab/examples/date_demo1.py
 26 yearsFmt =3D DateFormatter('%Y')
 27
---> 28 quotes =3D quotes_historical_yahoo(
 29 'INTC', date1, date2)
 30 if not quotes:
/usr/local/lib/python2.3/site-packages/matplotlib/finance.py in=20
quotes_historical_yahoo(ticker, date1, date2)
 61 if len(vals)!=3D7: continue
 62 datestr =3D vals[0]
---> 63 dt =3D datetime.date(*time.strptime(datestr, '%d-%b-%y')[=
:3])
 64 d =3D date2num(dt)
 65 open, high, low, close =3D [float(val) for val in vals[=
1:5]]
/usr/src/build/394694-i386/install/usr/lib/python2.3/_strptime.py in=20
strptime(data_string, format)
 422 found =3D format_regex.match(data_string)
 423 if not found:
--> 424 raise ValueError("time data did not match format: data=3D=
%s=20
fmt=3D%s" %
 425 (data_string, format))
 426 if len(data_string) !=3D found.end():
ValueError: time data did not match format: data=3D31-Mar-04 fmt=3D%d-%=
b-%y
WARNING: Failure executing file: <date_demo1.py>
The problem is that under different locales, dates come out formatted=20
differently. You seem to have hardcoded format expectations which break =
in=20
the face of non-US locales.
> Fernando> run print_stdout.py
>=20
> This is an example script to show how to print png to stdout from agg.
> Perhaps this fails because ipython doesn't really expect a png coming
> in from stdout? The header of that file states
Well, running it again I'm getting this:
Exception in thread Thread-1:
Traceback (most recent call last):
 File "/usr/src/build/394694-i386/install/usr/lib/python2.3/threading.p=
y",=20
line 436, in __bootstrap
 self.run()
 File "/home/fperez/code/python/IPython/Shell.py", line 527, in run
 self.IP.mainloop()
 File "/home/fperez/code/python/IPython/iplib.py", line 948, in mainloo=
p
 self.interact(banner)
 File "/home/fperez/code/python/IPython/iplib.py", line 1036, in intera=
ct
 line =3D self.raw_input(prompt)
 File "/home/fperez/code/python/IPython/iplib.py", line 1263, in raw_in=
put
 return self.prefilter(raw_input(prompt),
IOError: [Errno 9] Ung=FCltiger Dateideskriptor
Pehaps you could add (if you decide that you like that idea) the __IPYTHO=
N__=20
trap code to this as well, so that all examples are made ipython-friendly=
. In=20
this one, the message could additionally show this:
 print png to standard out
 usage: python print_stdout.py > somefile.png
so users know what to do straight away.
> Thanks for the detailed notes.
No prob. I'm a big believer that good examples are what helps most new u=
sers,=20
so I'm trying to make sure that out-of-the-box, things run as smoothly as=
=20
possible for all those scientists who are just dying to start using matpl=
otlib=20
 with ipython :)
Best,
f

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:
 >> Hi again,
 >> 
 >> Yes, I had the thought that using C for the algorithm would be
 >> easier as well. There are actually some very well-written
 >> marching squares contouring algorithms in C already out there.
 >> I will try to find such an implementation and point you to it
 >> or send you the source code.
 >> 
 Perry> Thanks, that would be helpful. In my search I didn't come
 Perry> across many. Keep in mind the license needs to be
 Perry> compatible with that of matplotlib.
Of course, in addition to the license, there is the patent issue. I
believe marching squares is patented. I know marching cubes is.
 http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=4,710,876.WKU.&OS=PN/4,710,876&RS=PN/4,710,876
I checked the header of vtkMarchingSquares.cxx which states
 Program: Visualization Toolkit
 Module: $RCSfile: vtkMarchingSquares.cxx,v $
 
 Copyright (c) Ken Martin, Will Schroeder, Bill Lorensen
 All rights reserved.
 See Copyright.txt or http://www.kitware.com/Copyright.htm for details.
 
 
 THIS CLASS IS PATENTED UNDER UNITED STATES PATENT NUMBER 4,710,876
 "System and Method for the Display of Surface Structures Contained
 Within the Interior Region of a Solid Body".
 Application of this software for commercial purposes requires
 a license grant from GE. Contact:
but the patent number they reference which is linked above begins with
 A method and apparatus for displaying *three dimensional surface
 images* includes the utilization of a case table for rapid retrieval
 of surface approximation information.
emphasis mine. So I don't know for sure what the patent status of the
2D algorithm is.
JDH

>>>>> "Helge" == Helge Avlesen <av...@ii...> writes:
 Helge> http://www.ii.uib.no/~avle/mpl/c1.png
 Helge> the first points of the segments are given by the vectors
 Helge> (x1,y1) the second (x2,y2). you can get pretty lines in
 Helge> matplotlib as well, but only by using the scattered line
 Helge> drawing methods of gtk. (something like
 Helge> self.area.window.draw_segments(self.gc, zip( x1,y1,x2,y2)?)
OK, I see. I didn't fully understand that x1,x2,y1,y2 were the verts
of unordered line segments. Then one can easily use a LineCollection
to draw these efficiently in matplotlib - script below and screenshot
http://nitace.bsd.uchicago.edu:8080/files/share/kontour.png. Jeez, I
feel bad for sitting on this since February!
 Helge> if you want do do it "right" in matplotlib, you should
 Helge> implement a contour following algorithm (in C) - with this
 Helge> I mean an routine that returns the linesegments defining
 Helge> each countour in bundles. the current alg. is sort of
 Helge> marching cubes in 2D, a simplified version of CONREC
 Helge> http://astronomy.swin.edu.au/~pbourke/projection/conrec/
 Helge> but only using 2 triangles per square.
Do you have any thoughts on how we might do labels with your code?
 Helge> doing contour following alg. it is also much easier to
 Helge> implement automatic contour labelling. I suspect python
 Helge> loops are too slow for such algorithms - it may perhaps be
 Helge> possible to do them in Numeric, but it will still be much
 Helge> slower than my simple library. I think you may use the
 Helge> GPL'ed PLPLOT (C) for an example of contour following alg.
We have a problem in that we cannot use GPL'd code in matplotlib
because the GPL does not allow redistribution of closed code, which
the matplotlib (and python license) do.
If we decide to go with your routines, at least for the time being
until we can "do it right", would you be willing to contribute your
code to matplotlib under the matplotlib license (PSF inspired, free
for commercial and noncommercial reuse)?
Thanks!
JDH
from matplotlib.matlab import *
from matplotlib.collections import LineCollection
import hutil
delta = 0.05
x = y = arange(-3.0, 3.0, delta)
X, Y = meshgrid(x, y)
Z1 = bivariate_normal(X, Y, 1.0, 1.0, 0.0, 0.0)
Z2 = bivariate_normal(X, Y, 1.5, 0.5, 1, 1)
Z = Z2-Z1
print Z.shape
fsm = ones(Z.shape, Z.typecode())
zmax, zmin = hutil.maxmin(Z)
depths=linspace(zmin, zmax, 10)
x1,y1,x2,y2 = hutil.contour2(Z, fsm, depths )
imshow(Z, origin='lower', interpolation='nearest')
segments = [ ( (thisy1, thisx1), (thisy2, thisx2) ) 
 for thisx1, thisy1, thisx2, thisy2 in zip( x1,y1,x2,y2)]
coll = LineCollection(segments)
gca().add_collection(coll)
savefig('kontour')
show()

John Hunter <jdh...@ac...> writes:
| I was concerned by the fact that the lines were not smooth - if you
| plot a connected line they line jumps from side to side. But it
| does get the contour right, and is implemented in pure numeric, and
| so it occurs to me that it might be easier to fix this problem than
| start from scratch. Perhaps Helge or one of you has some insight
| into how to fix this.
| 
| I'm attaching a modified version of the tarfile Helge initially sent
| me. I've included a script testkont_mpl.py that calls Helge's lib.
| Change the '.' linestyle to '-' to see the problem I discussed.
Hi,
not sure if I have matplotlib 100% correctly installed, but this is
what I see using your example script:
http://www.ii.uib.no/~avle/mpl/c0.png
(and with the current algorithm, more or less what I would expect...)
to get straight lines you must plot segments one by one since they are
not ordered. if I use gist for this(see the script at the end) I get
http://www.ii.uib.no/~avle/mpl/c1.png
the first points of the segments are given by the vectors (x1,y1) the
second (x2,y2). you can get pretty lines in matplotlib as well, but
only by using the scattered line drawing methods of gtk. (something
like self.area.window.draw_segments(self.gc, zip( x1,y1,x2,y2)?)
if you want do do it "right" in matplotlib, you should implement a
contour following algorithm (in C) - with this I mean an routine that
returns the linesegments defining each countour in bundles. the
current alg. is sort of marching cubes in 2D, a simplified version of
CONREC 
http://astronomy.swin.edu.au/~pbourke/projection/conrec/
but only using 2 triangles per square. 
doing contour following alg. it is also much easier to implement
automatic contour labelling. I suspect python loops are too slow for
such algorithms - it may perhaps be possible to do them in Numeric,
but it will still be much slower than my simple library. I think you
may use the GPL'ed PLPLOT (C) for an example of contour following alg.
Helge
from matplotlib.matlab import *
import hutil
delta = 0.05
x = y = arange(-3.0, 3.0, delta)
X, Y = meshgrid(x, y)
Z1 = bivariate_normal(X, Y, 1.0, 1.0, 0.0, 0.0)
Z2 = bivariate_normal(X, Y, 1.5, 0.5, 1, 1)
Z = Z2-Z1
print Z.shape
#fsm = ones(Z.shape, Z.typecode())
fsm = ones(Z.shape, 'l')
zmax, zmin = hutil.maxmin(Z)
depths=linspace(zmin, zmax, 10)
x1,y1,x2,y2 = hutil.contour2(Z, fsm, depths )
#imshow(Z, origin='lower', interpolation='nearest')
#plot(y2,x2,'-')
#show()
import gist
gist.pldefault(dpi=100,style='framed.gs')
gist.palette('rainbow.gp')
gist.pli(transpose(Z))
gist.pldj(x1,y1,x2,y2) # draw disjoint segments

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> I think we're doing pretty good, except that people can
 Fernando> always kill themselves by running true WX/GTK apps via
 Fernando> @run. IPython is really not made for this, it can only
 Fernando> handle gracefully show() calls from pure matplotlib
 Fernando> scripts, not full-blown GUI apps. But I think we have a
 Fernando> very reasonable environment at this point for most usage
 Fernando> cases.
It's looks like about 90% of your problems result from trying to cross
GUI backends within IPython. Is this fair to say?
As far as I'm concerned I don't have a problem with these cases.
Caveat emptor -- the user should be forewarned and expect disaster if
they try and run GUI specific examples from ipython. Perhaps you
should say pylab only supports pure matlab interface matplotlib at
this point.
From your end I see why it's a concern - you don't want any run
command to break or freeze ipython. If you have any ideas on what we
should do I'll be happy to help on the matplotlib end, but I don't
have any off the top of my head.
I'll comment on some of the non cross-GUI problems below....
 Fernando> // These don't run with LANG==de_DE.UTF-8, but are OK
 Fernando> with en_US.UTF-8 run date_demo_convert.py run
 Fernando> date_demo1.py run date_demo2.py run date_demo_rrule.py
 Fernando> run finance_demo.py
Do they run from the shell with LANG==de_DE.UTF-8? Any idea what is
going wrong?
 Fernando> run print_stdout.py
This is an example script to show how to print png to stdout from agg.
Perhaps this fails because ipython doesn't really expect a png coming
in from stdout? The header of that file states
 # print png to standard out
 # usage: python print_stdout.py > somefile.png
 Fernando> ****run ftface_props.py
 ---> 71 font.jdh = 'hi'
I was testing to see if I could setattr on my extension class. I'll
just remove this line from the example
 Fernando> ****run movie_demo.py: with WX backend it doesn't make
 Fernando> the .png frames at all with WXAgg, it runs fine but
 Fernando> fails to make the movie: ... Saving frame _tmp049.png
 Fernando> Making movie animation.mpg - this make take a while sh:
 Fernando> line 1: mpeg2encode: command not found convert: Delegate
 Fernando> failed (mpeg2encode "%i" "%o"). convert: Delegate
 Fernando> failed (mpeg2encode "%i" "%o") [No such file or
 Fernando> directory].
 Fernando> Symlinking mpeg2encode to mpeg2enc (the real binary)
 Fernando> doesn't help, a different error comes back.
 Fernando> I got it to work by commenting out the convert call and
 Fernando> reverting to the mencoder one. Great!
Yes, this fails on my system too. This line works
 os.system("convert _tmp*.png animation.mpg")
but I wasn't able to get convert to make mpg. I'll fixed this in the
examples dir and made the mencoder line the default.
 Fernando> ****run vertical_ticklabels.py
 Fernando> ---------------------------------------------------------------------------
 Fernando> NameError Traceback (most recent call last)
 Fernando> /home/fperez/code/python/pylab/examples/vertical_ticklabels.py
 Fernando> 3 4 plot([1,2,3,4], [1,4,9,16]) 5 xticks([1,2,3,4],
 Fernando> ['Frogs', 'Hogs', 'Bogs', 'Slogs'])
 ----> 6 set(t, 'rotation', 'vertical')
 Fernando> 7 show()
 Fernando> NameError: name 't' is not defined WARNING: Failure
 Fernando> executing file: <vertical_ticklabels.py>
Fixed. This also pointed me a bug in the new commands xticks and
yticks; they weren't returning the things they claimed in the doc
string.
Thanks for the detailed notes.
JDH

> Hi again,
>
> Yes, I had the thought that using C for the algorithm would be easier as
> well. There are actually some very well-written marching squares
> contouring algorithms in C already out there. I will try to find such an
> implementation and point you to it or send you the source code.
>
Thanks, that would be helpful. In my search I didn't come across many.
Keep in mind the license needs to be compatible with that of matplotlib.
> The second half is just the drawing, which should be implemented in
> matplotlib using the line collections class. Since vector plotting is not
Yeah, that's what we have in mind.
> that hard, I will try to get that working first. Then, someone can take
> my source code and adapt it easily to the contouring problem, once an
> effective and sufficiently high-performance algorithm implementation can
> be found.
>
> Cheers,
> Curtis
>
OK, Perry

> We are trying to adapt the C contour program that is used by gist
> (and can be found in the contour routine used by xplt in scipy).
> It would be best to look at the source for the precise description
> of the algorithm it uses (note though that gist apparently uses
> two different pieces of contour code for its contour tasks. The
> one we are looking to adapt, mainly because it appears much easier
> to isolate from the gist environment is the gcntr.c version).
> I would be amazed if one could find a pure Python algorithm to do
> contouring that was fast enough. Our current plan is to use these
> C routines to generate the contour segments, and do the plotting
> from within Python (as well as any contour labeling).
>
> If you have expertise in this area you may be able to do it better
> and faster than we can. Currently it is being worked on part time
> so we aren't able to do it as fast as we would like. I'm hoping that we
> will have at least a basic version (e.g., no labeling) in a couple
> weeks.
>
> If you want me to send or point you to the source code we are
> using as the basis, let me know.
Hi again,
Yes, I had the thought that using C for the algorithm would be easier as
well. There are actually some very well-written marching squares
contouring algorithms in C already out there. I will try to find such an
implementation and point you to it or send you the source code.
The second half is just the drawing, which should be implemented in
matplotlib using the line collections class. Since vector plotting is not
that hard, I will try to get that working first. Then, someone can take
my source code and adapt it easily to the contouring problem, once an
effective and sufficiently high-performance algorithm implementation can
be found.
Cheers,
Curtis

Curtis Cooper writes:
> My research is in computational fluid dynamics (specifically, the
> meteorologies of planetary atmospheres). Working contour and vector plots
> in matplotlib would make it possible for me to make 2D meteorological maps
> of atmospheric layers, etc.
>
> I noticed for the first time in the goals page that contour plots are
> being worked on, apparently by STSci. I have been considering
> implementing these two plot types as sets of line collections, but now
> that I know contour plots are being worked on, and vector plots are
> simpler to implement (in 2D), I will work on making vector plots. The
> mathematics is fairly straightforward. I just need to learn how to use
> the class library.
>
> About contour plots, however, I have a couple of questions. How is it
> being implemented? I was about to try to write a marching squares
> contouring routine, although it might have been painfully slow in Python.
> Does anyone have experience with this?
>
We are trying to adapt the C contour program that is used by gist
(and can be found in the contour routine used by xplt in scipy).
It would be best to look at the source for the precise description
of the algorithm it uses (note though that gist apparently uses
two different pieces of contour code for its contour tasks. The
one we are looking to adapt, mainly because it appears much easier
to isolate from the gist environment is the gcntr.c version).
I would be amazed if one could find a pure Python algorithm to do
contouring that was fast enough. Our current plan is to use these
C routines to generate the contour segments, and do the plotting
from within Python (as well as any contour labeling).
If you have expertise in this area you may be able to do it better
and faster than we can. Currently it is being worked on part time
so we aren't able to do it as fast as we would like. I'm hoping that we
will have at least a basic version (e.g., no labeling) in a couple
weeks.
If you want me to send or point you to the source code we are
using as the basis, let me know.
Perry Greenfield

Hi,
My research is in computational fluid dynamics (specifically, the
meteorologies of planetary atmospheres). Working contour and vector plots
in matplotlib would make it possible for me to make 2D meteorological maps
of atmospheric layers, etc.
I noticed for the first time in the goals page that contour plots are
being worked on, apparently by STSci. I have been considering
implementing these two plot types as sets of line collections, but now
that I know contour plots are being worked on, and vector plots are
simpler to implement (in 2D), I will work on making vector plots. The
mathematics is fairly straightforward. I just need to learn how to use
the class library.
About contour plots, however, I have a couple of questions. How is it
being implemented? I was about to try to write a marching squares
contouring routine, although it might have been painfully slow in Python.
Does anyone have experience with this?
Cheers,
Curtis

Hey John,
I've added code to ipython to wrap use() to prevent users from switching 
backends interactively, since this will instantly crash things badly. It's a 
nice example of how python's dynamic nature allows you to tweak a module from 
the outside, without having to poke at its source. I now see could have done 
this for the show() problem as well, since it's essentially the same logic, so 
I shouldn't really have bothered you with source changes to the backends. 
Well, at least it was done in a generic way and not slapping code all over 
many files...
With this safety in place, I tried running ALL the examples in 0.63 to see how 
we fare. I compiled some notes along the way, here they are for your (and 
other user's) reference.
I think we're doing pretty good, except that people can always kill themselves 
by running true WX/GTK apps via @run. IPython is really not made for this, it 
can only handle gracefully show() calls from pure matplotlib scripts, not 
full-blown GUI apps. But I think we have a very reasonable environment at 
this point for most usage cases.
Cheers,
f
#############################################################################
matplotlib examples under iypthon -pylab
----------------------------------------
I ran all the examples in mpl 0.63 with ipython (CVS from Sept 29/04, post
0.6.4.rc1). This was done using 'run foo.py', to see how robust this is.
Most examples run fine, and leave ipython usable afterwards. Those listed
below had some type of problem.
Platform notes: Fedora core 2, python 2.3.3, Numeric 23.5, matplotlib 0.63
compiled only with Numeric (no numarray) support.
// These don't run with LANG==de_DE.UTF-8, but are OK with en_US.UTF-8
run date_demo_convert.py
run date_demo1.py
run date_demo2.py
run date_demo_rrule.py
run finance_demo.py
// these two run but segfault on exit under ipython. They run OK from a cmd line.
run dynamic_demo_wx.py # this one runs, segfaults on exit
run dynamic_image_wxagg.py # this one runs, segfaults on exit
// OK with GTKAgg backend. It needs a use('GTKAgg') call to be safe for other
backends.
run dynamic_image_gtkagg.py #
// these are OK with gtkagg, but they segfault wxagg. The segfault happens
from a normal command line as well (no ipython).
run system_monitor.py
run dynamic_demo.py
// these block ipython/pylab - any embedded true Wx/gtk stuff will kill 
ipython badly. What should we do here?
run print_stdout.py
run object_picker.py
run embedding_in_gtk2.py
run embedding_in_gtk.py
run embedding_in_tk.py
run embedding_in_wx.py
run embedding_in_wx2.py
run embedding_in_wx3.py
run embedding_in_wx4.py
run mpl_with_glade.py
// other errors (not ipython related)
****run ftface_props.py
---------------------------------------------------------------------------
SystemError Traceback (most recent call last)
/home/fperez/code/python/pylab/examples/ftface_props.py
 68 print 'Mult. masters :', font.style_flags & 
FT_FACE_FLAG_MULTIPLE_MASTERS != 0
 69 print 'Glyph names :', font.style_flags & FT_FACE_FLAG_GLYPH_NAMES 
 != 0
 70
---> 71 font.jdh = 'hi'
 72 print dir(font)
SystemError: error return without exception set
WARNING: Failure executing file: <ftface_props.py>
****run movie_demo.py:
with WX backend it doesn't make the .png frames at all
with WXAgg, it runs fine but fails to make the movie:
...
Saving frame _tmp049.png
Making movie animation.mpg - this make take a while
sh: line 1: mpeg2encode: command not found
convert: Delegate failed (mpeg2encode "%i" "%o").
convert: Delegate failed (mpeg2encode "%i" "%o") [No such file or directory].
Symlinking mpeg2encode to mpeg2enc (the real binary) doesn't help, a different
error comes back.
I got it to work by commenting out the convert call and reverting to the
mencoder one. Great!
****run vertical_ticklabels.py
---------------------------------------------------------------------------
NameError Traceback (most recent call last)
/home/fperez/code/python/pylab/examples/vertical_ticklabels.py
 3
 4 plot([1,2,3,4], [1,4,9,16])
 5 xticks([1,2,3,4], ['Frogs', 'Hogs', 'Bogs', 'Slogs'])
----> 6 set(t, 'rotation', 'vertical')
 7 show()
NameError: name 't' is not defined
WARNING: Failure executing file: <vertical_ticklabels.py>

John Hunter schrieb:
> Are the levels indicated above sufficient to cover the spectrum? 
They sound reasonable, though I'd almost prefer a numerical value (0-4) 
instead of the names. Minor nit, though, feel free to ignore.
> What should the default be (either error or helpful)? 
Error. Good command line tools stay silent when successful (I'm paraphrasing 
some well-known unix quote I don't have at hand)
> Should we add a command line flag to allow the user to override the
> default level for easy access to debug info?
Yes.
Good job.
f

I added a Verbose class to matplotlib.__init__ and some verbose
options to rc. Quoting from rc
 # Set the verbose flags. This controls how much information
 # matplotlib gives you at runtime and where it goes. Ther verbosity
 # levels are: silent, error, helpful, debug, debug-annoying. At the
 # error level, you will only get error messages. Any level is
 # inclusive of all the levels below it. Ie, if your setting is
 # helpful, you'll also get all the error messages. If you setting is
 # debug, you'll get all the error and helpful messages. It is not
 # recommended to make your setting silent because you will not even
 # get error messages. When submitting problems to the mailing-list,
 # please set verbose to helpful or debug and paste the output into
 # your report.
 #
 #
 # The fileo gives the destination for any calls to verbose.report.
 # The erro gives the destination for any calls to
 # verbose.report_error. These objects can a filename, sys.stderr, or
 # sys.stdout. 
 #
 # You can access the verbose instance in your code
 # from matplotlib import verbose.
 verbose.level : helpful # one of silent, error, helpful, debug, debug-annoying
 verbose.fileo : sys.stdout # a log filename, sys.stdout or sys.stderr
 verbose.erro : sys.stderr # a log filename, sys.stdout or sys.stderr
In matplotlib code, you should no longer print to stdout or stderr;
rather you should do
 verbose.report('some message')
 verbose.report_error('some error message')
 #only report at debug levels or higher
 verbose.report('some message', 'debug') 
I haven't migrated all the matplotlib code yet, but I've gotten a
start. I've made some changes to the code base already so that
typical causes of user problems are reported in the helpful mode. Eg,
 hunter:~/python/projects/matplotlib> python examples/simple_plot.py -dWXAgg
 loaded rc file /hunter/jdhunter/python/projects/matplotlib/.matplotlibrc
 verbose.level helpful
 interactive False
 matplotlib version 0.63.4
 numerix Numeric 23.5
 font search path ['/usr/local/share/matplotlib']
 loaded ttfcache file /home/jdhunter/.ttffont.cache
 matplotlib data path /usr/local/share/matplotlib
 backend WXAgg version 2.4.2.4u
Backend authors, please set the string backend_version. The default
is 'unknown'. Eg in wx
 backend_version = wx.VERSION_STRING
Are the levels indicated above sufficient to cover the spectrum? 
What should the default be (either error or helpful)? 
Should we add a command line flag to allow the user to override the
default level for easy access to debug info?
Let me know if you have any comments or problems with the design or
implementation.
JDH

What's new in matplotlib-0.63.0
 Announce notes with links available at
 http://matplotlib.sf.net/whats_new.html
 * image interpolation works properly. I think I have finally and
 for real this time fixed the image interpolation / edge effect
 bug. It turns out there was a bug in antigrain (very unusual!)
 that was just found, fixed, and released. I've incorporated the
 latest release into matplotlib, and after talking with the Maxim
 implemented a solution in matplotlib which fixes the edge problem
 w/o the view lim hack used previously. Basically, I pad the edges
 of the input image. This is described in more detail in the new
 examples/image_interp.py. There is still an occasional off by 1
 rounding problem that causes a 1 pixel error (this is independent
 of the interpolation/edge bug). 
 * The dates handling is rewritten from the ground up, and now
 requires python2.3. It makes extensive use of dateutil for date
 ticking. All of your old date code will break, but it's an easy
 port. In particular, note that the date tick location
 constructors now have a different meaning. See
 http://matplotlib.sf.net/API_CHANGES,
 http://matplotlib.sf.net/matplotlib.dates.html, the updated date
 demos in examples/ and the new dates tutorial at
 http://matplotlib.sf.net/tutorial.html#dates.
 * setup.py now automatically detects Numeric, numarray or both, and
 compiles in the appropriate extension code. Thus you can use
 matplotlib with either or both packages and still get the optimal
 performance. So it is no longer necessary to set NUMERIX in
 setup.py, but it is necessary to have the extensions you want
 compiled available at the time you compile matplotlib. The win32
 build is for numarray 1.1.
 * new functions xlim, ylim, xticks and yticks to make setting axis
 limits, tick locations and labels more natural and elegant.
 * Reorganized all python library code to lib/ subdir
 * Added print to file handle for backend agg; see
 examples/print_stdout.py. Useful for webapp servers who want to
 print to a pipe.
 * x and y coords are printed in the toolbar on nouse motion in
 backends gtk* and tkagg (not implemented yet in wx*). You can set
 the axis attributes ax.fmt_xdata and ax.fmt_ydata with callable
 functions to control the formatting of the reported coords
 (default uses the major tick formatter). See
 examples/coords_report.py and examples/date_demo1.py.
 * Added axhline, axvline, axhspan and axvspan for plotting lines and
 rectangles (spans) in mixed data/axes coords. This is useful if
 for example, you want to provide a threshold line or range where
 the x range spans the axes (0-1 in axes coords) and the y range is
 given in data units. See example/axhspan_demo.py.
Downloads at https://sourceforge.net/projects/matplotlib/
JDH

Hello:
Is anyone working on an Aquaterm backend for Mac OS X? (I did a search 
for Aquaterm on this list and didn't find anything.) If you haven't 
heard of Aquaterm, see:
http://aquaterm.sourceforge.net/index.shtml?page=a3
It is a standard Gnuplot terminal for Mac OS X. I believe that all the 
appropriate pieces are in place for a matplotlib backend: Aquaterm 
communicates via Distributed Objects, which can be accessed, I believe, 
by the newest revision of PyObjC. I've looked at an example Aquaterm 
adapter written in C and it looks accessible. Anyone else thinking 
about this?
Tom
http://kornack.com
Fundamental Symmetries Lab, Princeton University
609-716-7259 (h), 609-933-2186 (m), 609-258-0702 (w), 609-258-1625 (f)
Thomas Kornack, 157 North Post Road, Princeton Junction, NJ 08550-5009