matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] Custom plot_trisurf triangulations

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

On Fri, Sep 21, 2012 at 6:21 PM, Ian Thomas <ian...@gm...> wrote:
> I am happy with option 3 too, but I don't think you need to do as much as
> this.  The existing 2d triplot/tripcolor/tricontour call
> Triangulation.get_from_args_and_kwargs, which removes the various
> args/kwargs needed for the triangulation and leaves the remainder for the
> calling function to process.  For example lib/matplotlib/tri/tricontour.py
> lines 86 to 88:
>
> tri, args, kwargs = \
>     Triangulation.get_from_args_and_kwargs(*args, **kwargs)
> z = np.asarray(args[0])
>
> Can't you just do the same here, or am I missing something?

Ah ok, I see. I was assuming a plot_trisurf(x, y, z, triangles, ...)
signature. Copying the tricontour signature would be better for
consistency reasons. It appears that I was the one missing something!

Thanks for that.

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

[Sandro T. <san...@gm...>]

On Thu, Sep 20, 2012 at 8:48 PM, Michael Droettboom <md...@st...> wrote:
> The source of that file has always been `matplotlibrc.template` at the root
> of the source tree.  That file is copied (by the build process) to
> lib/matplotlib/mpl-data/matplotlibrc, but it doesn't exist in the raw source
> tree.

ah nice, so I was using something outdated

> I'm not sure what matplotlib.conf is or was -- but I hope
> matplotlibrc.template fits the bill for the Debian package's purposes.

Absolutely, thanks for the quick reply!

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Re: [matplotlib-devel] Custom plot_trisurf triangulations

[Ian T. <ian...@gm...>]

On 21 September 2012 14:38, Benjamin Root <ben...@ou...> wrote:

> On Fri, Sep 21, 2012 at 6:43 AM, Damon McDougall <
> dam...@gm...> wrote:
>
>> On Fri, Sep 21, 2012 at 8:27 AM, Ian Thomas <ian...@gm...>
>> wrote:
>> > On 20 September 2012 22:30, Damon McDougall <dam...@gm...>
>> > wrote:
>>
> 3. Create a new args_2d tuple exactly equal to *args but with 'z'
>> removed. Then rely on the 2d code with:
>> Triangulation.get_from_args_and_kwargs(args_2d, **kwargs). Since this
>> option would be common to all 3d functions relying on the 2d heavy
>> lifting, it could be wrapped up into a convenience function.
>>
>> In my opinion, option 3. is preferable. Option 3. will also produce
>> commits with the highest signal-to-noise ratio.
>>
>>
> I agree with option 3.  It fits in nicely with the paradigms of the
> existing codebase (my recent contributions excluded...)
>

I am happy with option 3 too, but I don't think you need to do as much as
this.  The existing 2d triplot/tripcolor/tricontour call
Triangulation.get_from_args_and_kwargs, which removes the various
args/kwargs needed for the triangulation and leaves the remainder for the
calling function to process.  For example lib/matplotlib/tri/tricontour.py
lines 86 to 88:

tri, args, kwargs = \
    Triangulation.get_from_args_and_kwargs(*args, **kwargs)
z = np.asarray(args[0])

Can't you just do the same here, or am I missing something?

> A wider issue, and something I should have mentioned when you first
>> > implemented plot_trisurf, is that I don't like the function name.  It
>> seems
>> > unnecessary to have the plot_ at the front as most of the other
>> plot-related
>> > functions manage without it.  My unease extends to plot_surface and
>> > plot_wireframe as well.  I guess we can't just change such names now
>> that
>> > they are being used, but eventually I would like to see better naming
>> within
>> > mplot3d.
>> >
>>
>>
>> Agreed. Not sure how best to solve this. Furthermore, I think it
>> should be implemented in a pull request separate to the one migrating
>> these 3d methods to custom triangulations.
>>
>>
> I wouldn't be against going down a deprecation path for renaming these
> functions, but for what gains?  The names have been there since before I
> took up this toolkit, and ultimately, these functions aren't typed so often
> that brevity would gain one much.  Definitely any new functions should not
> take up that naming, but I see no real compelling reason to change the
> existing names.
>

