matplotlib-devel Mailing List for matplotlib

On Wednesday 31 October 2007 03:48:20 pm John Hunter wrote:
> On 10/31/07, Darren Dale <dar...@co...> wrote:
> > The STIX fonts issued their first beta release today.
>
> Darren, today is Halloween, not April Fools. We are not that gullible.
>
> :-)
They didn't include a copy of their license agreement in the zip file. I added 
a copy in license/ and fonts/otf/
Darren

On 10/31/07, Darren Dale <dar...@co...> wrote:
> The STIX fonts issued their first beta release today.
Darren, today is Halloween, not April Fools. We are not that gullible.
:-)

The STIX fonts issued their first beta release today. I added the fonts to 
mpl-data/fonts/otf.
Darren

On Wednesday 31 October 2007 12:07:12 pm Gael Varoquaux wrote:
> On Wed, Oct 31, 2007 at 11:49:24AM -0400, Darren Dale wrote:
> > > On Mon, Oct 29, 2007 at 12:05:25PM -1000, Eric Firing wrote:
> > >> When I go to the enthought web site, the most recent traits release I
> > >> see is 1.1, from August 2006. That doesn't make me optimistic about
> > >> traits as an external dependency any time soon.
> > >
> > > That's because the website is unmaintained. There have been two
> > > releases lately. One during scipy, and one mainly bug fix and small
> > > improvements, last week.
> > >
> > > This shows that enthought is really bad at communicating there work,
> > > something that I have come to realize, and that is a major prolblem.
> > >
> > > The software it self is pretty good, it just lacks packaging (I have
> > > more and more doubts about eggs), good release plans, and testing with
> > > different uses than enthought's.
> >
> > During the last Scipy conference, Fernando Perez and (I think) Dave
> > Peterson tracked down the source of a performance hit when we use our new
> > config package, which uses traits. They determined it was an issue with
> > setuptools. Do you know what is enthought's current thinking about using
> > setuptools?
>
> Their official thinking is to stick to it, and to improve it. But I have
> started release tarball that require setuptools only to build, but not at
> run-time. They are being used to package traits, traitsUI and mayavi2 in
> Debian. I would be happy to guive more info about that, but I am
> currently travelling, and my internet access is very poor.
>
> Beta versions of tarballs are on
> http://code.enthought.com/downloads/source . I will make cleaner tarballs
> of the release that was done last week when I get back home. These
> tarballscan be used for eg packaging, or integrating the dependency, as
> Fernando does in ipython.
This is just what we are looking for. Please let me know when the new tarballs 
are available.
Darren

On Mon, Oct 29, 2007 at 12:05:25PM -1000, Eric Firing wrote:
> When I go to the enthought web site, the most recent traits release I 
> see is 1.1, from August 2006. That doesn't make me optimistic about 
> traits as an external dependency any time soon.
That's because the website is unmaintained. There have been two releases
lately. One during scipy, and one mainly bug fix and small improvements,
last week.
This shows that enthought is really bad at communicating there work,
something that I have come to realize, and that is a major prolblem.
The software it self is pretty good, it just lacks packaging (I have more
and more doubts about eggs), good release plans, and testing with
different uses than enthought's.
Gael

On Wed, Oct 31, 2007 at 11:49:24AM -0400, Darren Dale wrote:
> > On Mon, Oct 29, 2007 at 12:05:25PM -1000, Eric Firing wrote:
> >> When I go to the enthought web site, the most recent traits release I
> >> see is 1.1, from August 2006. That doesn't make me optimistic about
> >> traits as an external dependency any time soon.
> > That's because the website is unmaintained. There have been two releases
> > lately. One during scipy, and one mainly bug fix and small improvements,
> > last week.
> > This shows that enthought is really bad at communicating there work,
> > something that I have come to realize, and that is a major prolblem.
> > The software it self is pretty good, it just lacks packaging (I have more
> > and more doubts about eggs), good release plans, and testing with
> > different uses than enthought's.
> During the last Scipy conference, Fernando Perez and (I think) Dave
> Peterson tracked down the source of a performance hit when we use our new
> config package, which uses traits. They determined it was an issue with
> setuptools. Do you know what is enthought's current thinking about using
> setuptools?
Their official thinking is to stick to it, and to improve it. But I have
started release tarball that require setuptools only to build, but not at
run-time. They are being used to package traits, traitsUI and mayavi2 in
Debian. I would be happy to guive more info about that, but I am
currently travelling, and my internet access is very poor.
Beta versions of tarballs are on 
http://code.enthought.com/downloads/source . I will make cleaner tarballs
of the release that was done last week when I get back home. These
tarballscan be used for eg packaging, or integrating the dependency, as
Fernando does in ipython.
Cheers,
Gael

On Monday 29 October 2007 03:29:17 pm Michael Droettboom wrote:
> As some of you probably know, I've been working on a fairly major
> refactoring of matplotlib. It's now getting to the point where I think
> more people may want to check it out and kick the tires. It is
> definitely not ready for real work -- I guarantee the first thing you
> try will break ;)
The first thing I tried was to enable the new config package and run 
backend_driver. I'm impressed, I saw only one error that doesnt occur in the 
trunk:
 driving mri_with_eeg.py
Traceback (most recent call last):
 File "_tmp_mri_with_eeg.py", line 13, in <module>
 from matplotlib.transforms import get_bbox_transform, Point, Value, Bbox,\
ImportError: cannot import name get_bbox_transform
backend_driver was a little slow to run on the transforms branch:
Backend Agg took 2.94 minutes to complete
 template ratio 1.527, template residual 1.015
Backend PS took 1.80 minutes to complete
 template ratio 0.933, template residual -0.129
Backend Template took 1.92 minutes to complete
 template ratio 1.000, template residual 0.000
Backend PDF took 2.17 minutes to complete
 template ratio 1.129, template residual 0.248
Backend SVG took 2.08 minutes to complete
 template ratio 1.082, template residual 0.158
as compared to the trunk:
Backend Agg took 1.53 minutes to complete
 template ratio 1.628, template residual 0.589
Backend PS took 1.34 minutes to complete
 template ratio 1.426, template residual 0.399
Backend Template took 0.94 minutes to complete
 template ratio 1.000, template residual 0.000
Backend PDF took 1.62 minutes to complete
 template ratio 1.726, template residual 0.680
Backend SVG took 1.45 minutes to complete
 template ratio 1.548, template residual 0.514
> However, it is passing the vast majority of examples in examples/ (with
> some major exceptions). The only working backends are Agg and all
> Agg-based GUIs, PS, PDF and SVG. Any 3D plotting has not even been
> attempted, and I'm certain is broken. There's a very good chance that
> external tools like basemap will not work at all. If you care about any
> of these missing things, you may not want to try the branch yet, or
> better yet, you may want to check out the branch and get those things
> working ;) Or, please let me know if the changes make any of those
> things much harder to do, so the design can be refined while we still
> have the chance ;)

On Tuesday 30 October 2007 09:33:53 pm Ralf Gommers wrote:
> Hi all,
>
> I just installed mpl on ubuntu gutsy, and got errors after setting
> text.usetex : True and ps.usedistiller : ghostscript. The problem seems
> to be in checkdep_ghostscript() in __init__.py, specifically the command
> 'gs -v' (should be replaced by 'gs --version').
> For my system I get:
> $ gs -v
> GPL Ghostscript SVN PRE-RELEASE 8.61 (2007年08月02日)
> Copyright (C) 2007 Artifex Software, Inc. All rights reserved.
>
> and:
> $ gs --version
> 8.61
>
> Below I give a modified version of checkdep_ghostscript() that should work
> for all version of ghostscript.
>
> Cheers,
> Ralf
>
>
>
> def checkdep_ghostscript():
> try:
> if sys.platform == 'win32':
> command = 'gswin32c -v'
> else:
> command = 'gs --version'
> stdin, stdout = os.popen4(command)
> line = stdout.readlines()[0]
> vtest = '.'.join(line.split('.')[:2]) # deal with version numbers like
> ' 7.07.1'
> float(vtest)
> return vtest
> except (IndexError, ValueError):
> return None
Thanks for the report. This was already fixed in svn, but not using --version, 
which looks like a better solution. Could someone using AFPL ghostscript let 
us know what is the output of gs --version?
Darren

