matplotlib-devel Mailing List for matplotlib

On Mon, Mar 26, 2012 at 7:42 PM, Tony Yu <ts...@gm...> wrote:

> I'm drawing hexbins with alpha < 1 and get dark lines at the bin edges. It
> turns out that setting `edgecolors = 'none'` sets the edge color to be the
> same as the face color, as mentioned in the docstring:
>
>            If ``'none'``, draws the edges in the same color as the fill
> color.
>            This is the default, as it avoids unsightly unpainted pixels
>            between the hexagons.
>
> This behavior is a bit weird, since setting colors to 'none' usually makes
> the element invisible. Wouldn't it be more consistent to let 'none' be
> passed to the PolyCollection (which draws the hexbins), such that edges
> aren't drawn. Then, to maintain the current behavior, change the default to
> 'face'. (Of course, this wouldn't really maintain current behavior for code
> that explicitly passes `edgecolors='none'`.)
>
> Also, if I let 'none' get passed to the PolyCollection, I don't see the
> "unsightly unpainted pixels between the hexagons". Is this just a
> system-dependent artifact, or is it an outdated docstring?
>
> Thanks,
> -Tony
>

Just to clarify, here's an example of how I think hexbin should behave:
https://github.com/tonysyu/matplotlib/commit/39e28540d30a55c18975533fe3625c47506c5908

-Tony

On Mar 26, 2012, at 7:37 PM, Derek Homeier <de...@as...> wrote:

> Hi Sandro,
> 
>> yes, Debian has a separate package for documentation (since it
>> requires to be build just on time, whilc mpl requires to be built on
>> each architecture we support, so splitting the package results in a
>> lot of saved space). JFYR this is the layout of packages in Debian:
>> 
>> python-matplotlib - the python module
>> python-matplotlib-data - mpl-data dir + sampeldata + config files + nib + fonts
>> python-matplotlib-dbg - debug symbols for python extensions
>> python-matplotlib-doc - all the built doc, in html and pdf formats
> 
> thanks for the info; currently fink only has extra packages for the basemap toolkit.
> While there are not that many actual architectures, there are still up to 4 or 5 
> Python versions to support, so a single doc package could also save a lot 
> (although I am not sure how to setup such a build yet…). 
> The actual matplotlib module could also be reduced much further in size when 
> building from the _notests tar ball. I am not sure how much demand there is 
> for normal users to be able to run the complete test suite. Or is this just a 
> temporary option for the rc builds anyway?
> 


I have also been uploading a "notests" tarball for those who do not want to carry the extra weight of the baseline test images. 

For packagers concerned about size, one option would be to provide just the baseline images as a separate package.  These are all the PNGs recursively under lib/matplotlib/tests. 

Hi Sandro,

> yes, Debian has a separate package for documentation (since it
> requires to be build just on time, whilc mpl requires to be built on
> each architecture we support, so splitting the package results in a
> lot of saved space). JFYR this is the layout of packages in Debian:
> 
> python-matplotlib - the python module
> python-matplotlib-data - mpl-data dir + sampeldata + config files + nib + fonts
> python-matplotlib-dbg - debug symbols for python extensions
> python-matplotlib-doc - all the built doc, in html and pdf formats

thanks for the info; currently fink only has extra packages for the basemap toolkit.
While there are not that many actual architectures, there are still up to 4 or 5 
Python versions to support, so a single doc package could also save a lot 
(although I am not sure how to setup such a build yet…). 
The actual matplotlib module could also be reduced much further in size when 
building from the _notests tar ball. I am not sure how much demand there is 
for normal users to be able to run the complete test suite. Or is this just a 
temporary option for the rc builds anyway?

Cheers,
						Derek

On 26.03.2012, at 7:43PM, John Hunter wrote:

> On Mon, Mar 26, 2012 at 12:00 PM, Russell Owen <ro...@uw...> wrote:
> On Mar 24, 2012, at 12:16 PM, Sandro Tosi wrote:
> 
> > On Sat, Mar 24, 2012 at 18:13, Derek Homeier
> > <de...@as...> wrote:
> >> I used the 1.1.0 version to build with the fink Python installation on MaxOS X
> >> and everything seems to work there, passing the tests at least (does pylab.test('full')
> >> execute all tests? It seems a rather small number…).
> >
> > to run tests I use:
> >
> > python -c "import matplotlib as m ; m.test(verbosity=1)"
> 
> Thank you for the test instructions. That's a much more complete test than I had been using. I get the following one failure on Mac OS X 10.6 using my new binary installer (results are appended). I'm also concerned about the complaint:
> """
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/__init__.py:921: UserWarning:  This call to matplotlib.use() has no effect
> because the the backend has already been chosen;
> matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
> or matplotlib.backends is imported for the first time.
> """
> which suggests a test that is mis-written.
> 
> At the end of the tests we try and switch back to the users original backend (we switch into agg at the start) in case the user is running interactively.  This warning is mostly harmless, and doesn't indicate a problem with any tests.  It appears you have just the one failure on fonts-styles.
> 
I also had two failures of this type on my first attempt to test the package; now when 
testing within the fink build environment, everything passes. This might have to do 
with the fontconfig setup, not sure if I can reproduce it any more or nail it further down. 

> Ran 1061 tests in 344.859s
> 
> FAILED (KNOWNFAIL=541, failures=1)

Russel, you may also want to check the testing dependencies mentioned in connection 
with the tests under Windows in this thread - installing inkscape in addition to ghostscript 
and pil got me rid of the Known Failures (due to missing functionality for comparing PDF 
and SVG output) as well. 

Does anyone see a problem with running the tests with 'python -B'? Otherwise I'd need to 
get rid of the byte-compiled files in the build directory afterwards, as they would cause the 
package validation to fail.

Cheers,
					Derek