matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] label= kwarg for imshow() and other scalarmappable plots

[Phil E. <pel...@gm...>]

In general I like the idea, but I'm not sure what behaviour I would expect
in this case:

plt.imshow(z, label='foobar')
plt.imshow(z, label='wibble')
plt.colorbar()

I suppose it is an analogous problem to:

plt.imshow(z, cmap='hot')
plt.imshow(z, cmap='jet')
plt.colorbar()

Which produces a colorbar for the [current scalar mappable]/gci.

On that basis, I've just convinced myself that your proposal is a good
idea, so +1 from me.





On 25 March 2013 07:03, Eric Firing <ef...@ha...> wrote:

> On 2013/03/24 12:14 PM, Benjamin Root wrote:
> > So, for plot(), scatter() and other plotting functions, we can provide a
> > label= kwarg so that a legend() can automatically populate the legend,
> > making it extremely easy and convenient for making legends.  But for
> > image-based (scalar mappable) type plotting functions like imshow() and
> > contourf(), the label kwarg doesn't do anything useful, but the
> > colorbar() is sort of analogous to a legend(), but for scalar mappables.
> >
> > Does it make sense to others for the following to be equivalent:
> >
> >  > plt.imshow(z)
> >  > cbar = plt.colorbar()
> >  > cbar.set_label('foobar')
> >
> >  > plt.imshow(z, label='foobar')
> >  > plt.colorbar()
> >
>
> I understand your argument, but it feels a bit odd.  To me it would be
> more natural for colorbar() itself to accept a label kwarg.  I have no
> idea why I didn't do that long ago.
>
> The two ideas are not mutually exclusive.
>
> Eric
>
> >
> > I found that it is a small change to make this work, I just wanted to
> > know if others think this makes sense before putting in the time to add
> > documentation, modify examples and such.
> >
> > Cheers!
> > Ben Root
> >
> >
> >
> ------------------------------------------------------------------------------
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> > http://p.sf.net/sfu/appdyn_d2d_mar
> >
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] label= kwarg for imshow() and other scalarmappable plots

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

On 2013/03/24 12:14 PM, Benjamin Root wrote:
> So, for plot(), scatter() and other plotting functions, we can provide a
> label= kwarg so that a legend() can automatically populate the legend,
> making it extremely easy and convenient for making legends.  But for
> image-based (scalar mappable) type plotting functions like imshow() and
> contourf(), the label kwarg doesn't do anything useful, but the
> colorbar() is sort of analogous to a legend(), but for scalar mappables.
>
> Does it make sense to others for the following to be equivalent:
>
>  > plt.imshow(z)
>  > cbar = plt.colorbar()
>  > cbar.set_label('foobar')
>
>  > plt.imshow(z, label='foobar')
>  > plt.colorbar()
>

I understand your argument, but it feels a bit odd.  To me it would be 
more natural for colorbar() itself to accept a label kwarg.  I have no 
idea why I didn't do that long ago.

The two ideas are not mutually exclusive.

Eric

>
> I found that it is a small change to make this work, I just wanted to
> know if others think this makes sense before putting in the time to add
> documentation, modify examples and such.
>
> Cheers!
> Ben Root
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

[matplotlib-devel] label= kwarg for imshow() and other scalarmappable plots

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

So, for plot(), scatter() and other plotting functions, we can provide a
label= kwarg so that a legend() can automatically populate the legend,
making it extremely easy and convenient for making legends.  But for
image-based (scalar mappable) type plotting functions like imshow() and
contourf(), the label kwarg doesn't do anything useful, but the colorbar()
is sort of analogous to a legend(), but for scalar mappables.

Does it make sense to others for the following to be equivalent:

> plt.imshow(z)
> cbar = plt.colorbar()
> cbar.set_label('foobar')

> plt.imshow(z, label='foobar')
> plt.colorbar()


I found that it is a small change to make this work, I just wanted to know
if others think this makes sense before putting in the time to add
documentation, modify examples and such.

Cheers!
Ben Root

Re: [matplotlib-devel] SciPy 2013

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

On Fri, Mar 22, 2013 at 12:11 PM, Nelle Varoquaux
<nel...@gm...> wrote:
>
>
>
> On 22 March 2013 18:06, Michael Droettboom <md...@st...> wrote:
>>
>> On 03/22/2013 12:45 PM, Nelle Varoquaux wrote:
>>
>>
>>> I'm hoping to host a matplotlib sprint during the final two days of Scipy
>>> 2013 this year, and I hope to see as many as possible of you there.  I think
>>> it's also really important to bring new developers into sprints, because
>>> it's such an efficient way to get people familiar with the code base.

Awesome idea.  I am for sure in.  In fact, I work in Austin now; it'd
be great to actually meet some of you in person.  We should share some
breakfast tacos or interior Mexican food!

>> Being in Europe, it is very unlikely I'll come to Scipy this year, but I
>> think it is a great idea to organize a sprint during this period.
>>
>>
>> I'll also try to set up some sort of remote communication tool (such as
>> Google Hangouts, or even just IRC) so that people can "participate" in the
>> sprint remotely.
>
>
> There's a #matplotlib chanel on irc, where a dozen people hang out. That
> could be a nice place to gather people during the sprint.

Is this on freenode?  I joined it yesterday to scope it out but it was
pretty quiet.

>
>>
>>
>>
>>
>>>
>>> It might be helpful to start brainstorming now about which projects we
>>> may want to tackle so that we can have as much in place as possible by then
>>> and hit the ground running.
>>
>>
>> One of the things I think would be great to tackle is the replacement of
>> the Travis bot. Ideally, I'd like to see a pep8 check of each patch and a
>> daily build of the documentation on master in addition of the tests.
>>
>>
>> Agreed.  That's definitely on my todo list.  We've got some funding
>> through my employer to pay for continuous integration hosting -- it's just
>> taking a while to work its way through the system.  Once we have some sort
>> of paid hosting system, we should be able to do a lot more than Travis
>> currently can.
>>
>> Mike
>>
>>
>>
>>>
>>>
>>> I've set up a wiki page here:
>>>
>>> https://github.com/matplotlib/matplotlib/wiki/Scipy-2013

I have edited the Wiki to confirm my attendance.

-- 
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] SciPy 2013

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

On 22 March 2013 18:06, Michael Droettboom <md...@st...> wrote:

>  On 03/22/2013 12:45 PM, Nelle Varoquaux wrote:
>
>
>   I'm hoping to host a matplotlib sprint during the final two days of
>> Scipy 2013 this year, and I hope to see as many as possible of you there.
>> I think it's also really important to bring new developers into sprints,
>> because it's such an efficient way to get people familiar with the code
>> base.
>>
>
>  Being in Europe, it is very unlikely I'll come to Scipy this year, but I
> think it is a great idea to organize a sprint during this period.
>
>
> I'll also try to set up some sort of remote communication tool (such as
> Google Hangouts, or even just IRC) so that people can "participate" in the
> sprint remotely.
>

There's a #matplotlib chanel on irc, where a dozen people hang out. That
could be a nice place to gather people during the sprint.


>
>
>
>
>>  It might be helpful to start brainstorming now about which projects we
>> may want to tackle so that we can have as much in place as possible by then
>> and hit the ground running.
>>
>
>  One of the things I think would be great to tackle is the replacement of
> the Travis bot. Ideally, I'd like to see a pep8 check of each patch and a
> daily build of the documentation on master in addition of the tests.
>
>
> Agreed.  That's definitely on my todo list.  We've got some funding
> through my employer to pay for continuous integration hosting -- it's just
> taking a while to work its way through the system.  Once we have some sort
> of paid hosting system, we should be able to do a lot more than Travis
> currently can.
>
> Mike
>
>
>
>
>>
>> I've set up a wiki page here:
>>
>> https://github.com/matplotlib/matplotlib/wiki/Scipy-2013
>>
>> Mike
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
>

Re: [matplotlib-devel] SciPy 2013

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

On 03/22/2013 12:45 PM, Nelle Varoquaux wrote:
>
>     I'm hoping to host a matplotlib sprint during the final two days
>     of Scipy 2013 this year, and I hope to see as many as possible of
>     you there.  I think it's also really important to bring new
>     developers into sprints, because it's such an efficient way to get
>     people familiar with the code base.
>
>
> Being in Europe, it is very unlikely I'll come to Scipy this year, but 
> I think it is a great idea to organize a sprint during this period.

I'll also try to set up some sort of remote communication tool (such as 
Google Hangouts, or even just IRC) so that people can "participate" in 
the sprint remotely.

>     It might be helpful to start brainstorming now about which
>     projects we may want to tackle so that we can have as much in
>     place as possible by then and hit the ground running.
>
>
> One of the things I think would be great to tackle is the replacement 
> of the Travis bot. Ideally, I'd like to see a pep8 check of each patch 
> and a daily build of the documentation on master in addition of the tests.

Agreed.  That's definitely on my todo list.  We've got some funding 
through my employer to pay for continuous integration hosting -- it's 
just taking a while to work its way through the system.  Once we have 
some sort of paid hosting system, we should be able to do a lot more 
than Travis currently can.

Mike

>
>     I've set up a wiki page here:
>
>     https://github.com/matplotlib/matplotlib/wiki/Scipy-2013
>
>     Mike
>
>     ------------------------------------------------------------------------------
>     Everyone hates slow websites. So do we.
>     Make your web apps faster with AppDynamics
>     Download AppDynamics Lite for free today:
>     http://p.sf.net/sfu/appdyn_d2d_mar
>     _______________________________________________
>     Matplotlib-devel mailing list
>     Mat...@li...
>     <mailto:Mat...@li...>
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Re: [matplotlib-devel] SciPy 2013

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

>  I'm hoping to host a matplotlib sprint during the final two days of Scipy
> 2013 this year, and I hope to see as many as possible of you there.  I
> think it's also really important to bring new developers into sprints,
> because it's such an efficient way to get people familiar with the code
> base.
>

Being in Europe, it is very unlikely I'll come to Scipy this year, but I
think it is a great idea to organize a sprint during this period.


> It might be helpful to start brainstorming now about which projects we may
> want to tackle so that we can have as much in place as possible by then and
> hit the ground running.
>

One of the things I think would be great to tackle is the replacement of
the Travis bot. Ideally, I'd like to see a pep8 check of each patch and a
daily build of the documentation on master in addition of the tests.


>
> I've set up a wiki page here:
>
> https://github.com/matplotlib/matplotlib/wiki/Scipy-2013
>
> Mike
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

[matplotlib-devel] SciPy 2013

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

I'm hoping to host a matplotlib sprint during the final two days of 
Scipy 2013 this year, and I hope to see as many as possible of you 
there.  I think it's also really important to bring new developers into 
sprints, because it's such an efficient way to get people familiar with 
the code base.

It might be helpful to start brainstorming now about which projects we 
may want to tackle so that we can have as much in place as possible by 
then and hit the ground running.

I've set up a wiki page here:

https://github.com/matplotlib/matplotlib/wiki/Scipy-2013

Mike

Re: [matplotlib-devel] RFC: Moving plots out of axes

[Thomas K. <th...@kl...>]

On 15 March 2013 17:18, Nathaniel Smith <nj...@po...> wrote:

> On 15 Mar 2013 16:50, "Todd" <tod...@gm...> wrote:
> > Within the axes constructor, the constructor would run through each of
> these modules and store them as attributes with the same name as the
> function and the function itself being the contents.  At least if me
> understanding is correct, this would make them behave as methods (since
> they are already set up to take an axes instance as their first argument).
>
> This won't work as described - the function -> unbound method -> bound
> method magic only happens for attributes that aren't found in the object
> dict, when  lookup falls back on the type dict. You'll want to inject the
> functions into the Axes type object, either via a metaclass constructor or
> just by hand after the type is created.
>

You can manually create bound methods using types.MethodType, if necessary.
However, I think adding them to the class is preferable.

Thomas

Re: [matplotlib-devel] RFC: Moving plots out of axes

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

On 15 Mar 2013 16:50, "Todd" <tod...@gm...> wrote:
> Within the axes constructor, the constructor would run through each of
these modules and store them as attributes with the same name as the
function and the function itself being the contents.  At least if me
understanding is correct, this would make them behave as methods (since
they are already set up to take an axes instance as their first argument).

This won't work as described - the function -> unbound method -> bound
method magic only happens for attributes that aren't found in the object
dict, when  lookup falls back on the type dict. You'll want to inject the
functions into the Axes type object, either via a metaclass constructor or
just by hand after the type is created.

-n

Re: [matplotlib-devel] How to contribute a new kind of plot

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

On Thu, Mar 14, 2013 at 1:50 AM, Pierre Barbier de Reuille <
pi...@ba...> wrote:

> Hello,
>
> for my own research, I have implemented a function plotting datasets as
> violin plots ( http://en.wikipedia.org/wiki/Violin_plot ). I attach an
> example output that I am using.
>
> It is fairly stand-alone, with the expection of a scipy dependency for
> computation of the estimated density of probability of the shown. Before
> distribution, I will need to document the function and classes associated.
>
> My question is: what is the process if there a place I can make the code
> available for consideration?
>
> Thanks,
>
>
Pierre,

The scipy dependency is unfortunately a deal breaker for matplotlib. I'm
not a core dev, but typically you have a work around the dependency in some
way (e.g., make the user specify the KDE for each dataset).

Also, the statsmodels project has this functionality:
http://statsmodels.sourceforge.net/devel/generated/statsmodels.graphics.boxplots.violinplot.html#statsmodels.graphics.boxplots.violinplot

Perhaps your ideas and approach could be used to improve
their implementation.
-paul

[matplotlib-devel] RFC: Moving plots out of axes

[Todd <tod...@gm...>]

Currently, many of the plot types reside in axes.  This makes sense from a
structural standpoint, since the plots are generally a part of an axes.
However, it makes things more difficult from a practical standpoint.
First, it means that the axes class is huge, with both core axes-related
methods and plotting-related methods.  Second, it means that boilerplate.py
has to be told explicitly which methods to use, rather than just grabbing
everything from a module.  Third, it makes it impossible to break the plot
types into smaller groups of related plots.

The solution, I think, is to move the plots into one or more modules and
implement them as functions.  They would have the same call signature as
now, we would just replace "self" with "ax" or something like that.  This
would allow you to, theoretically, import and call them without axes, but
this would probably not be common.

Within the axes constructor, the constructor would run through each of
these modules and store them as attributes with the same name as the
function and the function itself being the contents.  At least if me
understanding is correct, this would make them behave as methods (since
they are already set up to take an axes instance as their first argument).

The axes would just be left with the methods related to manipulating the
axes themselves.

This would also simplify boilerplate.py, since it would simply need to know
the names of the modules rather than the name of every plot type.  It would
then just run through the functions in the modules (or even just run
through all modules in a particular directory).  We would probably even be
able to do away with that portion of boilerplate.py completely, creating
the plotting functions in on-the-fly in pyplot at runtime, but that is a
separate issue.

What does everyone think of this approach?

Re: [matplotlib-devel] [Matplotlib-users] Feedback on an implementation of a matlab-ish "datacursor"

[Joe K. <jki...@ge...>]

Hi Phil,

On Wed, Mar 13, 2013 at 5:14 AM, Phil Elson <pel...@gm...> wrote:

> Joe,
>
> Do you have any feeling for performance of mpldatacursor? I'm interested
> to know if implementing this functionality by default (with an rcParam
> switch to disable) on all Axes would have a significant impact on
> performance?
>

It should be quite fast.  In most cases only one extra annotation object
per-axes will be created.  The annotation is updated, rather than a new one
being created, unless that's specifically what's desired (e.g. The
display='multiple' option).


>
>
> > If it is something that other people find useful, I'd be happy to submit
> a pull request to incorporate it into matplotlib.
>
> Personally, I find this kind of extension better as a completely separate
> piece of work which one could "pip install" - it means you can be more
> flexible with release cycles, especially in the early days of the code when
> regular updates are most likely. Though I should note, I'm not against it
> being included in mpl as an extension, if you would prefer that.
>

Good point! Especially in its current state, flexibility is a good thing!


>
>
> Thanks again for sharing!
>

Thanks! Glad to!

Cheers!
-Joe





On 13 March 2013 10:08, Phil Elson <pel...@gm...> wrote:

> Thanks for this Joe, mpldatacursor looks like an excellent piece of work -
> I for one will be installing and using it regularly.
>
> Thanks for sharing!
>
>
>
>
>
> On 13 March 2013 03:58, Joe Kington <jof...@gm...> wrote:
>
>> I recently got around to polishing up a snippet I've been using for quite
>> awhile.  https://github.com/joferkington/mpldatacursor/  and I was
>> hoping to get some feeding on the current implementation.
>>
>> "mpldatacursor" allows a user to easily click on an artist and display a
>> customizable, interactive pop-up box displaying information about the
>> selected artist (e.g. x & y, label, z for images and collections, etc).
>> It's a stand-alone module (and in pypi), but you could also just download
>> the examples directory from github and copy the mpldatacursor.py file into
>> it to try things out.
>>
>> A few key questions:
>>
>>    1. Is this something that anyone else finds useful?
>>
>>    2. Does it seem intuitive?
>>
>>    3. Does the implementation seem flexible enough for most needs? (Note
>>    that any additional kwargs are passed on to annotate to create the "data
>>    cursor", so the appearance of the box is customizable through annotation
>>    kwargs.)
>>
>>    4. Are there any obvious features missing?
>>
>>    5. Any suggestions? (especially better name suggestions...)
>>
>> If it is something that other people find useful, I'd be happy to submit
>> a pull request to incorporate it into matplotlib.  (If I did, it would
>> probably be best to drop the HighlightDataCursor class, as its limited in
>> what it can do.)
>>
>> Thanks a bunch!
>>
>> -Joe
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-dev<https://lists.sourceforge.net/lists/listinfo/matplotlib-devel>

Re: [matplotlib-devel] [Matplotlib-users] Feedback on an implementation of a matlab-ish "datacursor"

[Phil E. <pel...@gm...>]

Joe,

Do you have any feeling for performance of mpldatacursor? I'm interested to
know if implementing this functionality by default (with an rcParam switch
to disable) on all Axes would have a significant impact on performance?


> If it is something that other people find useful, I'd be happy to submit
a pull request to incorporate it into matplotlib.

Personally, I find this kind of extension better as a completely separate
piece of work which one could "pip install" - it means you can be more
flexible with release cycles, especially in the early days of the code when
regular updates are most likely. Though I should note, I'm not against it
being included in mpl as an extension, if you would prefer that.


Thanks again for sharing!





On 13 March 2013 10:08, Phil Elson <pel...@gm...> wrote:

> Thanks for this Joe, mpldatacursor looks like an excellent piece of work -
> I for one will be installing and using it regularly.
>
> Thanks for sharing!
>
>
>
>
>
> On 13 March 2013 03:58, Joe Kington <jof...@gm...> wrote:
>
>> I recently got around to polishing up a snippet I've been using for quite
>> awhile.  https://github.com/joferkington/mpldatacursor/  and I was
>> hoping to get some feeding on the current implementation.
>>
>> "mpldatacursor" allows a user to easily click on an artist and display a
>> customizable, interactive pop-up box displaying information about the
>> selected artist (e.g. x & y, label, z for images and collections, etc).
>> It's a stand-alone module (and in pypi), but you could also just download
>> the examples directory from github and copy the mpldatacursor.py file into
>> it to try things out.
>>
>> A few key questions:
>>
>>    1. Is this something that anyone else finds useful?
>>
>>    2. Does it seem intuitive?
>>
>>    3. Does the implementation seem flexible enough for most needs? (Note
>>    that any additional kwargs are passed on to annotate to create the "data
>>    cursor", so the appearance of the box is customizable through annotation
>>    kwargs.)
>>
>>    4. Are there any obvious features missing?
>>
>>    5. Any suggestions? (especially better name suggestions...)
>>
>> If it is something that other people find useful, I'd be happy to submit
>> a pull request to incorporate it into matplotlib.  (If I did, it would
>> probably be best to drop the HighlightDataCursor class, as its limited in
>> what it can do.)
>>
>> Thanks a bunch!
>>
>> -Joe
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>

Re: [matplotlib-devel] 1.2.1rc1 Tagged

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

In article <513...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:

> On 03/07/2013 06:48 PM, Russell E. Owen wrote:
> > In article <513...@st...>,
> >   Michael Droettboom <md...@st...>
> >   wrote:
> >
> >> We've finally squashed all of the bugs slated for 1.2.1, so I have
> >> tagged a 1.2.1rc1 for testing....
> >>
> >> It can be downloaded from the SF files server here:
> >>
> >> http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.2.
> >> 1rc
> >> 1/matplotlib-1.2.1rc1.tar.gz/download
> >>...
> > I uploaded two Mac binaries to SourceForge...
> >
> > They are both built against numpy 1.6.2, which is not ideal, but is the
> > best I can do at the moment.
> >
> I think that's fine for now -- for the rc it's most important to just 
> make sure that working packages *can* be built.  We can reevaluate what 
> Numpy version to use for the final release, and let me know if we should 
> push back the final release date to accomodate rejiggering your 
> development environment etc.

Do you have an opinion on the best numpy to use for matplotlib 1.2 
binaries?

Some considerations:

I think numpy 1.7.x is binary compatible with 1.6.x. If so, surely it is 
OK to build matplotlib against numpy 1.6.x, even if a user wants to use 
numpy 1.7.x? I have not tested this (nor the reverse direction).

numpy 1.7.0 has a serious memory leak (though I don't know how many 
users would ever see it). 1.7.1 is due out fairly soon. Personally I 
would rather skip 1.7.0 on my own machine. Yet it would be wise to let 
1.7.1 be used for a week or two before relying on it and I'd hate to 
hold up release of matplotlib 1.2.1.

-- Russell

Re: [matplotlib-devel] [Matplotlib-users] DLL Load failure for matploltlib._png

[Christoph G. <cg...@uc...>]

On 3/8/2013 2:16 AM, Tejashri Kandolkar wrote:
> Thanks Christoph, thanks for the help.
>
> However I found the issue.
> The issue is that somehow matplotlib_release variant linked to the debug
> lib of libpng.
> And so on a non-developer machine, which dosent have msvcr90d.dll (debug
> crt), DLL Load fails.

Good to know. The zlib, png and freetype libraries should be built as 
"Release, Static Library, Multi-threaded DLL" to be compatible with 
CPython. See also <https://github.com/matplotlib/matplotlib/issues/1717>

>
> So now I have another question:
>
> I have built the static libs of freetype, libpng (and zlib which is
> required by libpng) from source
> And I mention the paths of these static libs in setupext.py (by
> modifying "basedir") while building matplotlib.

No need to modify the source code. You can add the directories 
containing the headers and libraries to the INCLUDE and LIB environment 
variables.

>
> Now when matplotlib builds, and generates a _png.pyd, will it still need
> the static libs to be present in the location where the _png.pyd is present?
> What I understand is that it shouldn't since it is a static library and
> should be built into the binary.

The static libs are not needed at runtime. They are part of the pyd binary.

>
> Why I am asking this is because I am unable to build the libpng DLLs
> (for some reason I dont know).
> So I have to go forward with the static lib approach.

The static approach is recommended. If you link to the DLLs instead you 
will need to ship those with the binaries, which is not done in setup.py.

Christoph

>
> Thanks,
> Regards,
> Tej.
>
> On Thu, Mar 7, 2013 at 10:53 PM, Christoph Gohlke <cg...@uc...
> <mailto:cg...@uc...>> wrote:
>
>     On 3/7/2013 8:39 AM, Christoph Gohlke wrote:
>     > On 3/7/2013 6:00 AM, Tejashri Kandolkar wrote:
>     >> Hi,
>     >>
>     >> I built matplotlib1.2.0 with python3.2 on Windows7 from source.
>     >> I built the libpng and freetype libs and linked them statically to
>     >> matplotlib.
>     >>
>     >> Everything works fine on my machine, I can run the matplotlib examples etc
>     >> But on a new Win7 machine(with the exact same configuration as mine,
>     >> except a few softwares), I get the following error when i try to import
>     >> png module like this:
>     >>
>     >> import matplotlib._png
>     >>
>     >> ImportError: DLL load failed: The application has failed to start
>     >> because its side-by-side configuration is incorrect. Please see the
>     >> application event log or use the command-line sxstrace.exe tool for more
>     >> detail.
>     >>
>     >>
>     >> I used the dependency walker and found that pyd_ DLL was indeed having
>     >> issues during load.
>     >>
>     >> What could be the reason. Surprisingly it works all fine on my machine.
>     >>
>     >>
>     >> Regards,
>     >> Tej
>     >>
>     >
>     > Assuming this is 32 bit Python, install the Microsoft Visual C++ 2008
>     > Redistributable Package (x86) <from
>     >http://www.microsoft.com/en-us/download/details.aspx?id=29>
>     >
>
>     Besides that, look for extra msvcp90.dll or msvcr90.dll files in PATH
>     (for example MikteX is known for that) and resolve conflicts.
>
>     Christoph
>
>     ------------------------------------------------------------------------------
>     Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
>     Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
>     endpoint security space. For insight on selecting the right partner to
>     tackle endpoint security challenges, access the full report.
>     http://p.sf.net/sfu/symantec-dev2dev
>     _______________________________________________
>     Matplotlib-users mailing list
>     Mat...@li...
>     <mailto:Mat...@li...>
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Re: [matplotlib-devel] 1.2.1rc1 Tagged

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

On 03/07/2013 06:48 PM, Russell E. Owen wrote:
> In article <513...@st...>,
>   Michael Droettboom <md...@st...>
>   wrote:
>
>> We've finally squashed all of the bugs slated for 1.2.1, so I have
>> tagged a 1.2.1rc1 for testing.  This is a bugfix release, and improves
>> on the overall quality of 1.2.0.  Thanks to everyone who worked hard to
>> fix a multitude of papercuts.  I'll provide a more detailed list of
>> changes in the announcement of the final version.
>>
>> It can be downloaded from the SF files server here:
>>
>> http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.2.1rc
>> 1/matplotlib-1.2.1rc1.tar.gz/download
>>
>> Packagers: I don't expect a lot of glitches as nothing significant has
>> changed about the build since 1.2.0, but now is the best time to try to
>> build for your various packaging systems and report back any problems.
>> If all goes well, I plan to make a final release in approximately two
>> weeks on March 25.
> I uploaded two Mac binaries to SourceForge:
> - A 10.3-compatible version built and tested on 10.4
> - A 10.6-compatible version built and tested on 10.8 (I should also test
> it on 10.6 but don't have time right now).
>
> They are both built against numpy 1.6.2, which is not ideal, but is the
> best I can do at the moment.
>
I think that's fine for now -- for the rc it's most important to just 
make sure that working packages *can* be built.  We can reevaluate what 
Numpy version to use for the final release, and let me know if we should 
push back the final release date to accomodate rejiggering your 
development environment etc.

Cheers,
Mike

Re: [matplotlib-devel] [Matplotlib-users] DLL Load failure for matploltlib._png

[Tejashri K. <tej...@gm...>]

On Fri, Mar 8, 2013 at 3:46 PM, Tejashri Kandolkar <
tej...@gm...> wrote:

> Thanks Christoph, thanks for the help.
>
> However I found the issue.
> The issue is that somehow matplotlib_release variant linked to the debug
> lib of libpng.
> And so on a non-developer machine, which dosent have msvcr90d.dll (debug
> crt), DLL Load fails.
>
> So now I have another question:
>
> I have built the static libs of freetype, libpng (and zlib which is
> required by libpng) from source
> And I mention the paths of these static libs in setupext.py (by modifying
> "basedir") while building matplotlib.
>
> Now when matplotlib builds, and generates a _png.pyd, will it still need
> the static libs to be present in the location where the _png.pyd is present?
> What I understand is that it shouldn't since it is a static library and
> should be built into the binary.
>
> Why I am asking this is because I am unable to build the libpng DLLs (for
> some reason I dont know).
> So I have to go forward with the static lib approach.
>
> Thanks,
> Regards,
> Tej.
>
>
> On Thu, Mar 7, 2013 at 10:53 PM, Christoph Gohlke <cg...@uc...> wrote:
>
>> On 3/7/2013 8:39 AM, Christoph Gohlke wrote:
>> > On 3/7/2013 6:00 AM, Tejashri Kandolkar wrote:
>> >> Hi,
>> >>
>> >> I built matplotlib1.2.0 with python3.2 on Windows7 from source.
>> >> I built the libpng and freetype libs and linked them statically to
>> >> matplotlib.
>> >>
>> >> Everything works fine on my machine, I can run the matplotlib examples
>> etc
>> >> But on a new Win7 machine(with the exact same configuration as mine,
>> >> except a few softwares), I get the following error when i try to import
>> >> png module like this:
>> >>
>> >> import matplotlib._png
>> >>
>> >> ImportError: DLL load failed: The application has failed to start
>> >> because its side-by-side configuration is incorrect. Please see the
>> >> application event log or use the command-line sxstrace.exe tool for
>> more
>> >> detail.
>> >>
>> >>
>> >> I used the dependency walker and found that pyd_ DLL was indeed having
>> >> issues during load.
>> >>
>> >> What could be the reason. Surprisingly it works all fine on my machine.
>> >>
>> >>
>> >> Regards,
>> >> Tej
>> >>
>> >
>> > Assuming this is 32 bit Python, install the Microsoft Visual C++ 2008
>> > Redistributable Package (x86) <from
>> > http://www.microsoft.com/en-us/download/details.aspx?id=29>
>> >
>>
>> Besides that, look for extra msvcp90.dll or msvcr90.dll files in PATH
>> (for example MikteX is known for that) and resolve conflicts.
>>
>> Christoph
>>
>>
>> ------------------------------------------------------------------------------
>> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
>> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
>> endpoint security space. For insight on selecting the right partner to
>> tackle endpoint security challenges, access the full report.
>> http://p.sf.net/sfu/symantec-dev2dev
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>
>

Re: [matplotlib-devel] 1.2.1rc1 Tagged

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

In article <513...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:

> We've finally squashed all of the bugs slated for 1.2.1, so I have 
> tagged a 1.2.1rc1 for testing.  This is a bugfix release, and improves 
> on the overall quality of 1.2.0.  Thanks to everyone who worked hard to 
> fix a multitude of papercuts.  I'll provide a more detailed list of 
> changes in the announcement of the final version.
> 
> It can be downloaded from the SF files server here:
> 
> http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.2.1rc
> 1/matplotlib-1.2.1rc1.tar.gz/download
> 
> Packagers: I don't expect a lot of glitches as nothing significant has 
> changed about the build since 1.2.0, but now is the best time to try to 
> build for your various packaging systems and report back any problems.  
> If all goes well, I plan to make a final release in approximately two 
> weeks on March 25.

I uploaded two Mac binaries to SourceForge:
- A 10.3-compatible version built and tested on 10.4
- A 10.6-compatible version built and tested on 10.8 (I should also test 
it on 10.6 but don't have time right now).

They are both built against numpy 1.6.2, which is not ideal, but is the 
best I can do at the moment.

-- Russell

Re: [matplotlib-devel] 1.2.1rc1 Tagged

[Christoph G. <cg...@uc...>]

On 3/7/2013 11:30 AM, Michael Droettboom wrote:
> We've finally squashed all of the bugs slated for 1.2.1, so I have
> tagged a 1.2.1rc1 for testing.  This is a bugfix release, and improves
> on the overall quality of 1.2.0.  Thanks to everyone who worked hard to
> fix a multitude of papercuts.  I'll provide a more detailed list of
> changes in the announcement of the final version.
>
> It can be downloaded from the SF files server here:
>
> http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.2.1rc1/matplotlib-1.2.1rc1.tar.gz/download
>
> Packagers: I don't expect a lot of glitches as nothing significant has
> changed about the build since 1.2.0, but now is the best time to try to
> build for your various packaging systems and report back any problems.
> If all goes well, I plan to make a final release in approximately two
> weeks on March 25.
>
> Cheers,
> Mike

Thanks. It builds and tests OK on Windows. Should I upload the binaries 
to SF? They are built against numpy 1.7 and therefore require numpy >= 
1.7.0.

Christoph

Re: [matplotlib-devel] 1.2.1rc1 Tagged

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

On Thu, Mar 7, 2013 at 1:30 PM, Michael Droettboom <md...@st...> wrote:
> Packagers: I don't expect a lot of glitches as nothing significant has
> changed about the build since 1.2.0, but now is the best time to try to
> build for your various packaging systems and report back any problems.

Ryan, if you're out there, let me know if you run into snags with
building for the Mac.

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

[matplotlib-devel] 1.2.1rc1 Tagged

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

We've finally squashed all of the bugs slated for 1.2.1, so I have 
tagged a 1.2.1rc1 for testing.  This is a bugfix release, and improves 
on the overall quality of 1.2.0.  Thanks to everyone who worked hard to 
fix a multitude of papercuts.  I'll provide a more detailed list of 
changes in the announcement of the final version.

It can be downloaded from the SF files server here:

http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.2.1rc1/matplotlib-1.2.1rc1.tar.gz/download

Packagers: I don't expect a lot of glitches as nothing significant has 
changed about the build since 1.2.0, but now is the best time to try to 
build for your various packaging systems and report back any problems.  
If all goes well, I plan to make a final release in approximately two 
weeks on March 25.

Cheers,
Mike

Re: [matplotlib-devel] GSOC 2013 (Google Summer Of Code)

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

On 03/07/2013 12:45 PM, Damon McDougall wrote:
> I'm really lost when it comes to how to could optimise our rendering, 
> especially with text rendering being extremely slow at present.

Let's put some benchmarks together for this.  There's a lot of 
optimizations to the text rendering in the Agg backend already (caching 
pre-rendered text etc.), so if there's anything more to be done, we 
should get to the bottom of it.

Mike

Re: [matplotlib-devel] GSOC 2013 (Google Summer Of Code)

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

On Thu, Mar 7, 2013 at 9:24 AM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Thu, Mar 7, 2013 at 10:12 AM, Michael Droettboom <md...@st...> wrote:
>>
>> Ah, yes.  I forgot that my issues with trying to do rendering in the
>> browser shared some similarities here.
>>
>> When I did the last major backend refactoring (which is coming on 6
>> years ago now), I considered exactly this, which is why draw_path takes
>> both a path object (which is unlikely to change) and a transform.  It
>> turned out to not be terribly useful for most the backends we have,
>> since PDF, PS, SVG (at least in the versions of the specs we're using)
>> all scale the stroke width along with the vertices, so you couldn't, for
>> example, zoom in on a line plot without the line width exploding.  The
>> Agg backend is able to perform the transform itself since we wrote it to
>> not scale the stroke using the path's transform, but there's little
>> advantage since it's all software anyway.  But the API still works this
>> way even if nothing takes advantage of it.  Though technically paths are
>> mutable, since they store Numpy arrays which are mutable, in practice
>> they are rarely if never mutated (I'll have to verify this, but
>> certainly in the course of panning and zooming, they wouldn't be), so it
>> should be possible to know whether a path is already on the GPU by
>> checking its id against a table of what's on the GPU.
>>
>> The other wrinkle is that the transform is a combination of affine
>> transforms (which I'm sure OpenGL handles just fine) with arbitrary
>> transforms such as log scaling or polar transformations.  I assume this
>> would all have to be implemented as a vertex shader to get the
>> performance benefits of OpenGL.  We could probably implement all of the
>> transforms built in to matplotlib (which cover a lot of cases), and then
>> just provide some slow "escape route" to handle arbitrary transforms
>> written in Numpy/Python, and for bonus points provide a hook for users
>> to add their own OpenGL transforms (just as it would have been necessary
>> to do with Javascript in the case of web browser rendering).  But I bet
>> a lot of people would be happy as a start to just have the built-in
>> transforms working.
>>
>> The last thing to raise is the case of very large data.  When I was
>> investigating rendering in a web browser, there were pretty low limits
>> to the number of vertices I could keep hold of in the browser.
>> matplotlib has a "path simplification" algorithm to reduce the number of
>> vertices without changing the appearance of the plot, but of course
>> that's dependant on the scale, so it has to be rerun every time the
>> scale changes.  While path simplification may not be as necessary for
>> speed on the GPU, it may be necessary due to memory constraints.
>>
>> Mike
>>
>
> Just to voice what my main interest in an OpenGL backend is a chance to move
> away from the layering approach of the matplotlib renderer to the ability to
> specify three dimensional data to plot.  Performance is a nice side-benefit,
> certainly, but breaking out our low-level assumptions of how we plot would
> be refreshing.

I agree here.  I would certainly benefit from this.  I'm really lost
when it comes to how to could optimise our rendering, especially with
text rendering being extremely slow at present.

I am, however, a little concerned we may be reinventing the wheel here
with useful tools that already exist for 3d rendering.  Paraview and
MayaVi come to mind.

>
> Ben Root
>
>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> 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] GSOC 2013 (Google Summer Of Code)

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

On Thu, Mar 7, 2013 at 10:12 AM, Michael Droettboom <md...@st...> wrote:

> Ah, yes.  I forgot that my issues with trying to do rendering in the
> browser shared some similarities here.
>
> When I did the last major backend refactoring (which is coming on 6
> years ago now), I considered exactly this, which is why draw_path takes
> both a path object (which is unlikely to change) and a transform.  It
> turned out to not be terribly useful for most the backends we have,
> since PDF, PS, SVG (at least in the versions of the specs we're using)
> all scale the stroke width along with the vertices, so you couldn't, for
> example, zoom in on a line plot without the line width exploding.  The
> Agg backend is able to perform the transform itself since we wrote it to
> not scale the stroke using the path's transform, but there's little
> advantage since it's all software anyway.  But the API still works this
> way even if nothing takes advantage of it.  Though technically paths are
> mutable, since they store Numpy arrays which are mutable, in practice
> they are rarely if never mutated (I'll have to verify this, but
> certainly in the course of panning and zooming, they wouldn't be), so it
> should be possible to know whether a path is already on the GPU by
> checking its id against a table of what's on the GPU.
>
> The other wrinkle is that the transform is a combination of affine
> transforms (which I'm sure OpenGL handles just fine) with arbitrary
> transforms such as log scaling or polar transformations.  I assume this
> would all have to be implemented as a vertex shader to get the
> performance benefits of OpenGL.  We could probably implement all of the
> transforms built in to matplotlib (which cover a lot of cases), and then
> just provide some slow "escape route" to handle arbitrary transforms
> written in Numpy/Python, and for bonus points provide a hook for users
> to add their own OpenGL transforms (just as it would have been necessary
> to do with Javascript in the case of web browser rendering).  But I bet
> a lot of people would be happy as a start to just have the built-in
> transforms working.
>
> The last thing to raise is the case of very large data.  When I was
> investigating rendering in a web browser, there were pretty low limits
> to the number of vertices I could keep hold of in the browser.
> matplotlib has a "path simplification" algorithm to reduce the number of
> vertices without changing the appearance of the plot, but of course
> that's dependant on the scale, so it has to be rerun every time the
> scale changes.  While path simplification may not be as necessary for
> speed on the GPU, it may be necessary due to memory constraints.
>
> Mike
>
>
Just to voice what my main interest in an OpenGL backend is a chance to
move away from the layering approach of the matplotlib renderer to the
ability to specify three dimensional data to plot.  Performance is a nice
side-benefit, certainly, but breaking out our low-level assumptions of how
we plot would be refreshing.

Ben Root