Hi,
I've reworked the Tcl/Tk checking code in setupext.py (see attached
patch). It is now possible to build matplotlib with Tk support without
requiring a running X server. This is useful for doing autobuilds
(e.g. as done by Debian) and for building a package on one machine to
be installed and used on another.
This seems to be an old issue... (see matplotlib-devel, "building
matplotlib without X-server connection," 11 Nov 2004)
The patch also fixes a potential hang, which happens when I try to
build the latest matplotlib on Debian Etch with Python 2.4, on a
system with libtk8.4-dev installed but no running X server. The build
should have continued without TkAgg support, but it hangs. The hang
occurs because the Tcl/Tk checking code calls Tkinter.Tk() multiple
times, which is not a good idea. In fact, just running the following
snippet hangs the interpreter in this scenario:
import Tkinter
tk = Tkinter.Tk()
tk = Tkinter.Tk()
The patch applies to setupext.py in revision r3975. I checked it with
matplotlib r4064, using Python 2.4 on Debian Etch, and Python 2.5 on
Mac OS X 10.4.10. Could someone please check it with Python 2.3 and on
Windows?
Regards,
Ludwig

Hi all,
I just installed mpl on ubuntu gutsy, and got errors after setting
text.usetex : True and ps.usedistiller : ghostscript. The problem seems
to be in checkdep_ghostscript() in __init__.py, specifically the command 'gs
-v' (should be replaced by 'gs --version').
For my system I get:
$ gs -v
GPL Ghostscript SVN PRE-RELEASE 8.61 (2007年08月02日)
Copyright (C) 2007 Artifex Software, Inc. All rights reserved.
and:
$ gs --version
8.61
Below I give a modified version of checkdep_ghostscript() that should work
for all version of ghostscript.
Cheers,
Ralf
def checkdep_ghostscript():
 try:
 if sys.platform == 'win32':
 command = 'gswin32c -v'
 else:
 command = 'gs --version'
 stdin, stdout = os.popen4(command)
 line = stdout.readlines()[0]
 vtest = '.'.join(line.split('.')[:2]) # deal with version numbers like '
7.07.1'
 float(vtest)
 return vtest
 except (IndexError, ValueError):
 return None

On Tuesday 30 October 2007 11:07:32 am you wrote:
> On 10/29/07, Darren Dale <dar...@co...> wrote:
> > Maybe we can consider switching to the traited config package after the
> > potential merge. I have been running with it for quite a long time, and
>
> I think it would be a good time to do the switch. Michael's changes
> do not change much of the API, but there are a number of places where
> there will be changes, and so it is a good idea to get as many of
> these things in at once. I think a good way to proceed will be to
> treat this as a pre-pre 1.0 release (0.98?), with widely advertised
> changes, so people will expect some pain in the upgrade. The only
> other major thing I want to see overhauled before 1.0 is the axis
> treatment, so people can add an arbitrary number of x and y axis
> instances with different scaling and placement.
>
> I am also mostly in agreement with Eric that I am hesitant to rely on
> traits as an external dependency. When I first started testing traits
> this summer and did the install on my powerbook, the install was
> anything but painless. The team on the enthought-dev mailing lists
> was awesome in their support, but it took a lot of support for me to
> get everything working right, and I was at least 10 times more
> motivated, and probably more competent, than the typical user. When
> there is a single tarball or command that works on almost all
> platforms, and continues to do so for six months or so, I am amenable
> to making it an external dependency, which is the approach enthought
> prefers and which has its own advantages . Darren, how much work
> would it take to get traits 3.0 into our install pipline?
I think that part should be pretty easy. The hard part is writing the default 
config file during development and then updating it at build time depending 
on the available backends, etc. Solving that problem would be easy with an 
external traits, but with an internal package, I don't think we will have 
access to the machinery of tconfig until "setup.py install" has been run, is 
that correct? I'll come up with some kind of workaround.
> Proposed timeline:
>
> * get out a release of the current trunk, and make a branch for bug
> fix releases
>
> * merge Michael's branch into the trunk with emails to the lists and
> posts to the site that svn is bleeding edge, and this time we mean it,
> with instructions on how to use the oldline branch for people who need
> up to the minute bug fixes in the old branch
I think we should consider an mpl1 branch and a temporary dev mailing list for 
that branch, like they did with py3k. It would be less disruptive to the many 
users who already run svn-mpl. Then when people complain that mpl-0.98 is 
broken, we can tell them they asked for it :) 
> * bring enthought traits 3.0 into our build pipeline
>
> * turn on traited config, and deprecate the old config.
>
> * add traited properties for the artists.
At this point, we should start using the traited config object directly, and 
add deprecation warnings in the rcParams wrapper.
> * release 0.98 sometime early next year.
>
> We probably want to consult with the ipython folks to see what their
> plans are vis-a-vis traits and config to see if there is any
> duplication of effort we can avoid.
Darren