The gain is that of more consistent naming of the mplot3d api functions.
The argument that we should keep names because they have been around for a
long time is not a strong one if the names are poor choices in the first
place.  But I am not particularly concerned as I think that mplot3d has
some bigger problems to solve than this e.g. correct rendering of nested
polygons, z-order rendering, so maybe I should keep quiet about such
details!

Ian

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

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

On 09/21/2012 09:40 AM, Benjamin Root wrote:
>
>
> On Fri, Sep 21, 2012 at 9:23 AM, Benjamin Root <ben...@ou... 
> <mailto:ben...@ou...>> wrote:
>
>
>
>     On Fri, Sep 21, 2012 at 5:30 AM, Phil Elson <pel...@gm...
>     <mailto:pel...@gm...>> wrote:
>
>         @Ben: Presumably your running one of the examples. Probably
>         changed with https://github.com/matplotlib/matplotlib/pull/921
>
>
>
>
>     That would explain it.  I forgot that the examples got modified to
>     showcase other colormaps.  I think the 3d plots need some more
>     "pop", though.  I think I will make a PR to change them from the
>     "coolwarm" colormap to something a bit more appealing.  The
>     coolwarm colors just look dull and unappealing.
>
>     Cheers!
>     Ben Root
>
>
> This raises an important question, though...  the matplotlib.org 
> <http://matplotlib.org> site has the older examples.  That particular 
> PR was merged 4 months ago.  Is the mplot3d part of the docs not 
> getting rebuilt?

The root of the documentation is still for 1.1.1 (the last released 
version).  The docs that correspond to the release candidate are under 
matplotlib.org/1.2.0 (and this is linked to from the root page).  Once 
the 1.2.0 release is made, this will be reversed, with 1.2.0 taking the 
top level and 1.1.1 relegated to an "archive" at matplotlib.org/1.1.1

Mike

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

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

On Fri, Sep 21, 2012 at 9:23 AM, Benjamin Root <ben...@ou...> wrote:

>
>
> On Fri, Sep 21, 2012 at 5:30 AM, Phil Elson <pel...@gm...> wrote:
>
>> @Ben: Presumably your running one of the examples. Probably changed with
>> https://github.com/matplotlib/matplotlib/pull/921
>>
>>
>>
>
> That would explain it.  I forgot that the examples got modified to
> showcase other colormaps.  I think the 3d plots need some more "pop",
> though.  I think I will make a PR to change them from the "coolwarm"
> colormap to something a bit more appealing.  The coolwarm colors just look
> dull and unappealing.
>
> Cheers!
> Ben Root
>
>
This raises an important question, though...  the matplotlib.org site has
the older examples.  That particular PR was merged 4 months ago.  Is the
mplot3d part of the docs not getting rebuilt?

Ben Root

Re: [matplotlib-devel] Custom plot_trisurf triangulations

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

On Fri, Sep 21, 2012 at 6:43 AM, Damon McDougall
<dam...@gm...>wrote:

> On Fri, Sep 21, 2012 at 8:27 AM, Ian Thomas <ian...@gm...> wrote:
> > On 20 September 2012 22:30, Damon McDougall <dam...@gm...>
> > wrote:
> >>
> >> I have been playing with custom triangulations in the plot_trisurf
> >> method of the mplot3d toolkit. I thought I would share my sweet
> >> creation: https://www.dropbox.com/s/ccptm6ok7nd3yn5/mobius.png
> >>
> >> Let me know your thoughts. I should probably make a pull request out
> >> of this, but the code is not currently readable by humans. I will tidy
> >> it up first. Make it look purrty.
> >
> >
> > Yes please!  Ideally it would be good if all mplot3d functions supported
> the
> > same arg and kwarg combinations as their 2d equivalents, for consistency.
> > You may have done this already, but if not you might find the 2d
> tripcolor
> > code helpful - it calls Triangulation.get_from_args_and_kwargs(*args,
> > **kwargs) to do the initial heavy lifting.
> >
>
> Yes, I had seen it. Thank you. Unfortunately, using this is
> non-trivial when you have an extra 'z' variable. There are a couple of
> options to get around this:
>
> 1. Re-write a 3d version and add it to matplotlib.tri. Pros of this
> approach are that the 3d methods would basically only require one
> extra line, a call to Triangulation.get_from_args_and_kwargs_3d(*args,
> **kwargs). Cons of this approach are code repetition. Also, I'm not a
> fan of putting 3d code into main mpl codebase. I think it should stay
> in the toolkit.
>
> 2. Implement option 1. but in the mplot3d toolkit rather than the main
> codebase.
>
> 3. Create a new args_2d tuple exactly equal to *args but with 'z'
> removed. Then rely on the 2d code with:
> Triangulation.get_from_args_and_kwargs(args_2d, **kwargs). Since this
> option would be common to all 3d functions relying on the 2d heavy
> lifting, it could be wrapped up into a convenience function.
>
> In my opinion, option 3. is preferable. Option 3. will also produce
> commits with the highest signal-to-noise ratio.
>
>
I agree with option 3.  It fits in nicely with the paradigms of the
existing codebase (my recent contributions excluded...)



