matplotlib-devel Mailing List for matplotlib

On Thu, Jun 26, 2014 at 02:36:28PM -0400, Benjamin Root wrote:
> This is very interesting. I have also noticed that ticking has been a
> bottleneck in rendering, but always suspected the computation of the ticks
> rather than the actual rendering of the marks. Perhaps this might spur some
> renewed interest in identifying the specific reason for the bottleneck and
> solving that issue now that we know that there are significant performance
> gain potential here?
I'm thinking about "specific reasons":
1) Path.__init__ does mysterious stuff (at least, mysterious to me) and seems
designed to handle many different inputs in various stages of readiness for
something. It is also called many times in the course of getting a graph on
screen and it isn't very fast. I think the checking and rechecking vertices is
needlessly expensive in particular around TransformedPath. This is deep stuff
and I'm too novice.
1a) Line2D.recache is a big hunk in the profiler, but that's partly due to #1.
2) The loops in axis.py over major_ticks and minor_ticks are repeated in time
sensitive areas and apply the same things to many sub-objects. This is the
issue that my current ideas are addressing.
3) If one addresses 1&2, the next largest elephant appears to be text
rendering.
While fixing #1 is a really good idea, it's hard work and the multitude of
explicit tick objects of #2 will always have a great deal of python call
overhead.
Fixing #3 has little low-hanging fruit. I've seen
https://github.com/matplotlib/matplotlib/issues/347 and a 20% gain would be
a noticeable improvement on the graphs I'm working on (but only after #2 is
addressed). Of course, I'm not sure of what total quantity mdboom's 20%
referred to.
Joel
PS: all of these thoughts are brought to you by snakeviz ... nice profile
visualizer
> 
> Looking forward to reviewing this at some point in the next few weeks.
> 
> Cheers!
> Ben Root
> 
> 
> 
> On Thu, Jun 26, 2014 at 2:10 PM, Joel B. Mohler <jo...@ki...>
> wrote:
> 
> > About a week ago I sent a message to the users mailing list with tick mark
> > performance problems. I now have a proof of concept patch which
> > (mis-)uses the
> > projection keyword in add_subplot to use a custom Axes class. Import one
> > python file, use "projection='fastticks'" -> boring scatter plots render
> > about
> > 2x as fast and plots with lots of minor ticks render 6x faster.
> >
> > The code is at https://github.com/jbmohler/mplfastaxes ; the core idea is
> > in
> > fastaxes.py which uses a single Line2D for all tick marks of a given flavor
> > rather than a Line2D for every single tick mark.
> >
> > There are two reasons this isn't a total win:
> > 1) it's not done yet in all tick/grid configurations.
> > 2) it loses flexibility in tick labeling
> >
> > The lost flexibility may matter a great deal to other people. In my
> > use-case,
> > the labeling flexibility simply seems misguided and the performance is much
> > much preferred.
> >
> > Comments welcome about how this could move forward toward being included in
> > MPL.
> >
> > Joel
> >
> >
> > ------------------------------------------------------------------------------
> > Open source business process management suite built on Java and Eclipse
> > Turn processes into business applications with Bonita BPM Community Edition
> > Quickly connect people, data, and systems into organized workflows
> > Winner of BOSSIE, CODIE, OW2 and Gartner awards
> > http://p.sf.net/sfu/Bonitasoft
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >

False alarm. The Travis logs includes (but hides) the install output, and
test_mlab was running for me, but I was looking at the wrong line
numbers. Still though, I would be curious as to any differences, but I
can't seem to download the log file.
Ben
On Thu, Jun 26, 2014 at 6:57 PM, Benjamin Root <ben...@ou...> wrote:
> Just noticed an oddity with the tests on Travis versus the tests on my
> machine. The test log on Travis for a single run has over 10,000 lines.
> But, for me, it is over ~4800 lines. At a glance, I can see that test_mlab
> is not executed for me, but they are for Travis. I am very suspicious of
> the test_mlab run on Travis because it seems to be running multiple times,
> but I can't be sure.
>
> Michael, can I get the test log for one of the recent Travis runs?
>
> Thanks,
> Ben Root
>
>
>
> On Wed, Jun 4, 2014 at 1:49 PM, Benjamin Root <ben...@ou...> wrote:
>
>> 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
>>>
>>
>

Just noticed an oddity with the tests on Travis versus the tests on my
machine. The test log on Travis for a single run has over 10,000 lines.
But, for me, it is over ~4800 lines. At a glance, I can see that test_mlab
is not executed for me, but they are for Travis. I am very suspicious of
the test_mlab run on Travis because it seems to be running multiple times,
but I can't be sure.
Michael, can I get the test log for one of the recent Travis runs?
Thanks,
Ben Root
On Wed, Jun 4, 2014 at 1:49 PM, Benjamin Root <ben...@ou...> wrote:
> 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
>>
>

This is very interesting. I have also noticed that ticking has been a
bottleneck in rendering, but always suspected the computation of the ticks
rather than the actual rendering of the marks. Perhaps this might spur some
renewed interest in identifying the specific reason for the bottleneck and
solving that issue now that we know that there are significant performance
gain potential here?
Looking forward to reviewing this at some point in the next few weeks.
Cheers!
Ben Root
On Thu, Jun 26, 2014 at 2:10 PM, Joel B. Mohler <jo...@ki...>
wrote:
> About a week ago I sent a message to the users mailing list with tick mark
> performance problems. I now have a proof of concept patch which
> (mis-)uses the
> projection keyword in add_subplot to use a custom Axes class. Import one
> python file, use "projection='fastticks'" -> boring scatter plots render
> about
> 2x as fast and plots with lots of minor ticks render 6x faster.
>
> The code is at https://github.com/jbmohler/mplfastaxes ; the core idea is
> in
> fastaxes.py which uses a single Line2D for all tick marks of a given flavor
> rather than a Line2D for every single tick mark.
>
> There are two reasons this isn't a total win:
> 1) it's not done yet in all tick/grid configurations.
> 2) it loses flexibility in tick labeling
>
> The lost flexibility may matter a great deal to other people. In my
> use-case,
> the labeling flexibility simply seems misguided and the performance is much
> much preferred.
>
> Comments welcome about how this could move forward toward being included in
> MPL.
>
> Joel
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

About a week ago I sent a message to the users mailing list with tick mark
performance problems. I now have a proof of concept patch which (mis-)uses the
projection keyword in add_subplot to use a custom Axes class. Import one
python file, use "projection='fastticks'" -> boring scatter plots render about
2x as fast and plots with lots of minor ticks render 6x faster.
The code is at https://github.com/jbmohler/mplfastaxes ; the core idea is in
fastaxes.py which uses a single Line2D for all tick marks of a given flavor
rather than a Line2D for every single tick mark.
There are two reasons this isn't a total win:
1) it's not done yet in all tick/grid configurations.
2) it loses flexibility in tick labeling
The lost flexibility may matter a great deal to other people. In my use-case,
the labeling flexibility simply seems misguided and the performance is much
much preferred.
Comments welcome about how this could move forward toward being included in
MPL.
Joel

On 25 June 2014 17:55, Benjamin Root <ben...@ou...> wrote:
> The mplot3d tests are not run automatically, so I have no idea when this
> change happened. But I would suspect it is related to the changes in
> triangulation rather than with mplot3d itself. I have zero expertise to say
> if one result is more correct than the other. See attached.
>
> I should note that this particular difference was within the default
> tolerance. It was the rendering to PDF that seemed to have enough
> difference to trigger a failure.
>
Ben,
You are right, this change occurred when the underlying triangulation code
was switched to using qhull. Both before and after pictures are equally
correct.
A rectangle in the x-y plane is split into two triangles by adding a
diagonal. The shortest of the two diagonals should added, so for the
analytical solution either diagonal is equally valid. In practice the
choice of diagonal depends on the order of operations in the underlying
algorithm and how these interact with finite machine precision.
Rather than just changing the test image, a better solution would be to
modify the relevant example/test code to avoid such degenerate cases that
can give problems in the future. The source code for trisurf3d_demo (
http://matplotlib.org/examples/mplot3d/trisurf3d_demo.html) is clearly
derived from tripcolor_demo (
http://matplotlib.org/examples/pylab_examples/tripcolor_demo.html), but
omits the key line near the beginning of
angles[:,1::2] += math.pi/n_angles
Putting this line back in will avoid similar problems in the future, and
improve the images too.
Ian

Hi,
On Wed, Jun 25, 2014 at 4:49 PM, <kei...@bt...> wrote:
> Thanks, but I didn't get it when I downloaded matplotlib-1.3.1.tar.gz.
>
> kbriggs:~/Downloads> tar tf matplotlib-1.3.1.tar.gz | grep tests.py
>
> Keith
>
> ________________________________________
> From: ben...@gm... [ben...@gm...] On Behalf Of Benjamin Root [ben...@ou...]
> Sent: 25 June 2014 16:45
> To: Briggs,KM,Keith,TUB2 R
> Cc: matplotlib development list
> Subject: Re: [matplotlib-devel] tests.py missing
>
> It is right there in the root directory for the distribution:
>
> https://github.com/matplotlib/matplotlib/tree/v1.3.x
>
>
> On Thu, Jun 19, 2014 at 11:29 AM, <kei...@bt...<mailto:kei...@bt...>> wrote:
> README.rst in matplotlib-1.3.1 says:
>
>> After installation, you can launch the test suite::
>>
>> python tests.py
>
> but actually there is no tests.py anywhere in the distribution.
Actually, it would be very good to have the tests.py file somewhere
from a standard install - I had to hack round that for automated tests
of a pip tarball, for example, by downloading the test.py separately.
Cheers,
Matthew

Heh... well, that's a horse of a different color! We will have to make sure
it is in there for the upcoming release.
Cheers!
Ben Root
On Wed, Jun 25, 2014 at 11:49 AM, <kei...@bt...> wrote:
> Thanks, but I didn't get it when I downloaded matplotlib-1.3.1.tar.gz.
>
> kbriggs:~/Downloads> tar tf matplotlib-1.3.1.tar.gz | grep tests.py
>
> Keith
>
> ________________________________________
> From: ben...@gm... [ben...@gm...] On Behalf Of Benjamin
> Root [ben...@ou...]
> Sent: 25 June 2014 16:45
> To: Briggs,KM,Keith,TUB2 R
> Cc: matplotlib development list
> Subject: Re: [matplotlib-devel] tests.py missing
>
> It is right there in the root directory for the distribution:
>
> https://github.com/matplotlib/matplotlib/tree/v1.3.x
>
>
> On Thu, Jun 19, 2014 at 11:29 AM, <kei...@bt...<mailto:
> kei...@bt...>> wrote:
> README.rst in matplotlib-1.3.1 says:
>
> > After installation, you can launch the test suite::
> >
> > python tests.py
>
> but actually there is no tests.py anywhere in the distribution.
>
> Keith
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...<mailto:
> Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Thanks, but I didn't get it when I downloaded matplotlib-1.3.1.tar.gz.
kbriggs:~/Downloads> tar tf matplotlib-1.3.1.tar.gz | grep tests.py
Keith
________________________________________
From: ben...@gm... [ben...@gm...] On Behalf Of Benjamin Root [ben...@ou...]
Sent: 25 June 2014 16:45
To: Briggs,KM,Keith,TUB2 R
Cc: matplotlib development list
Subject: Re: [matplotlib-devel] tests.py missing
It is right there in the root directory for the distribution:
https://github.com/matplotlib/matplotlib/tree/v1.3.x
On Thu, Jun 19, 2014 at 11:29 AM, <kei...@bt...<mailto:kei...@bt...>> wrote:
README.rst in matplotlib-1.3.1 says:
> After installation, you can launch the test suite::
>
> python tests.py
but actually there is no tests.py anywhere in the distribution.
Keith
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...<mailto:Mat...@li...>
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

It is right there in the root directory for the distribution:
https://github.com/matplotlib/matplotlib/tree/v1.3.x
On Thu, Jun 19, 2014 at 11:29 AM, <kei...@bt...> wrote:
> README.rst in matplotlib-1.3.1 says:
>
> > After installation, you can launch the test suite::
> >
> > python tests.py
>
> but actually there is no tests.py anywhere in the distribution.
>
> Keith
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Fri, Jun 20, 2014 at 12:01 PM, Matthew Brett <mat...@gm...> wrote:
> Hi,
>
> On Thu, Jun 5, 2014 at 5:18 AM, Chris Barker <chr...@no...> wrote:
>> 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...
>
> Updating for those of you not on the numpy mailing list - I've
> uploaded 32 / 64 bit numpy / scipy wheels to pypi, so we should be
> good for 32-bit compatibility now. I hope that will continue for at
> least a couple of years, because I've automated the 32 / 64 bit build
> process [1] and added 32-bit tests to my scipy-stack test rig [2].
>
> So, I think it is time to rename the matplotlib wheels as I proposed
> at the beginning of the thread. I propose to do that tomorrow unless
> anyone can think of a reason not to.
Done - please let me know if you have any problems.
Matthew

Hi,
On Thu, Jun 5, 2014 at 5:18 AM, Chris Barker <chr...@no...> wrote:
> 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...
Updating for those of you not on the numpy mailing list - I've
uploaded 32 / 64 bit numpy / scipy wheels to pypi, so we should be
good for 32-bit compatibility now. I hope that will continue for at
least a couple of years, because I've automated the 32 / 64 bit build
process [1] and added 32-bit tests to my scipy-stack test rig [2].
So, I think it is time to rename the matplotlib wheels as I proposed
at the beginning of the thread. I propose to do that tomorrow unless
anyone can think of a reason not to.
Cheers,
Matthew
[1] https://github.com/matthew-brett/numpy-atlas-binaries
[2] https://travis-ci.org/matthew-brett/scipy-stack-osx-testing

README.rst in matplotlib-1.3.1 says:
> After installation, you can launch the test suite::
> 
> python tests.py
but actually there is no tests.py anywhere in the distribution.
Keith

Which version of matplotlib are you using? Also, do you have an example
dataset and a simple, self-contained example to demonstrate this?
Chances are, there are NaNs occurring in the calculation, but since we have
code elsewhere that handles NaNs properly, it probably isn't impacting your
graph. However, it *might* be a sign that there is something
wrong/unexpected with your input data (or maybe even the contour levels
themselves).
Cheers!
Ben Root
On Tue, Jun 17, 2014 at 6:45 AM, <kei...@bt...> wrote:
> Using pyplot.contour, I'm getting
>
> /usr/lib/pymodules/python2.7/matplotlib/contour.py:374: RuntimeWarning:
> invalid value encountered in true_divide
> dist = np.add.reduce(([(abs(s)[i]/L[i]) for i in range(xsize)]),-1)
>
> although the resulting plot seems to be ok.
>
> Keith
>
>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Using pyplot.contour, I'm getting
/usr/lib/pymodules/python2.7/matplotlib/contour.py:374: RuntimeWarning: invalid value encountered in true_divide
 dist = np.add.reduce(([(abs(s)[i]/L[i]) for i in range(xsize)]),-1)
although the resulting plot seems to be ok.
Keith

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

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

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

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

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

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

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

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

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

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
>