matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] numpy indexing changes

[Nathaniel S. <nj...@po...>]

On 10 Jun 2014 19:07, "Eric Firing" <ef...@ha...> wrote:
>
> This is just a heads-up: some indexing changes in the numpy 1.9rc break
> matplotlib, as revealed in the mpl tests; there is a discussion on the
> numpy-discussion list about what to do about it.  It looks like they
> will back off on the changes and put in deprecations, giving us time to
> modify mpl.

Yes, and please do test the numpy betas/RCs - we're trying to do a better
job at not breaking downstreams on every release, but it's easy for us to
miss breakages, or to think we've fixed something in the second beta but be
wrong about this. If you notice *anything* broken by the betas then please
at least let us know (even if the code is easy to fix on tour end), and
when doing so please use the magic word "regression" so that we can assign
it appropriate priority.

-n

[matplotlib-devel] numpy indexing changes

[Eric F. <ef...@ha...>]

This is just a heads-up: some indexing changes in the numpy 1.9rc break 
matplotlib, as revealed in the mpl tests; there is a discussion on the 
numpy-discussion list about what to do about it.  It looks like they 
will back off on the changes and put in deprecations, giving us time to 
modify mpl.  I don't think the required modifications will be extensive, 
intrusive, or difficult in the least.

Somewhat related, I have been noticing warnings in the tests coming from 
some masked array usage, and maybe other things.  It would be nice to 
get everything cleaned up, and see the tests fly by with no warnings.  I 
don't have time to work on it now, though.  If you have been thinking 
you would like to help out, but haven't taken the plunge yet, this would 
be a good way to get started.

Eric

[matplotlib-devel] Add a cookbook doc repo to github?

[Eric F. <ef...@ha...>]

Documentation is critical for helping people use mpl effectively (or at 
all).  Our core documentation has many shortcomings, and needs much more 
attention than it gets.  But that's another topic.

This message is prompted by 
https://github.com/matplotlib/matplotlib/pull/3088, which has led to the 
suggestion that we make a separate repo for documenting examples that 
might be too elaborate or specialized to go in the core, but that can be 
more visible, more effective, and better-maintained if they are kept in 
another repo in our github account.  They could then be published 
automatically using readthedocs.org.

The primary alternatives here are:

1) Continue with PR 3088 as-is, and encourage other such additions to 
the core docs.

2) Redirect such contributions to http://wiki.scipy.org/Cookbook/Matplotlib.

3) Start a new repo on our github account, as suggested above.

The advantage of (1) is that it keeps everything together; the 
disadvantage is that it makes the central mpl repo even more sprawling 
and harder to coordinate for releases.

The advantage of (2) is that it already exists, and its wiki interface 
might make contributions and updates easier.  The disadvantage is that 
it doesn't seem to get much maintenance, and it's wiki format is not as 
nice as full Sphinx docs.

The advantage of (3) is that it encourages expansion of documentation 
that can proceed independently of the core release schedule, and without 
bloating the core.

With either (2) or (3), our core docs should point to the Cookbook location.

The key to making any of these options work well is participation; we 
need people to keep working on improvements.

Eric

Re: [matplotlib-devel] Developer summit at Scipy?

[Damon M. <dam...@gm...>]

s/when/if/g

On Thu, Jun 5, 2014 at 3:34 PM, Damon McDougall
<dam...@gm...> wrote:
> No worries, I've submitted the proposal.  I'll let everyone know when
> it gets accepted.
>
> On Thu, Jun 5, 2014 at 11:47 AM, Michael Droettboom <md...@st...> wrote:
>> Agreed.  Sounds good.  Thanks, Damon.
>>
>> Mike
>>
>>
>> On 06/04/2014 11:44 AM, Benjamin Root wrote:
>>
>> Yes please. Last year's BoF was well-attended. I would expect nothing less
>> this year.
>>
>> Ben
>>
>>
>> On Wed, Jun 4, 2014 at 10:39 AM, Damon McDougall <dam...@gm...>
>> wrote:
>>>
>>> Shall I go ahead and set up a MEP bof?  Just got an email for a call
>>> for BoFs which reminded me to ask.
>>>
>>> On Mon, Jun 2, 2014 at 2:15 PM, Benjamin Root <ben...@ou...> wrote:
>>> > That is unfortunate that we can't have a summit before/after SciPy 2014.
>>> > I
>>> > have also booked my flights and hotel, and the only time I would have to
>>> > fit
>>> > a "summit" outside of SciPy 2014 would be Saturday, July 5th in the
>>> > evening.
>>> >
>>> > I will be there, though, for the entire conference (including both
>>> > sprint
>>> > days). Perhaps we can have a somewhat formalized Birds-of-a-feather
>>> > session?
>>> > Maybe with a discussion panel and some short presentations on our
>>> > visions
>>> > for future matplotlib development?
>>> >
>>> > Ben Root
>>> >
>>> >
>>> >
>>> > On Fri, May 30, 2014 at 9:35 AM, Michael Droettboom <md...@st...>
>>> > wrote:
>>> >>
>>> >> Hello all,
>>> >>
>>> >> Sorry to be writing this at this late point, but I've been hoping I
>>> >> could find a way around it.  I won't be able to attend an extra day at
>>> >> either end of Scipy year, both due to personal commitments and new
>>> >> funding constraints at NASA.  I do plan to attend/host the matplotlib
>>> >> sprint again, however, which is not a bad opportunity to catch up on
>>> >> some of these issues.
>>> >>
>>> >> So, an extra developer summit day is still possible if someone else is
>>> >> able to organize it -- I just, unfortunately, won't be able to attend.
>>> >> We can still use the matplotlib donated funds to cover the cost of the
>>> >> extra hotel night (assuming the numbers of people wanting to do that is
>>> >> not too large) and meeting space (if the cost is not too high, though
>>> >> maybe locals like Damon have a connection for free and/or cheap space).
>>> >> For reimbursement, I would need a receipt for that hotel night (ideally
>>> >> with that one night broken out individually), which will then be
>>> >> submitted to numfocus, who will reimburse you directly.
>>> >>
>>> >> Sorry to be uncommunicative on this (and uncommunicative in general
>>> >> lately).  I hope something can still work out at this late date!
>>> >>
>>> >> Mike
>>> >>
>>> >> On 02/27/2014 11:28 AM, Michael Droettboom wrote:
>>> >> > How many matplotlib developers are planning to attend SciPy this
>>> >> > year?
>>> >> >
>>> >> > 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
>>> >> >
>>> >>
>>> >>
>>> >> --
>>> >> Michael Droettboom
>>> >> Science Software Branch
>>> >> Space Telescope Science Institute
>>> >>
>>> >> http://www.droettboom.com
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> ------------------------------------------------------------------------------
>>> >> Time is money. Stop wasting it! Get your web API in 5 minutes.
>>> >> www.restlet.com/download
>>> >> http://p.sf.net/sfu/restlet
>>> >> _______________________________________________
>>> >> Matplotlib-devel mailing list
>>> >> Mat...@li...
>>> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>> >
>>> >
>>> >
>>> >
>>> > ------------------------------------------------------------------------------
>>> > 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/NeoTech
>>> > _______________________________________________
>>> > Matplotlib-devel mailing list
>>> > Mat...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>> >
>>>
>>>
>>>
>>> --
>>> Damon McDougall
>>> http://www.damon-is-a-geek.com
>>> Institute for Computational Engineering Sciences
>>> 201 E. 24th St.
>>> Stop C0200
>>> The University of Texas at Austin
>>> Austin, TX 78712-1229
>>
>>
>>
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Space Telescope Science Institute
>>
>> http://www.droettboom.com
>
>
>
> --
> Damon McDougall
> http://www.damon-is-a-geek.com
> Institute for Computational Engineering Sciences
> 201 E. 24th St.
> Stop C0200
> The University of Texas at Austin
> Austin, TX 78712-1229



-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

Re: [matplotlib-devel] Developer summit at Scipy?

[Damon M. <dam...@gm...>]

No worries, I've submitted the proposal.  I'll let everyone know when
it gets accepted.

On Thu, Jun 5, 2014 at 11:47 AM, Michael Droettboom <md...@st...> wrote:
> Agreed.  Sounds good.  Thanks, Damon.
>
> Mike
>
>
> On 06/04/2014 11:44 AM, Benjamin Root wrote:
>
> Yes please. Last year's BoF was well-attended. I would expect nothing less
> this year.
>
> Ben
>
>
> On Wed, Jun 4, 2014 at 10:39 AM, Damon McDougall <dam...@gm...>
> wrote:
>>
>> Shall I go ahead and set up a MEP bof?  Just got an email for a call
>> for BoFs which reminded me to ask.
>>
>> On Mon, Jun 2, 2014 at 2:15 PM, Benjamin Root <ben...@ou...> wrote:
>> > That is unfortunate that we can't have a summit before/after SciPy 2014.
>> > I
>> > have also booked my flights and hotel, and the only time I would have to
>> > fit
>> > a "summit" outside of SciPy 2014 would be Saturday, July 5th in the
>> > evening.
>> >
>> > I will be there, though, for the entire conference (including both
>> > sprint
>> > days). Perhaps we can have a somewhat formalized Birds-of-a-feather
>> > session?
>> > Maybe with a discussion panel and some short presentations on our
>> > visions
>> > for future matplotlib development?
>> >
>> > Ben Root
>> >
>> >
>> >
>> > On Fri, May 30, 2014 at 9:35 AM, Michael Droettboom <md...@st...>
>> > wrote:
>> >>
>> >> Hello all,
>> >>
>> >> Sorry to be writing this at this late point, but I've been hoping I
>> >> could find a way around it.  I won't be able to attend an extra day at
>> >> either end of Scipy year, both due to personal commitments and new
>> >> funding constraints at NASA.  I do plan to attend/host the matplotlib
>> >> sprint again, however, which is not a bad opportunity to catch up on
>> >> some of these issues.
>> >>
>> >> So, an extra developer summit day is still possible if someone else is
>> >> able to organize it -- I just, unfortunately, won't be able to attend.
>> >> We can still use the matplotlib donated funds to cover the cost of the
>> >> extra hotel night (assuming the numbers of people wanting to do that is
>> >> not too large) and meeting space (if the cost is not too high, though
>> >> maybe locals like Damon have a connection for free and/or cheap space).
>> >> For reimbursement, I would need a receipt for that hotel night (ideally
>> >> with that one night broken out individually), which will then be
>> >> submitted to numfocus, who will reimburse you directly.
>> >>
>> >> Sorry to be uncommunicative on this (and uncommunicative in general
>> >> lately).  I hope something can still work out at this late date!
>> >>
>> >> Mike
>> >>
>> >> On 02/27/2014 11:28 AM, Michael Droettboom wrote:
>> >> > How many matplotlib developers are planning to attend SciPy this
>> >> > year?
>> >> >
>> >> > 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
>> >> >
>> >>
>> >>
>> >> --
>> >> Michael Droettboom
>> >> Science Software Branch
>> >> Space Telescope Science Institute
>> >>
>> >> http://www.droettboom.com
>> >>
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Time is money. Stop wasting it! Get your web API in 5 minutes.
>> >> www.restlet.com/download
>> >> http://p.sf.net/sfu/restlet
>> >> _______________________________________________
>> >> Matplotlib-devel mailing list
>> >> Mat...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > 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/NeoTech
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >
>>
>>
>>
>> --
>> Damon McDougall
>> http://www.damon-is-a-geek.com
>> Institute for Computational Engineering Sciences
>> 201 E. 24th St.
>> Stop C0200
>> The University of Texas at Austin
>> Austin, TX 78712-1229
>
>
>
>
> --
> Michael Droettboom
> Science Software Branch
> Space Telescope Science Institute
>
> http://www.droettboom.com



-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

Re: [matplotlib-devel] Developer summit at Scipy?

[Michael D. <md...@st...>]

Agreed.  Sounds good.  Thanks, Damon.

Mike

On 06/04/2014 11:44 AM, Benjamin Root wrote:
> Yes please. Last year's BoF was well-attended. I would expect nothing 
> less this year.
>
> Ben
>
>
> On Wed, Jun 4, 2014 at 10:39 AM, Damon McDougall 
> <dam...@gm... <mailto:dam...@gm...>> wrote:
>
>     Shall I go ahead and set up a MEP bof?  Just got an email for a call
>     for BoFs which reminded me to ask.
>
>     On Mon, Jun 2, 2014 at 2:15 PM, Benjamin Root <ben...@ou...
>     <mailto:ben...@ou...>> wrote:
>     > That is unfortunate that we can't have a summit before/after
>     SciPy 2014. I
>     > have also booked my flights and hotel, and the only time I would
>     have to fit
>     > a "summit" outside of SciPy 2014 would be Saturday, July 5th in
>     the evening.
>     >
>     > I will be there, though, for the entire conference (including
>     both sprint
>     > days). Perhaps we can have a somewhat formalized
>     Birds-of-a-feather session?
>     > Maybe with a discussion panel and some short presentations on
>     our visions
>     > for future matplotlib development?
>     >
>     > Ben Root
>     >
>     >
>     >
>     > On Fri, May 30, 2014 at 9:35 AM, Michael Droettboom
>     <md...@st... <mailto:md...@st...>> wrote:
>     >>
>     >> Hello all,
>     >>
>     >> Sorry to be writing this at this late point, but I've been hoping I
>     >> could find a way around it.  I won't be able to attend an extra
>     day at
>     >> either end of Scipy year, both due to personal commitments and new
>     >> funding constraints at NASA.  I do plan to attend/host the
>     matplotlib
>     >> sprint again, however, which is not a bad opportunity to catch
>     up on
>     >> some of these issues.
>     >>
>     >> So, an extra developer summit day is still possible if someone
>     else is
>     >> able to organize it -- I just, unfortunately, won't be able to
>     attend.
>     >> We can still use the matplotlib donated funds to cover the cost
>     of the
>     >> extra hotel night (assuming the numbers of people wanting to do
>     that is
>     >> not too large) and meeting space (if the cost is not too high,
>     though
>     >> maybe locals like Damon have a connection for free and/or cheap
>     space).
>     >> For reimbursement, I would need a receipt for that hotel night
>     (ideally
>     >> with that one night broken out individually), which will then be
>     >> submitted to numfocus, who will reimburse you directly.
>     >>
>     >> Sorry to be uncommunicative on this (and uncommunicative in general
>     >> lately).  I hope something can still work out at this late date!
>     >>
>     >> Mike
>     >>
>     >> On 02/27/2014 11:28 AM, Michael Droettboom wrote:
>     >> > How many matplotlib developers are planning to attend SciPy
>     this year?
>     >> >
>     >> > 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
>     >> >
>     >>
>     >>
>     >> --
>     >> Michael Droettboom
>     >> Science Software Branch
>     >> Space Telescope Science Institute
>     >>
>     >> http://www.droettboom.com
>     >>
>     >>
>     >>
>     >>
>     ------------------------------------------------------------------------------
>     >> Time is money. Stop wasting it! Get your web API in 5 minutes.
>     >> www.restlet.com/download <http://www.restlet.com/download>
>     >> http://p.sf.net/sfu/restlet
>     >> _______________________________________________
>     >> Matplotlib-devel mailing list
>     >> Mat...@li...
>     <mailto:Mat...@li...>
>     >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>     >
>     >
>     >
>     >
>     ------------------------------------------------------------------------------
>     > 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/NeoTech
>     > _______________________________________________
>     > Matplotlib-devel mailing list
>     > Mat...@li...
>     <mailto:Mat...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>     >
>
>
>
>     --
>     Damon McDougall
>     http://www.damon-is-a-geek.com
>     Institute for Computational Engineering Sciences
>     201 E. 24th St.
>     Stop C0200
>     The University of Texas at Austin
>     Austin, TX 78712-1229
>
>


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute

http://www.droettboom.com

Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general

[Chris B. <chr...@no...>]

On Wed, Jun 4, 2014 at 2:12 PM, Russell E. Owen <ro...@uw...> wrote:

> What I need is a python, numpy, and matplotlib that support 32-bit and
> (preferably) 64-bit for MacOS X 10.6 and later. I have been using
> python.org python and the standard binary installers until now.
>

well we (that is, Matthew) have scripts that build those, so no reason not
to keep doing it.


> Until Mavericks I was using 64-bit mode. Unfortunately 32-bit is
> required for older versions of Tcl/Tk to run under Mavericks


kind of ironic that the latest OS doesn't end up supporting 64 bit!


> I realize I'm in an unusual situation,


maybe -- but tkInter is part of the standard library, so we probably do
want to support it! If nothing else, various folks that teach Python use
the turtle module early on -- and one of the use cases for
easy-to-fine-and-install binaries is newbies...


> and I'm not the one building the
> binaries and trying to deal with the ATLAS headaches. If worst comes to
> worst we can stay at the current version of numpy and matplotlib (at
> least for now). Long term we should probably switch away from Tcl/TK,
> though that would be a huge undertaking, or hire somebody to fix the
> Tcl/Tk bug.


Is Tcl/Tk that unused that this isn't getting addressed? kind of Sad,
though I was never a big fan -- at least once I discovered Python...

-Chris

-- 

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...

Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general

[Russell E. O. <ro...@uw...>]

In article 
<CAH6Pt5r_ZP8a-8U9TLBaRvH=PBb...@ma...>,
 Matthew Brett <mat...@gm...> 
 wrote:

> Hi,
> 
> On Tue, Jun 3, 2014 at 1:00 PM, Russell E. Owen 
> <ro...@uw...> wrote:
> > In article
> > <CALGmxEL6geHVqGibWbUir3tovKs4KeGuW-qeTv5KMcsR40r-bQ-JsoAwUIsXosN+BqQ9rBEUg@
> > public.gmane.org>,
> >  Chris Barker <chr...@no...> wrote:
> >
> >> On Mon, Jun 2, 2014 at 5:28 PM, Matthew Brett
> >> <mat...@gm...>
> >> wrote:
> >>
> >> > > what is this going to do on OS-X 10.7 and 10.8  systems running 
> >> > > homebrew
> >> > or
> >> > > macports pythons? It seems this list could get pretty long!
> >> >
> >> Yes, it could, but this list:
> >> >
> >> > so we would have to add all those if we wanted to support them...
> >>
> >>
> >>
> >> > https://www.adium.im/sparkle/?year=2014&week=22&graph=bar#osVersion
> >> >
> >> >
> >> very interesting stats! I wonder how representative those are? Makes we
> >> think we can drop 32 bit support, too. Maybe the newest 2.7 py.org 
> >> binaries
> >> could be 64 bit only. It would simplify things a bit.
> >
> > I hope you will not drop 32-bit support yet.. I still use it to
> > distribute some Tkinter apps. All recent versions of ActiveState Tcl/Tk
> > 8.5 have a nasty crashing bug that I have not found a workaround for,
> > and old enough versions that don't have the bug need to run in 32-bit
> > mode on Mavericks.
> 
> Do you need 32 bit support for the wheels or just for the MacPython
> binaries?   It's getting harder to build 32 / 64 bit universal
> binaries these days...

What I need is a python, numpy, and matplotlib that support 32-bit and 
(preferably) 64-bit for MacOS X 10.6 and later. I have been using 
python.org python and the standard binary installers until now.

Until Mavericks I was using 64-bit mode. Unfortunately 32-bit is 
required for older versions of Tcl/Tk to run under Mavericks and as I 
noted, I can't use recent versions due to due to a bug (example 
appended) that I've not found a workaround for.

I realize I'm in an unusual situation, and I"m not the one building the 
binaries and trying to deal with the ATLAS headaches. If worst comes to 
worst we can stay at the current version of numpy and matplotlib (at 
least for now). Long term we should probably switch away from Tcl/TK, 
though that would be a huge undertaking, or hire somebody to fix the 
Tcl/Tk bug.

-- Russell

# tcl menu crash; run in wish and push the Change Font button
menu .parentMenu
menu .parentMenu.apple -tearoff 0
# the following line is optional, but shows the menu is created
.parentMenu add cascade -label Wish -menu .parentMenu.apple
font create testFont
option add "*Button.font" testFont
button .btn -text "Change Font" -command { font configure testFont -size 
20 }
pack .btn
. configure -menu .parentMenu

Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general

[Chris B. <chr...@no...>]

Hi Russell,

>
> >Makes we
> > think we can drop 32 bit support, too. Maybe the newest 2.7 py.org
> binaries
> > could be 64 bit only. It would simplify things a bit.
>
> I hope you will not drop 32-bit support yet.. I still use it to
> distribute some Tkinter apps. All recent versions of ActiveState Tcl/Tk
> 8.5 have a nasty crashing bug that I have not found a workaround for,
> and old enough versions that don't have the bug need to run in 32-bit
> mode on Mavericks.


Darn. I guess it's not uncommon that even folks with a 64 bit machine may
need a lib or something that is 32 bit only -- so maybe good to keep it.
But it really is a pain -- and this example is supposed to be part of
Python's stdlib!

On Tue, Jun 3, 2014 at 1:44 PM, Matthew Brett <mat...@gm...>
 wrote:

Do you need 32 bit support for the wheels or just for the MacPython
> binaries?   It's getting harder to build 32 / 64 bit universal
> binaries these days...


Exactly -- will an Intel  Universal Python pick up a 64 bit-only wheel?

That would be OK for most folks, I guess, though I'd really prefer it if
things were more clear -- you have a 32/64 bit python, you install wheels
and it works fine for you, so distribute via py2app, then it crashed when
run in 32 bit mode...

Oh well.

-Chris


-- 

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...

Re: [matplotlib-devel] nosetests: too slow, too much memory

[Benjamin R. <ben...@ou...>]

So, I just tried comparing memory usage for a plot displayed via show()
versus savefig() as a PNG. It would seem that saving to pngs uses more
memory. Not sure why, though.

Ben
On Jun 4, 2014 12:57 PM, "Eric Firing" <ef...@ha...> wrote:

> On 2014/06/04 6:26 AM, Benjamin Root wrote:
>
>> A theory...
>>
>> If I remember correctly, the nosttests was set up to execute in parallel
>> using the default Multiprocessing settings, which is to have a process
>> worker for each available CPU core. Perhaps this might be the crux of
>> the issue with so many simultaneous tests running that the amount of
>> memory used at the same time becomes too large. Or, am I thinking of the
>> doc build system?
>>
>> Ben Root
>>
>
> Ben,
>
> Top shows a single process.  The VM is configured with 2 cores.
>
> Eric
>

Re: [matplotlib-devel] nosetests: too slow, too much memory

[Eric F. <ef...@ha...>]

On 2014/06/04 6:26 AM, Benjamin Root wrote:
> A theory...
>
> If I remember correctly, the nosttests was set up to execute in parallel
> using the default Multiprocessing settings, which is to have a process
> worker for each available CPU core. Perhaps this might be the crux of
> the issue with so many simultaneous tests running that the amount of
> memory used at the same time becomes too large. Or, am I thinking of the
> doc build system?
>
> Ben Root

Ben,

Top shows a single process.  The VM is configured with 2 cores.

Eric

Re: [matplotlib-devel] nosetests: too slow, too much memory

[Benjamin R. <ben...@ou...>]

A theory...

If I remember correctly, the nosttests was set up to execute in parallel
using the default Multiprocessing settings, which is to have a process
worker for each available CPU core. Perhaps this might be the crux of the
issue with so many simultaneous tests running that the amount of memory
used at the same time becomes too large. Or, am I thinking of the doc build
system?

Ben Root


On Wed, Jun 4, 2014 at 12:20 PM, Nelle Varoquaux <nel...@gm...>
wrote:

> > Our standard test has gotten out of control.  The most serious problem is
> > that running a full test suite now fails on a linux VM with 4 GB--it's
> out
> > of memory. Half-way through the set, it is already using more than 2 GB.
> > That's ridiculous.  Running nosetests separately on each test module
> keeps
> > the max reported by top to 1.6 GB, and the max by report_memory to 0.5
> GB;
> > still quite a bit, but tolerable.  (I don't know why there is this
> factor of
> > 3 between top and report_memory.)  This scheme of running test modules
> one
> > at a time also speeds it up by a factor of 2; I don't understand why.
> >
> > The script I used for the module-at-a-time test is attached.  It is a
> > modification of matplotlib.tests().
> >
> > Are there any nosetest experts out there with ideas about how to
> streamline
> > the standard test routine?
>
> This issue is probably worth mentionning on other mailing list of
> people using nosetest, and nosetests.
> I'm thinking of scikit-learn in particular, which also uses nosetest
> heavily. The scipy-users list might be a good place to exchange
> experience.
>
> N
>
> >
> > Eric
> >
> >
> ------------------------------------------------------------------------------
> > Time is money. Stop wasting it! Get your web API in 5 minutes.
> > www.restlet.com/download
> > http://p.sf.net/sfu/restlet
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
> ------------------------------------------------------------------------------
> 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/NeoTech
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] nosetests: too slow, too much memory

[Nelle V. <nel...@gm...>]

> Our standard test has gotten out of control.  The most serious problem is
> that running a full test suite now fails on a linux VM with 4 GB--it's out
> of memory. Half-way through the set, it is already using more than 2 GB.
> That's ridiculous.  Running nosetests separately on each test module keeps
> the max reported by top to 1.6 GB, and the max by report_memory to 0.5 GB;
> still quite a bit, but tolerable.  (I don't know why there is this factor of
> 3 between top and report_memory.)  This scheme of running test modules one
> at a time also speeds it up by a factor of 2; I don't understand why.
>
> The script I used for the module-at-a-time test is attached.  It is a
> modification of matplotlib.tests().
>
> Are there any nosetest experts out there with ideas about how to streamline
> the standard test routine?

This issue is probably worth mentionning on other mailing list of
people using nosetest, and nosetests.
I'm thinking of scikit-learn in particular, which also uses nosetest
heavily. The scipy-users list might be a good place to exchange
experience.

N

>
> Eric
>
> ------------------------------------------------------------------------------
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] Developer summit at Scipy?

[Benjamin R. <ben...@ou...>]

Yes please. Last year's BoF was well-attended. I would expect nothing less
this year.

Ben


On Wed, Jun 4, 2014 at 10:39 AM, Damon McDougall <dam...@gm...>
wrote:

> Shall I go ahead and set up a MEP bof?  Just got an email for a call
> for BoFs which reminded me to ask.
>
> On Mon, Jun 2, 2014 at 2:15 PM, Benjamin Root <ben...@ou...> wrote:
> > That is unfortunate that we can't have a summit before/after SciPy 2014.
> I
> > have also booked my flights and hotel, and the only time I would have to
> fit
> > a "summit" outside of SciPy 2014 would be Saturday, July 5th in the
> evening.
> >
> > I will be there, though, for the entire conference (including both sprint
> > days). Perhaps we can have a somewhat formalized Birds-of-a-feather
> session?
> > Maybe with a discussion panel and some short presentations on our visions
> > for future matplotlib development?
> >
> > Ben Root
> >
> >
> >
> > On Fri, May 30, 2014 at 9:35 AM, Michael Droettboom <md...@st...>
> wrote:
> >>
> >> Hello all,
> >>
> >> Sorry to be writing this at this late point, but I've been hoping I
> >> could find a way around it.  I won't be able to attend an extra day at
> >> either end of Scipy year, both due to personal commitments and new
> >> funding constraints at NASA.  I do plan to attend/host the matplotlib
> >> sprint again, however, which is not a bad opportunity to catch up on
> >> some of these issues.
> >>
> >> So, an extra developer summit day is still possible if someone else is
> >> able to organize it -- I just, unfortunately, won't be able to attend.
> >> We can still use the matplotlib donated funds to cover the cost of the
> >> extra hotel night (assuming the numbers of people wanting to do that is
> >> not too large) and meeting space (if the cost is not too high, though
> >> maybe locals like Damon have a connection for free and/or cheap space).
> >> For reimbursement, I would need a receipt for that hotel night (ideally
> >> with that one night broken out individually), which will then be
> >> submitted to numfocus, who will reimburse you directly.
> >>
> >> Sorry to be uncommunicative on this (and uncommunicative in general
> >> lately).  I hope something can still work out at this late date!
> >>
> >> Mike
> >>
> >> On 02/27/2014 11:28 AM, Michael Droettboom wrote:
> >> > How many matplotlib developers are planning to attend SciPy this year?
> >> >
> >> > 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
> >> >
> >>
> >>
> >> --
> >> Michael Droettboom
> >> Science Software Branch
> >> Space Telescope Science Institute
> >>
> >> http://www.droettboom.com
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Time is money. Stop wasting it! Get your web API in 5 minutes.
> >> www.restlet.com/download
> >> http://p.sf.net/sfu/restlet
> >> _______________________________________________
> >> Matplotlib-devel mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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/NeoTech
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
>
> --
> Damon McDougall
> http://www.damon-is-a-geek.com
> Institute for Computational Engineering Sciences
> 201 E. 24th St.
> Stop C0200
> The University of Texas at Austin
> Austin, TX 78712-1229
>

Re: [matplotlib-devel] Developer summit at Scipy?

[Damon M. <dam...@gm...>]

Shall I go ahead and set up a MEP bof?  Just got an email for a call
for BoFs which reminded me to ask.

On Mon, Jun 2, 2014 at 2:15 PM, Benjamin Root <ben...@ou...> wrote:
> That is unfortunate that we can't have a summit before/after SciPy 2014. I
> have also booked my flights and hotel, and the only time I would have to fit
> a "summit" outside of SciPy 2014 would be Saturday, July 5th in the evening.
>
> I will be there, though, for the entire conference (including both sprint
> days). Perhaps we can have a somewhat formalized Birds-of-a-feather session?
> Maybe with a discussion panel and some short presentations on our visions
> for future matplotlib development?
>
> Ben Root
>
>
>
> On Fri, May 30, 2014 at 9:35 AM, Michael Droettboom <md...@st...> wrote:
>>
>> Hello all,
>>
>> Sorry to be writing this at this late point, but I've been hoping I
>> could find a way around it.  I won't be able to attend an extra day at
>> either end of Scipy year, both due to personal commitments and new
>> funding constraints at NASA.  I do plan to attend/host the matplotlib
>> sprint again, however, which is not a bad opportunity to catch up on
>> some of these issues.
>>
>> So, an extra developer summit day is still possible if someone else is
>> able to organize it -- I just, unfortunately, won't be able to attend.
>> We can still use the matplotlib donated funds to cover the cost of the
>> extra hotel night (assuming the numbers of people wanting to do that is
>> not too large) and meeting space (if the cost is not too high, though
>> maybe locals like Damon have a connection for free and/or cheap space).
>> For reimbursement, I would need a receipt for that hotel night (ideally
>> with that one night broken out individually), which will then be
>> submitted to numfocus, who will reimburse you directly.
>>
>> Sorry to be uncommunicative on this (and uncommunicative in general
>> lately).  I hope something can still work out at this late date!
>>
>> Mike
>>
>> On 02/27/2014 11:28 AM, Michael Droettboom wrote:
>> > How many matplotlib developers are planning to attend SciPy this year?
>> >
>> > 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
>> >
>>
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Space Telescope Science Institute
>>
>> http://www.droettboom.com
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Time is money. Stop wasting it! Get your web API in 5 minutes.
>> www.restlet.com/download
>> http://p.sf.net/sfu/restlet
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> 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/NeoTech
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>



-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general

[Matthew B. <mat...@gm...>]

Hi,

On Tue, Jun 3, 2014 at 1:00 PM, Russell E. Owen <ro...@uw...> wrote:
> In article
> <CAL...@ma...>,
>  Chris Barker <chr...@no...> wrote:
>
>> On Mon, Jun 2, 2014 at 5:28 PM, Matthew Brett
>> <mat...@gm...>
>> wrote:
>>
>> > > what is this going to do on OS-X 10.7 and 10.8  systems running homebrew
>> > or
>> > > macports pythons? It seems this list could get pretty long!
>> >
>> Yes, it could, but this list:
>> >
>> > so we would have to add all those if we wanted to support them...
>>
>>
>>
>> > https://www.adium.im/sparkle/?year=2014&week=22&graph=bar#osVersion
>> >
>> >
>> very interesting stats! I wonder how representative those are? Makes we
>> think we can drop 32 bit support, too. Maybe the newest 2.7 py.org binaries
>> could be 64 bit only. It would simplify things a bit.
>
> I hope you will not drop 32-bit support yet.. I still use it to
> distribute some Tkinter apps. All recent versions of ActiveState Tcl/Tk
> 8.5 have a nasty crashing bug that I have not found a workaround for,
> and old enough versions that don't have the bug need to run in 32-bit
> mode on Mavericks.

Do you need 32 bit support for the wheels or just for the MacPython
binaries?   It's getting harder to build 32 / 64 bit universal
binaries these days...

Cheers,

Matthew

Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general

[Russell E. O. <ro...@uw...>]

In article 
<CAL...@ma...>,
 Chris Barker <chr...@no...> wrote:

> On Mon, Jun 2, 2014 at 5:28 PM, Matthew Brett 
> <mat...@gm...>
> wrote:
> 
> > > what is this going to do on OS-X 10.7 and 10.8  systems running homebrew
> > or
> > > macports pythons? It seems this list could get pretty long!
> >
> Yes, it could, but this list:
> >
> > so we would have to add all those if we wanted to support them...
> 
> 
> 
> > https://www.adium.im/sparkle/?year=2014&week=22&graph=bar#osVersion
> >
> >
> very interesting stats! I wonder how representative those are? Makes we
> think we can drop 32 bit support, too. Maybe the newest 2.7 py.org binaries
> could be 64 bit only. It would simplify things a bit.

I hope you will not drop 32-bit support yet.. I still use it to 
distribute some Tkinter apps. All recent versions of ActiveState Tcl/Tk 
8.5 have a nasty crashing bug that I have not found a workaround for, 
and old enough versions that don't have the bug need to run in 32-bit 
mode on Mavericks.

-- Russell

Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general

[Chris B. <chr...@no...>]

On Mon, Jun 2, 2014 at 5:28 PM, Matthew Brett <mat...@gm...>
wrote:

> > what is this going to do on OS-X 10.7 and 10.8  systems running homebrew
> or
> > macports pythons? It seems this list could get pretty long!
>
Yes, it could, but this list:
>
> so we would have to add all those if we wanted to support them...



> https://www.adium.im/sparkle/?year=2014&week=22&graph=bar#osVersion
>
>
very interesting stats! I wonder how representative those are? Makes we
think we can drop 32 bit support, too. Maybe the newest 2.7 py.org binaries
could be 64 bit only. It would simplify things a bit.


> suggests that 10.9 is the majority, and that 10.8 and 10.7 are only
> about 14 percent combined.  I guess a better case could be made for
> 10.6 (still 16 percent), but I wonder how many 10.6 hold-outs are
> updating their homebrew / macports numpies regularly.
>

not many -- it can be a really a pain to do so -- macports and homebrew
really expect you to have a recent compiler, which I think is difficult or
impossible to install on 10.6...

-Chris


-- 

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...

Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general

[Matthew B. <mat...@gm...>]

Hi,

On Mon, Jun 2, 2014 at 5:14 PM, Chris Barker <chr...@no...> wrote:
> On Mon, Jun 2, 2014 at 11:48 AM, Matthew Brett <mat...@gm...>
> wrote:
>>
>> I want to rename the matplotlib wheel OSX wheel files on pypi so they
>> will also install into homebrew, macports and system python.
>
>
> +1
>
>>
>>
>> matplotlib-1.3.1-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl
>
>
> what is this going to do on OS-X 10.7 and 10.8  systems running homebrew or
> macports pythons? It seems this list could get pretty long!

Yes, it could, but this list:

https://www.adium.im/sparkle/?year=2014&week=22&graph=bar#osVersion

suggests that 10.9 is the majority, and that 10.8 and 10.7 are only
about 14 percent combined.  I guess a better case could be made for
10.6 (still 16 percent), but I wonder how many 10.6 hold-outs are
updating their homebrew / macports numpies regularly.

Cheers,

Matthew

Re: [matplotlib-devel] Renaming OSX wheels on pypi to make them more general

[Chris B. <chr...@no...>]

On Mon, Jun 2, 2014 at 11:48 AM, Matthew Brett <mat...@gm...>
wrote:

> I want to rename the matplotlib wheel OSX wheel files on pypi so they
> will also install into homebrew, macports and system python.
>

+1


>
> matplotlib-1.3.1-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl
>

what is this going to do on OS-X 10.7 and 10.8  systems running homebrew or
macports pythons? It seems this list could get pretty long!

-Chris


-- 

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...

Re: [matplotlib-devel] Developer summit at Scipy?

[Benjamin R. <ben...@ou...>]

That is unfortunate that we can't have a summit before/after SciPy 2014. I
have also booked my flights and hotel, and the only time I would have to
fit a "summit" outside of SciPy 2014 would be Saturday, July 5th in the
evening.

I will be there, though, for the entire conference (including both sprint
days). Perhaps we can have a somewhat formalized Birds-of-a-feather
session? Maybe with a discussion panel and some short presentations on our
visions for future matplotlib development?

Ben Root



On Fri, May 30, 2014 at 9:35 AM, Michael Droettboom <md...@st...> wrote:

> Hello all,
>
> Sorry to be writing this at this late point, but I've been hoping I
> could find a way around it.  I won't be able to attend an extra day at
> either end of Scipy year, both due to personal commitments and new
> funding constraints at NASA.  I do plan to attend/host the matplotlib
> sprint again, however, which is not a bad opportunity to catch up on
> some of these issues.
>
> So, an extra developer summit day is still possible if someone else is
> able to organize it -- I just, unfortunately, won't be able to attend.
> We can still use the matplotlib donated funds to cover the cost of the
> extra hotel night (assuming the numbers of people wanting to do that is
> not too large) and meeting space (if the cost is not too high, though
> maybe locals like Damon have a connection for free and/or cheap space).
> For reimbursement, I would need a receipt for that hotel night (ideally
> with that one night broken out individually), which will then be
> submitted to numfocus, who will reimburse you directly.
>
> Sorry to be uncommunicative on this (and uncommunicative in general
> lately).  I hope something can still work out at this late date!
>
> Mike
>
> On 02/27/2014 11:28 AM, Michael Droettboom wrote:
> > How many matplotlib developers are planning to attend SciPy this year?
> >
> > 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
> >
>
>
> --
> Michael Droettboom
> Science Software Branch
> Space Telescope Science Institute
>
> http://www.droettboom.com
>
>
>
> ------------------------------------------------------------------------------
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

[matplotlib-devel] Renaming OSX wheels on pypi to make them more general

[Matthew B. <mat...@gm...>]

Hi,

Sorry for those of you on the numpy mailing list - this email will
seem a bit familiar.

I want to rename the matplotlib wheel OSX wheel files on pypi so they
will also install into homebrew, macports and system python.

I'm just doing this now for numpy and scipy, but I wanted to make sure
y'all had no objections for matplotlib.

The logic of the renaming is explained here:
https://github.com/MacPython/wiki/wiki/Spinning-wheels

Basically, by adding extra 'platform tags' to the wheel filename, we
can signal to pip that the wheel is compatible with these other
systems.

The page above explains why the wheels I built are compatible with the
other Pythons, and this test grid:

https://travis-ci.org/matthew-brett/scipy-stack-osx-testing/builds/26482436

confirms that the renamed wheels install and test OK on homebrew,
macports, system python.

So, I propose to rename the current matplotlib python 2.7 wheel from:

matplotlib-1.3.1-cp27-none-macosx_10_6_intel.whl

to

matplotlib-1.3.1-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl

and so on for python 3.3, 3.4.

I don't think this has a downside, but I'm happy for any feedback,

Cheers,

Matthew

[matplotlib-devel] nosetests: too slow, too much memory

[Eric F. <ef...@ha...>]

Our standard test has gotten out of control.  The most serious problem 
is that running a full test suite now fails on a linux VM with 4 
GB--it's out of memory. Half-way through the set, it is already using 
more than 2 GB. That's ridiculous.  Running nosetests separately on each 
test module keeps the max reported by top to 1.6 GB, and the max by 
report_memory to 0.5 GB; still quite a bit, but tolerable.  (I don't 
know why there is this factor of 3 between top and report_memory.)  This 
scheme of running test modules one at a time also speeds it up by a 
factor of 2; I don't understand why.

The script I used for the module-at-a-time test is attached.  It is a 
modification of matplotlib.tests().

Are there any nosetest experts out there with ideas about how to 
streamline the standard test routine?

Eric

Re: [matplotlib-devel] Setting default labelpad

[Peter S. J. <pet...@gm...>]

Sure, here it is:

https://github.com/matplotlib/matplotlib/pull/3096


On Fri, May 30, 2014 at 4:21 PM, Paul Hobson <pmh...@gm...> wrote:

> Peter,
>
> Can you submit this as a pull request on github?
> http://matplotlib.org/devel/gitwash/git_development.html
>
>
> On Fri, May 30, 2014 at 12:37 PM, Peter St. John <pet...@gm...>
> wrote:
>
>> Finally made this into a patch to allow the dynamic updating of the
>> axes.labelpad parameter.
>> Hope this is in the appropriate format!
>>
>> Thanks,
>> -- Peter
>>
>>
>> On Mon, Oct 28, 2013 at 10:45 AM, Peter St. John <pet...@gm...
>> > wrote:
>>
>>> Hi Matplotlib-users,
>>>
>>> I found it was useful to be able to change the default 'Axis.labelpad'
>>> parameter, since this value didn't scale when changing the default figure
>>> size (in my opinion its easier to prepare figures for publication assuming
>>> they'll need to fit in a 1-column figure). I don't consider myself
>>> experienced enough to attempt to contribute a patch, but nevertheless here
>>> is the hack I used in case anyone has a similar problem:
>>>
>>> axis.py, line 652:
>>> original: self.labelpad = 5
>>> changed : self.labelpad = rcParams['axes.labelpad']
>>>
>>> Then, in rcsetup.py, I added the line (at 578):
>>>     'axes.labelpad' :        [5.0, validate_float],
>>>
>>> This lets you put
>>> axes.labelpad       : 3
>>> for instance, in your matplotlibrc to change the default label padding.
>>>
>>> Anyways, not sure if this is the right mailing list for this type of
>>> thing, but just thought I'd contribute it nevertheless.
>>>
>>> Best,
>>> -- Peter
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Time is money. Stop wasting it! Get your web API in 5 minutes.
>> www.restlet.com/download
>> http://p.sf.net/sfu/restlet
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>

Re: [matplotlib-devel] Setting default labelpad

[Paul H. <pmh...@gm...>]

Peter,

Can you submit this as a pull request on github?
http://matplotlib.org/devel/gitwash/git_development.html


On Fri, May 30, 2014 at 12:37 PM, Peter St. John <pet...@gm...>
wrote:

> Finally made this into a patch to allow the dynamic updating of the
> axes.labelpad parameter.
> Hope this is in the appropriate format!
>
> Thanks,
> -- Peter
>
>
> On Mon, Oct 28, 2013 at 10:45 AM, Peter St. John <pet...@gm...>
> wrote:
>
>> Hi Matplotlib-users,
>>
>> I found it was useful to be able to change the default 'Axis.labelpad'
>> parameter, since this value didn't scale when changing the default figure
>> size (in my opinion its easier to prepare figures for publication assuming
>> they'll need to fit in a 1-column figure). I don't consider myself
>> experienced enough to attempt to contribute a patch, but nevertheless here
>> is the hack I used in case anyone has a similar problem:
>>
>> axis.py, line 652:
>> original: self.labelpad = 5
>> changed : self.labelpad = rcParams['axes.labelpad']
>>
>> Then, in rcsetup.py, I added the line (at 578):
>>     'axes.labelpad' :        [5.0, validate_float],
>>
>> This lets you put
>> axes.labelpad       : 3
>> for instance, in your matplotlibrc to change the default label padding.
>>
>> Anyways, not sure if this is the right mailing list for this type of
>> thing, but just thought I'd contribute it nevertheless.
>>
>> Best,
>> -- Peter
>>
>
>
>
> ------------------------------------------------------------------------------
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>