>  > Forgive my cheek, but whilst you are looking at this area
> mplot3d.tricontour
> > and tricontourf need similar improvement...
> >
>
> Forgiven. I might as well do it whilst I'm already half-way down the
> rabbit hole.
>
> > A wider issue, and something I should have mentioned when you first
> > implemented plot_trisurf, is that I don't like the function name.  It
> seems
> > unnecessary to have the plot_ at the front as most of the other
> plot-related
> > functions manage without it.  My unease extends to plot_surface and
> > plot_wireframe as well.  I guess we can't just change such names now that
> > they are being used, but eventually I would like to see better naming
> within
> > mplot3d.
> >
>
> Agreed. Not sure how best to solve this. Furthermore, I think it
> should be implemented in a pull request separate to the one migrating
> these 3d methods to custom triangulations.
>
>
I wouldn't be against going down a deprecation path for renaming these
functions, but for what gains?  The names have been there since before I
took up this toolkit, and ultimately, these functions aren't typed so often
that brevity would gain one much.  Definitely any new functions should not
take up that naming, but I see no real compelling reason to change the
existing names.

Cheers!
Ben Root

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

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

On Fri, Sep 21, 2012 at 5:30 AM, Phil Elson <pel...@gm...> wrote:

> @Ben: Presumably your running one of the examples. Probably changed with
> https://github.com/matplotlib/matplotlib/pull/921
>
>
>

That would explain it.  I forgot that the examples got modified to showcase
other colormaps.  I think the 3d plots need some more "pop", though.  I
think I will make a PR to change them from the "coolwarm" colormap to
something a bit more appealing.  The coolwarm colors just look dull and
unappealing.

Cheers!
Ben Root

Re: [matplotlib-devel] Custom plot_trisurf triangulations

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

On Fri, Sep 21, 2012 at 8:27 AM, Ian Thomas <ian...@gm...> wrote:
> On 20 September 2012 22:30, Damon McDougall <dam...@gm...>
> wrote:
>>
>> I have been playing with custom triangulations in the plot_trisurf
>> method of the mplot3d toolkit. I thought I would share my sweet
>> creation: https://www.dropbox.com/s/ccptm6ok7nd3yn5/mobius.png
>>
>> Let me know your thoughts. I should probably make a pull request out
>> of this, but the code is not currently readable by humans. I will tidy
>> it up first. Make it look purrty.
>
>
> Yes please!  Ideally it would be good if all mplot3d functions supported the
> same arg and kwarg combinations as their 2d equivalents, for consistency.
> You may have done this already, but if not you might find the 2d tripcolor
> code helpful - it calls Triangulation.get_from_args_and_kwargs(*args,
> **kwargs) to do the initial heavy lifting.
>

Yes, I had seen it. Thank you. Unfortunately, using this is
non-trivial when you have an extra 'z' variable. There are a couple of
options to get around this:

1. Re-write a 3d version and add it to matplotlib.tri. Pros of this
approach are that the 3d methods would basically only require one
extra line, a call to Triangulation.get_from_args_and_kwargs_3d(*args,
**kwargs). Cons of this approach are code repetition. Also, I'm not a
fan of putting 3d code into main mpl codebase. I think it should stay
in the toolkit.

2. Implement option 1. but in the mplot3d toolkit rather than the main codebase.

3. Create a new args_2d tuple exactly equal to *args but with 'z'
removed. Then rely on the 2d code with:
Triangulation.get_from_args_and_kwargs(args_2d, **kwargs). Since this
option would be common to all 3d functions relying on the 2d heavy
lifting, it could be wrapped up into a convenience function.

In my opinion, option 3. is preferable. Option 3. will also produce
commits with the highest signal-to-noise ratio.

> Forgive my cheek, but whilst you are looking at this area mplot3d.tricontour
> and tricontourf need similar improvement...
>

Forgiven. I might as well do it whilst I'm already half-way down the
rabbit hole.

> A wider issue, and something I should have mentioned when you first
> implemented plot_trisurf, is that I don't like the function name.  It seems
> unnecessary to have the plot_ at the front as most of the other plot-related
> functions manage without it.  My unease extends to plot_surface and
> plot_wireframe as well.  I guess we can't just change such names now that
> they are being used, but eventually I would like to see better naming within
> mplot3d.
>

Agreed. Not sure how best to solve this. Furthermore, I think it
should be implemented in a pull request separate to the one migrating
these 3d methods to custom triangulations.

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

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

@Ben: Presumably your running one of the examples. Probably changed with
https://github.com/matplotlib/matplotlib/pull/921




On 20 September 2012 18:23, Benjamin Root <ben...@ou...> wrote:

>
>
> On Wed, Sep 19, 2012 at 1:53 PM, Michael Droettboom <md...@st...>wrote:
>
>> I have tagged and created a tarball for 1.2.0rc2.  The githash is
>> 656c88f3e546.  The tarball is on the github download page here:
>>
>> https://github.com/matplotlib/matplotlib/downloads
>>
>> This includes a number of important bugfixes, including things required
>> for creating Macintosh and Windows binaries.  The Travis tests are also
>> now passing.
>>
>> I hope it will be easier for the binaries to be created this time. Once
>> they are available at github, I will make an announcement to
>> matplotlib-users and hopefully get some serious testing out of this thing.
>>
>> Thanks for all of the hard work!
>>
>> Mike
>>
>>
> Is it just me, or are colors looking duller?
>
> I attached before (v1.1.x) and after (v1.2.x) images.
>
> Ben Root
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Re: [matplotlib-devel] Custom plot_trisurf triangulations

[Ian T. <ian...@gm...>]

On 20 September 2012 22:30, Damon McDougall <dam...@gm...>wrote:

> I have been playing with custom triangulations in the plot_trisurf
> method of the mplot3d toolkit. I thought I would share my sweet
> creation: https://www.dropbox.com/s/ccptm6ok7nd3yn5/mobius.png
>
> Let me know your thoughts. I should probably make a pull request out
> of this, but the code is not currently readable by humans. I will tidy
> it up first. Make it look purrty.
>

Yes please!  Ideally it would be good if all mplot3d functions supported
the same arg and kwarg combinations as their 2d equivalents, for
consistency.  You may have done this already, but if not you might find the
2d tripcolor code helpful - it calls
Triangulation.get_from_args_and_kwargs(*args, **kwargs) to do the initial
heavy lifting.

Forgive my cheek, but whilst you are looking at this area
mplot3d.tricontour and tricontourf need similar improvement...

A wider issue, and something I should have mentioned when you first
implemented plot_trisurf, is that I don't like the function name.  It seems
unnecessary to have the plot_ at the front as most of the other
plot-related functions manage without it.  My unease extends to
plot_surface and plot_wireframe as well.  I guess we can't just change such
names now that they are being used, but eventually I would like to see
better naming within mplot3d.

Thanks,
Ian

[matplotlib-devel] Custom plot_trisurf triangulations

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

Greetings denizens,

I have been playing with custom triangulations in the plot_trisurf
method of the mplot3d toolkit. I thought I would share my sweet
creation: https://www.dropbox.com/s/ccptm6ok7nd3yn5/mobius.png

Let me know your thoughts. I should probably make a pull request out
of this, but the code is not currently readable by humans. I will tidy
it up first. Make it look purrty.

Lots of love,
Damon

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

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

On 09/20/2012 01:16 PM, Sandro Tosi wrote:
> Hi Michael,
>
> On Wed, Sep 19, 2012 at 7:53 PM, Michael Droettboom <md...@st...> wrote:
>> I have tagged and created a tarball for 1.2.0rc2.  The githash is
>> 656c88f3e546.  The tarball is on the github download page here:
> Thanks for the release!
>
> I'm testing the Debian packaging, and I noticed that the file
> lib/matplotlib/mpl-data/matplotlib.conf disappeared between 1.1.1 and
> 1.2.0rc1. That was a sample file that was nice to ship to users to
> have an idea what can be customized. We were also shipping it into
> /usr/share/matplotlib/ so a first configuration was already provided
> to users. Do you have something to suggest to restore the situation? I
> don't know if you like to add the file back (maybe in a different
> location) or if we should point users to the doc and stop.
>
The source of that file has always been `matplotlibrc.template` at the 
root of the source tree.  That file is copied (by the build process) to 
lib/matplotlib/mpl-data/matplotlibrc, but it doesn't exist in the raw 
source tree.  I'm not sure what matplotlib.conf is or was -- but I hope 
matplotlibrc.template fits the bill for the Debian package's purposes.

Mike

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

[Derek H. <de...@as...>]

On 20.09.2012, at 7:23PM, Benjamin Root <ben...@ou...> wrote:

> Is it just me, or are colors looking duller?
> 
> I attached before (v1.1.x) and after (v1.2.x) images.

Is this the same colour map? To me it looks like jet or rainbow vs. coolwarm. 
The latter had been endorsed by a number of people here for its visualisation 
qualities [http://www.sandia.gov/~kmorel/documents/ColorMaps/]; 
maybe it has just become the new default?

Cheers,
					Derek

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

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

On Thursday, September 20, 2012, Benjamin Root wrote:

>
>
> On Wed, Sep 19, 2012 at 1:53 PM, Michael Droettboom <md...@st...<javascript:_e({}, 'cvml', 'md...@st...');>
> > wrote:
>
>> I have tagged and created a tarball for 1.2.0rc2.  The githash is
>> 656c88f3e546.  The tarball is on the github download page here:
>>
>> https://github.com/matplotlib/matplotlib/downloads
>>
>> This includes a number of important bugfixes, including things required
>> for creating Macintosh and Windows binaries.  The Travis tests are also
>> now passing.
>>
>> I hope it will be easier for the binaries to be created this time. Once
>> they are available at github, I will make an announcement to
>> matplotlib-users and hopefully get some serious testing out of this thing.
>>
>> Thanks for all of the hard work!
>>
>> Mike
>>
>>
> Is it just me, or are colors looking duller?
>
> I attached before (v1.1.x) and after (v1.2.x) images.
>
> Ben Root
>
>
Are those different colour maps? Do they look the same when you explicitly
set cmap=cm.jet?


-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded

[Sandro T. <san...@gm...>]

Hi Michael,

On Wed, Sep 19, 2012 at 7:53 PM, Michael Droettboom <md...@st...> wrote:
> I have tagged and created a tarball for 1.2.0rc2.  The githash is
> 656c88f3e546.  The tarball is on the github download page here:

Thanks for the release!

I'm testing the Debian packaging, and I noticed that the file
lib/matplotlib/mpl-data/matplotlib.conf disappeared between 1.1.1 and
1.2.0rc1. That was a sample file that was nice to ship to users to
have an idea what can be customized. We were also shipping it into
/usr/share/matplotlib/ so a first configuration was already provided
to users. Do you have something to suggest to restore the situation? I
don't know if you like to add the file back (maybe in a different
location) or if we should point users to the doc and stop.

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Re: [matplotlib-devel] Welcoming new core developers

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

On Thursday, September 20, 2012, Phil Elson wrote:

> Congrats to the three of you. The hard work that you all put in doesn't go
> unnoticed, and is massively appreciated!
>
> Mike, as lead developer, your opening round of beers for mpl devs at
> SciPy13 is beginning to look costly. ;-)
>
>
>
> On 20 September 2012 03:25, Benjamin Root <ben...@ou...<javascript:_e({}, 'cvml', 'ben...@ou...');>
> > wrote:
>
>>
>>
>> On Wednesday, September 19, 2012, Michael Droettboom wrote:
>>
>>> Damon McDougall, Christoph Gohlke and Russell Owen have been added to
>>> the set of core developers with push rights and the ability to upload
>>> files to the github download page.
>>>
>>> Damon has come recently on the scene, but has provided all kinds of
>>> helpful bug triaging and fixing during the 1.2.0 release cycle, as well
>>> as cool new features such as 3d trisurfaces and stacked plots, to name
>>> only a few.
>>>
>>> Christoph Gohlke, besides providing tons of support on the mailing list
>>> for a long while, has been providing Windows binaries for the past few
>>> releases.
>>>
>>> Russell Owen has been providing Mac OS-X builds for the past few
>>> releases and has helped track down some portability problems in the
>>> 1.2.0 release.
>>>
>>> Thanks to everyone on the growing team!
>>>
>>> Mike
>>>
>>>
>> Welcome aboard!
>>
>> Ben Root
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://ad.doubleclick.net/clk;258768047;13503038;j?
>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li... <javascript:_e({}, 'cvml',
>> 'Mat...@li...');>
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
Wooohooo! Time to stretch that itchy merge finger!

Thanks for the recognition, and congratulations to Christoph and Russell,
too! This growth will excite more teamwork and development. I'm stoked to
be a part of it.

Thanks all,
Damon


-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] Welcoming new core developers

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

Congrats to the three of you. The hard work that you all put in doesn't go
unnoticed, and is massively appreciated!

Mike, as lead developer, your opening round of beers for mpl devs at
SciPy13 is beginning to look costly. ;-)



On 20 September 2012 03:25, Benjamin Root <ben...@ou...> wrote:

>
>
> On Wednesday, September 19, 2012, Michael Droettboom wrote:
>
>> Damon McDougall, Christoph Gohlke and Russell Owen have been added to
>> the set of core developers with push rights and the ability to upload
>> files to the github download page.
>>
>> Damon has come recently on the scene, but has provided all kinds of
>> helpful bug triaging and fixing during the 1.2.0 release cycle, as well
>> as cool new features such as 3d trisurfaces and stacked plots, to name
>> only a few.
>>
>> Christoph Gohlke, besides providing tons of support on the mailing list
>> for a long while, has been providing Windows binaries for the past few
>> releases.
>>
>> Russell Owen has been providing Mac OS-X builds for the past few
>> releases and has helped track down some portability problems in the
>> 1.2.0 release.
>>
>> Thanks to everyone on the growing team!
>>
>> Mike
>>
>>
> Welcome aboard!
>
> Ben Root
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Re: [matplotlib-devel] Welcoming new core developers

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

On Wednesday, September 19, 2012, Michael Droettboom wrote:

> Damon McDougall, Christoph Gohlke and Russell Owen have been added to
> the set of core developers with push rights and the ability to upload
> files to the github download page.
>
> Damon has come recently on the scene, but has provided all kinds of
> helpful bug triaging and fixing during the 1.2.0 release cycle, as well
> as cool new features such as 3d trisurfaces and stacked plots, to name
> only a few.
>
> Christoph Gohlke, besides providing tons of support on the mailing list
> for a long while, has been providing Windows binaries for the past few
> releases.
>
> Russell Owen has been providing Mac OS-X builds for the past few
> releases and has helped track down some portability problems in the
> 1.2.0 release.
>
> Thanks to everyone on the growing team!
>
> Mike
>
>
Welcome aboard!

Ben Root

[matplotlib-devel] Welcoming new core developers

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

Damon McDougall, Christoph Gohlke and Russell Owen have been added to 
the set of core developers with push rights and the ability to upload 
files to the github download page.

Damon has come recently on the scene, but has provided all kinds of 
helpful bug triaging and fixing during the 1.2.0 release cycle, as well 
as cool new features such as 3d trisurfaces and stacked plots, to name 
only a few.

Christoph Gohlke, besides providing tons of support on the mailing list 
for a long while, has been providing Windows binaries for the past few 
releases.

Russell Owen has been providing Mac OS-X builds for the past few 
releases and has helped track down some portability problems in the 
1.2.0 release.

Thanks to everyone on the growing team!

Mike

[matplotlib-devel] 1.2.0rc2 is tagged and uploaded

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

I have tagged and created a tarball for 1.2.0rc2.  The githash is 
656c88f3e546.  The tarball is on the github download page here:

https://github.com/matplotlib/matplotlib/downloads

This includes a number of important bugfixes, including things required 
for creating Macintosh and Windows binaries.  The Travis tests are also 
now passing.

I hope it will be easier for the binaries to be created this time. Once 
they are available at github, I will make an announcement to 
matplotlib-users and hopefully get some serious testing out of this thing.

Thanks for all of the hard work!

Mike

Re: [matplotlib-devel] 1.2.0rc1 is cut

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

Russell, I fixed this and it will be in rc2. See
https://github.com/matplotlib/matplotlib/pull/1264.

Thanks,


On 19 September 2012 00:32, Russell Owen <ro...@uw...> wrote:

>
> On Sep 18, 2012, at 4:05 PM, Paul Hobson wrote:
>
> > On Tue, Sep 18, 2012 at 3:57 PM, Russell E. Owen <ro...@uw...> wrote:
> >> In article <505...@st...>,
> >> Michael Droettboom <md...@st...>
> >> wrote:
> >>
> >>> I have tagged and created a tarball for 1.2.0rc1.  The githash is
> >>> bda6dd9feab8.  The tarball is on the github download page here:
> >>>
> >>> https://github.com/matplotlib/matplotlib/downloads
> >>>
> >>> I have created a new branch, v1.2.x, for continuing 1.2.x development.
> >>> The feature freeze on master is now lifted and big experimental changes
> >>> can be merged into master.  Any bugfixes that need to go into 1.2.x
> >>> should be merged into both places.  Please mark any PRs for the 1.2.x
> >>> branch with the 1.2.x milestone so we can verify that things are merged
> >>> in both places.
> >>
> >> It appears that
> >> import matplotlib
> >> no longer imports matplotlib.dates -- that I must do that explicitly:
> >> import matplotlib.dates
> >>
> >> Is that an intentional change? It breaks existing code of mine, which is
> >> easily fixed and perhaps was making unwarranted assumptions. But I
> >> wonder what else will break.
> >
> > Russel,
> >
> > Which version were you on? with MPL v1.1 i get:
> > In [28]: import matplotlib
> >
> > In [29]: matplotlib.dates
> >
> ---------------------------------------------------------------------------
> > AttributeError                            Traceback (most recent call
> last)
> > <ipython-input-29-a13aa8cf36d8> in <module>()
> > ----> 1 matplotlib.dates
> >
> > AttributeError: 'module' object has no attribute 'dates'
> >
> > In [30]: matplotlib.__version__
> > Out[30]: '1.1.0'
> >
> > In [31]: import matplotlib.dates
> >
> > In [32]: matplotlib.dates
> > Out[32]: <module 'matplotlib.dates' from
> > 'C:\Python27\lib\site-packages\matplotlib\dates.pyc'>
>
> I was using 1.1.1 most recently. I'm not sure when I started using
> matplotlib.dates without explicitly importing it.
>
> In any case, it sounds as if it's not meant to work, so there's no need to
> change anything in matplotlib.
>
> Regards,
>
> -- Russell
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] 1.2.0rc1 is cut

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

On Sep 18, 2012, at 4:05 PM, Paul Hobson wrote:

> On Tue, Sep 18, 2012 at 3:57 PM, Russell E. Owen <ro...@uw...> wrote:
>> In article <505...@st...>,
>> Michael Droettboom <md...@st...>
>> wrote:
>> 
>>> I have tagged and created a tarball for 1.2.0rc1.  The githash is
>>> bda6dd9feab8.  The tarball is on the github download page here:
>>> 
>>> https://github.com/matplotlib/matplotlib/downloads
>>> 
>>> I have created a new branch, v1.2.x, for continuing 1.2.x development.
>>> The feature freeze on master is now lifted and big experimental changes
>>> can be merged into master.  Any bugfixes that need to go into 1.2.x
>>> should be merged into both places.  Please mark any PRs for the 1.2.x
>>> branch with the 1.2.x milestone so we can verify that things are merged
>>> in both places.
>> 
>> It appears that
>> import matplotlib
>> no longer imports matplotlib.dates -- that I must do that explicitly:
>> import matplotlib.dates
>> 
>> Is that an intentional change? It breaks existing code of mine, which is
>> easily fixed and perhaps was making unwarranted assumptions. But I
>> wonder what else will break.
> 
> Russel,
> 
> Which version were you on? with MPL v1.1 i get:
> In [28]: import matplotlib
> 
> In [29]: matplotlib.dates
> ---------------------------------------------------------------------------
> AttributeError                            Traceback (most recent call last)
> <ipython-input-29-a13aa8cf36d8> in <module>()
> ----> 1 matplotlib.dates
> 
> AttributeError: 'module' object has no attribute 'dates'
> 
> In [30]: matplotlib.__version__
> Out[30]: '1.1.0'
> 
> In [31]: import matplotlib.dates
> 
> In [32]: matplotlib.dates
> Out[32]: <module 'matplotlib.dates' from
> 'C:\Python27\lib\site-packages\matplotlib\dates.pyc'>

I was using 1.1.1 most recently. I'm not sure when I started using matplotlib.dates without explicitly importing it.

In any case, it sounds as if it's not meant to work, so there's no need to change anything in matplotlib.

Regards,

-- Russell

Re: [matplotlib-devel] 1.2.0rc1 is cut

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

On Tue, Sep 18, 2012 at 3:57 PM, Russell E. Owen <ro...@uw...> wrote:
> In article <505...@st...>,
>  Michael Droettboom <md...@st...>
>  wrote:
>
>> I have tagged and created a tarball for 1.2.0rc1.  The githash is
>> bda6dd9feab8.  The tarball is on the github download page here:
>>
>> https://github.com/matplotlib/matplotlib/downloads
>>
>> I have created a new branch, v1.2.x, for continuing 1.2.x development.
>> The feature freeze on master is now lifted and big experimental changes
>> can be merged into master.  Any bugfixes that need to go into 1.2.x
>> should be merged into both places.  Please mark any PRs for the 1.2.x
>> branch with the 1.2.x milestone so we can verify that things are merged
>> in both places.
>
> It appears that
> import matplotlib
> no longer imports matplotlib.dates -- that I must do that explicitly:
> import matplotlib.dates
>
> Is that an intentional change? It breaks existing code of mine, which is
> easily fixed and perhaps was making unwarranted assumptions. But I
> wonder what else will break.

Russel,

Which version were you on? with MPL v1.1 i get:
In [28]: import matplotlib

In [29]: matplotlib.dates
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-29-a13aa8cf36d8> in <module>()
----> 1 matplotlib.dates

AttributeError: 'module' object has no attribute 'dates'

In [30]: matplotlib.__version__
Out[30]: '1.1.0'

In [31]: import matplotlib.dates

In [32]: matplotlib.dates
Out[32]: <module 'matplotlib.dates' from
'C:\Python27\lib\site-packages\matplotlib\dates.pyc'>

Re: [matplotlib-devel] 1.2.0rc1 is cut

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

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

> I have tagged and created a tarball for 1.2.0rc1.  The githash is 
> bda6dd9feab8.  The tarball is on the github download page here:
> 
> https://github.com/matplotlib/matplotlib/downloads
> 
> I have created a new branch, v1.2.x, for continuing 1.2.x development.  
> The feature freeze on master is now lifted and big experimental changes 
> can be merged into master.  Any bugfixes that need to go into 1.2.x 
> should be merged into both places.  Please mark any PRs for the 1.2.x 
> branch with the 1.2.x milestone so we can verify that things are merged 
> in both places.

It appears that 
import matplotlib
no longer imports matplotlib.dates -- that I must do that explicitly:
import matplotlib.dates

Is that an intentional change? It breaks existing code of mine, which is 
easily fixed and perhaps was making unwarranted assumptions. But I 
wonder what else will break.

-- Russell

P.S. Damon McDougall and mdehoon fixed the problem with matplotlib 
building for Mac using gcc 4.0! Many thanks!

Re: [matplotlib-devel] 1.2.0rc1 is cut

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

On Mon, Sep 17, 2012 at 10:53 PM, Michael Droettboom <md...@st...> wrote:
> Thanks for this.  I think it makes sense to see if we can get to the
> bottom of this before putting out another release candidate.  I have a
> feeling that the solution might be obvious to an Objective C expert --
> which I am not.
>
> Mike
>

The problem is that gcc 4.0 does not support objective c 2.0. The "for
(blah in thing) .." construct was a new addition in Objective C 2.0.

-- 
Damon McDougall
http://www.damon.is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom