matplotlib-devel Mailing List for matplotlib (Page 3)

On second look, I think it's the "--small" commandline option that 
breaks this. I hadn't tested my recent changes to the plot directive 
with that flag. The new version of make.py in SVN r7815 should fix this.
Mike
Sandro Tosi wrote:
> Hi all,
> I'm a bit unsure if this is really a problem in the code or it's my
> machine that has problem (I didn't manage to test it in a clean
> chroot).
>
> When building the doc (after having built mpl with python setup.py
> build) I got the attached traceback.
>
> The strange fact is that 'formats' is indeed defined as a 2D list (At
> the bottom of plot_directive.py).
>
> Thanks for considering,
> 
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

It's also an overridable parameter in conf.py. Of course, it works with 
the conf.py in SVN, but do you perhaps have any local changes to it?
Mike
Sandro Tosi wrote:
> Hi all,
> I'm a bit unsure if this is really a problem in the code or it's my
> machine that has problem (I didn't manage to test it in a clean
> chroot).
>
> When building the doc (after having built mpl with python setup.py
> build) I got the attached traceback.
>
> The strange fact is that 'formats' is indeed defined as a 2D list (At
> the bottom of plot_directive.py).
>
> Thanks for considering,
> 
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

Thanks Fernando for the quick response.
Today this is the 3rd time I am hitting an unsupported feature in the Python
lands.
1-) No attribute docstrings
2-) Look this question:
http://stackoverflow.com/questions/1458203/reading-a-float-from-string
and 3rd is this.
However I think I influenced to guys in our campus to take a look Python.
One using Matlab-Simulink and C on collision-detection system design, the
latter uses C to design a small scale embedded acquisition system for UAV
platforms. He uses an ARM Cortex A8 processor powered Gumstix
board<http://www.gumstix.com/store/catalog/product_info.php?cPath=31&products_id=228>.
Xubuntu 9.04 runs on it. I saw Python 2.6.2 installed, however not sure how
easy would that be to bring rest of the scipy stack into that machine.
Besides, tomorrow there is going to be a Matlab seminar here
http://www.mathworks.com/company/events/seminars/seminar39323.html
It is about a SciPy advanced tutorial long.
Many similar subjects I see there:
*Speeding Up MATLAB Applications:Tips and Tricks for Writing Efficient Code
*Topics include:
• Understanding preallocation and vectorization
• Addressing bottlenecks
• Efficient indexing and manipulations
• JIT
• Interpreter
• Mex
*Brief Introduction to Parallel Computing with MATLAB
*• Task parallel applications for faster processing
• Data parallel applications for handling large data sets
• Scheduling your programs to run
I hope I will not kick out from the session by keep commenting oh that is
possible in Python, oh this is too :)
On Tue, Sep 22, 2009 at 12:18 AM, Fernando Perez <fpe...@gm...>wrote:
> 2009年9月21日 Gökhan Sever <gok...@gm...>:
> >
> > It's a very late reply but I am wondering how to make these appear in the
> Ipy dev loaded into the session but not visible to a whos listing?
> >
>
> I don't think that's supported quite right now. IPython does one
> special thing to support a clean %whos listing: right before opening
> up the user mainloop, it checks all keys in the user namespace, and
> later on when %whos is run, those variables that were initially
> present are not displayed. So for now if you do this interactively,
> you will unfortunately pollute %whos.
>
> This is one thing we'll need to make sure works nicely again when the
> dust settles.
>
> Cheers,
>
> f
>
-- 
Gökhan

Hi all,
I'm a bit unsure if this is really a problem in the code or it's my
machine that has problem (I didn't manage to test it in a clean
chroot).
When building the doc (after having built mpl with python setup.py
build) I got the attached traceback.
The strange fact is that 'formats' is indeed defined as a 2D list (At
the bottom of plot_directive.py).
Thanks for considering,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

2009年9月21日 Gökhan Sever <gok...@gm...>:
>
> It's a very late reply but I am wondering how to make these appear in the Ipy dev loaded into the session but not visible to a whos listing?
>
I don't think that's supported quite right now. IPython does one
special thing to support a clean %whos listing: right before opening
up the user mainloop, it checks all keys in the user namespace, and
later on when %whos is run, those variables that were initially
present are not displayed. So for now if you do this interactively,
you will unfortunately pollute %whos.
This is one thing we'll need to make sure works nicely again when the
dust settles.
Cheers,
f

On Tue, Sep 8, 2009 at 3:45 PM, Fernando Perez <fpe...@gm...> wrote:
> Hey Gokhan,
>
> thanks for the summary.
>
> On Tue, Sep 8, 2009 at 12:45 PM, Gökhan Sever <gok...@gm...>
> wrote:
> > ### In a new IPython, these lines work --no locking after plt.show() "-a"
> > makes the difference.
> >
> > I[1]: import matplotlib.pyplot as plt
> >
> > I[2]: %gui -a qt
> > O[2]: <PyQt4.QtGui.QApplication object at 0x8fdceac>
> >
> > I[3]: plt.plot(range(10))
> > O[3]: [<matplotlib.lines.Line2D object at 0x9a2c84c>]
> >
> > I[4]: plt.show()
>
> If you do
>
> plt.ion()
>
> right after you import it, then you don't need to do 'show'
> explicitely anymore. Basically what today's '-pylab' does is:
>
> - a bunch of imports
> - the equivalent of %gui, but uglier and at startup
> - do plt.ion() for you
> - patch %run a little so it does ioff() before starting up and ion() at the
> end.
>
> As you can see, even now with trunk in the state of upheaval it is,
> you can get almost all of this back with this snippet. This is pretty
> much what we'll make available built-in when the dust settles (with
> the 'import *' being optional, as they are today):
>
>
It's a very late reply but I am wondering how to make these appear in the
Ipy dev loaded into the session but not visible to a whos listing?
Thanks.
> %gui -a qt
>
> import numpy as np
> import matplotlib.pyplot as plt
> import matplotlib.pylab as pylab
> import matplotlib.mlab as mlab
>
> from numpy import *
> from matplotlib.pyplot import *
>
> plt.ion()
>
>
> ### END CODE
>
> Cheers,
>
> f
>
-- 
Gökhan

On Mon, Sep 21, 2009 at 7:04 AM, Michael Droettboom <md...@st...> wrote:
> It's caused by the files having multiple locations (relative to the root of
> the source tree) in different branches, or existing in some branches but not
> in others. In other words, files that have been moved, deleted or added
> since branch creation. I think if we retire old branches (0.91, 0.98),
> which I'm in favor of, we might alleviate some of that (I'm not 100% sure,
> but it seems plausible).
>
I think it is safe to delete these branches
JDH

The relevant bugs on the tracker have been addressed and I just did a
round of testing on the release branch and it looks like we are good
to go for 0.99.1. Unless something critical comes up in the next 24
hours, I'm tagging r7813 on the release branch for 0.99.1 and will
build the OS X binaries tonight. Christoph, unless you hear otherwise
in the interim, if you could build the win32 binaries from this
revision, I'll shoot for a release and announcement tomorrow.
Thanks,
JDH

Wow - thanks for the detailed update. I feel bad for making you type that much :)
Thanks for fixing that problem. 
Ted
> -----Original Message-----
> From: John Hunter [mailto:jd...@gm...]
> Sent: Sunday, September 20, 2009 7:35 PM
> To: Drain, Theodore R (343P)
> Cc: Andrew Straw; matplotlib development list
> Subject: Re: [matplotlib-devel] empty date formatter unit tests
> 
> On Sun, Sep 20, 2009 at 6:50 PM, Drain, Theodore R (343P)
> <the...@jp...> wrote:
> 
> > I've run into this problem quite a few times and I'd love to figure
> out some way to fix it. As an example, here's the kind of scenario
> this occurs in:
> >
> > I embed MPL in a few different GUI's that plot data either in real-
> time or via the user selecting things. There is a saved state which
> contains preferences like auto-scaling, legend on/off, axis formatting,
> etc. When the app starts up, I need to create a plot to put on the
> screen and configure it. What I'd like to do is this:
> >
> > - create widget
> > - apply format (date formatter, etc)
> > - apply settings (autoscale, etc)
> > - wait for data (either via real time feed or user clicking on
> things)
> >
> > But this is impossible because of this kind of bug. Instead, I have
> to create a plot with a fake date range and test every operation to see
> if it's actually setting data before applying the settings like
> autoscale. In addition, if the user removes data from the plot (via
> menu or selectable lists), I have to either start over or "unset" the
> settings back to something safe so this error won't occur. It really
> makes coding something like this a royal pain.
> >
> > I don't have a suggestion as of yet... Perhaps it could just return
> "N/A" or something like that.
> >
> > I think part of the problem might be the default ranges used by the
> autoscaling algorithm when there is no data are invalid for certain
> formatters and locators. That suggests that possible solutions might be
> one of:
> >
> > 1) require autoscaling or scaling algorithms to return ranges that
> will be OK for known scalers/formatters. Perhaps some system that
> allows different autoscaling algorithms to be set which can configure
> the default?
> > 2) require scalers/formatters to be robust for any range or engineer
> the system to allow them to report "errors" in a way that allows the
> plot do something reasonable and not trigger an exception (perhaps some
> changeable behavior w/ the default as an exception?).
> >
> > I'll think about this a little this week and see if any other ideas
> come to mind.
> 
> I think we have this problem mostly licked. The problem I was writing
> about in my email is a 2nd tier problem. For example, in svn HEAD,
> you can specify an "empty" date plot as long as you inform mpl of you
> intentions.. From the test_date_empty unit test::
> 
> fig = plt.figure()
> ax = fig.add_subplot(1,1,1)
> ax.xaxis_date()
> fig.savefig('date_empty')
> 
> Here we are fine, because we call ax.axaxis_date, which informs mpl
> that you intend to pass in datetime instances. The key piece which
> makes this possible, which you allude to in your post, is the default
> xlimits, which is new in svn HEAD. In particular, the default
> converter provides an AxisInfo which now supports an optional
> attribute
> 
> default_limits: the default min, max of the axis if no data is
> present
> 
> which is overridden in the DateConverter:
> 
> def axisinfo(unit, axis):
> 'return the unit AxisInfo'
> # make sure that the axis does not start at 0
> 
> majloc = AutoDateLocator(tz=unit)
> majfmt = AutoDateFormatter(majloc, tz=unit)
> datemin = datetime.date(2000, 1, 1)
> datemax = datetime.date(2010, 1, 1)
> 
> return units.AxisInfo( majloc=majloc, majfmt=majfmt, label='',
> default_limits=(datemin, datemax))
> 
> 
> while the min/max are arbitrary, the important thing is that custom
> types can now handle the default min/max limits, so when you present a
> new type to mpl, the type can request a certain default view/data lim
> if no data are presented. Additionally, because of the
> "ignore"setting on the limts argument, we can detect whether the
> limits we are applying are defaults or actively set by the user.
> 
> The complication that motivated the sf bug
> http://sourceforge.net/tracker/?func=detail&aid=2861426&group_id=80706&
> atid=560720
> is a bit more subtle. Here no data type is presented to mpl -- either
> through "plot" or "fill" or "set_xlim" or whatever. If the user had
> passed any data in, or manually expressed their intent through
> "ax.xaxis_date" we would be fine. The difficulty is that they passed
> no data in but declared their intention to use a "YearFormatter". My
> original inclination, and the one that failed the unit tests, was to
> trigger a call to Axis.axis_date (a new method) on a call to
> ax.xaxis.set_major_formatter (or locator) where the argument was a
> DateLocator or DateFormatter. This seemed to be an imminently
> reasonable and helpful thing to do -- if they want a date locator or
> formatter presumably they will be passing in dates -- but the unit
> tests told me this was wrong.
> 
> The locators and formatters work on *converted* units. The
> EpochConverter and DateConverter both convert their native types to
> floating point days since 0000-00-00. So here are two custom
> converter interfaces which both end up with the same floating point
> representation. The conclusion is: mpl cannot use the
> locator/formatter type to infer what the basic type that users will be
> passing in. Just because two classes end up with the same floating
> point representation does not indicate that they want the same
> conversion pipeline from type -> float.
> 
> Nonetheless, we can, and already do in svn HEAD, handle the cases that
> I think you are worried about in this email. As long as you know what
> type you will be passing into mpl (regardless of whether you have any
> data available right now) you can inform the units interface with
> 
> ax.xaxis.update_units(someval)
> 
> where someval is an instance of the type you plan to pass in. Doing
> so will not affect your current data or view limits, but will trigger
> the conversion interface and importantly will trigger the
> units.AxisInfo.default_limits scaling which was recently added to
> avoid the kinds of problems we have been seeing with date conversion
> when no data is passed in.
> 
> 
> So despite this long winded email, the current infrastructure should
> support
> 
> * create axes, etc
> 
> * set your current formatter/locator
> 
> * ax.xaxis.update_units(myInstance)
> 
> where myInstance is an object of the type you expect to pass in. As
> long as you have registered a converter from type(myInstance) ->
> ConversionInterface, you can now specify the default limits through
> the ConversionInterface.default_limits method::
> 
> @staticmethod
> def default_units(x, axis):
> 'return the default unit for x or None for the given axis'
> return None
> 
> 
> As an example in matplotlib.dates, we choose an arbitrary interval,
> which while arbitrary avoids the 0..1 problem we have been having::
> 
> class DateConverter(units.ConversionInterface):
> """The units are equivalent to the timezone."""
> 
> @staticmethod
> def axisinfo(unit, axis):
> 'return the unit AxisInfo'
> # make sure that the axis does not start at 0
> 
> majloc = AutoDateLocator(tz=unit)
> majfmt = AutoDateFormatter(majloc, tz=unit)
> datemin = datetime.date(2000, 1, 1)
> datemax = datetime.date(2010, 1, 1)
> 
> return units.AxisInfo( majloc=majloc, majfmt=majfmt, label='',
> default_limits=(datemin, datemax))
> 
> JDH
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.409 / Virus Database: 270.13.110/2385 - Release Date:
> 09/20/09 17:51:00

On Sun, Sep 20, 2009 at 9:35 PM, John Hunter <jd...@gm...> wrote:
> where myInstance is an object of the type you expect to pass in. As
> long as you have registered a converter from type(myInstance) ->
> ConversionInterface, you can now specify the default limits through
> the ConversionInterface.default_limits method::
>
>  @staticmethod
>  def default_units(x, axis):
>    'return the default unit for x or None for the given axis'
>    return None
This is a typo: I should be referring to the default_limits attribute
of AxisInfo. Instead, I pasted in the default_units method of the
conversion interface
> As an example in matplotlib.dates, we choose an arbitrary interval,
> which while arbitrary avoids the 0..1 problem we have been having::
>
> class DateConverter(units.ConversionInterface):
>  """The units are equivalent to the timezone."""
>
>  @staticmethod
>  def axisinfo(unit, axis):
>    'return the unit AxisInfo'
>    # make sure that the axis does not start at 0
>
>    majloc = AutoDateLocator(tz=unit)
>    majfmt = AutoDateFormatter(majloc, tz=unit)
>    datemin = datetime.date(2000, 1, 1)
>    datemax = datetime.date(2010, 1, 1)
>
>    return units.AxisInfo( majloc=majloc, majfmt=majfmt, label='',
>                default_limits=(datemin, datemax))
This is the correct way to specify default_limits
JDH

It's caused by the files having multiple locations (relative to the root 
of the source tree) in different branches, or existing in some branches 
but not in others. In other words, files that have been moved, deleted 
or added since branch creation. I think if we retire old branches 
(0.91, 0.98), which I'm in favor of, we might alleviate some of that 
(I'm not 100% sure, but it seems plausible).
Mike
On 09/20/2009 01:21 PM, John Hunter wrote:
> Some files seem to get a properties modification on them every time
> someone does an svn merge, eg
>
> examples/misc/multiprocess.py
>
> which is rarely changed, but frequently has its svnmerge properties change
>
> home:~/mpl> svn diff -rPREV:HEAD examples/misc/multiprocess.py
>
> Property changes on: examples/misc/multiprocess.py
> ___________________________________________________________________
> Name: svn:mergeinfo
> - /branches/v0_91_maint/examples/misc/log.py:5753-5771
> /branches/v0_98_5_maint/examples/misc/log.py:6581,6585,6587,6589-6609,6614,6616,6625,6652,6660-6662,6672-6673,6714-6715,6717-6732,6752-6754,6761-6773,6781,6792,6800,6802,6805,6809,6811,6822,6827,6850,6854,6856,6859,6861-6873,6883-6884,6886,6890-6891,6906-6909,6911-6912,6915-6916,6918,6920-6925,6927-6928,6934,6941,6946,6948,6950,6952,6960,6972,6984-6985,6990,6995,6997-7001,7014,7016,7018,7024-7025,7033,7035,7042,7072,7080
> /branches/v0_99_maint/examples/misc/multiprocess.py:7338,7393,7395-7404,7407-7424,7428-7433,7442-7444,7446,7475-7482,7484,7486,7489-7523,7567,7569,7582-7584,7616-7618,7633,7638,7703,7727-7734,7740-7741,7745,7751,7756,7762,7770,7772,7774,7776-7778,7780,7784,7788,7790,7792,7794
> + /branches/v0_91_maint/examples/misc/log.py:5753-5771
> /branches/v0_98_5_maint/examples/misc/log.py:6581,6585,6587,6589-6609,6614,6616,6625,6652,6660-6662,6672-6673,6714-6715,6717-6732,6752-6754,6761-6773,6781,6792,6800,6802,6805,6809,6811,6822,6827,6850,6854,6856,6859,6861-6873,6883-6884,6886,6890-6891,6906-6909,6911-6912,6915-6916,6918,6920-6925,6927-6928,6934,6941,6946,6948,6950,6952,6960,6972,6984-6985,6990,6995,6997-7001,7014,7016,7018,7024-7025,7033,7035,7042,7072,7080
> /branches/v0_99_maint/examples/misc/multiprocess.py:7338,7393,7395-7404,7407-7424,7428-7433,7442-7444,7446,7475-7482,7484,7486,7489-7523,7567,7569,7582-7584,7616-7618,7633,7638,7703,7727-7734,7740-7741,7745,7751,7756,7762,7770,7772,7774,7776-7778,7780,7784,7788,7790,7792,7794,7796
>
> home:~/mpl> examples/misc/multiprocess.py
>
> Other examples that are frequently subject to properties changes are
>
> U doc/sphinxext/gen_gallery.py
> U doc/sphinxext/gen_rst.py
> U examples/mplot3d/contourf3d_demo.py
> U examples/mplot3d/scatter3d_demo.py
> U examples/mplot3d/polys3d_demo.py
> U examples/mplot3d/wire3d_demo.py
> U examples/mplot3d/surface3d_demo.py
> U examples/mplot3d/contour3d_demo.py
>
> Any idea what is special about these files that is causing them to get
> frequent property changes even when they are not modified apparently?
>
> It is a minor nuisance, but it makes it harder to see what has
> actually changed after a merge.
>
> JDH
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

On Sun, Sep 20, 2009 at 6:50 PM, Drain, Theodore R (343P)
<the...@jp...> wrote:
> I've run into this problem quite a few times and I'd love to figure out some way to fix it. As an example, here's the kind of scenario this occurs in:
>
> I embed MPL in a few different GUI's that plot data either in real-time or via the user selecting things. There is a saved state which contains preferences like auto-scaling, legend on/off, axis formatting, etc. When the app starts up, I need to create a plot to put on the screen and configure it. What I'd like to do is this:
>
> - create widget
> - apply format (date formatter, etc)
> - apply settings (autoscale, etc)
> - wait for data (either via real time feed or user clicking on things)
>
> But this is impossible because of this kind of bug. Instead, I have to create a plot with a fake date range and test every operation to see if it's actually setting data before applying the settings like autoscale. In addition, if the user removes data from the plot (via menu or selectable lists), I have to either start over or "unset" the settings back to something safe so this error won't occur. It really makes coding something like this a royal pain.
>
> I don't have a suggestion as of yet... Perhaps it could just return "N/A" or something like that.
>
> I think part of the problem might be the default ranges used by the autoscaling algorithm when there is no data are invalid for certain formatters and locators. That suggests that possible solutions might be one of:
>
> 1) require autoscaling or scaling algorithms to return ranges that will be OK for known scalers/formatters. Perhaps some system that allows different autoscaling algorithms to be set which can configure the default?
> 2) require scalers/formatters to be robust for any range or engineer the system to allow them to report "errors" in a way that allows the plot do something reasonable and not trigger an exception (perhaps some changeable behavior w/ the default as an exception?).
>
> I'll think about this a little this week and see if any other ideas come to mind.
I think we have this problem mostly licked. The problem I was writing
about in my email is a 2nd tier problem. For example, in svn HEAD,
you can specify an "empty" date plot as long as you inform mpl of you
intentions.. From the test_date_empty unit test::
 fig = plt.figure()
 ax = fig.add_subplot(1,1,1)
 ax.xaxis_date()
 fig.savefig('date_empty')
Here we are fine, because we call ax.axaxis_date, which informs mpl
that you intend to pass in datetime instances. The key piece which
makes this possible, which you allude to in your post, is the default
xlimits, which is new in svn HEAD. In particular, the default
converter provides an AxisInfo which now supports an optional
attribute
 default_limits: the default min, max of the axis if no data is present
which is overridden in the DateConverter:
 def axisinfo(unit, axis):
 'return the unit AxisInfo'
 # make sure that the axis does not start at 0
 majloc = AutoDateLocator(tz=unit)
 majfmt = AutoDateFormatter(majloc, tz=unit)
 datemin = datetime.date(2000, 1, 1)
 datemax = datetime.date(2010, 1, 1)
 return units.AxisInfo( majloc=majloc, majfmt=majfmt, label='',
 default_limits=(datemin, datemax))
while the min/max are arbitrary, the important thing is that custom
types can now handle the default min/max limits, so when you present a
new type to mpl, the type can request a certain default view/data lim
if no data are presented. Additionally, because of the
"ignore"setting on the limts argument, we can detect whether the
limits we are applying are defaults or actively set by the user.
The complication that motivated the sf bug
http://sourceforge.net/tracker/?func=detail&aid=2861426&group_id=80706&atid=560720
is a bit more subtle. Here no data type is presented to mpl -- either
through "plot" or "fill" or "set_xlim" or whatever. If the user had
passed any data in, or manually expressed their intent through
"ax.xaxis_date" we would be fine. The difficulty is that they passed
no data in but declared their intention to use a "YearFormatter". My
original inclination, and the one that failed the unit tests, was to
trigger a call to Axis.axis_date (a new method) on a call to
ax.xaxis.set_major_formatter (or locator) where the argument was a
DateLocator or DateFormatter. This seemed to be an imminently
reasonable and helpful thing to do -- if they want a date locator or
formatter presumably they will be passing in dates -- but the unit
tests told me this was wrong.
The locators and formatters work on *converted* units. The
EpochConverter and DateConverter both convert their native types to
floating point days since 0000-00-00. So here are two custom
converter interfaces which both end up with the same floating point
representation. The conclusion is: mpl cannot use the
locator/formatter type to infer what the basic type that users will be
passing in. Just because two classes end up with the same floating
point representation does not indicate that they want the same
conversion pipeline from type -> float.
Nonetheless, we can, and already do in svn HEAD, handle the cases that
I think you are worried about in this email. As long as you know what
type you will be passing into mpl (regardless of whether you have any
data available right now) you can inform the units interface with
 ax.xaxis.update_units(someval)
where someval is an instance of the type you plan to pass in. Doing
so will not affect your current data or view limits, but will trigger
the conversion interface and importantly will trigger the
units.AxisInfo.default_limits scaling which was recently added to
avoid the kinds of problems we have been seeing with date conversion
when no data is passed in.
So despite this long winded email, the current infrastructure should support
 * create axes, etc
 * set your current formatter/locator
 * ax.xaxis.update_units(myInstance)
where myInstance is an object of the type you expect to pass in. As
long as you have registered a converter from type(myInstance) ->
ConversionInterface, you can now specify the default limits through
the ConversionInterface.default_limits method::
 @staticmethod
 def default_units(x, axis):
 'return the default unit for x or None for the given axis'
 return None
As an example in matplotlib.dates, we choose an arbitrary interval,
which while arbitrary avoids the 0..1 problem we have been having::
class DateConverter(units.ConversionInterface):
 """The units are equivalent to the timezone."""
 @staticmethod
 def axisinfo(unit, axis):
 'return the unit AxisInfo'
 # make sure that the axis does not start at 0
 majloc = AutoDateLocator(tz=unit)
 majfmt = AutoDateFormatter(majloc, tz=unit)
 datemin = datetime.date(2000, 1, 1)
 datemax = datetime.date(2010, 1, 1)
 return units.AxisInfo( majloc=majloc, majfmt=majfmt, label='',
 default_limits=(datemin, datemax))
JDH

John,
I've run into this problem quite a few times and I'd love to figure out some way to fix it. As an example, here's the kind of scenario this occurs in:
I embed MPL in a few different GUI's that plot data either in real-time or via the user selecting things. There is a saved state which contains preferences like auto-scaling, legend on/off, axis formatting, etc. When the app starts up, I need to create a plot to put on the screen and configure it. What I'd like to do is this:
- create widget
- apply format (date formatter, etc)
- apply settings (autoscale, etc)
- wait for data (either via real time feed or user clicking on things)
But this is impossible because of this kind of bug. Instead, I have to create a plot with a fake date range and test every operation to see if it's actually setting data before applying the settings like autoscale. In addition, if the user removes data from the plot (via menu or selectable lists), I have to either start over or "unset" the settings back to something safe so this error won't occur. It really makes coding something like this a royal pain.
I don't have a suggestion as of yet... Perhaps it could just return "N/A" or something like that. 
I think part of the problem might be the default ranges used by the autoscaling algorithm when there is no data are invalid for certain formatters and locators. That suggests that possible solutions might be one of:
1) require autoscaling or scaling algorithms to return ranges that will be OK for known scalers/formatters. Perhaps some system that allows different autoscaling algorithms to be set which can configure the default?
2) require scalers/formatters to be robust for any range or engineer the system to allow them to report "errors" in a way that allows the plot do something reasonable and not trigger an exception (perhaps some changeable behavior w/ the default as an exception?).
I'll think about this a little this week and see if any other ideas come to mind.
Ted
> -----Original Message-----
> From: John Hunter [mailto:jd...@gm...]
> Sent: Sunday, September 20, 2009 3:26 PM
> To: Andrew Straw; matplotlib development list
> Subject: [matplotlib-devel] empty date formatter unit tests
> 
> I spent a long time working on
> 
> 
> https://sourceforge.net/tracker/index.php?func=detail&aid=2861426&group
> _id=80706&atid=560720
> 
> and the associated unit test. I learned a lot and the unit tests
> really helped.
> 
> First, I decided that if someone sets the formatter or locator to be a
> DateFormatter or DateLocator, then they are expressing their intention
> to plot dates, so I triggered the axis unit conversion pipeline on
> set_major_formatter(aDateFormatter) to use a DateConverter. This
> worked fine, but broke the JPL unit tests, because in their
> EpochConverter, they have a *different* class that nonetheless
> converts to the "datenum" floats, ie days since 0000-00-00, and thus
> they also use the AutoDateFormatter and AutoDateLocator in their
> AxisInfo converter info.
> 
> So what was happening is that the unit tests for the Epochs passed in
> an Epoch instance, this triggered the unit conversion interface which
> set the formatter to be an AutoDateFormatter, which triggered my new
> code to use a DateConverter, which in turn broke the Epochs since the
> DateConverter doesn't know how to hand;e an Epoch. This is quite
> subtle, but what is happening is that two different classes are
> converting to the same floating point representation, and so both can
> use the same Formatter and Locator, but we can't invert -- just
> because we see a Formatter or Locator of a certain type, we can't
> infer the class.
> 
> I would have never caught this w/o the unit test, would have happily
> committed my "fix" while screwing up all the JPL stuff.
> 
> At the end of the day, after realizing all this, I decided the current
> behavior was not a bug at all, and that mpl was doing what it was told
> to do. And there is no way to be smart here, since the use of a
> DateFormatter does not imply you want a DateConverter. So I simply
> modified the DateFormatter code to raise with an intelligible message.
> 
> The question is: what to do with the unit test I wrote to expose the :
> test_dates.test_empty_date_with_year_formatter
> 
> I can either leave it as a knownfailure, since that is what it is, or
> modify it to set ax.xaxis_date as the traceback advises, and then add
> the image comparison.
> 
> What do you think?
> 
> Another win for the unit tests, though they caused me to spend a lot
> more time "fixing" this bug than I would have without them <wink>
> 
> JDH
> 
> -----------------------------------------------------------------------
> -------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register
> now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.409 / Virus Database: 270.13.109/2384 - Release Date:
> 09/20/09 06:22:00

I spent a long time working on
 https://sourceforge.net/tracker/index.php?func=detail&aid=2861426&group_id=80706&atid=560720
and the associated unit test. I learned a lot and the unit tests really helped.
First, I decided that if someone sets the formatter or locator to be a
DateFormatter or DateLocator, then they are expressing their intention
to plot dates, so I triggered the axis unit conversion pipeline on
set_major_formatter(aDateFormatter) to use a DateConverter. This
worked fine, but broke the JPL unit tests, because in their
EpochConverter, they have a *different* class that nonetheless
converts to the "datenum" floats, ie days since 0000-00-00, and thus
they also use the AutoDateFormatter and AutoDateLocator in their
AxisInfo converter info.
So what was happening is that the unit tests for the Epochs passed in
an Epoch instance, this triggered the unit conversion interface which
set the formatter to be an AutoDateFormatter, which triggered my new
code to use a DateConverter, which in turn broke the Epochs since the
DateConverter doesn't know how to hand;e an Epoch. This is quite
subtle, but what is happening is that two different classes are
converting to the same floating point representation, and so both can
use the same Formatter and Locator, but we can't invert -- just
because we see a Formatter or Locator of a certain type, we can't
infer the class.
I would have never caught this w/o the unit test, would have happily
committed my "fix" while screwing up all the JPL stuff.
At the end of the day, after realizing all this, I decided the current
behavior was not a bug at all, and that mpl was doing what it was told
to do. And there is no way to be smart here, since the use of a
DateFormatter does not imply you want a DateConverter. So I simply
modified the DateFormatter code to raise with an intelligible message.
The question is: what to do with the unit test I wrote to expose the :
test_dates.test_empty_date_with_year_formatter
I can either leave it as a knownfailure, since that is what it is, or
modify it to set ax.xaxis_date as the traceback advises, and then add
the image comparison.
What do you think?
Another win for the unit tests, though they caused me to spend a lot
more time "fixing" this bug than I would have without them <wink>
JDH

Some files seem to get a properties modification on them every time
someone does an svn merge, eg
 examples/misc/multiprocess.py
which is rarely changed, but frequently has its svnmerge properties change
home:~/mpl> svn diff -rPREV:HEAD examples/misc/multiprocess.py
Property changes on: examples/misc/multiprocess.py
___________________________________________________________________
Name: svn:mergeinfo
 - /branches/v0_91_maint/examples/misc/log.py:5753-5771
/branches/v0_98_5_maint/examples/misc/log.py:6581,6585,6587,6589-6609,6614,6616,6625,6652,6660-6662,6672-6673,6714-6715,6717-6732,6752-6754,6761-6773,6781,6792,6800,6802,6805,6809,6811,6822,6827,6850,6854,6856,6859,6861-6873,6883-6884,6886,6890-6891,6906-6909,6911-6912,6915-6916,6918,6920-6925,6927-6928,6934,6941,6946,6948,6950,6952,6960,6972,6984-6985,6990,6995,6997-7001,7014,7016,7018,7024-7025,7033,7035,7042,7072,7080
/branches/v0_99_maint/examples/misc/multiprocess.py:7338,7393,7395-7404,7407-7424,7428-7433,7442-7444,7446,7475-7482,7484,7486,7489-7523,7567,7569,7582-7584,7616-7618,7633,7638,7703,7727-7734,7740-7741,7745,7751,7756,7762,7770,7772,7774,7776-7778,7780,7784,7788,7790,7792,7794
 + /branches/v0_91_maint/examples/misc/log.py:5753-5771
/branches/v0_98_5_maint/examples/misc/log.py:6581,6585,6587,6589-6609,6614,6616,6625,6652,6660-6662,6672-6673,6714-6715,6717-6732,6752-6754,6761-6773,6781,6792,6800,6802,6805,6809,6811,6822,6827,6850,6854,6856,6859,6861-6873,6883-6884,6886,6890-6891,6906-6909,6911-6912,6915-6916,6918,6920-6925,6927-6928,6934,6941,6946,6948,6950,6952,6960,6972,6984-6985,6990,6995,6997-7001,7014,7016,7018,7024-7025,7033,7035,7042,7072,7080
/branches/v0_99_maint/examples/misc/multiprocess.py:7338,7393,7395-7404,7407-7424,7428-7433,7442-7444,7446,7475-7482,7484,7486,7489-7523,7567,7569,7582-7584,7616-7618,7633,7638,7703,7727-7734,7740-7741,7745,7751,7756,7762,7770,7772,7774,7776-7778,7780,7784,7788,7790,7792,7794,7796
home:~/mpl> examples/misc/multiprocess.py
Other examples that are frequently subject to properties changes are
 U doc/sphinxext/gen_gallery.py
 U doc/sphinxext/gen_rst.py
 U examples/mplot3d/contourf3d_demo.py
 U examples/mplot3d/scatter3d_demo.py
 U examples/mplot3d/polys3d_demo.py
 U examples/mplot3d/wire3d_demo.py
 U examples/mplot3d/surface3d_demo.py
 U examples/mplot3d/contour3d_demo.py
Any idea what is special about these files that is causing them to get
frequent property changes even when they are not modified apparently?
It is a minor nuisance, but it makes it harder to see what has
actually changed after a merge.
JDH

On Thu, Sep 17, 2009 at 11:02 AM, Fernando Perez <fpe...@gm...> wrote:
> Thanks :) I'll take care of it later then, I'll try to fix a warning
> we're seeing as well because it lacks a setup.py.
>
Done. I also committed the update to sampledoc, with a note in the
log to eventually remove it once it's 'enough' in the wild in mpl.
Cheers,
f

Brad Chivari wrote:
> SUBJECT:
> Filtering out 0 bar height/width not working
> 
> FILE:
> matplotlib/ trunk/ matplotlib/ lib/ matplotlib/ axes.py
> 
> PROBLEM:
> xmin = np.amin(width[width!=0]) # filter out the 0 width rects
> ymin = np.amin(height[height!=0]) # filter out the 0 height rects
> 
> These aren't using proper python list comprehension and don't work as expected (for me anyway).
> 
> SOLUTION:
> Shouldn't they be something like:
> xmin = np.amin([w for w in width if w != 0])
> ymin = np.amin([h for h in height if h != 0])
> 
> Once I changed them they seem to work properly.
I have applied a slight modification to your fix, which seems to me to 
be the right approach, given that the bar implementation is based on 
lists rather than ndarrays.
Thanks.
Eric

Ryanitus wrote:
> I may have found a bug in the __setitem__ method of the maxdict class.
> 
Fixed--thanks for pointing it out.
Eric
> Since a dictionary is a mapping class, if an item is set that already
> exists, it overwrites the previous. However, you are still appending that
> item to _killkeys regardless.
> 
> In the case where 2 items with the same key were added and later removed due
> to size constraints, the line in bold would throw an exception on the second
> call.
> 
> By checking for the key existance, you handle that situation gracefully. 
> The item can still be removed from _killkeys, since it's the next to go
> anyway.
> 
> Ryan
> 
> Original code (circa line 776):
> 
> if len(self)>=self.maxsize:
> del self[self._killkeys[0]]
> del self._killkeys[0]
> dict.__setitem__(self, k, v)
> self._killkeys.append(k)
> 
> Possible solution:
> 
> if len(self)>=self.maxsize:
> if self.has_key(self._killkeys[0]):
> del self[self._killkeys[0]]
> del self._killkeys[0]
> dict.__setitem__(self, k, v)
> self._killkeys.append(k)
> 
> 
> 

On Fri, Sep 18, 2009 at 7:01 PM, Andrew Straw <str...@as...> wrote:
> Maybe the MPL binary was built with a numpy svn version that had API
> incompatibilities with numpy releases?
I built the python2.6 OSX 0.99.1rc1 binary with the numpy from the
1.3.0 dmg installer from the sf site, intentionally not using my local
numpy from svn since I understand there are some ABI incompatibilities
between 1.3.0 and 1.4.0svn and I wanted to target the latest release.
 What version are you using David?
JDH

David Warde-Farley wrote:
> On 18-Sep-09, at 6:42 PM, David Warde-Farley wrote:
> 
>> File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
>> python2.6/site-packages/ipython-0.10-py2.6.egg/IPython/Shell.py", line
>> 627, in __init__
>> user_ns,user_global_ns,b2 =
>> self._matplotlib_config(name,user_ns,user_global_ns)
>> File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
>> python2.6/site-packages/ipython-0.10-py2.6.egg/IPython/Shell.py", line
>> 556, in _matplotlib_config
>> import matplotlib.pylab as pylab
>> File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
>> python2.6/site-packages/matplotlib/pylab.py", line 206, in <module>
>> from matplotlib import mpl # pulls in most modules
>> File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
>> python2.6/site-packages/matplotlib/mpl.py", line 1, in <module>
>> from matplotlib import artist
>> File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
>> python2.6/site-packages/matplotlib/artist.py", line 5, in <module>
>> from transforms import Bbox, IdentityTransform, TransformedBbox,
>> TransformedPath
>> File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
>> python2.6/site-packages/matplotlib/transforms.py", line 34, in 
>> <module>
>> from matplotlib._path import affine_transform
>> ImportError: numpy.core.multiarray failed to import
>> 
>
> Looking a little harder at this (after downloading the source) I'm 
> positively at a loss, since multiarray doesn't seem to be explicitly 
> imported anywhere in matplotlib. Furthermore, importing 
> numpy.core.multiarray from ipython works just fine.
>
> Moreover, I just built matplotlib-0.99.1rc1 from source and the 
> problem doesn't manifest. _Weird_. Any idea what's going on?
> 
Maybe the MPL binary was built with a numpy svn version that had API
incompatibilities with numpy releases?

On 18-Sep-09, at 6:42 PM, David Warde-Farley wrote:
> File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
> python2.6/site-packages/ipython-0.10-py2.6.egg/IPython/Shell.py", line
> 627, in __init__
> user_ns,user_global_ns,b2 =
> self._matplotlib_config(name,user_ns,user_global_ns)
> File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
> python2.6/site-packages/ipython-0.10-py2.6.egg/IPython/Shell.py", line
> 556, in _matplotlib_config
> import matplotlib.pylab as pylab
> File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
> python2.6/site-packages/matplotlib/pylab.py", line 206, in <module>
> from matplotlib import mpl # pulls in most modules
> File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
> python2.6/site-packages/matplotlib/mpl.py", line 1, in <module>
> from matplotlib import artist
> File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
> python2.6/site-packages/matplotlib/artist.py", line 5, in <module>
> from transforms import Bbox, IdentityTransform, TransformedBbox,
> TransformedPath
> File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
> python2.6/site-packages/matplotlib/transforms.py", line 34, in 
> <module>
> from matplotlib._path import affine_transform
> ImportError: numpy.core.multiarray failed to import
Looking a little harder at this (after downloading the source) I'm 
positively at a loss, since multiarray doesn't seem to be explicitly 
imported anywhere in matplotlib. Furthermore, importing 
numpy.core.multiarray from ipython works just fine.
Moreover, I just built matplotlib-0.99.1rc1 from source and the 
problem doesn't manifest. _Weird_. Any idea what's going on?
David

On 18-Sep-09, at 6:09 PM, John Hunter wrote:
> Could you try the 99.1rc release candidate linked to in the "news" 
> box on the mpl homepage? I did fix some link problems in the osx 
> binaries since 0.99.0.
Just tried, unfortunately it doesn't seem to like my setup either:
RuntimeError: FATAL: module compiled aslittle endian, but detected 
different endianness at runtime
Traceback (most recent call last):
 File "/Library/Frameworks/Python.framework/Versions/2.6/bin/ 
ipython", line 8, in <module>
 load_entry_point('ipython==0.10', 'console_scripts', 'ipython')()
 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/ipython-0.10-py2.6.egg/IPython/ipapi.py", line 
556, in launch_new_instance
 ses = make_session(user_ns,shellclass)
 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/ipython-0.10-py2.6.egg/IPython/ipapi.py", line 
684, in make_session
 return IPython.Shell.start(user_ns)
 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/ipython-0.10-py2.6.egg/IPython/Shell.py", line 
1241, in start
 return shell(user_ns = user_ns)
 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/ipython-0.10-py2.6.egg/IPython/Shell.py", line 
1106, in __init__
 shell_class=MatplotlibShell)
 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/ipython-0.10-py2.6.egg/IPython/Shell.py", line 
73, in __init__
 debug=debug,shell_class=shell_class)
 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/ipython-0.10-py2.6.egg/IPython/ipmaker.py", 
line 100, in make_IPython
 embedded=embedded,**kw)
 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/ipython-0.10-py2.6.egg/IPython/Shell.py", line 
627, in __init__
 user_ns,user_global_ns,b2 = 
self._matplotlib_config(name,user_ns,user_global_ns)
 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/ipython-0.10-py2.6.egg/IPython/Shell.py", line 
556, in _matplotlib_config
 import matplotlib.pylab as pylab
 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/matplotlib/pylab.py", line 206, in <module>
 from matplotlib import mpl # pulls in most modules
 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/matplotlib/mpl.py", line 1, in <module>
 from matplotlib import artist
 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/matplotlib/artist.py", line 5, in <module>
 from transforms import Bbox, IdentityTransform, TransformedBbox, 
TransformedPath
 File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ 
python2.6/site-packages/matplotlib/transforms.py", line 34, in <module>
 from matplotlib._path import affine_transform
ImportError: numpy.core.multiarray failed to import

Could you try the 99.1rc release candidate linked to in the "news" box 
on the mpl homepage? I did fix some link problems in the osx binaries 
since 0.99.0.
On Sep 18, 2009, at 4:53 PM, David Warde-Farley <dw...@cs...> 
wrote:
> Using the binaries at matplotlib.sf.net:
>
>
> dwf@strafe:~$ ipython -pylab
> Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39)
> Type "copyright", "credits" or "license" for more information.
>
> IPython 0.10 -- An enhanced Interactive Python.
> ? -> Introduction and overview of IPython's features.
> %quickref -> Quick reference.
> help -> Python's own help system.
> object? -> Details about 'object'. ?object also works, ?? prints 
> more.
>
> Welcome to pylab, a matplotlib-based Python environment.
> For more information, type 'help(pylab)'.
>
> In [1]: matplotlib.__version__Out[1]: '0.99.0'
>
> In [2]: matplotlib.get_backend()
> Out[2]: 'TkAgg'
>
> In [3]: plt.figure()
> Bus error
>
>
> GDB says this was the problem:
>
>>>> fig = plt.figure()
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x00000028
> 0x00e04d95 in PyArray_INCREF ()
>
> I wonder if this is caused by me having my own freetype installed
> under /usr/local (I was installing Chaco the other day from source,
> and thus required it), and the dynamic linker getting confused about
> which version to use?
>
> David
>
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart 
> your
> developing skills, take BlackBerry mobile applications to market and 
> stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register 
> now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Using the binaries at matplotlib.sf.net:
dwf@strafe:~$ ipython -pylab
Python 2.6.2 (r262:71600, Apr 16 2009, 09:17:39)
Type "copyright", "credits" or "license" for more information.
IPython 0.10 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.
 Welcome to pylab, a matplotlib-based Python environment.
 For more information, type 'help(pylab)'.
In [1]: matplotlib.__version__Out[1]: '0.99.0'
In [2]: matplotlib.get_backend()
Out[2]: 'TkAgg'
In [3]: plt.figure()
Bus error
GDB says this was the problem:
 >>> fig = plt.figure()
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000028
0x00e04d95 in PyArray_INCREF ()
I wonder if this is caused by me having my own freetype installed 
under /usr/local (I was installing Chaco the other day from source, 
and thus required it), and the dynamic linker getting confused about 
which version to use?
David

On Fri, Sep 18, 2009 at 17:44, Michael Droettboom <md...@st...> wrote:
> Thanks. The subslicing optimization added in 0.99 was truncating the polar
> path. Subslicing has been made more "cautious" now and will only be applied
> when the axes are rectilinear and non-logarithmic.
>
> Interestingly, there was already a test in the test framework for this bug,
> but the baseline image was wrong :)
Thanks for fixing this :)
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi