matplotlib-devel Mailing List for matplotlib

My PR to squelch the seemingly new tests passes travis. Unless
someone strongly protests, I will merge it later this afternoon so we
can get back to our normally scheduled testing.
If we want to discuss turning some of the tests back on we can have
that discussion later.
Tom
On Thu, Mar 27, 2014 at 11:40 AM, Phil Elson <phi...@gm...> wrote:
> I see your point Paul, but from my perspective matplotlib's codebase is
> slowly but surely being tidied up, and the consistently styled code is
> making it easier to read, maintain and enhance.
>
> Re-quoting Guido:
>
>
> Let's try to make new stdlib modules use the best style we
> can think of, but limit the time spent fretting over code
> that's already there.
>
> We've also taken this view and as a result have whole sub-packages which we
> do not check the PEP8 tests against
> (https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/tests/test_coding_standards.py#L41).
> However, I must add that it is actually quite rewarding to go through ugly
> code and turn it into something approaching consistent [I encourage you to
> try it when the sun isn't shining in California ;) ], not not mention it
> being a great way to get involved in the development of mpl (actually in the
> beginning I think that is how Thomas and Nelle became frequent committers).
>
> So in summary I agree they are just *guidelines*, not strict rules, but we
> have to maintain a highly collaborative repository of code and we ultimately
> need to make it as readable and maintainable as possible - the best way of
> doing that IMHO is to automate the testing using tools such as pep8 so that
> when we review PRs we only need to focus on behaviour, and not on whether
> there are trailing whitespace characters etc.
>
>
>
>
>
>
>
>
> On 27 March 2014 01:51, Thomas Caswell <tca...@gm...> wrote:
>>
>> At any rate, I have a PR (#2930) that should make it pass cleanly again.
>>
>> On the bright side, it looks like one of the changes is 1.5 is that
>> long unbreakable lines will get ignored by E501 so urls are safe
>> again.
>>
>>
>>
>> On Wed, Mar 26, 2014 at 6:10 PM, Paul Ivanov <pi...@be...> wrote:
>> > Nelle Varoquaux, on 2014年03月26日 21:27, wrote:
>> >> > Does anyone know why we are seeing a huge number of PEP 8 failures
>> >> > now?
>> >> > It looks to me like it is a change in which modules are subject to
>> >> > the
>> >> > test, or in which tests are grounds for failure. I don't know how
>> >> > all
>> >> > this is set up, though.
>> >>
>> >> If it started very recently, it could be linked to the new release.
>> >> They
>> >> have started to make "none backward" compatible version, in the sense
>> >> that
>> >> the stylechecker is increasingly strict. It is very annoying...
>> >
>> > Can we not revisit (and possibly revert) the morally absolutist
>> > PEP-8 or death position that matplotlib has taken?
>> >
>> > Quoting GvR (emphasis mine):
>> >
>> > All I want to say is, people lighten up. The style guide
>> > can't solve all your problems. You are never going to have
>> > all code compliant. Use the style guide when it helps, *ignore
>> > it when it's in the way*
>> >
>> > And from that same email:
>> >
>> > Let's try to make new stdlib modules use the best style we
>> > can think of, but limit the time spent fretting over code
>> > that's already there.
>> >
>> >
>> > The rest of the message is useful to read:
>> > https://mail.python.org/pipermail/python-dev/2010-November/105681.html
>> >
>> > Another reason for not being so rigid about PEP-8 is that its a
>> > living document. Are we really doing massive search-and-replace
>> > changes to the codebase just to comply with a moving target?
>> >
>> > best,
>> > --
>> > _
>> > / \
>> > A* \^ -
>> > ,./ _.`\\ / \
>> > / ,--.S \/ \
>> > / `"~,_ \ \
>> > __o ?
>> > _ \<,_ /:\
>> > --(_)/-(_)----.../ | \
>> > --------------.......J
>> > Paul Ivanov
>> > http://pirsquared.org
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>>
>> --
>> Thomas Caswell
>> tca...@gm...
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
-- 
Thomas Caswell
tca...@gm...

At any rate, I have a PR (#2930) that should make it pass cleanly again.
On the bright side, it looks like one of the changes is 1.5 is that
long unbreakable lines will get ignored by E501 so urls are safe
again.
On Wed, Mar 26, 2014 at 6:10 PM, Paul Ivanov <pi...@be...> wrote:
> Nelle Varoquaux, on 2014年03月26日 21:27, wrote:
>> > Does anyone know why we are seeing a huge number of PEP 8 failures now?
>> > It looks to me like it is a change in which modules are subject to the
>> > test, or in which tests are grounds for failure. I don't know how all
>> > this is set up, though.
>>
>> If it started very recently, it could be linked to the new release. They
>> have started to make "none backward" compatible version, in the sense that
>> the stylechecker is increasingly strict. It is very annoying...
>
> Can we not revisit (and possibly revert) the morally absolutist
> PEP-8 or death position that matplotlib has taken?
>
> Quoting GvR (emphasis mine):
>
> All I want to say is, people lighten up. The style guide
> can't solve all your problems. You are never going to have
> all code compliant. Use the style guide when it helps, *ignore
> it when it's in the way*
>
> And from that same email:
>
> Let's try to make new stdlib modules use the best style we
> can think of, but limit the time spent fretting over code
> that's already there.
>
>
> The rest of the message is useful to read:
> https://mail.python.org/pipermail/python-dev/2010-November/105681.html
>
> Another reason for not being so rigid about PEP-8 is that its a
> living document. Are we really doing massive search-and-replace
> changes to the codebase just to comply with a moving target?
>
> best,
> --
> _
> / \
> A* \^ -
> ,./ _.`\\ / \
> / ,--.S \/ \
> / `"~,_ \ \
> __o ?
> _ \<,_ /:\
> --(_)/-(_)----.../ | \
> --------------.......J
> Paul Ivanov
> http://pirsquared.org
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Thomas Caswell
tca...@gm...

Nelle Varoquaux, on 2014年03月26日 21:27, wrote:
> > Does anyone know why we are seeing a huge number of PEP 8 failures now?
> > It looks to me like it is a change in which modules are subject to the
> > test, or in which tests are grounds for failure. I don't know how all
> > this is set up, though.
> 
> If it started very recently, it could be linked to the new release. They
> have started to make "none backward" compatible version, in the sense that
> the stylechecker is increasingly strict. It is very annoying...
Can we not revisit (and possibly revert) the morally absolutist
PEP-8 or death position that matplotlib has taken?
Quoting GvR (emphasis mine):
 All I want to say is, people lighten up. The style guide
 can't solve all your problems. You are never going to have
 all code compliant. Use the style guide when it helps, *ignore
 it when it's in the way*
And from that same email:
 Let's try to make new stdlib modules use the best style we
 can think of, but limit the time spent fretting over code
 that's already there.
 
The rest of the message is useful to read:
https://mail.python.org/pipermail/python-dev/2010-November/105681.html
Another reason for not being so rigid about PEP-8 is that its a
living document. Are we really doing massive search-and-replace
changes to the codebase just to comply with a moving target?
best,
-- 
 _
 / \
 A* \^ -
 ,./ _.`\\ / \
 / ,--.S \/ \
 / `"~,_ \ \
 __o ?
 _ \<,_ /:\
--(_)/-(_)----.../ | \
--------------.......J
Paul Ivanov
http://pirsquared.org

> Does anyone know why we are seeing a huge number of PEP 8 failures now?
> It looks to me like it is a change in which modules are subject to the
> test, or in which tests are grounds for failure. I don't know how all
> this is set up, though.
>
If it started very recently, it could be linked to the new release. They
have started to make "none backward" compatible version, in the sense that
the stylechecker is increasingly strict. It is very annoying...
>
> Eric
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Does anyone know why we are seeing a huge number of PEP 8 failures now? 
 It looks to me like it is a change in which modules are subject to the 
test, or in which tests are grounds for failure. I don't know how all 
this is set up, though.
Eric

Hi,
I've built and tested some binary wheels for OSX - available here:
https://nipy.bic.berkeley.edu/scipy_installers/
I'd really like to upload these to pypi so that people get them by
default with 'pip install matplotlb'. Is that OK? Can someone give
me permission to do that?
Thanks a lot,
Matthew

Hi,
On Mon, Mar 24, 2014 at 6:29 AM, Benjamin Root <ben...@ou...> wrote:
> I thought we fixed this one...
>
> Seems like we haven't as there is an open issue for it:
> https://github.com/matplotlib/matplotlib/issues/2842
Sorry - I didn't say - but the wheels are for the 1.3.1 release...
Cheers,
Matthew

Hi,
Working on mpld3, I've hit something I don't quite know how to handle. I'm
trying to render legend components in d3, and the strange thing is that
markers within the legend have empty paths. Consider the script below:
#------------------------------------------------------
import matplotlib.pyplot as plt
fig, ax = plt.subplots()
line, = ax.plot(range(5), range(5), 'o', label='dots')
ax.legend()
print("here is the marker as it appears in the plot:")
print(line._marker.get_path())
leg = ax.get_legend()
children = leg.get_children()
print("here is the marker as it appears in the legend")
print(children[1]._marker.get_path())
#------------------------------------------------------
On the plot itself, the marker is a circle. On the legend, the marker is an
empty path. I've tried poking around in the backend code to figure out how
the renderers know what path to use when drawing the legend, but the answer
is not obvious to me.
Does anyone have insight into what special magic happens here when the
legend is rendered? Thanks,
 Jake
 Jake VanderPlas
 Director of Research - Physical Sciences
 eScience Institute, University of Washington
 http://www.vanderplas.com

Wow. Thanks so much, Stan! This is a huge help and works just as I need it
to.
Much appreciated!
On Mon, Mar 24, 2014 at 11:26 AM, Stan West <sta...@nr...> wrote:
> On 2014年03月24日 14:08, Stan West wrote:
>
> May I suggest that you look at the mailing list thread from that time [1],
> try the patch in the thread, and see whether your issue is resolved? This
> solution doesn't provide a work-around in your code, but it may fix the
> problem at the root.
>
> Paul, I just found the work-around that I used in my code. Define the
> following function:
>
> def set_spine_position(spine, position):
> """
> Set the spine's position without resetting an associated axis.
>
> As of matplotlib v. 1.0.0, if a spine has an associated axis, then
> spine.set_position() calls axis.cla(), which resets locators, formatters,
> etc. We temporarily replace that call with axis.reset_ticks(), which is
> sufficient for our purposes.
> """
> axis = spine.axis
> if axis is not None:
> cla = axis.cla
> axis.cla = axis.reset_ticks
> spine.set_position(position)
> if axis is not None:
> axis.cla = cla
>
> (The mention of v. 1.0.0 in the docstring is just the version I was using
> at the time, not necessarily the earliest version with this issue.) Then
> replace method calls like "spine.set_position(pos)" with the function call
> "set_spine_position(spine, pos)". I hope this helps.
>

On 2014年02月05日 02:26, Paul Hobson wrote:
> I noticed that when you offset the spines of an Axes object, the 
> labels, ticks, and ticklabels/formatting get mostly cleared. Is this 
> intentional and is there a way to prevent (or undo) it?
[...]
Paul, I may have encountered the same issue a few years ago. May I 
suggest that you look at the mailing list thread from that time [1], try 
the patch in the thread, and see whether your issue is resolved? This 
solution doesn't provide a work-around in your code, but it may fix the 
problem at the root. I took a brief look at the current state of 
spines.py, and I found only the same instances of "self.axis.cla()" that 
the patch changes to "self.axis.reset_ticks()".
Kind regards,
Stan
[1] 
http://matplotlib.1069221.n5.nabble.com/Spine-set-position-unexpectedly-clears-axis-td37865.html, 
29 Sep. 2010.

On 2014年03月24日 14:08, Stan West wrote:
> May I suggest that you look at the mailing list thread from that time 
> [1], try the patch in the thread, and see whether your issue is 
> resolved? This solution doesn't provide a work-around in your code, 
> but it may fix the problem at the root.
Paul, I just found the work-around that I used in my code. Define the 
following function:
 def set_spine_position(spine, position):
 """
 Set the spine's position without resetting an associated axis.
 
 As of matplotlib v. 1.0.0, if a spine has an associated axis, then
 spine.set_position() calls axis.cla(), which resets locators, formatters,
 etc. We temporarily replace that call with axis.reset_ticks(), which is
 sufficient for our purposes.
 """
 axis = spine.axis
 if axis is not None:
 cla = axis.cla
 axis.cla = axis.reset_ticks
 spine.set_position(position)
 if axis is not None:
 axis.cla = cla
(The mention of v. 1.0.0 in the docstring is just the version I was 
using at the time, not necessarily the earliest version with this 
issue.) Then replace method calls like "spine.set_position(pos)" with 
the function call "set_spine_position(spine, pos)". I hope this helps.

Hello all,
I currently have 14 open PR's (most of which have an associated
issue). If these could get reviewed/merged it would go along way to
cutting down the number of outstanding issues we have to get through
before we can cut 1.4.0
https://github.com/matplotlib/matplotlib/issues/created_by/tacaswell?direction=desc&labels=needs_review&milestone=10&page=1&sort=created&state=open
https://github.com/matplotlib/matplotlib/issues/created_by/tacaswell?direction=desc&labels=needs_review&milestone=9&page=1&sort=created&state=open
https://github.com/matplotlib/matplotlib/issues/created_by/tacaswell?direction=desc&labels=needs_review&milestone=7&page=1&sort=created&state=open
Tom
-- 
Thomas Caswell
tca...@gm...

I thought we fixed this one...
Seems like we haven't as there is an open issue for it:
https://github.com/matplotlib/matplotlib/issues/2842
On Sun, Mar 23, 2014 at 7:07 AM, Matthew Brett <mat...@gm...>wrote:
> Hi,
>
> On Sun, Mar 23, 2014 at 1:46 AM, Matthew Brett <mat...@gm...>
> wrote:
> > Hi,
> >
> > On Sat, Dec 14, 2013 at 12:28 PM, Matthew Brett <mat...@gm...>
> wrote:
> >> Hi,
> >>
> >> Prompted by Chris B, I just added matplotlib wheels building to the
> >> framework here:
> >>
> >> https://github.com/matthew-brett/mpl-osx-binaries
> >>
> >> Instructions for build in the README.
> >>
> >> Sorry - am In Cuba at the moment with very low internet bandwidth and
> >> can't upload the wheels, but they should be simple to build (or I
> >> messed up with the instructions),
> >
> > Following up on this one - I have built OSX wheels for python 2.7, 3.3
> > and 3.4 here:
> >
> > https://nipy.bic.berkeley.edu/scipy_installers/
> >
> > You should now be able to do:
> >
> > # upgrade to latest pip
> > pip install --upgrade pip
> > # get fully binary install of matplotlib
> > pip install --find-links=https://nipy.bic.berkeley.edu/scipy_installers
> > matplotlib
> >
> > I've tested on a bare 10.6 machine for Python 2.7, will test for 3.3
> > and 3.4 - but - could y'all give the installation a try and see if it
> > works for you? It will work as well into a virtualenv. There are
> > also numpy wheels there so you can get the full stack with that
> > command.
>
> Yes, they seem to work on bare 10.6 on all three python versions. I
> got one failure on python 3.4 but it didn't look related to the wheel:
>
> ======================================================================
> FAIL: matplotlib.tests.test_basic.test_override_builtins
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/nose/case.py",
> line 198, in runTest
> self.test(*self.arg)
> File
> "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/matplotlib/tests/test_basic.py",
> line 38, in test_override_builtins
> assert not overridden
> nose.proxy.AssertionError:
> -------------------- >> begin captured stdout << ---------------------
> '__spec__' was overridden in globals().
>
> --------------------- >> end captured stdout << ----------------------
>
> Cheers,
>
> Matthew
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi,
On Sun, Mar 23, 2014 at 1:46 AM, Matthew Brett <mat...@gm...> wrote:
> Hi,
>
> On Sat, Dec 14, 2013 at 12:28 PM, Matthew Brett <mat...@gm...> wrote:
>> Hi,
>>
>> Prompted by Chris B, I just added matplotlib wheels building to the
>> framework here:
>>
>> https://github.com/matthew-brett/mpl-osx-binaries
>>
>> Instructions for build in the README.
>>
>> Sorry - am In Cuba at the moment with very low internet bandwidth and
>> can't upload the wheels, but they should be simple to build (or I
>> messed up with the instructions),
>
> Following up on this one - I have built OSX wheels for python 2.7, 3.3
> and 3.4 here:
>
> https://nipy.bic.berkeley.edu/scipy_installers/
>
> You should now be able to do:
>
> # upgrade to latest pip
> pip install --upgrade pip
> # get fully binary install of matplotlib
> pip install --find-links=https://nipy.bic.berkeley.edu/scipy_installers
> matplotlib
>
> I've tested on a bare 10.6 machine for Python 2.7, will test for 3.3
> and 3.4 - but - could y'all give the installation a try and see if it
> works for you? It will work as well into a virtualenv. There are
> also numpy wheels there so you can get the full stack with that
> command.
Yes, they seem to work on bare 10.6 on all three python versions. I
got one failure on python 3.4 but it didn't look related to the wheel:
======================================================================
FAIL: matplotlib.tests.test_basic.test_override_builtins
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/nose/case.py",
line 198, in runTest
 self.test(*self.arg)
 File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/matplotlib/tests/test_basic.py",
line 38, in test_override_builtins
 assert not overridden
nose.proxy.AssertionError:
-------------------- >> begin captured stdout << ---------------------
'__spec__' was overridden in globals().
--------------------- >> end captured stdout << ----------------------
Cheers,
Matthew

Hi,
On Sat, Dec 14, 2013 at 12:28 PM, Matthew Brett <mat...@gm...> wrote:
> Hi,
>
> Prompted by Chris B, I just added matplotlib wheels building to the
> framework here:
>
> https://github.com/matthew-brett/mpl-osx-binaries
>
> Instructions for build in the README.
>
> Sorry - am In Cuba at the moment with very low internet bandwidth and
> can't upload the wheels, but they should be simple to build (or I
> messed up with the instructions),
Following up on this one - I have built OSX wheels for python 2.7, 3.3
and 3.4 here:
https://nipy.bic.berkeley.edu/scipy_installers/
You should now be able to do:
# upgrade to latest pip
pip install --upgrade pip
# get fully binary install of matplotlib
pip install --find-links=https://nipy.bic.berkeley.edu/scipy_installers
matplotlib
I've tested on a bare 10.6 machine for Python 2.7, will test for 3.3
and 3.4 - but - could y'all give the installation a try and see if it
works for you? It will work as well into a virtualenv. There are
also numpy wheels there so you can get the full stack with that
command.
These wheels are only for OSX I'm afraid - I'm no expert in windows builds.
Cheers,
Matthew

Turns out I had turned off the deprecated Numpy API a year or so ago after I
updated Numpy. By removing my definition of the non deprecated Numpy Version
at the end of my ndarraytypes.h file, I was able to get the git version of
matplotlib to compile and install successfully.
Hope this helps anyone else seeing similar errors.
-Greg
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/build-failure-in-v1-2-x-branch-tp39933p43096.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Hi all,
I'm trying to build matplotlib 1.3.1 from source on a Windows 8.1 machine
via Cygwin. It seems I'm gettting similar errors to what Ben was above:
In file included from src/file_compat.h:7:0,
 from src/ft2font.cpp:7:
src/ft2font.cpp: In member function ‘Py::Object FT2Image::py_as_array(const
Py::Tuple&)’:
src/ft2font.cpp:397:83: error: ‘PyArray_UBYTE’ was not declared in this
scope
 PyArrayObject *A = (PyArrayObject *) PyArray_SimpleNewFromData(2,
dimensions, PyArray_UBYTE, _buffer);
Is there any other possible explanations for this issue? I'm using Numpy
1.7.2.
Thanks,
Greg
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/build-failure-in-v1-2-x-branch-tp39933p43087.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Michael,
 I'm using matplotlib-1.3.1, and as mentioned above I manually set
PKG_CONFIG_PATH prior to running to ensure the dependencies are found.
The initial output from the matplotlib build shows that it is finding the
2.5.2 version
i.e. output from
python setup.py build is
freetype: yes [version 17.1.11]
Cheers,
--Jim
On Wed, Mar 12, 2014 at 8:54 AM, Michael Droettboom <md...@st...> wrote:
> What version of matplotlib are you using? The present behavior is
> (supposed to) only use freetype-config if pkg-config isn't available on the
> path.
>
> https://github.com/matplotlib/matplotlib/pull/1941
>
> Mike
>
>
> On 03/11/2014 05:00 PM, Jim Parker wrote:
>
> All,
> I needed to install matplotlib from source along with all dependencies,
> and I found a "gotcha" related to how setupext.py discovers freetype2
> dependencies.
>
> The default is to use
> freetype-config --version
>
> which uses a custom binary provided by freetype to list the version
> number and linker dependencies. Versions 2.4 and 2.5 of freetype use
> pkg-config to also provide this information but matplotlib skips it.
>
> setting
> PKG_CONFIG_PATH=<path-to-custom-dependency>
>
> or using setup.cfg
>
> basedirlist=<path-to-custom-dependency>
>
> will not fix the problem if your PATH variable points to the
> freetype-config binary in your system path first.
>
> If freetype-config is no longer necessary for matplotlib to compile, I
> would recommend using pkg-config to get the linker and compiler flags, so
> that typical end-user fixes to paths will work as desired.
>
> BTW, a clean install of freetype.2.5.2 will not compile with matplotlib
> without including a soft link
> ln -s <include-dir>/freetype2 <include-dir>/freetype
>
> I think this a problem with the freetype package. They have references
> to changes in the structure of their includes in version 2.5.1.
>
> Cheers,
> --Jim
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!http://p.sf.net/sfu/13534_NeoTech
>
>
>
> _______________________________________________
> Matplotlib-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> --
> _
> |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
> | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
> http://www.droettboom.com
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

What version of matplotlib are you using? The present behavior is 
(supposed to) only use freetype-config if pkg-config isn't available on 
the path.
https://github.com/matplotlib/matplotlib/pull/1941
Mike
On 03/11/2014 05:00 PM, Jim Parker wrote:
> All,
> I needed to install matplotlib from source along with all 
> dependencies, and I found a "gotcha" related to how setupext.py 
> discovers freetype2 dependencies.
>
> The default is to use
> freetype-config --version
>
> which uses a custom binary provided by freetype to list the version 
> number and linker dependencies. Versions 2.4 and 2.5 of freetype use 
> pkg-config to also provide this information but matplotlib skips it.
>
> setting
> PKG_CONFIG_PATH=<path-to-custom-dependency>
>
> or using setup.cfg
>
> basedirlist=<path-to-custom-dependency>
>
> will not fix the problem if your PATH variable points to the 
> freetype-config binary in your system path first.
>
> If freetype-config is no longer necessary for matplotlib to compile, I 
> would recommend using pkg-config to get the linker and compiler 
> flags, so that typical end-user fixes to paths will work as desired.
>
> BTW, a clean install of freetype.2.5.2 will not compile with 
> matplotlib without including a soft link
> ln -s <include-dir>/freetype2 <include-dir>/freetype
>
> I think this a problem with the freetype package. They have 
> references to changes in the structure of their includes in version 2.5.1.
>
> Cheers,
> --Jim
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com

All,
 I needed to install matplotlib from source along with all dependencies,
and I found a "gotcha" related to how setupext.py discovers freetype2
dependencies.
The default is to use
freetype-config --version
which uses a custom binary provided by freetype to list the version number
and linker dependencies. Versions 2.4 and 2.5 of freetype use pkg-config
to also provide this information but matplotlib skips it.
setting
PKG_CONFIG_PATH=<path-to-custom-dependency>
or using setup.cfg
basedirlist=<path-to-custom-dependency>
will not fix the problem if your PATH variable points to the
freetype-config binary in your system path first.
If freetype-config is no longer necessary for matplotlib to compile, I
would recommend using pkg-config to get the linker and compiler flags, so
that typical end-user fixes to paths will work as desired.
BTW, a clean install of freetype.2.5.2 will not compile with matplotlib
without including a soft link
ln -s <include-dir>/freetype2 <include-dir>/freetype
I think this a problem with the freetype package. They have references to
changes in the structure of their includes in version 2.5.1.
Cheers,
--Jim

I think we can be flexible about whether it's before or after the 
conference based on who is coming and their availability.
On 03/06/2014 04:33 PM, Benjamin Root wrote:
> I am awaiting approval from my superiors to pay for me to go this 
> year. I plan to split out my Anatomy of Matplotlib tutorial into two 
> levels. If that works out and both tutorials get accepted, then I 
> would imagine that I could spend an extra day. Would this extra day be 
> before or after the week of the conference?
>
> Ben Root
>
>
> On Thu, Mar 6, 2014 at 12:49 PM, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
>
> On 2014年02月27日 6:28 AM, Michael Droettboom wrote:
> > How many matplotlib developers are planning to attend SciPy this
> year?
>
> Most likely I will not.
>
> Eric
>
> >
> > If we used some of our funds to support an extra hotel night,
> would any
> > of you be interested in spending an extra day for a "matplotlib
> > developer summit" to discuss matplotlib projects? This would be in
> > addition to the sprints, which I see probably being a larger
> group. Your
> > response isn't a committment at this point, I'm just trying to
> gauge how
> > much interest there might be.
> >
> > Mike
> >
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move
> to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually
> works.
> Faster operations. Version large binaries. Built-in WAN
> optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com

On Mar 6, 2014 10:24 PM, "Skip Montanaro" <sk...@po...> wrote:
>
> On Thu, Mar 6, 2014 at 3:13 PM, Nelle Varoquaux
> <nel...@gm...> wrote:
> > If I need to understand what exactly os.stat returns, I just read the
> > documentation, and not rely on some possibly misleading variable
> > names.
>
> Despite our wish that it wasn't so, it is likely that there is far
> more undocumented than documented code out in the wild, or behind
> firewalls where we can't see it. I just used os.stat as an example of
> a well-known function that returns multiple values. (Precisely, so
> people wouldn't have to run to the documentation or that I would have
> to provide a more-fleshed-out example.) In my experience, there's no
> real need to be intentionally obscure by not giving a variable a
> meaningful, whether or not you intend/expect to use it. Besides, open
> source code can serve as a living example of good coding practices.
> Might as well do our best in that regard.
>
> Just sayin'...
>
> Skip
Whether it is necessarily the optimal choice, I think there is something to
be said for following established conventions. Besides the fact that IDEs
complain if you don't, it makes it easier for outside contributors to
understand what it's going on.

I'm hoping to return to more active status with a change in jobs now and
finally finishing off the thesis.
I should be at SciPy and would very much be interested in sticking around
to discuss development. (Though I should probably make sure the job will
pay for me to stick around for the sprints...)
Ryan
On Thu, Mar 6, 2014 at 2:33 PM, Benjamin Root <ben...@ou...> wrote:
> I am awaiting approval from my superiors to pay for me to go this year. I
> plan to split out my Anatomy of Matplotlib tutorial into two levels. If
> that works out and both tutorials get accepted, then I would imagine that I
> could spend an extra day. Would this extra day be before or after the week
> of the conference?
>
> Ben Root
>
>
> On Thu, Mar 6, 2014 at 12:49 PM, Eric Firing <ef...@ha...> wrote:
>
>> On 2014年02月27日 6:28 AM, Michael Droettboom wrote:
>> > How many matplotlib developers are planning to attend SciPy this year?
>>
>> Most likely I will not.
>>
>> Eric
>>
>> >
>> > If we used some of our funds to support an extra hotel night, would any
>> > of you be interested in spending an extra day for a "matplotlib
>> > developer summit" to discuss matplotlib projects? This would be in
>> > addition to the sprints, which I see probably being a larger group. Your
>> > response isn't a committment at this point, I'm just trying to gauge how
>> > much interest there might be.
>> >
>> > Mike
>> >
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Subversion Kills Productivity. Get off Subversion & Make the Move to
>> Perforce.
>> With Perforce, you get hassle-free workflows. Merge that actually works.
>> Faster operations. Version large binaries. Built-in WAN optimization and
>> the
>> freedom to use Git, Perforce or both. Make the move to Perforce.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Thu, Mar 6, 2014 at 3:58 PM, Chris Barker <chr...@no...> wrote:
> it looks like pylint, anyway, will accept that.
Yes, pylint used to only accept a leading underscore by default as a
flag that a variable was unused. When I switched from pychecker to
pylint a few years ago, all my carefully crafted "unused_" variables
got flagged by pylint. I suggested adding that as another default
prefix, and they agreed.
Skip

On Thu, Mar 6, 2014 at 1:23 PM, Skip Montanaro <sk...@po...> wrote:
> Despite our wish that it wasn't so, it is likely that there is far
> more undocumented than documented code out in the wild, or behind
> firewalls where we can't see it.
Well, then you're hosed anyway -- relying on the name of an unused variable
using a call for your docs is, shall we say not very robust.
In my experience, there's no
> real need to be intentionally obscure by not giving a variable a
> meaningful, whether or not you intend/expect to use it. Besides, open
> source code can serve as a living example of good coding practices.
> Might as well do our best in that regard.
>
then use "unused_meaningful_name"
it looks like pylint, anyway, will accept that.
Or is the goal here to come to a consensus for MPL style?
If so, I'm +1 on "_", and -0 on unused_meaningful_name
-Chris
>
> Just sayin'...
>
> Skip
>
>
> ------------------------------------------------------------------------------
> Subversion Kills Productivity. Get off Subversion & Make the Move to
> Perforce.
> With Perforce, you get hassle-free workflows. Merge that actually works.
> Faster operations. Version large binaries. Built-in WAN optimization and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
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...