On 10/29/07, Darren Dale <dar...@co...> wrote:
> Maybe we can consider switching to the traited config package after the
> potential merge. I have been running with it for quite a long time, and
I think it would be a good time to do the switch. Michael's changes
do not change much of the API, but there are a number of places where
there will be changes, and so it is a good idea to get as many of
these things in at once. I think a good way to proceed will be to
treat this as a pre-pre 1.0 release (0.98?), with widely advertised
changes, so people will expect some pain in the upgrade. The only
other major thing I want to see overhauled before 1.0 is the axis
treatment, so people can add an arbitrary number of x and y axis
instances with different scaling and placement.
I am also mostly in agreement with Eric that I am hesitant to rely on
traits as an external dependency. When I first started testing traits
this summer and did the install on my powerbook, the install was
anything but painless. The team on the enthought-dev mailing lists
was awesome in their support, but it took a lot of support for me to
get everything working right, and I was at least 10 times more
motivated, and probably more competent, than the typical user. When
there is a single tarball or command that works on almost all
platforms, and continues to do so for six months or so, I am amenable
to making it an external dependency, which is the approach enthought
prefers and which has its own advantages . Darren, how much work
would it take to get traits 3.0 into our install pipline?
Proposed timeline:
 * get out a release of the current trunk, and make a branch for bug
fix releases
 * merge Michael's branch into the trunk with emails to the lists and
posts to the site that svn is bleeding edge, and this time we mean it,
with instructions on how to use the oldline branch for people who need
up to the minute bug fixes in the old branch
 * bring enthought traits 3.0 into our build pipeline
 * turn on traited config, and deprecate the old config.
 * add traited properties for the artists.
 * release 0.98 sometime early next year.
We probably want to consult with the ipython folks to see what their
plans are vis-a-vis traits and config to see if there is any
duplication of effort we can avoid.

Just to clarify: the OFFICIAL definition of an inch is 2.54 cm.
So rounding errors shouldn't be much of a problem.
> Date: 2007年10月29日 09:37:06 -0400
> From: Michael Droettboom <md...@st...>
>
> I agree that we have to remain in inches internally. Non-metric units
> are pretty ingrained in the printing world (not just in matplotlib) --
> Postscript, for example, always does page sizes in inches, even if
> you're using a "metric" page size like A4. The current definition of a
> point as 1/72 of a modern inch is also fairly standard worldwide. Even
> printers in France, for example, are spec'd in points par pouce (ppp),
> which is exactly equivalent to dots per inch (dpi).
>
> However, that's just an implementation detail we have to stick with.
> Matplotlib has Figure.get/set_size_inches now. What's to stop us from
> adding get/set_size_cm, and doing the conversion right there? There
> might be some rounding error, but I don't think it matters in this
> particular case. We would probably also want to add a "figsize_cm"
> kwarg to the Figure constructor (which would be mutually exclusive to
> "figsize"). What do you think?
>
> Cheers,
> Mike
>
>

Darren Dale wrote:
> 
> Maybe we can consider switching to the traited config package after the 
> potential merge. I have been running with it for quite a long time, and 
> haven't had any issues. Now that traits can be installed without any 
> additional dependencies, and enthought has been working on playing well with 
> debs and rpms, we could consider making traits an external dependency. I 
> think it should be external, because that will make it easier to generate 
> default config files at compile time. We could also benefit from a 
> reorganization of the src directory tree, one that would not touch the actual 
> api. I think I will have some free evenings and weekends for these projects 
> starting Dec 4.
Darren,
When I go to the enthought web site, the most recent traits release I 
see is 1.1, from August 2006. That doesn't make me optimistic about 
traits as an external dependency any time soon.
Eric

On Monday 29 October 2007 03:29:17 pm Michael Droettboom wrote:
> As some of you probably know, I've been working on a fairly major
> refactoring of matplotlib. It's now getting to the point where I think
> more people may want to check it out and kick the tires. It is
> definitely not ready for real work -- I guarantee the first thing you
> try will break ;)
>
> However, it is passing the vast majority of examples in examples/ (with
> some major exceptions). The only working backends are Agg and all
> Agg-based GUIs, PS, PDF and SVG. Any 3D plotting has not even been
> attempted, and I'm certain is broken. There's a very good chance that
> external tools like basemap will not work at all. If you care about any
> of these missing things, you may not want to try the branch yet, or
> better yet, you may want to check out the branch and get those things
> working ;) Or, please let me know if the changes make any of those
> things much harder to do, so the design can be refined while we still
> have the chance ;)
>
> There are more details about the changes in CHANGELOG and API_CHANGES.
> PASSED_DEMOS contains my own notes about what is currently working.
>
> The SVN URL is:
>
>
> https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/transfor
>ms
I'm looking forward to trying it out.
Maybe we can consider switching to the traited config package after the 
potential merge. I have been running with it for quite a long time, and 
haven't had any issues. Now that traits can be installed without any 
additional dependencies, and enthought has been working on playing well with 
debs and rpms, we could consider making traits an external dependency. I 
think it should be external, because that will make it easier to generate 
default config files at compile time. We could also benefit from a 
reorganization of the src directory tree, one that would not touch the actual 
api. I think I will have some free evenings and weekends for these projects 
starting Dec 4.
Darren

John Hunter wrote:
> After that, are you getting close Michael to merging your branch into
> the trunk?
I think our lines crossed -- I just sent an e-mail about this.
This is probably implied, but I think it would be a good idea to keep a 
maintenance branch around based on the upcoming release -- it may be 
helpful to be able to make quick and easy bugfixes against the release 
without worrying about all the new bugs my branch has introduced ;)
I've been merging trunk into my branch almost daily since I started, so 
the merge back into the trunk should be reasonably painless.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

As some of you probably know, I've been working on a fairly major
refactoring of matplotlib. It's now getting to the point where I think
more people may want to check it out and kick the tires. It is
definitely not ready for real work -- I guarantee the first thing you
try will break ;)
However, it is passing the vast majority of examples in examples/ (with
some major exceptions). The only working backends are Agg and all
Agg-based GUIs, PS, PDF and SVG. Any 3D plotting has not even been
attempted, and I'm certain is broken. There's a very good chance that
external tools like basemap will not work at all. If you care about any
of these missing things, you may not want to try the branch yet, or
better yet, you may want to check out the branch and get those things
working ;) Or, please let me know if the changes make any of those
things much harder to do, so the design can be refined while we still
have the chance ;)
There are more details about the changes in CHANGELOG and API_CHANGES.
PASSED_DEMOS contains my own notes about what is currently working.
The SVN URL is:
 
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/transforms
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On 10/29/07, Michael Droettboom <md...@st...> wrote:
> I've also run backend_driver.py through a code coverage tool
> (coverage.py) and identified a few large parts of the code that weren't
> covered. I added a dozen or so existing examples to backend_driver, and
> now though there are lots of little places that never get run (mainly
> error cases and such), the code coverage of backend_driver is quite
> good. The only high-level method in axes.py that isn't being tested is
> cohere(). Does anyone have a test for it that could be added?
Once we get these bugs cleared up, and the tkagg segfault I mentioned
earlier, it is probably a good time to prepare for a new release.
There have been lots of major enhancements in the trunk since 0.90.1,
most importantly the new mathtext. I encourage everyone to visit the
bugs and patches page and let's knock out as many as we can and get
any new features from developers trees in, and shoot for a release
next week.
After that, are you getting close Michael to merging your branch into
the trunk?
JDH

On 10/29/07, Michael Droettboom <md...@st...> wrote:
> I've been relying very heavily on the examples lately to test my
> refactored branch of matplotlib. In doing so, I've discovered a few
> that are currently broken in matplotlib's trunk. I'm reporting these
> just to bring them to the attention of the list, not because they are
> priority bugs for me. Some of these may simply be old and should be
> removed. Let me know if you need any more information for them.
> I've also run backend_driver.py through a code coverage tool
> (coverage.py) and identified a few large parts of the code that weren't
> covered. I added a dozen or so existing examples to backend_driver, and
> now though there are lots of little places that never get run (mainly
> error cases and such), the code coverage of backend_driver is quite
> good. The only high-level method in axes.py that isn't being tested is
> cohere(). Does anyone have a test for it that could be added?
This is great -- our backend _driver is a poor man's unit test, but it
has served us well and it's good to make the most of it. I've added a
cohere_demo.py and added it to backend_driver.
> > python agg_resize.py
> Traceback (most recent call last):
> File "agg_resize.py", line 7, in <module>
> interp = agg.span_interpolator_linear(imMatrix);
> AttributeError: 'module' object has no attribute 'span_interpolator_linear'
Hmm, for some reason the following lines are commented out of swig.agg.i
//%include "agg_span_interpolator_linear.h"
//%template(span_interpolator_linear_affine)
agg::span_interpolator_linear<agg::trans_affine>;
//%include "agg_span_image_filter.i"
I think I am the only one who has worked on this part of the code, so
I must have done it but don't know why. This is a low priority bug
since we are not using the low level agg renderer for much (it was
written to try and decrease reliance and ultimately drop the CXX) but
the endeavor has languished. I'll need to spend some time to figure
out why this is commented out and if it can be restored.
> > python embedding_in_wx2.py
> [The y-axis labels are being cut off at the bottom of the figure.]
This is a pretty low priority since I am already somewhat inclined to
drop pure wx rendering.
> > python image_slices_viewer.py
> [It says the "use the scroll wheen to navigate images" [sic], but the
> scroll wheel doesn't appear to do anything in TkAgg on Linux.]
This works in gtkagg -- some tk users/developer/advocate needs to add
support for the 'scroll_event'. I consider this to be fairly high
priority and an easy fix.
> > python keypress_demo.py
> [Pressing "g" to toggle the grid causes the grid to flash momentarily
> and then disappear again.]
Fixed - this was written a long time ago before toggling the grid with
'g' was made the default. So this example simply toggled it on and
off since two event handlers were being triggered. I rewrote it to to
toggle the xlabel
> > python bar_unit_demo.py
> Traceback (most recent call last):
> File "bar_unit_demo.py", line 14, in <module>
> p1 = ax.bar(ind, menMeans, width, color='r', bottom=0*cm, yerr=menStd)
> File
> "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", line
> 3307, in bar
> fmt=None, ecolor=ecolor, capsize=capsize)
> File
> "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", line
> 3727, in errorbar
> lower = y-yerr
> TypeError: unsupported operand type(s) for -: 'int' and 'TaggedValue'
fixed in svn
> > python ellipse_with_units.py
> Traceback (most recent call last):
> File "ellipse_with_units.py", line 36, in <module>
> ax.add_patch(e1)
> File
> "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", line
> 1143, in add_patch
> self._update_patch_limits(p)
> File
> "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", line
> 1150, in _update_patch_limits
> p.get_transform(), p.get_verts())
> File
> "/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/patches.py",
> line 814, in get_verts
> x = width/2. * npy.cos(theta)
> TypeError: unsupported operand type(s) for /: 'TaggedValue' and 'float'
fixed in svn
JDH

I've been relying very heavily on the examples lately to test my 
refactored branch of matplotlib. In doing so, I've discovered a few 
that are currently broken in matplotlib's trunk. I'm reporting these 
just to bring them to the attention of the list, not because they are 
priority bugs for me. Some of these may simply be old and should be 
removed. Let me know if you need any more information for them.
I've also run backend_driver.py through a code coverage tool 
(coverage.py) and identified a few large parts of the code that weren't 
covered. I added a dozen or so existing examples to backend_driver, and 
now though there are lots of little places that never get run (mainly 
error cases and such), the code coverage of backend_driver is quite 
good. The only high-level method in axes.py that isn't being tested is 
cohere(). Does anyone have a test for it that could be added?
Errors follow.
Cheers,
Mike
 > python agg_resize.py
Traceback (most recent call last):
 File "agg_resize.py", line 7, in <module>
 interp = agg.span_interpolator_linear(imMatrix);
AttributeError: 'module' object has no attribute 'span_interpolator_linear'
 > python embedding_in_wx2.py
[The y-axis labels are being cut off at the bottom of the figure.]
 > python image_slices_viewer.py
[It says the "use the scroll wheen to navigate images" [sic], but the 
scroll wheel doesn't appear to do anything in TkAgg on Linux.]
 > python keypress_demo.py
[Pressing "g" to toggle the grid causes the grid to flash momentarily 
and then disappear again.]
 > python bar_unit_demo.py
Traceback (most recent call last):
 File "bar_unit_demo.py", line 14, in <module>
 p1 = ax.bar(ind, menMeans, width, color='r', bottom=0*cm, yerr=menStd)
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 
3307, in bar
 fmt=None, ecolor=ecolor, capsize=capsize)
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 
3727, in errorbar
 lower = y-yerr
TypeError: unsupported operand type(s) for -: 'int' and 'TaggedValue'
 > python ellipse_with_units.py
Traceback (most recent call last):
 File "ellipse_with_units.py", line 36, in <module>
 ax.add_patch(e1)
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 
1143, in add_patch
 self._update_patch_limits(p)
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/axes.py", line 
1150, in _update_patch_limits
 p.get_transform(), p.get_verts())
 File 
"/home/mdroe/usr/lib/python2.5/site-packages/matplotlib/patches.py", 
line 814, in get_verts
 x = width/2. * npy.cos(theta)
TypeError: unsupported operand type(s) for /: 'TaggedValue' and 'float'
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Eric Firing wrote:
> Somewhere along the line, it may make sense to support the metric system 
> better in mpl.
It seems to me that the "right" way to do this is to use some sort of 
"array-with_units" class. Then what MPL would except was a "length", and 
the user would specify what they want. i.e:
figure(figsize = units.inches((8.5,11))
rather than:
figure(figsize = (8.5, 11), units=inches)
Though this does make for more typing. With the later way, a system 
default for units could be used more easily.
I really want a unit class like this for other stuff anyway.
-- just thinking in email....
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

I agree that we have to remain in inches internally. Non-metric units 
are pretty ingrained in the printing world (not just in matplotlib) -- 
Postscript, for example, always does page sizes in inches, even if 
you're using a "metric" page size like A4. The current definition of a 
point as 1/72 of a modern inch is also fairly standard worldwide. Even 
printers in France, for example, are spec'd in points par pouce (ppp), 
which is exactly equivalent to dots per inch (dpi).
However, that's just an implementation detail we have to stick with. 
Matplotlib has Figure.get/set_size_inches now. What's to stop us from 
adding get/set_size_cm, and doing the conversion right there? There 
might be some rounding error, but I don't think it matters in this 
particular case. We would probably also want to add a "figsize_cm" 
kwarg to the Figure constructor (which would be mutually exclusive to 
"figsize"). What do you think?
Cheers,
Mike
Eric Firing wrote:
> Coincidentally, I was just thinking about this a couple days ago, when 
> reviewing the units kwarg of the colorbar. I decided then that adding a 
> cm option just wasn't worth even the small amount of extra code; inches 
> are fairly deeply embedded, as witness the standard "dpi" way of 
> specifying pixel size on output devices.
> 
> I do understand the rationale; many of us in the US would have preferred 
> if the US had continued with the transition to metric units instead of 
> backing off. For mpl right now, however, I don't think it is worthwhile 
> to add the extra complexity, no matter how small it may seem, of a 
> general cm option, or a great number of docstring additions saying 
> "There are 2.54 cm per inch."
> 
> Somewhere along the line, it may make sense to support the metric system 
> better in mpl.
> 
> Eric
> 
> Olivier Verdier wrote:
>> Hi!
>>
>>
>> I really enjoy using matplotlib but something is strange with the units 
>> used for the figure size. It seems that it must be in inches? (I'm 
>> thinking of the figure.figsize value in matplotlibrc, for instance).
>>
>>
>> Of course if one knows how long an inch is (apparently 2.5 cm) it's not 
>> difficult to convert a value in mm or cm to inches but most people 
>> around here (Europe) have never used inches in their life.
>>
>>
>> I believe that centimetres (or millimetres) should be the default unit 
>> for all lengths because it is familiar to everybody... as far as I know.
>>
>>
>> Then you might also allow the customary local units of various 
>> countries. If you really want to only use inches then i think that you 
>> should specify that an inch corresponds to 2.5 cm wherever a value in 
>> inches is needed. Most users of matplotlib have no clue as to how long 
>> an inch is.
>>
>>
>> I'd be willing to help on that matter if you all agree that such a 
>> change would be a good idea.
>>
>>
>> Thanks!!
>>
>>
>> == Olivier
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Coincidentally, I was just thinking about this a couple days ago, when 
reviewing the units kwarg of the colorbar. I decided then that adding a 
cm option just wasn't worth even the small amount of extra code; inches 
are fairly deeply embedded, as witness the standard "dpi" way of 
specifying pixel size on output devices.
I do understand the rationale; many of us in the US would have preferred 
if the US had continued with the transition to metric units instead of 
backing off. For mpl right now, however, I don't think it is worthwhile 
to add the extra complexity, no matter how small it may seem, of a 
general cm option, or a great number of docstring additions saying 
"There are 2.54 cm per inch."
Somewhere along the line, it may make sense to support the metric system 
better in mpl.
Eric
Olivier Verdier wrote:
> Hi!
> 
> 
> I really enjoy using matplotlib but something is strange with the units 
> used for the figure size. It seems that it must be in inches? (I'm 
> thinking of the figure.figsize value in matplotlibrc, for instance).
> 
> 
> Of course if one knows how long an inch is (apparently 2.5 cm) it's not 
> difficult to convert a value in mm or cm to inches but most people 
> around here (Europe) have never used inches in their life.
> 
> 
> I believe that centimetres (or millimetres) should be the default unit 
> for all lengths because it is familiar to everybody... as far as I know.
> 
> 
> Then you might also allow the customary local units of various 
> countries. If you really want to only use inches then i think that you 
> should specify that an inch corresponds to 2.5 cm wherever a value in 
> inches is needed. Most users of matplotlib have no clue as to how long 
> an inch is.
> 
> 
> I'd be willing to help on that matter if you all agree that such a 
> change would be a good idea.
> 
> 
> Thanks!!
> 
> 
> == Olivier
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi!
I really enjoy using matplotlib but something is strange with the units used
for the figure size. It seems that it must be in inches? (I'm thinking of
the figure.figsize value in matplotlibrc, for instance).
Of course if one knows how long an inch is (apparently 2.5 cm) it's not
difficult to convert a value in mm or cm to inches but most people around
here (Europe) have never used inches in their life.
I believe that centimetres (or millimetres) should be the default unit for
all lengths because it is familiar to everybody... as far as I know.
Then you might also allow the customary local units of various countries. If
you really want to only use inches then i think that you should specify that
an inch corresponds to 2.5 cm wherever a value in inches is needed. Most
users of matplotlib have no clue as to how long an inch is.
I'd be willing to help on that matter if you all agree that such a change
would be a good idea.
Thanks!!
== Olivier

Darren Dale wrote:
> On Friday 19 October 2007 10:55:24 am John Hunter wrote:
>> On 10/19/07, Darren Dale <dar...@co...> wrote:
>>> I removed a gsave/grestore pair surrounding RendererPS._draw_ps in
>>> svn-3967. It looks like this fixed the problem (graphics state was being
>>> lost). I checked contour_demo.py for any unintended side-effects, and
>>> didn't find any, but please keep an eye out for strange behavior.
>> I added this gsave/grestore pair in draw_ps because in a first attempt
>> to get Ellipse working properly with axis='auto'. I was using an
>> approach inspired by Michael's branch, which is to create a unit
>> circle and then apply rotation and scaing transformation to make the
>> ellipse. The transformation settings were persistent so I wrapped all
>> of the draw_ps in a save/restore block to insulate them.
>>
>> Then I realized that doing the transformation in PS wreaks all kinds
>> of havoc with the linewidth settings, and reverted the code to doing
>> the transformations in python, as we have always done. So removing
>> the save/restore block should be fine, but file it away in the back of
>> your mind that pushing transformations in the current implementation
>> may result in unintended weirdness.
The gsave/grestore can always be placed only around the transform and 
the fill/stroke itself, not around the graphics context changes. That's 
what I have done for the clip paths on the branch, and what the clipping 
rectangle already does on the trunk.
> Thanks for letting me know. When we first implemented draw_markers in 
> backend_ps, we let the postscript interpretter do the transforms. That turned 
> out to be a disaster. It took forever for ghostscript to render the images, 
> so we went back to doing transforms in mpl.
For both of these reasons, I also bailed on doing the transformations in 
the Postscript (and PDF, SVG and probably Cairo) on my branch as well. 
I'm leaving the backend interface as-is (where the outline and the 
transform are both passed to the backend), because that approach is 
slightly faster with the Agg backend, mainly because it doesn't have to 
make a transformed copy of all of the points before rendering. But that 
does mean the output of the non-interactive backends will benefit less 
from all this refactoring than originally thought. However, it should 
be helpful in the long run to have fewer backend methods to write and 
maintain.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA