test_bar_log fights back with matplotlib 1.3.0

[yarikoptic]

======================================================================
FAIL: test_bar_log (pandas.tests.test_graphics.TestDataFramePlots)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/yoh/deb/gits/pkg-exppsy/pandas/pandas/tests/test_graphics.py", line 568, in test_bar_log
    self.assertEqual(ax.yaxis.get_ticklocs()[0], 1.0)
AssertionError: 0.10000000000000001 != 1.0

----------------------------------------------------------------------
Ran 1 test in 0.341s

needs to be fixed up for debian where mpl now 1.3.0

[jtratner]

@yarikoptic side note - aren't there a bunch of failing tests for nipy's pandas builds?

[yarikoptic]

@jtratner -- yes unfortunately there are
http://nipy.bic.berkeley.edu/waterfall?category=pandas
and I would appreciate if they get addressed. ATM I worry about this particular one to stabilize released pandas 0.12 building on Debian

[jtratner]

@yarikoptic or @cpcloud any chance there's a vagrant box already set up to make it easier to debug these locally?

[cpcloud]

@yarikoptic Forgive me, but can you give a 2-second overview of how to navigate all of that stuff?

[yarikoptic]

@jtratner for this particular bug I guess you would not find any "stock" vagrant box since Debian unstable is rolling too much (updated twice a day) for anyone to care... may be at some point I would reincarnate my veewee setup to furnish those. But you could get ANY Debian based vagrant box (thus stock too) and debootstrap a complete Debian into a subdirectory within... see e.g. my elderly post http://neuro.debian.net/blog/2011/2011-12-12_schroot_fslview.html

For sparc-specific bugs -- you would need a sparc box and vagrant alone would not be sufficient.

[yarikoptic]

@cpcloud buildbot's views are indeed a bit archaic and require "get used to". I prefer waterfall for a quick look
http://nipy.bic.berkeley.edu/waterfall?category=pandas
there on top it better be green ;) those are builders names, defined as combinations of project, python, architecture etc in their names, e.g. pandas-py2.x-sid-sparc is pandas with python2 (whatever is default there), Debian sid, sparc architecture. Thus you have "builders" for sid (unstable) and wheezy (stable Debian), python2 and python3 (concrete versions differ between sid and wheezy -- look inside logs ;) ).

if any builder "red" -- look inside,e.g. go to
http://nipy.bic.berkeley.edu/builders/pandas-py2.x-sid-sparc
there you would see all failed/succeeded builds. For failed, go to the failed one e.g.
http://nipy.bic.berkeley.edu/builders/pandas-py2.x-sid-sparc/builds/87
and you will see what succeded (in green) and what failed (again in red). Step 9 here (shell_4 'xvfb-run --auto-servernum ...) is the one running tests and it is in red -- just click on its stdio link to get to entire dump of output.

You could also get there straight from waterfall for recent builds -- for older ones you might need to scroll down to get to that failed step in red.

I hope this helps

[jtratner]

@cpcloud I actually find it easier to just go to this page - http://nipy.bic.berkeley.edu/builders and search for 'pandas' - then it's basically just the same thing as Travis, just need to click on the red blocks until it shows you a list of test cases.

[yarikoptic]

so what about the issue itself? ;)

[cpcloud]

@yarikoptic forgot to say: thanks, your explanation was very helpful...

re this bug....i'll take a look...i don't think this is just happening on sparc

[yarikoptic]

@cpcloud I never said it happens just on sparc ;) it is matplotlib 1.3.0 compatibility issue

[cpcloud]

@y-p

wondering if u know the reason for this:

In [1]: paste
        p1 = Series([200, 500]).plot(log=True, kind='bar')
## -- End pasted text --

In [2]: p1.yaxis.get_ticklocs()
Out[2]: array([     0.1,      1. ,     10. ,    100. ,   1000. ,  10000. ])

note the extra 0.1 and 10000, here's the plot

only 1, 10, 100, and 1000 in the plot....should i report to matplotlib?

[cpcloud]

opened an issue over at matplotlib

matplotlib/matplotlib#2419

[cpcloud]

commit 4c0f3f30f805f53f91f22f26212d366c59d2ae48
Author: Daniel Hyams <dhyams@gitdev.(none)>
Date: Sat Jan 19 19:14:03 2013 -0500

Modifications to MultipleLocator and LogLocator, so that the locators will
give locations one past what they really need to. This is necessary, because
in situations where round off error matters, we want the locator to offer
more that it really thinks it needs to. The clipping of ticks still takes
place in the Axis class, so it's perfectly fine to add more locs than necessary.

In fact, matplotlib relies on the clipping behavior in the Axis class already
to not draw ticks outside of the limits of the axis.

I'll update the tests for different versions of MPL