matplotlib-devel Mailing List for matplotlib

Hi,
the more recent information on installing matplotlib on AIX with XLC 
compiler are pretty dated (5 years ago), so I'd like to let you know 
what I did to have it on my machine. This is matplotlib-v1.1.0 on 
AIX-v5.3 and xlc-v10.1
Some code is worth 1000 words, so here it is, just a couple of comments:
- Note that similar problems occurred when installing scipy: 
http://projects.scipy.org/scipy/ticket/1299
- if I understand C++ Standard (ISO/IEC 14882), section 14.6.4.2, you 
should apply my patch1 below to the mainline (trunk).
#!/bin/bash
 
 
 
cat >xlC <<-"xlC-script-fooling"
 #!/bin/bash
 echo "Davide's xlC - parameters:" $*
 tbr=""
 
 
 
 # getting rid of wrong cc_r first argument
 # note that 1ドル becomes $params[0]
 [ "1ドル" = "cc_r" ] && tbr=0
 
 
 
 # getting rid of other unwanted arguments
 params=( "$@" );
 
 
 
 for i in ${!params[*]}; do
 # you don't link to stdc++ with XL compilers
 [ "${params[$i]}" == "-lstdc++" ] && tbr="$tbr $i"
 done
 
 
 
 for i in $tbr; do
 unset params[$i]
 done
 # -qmkshrobj is to create shared objects with XLC
 set -- "-qmkshrobj ${params[@]}"
 /bin/xlC $*
xlC-script-fooling
cat xlC
chmod +x xlC
cp setup.cfg.template setup.cfg
patch setup.cfg <<-"patch0"
60c
#macosx = False
.
17c
#verbose = True
.
9c
#basedirlist = /usr
.
patch0
patch agg24/include/agg_rasterizer_cells_aa.h <<-"patch1"
499c
 template <class T> AGG_INLINE void swap_cells(T* a, T* b)
.
patch1
# Note sure why they think this should be undefined on AIX
patch src/_png.cpp <<-"patch2"
34c
#endif */
.
32c
/* #ifdef _AIX
.
patch2
export PATH=$PATH:`pwd`
export PKG_CONFIG_PATH=/contrib/freetype/2.4.8/lib/pkgconfig/
export CFLAGS="-qcpluscmt -bnoquiet -I/contrib/zlib/include/ 
-I/contrib/libpng-1.2.40/include/"
source /contrib/Modules/3.2.6/init/bash
module load python zlib libpng-1.2.40
cat setup.cfg
echo
export
echo
python setup.py build
rm xlC
Regards,
Davide Del Vento,
NCAR Computational & Information Services Laboratory
Consulting Services Software Engineer
http://www.cisl.ucar.edu/hss/csg/
SEA Chair http://sea.ucar.edu/

I had some time to work on matplotlib, and created pull request #633 to
fix a bug reported recently. I branched off v1.1.x since the fix is
small and self-contained, and thought I'd create a different branch for
master, where the relevant code has changed a little. (What should the
process be in this kind of cases?)
However, it seems that v1.1.x has diverged from master:
commit 2da9d8fb5d087eaeb31c0af88141aafaf0716e9c
Merge: 3c3c466 585606f
Author: Eric Firing <ef...@ha...>
Date: Wed Dec 14 10:01:53 2011 -0800
 Merge pull request #627 from efiring/quiver_angle
 
 Quiver: copy input angles array to avoid side effects; fixes issue #625
commit 3c3c466564cba3d80f928a46857e54738787779b
Merge: 96caca8 fb52b96
Author: Michael Droettboom <md...@gm...>
Date: Wed Dec 14 06:10:26 2011 -0800
 Merge pull request #586 from mdboom/numpy-version-13
 
 Numpy version 1.4
commit 585606f7bd79b93cbaa9d538cbf537c82cb9a4a6
Author: Eric Firing <ef...@ha...>
Date: Tue Dec 13 07:53:54 2011 -1000
 Quiver: copy input angles array to avoid side effects; fixes issue #625
commit fb52b961a596c41fa2a1bb2dd85d7078f2ad39de
Author: Michael Droettboom <md...@gm...>
Date: Mon Nov 14 14:42:28 2011 -0500
 Put the minimum required version of Numpy in one place.
commit bf73b9088e0ce5e2dfcc5b2cac9a4f20515ed9f2
Author: Michael Droettboom <md...@gm...>
Date: Mon Nov 14 08:31:34 2011 -0500
 Update checks and documentation to refer to Numpy 1.4 as the minimum Numpy version.
I presume all of these changes are wanted on master, but the branch
doesn't merge cleanly. It would probably be best if the author of each
change did the merging into master, since they know best how to resolve
any merge conflicts. I can make a suggested merge as a pull request, but
it would be best if Eric and Michael reviewed it.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi mpl developers,
Over the last months I've become a great matplotlib fan. There's one thing that I miss a lot:
- a non-interactive X backend
that is fast to use remotely.
The GTK and TK backends have too much overhead for remote use, they're pretty unresponsive. The non-interactive backends all output to files.
For analyzing data that is on a remote machine, one now has to either:
1. transfer data to local machine to analyze (quite an effort if it's much data)
2. analyze remotely, generate remote graphics file, transfer graphics file, open graphics file locally to inspect the result
Both options are far from ideal, and having remote data is not an uncommon thing.
In IDL (interactive data languge), there is such a low-level, non-interactive, X 'device' that one can plot to. It is as fast for remote uses as for local uses.
Unfortunately, I'm not an X expert myself, but I'd be very interested in collaborating on a 'minimalist X backend' effort.
Is anybody interested?
Best,
Daan

Sorry for the multiple mailings.
in makers.py I request to change
 def _set_custom_marker(self, path):
 verts = path.vertices
 rescale = max(np.max(np.abs(verts[:,0])),
np.max(np.abs(verts[:,1])))
 self._transform = Affine2D().scale(1.0 / rescale)
 self._path = path
to
 def _set_custom_marker(self, path):
 verts = path.vertices
 rescale = np.max(np.sqrt(np.square(verts[:,0]) +
np.square(verts[:,1])))
 self._transform = Affine2D().scale(1.0 / rescale)
 self._path = path
such that the symbol *radius* is normalized to 1.0
This way my previous example give better results if the symbol is rotated:
import matplotlib.path as path
from matplotlib.transforms import Affine2D
# define codes
P = path.Path
Pm = P.MOVETO
Pl = P.LINETO
Pc = P.CLOSEPOLY
c = [Pm] + [Pl]*3 + [Pc]
cx=c*2
# define basic path
r=np.array(((-1.,-1),(1.,-1),(1.,1.),(-1,1.),(-1,-1)))
# we add second closed path of half size but reverse parity
rh=0.5*r[::-1]
rx = np.vstack((r,rh))
p = path.Path(rx,codes=cx)
x = np.linspace(0,1,10)**2
plot(x,c='r',marker=p,ms=10)
pr = p.transformed(Affine2D().rotate_deg(45.))
plot(x,c='r',marker=pr,ms=10)
show()
I think this is how it is "meant" to be, but maybe you have to add a
parameter to allow people recover the current behavior in that case.
-Alexander
====
I just like round cows better than square cows.

in makers.py I request to change
 def _set_custom_marker(self, path):
 verts = path.vertices
 rescale = max(np.max(np.abs(verts[:,0])), 
np.max(np.abs(verts[:,1])))
 self._transform = Affine2D().scale(1.0 / rescale)
 self._path = path
to
 def _set_custom_marker(self, path):
 verts = path.vertices
 rescale = np.max(np.sqrt(np.square(verts[:,0]) + 
np.square(verts[:,1])))
 self._transform = Affine2D().scale(1.0 / rescale)
 self._path = path
such that the symbol *radius* is normalized to 1.0
This way my previous example give better results if the symbol is rotated:
import matplotlib.path as path
from matplotlib.transforms import Affine2D
# define codes
P = path.Path
Pm = P.MOVETO
Pl = P.LINETO
Pc = P.CLOSEPOLY
c = [Pm] + [Pl]*3 + [Pc]
cx=c*2
# define basic path
r=np.array(((-1.,-1),(1.,-1),(1.,1.),(-1,1.),(-1,-1)))
# we add second closed path of half size but reverse parity
rh=0.5*r[::-1]
rx = np.vstack((r,rh))
p = path.Path(rx,codes=cx)
x = np.linspace(0,1,10)**2
plot(x,c='r',marker=p,ms=10)
pr = p.transformed(Affine2D().rotate_deg(45.))
plot(x,c='r',marker=pr,ms=10)
show()
I think this is how it is "meant" to be, but maybe you have to add a 
parameter to allow people recover the current behavior in that case.
-Alexander
====
I just like round cows better than square cows.

In [1]: matplotlib.__version__
Out[1]: '1.2.x'
~/matplotlib/lib/matplotlib>diff markers.py_broken markers.py
190c190
< path = Path(verts)
---
 > path = Path(self._marker)
PS - I tried to log into
https://github.com/matplotlib/matplotlib/issues
using my mailing list password to create a bug report, but it would not 
accept it, so you get it this way.
DOCUMENTATION NOTES
1) in the table for marker vertices it states
http://matplotlib.sourceforge.net/api/artist_api.html#matplotlib.lines.Line2D.set_marker
verts	a list of (x, y) pairs in range (0, 1)
it really should be just normalized or abs(1), (0,0) being center, and 
hence the (x,y) values should be in the range (-1,+1). Would be good to 
add an example
x=np.linspace(0,1,10)**2
plot(x,c='r',marker=((-1.,-1),(1.,-1),(1.,1.),(-1,1.),(-1,-1)),ms=10)
2) the source also support to just provide a path as a marker, which (a) 
is cool, and (b) seemed natural as internal many things are done a 
paths, and even complies paths are generated from the $...$ syntax math. 
 In any case, this should be added to the documentation for allowed markers
path	a matplotlib.path.Path object
import matplotlib.path as path
x = np.linspace(0,1,10)**2
p = path.Path(((-1.,-1),(1.,-1),(1.,1.),(-1,1.),(-1,-1)))
plot(x,c='r',marker=p,ms=10)
or a cool example that you may want tot add to the library...
import matplotlib.path as path
# define codes
P = path.Path
Pm = P.MOVETO
Pl = P.LINETO
Pc = P.CLOSEPOLY
c = [Pm] + [Pl]*3 + [Pc]
cx=c*2
# define basic path
r=np.array(((-1.,-1),(1.,-1),(1.,1.),(-1,1.),(-1,-1)))
# we add second closed path of half size but reverse parity
rh=0.5*r[::-1]
rx = np.vstack((r,rh))
p = path.Path(rx,codes=cx)
x = np.linspace(0,1,10)**2
plot(x,c='r',marker=p,ms=10)
PS - I guess I need to figure out how to do such updates w/o requesting 
action from the lest eventually.
Just to emphasize (2a): COOL!!!
Wishlist:
Can we add a "transform" parameter to overwrite self._transform?
I suppose this would have to go many places.
"set_marker_transform"
Maybe add to MarkerStyle
from transforms import Transform
def self.set_transform(self, transform = IdentityTransform()):
 assert isinstance(x, Transform)					
 self._transfrom = transfrom()
Maybe less fancy, and better for starters, to add an angle
"set_marker_rotation(angle)"
using
Affine2D().rotate_deg(angle)
-Alexander

On Sat, Dec 17, 2011 at 11:56 AM, John Hunter <jd...@gm...> wrote:
> Did you test? I did enable the same old fer_perez sf account you've always had. I was just referring to you by your email moniker in the post above. If it's still not working, I'll see if there is some other setting that needs tweaking.
OK, it worked now. I was using before an auto-generated password that
was OK for web login but had funny quote characters that were
confusing the svn login (probably being escaped by the shell). I
changed that to a more normal password, and now I was able to push.
Sorry for the confusion, and thanks!
Doing these updates should be easy and infrequent enough that I'm
happy to push them by hand when needed, just ping me.
Checked and the system mpl on ubuntu 11.10 can now fetch stinkbug correctly:
In [3]: matplotlib.__version__
Out[3]: '1.0.1'
In [4]: cbook.get_sample_data('stinkbug.png')
Out[4]: <open file
'/home/fperez/.matplotlib/sample_data/stinkbug.png', mode 'rb' at
0x2860b70>
Cheers,
f

> my SF username is fer_perez, by the time I joined fperez was taken on
> SF. If you have a chance of fixing this, I'll try to push again.
Did you test? I did enable the same old fer_perez sf account you've always had. I was just referring to you by your email moniker in the post above. If it's still not working, I'll see if there is some other setting that needs tweaking. 
> 

Hey John,
On Sat, Dec 17, 2011 at 5:23 AM, John Hunter <jd...@gm...> wrote:
> I've selectively enabled your (fperez) write access to the repo. Give
> it a try and let me know if you have any problems.
my SF username is fer_perez, by the time I joined fperez was taken on
SF. If you have a chance of fixing this, I'll try to push again.
Thanks!
f

On Fri, Dec 16, 2011 at 7:17 PM, Fernando Perez <fpe...@gm...> wrote:
> OK, thanks for trying. Next week we can see if John can reopen it for
> this. I think there's no danger of anyone mistakenly committing any
> real work there anymore.
I've selectively enabled your (fperez) write access to the repo. Give
it a try and let me know if you have any problems.
Thanks,
JDH

On Fri, Dec 16, 2011 at 5:11 PM, Eric Firing <ef...@ha...> wrote:
> Nope:
>
> efiring@manini:~/temp/sample_data_svn$ svn commit -m"Sync SVN repo with
> contents in current git repo"
> svn: Commit failed (details follow):
> svn: Server sent unexpected return value (403 Forbidden) in response to
> MKACTIVITY request for
> '/svnroot/matplotlib/!svn/act/9b074418-cd32-4039-88d8-06b46c4c8764'
>
> I think the repo was frozen when we moved to github.
OK, thanks for trying. Next week we can see if John can reopen it for
this. I think there's no danger of anyone mistakenly committing any
real work there anymore.
Cheers,
f

On 12/16/2011 02:12 PM, Fernando Perez wrote:
> wgethttp://fperez.org/tmp/sample_data_svn.tgz
> tar xzf sample_data_svn.tgz
> cd sample_data_svn
> svn commit -m"Sync SVN repo with contents in current git repo"
>
Nope:
efiring@manini:~/temp/sample_data_svn$ svn commit -m"Sync SVN repo with 
contents in current git repo"
svn: Commit failed (details follow):
svn: Server sent unexpected return value (403 Forbidden) in response to 
MKACTIVITY request for 
'/svnroot/matplotlib/!svn/act/9b074418-cd32-4039-88d8-06b46c4c8764'
I think the repo was frozen when we moved to github.
Eric

On Fri, Dec 16, 2011 at 3:39 PM, Fernando Perez <fpe...@gm...> wrote:
> Great, thanks. I'll see if I can push and will report back. If it
> doesn't work, we'll see if John can later restore write access to it.
Well, I can't seem to push. I don't know if it's my sourceforge
credentials, or if the repos are read-only, or what. In case anyone
else wants to give it a try, I tarred the svn directory and put it up
here:
http://fperez.org/tmp/sample_data_svn.tgz
I've already done the add steps, so all you should need to do is:
wget http://fperez.org/tmp/sample_data_svn.tgz
tar xzf sample_data_svn.tgz
cd sample_data_svn
svn commit -m"Sync SVN repo with contents in current git repo"
If one of you wants to try pasting the above four lines into a
terminal, let me know if it works for you.
Cheers,
f

On Fri, Dec 16, 2011 at 3:34 PM, Eric Firing <ef...@ha...> wrote:
> If you are willing and able to do it, please go ahead. I can't think of
> any problem it would create. (But I don't know whether the repo is
> writable.)
Great, thanks. I'll see if I can push and will report back. If it
doesn't work, we'll see if John can later restore write access to it.
Cheers,
f

On 12/16/2011 10:20 AM, Fernando Perez wrote:
> Hi all,
>
> I just added the stinkbug.png file to the sample_data repo so the
> Image tutorial and other examples using this image could be run by
> users making cbook.get_sample_data calls. But while it works fine
> with a reasonably recent MPL, I tested with the system one in Ubuntu
> 11.10, and it does not find the file. The reason is simply that this
> version of mpl still had the old SVN sample_data repo URL:
>
> baseurl = 'http://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/sample_data/'
>
> So the problem is that any users of 11.10 are now stuck with a 'frozen
> in time' sample_data repo.
>
> We can fix this easily by simply pushing over to sample_data an update
> with any new files in the github one. Since that repo changes fairly
> slowly and the changes typically involve just putting new files in and
> no actual code, it should be fairly easy to do manually.
>
> What do folks think? If you agree, I'm happy to push an update now
> (I'm assuming the SVN repo is still writable, which might not be the
> case...).
Fernando,
If you are willing and able to do it, please go ahead. I can't think of 
any problem it would create. (But I don't know whether the repo is 
writable.)
Eric
>
> Cheers,
>
> f
>

Hi all,
I just added the stinkbug.png file to the sample_data repo so the
Image tutorial and other examples using this image could be run by
users making cbook.get_sample_data calls. But while it works fine
with a reasonably recent MPL, I tested with the system one in Ubuntu
11.10, and it does not find the file. The reason is simply that this
version of mpl still had the old SVN sample_data repo URL:
baseurl = 'http://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/sample_data/'
So the problem is that any users of 11.10 are now stuck with a 'frozen
in time' sample_data repo.
We can fix this easily by simply pushing over to sample_data an update
with any new files in the github one. Since that repo changes fairly
slowly and the changes typically involve just putting new files in and
no actual code, it should be fairly easy to do manually.
What do folks think? If you agree, I'm happy to push an update now
(I'm assuming the SVN repo is still writable, which might not be the
case...).
Cheers,
f

On 12/15/2011 11:44 PM, Jason Grout wrote:
> On 12/15/11 8:03 PM, Michael Droettboom wrote:
>> On 12/07/2011 11:36 PM, Jason Grout wrote:
>>> On 12/7/11 10:27 PM, Chris Barker wrote:
>>>> On 12/5/11 9:49 PM, Jason Grout wrote:
>>>>> Has anyone ever worked on a backend that generates javascript code for
>>>>> one of the javascript plotters out there (like jsxgraph or flot)?
>>>>> Alternatively, I suppose we could generate an svg or html5 plot and then
>>>>> accompany it with the javascript code to trace the function, etc.
>>>> Someone has worked on a html5 back-end, It was jsut discussed a bit on
>>>> the thread "Using the Agg renderer by itself"
>>>>
>>>> Here's a cut and paste:
>>>>
>>>> On 11/27/11 12:33 PM, Ludwig Schwardt wrote:
>>>> >
>>>> > Ben is referring to mplh5canvas, available at
>>>> > http://code.google.com/p/mplh5canvas/. The main advantage of this
>>>> > approach is interactive zooming of plots within the browser. If this is
>>>> > not important to you, it will probably be faster to generate static PNGs
>>>> > or SVGs.
>>>> >
>>>> > The HTML5 backend should be easy to try out, as it is a pure Python
>>>> > package with no onerous dependencies.
>>>> >
>>> Michael Droettboom played with this a little at the Sage Days in March,
>>> IIRC, and I seem to think he also whipped up an interactive demo using
>>> svg plots. Michael, do you remember what your conclusions were?
>>>
>> My conclusion was basically that the current crop of browsers are plenty
>> fast and its generally feasible. But rewriting all that Python code in
>> Javascript ain't a small project ;)
> So maybe pyjamas or pyjs might help?
>
> http://pyjs.org/
>
> http://stackoverflow.com/questions/683462/best-way-to-integrate-python-and-javascript
> gives a few other python->javascript compilers. I don't know if any are
> currently active, though.
>
> I thought you also had some conclusion about using SVG instead of HTML5
> canvas...
>
Yes. In the case where you want to create a bunch of graphics objects 
that may be transformed (i.e. zoomed and panned) later, SVG is much more 
efficient. Canvas forces JavaScript to run through the entire drawing 
stack with each update, whereas SVG rendering allows a single object to 
be manipulated and only the parts of the drawing that change will be 
updated (and that all happens in the browser's renderer, not JavaScript 
so is therefore much faster).
Mike

On 12/15/11 8:03 PM, Michael Droettboom wrote:
> On 12/07/2011 11:36 PM, Jason Grout wrote:
>> On 12/7/11 10:27 PM, Chris Barker wrote:
>>> On 12/5/11 9:49 PM, Jason Grout wrote:
>>>> Has anyone ever worked on a backend that generates javascript code for
>>>> one of the javascript plotters out there (like jsxgraph or flot)?
>>>> Alternatively, I suppose we could generate an svg or html5 plot and then
>>>> accompany it with the javascript code to trace the function, etc.
>>> Someone has worked on a html5 back-end, It was jsut discussed a bit on
>>> the thread "Using the Agg renderer by itself"
>>>
>>> Here's a cut and paste:
>>>
>>> On 11/27/11 12:33 PM, Ludwig Schwardt wrote:
>>> >
>>> > Ben is referring to mplh5canvas, available at
>>> > http://code.google.com/p/mplh5canvas/. The main advantage of this
>>> > approach is interactive zooming of plots within the browser. If this is
>>> > not important to you, it will probably be faster to generate static PNGs
>>> > or SVGs.
>>> >
>>> > The HTML5 backend should be easy to try out, as it is a pure Python
>>> > package with no onerous dependencies.
>>> >
>> Michael Droettboom played with this a little at the Sage Days in March,
>> IIRC, and I seem to think he also whipped up an interactive demo using
>> svg plots. Michael, do you remember what your conclusions were?
>>
> My conclusion was basically that the current crop of browsers are plenty
> fast and its generally feasible. But rewriting all that Python code in
> Javascript ain't a small project ;)
So maybe pyjamas or pyjs might help?
http://pyjs.org/
http://stackoverflow.com/questions/683462/best-way-to-integrate-python-and-javascript 
gives a few other python->javascript compilers. I don't know if any are 
currently active, though.
I thought you also had some conclusion about using SVG instead of HTML5 
canvas...
Jason

On 12/07/2011 11:36 PM, Jason Grout wrote:
> On 12/7/11 10:27 PM, Chris Barker wrote:
>> On 12/5/11 9:49 PM, Jason Grout wrote:
>>> Has anyone ever worked on a backend that generates javascript code for
>>> one of the javascript plotters out there (like jsxgraph or flot)?
>>> Alternatively, I suppose we could generate an svg or html5 plot and then
>>> accompany it with the javascript code to trace the function, etc.
>> Someone has worked on a html5 back-end, It was jsut discussed a bit on
>> the thread "Using the Agg renderer by itself"
>>
>> Here's a cut and paste:
>>
>> On 11/27/11 12:33 PM, Ludwig Schwardt wrote:
>> >
>> > Ben is referring to mplh5canvas, available at
>> > http://code.google.com/p/mplh5canvas/. The main advantage of this
>> > approach is interactive zooming of plots within the browser. If this is
>> > not important to you, it will probably be faster to generate static PNGs
>> > or SVGs.
>> >
>> > The HTML5 backend should be easy to try out, as it is a pure Python
>> > package with no onerous dependencies.
>> >
> Michael Droettboom played with this a little at the Sage Days in March,
> IIRC, and I seem to think he also whipped up an interactive demo using
> svg plots. Michael, do you remember what your conclusions were?
>
My conclusion was basically that the current crop of browsers are plenty 
fast and its generally feasible. But rewriting all that Python code in 
Javascript ain't a small project ;)
Mike

On Wed, Dec 14, 2011 at 7:44 AM, Michael Droettboom <md...@st...> wrote:
> Thanks to the great work of Robert Johannson, we now have Gtk3 support
> using the GObject introspection Python bindings. To use, set your backend
> to "Gtk3Cairo" or "Gtk3Agg".
>
> It seems to be working well, but it would be great to get testing on a
> broader set of platforms etc.
>
> Unfortunately, the Gtk3Agg backend will not currently work under Python
> 3. For the gory details, see this:
>
> http://lists.cairographics.org/archives/cairo/2011-November/022519.html
>
> (On Fedora, you need to install the "pygobject3" package. Can someone
> report back the package name for the Debian/Ubuntu folks?)
>
>
I have not totally confirmed this yet, but it looks like there are two
packages: one for python2.x and one for py3k. They are python-gobject and
python3-gobject. It also appears that in Ubuntu, it is somewhat standard
to have a separate package containing introspection data. I don't know how
well that would apply to us.
I will update after doing some testing.
Ben Root

Thanks to the great work of Robert Johannson, we now have Gtk3 support 
using the GObject introspection Python bindings. To use, set your 
backend to "Gtk3Cairo" or "Gtk3Agg".
It seems to be working well, but it would be great to get testing on a 
broader set of platforms etc.
Unfortunately, the Gtk3Agg backend will not currently work under Python 
3. For the gory details, see this:
http://lists.cairographics.org/archives/cairo/2011-November/022519.html
(On Fedora, you need to install the "pygobject3" package. Can someone 
report back the package name for the Debian/Ubuntu folks?)
Mike

Hi all,
I'm getting an error (with current mpl master) illustrated by this code:
###
from cStringIO import StringIO
import matplotlib.pyplot as plt
import matplotlib.lines as lines
fig = plt.figure()
l1 = lines.Line2D([0, 1], [0, 1], transform=fig.transFigure, figure=fig)
l2 = lines.Line2D([0, 1], [1, 0], transform=fig.transFigure, figure=fig)
fig.lines.extend([l1, l2])
fig.canvas.draw()
sio = StringIO()
fig.canvas.print_figure(sio, format='png', bbox_inches='tight')
###
Is this a bug, or am I misusing print_figure?
I don't want to open a ticket if it's not a real bug, if it is one
I'll file it on gh.
Thanks,
f

On Sun, Dec 11, 2011 at 5:48 PM, Mike Kaufman <mc...@gm...> wrote:
> Attached. Also put the viewed pdf on the right side of the screen.
>
> M
>
>
> On 12/11/11 6:04 PM, Benjamin Root wrote:
>
>>
>>
>> On Sunday, December 11, 2011, Mike Kaufman <mc...@gm...
>> <mailto:mc...@gm...>> wrote:
>> >
>> > Both Skim 1.3.18 and Preview on OSX 10.6.8 show this. I'm using gv
>> 3.7.1 as a postscript viewer.
>> >
>> > M
>> >
>>
>> Could you send the PDF and a screen capture of what you see as a png so
>> we can check? The mac's Preview program was the one that I found to be
>> faulty.
>>
>> Ben Root
>>
>
>
Mike,
I have confirmed that the problem exists. I have also replicated the
problem on my own machine. Could you file a bug report for us, please?
Thanks,
Ben Root

On Sat, Dec 10, 2011 at 1:58 PM, cgraves <chr...@gm...> wrote:
>
> For the 3rd contour example at
> http://matplotlib.sourceforge.net/mpl_toolkits/mplot3d/tutorial.html , the
> code (
> http://matplotlib.sourceforge.net/mpl_examples/mplot3d/contour3d_demo3.py)
> should be changed from ax.set_xlim(-40, 40)
> to ax.set_xlim3d(-40, 40) for the code to work. Same for ylim and zlim.
> Probably the syntax was just updated since that example was made. Of course
> any other examples on that page which use xlim should also be fixed.
>
> Best,
> Chris
>
Chris,
Because the documentation is for v1.1.0, the example code is correct.
There has been significant updates to mplot3d for v1.1.0 that we really
want to move users away from previous versions (and particularly, away from
functions such as set_xlim3d()).
Thanks,
Ben Root

Attached. Also put the viewed pdf on the right side of the screen.
M
On 12/11/11 6:04 PM, Benjamin Root wrote:
>
>
> On Sunday, December 11, 2011, Mike Kaufman <mc...@gm...
> <mailto:mc...@gm...>> wrote:
> >
> > Both Skim 1.3.18 and Preview on OSX 10.6.8 show this. I'm using gv
> 3.7.1 as a postscript viewer.
> >
> > M
> >
>
> Could you send the PDF and a screen capture of what you see as a png so
> we can check? The mac's Preview program was the one that I found to be
> faulty.
>
> Ben Root