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 work
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
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 -
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,
On 10/29/07, Michael Droettboom <[EMAIL PROTECTED]> 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
On 10/29/07, Michael Droettboom <[EMAIL PROTECTED]> 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 a
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.
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.
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
