From tcaswell at gmail.com  Fri Apr  1 17:11:55 2016
From: tcaswell at gmail.com (Thomas Caswell)
Date: Fri, 01 Apr 2016 21:11:55 +0000
Subject: [Matplotlib-devel] disabled squashing commits
Message-ID: <CAA48SF8mCUqYSRpRwU27sKte+43QbB=4xb5ggZwV9h-r95oUZg@mail.gmail.com>

Hey all,

In what I hope is an April Fools day joke github has add a 'merge by
squashing' option to the merge button (and turned it on by default) [1].

I have taken the liberty of disabling it for the main matplotlib repository
(and will likely do the rest) in the case that it is not.

Tom

[1] https://github.com/blog/2141-squash-your-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160401/4f9d343d/attachment.html>

From njs at pobox.com  Wed Apr 20 19:22:18 2016
From: njs at pobox.com (Nathaniel Smith)
Date: Wed, 20 Apr 2016 16:22:18 -0700
Subject: [Matplotlib-devel] [rfc] a better interchange format for colormaps
Message-ID: <CAPJVwBkXX8QVHJp+zwsrMohDq79EgVmCE1-S9jah8zZvrT_kjA@mail.gmail.com>

Hi matplotters,

We've been working on improving our tool for building custom
viridis-like colormaps (e.g. adding support for diverging colormaps),
and one of the things that we got frustrated by is how there's no
compelling way to save and distribute the resulting colormaps so that
people can actually use them. So, I wrote up a little spec to
standardize a way of storing and distributing colormaps in JSON, with
the hope that we can convince everyone to implement this and stop
writing silly little conversion scripts all the time.

The v0.1 draft is here:
    https://github.com/njsmith/json-cm/blob/master/json-cm-spec.md

Any comments? There are always a lot of fiddly details to get right in
this kind of thing -- I made a bunch of guesses about what kind of
stuff is important and how to represent it, but it can only benefit
from review from different perspectives. I would equally love to get
nitpicky critiques and high-level queries.

Thanks!
-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From daniele at grinta.net  Wed Apr 20 19:59:15 2016
From: daniele at grinta.net (Daniele Nicolodi)
Date: Wed, 20 Apr 2016 17:59:15 -0600
Subject: [Matplotlib-devel] [rfc] a better interchange format for
 colormaps
In-Reply-To: <CAPJVwBkXX8QVHJp+zwsrMohDq79EgVmCE1-S9jah8zZvrT_kjA@mail.gmail.com>
References: <CAPJVwBkXX8QVHJp+zwsrMohDq79EgVmCE1-S9jah8zZvrT_kjA@mail.gmail.com>
Message-ID: <571817D3.6020003@grinta.net>

On 4/20/16 5:22 PM, Nathaniel Smith wrote:
> I wrote up a little spec to
> standardize a way of storing and distributing colormaps in JSON, with
> the hope that we can convince everyone to implement this and stop
> writing silly little conversion scripts all the time.

While I'm not a fan of Matlab, I think it would be nice to be able to
use colormaps defined in this way with it. It is a few years I'm not
working in Matlab, but at the time there were no built-in tools to read
JSON files. It would be unfortunate if this interchange format would
depend on a large third party library to be used with Matlab.

Cheers,
Daniele


From njs at pobox.com  Wed Apr 20 20:10:53 2016
From: njs at pobox.com (Nathaniel Smith)
Date: Wed, 20 Apr 2016 17:10:53 -0700
Subject: [Matplotlib-devel] [rfc] a better interchange format for
 colormaps
In-Reply-To: <571817D3.6020003@grinta.net>
References: <CAPJVwBkXX8QVHJp+zwsrMohDq79EgVmCE1-S9jah8zZvrT_kjA@mail.gmail.com>
 <571817D3.6020003@grinta.net>
Message-ID: <CAPJVwBnmN-nJD4hPrnZLVQdmgXyExmgdpnfAJhpBwKbjWDAMEg@mail.gmail.com>

On Wed, Apr 20, 2016 at 4:59 PM, Daniele Nicolodi <daniele at grinta.net> wrote:
> On 4/20/16 5:22 PM, Nathaniel Smith wrote:
>> I wrote up a little spec to
>> standardize a way of storing and distributing colormaps in JSON, with
>> the hope that we can convince everyone to implement this and stop
>> writing silly little conversion scripts all the time.
>
> While I'm not a fan of Matlab, I think it would be nice to be able to
> use colormaps defined in this way with it. It is a few years I'm not
> working in Matlab, but at the time there were no built-in tools to read
> JSON files. It would be unfortunate if this interchange format would
> depend on a large third party library to be used with Matlab.

Do you have any suggestions for how to format the data so that it
could be used more easily in Matlab while still being easily usable
from Javascript? I guess if I have to pick I'm more worried about
compatibility with D3 and Vega than with Matlab...

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From isaac.gerg at gergltd.com  Wed Apr 20 21:25:46 2016
From: isaac.gerg at gergltd.com (Isaac Gerg)
Date: Wed, 20 Apr 2016 21:25:46 -0400
Subject: [Matplotlib-devel] [rfc] a better interchange format for
 colormaps
In-Reply-To: <CAPJVwBnmN-nJD4hPrnZLVQdmgXyExmgdpnfAJhpBwKbjWDAMEg@mail.gmail.com>
References: <CAPJVwBkXX8QVHJp+zwsrMohDq79EgVmCE1-S9jah8zZvrT_kjA@mail.gmail.com>
 <571817D3.6020003@grinta.net>
 <CAPJVwBnmN-nJD4hPrnZLVQdmgXyExmgdpnfAJhpBwKbjWDAMEg@mail.gmail.com>
Message-ID: <CADnN3yWOKUtLNRMyt=uRXtu3nFMy4Cfr_1u3autS5xzjzY8T-w@mail.gmail.com>

Could you use HDF format?  Its a bit overkill as a storage container but
almost everything supports it.

On Wed, Apr 20, 2016 at 8:10 PM, Nathaniel Smith <njs at pobox.com> wrote:

> On Wed, Apr 20, 2016 at 4:59 PM, Daniele Nicolodi <daniele at grinta.net>
> wrote:
> > On 4/20/16 5:22 PM, Nathaniel Smith wrote:
> >> I wrote up a little spec to
> >> standardize a way of storing and distributing colormaps in JSON, with
> >> the hope that we can convince everyone to implement this and stop
> >> writing silly little conversion scripts all the time.
> >
> > While I'm not a fan of Matlab, I think it would be nice to be able to
> > use colormaps defined in this way with it. It is a few years I'm not
> > working in Matlab, but at the time there were no built-in tools to read
> > JSON files. It would be unfortunate if this interchange format would
> > depend on a large third party library to be used with Matlab.
>
> Do you have any suggestions for how to format the data so that it
> could be used more easily in Matlab while still being easily usable
> from Javascript? I guess if I have to pick I'm more worried about
> compatibility with D3 and Vega than with Matlab...
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160420/d358bf6d/attachment.html>

From njs at pobox.com  Wed Apr 20 22:21:12 2016
From: njs at pobox.com (Nathaniel Smith)
Date: Wed, 20 Apr 2016 19:21:12 -0700
Subject: [Matplotlib-devel] [rfc] a better interchange format for
 colormaps
In-Reply-To: <CADnN3yWOKUtLNRMyt=uRXtu3nFMy4Cfr_1u3autS5xzjzY8T-w@mail.gmail.com>
References: <CAPJVwBkXX8QVHJp+zwsrMohDq79EgVmCE1-S9jah8zZvrT_kjA@mail.gmail.com>
 <571817D3.6020003@grinta.net>
 <CAPJVwBnmN-nJD4hPrnZLVQdmgXyExmgdpnfAJhpBwKbjWDAMEg@mail.gmail.com>
 <CADnN3yWOKUtLNRMyt=uRXtu3nFMy4Cfr_1u3autS5xzjzY8T-w@mail.gmail.com>
Message-ID: <CAPJVwBnFs5=VFJ0kVVtsq2o09HWNV4xEV53TiGRbRZeep7j2Bw@mail.gmail.com>

On Wed, Apr 20, 2016 at 6:25 PM, Isaac Gerg <isaac.gerg at gergltd.com> wrote:
> Could you use HDF format?  Its a bit overkill as a storage container but
> almost everything supports it.

The only thing that can read/write HDF5 is libhdf5, which is a giant C
codebase. Unless I'm missing something, I think this would make the
format utterly inaccessible to browser-based Javascript visualizations
-- versus, it's at least *possible* to read JSON in Matlab :-).

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From efiring at hawaii.edu  Wed Apr 20 22:32:37 2016
From: efiring at hawaii.edu (Eric Firing)
Date: Wed, 20 Apr 2016 16:32:37 -1000
Subject: [Matplotlib-devel] [rfc] a better interchange format for
 colormaps
In-Reply-To: <CAPJVwBkXX8QVHJp+zwsrMohDq79EgVmCE1-S9jah8zZvrT_kjA@mail.gmail.com>
References: <CAPJVwBkXX8QVHJp+zwsrMohDq79EgVmCE1-S9jah8zZvrT_kjA@mail.gmail.com>
Message-ID: <57183BC5.6020107@hawaii.edu>

On 2016/04/20 1:22 PM, Nathaniel Smith wrote:
> Hi matplotters,
>
> We've been working on improving our tool for building custom
> viridis-like colormaps (e.g. adding support for diverging colormaps),
> and one of the things that we got frustrated by is how there's no
> compelling way to save and distribute the resulting colormaps so that
> people can actually use them. So, I wrote up a little spec to
> standardize a way of storing and distributing colormaps in JSON, with
> the hope that we can convince everyone to implement this and stop
> writing silly little conversion scripts all the time.
>
> The v0.1 draft is here:
>      https://github.com/njsmith/json-cm/blob/master/json-cm-spec.md
>
> Any comments? There are always a lot of fiddly details to get right in
> this kind of thing -- I made a bunch of guesses about what kind of
> stuff is important and how to represent it, but it can only benefit
> from review from different perspectives. I would equally love to get
> nitpicky critiques and high-level queries.
>
> Thanks!
> -n
>

Nathaniel,

I like the idea.

Minor and tentative suggestion: add a key to specify the number of 
colors.  Yes, it can be calculated from the length of the "colors" 
string, but I have a hunch the convenience of having it immediately 
available (even grep-able) would be worth the slight redundancy.

Although matplotlib's colormap support was originally designed by John 
Hunter around his LinearSegmentedColormap scheme, that method for 
defining and recording a colormap has always been baffling to most 
people--and the end result is a simple lookup table anyway.  Therefore I 
favor moving to the direct specification of the evenly-spaced 
fine-grained color list (suitable for matplotlib's ListedColormap) as in 
your proposal here.

Eric

From efiring at hawaii.edu  Wed Apr 20 22:35:05 2016
From: efiring at hawaii.edu (Eric Firing)
Date: Wed, 20 Apr 2016 16:35:05 -1000
Subject: [Matplotlib-devel] [rfc] a better interchange format for
 colormaps
In-Reply-To: <571817D3.6020003@grinta.net>
References: <CAPJVwBkXX8QVHJp+zwsrMohDq79EgVmCE1-S9jah8zZvrT_kjA@mail.gmail.com>
 <571817D3.6020003@grinta.net>
Message-ID: <57183C59.20308@hawaii.edu>

On 2016/04/20 1:59 PM, Daniele Nicolodi wrote:
> On 4/20/16 5:22 PM, Nathaniel Smith wrote:
>> I wrote up a little spec to
>> standardize a way of storing and distributing colormaps in JSON, with
>> the hope that we can convince everyone to implement this and stop
>> writing silly little conversion scripts all the time.
>
> While I'm not a fan of Matlab, I think it would be nice to be able to
> use colormaps defined in this way with it. It is a few years I'm not
> working in Matlab, but at the time there were no built-in tools to read
> JSON files. It would be unfortunate if this interchange format would
> depend on a large third party library to be used with Matlab.

I haven't tried it (I don't use Matlab any more), but it looks like this 
small third party library takes care of it:

https://github.com/fangq/jsonlab

Eric

>
> Cheers,
> Daniele
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>


From njs at pobox.com  Wed Apr 20 23:07:09 2016
From: njs at pobox.com (Nathaniel Smith)
Date: Wed, 20 Apr 2016 20:07:09 -0700
Subject: [Matplotlib-devel] [rfc] a better interchange format for
 colormaps
In-Reply-To: <57183BC5.6020107@hawaii.edu>
References: <CAPJVwBkXX8QVHJp+zwsrMohDq79EgVmCE1-S9jah8zZvrT_kjA@mail.gmail.com>
 <57183BC5.6020107@hawaii.edu>
Message-ID: <CAPJVwBnc90Cp2rk04Ye_zedHKJZCy6LEbQm7JHnf0fBfCOHY-Q@mail.gmail.com>

On Wed, Apr 20, 2016 at 7:32 PM, Eric Firing <efiring at hawaii.edu> wrote:
> On 2016/04/20 1:22 PM, Nathaniel Smith wrote:
>>
>> Hi matplotters,
>>
>> We've been working on improving our tool for building custom
>> viridis-like colormaps (e.g. adding support for diverging colormaps),
>> and one of the things that we got frustrated by is how there's no
>> compelling way to save and distribute the resulting colormaps so that
>> people can actually use them. So, I wrote up a little spec to
>> standardize a way of storing and distributing colormaps in JSON, with
>> the hope that we can convince everyone to implement this and stop
>> writing silly little conversion scripts all the time.
>>
>> The v0.1 draft is here:
>>      https://github.com/njsmith/json-cm/blob/master/json-cm-spec.md
>>
>> Any comments? There are always a lot of fiddly details to get right in
>> this kind of thing -- I made a bunch of guesses about what kind of
>> stuff is important and how to represent it, but it can only benefit
>> from review from different perspectives. I would equally love to get
>> nitpicky critiques and high-level queries.
>>
>> Thanks!
>> -n
>>
>
> Nathaniel,
>
> I like the idea.
>
> Minor and tentative suggestion: add a key to specify the number of colors.
> Yes, it can be calculated from the length of the "colors" string, but I have
> a hunch the convenience of having it immediately available (even grep-able)
> would be worth the slight redundancy.

Hmm, I'll have to think about that one. My gut reaction is to be wary
about introducing redundancy because it tends to create
source-of-truth problems -- if the two things disagree, then which is
right? -- and then those tend to create interoperability problems.
But, maybe I'm just missing something... I don't think I've ever
grepped for a colormap on the basis of how many control points it
contained, so I might not be the target audience :-). Can you give any
examples of when you'd use this?

> Although matplotlib's colormap support was originally designed by John
> Hunter around his LinearSegmentedColormap scheme, that method for defining
> and recording a colormap has always been baffling to most people--and the
> end result is a simple lookup table anyway.  Therefore I favor moving to the
> direct specification of the evenly-spaced fine-grained color list (suitable
> for matplotlib's ListedColormap) as in your proposal here.

This might improve the handling of discrete/qualitative colormaps too
-- right now AFAICT matplotlib just doesn't handle these sensibly at
all by default. The way the colorbrewer palettes have historically
been mangled in matplotlib is pretty bad :-/

    http://matplotlib.org/mpl_examples/color/colormaps_reference_04.png

Though in some sense I suppose one has lost as soon as one is trying
to use the Colormap interface's float -> color semantics for a
discrete map -- the seaborn "palette" concept is in some ways closer
to what we'd want for qualitative colormaps.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From efiring at hawaii.edu  Thu Apr 21 01:04:04 2016
From: efiring at hawaii.edu (Eric Firing)
Date: Wed, 20 Apr 2016 19:04:04 -1000
Subject: [Matplotlib-devel] [rfc] a better interchange format for
 colormaps
In-Reply-To: <CAPJVwBnc90Cp2rk04Ye_zedHKJZCy6LEbQm7JHnf0fBfCOHY-Q@mail.gmail.com>
References: <CAPJVwBkXX8QVHJp+zwsrMohDq79EgVmCE1-S9jah8zZvrT_kjA@mail.gmail.com>
 <57183BC5.6020107@hawaii.edu>
 <CAPJVwBnc90Cp2rk04Ye_zedHKJZCy6LEbQm7JHnf0fBfCOHY-Q@mail.gmail.com>
Message-ID: <57185F44.3010607@hawaii.edu>

On 2016/04/20 5:07 PM, Nathaniel Smith wrote:
> On Wed, Apr 20, 2016 at 7:32 PM, Eric Firing <efiring at hawaii.edu> wrote:
>> On 2016/04/20 1:22 PM, Nathaniel Smith wrote:
>>>
>>> Hi matplotters,
>>>
>>> We've been working on improving our tool for building custom
>>> viridis-like colormaps (e.g. adding support for diverging colormaps),
>>> and one of the things that we got frustrated by is how there's no
>>> compelling way to save and distribute the resulting colormaps so that
>>> people can actually use them. So, I wrote up a little spec to
>>> standardize a way of storing and distributing colormaps in JSON, with
>>> the hope that we can convince everyone to implement this and stop
>>> writing silly little conversion scripts all the time.
>>>
>>> The v0.1 draft is here:
>>>       https://github.com/njsmith/json-cm/blob/master/json-cm-spec.md
>>>
>>> Any comments? There are always a lot of fiddly details to get right in
>>> this kind of thing -- I made a bunch of guesses about what kind of
>>> stuff is important and how to represent it, but it can only benefit
>>> from review from different perspectives. I would equally love to get
>>> nitpicky critiques and high-level queries.
>>>
>>> Thanks!
>>> -n
>>>
>>
>> Nathaniel,
>>
>> I like the idea.
>>
>> Minor and tentative suggestion: add a key to specify the number of colors.
>> Yes, it can be calculated from the length of the "colors" string, but I have
>> a hunch the convenience of having it immediately available (even grep-able)
>> would be worth the slight redundancy.
>
> Hmm, I'll have to think about that one. My gut reaction is to be wary
> about introducing redundancy because it tends to create
> source-of-truth problems -- if the two things disagree, then which is
> right? -- and then those tend to create interoperability problems.

Agreed, which is why I said "tentative".

> But, maybe I'm just missing something... I don't think I've ever
> grepped for a colormap on the basis of how many control points it
> contained, so I might not be the target audience :-). Can you give any
> examples of when you'd use this?

I was thinking of how one would quickly summarize the characteristics of 
a file without having to parse it programmatically as JSON.  The number 
of colors in the list is just meta-data.  But this is not a big deal 
either way.

>
>> Although matplotlib's colormap support was originally designed by John
>> Hunter around his LinearSegmentedColormap scheme, that method for defining
>> and recording a colormap has always been baffling to most people--and the
>> end result is a simple lookup table anyway.  Therefore I favor moving to the
>> direct specification of the evenly-spaced fine-grained color list (suitable
>> for matplotlib's ListedColormap) as in your proposal here.
>
> This might improve the handling of discrete/qualitative colormaps too
> -- right now AFAICT matplotlib just doesn't handle these sensibly at
> all by default. The way the colorbrewer palettes have historically
> been mangled in matplotlib is pretty bad :-/

Agreed.  That slipped in without adequate review.

>
>      http://matplotlib.org/mpl_examples/color/colormaps_reference_04.png
>
> Though in some sense I suppose one has lost as soon as one is trying
> to use the Colormap interface's float -> color semantics for a
> discrete map -- the seaborn "palette" concept is in some ways closer
> to what we'd want for qualitative colormaps.

Matplotlib colormaps can be indexed with an integer to go straight to an 
element in the lookup table; it is not necessary to use a float in the 
0-1 range.

It would be possible to modify Colormap to include a "qualitative" flag, 
and require a direct integer index when that flag is set.  Or a warning 
could be issued upon use of a float.

Eric

>
> -n
>


From chris.barker at noaa.gov  Thu Apr 21 15:07:26 2016
From: chris.barker at noaa.gov (Chris Barker)
Date: Thu, 21 Apr 2016 12:07:26 -0700
Subject: [Matplotlib-devel] [rfc] a better interchange format for
 colormaps
In-Reply-To: <CAPJVwBnc90Cp2rk04Ye_zedHKJZCy6LEbQm7JHnf0fBfCOHY-Q@mail.gmail.com>
References: <CAPJVwBkXX8QVHJp+zwsrMohDq79EgVmCE1-S9jah8zZvrT_kjA@mail.gmail.com>
 <57183BC5.6020107@hawaii.edu>
 <CAPJVwBnc90Cp2rk04Ye_zedHKJZCy6LEbQm7JHnf0fBfCOHY-Q@mail.gmail.com>
Message-ID: <CALGmxEJ2UiUs12CcyQyY6E-5-C0ND1ytrzGeWuuDEDFUC90AUw@mail.gmail.com>

On Wed, Apr 20, 2016 at 8:07 PM, Nathaniel Smith <njs at pobox.com> wrote:

> Though in some sense I suppose one has lost as soon as one is trying
> to use the Colormap interface's float -> color semantics for a
> discrete map


I agree -- I think a discrete set of colors is fundamentally different than
a (logically at least) continuous colormap -- we should simply keep them
separate.


> -- the seaborn "palette" concept is in some ways closer
> to what we'd want for qualitative colormaps.


yup.

-CHB


-- 

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

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160421/cac24879/attachment.html>

From chris.barker at noaa.gov  Thu Apr 21 15:23:40 2016
From: chris.barker at noaa.gov (Chris Barker)
Date: Thu, 21 Apr 2016 12:23:40 -0700
Subject: [Matplotlib-devel] [rfc] a better interchange format for
 colormaps
In-Reply-To: <CAPJVwBkXX8QVHJp+zwsrMohDq79EgVmCE1-S9jah8zZvrT_kjA@mail.gmail.com>
References: <CAPJVwBkXX8QVHJp+zwsrMohDq79EgVmCE1-S9jah8zZvrT_kjA@mail.gmail.com>
Message-ID: <CALGmxEJuRsX5RbDuF7CTY-eKgWmmox21vaHkmpwecCNeXojQvw@mail.gmail.com>

Great idea!

AS it happens, we're messing with colormaps ourselves here, and indeed to
need to have consistent ones across browser-JS and python -- so great
timing!

I'm not so sure about the encoding of the colors -- I read the
justification (nicely written), but I still think file size is pretty much
a non-issue -- these are not going to be gigabytes no matter how you slice
it. and the compressed file sizes are definitely close enough in size to
make no difference. So I would much prefer:

[ [r, g, b], [r,g,b], ....]

However, maybe that's because I still can't wrap my head easily around hex
:-)

I think compatibility with D3 per se should be a minor influence, but if
Javascript itself "likes" to use hex colors and could more easily deal with
this, then I guess that might be a driver (or do I think that because I'm a
pythonista that could easily write the conversion code in Python than JS
...)

Also for discrete colormaps, might there be a use case for transparency?
i.e. RGBA ? In which case, the encoding should be able to handle  either
three or four channels per color with no ambiguity. Would that be two hex
values per color for a 32 bit color (then you have to have a clean
endianness, yes?) or commas or something separating the colors.

As for specifying the number of colors somewhere else, I agree that that's
just a recipe for inconsistency with no gain -- is anyone going to have to
write a parser where they have to alocate teh memory ahead of time???

-CHB


On Wed, Apr 20, 2016 at 4:22 PM, Nathaniel Smith <njs at pobox.com> wrote:

> Hi matplotters,
>
> We've been working on improving our tool for building custom
> viridis-like colormaps (e.g. adding support for diverging colormaps),
> and one of the things that we got frustrated by is how there's no
> compelling way to save and distribute the resulting colormaps so that
> people can actually use them. So, I wrote up a little spec to
> standardize a way of storing and distributing colormaps in JSON, with
> the hope that we can convince everyone to implement this and stop
> writing silly little conversion scripts all the time.
>
> The v0.1 draft is here:
>     https://github.com/njsmith/json-cm/blob/master/json-cm-spec.md
>
> Any comments? There are always a lot of fiddly details to get right in
> this kind of thing -- I made a bunch of guesses about what kind of
> stuff is important and how to represent it, but it can only benefit
> from review from different perspectives. I would equally love to get
> nitpicky critiques and high-level queries.
>
> Thanks!
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160421/0098746b/attachment.html>

From matthew.brett at gmail.com  Sat Apr 23 13:04:08 2016
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sat, 23 Apr 2016 10:04:08 -0700
Subject: [Matplotlib-devel] Advice on building wheels for Linux
Message-ID: <CAH6Pt5o40_sBS2JaC+tBY8rfzEPg-SZ+5588YzVBAG4hCym_gg@mail.gmail.com>

Hi,

I have been working on building manylinux [1] wheels for matplotlib.

My first-pass at a recipe for a matplotlib wheel is here:

https://github.com/matthew-brett/manylinux-builds/blob/master/build_matplotlibs.sh

The main work is deciding which external libraries to build - here's
that part of the recipe:

https://github.com/matthew-brett/manylinux-builds/blob/master/build_mpl_libs.sh

In short, I'm building libz, libbz2, libjpeg, libpng and freetype.

Is that the right list?  Should I add more?

I have built wheels for testing at https://nipy.bic.berkeley.edu/manylinux:

# upgrade pip to latest for manylinux support
python -m pip install --upgrade pip
pip install -f https://nipy.bic.berkeley.edu/manylinux matplotlib

I would be very grateful for any feedback,

Thanks a lot,

Matthew

[1] https://www.python.org/dev/peps/pep-0513/

From tcaswell at gmail.com  Mon Apr 25 01:53:49 2016
From: tcaswell at gmail.com (Thomas Caswell)
Date: Mon, 25 Apr 2016 05:53:49 +0000
Subject: [Matplotlib-devel] [rfc] a better interchange format for
 colormaps
In-Reply-To: <CALGmxEJuRsX5RbDuF7CTY-eKgWmmox21vaHkmpwecCNeXojQvw@mail.gmail.com>
References: <CAPJVwBkXX8QVHJp+zwsrMohDq79EgVmCE1-S9jah8zZvrT_kjA@mail.gmail.com>
 <CALGmxEJuRsX5RbDuF7CTY-eKgWmmox21vaHkmpwecCNeXojQvw@mail.gmail.com>
Message-ID: <CAA48SF_Bvxhnc7YfrFhqHRL8t5Po6UWUUg+wT+Q76R8b+5k09Q@mail.gmail.com>

A few quick comments:

We have a gsoc student who will be working on categorical axis which might
spill out in to improving the discrete color maps.

I agree about the importance of supporting alpha in color maps, by that
could be dealt with by using 'sRGBA' or 'RGBA' as the color space?

json is for better or worse the lingua franca these days. For something
this size hdf5 is super overkill.  It would also introduce a pretty heavy
dependencie to mpl that I would be inclined to reject (libhdf5, h5py and
implicitly cython).

I can see the advantage of being able to extract the number of points with
out parsing the data, but would want to see a case where that parsing is a
significant bottle neck to trade against the possible ambiguity of
including the same information twice.

Tom

On Thu, Apr 21, 2016, 12:24 Chris Barker <chris.barker at noaa.gov> wrote:

> Great idea!
>
> AS it happens, we're messing with colormaps ourselves here, and indeed to
> need to have consistent ones across browser-JS and python -- so great
> timing!
>
> I'm not so sure about the encoding of the colors -- I read the
> justification (nicely written), but I still think file size is pretty much
> a non-issue -- these are not going to be gigabytes no matter how you slice
> it. and the compressed file sizes are definitely close enough in size to
> make no difference. So I would much prefer:
>
> [ [r, g, b], [r,g,b], ....]
>
> However, maybe that's because I still can't wrap my head easily around hex
> :-)
>
> I think compatibility with D3 per se should be a minor influence, but if
> Javascript itself "likes" to use hex colors and could more easily deal with
> this, then I guess that might be a driver (or do I think that because I'm a
> pythonista that could easily write the conversion code in Python than JS
> ...)
>
> Also for discrete colormaps, might there be a use case for transparency?
> i.e. RGBA ? In which case, the encoding should be able to handle  either
> three or four channels per color with no ambiguity. Would that be two hex
> values per color for a 32 bit color (then you have to have a clean
> endianness, yes?) or commas or something separating the colors.
>
> As for specifying the number of colors somewhere else, I agree that that's
> just a recipe for inconsistency with no gain -- is anyone going to have to
> write a parser where they have to alocate teh memory ahead of time???
>
> -CHB
>
>
> On Wed, Apr 20, 2016 at 4:22 PM, Nathaniel Smith <njs at pobox.com> wrote:
>
>> Hi matplotters,
>>
>> We've been working on improving our tool for building custom
>> viridis-like colormaps (e.g. adding support for diverging colormaps),
>> and one of the things that we got frustrated by is how there's no
>> compelling way to save and distribute the resulting colormaps so that
>> people can actually use them. So, I wrote up a little spec to
>> standardize a way of storing and distributing colormaps in JSON, with
>> the hope that we can convince everyone to implement this and stop
>> writing silly little conversion scripts all the time.
>>
>> The v0.1 draft is here:
>>     https://github.com/njsmith/json-cm/blob/master/json-cm-spec.md
>>
>> Any comments? There are always a lot of fiddly details to get right in
>> this kind of thing -- I made a bunch of guesses about what kind of
>> stuff is important and how to represent it, but it can only benefit
>> from review from different perspectives. I would equally love to get
>> nitpicky critiques and high-level queries.
>>
>> Thanks!
>> -n
>>
>> --
>> Nathaniel J. Smith -- https://vorpus.org
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
>
> Chris.Barker at noaa.gov
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160425/bb5eee28/attachment.html>

From matthew.brett at gmail.com  Mon Apr 25 13:37:19 2016
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 25 Apr 2016 10:37:19 -0700
Subject: [Matplotlib-devel] Manylinux external library test case -
 matplotlib, tk
Message-ID: <CAH6Pt5o6+mDwyUarxVjYVKNJNAV0a6Ku0uRy4D77xOiPXuW8Tw@mail.gmail.com>

Hi,

I am building matplotlib manylinux wheels:

https://github.com/matthew-brett/manylinux-builds/blob/master/build_matplotlibs.sh

The problem is, what to do about the default matplotlib tk optional dependency?

Normally, matplotlib builds against the installed system tk libs :
https://github.com/matplotlib/matplotlib/blob/master/setupext.py#L1522

When building a manylinux wheel, we can only build against the tk libs
/ headers on the manylinux docker image, by doing `yum install -y
tk-devel` before building.

This means that the tk that matplotlib is built against, is different
from the one that Python uses with `import Tkinter`.  I suppose that
is what causes the following, when building matplotlib with tk-devel
installed:

>>> import matplotlib
>>> matplotlib.get_backend()
u'TkAgg'
>>> import matplotlib.pyplot as plt
>>> plt.plot(range(10))
[<matplotlib.lines.Line2D object at 0x7f2a8e4b4390>]
>>> plt.show()
Segmentation fault

I don't immediately see a good way to deal with this.  Any thoughts?

Cheers,

Matthew

From tcaswell at gmail.com  Mon Apr 25 14:58:16 2016
From: tcaswell at gmail.com (Thomas Caswell)
Date: Mon, 25 Apr 2016 18:58:16 +0000
Subject: [Matplotlib-devel] Manylinux external library test case -
 matplotlib, tk
In-Reply-To: <CAH6Pt5o6+mDwyUarxVjYVKNJNAV0a6Ku0uRy4D77xOiPXuW8Tw@mail.gmail.com>
References: <CAH6Pt5o6+mDwyUarxVjYVKNJNAV0a6Ku0uRy4D77xOiPXuW8Tw@mail.gmail.com>
Message-ID: <CAA48SF8JsQGZMUJ+Yxr3yYsQ_PhD3_NCJNJFvqtfmixt8_2yXQ@mail.gmail.com>

My only thought is to just not build the tk backend, shipping wheels that
are known to segfault is no good.

Is there any way to (optionally) do a bit of compilation on installation of
a binary wheel?

Tom

On Mon, Apr 25, 2016 at 1:38 PM Matthew Brett <matthew.brett at gmail.com>
wrote:

> Hi,
>
> I am building matplotlib manylinux wheels:
>
>
> https://github.com/matthew-brett/manylinux-builds/blob/master/build_matplotlibs.sh
>
> The problem is, what to do about the default matplotlib tk optional
> dependency?
>
> Normally, matplotlib builds against the installed system tk libs :
> https://github.com/matplotlib/matplotlib/blob/master/setupext.py#L1522
>
> When building a manylinux wheel, we can only build against the tk libs
> / headers on the manylinux docker image, by doing `yum install -y
> tk-devel` before building.
>
> This means that the tk that matplotlib is built against, is different
> from the one that Python uses with `import Tkinter`.  I suppose that
> is what causes the following, when building matplotlib with tk-devel
> installed:
>
> >>> import matplotlib
> >>> matplotlib.get_backend()
> u'TkAgg'
> >>> import matplotlib.pyplot as plt
> >>> plt.plot(range(10))
> [<matplotlib.lines.Line2D object at 0x7f2a8e4b4390>]
> >>> plt.show()
> Segmentation fault
>
> I don't immediately see a good way to deal with this.  Any thoughts?
>
> Cheers,
>
> Matthew
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160425/f85c59eb/attachment.html>

From matthew.brett at gmail.com  Mon Apr 25 15:03:26 2016
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 25 Apr 2016 12:03:26 -0700
Subject: [Matplotlib-devel] Manylinux external library test case -
 matplotlib, tk
In-Reply-To: <CAA48SF8JsQGZMUJ+Yxr3yYsQ_PhD3_NCJNJFvqtfmixt8_2yXQ@mail.gmail.com>
References: <CAH6Pt5o6+mDwyUarxVjYVKNJNAV0a6Ku0uRy4D77xOiPXuW8Tw@mail.gmail.com>
 <CAA48SF8JsQGZMUJ+Yxr3yYsQ_PhD3_NCJNJFvqtfmixt8_2yXQ@mail.gmail.com>
Message-ID: <CAH6Pt5pzZOpqvrm9xk3g_+y=BNynwQwRXz1ZLWPWqGGMi4zmGA@mail.gmail.com>

Hi,

On Mon, Apr 25, 2016 at 11:58 AM, Thomas Caswell <tcaswell at gmail.com> wrote:
> My only thought is to just not build the tk backend, shipping wheels that
> are known to segfault is no good.

:) - no good at all!

Incidentally, the wheels at http://nipy.bic.berkeley.edu/manylinux/ do
not have the tk backend, and so, do not (are not known to) segfault.

> Is there any way to (optionally) do a bit of compilation on installation of
> a binary wheel?

No, at least not with the `pip install` step.  The wheel install
mechanism doesn't have post-install hooks.

Is there an easy way to only do the tkagg build install, if we worked
out a way to trigger that?

Cheers,

Matthew

From ben.v.root at gmail.com  Mon Apr 25 15:19:31 2016
From: ben.v.root at gmail.com (Benjamin Root)
Date: Mon, 25 Apr 2016 15:19:31 -0400
Subject: [Matplotlib-devel] Manylinux external library test case -
 matplotlib, tk
In-Reply-To: <CAH6Pt5pzZOpqvrm9xk3g_+y=BNynwQwRXz1ZLWPWqGGMi4zmGA@mail.gmail.com>
References: <CAH6Pt5o6+mDwyUarxVjYVKNJNAV0a6Ku0uRy4D77xOiPXuW8Tw@mail.gmail.com>
 <CAA48SF8JsQGZMUJ+Yxr3yYsQ_PhD3_NCJNJFvqtfmixt8_2yXQ@mail.gmail.com>
 <CAH6Pt5pzZOpqvrm9xk3g_+y=BNynwQwRXz1ZLWPWqGGMi4zmGA@mail.gmail.com>
Message-ID: <CANNq6Fn9qUNCT0U3VPd++SnVw3bH=pzGmJaPo+7daWV2MwfPBw@mail.gmail.com>

What would be better is if we can get rid of the compilation requirement,
but from Michael's comments in the past, it seems that this isn't possible
at the moment. The problem is that the compiled portion provides the image
buffer access, which seems to not be available at the python level. Perhaps
it might make sense to pursue submitting our code to the Tk/Tcl project so
that we might be able to drop this step at some point?

Ben Root


On Mon, Apr 25, 2016 at 3:03 PM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> Hi,
>
> On Mon, Apr 25, 2016 at 11:58 AM, Thomas Caswell <tcaswell at gmail.com>
> wrote:
> > My only thought is to just not build the tk backend, shipping wheels that
> > are known to segfault is no good.
>
> :) - no good at all!
>
> Incidentally, the wheels at http://nipy.bic.berkeley.edu/manylinux/ do
> not have the tk backend, and so, do not (are not known to) segfault.
>
> > Is there any way to (optionally) do a bit of compilation on installation
> of
> > a binary wheel?
>
> No, at least not with the `pip install` step.  The wheel install
> mechanism doesn't have post-install hooks.
>
> Is there an easy way to only do the tkagg build install, if we worked
> out a way to trigger that?
>
> Cheers,
>
> Matthew
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160425/459ba23c/attachment.html>

From njs at pobox.com  Mon Apr 25 16:00:03 2016
From: njs at pobox.com (Nathaniel Smith)
Date: Mon, 25 Apr 2016 13:00:03 -0700
Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library
 test case - matplotlib, tk
In-Reply-To: <CAH6Pt5o6+mDwyUarxVjYVKNJNAV0a6Ku0uRy4D77xOiPXuW8Tw@mail.gmail.com>
References: <CAH6Pt5o6+mDwyUarxVjYVKNJNAV0a6Ku0uRy4D77xOiPXuW8Tw@mail.gmail.com>
Message-ID: <CAPJVwBk_7EVycUsupt22sTC0wgi5WzK8b45LUrgnxACXDT6Ymg@mail.gmail.com>

On Apr 25, 2016 10:38 AM, "Matthew Brett" <matthew.brett at gmail.com> wrote:
>
> Hi,
>
> I am building matplotlib manylinux wheels:
>
>
https://github.com/matthew-brett/manylinux-builds/blob/master/build_matplotlibs.sh
>
> The problem is, what to do about the default matplotlib tk optional
dependency?
>
> Normally, matplotlib builds against the installed system tk libs :
> https://github.com/matplotlib/matplotlib/blob/master/setupext.py#L1522
>
> When building a manylinux wheel, we can only build against the tk libs
> / headers on the manylinux docker image, by doing `yum install -y
> tk-devel` before building.
>
> This means that the tk that matplotlib is built against, is different
> from the one that Python uses with `import Tkinter`.  I suppose that
> is what causes the following, when building matplotlib with tk-devel
> installed:
>
> >>> import matplotlib
> >>> matplotlib.get_backend()
> u'TkAgg'
> >>> import matplotlib.pyplot as plt
> >>> plt.plot(range(10))
> [<matplotlib.lines.Line2D object at 0x7f2a8e4b4390>]
> >>> plt.show()
> Segmentation fault
>
> I don't immediately see a good way to deal with this.  Any thoughts?

Maybe obvious, but here's a syllogism:

If:
    matplotlib and python have to agree on which tk libs they are using,
and:
    there are inconsistencies between tk libs on different Linux systems
such that matplotlib must be built against the same tk as it eventually
uses,
then:
    we don't really have any option except to disable tk support in
matplotlib manylinux wheels

So I guess the question to focus on are whether those two premises are
actually true. I guess a backtrace on the segfault would help?

Also: how important is tk support? Do we have a fallback? I know that Qt
packaging is something of a mess right now too...

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160425/bc1c5978/attachment-0001.html>

From njs at pobox.com  Mon Apr 25 17:56:57 2016
From: njs at pobox.com (Nathaniel Smith)
Date: Mon, 25 Apr 2016 14:56:57 -0700
Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library
 test case - matplotlib, tk
In-Reply-To: <CAFvE7K5CcidUOPOwqeq_OEDiezBxPKetHK8QmjDCT4hiugxOLA@mail.gmail.com>
References: <CAH6Pt5o6+mDwyUarxVjYVKNJNAV0a6Ku0uRy4D77xOiPXuW8Tw@mail.gmail.com>
 <CAPJVwBk_7EVycUsupt22sTC0wgi5WzK8b45LUrgnxACXDT6Ymg@mail.gmail.com>
 <CAFvE7K5CcidUOPOwqeq_OEDiezBxPKetHK8QmjDCT4hiugxOLA@mail.gmail.com>
Message-ID: <CAPJVwBmAsvbb6ANEp7TwKkBr7jM0z2WdxHJn9f9s7+S14pSmcg@mail.gmail.com>

On Mon, Apr 25, 2016 at 2:52 PM, Olivier Grisel
<olivier.grisel at ensta.org> wrote:
> It would be nice to have a manylinux1 wheel for PyQT with embedded QT libs.

PySide might be an easier initial target -- they almost support
installing from wheels already. (You can make and post wheels, but
they have a post-install script you have to manually run. Presumably
whatever this does could be run from __init__.py on first import
instead, at least when installing into a venv...)

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From matthew.brett at gmail.com  Mon Apr 25 19:23:27 2016
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 25 Apr 2016 16:23:27 -0700
Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library
 test case - matplotlib, tk
In-Reply-To: <CAFvE7K4K0LZ7pH=CAPKNTgg2CiZgAKBdgkDjZ2trG9j_FbJ62w@mail.gmail.com>
References: <CAH6Pt5o6+mDwyUarxVjYVKNJNAV0a6Ku0uRy4D77xOiPXuW8Tw@mail.gmail.com>
 <CAA48SF8JsQGZMUJ+Yxr3yYsQ_PhD3_NCJNJFvqtfmixt8_2yXQ@mail.gmail.com>
 <CAH6Pt5pzZOpqvrm9xk3g_+y=BNynwQwRXz1ZLWPWqGGMi4zmGA@mail.gmail.com>
 <CANNq6Fn9qUNCT0U3VPd++SnVw3bH=pzGmJaPo+7daWV2MwfPBw@mail.gmail.com>
 <CAFvE7K4K0LZ7pH=CAPKNTgg2CiZgAKBdgkDjZ2trG9j_FbJ62w@mail.gmail.com>
Message-ID: <CAH6Pt5okCqF-bvBNB7JCYuf6t64i0Q-9TtKRYeTgfR5x_Rp0wQ@mail.gmail.com>

Hi,

On Mon, Apr 25, 2016 at 12:42 PM, Olivier Grisel
<olivier.grisel at ensta.org> wrote:
> 2016-04-25 21:19 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:
>> What would be better is if we can get rid of the compilation requirement,
>> but from Michael's comments in the past, it seems that this isn't possible
>> at the moment. The problem is that the compiled portion provides the image
>> buffer access, which seems to not be available at the python level. Perhaps
>> it might make sense to pursue submitting our code to the Tk/Tcl project so
>> that we might be able to drop this step at some point?
>
> Wouldn't it be possible to rewrite this part using ctypes instead?

I had the same thought - has anyone looked into that?

Thanks,

Matthew

From jayryuusei at gmail.com  Thu Apr 28 00:52:49 2016
From: jayryuusei at gmail.com (jayryuusei at gmail.com)
Date: Thu, 28 Apr 2016 04:52:49 +0000
Subject: [Matplotlib-devel] New to the list, MEPS,
 and plot serialization questions
Message-ID: <CAMPkvMcvxMDX-zYGDbhHgUnbPtGWDACOCe1UFEuivoWj-41LwA@mail.gmail.com>

Hi all,

I am a grad student in plasma physics and a long-time Python programmer. I
have used matplotlib off-and-on for years - I'd like to get involved. I
have certain features I am most interested in working on, so I thought I'd
reach out and let you all know I wanted to get started.

The first thing I am interested in working on is plot serialization. I read MEP
25 <http://matplotlib.org/devel/MEP/MEP25.html> and I am curious the
current status of it - specifically, are other people already working on
this, discussing it, and thinking about it or was it a feature request and
not much has been figured out? Are other developers open to adding this
kind of functionality? Are there strong opinions about how it should (or
shouldn't) be done?

I searched the mailing-list archive and I see this is a topic that has come
up a few times, but I am lost as to its current status and general
acceptance in the community. How do MEPs move from being Discussed to
approved, for example?

Thanks for the info, and most of all thank you for matplotlib!!!
-Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160428/8ee3b2ab/attachment.html>

From matthew.brett at gmail.com  Thu Apr 28 08:45:15 2016
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 28 Apr 2016 05:45:15 -0700
Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library
 test case - matplotlib, tk
In-Reply-To: <CAH6Pt5okCqF-bvBNB7JCYuf6t64i0Q-9TtKRYeTgfR5x_Rp0wQ@mail.gmail.com>
References: <CAH6Pt5o6+mDwyUarxVjYVKNJNAV0a6Ku0uRy4D77xOiPXuW8Tw@mail.gmail.com>
 <CAA48SF8JsQGZMUJ+Yxr3yYsQ_PhD3_NCJNJFvqtfmixt8_2yXQ@mail.gmail.com>
 <CAH6Pt5pzZOpqvrm9xk3g_+y=BNynwQwRXz1ZLWPWqGGMi4zmGA@mail.gmail.com>
 <CANNq6Fn9qUNCT0U3VPd++SnVw3bH=pzGmJaPo+7daWV2MwfPBw@mail.gmail.com>
 <CAFvE7K4K0LZ7pH=CAPKNTgg2CiZgAKBdgkDjZ2trG9j_FbJ62w@mail.gmail.com>
 <CAH6Pt5okCqF-bvBNB7JCYuf6t64i0Q-9TtKRYeTgfR5x_Rp0wQ@mail.gmail.com>
Message-ID: <CAH6Pt5ruiYk+iY8ozksaJhsNKzr-WZEmgU6qNCA8RYTG2byf+Q@mail.gmail.com>

Hi,

On Mon, Apr 25, 2016 at 4:23 PM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> On Mon, Apr 25, 2016 at 12:42 PM, Olivier Grisel
> <olivier.grisel at ensta.org> wrote:
>> 2016-04-25 21:19 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:
>>> What would be better is if we can get rid of the compilation requirement,
>>> but from Michael's comments in the past, it seems that this isn't possible
>>> at the moment. The problem is that the compiled portion provides the image
>>> buffer access, which seems to not be available at the python level. Perhaps
>>> it might make sense to pursue submitting our code to the Tk/Tcl project so
>>> that we might be able to drop this step at some point?
>>
>> Wouldn't it be possible to rewrite this part using ctypes instead?
>
> I had the same thought - has anyone looked into that?

I was thinking of looking into this.  It would be very useful to
unlink matplotlib from the tk compile.  It's already a pain to get
this right for OSX - for the wheel build, we have to download the
activestate tcl/tk, check it's the right version, link to it, and then
make sure we haven't shipped any of it :

https://github.com/MacPython/matplotlib-wheels/blob/master/run_install.sh#L5
https://github.com/MacPython/matplotlib-wheels/blob/master/check_tcl.py
https://github.com/MacPython/matplotlib-wheels/blob/master/mpl_delocate.py

I'm sure it's also annoying on Windows.

Michael D - are you the right person to ask about this stuff?   Do you
have any pointers about where the problems will be?

Thanks a lot,

Matthew

From kthyng at gmail.com  Fri Apr 22 10:30:49 2016
From: kthyng at gmail.com (kthyng)
Date: Fri, 22 Apr 2016 07:30:49 -0700 (MST)
Subject: [Matplotlib-devel] [rfc] a better interchange format for
 colormaps
In-Reply-To: <CALGmxEJuRsX5RbDuF7CTY-eKgWmmox21vaHkmpwecCNeXojQvw@mail.gmail.com>
References: <CAPJVwBkXX8QVHJp+zwsrMohDq79EgVmCE1-S9jah8zZvrT_kjA@mail.gmail.com>
 <CALGmxEJuRsX5RbDuF7CTY-eKgWmmox21vaHkmpwecCNeXojQvw@mail.gmail.com>
Message-ID: <CAMGH-oYPDq_EKT_kaEZM6Aps3SN4dFYHjsCnT4s=kfRAqq0Qvw@mail.gmail.com>

Columns of rgb points that I have been using for sharing colormaps have
been pretty easy and straight-forward (easily extended to 4 columns for
alpha). Is the main problem the lack of meta data?

Kristen

On Thu, Apr 21, 2016 at 2:24 PM, Chris Barker - NOAA Federal [via
matplotlib] <ml-node+s1069221n46987h22 at n5.nabble.com> wrote:

> Great idea!
>
> AS it happens, we're messing with colormaps ourselves here, and indeed to
> need to have consistent ones across browser-JS and python -- so great
> timing!
>
> I'm not so sure about the encoding of the colors -- I read the
> justification (nicely written), but I still think file size is pretty much
> a non-issue -- these are not going to be gigabytes no matter how you slice
> it. and the compressed file sizes are definitely close enough in size to
> make no difference. So I would much prefer:
>
> [ [r, g, b], [r,g,b], ....]
>
> However, maybe that's because I still can't wrap my head easily around hex
> :-)
>
> I think compatibility with D3 per se should be a minor influence, but if
> Javascript itself "likes" to use hex colors and could more easily deal with
> this, then I guess that might be a driver (or do I think that because I'm a
> pythonista that could easily write the conversion code in Python than JS
> ...)
>
> Also for discrete colormaps, might there be a use case for transparency?
> i.e. RGBA ? In which case, the encoding should be able to handle  either
> three or four channels per color with no ambiguity. Would that be two hex
> values per color for a 32 bit color (then you have to have a clean
> endianness, yes?) or commas or something separating the colors.
>
> As for specifying the number of colors somewhere else, I agree that that's
> just a recipe for inconsistency with no gain -- is anyone going to have to
> write a parser where they have to alocate teh memory ahead of time???
>
> -CHB
>
>
> On Wed, Apr 20, 2016 at 4:22 PM, Nathaniel Smith <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=46987&i=0>> wrote:
>
>> Hi matplotters,
>>
>> We've been working on improving our tool for building custom
>> viridis-like colormaps (e.g. adding support for diverging colormaps),
>> and one of the things that we got frustrated by is how there's no
>> compelling way to save and distribute the resulting colormaps so that
>> people can actually use them. So, I wrote up a little spec to
>> standardize a way of storing and distributing colormaps in JSON, with
>> the hope that we can convince everyone to implement this and stop
>> writing silly little conversion scripts all the time.
>>
>> The v0.1 draft is here:
>>     https://github.com/njsmith/json-cm/blob/master/json-cm-spec.md
>>
>> Any comments? There are always a lot of fiddly details to get right in
>> this kind of thing -- I made a bunch of guesses about what kind of
>> stuff is important and how to represent it, but it can only benefit
>> from review from different perspectives. I would equally love to get
>> nitpicky critiques and high-level queries.
>>
>> Thanks!
>> -n
>>
>> --
>> Nathaniel J. Smith -- https://vorpus.org
>> _______________________________________________
>> Matplotlib-devel mailing list
>> [hidden email] <http:///user/SendEmail.jtp?type=node&node=46987&i=1>
>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
>
> [hidden email] <http:///user/SendEmail.jtp?type=node&node=46987&i=2>
>
> _______________________________________________
> Matplotlib-devel mailing list
> [hidden email] <http:///user/SendEmail.jtp?type=node&node=46987&i=3>
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://matplotlib.1069221.n5.nabble.com/Matplotlib-devel-rfc-a-better-interchange-format-for-colormaps-tp46977p46987.html
> To start a new topic under matplotlib - devel, email
> ml-node+s1069221n28077h12 at n5.nabble.com
> To unsubscribe from matplotlib - devel, click here
> <http://matplotlib.1069221.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=28077&code=a3RoeW5nQGdtYWlsLmNvbXwyODA3N3wtMTk2MDcwNTI1Ng==>
> .
> NAML
> <http://matplotlib.1069221.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>



-- 
Kristen M. Thyng
Assistant Research Scientist
Department of Oceanography
Texas A&M University
Eller O&M 607
http://kristenthyng.com




--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Matplotlib-devel-rfc-a-better-interchange-format-for-colormaps-tp46977p46992.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160422/1b94d2b3/attachment-0001.html>

From olivier.grisel at ensta.org  Mon Apr 25 15:42:27 2016
From: olivier.grisel at ensta.org (Olivier Grisel)
Date: Mon, 25 Apr 2016 21:42:27 +0200
Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library
 test case - matplotlib, tk
In-Reply-To: <CANNq6Fn9qUNCT0U3VPd++SnVw3bH=pzGmJaPo+7daWV2MwfPBw@mail.gmail.com>
References: <CAH6Pt5o6+mDwyUarxVjYVKNJNAV0a6Ku0uRy4D77xOiPXuW8Tw@mail.gmail.com>
 <CAA48SF8JsQGZMUJ+Yxr3yYsQ_PhD3_NCJNJFvqtfmixt8_2yXQ@mail.gmail.com>
 <CAH6Pt5pzZOpqvrm9xk3g_+y=BNynwQwRXz1ZLWPWqGGMi4zmGA@mail.gmail.com>
 <CANNq6Fn9qUNCT0U3VPd++SnVw3bH=pzGmJaPo+7daWV2MwfPBw@mail.gmail.com>
Message-ID: <CAFvE7K4K0LZ7pH=CAPKNTgg2CiZgAKBdgkDjZ2trG9j_FbJ62w@mail.gmail.com>

2016-04-25 21:19 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:
> What would be better is if we can get rid of the compilation requirement,
> but from Michael's comments in the past, it seems that this isn't possible
> at the moment. The problem is that the compiled portion provides the image
> buffer access, which seems to not be available at the python level. Perhaps
> it might make sense to pursue submitting our code to the Tk/Tcl project so
> that we might be able to drop this step at some point?

Wouldn't it be possible to rewrite this part using ctypes instead?

-- 
Olivier Grisel

From olivier.grisel at ensta.org  Mon Apr 25 17:52:56 2016
From: olivier.grisel at ensta.org (Olivier Grisel)
Date: Mon, 25 Apr 2016 23:52:56 +0200
Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library
 test case - matplotlib, tk
In-Reply-To: <CAPJVwBk_7EVycUsupt22sTC0wgi5WzK8b45LUrgnxACXDT6Ymg@mail.gmail.com>
References: <CAH6Pt5o6+mDwyUarxVjYVKNJNAV0a6Ku0uRy4D77xOiPXuW8Tw@mail.gmail.com>
 <CAPJVwBk_7EVycUsupt22sTC0wgi5WzK8b45LUrgnxACXDT6Ymg@mail.gmail.com>
Message-ID: <CAFvE7K5CcidUOPOwqeq_OEDiezBxPKetHK8QmjDCT4hiugxOLA@mail.gmail.com>

It would be nice to have a manylinux1 wheel for PyQT with embedded QT libs.

-- 
Olivier

From mdboom at gmail.com  Thu Apr 28 08:54:17 2016
From: mdboom at gmail.com (Michael Droettboom)
Date: Thu, 28 Apr 2016 12:54:17 +0000
Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library
 test case - matplotlib, tk
In-Reply-To: <CAH6Pt5ruiYk+iY8ozksaJhsNKzr-WZEmgU6qNCA8RYTG2byf+Q@mail.gmail.com>
References: <CAH6Pt5o6+mDwyUarxVjYVKNJNAV0a6Ku0uRy4D77xOiPXuW8Tw@mail.gmail.com>
 <CAA48SF8JsQGZMUJ+Yxr3yYsQ_PhD3_NCJNJFvqtfmixt8_2yXQ@mail.gmail.com>
 <CAH6Pt5pzZOpqvrm9xk3g_+y=BNynwQwRXz1ZLWPWqGGMi4zmGA@mail.gmail.com>
 <CANNq6Fn9qUNCT0U3VPd++SnVw3bH=pzGmJaPo+7daWV2MwfPBw@mail.gmail.com>
 <CAFvE7K4K0LZ7pH=CAPKNTgg2CiZgAKBdgkDjZ2trG9j_FbJ62w@mail.gmail.com>
 <CAH6Pt5okCqF-bvBNB7JCYuf6t64i0Q-9TtKRYeTgfR5x_Rp0wQ@mail.gmail.com>
 <CAH6Pt5ruiYk+iY8ozksaJhsNKzr-WZEmgU6qNCA8RYTG2byf+Q@mail.gmail.com>
Message-ID: <CAJd6-49MN9-6QB4QcRygFp=-KjbO4NQcAgYdnREBm2BiRP9gPw@mail.gmail.com>

I'd be open to a ctypes implementation of the tk backend as long as it's
fully optional (like the current tk backend) since using ctypes excludes us
from use in restricted environments such as Google app engine.

Submitting the buffer hook to tcl/tk and/or tkinter would be nice.  All
other modern Python GUI frameworks have this feature.

Mike

On Thu, Apr 28, 2016, 8:45 AM Matthew Brett <matthew.brett at gmail.com> wrote:

> Hi,
>
> On Mon, Apr 25, 2016 at 4:23 PM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
> > Hi,
> >
> > On Mon, Apr 25, 2016 at 12:42 PM, Olivier Grisel
> > <olivier.grisel at ensta.org> wrote:
> >> 2016-04-25 21:19 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:
> >>> What would be better is if we can get rid of the compilation
> requirement,
> >>> but from Michael's comments in the past, it seems that this isn't
> possible
> >>> at the moment. The problem is that the compiled portion provides the
> image
> >>> buffer access, which seems to not be available at the python level.
> Perhaps
> >>> it might make sense to pursue submitting our code to the Tk/Tcl
> project so
> >>> that we might be able to drop this step at some point?
> >>
> >> Wouldn't it be possible to rewrite this part using ctypes instead?
> >
> > I had the same thought - has anyone looked into that?
>
> I was thinking of looking into this.  It would be very useful to
> unlink matplotlib from the tk compile.  It's already a pain to get
> this right for OSX - for the wheel build, we have to download the
> activestate tcl/tk, check it's the right version, link to it, and then
> make sure we haven't shipped any of it :
>
>
> https://github.com/MacPython/matplotlib-wheels/blob/master/run_install.sh#L5
> https://github.com/MacPython/matplotlib-wheels/blob/master/check_tcl.py
> https://github.com/MacPython/matplotlib-wheels/blob/master/mpl_delocate.py
>
> I'm sure it's also annoying on Windows.
>
> Michael D - are you the right person to ask about this stuff?   Do you
> have any pointers about where the problems will be?
>
> Thanks a lot,
>
> Matthew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160428/3f3bcfd9/attachment.html>

From chris.barker at noaa.gov  Sat Apr 30 00:23:41 2016
From: chris.barker at noaa.gov (Chris Barker)
Date: Fri, 29 Apr 2016 21:23:41 -0700
Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library
 test case - matplotlib, tk
In-Reply-To: <CAJd6-49MN9-6QB4QcRygFp=-KjbO4NQcAgYdnREBm2BiRP9gPw@mail.gmail.com>
References: <CAH6Pt5o6+mDwyUarxVjYVKNJNAV0a6Ku0uRy4D77xOiPXuW8Tw@mail.gmail.com>
 <CAA48SF8JsQGZMUJ+Yxr3yYsQ_PhD3_NCJNJFvqtfmixt8_2yXQ@mail.gmail.com>
 <CAH6Pt5pzZOpqvrm9xk3g_+y=BNynwQwRXz1ZLWPWqGGMi4zmGA@mail.gmail.com>
 <CANNq6Fn9qUNCT0U3VPd++SnVw3bH=pzGmJaPo+7daWV2MwfPBw@mail.gmail.com>
 <CAFvE7K4K0LZ7pH=CAPKNTgg2CiZgAKBdgkDjZ2trG9j_FbJ62w@mail.gmail.com>
 <CAH6Pt5okCqF-bvBNB7JCYuf6t64i0Q-9TtKRYeTgfR5x_Rp0wQ@mail.gmail.com>
 <CAH6Pt5ruiYk+iY8ozksaJhsNKzr-WZEmgU6qNCA8RYTG2byf+Q@mail.gmail.com>
 <CAJd6-49MN9-6QB4QcRygFp=-KjbO4NQcAgYdnREBm2BiRP9gPw@mail.gmail.com>
Message-ID: <CALGmxEL32b7fiN79H=v0tB2VJrrYZu4GFkksiuFm2yHu8CxVbQ@mail.gmail.com>

I'm sure I missed the conversation, but as tkInter is included with Python
itself, why can't the wheels link against the same version that python
ships??

> Submitting the buffer hook to tcl/tk and/or tkinter would be nice.

That would be the better solution, yes -- presumable to tkinter -- but
that's only going to help with Python 3.6 or greater.....

(or maybe it could be back-ported)

-CHB




-- 

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

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160429/2351a26d/attachment.html>

From njs at pobox.com  Sat Apr 30 03:43:20 2016
From: njs at pobox.com (Nathaniel Smith)
Date: Sat, 30 Apr 2016 00:43:20 -0700
Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library
 test case - matplotlib, tk
In-Reply-To: <CALGmxEL32b7fiN79H=v0tB2VJrrYZu4GFkksiuFm2yHu8CxVbQ@mail.gmail.com>
References: <CAH6Pt5o6+mDwyUarxVjYVKNJNAV0a6Ku0uRy4D77xOiPXuW8Tw@mail.gmail.com>
 <CAA48SF8JsQGZMUJ+Yxr3yYsQ_PhD3_NCJNJFvqtfmixt8_2yXQ@mail.gmail.com>
 <CAH6Pt5pzZOpqvrm9xk3g_+y=BNynwQwRXz1ZLWPWqGGMi4zmGA@mail.gmail.com>
 <CANNq6Fn9qUNCT0U3VPd++SnVw3bH=pzGmJaPo+7daWV2MwfPBw@mail.gmail.com>
 <CAFvE7K4K0LZ7pH=CAPKNTgg2CiZgAKBdgkDjZ2trG9j_FbJ62w@mail.gmail.com>
 <CAH6Pt5okCqF-bvBNB7JCYuf6t64i0Q-9TtKRYeTgfR5x_Rp0wQ@mail.gmail.com>
 <CAH6Pt5ruiYk+iY8ozksaJhsNKzr-WZEmgU6qNCA8RYTG2byf+Q@mail.gmail.com>
 <CAJd6-49MN9-6QB4QcRygFp=-KjbO4NQcAgYdnREBm2BiRP9gPw@mail.gmail.com>
 <CALGmxEL32b7fiN79H=v0tB2VJrrYZu4GFkksiuFm2yHu8CxVbQ@mail.gmail.com>
Message-ID: <CAPJVwBniC5FJn89q8EMdP3ND8hpTcGr7Su_X7W1idWMt1SRrGA@mail.gmail.com>

On Fri, Apr 29, 2016 at 9:23 PM, Chris Barker <chris.barker at noaa.gov> wrote:
> I'm sure I missed the conversation, but as tkInter is included with Python
> itself, why can't the wheels link against the same version that python
> ships??

The problem is that we're trying to make a single build of matplotlib
that works with multiple different builds of Python, which might come
with different, incompatible builds of tkInter -- so if we build
against the version shipped with python A then it will be broken on
python B and vice-versa.

Or maybe not -- Matthew's seeing a segfault, and it *might* be due to
the existence of fundamental ABI incompatibilities between different
tk builds, but it hasn't really been characterized.

>> Submitting the buffer hook to tcl/tk and/or tkinter would be nice.
>
> That would be the better solution, yes -- presumable to tkinter -- but
> that's only going to help with Python 3.6 or greater.....
>
> (or maybe it could be back-ported)

It might get backported to 3.5, maybe 3.4 if we're really quick, but
it won't get backported to 2.7, so yeah, anything involving changing
python upstream isn't going to be a short-term solution.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From ben.v.root at gmail.com  Sat Apr 30 11:16:46 2016
From: ben.v.root at gmail.com (Benjamin Root)
Date: Sat, 30 Apr 2016 11:16:46 -0400
Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library
 test case - matplotlib, tk
In-Reply-To: <CAPJVwBniC5FJn89q8EMdP3ND8hpTcGr7Su_X7W1idWMt1SRrGA@mail.gmail.com>
References: <CAH6Pt5o6+mDwyUarxVjYVKNJNAV0a6Ku0uRy4D77xOiPXuW8Tw@mail.gmail.com>
 <CAA48SF8JsQGZMUJ+Yxr3yYsQ_PhD3_NCJNJFvqtfmixt8_2yXQ@mail.gmail.com>
 <CAH6Pt5pzZOpqvrm9xk3g_+y=BNynwQwRXz1ZLWPWqGGMi4zmGA@mail.gmail.com>
 <CANNq6Fn9qUNCT0U3VPd++SnVw3bH=pzGmJaPo+7daWV2MwfPBw@mail.gmail.com>
 <CAFvE7K4K0LZ7pH=CAPKNTgg2CiZgAKBdgkDjZ2trG9j_FbJ62w@mail.gmail.com>
 <CAH6Pt5okCqF-bvBNB7JCYuf6t64i0Q-9TtKRYeTgfR5x_Rp0wQ@mail.gmail.com>
 <CAH6Pt5ruiYk+iY8ozksaJhsNKzr-WZEmgU6qNCA8RYTG2byf+Q@mail.gmail.com>
 <CAJd6-49MN9-6QB4QcRygFp=-KjbO4NQcAgYdnREBm2BiRP9gPw@mail.gmail.com>
 <CALGmxEL32b7fiN79H=v0tB2VJrrYZu4GFkksiuFm2yHu8CxVbQ@mail.gmail.com>
 <CAPJVwBniC5FJn89q8EMdP3ND8hpTcGr7Su_X7W1idWMt1SRrGA@mail.gmail.com>
Message-ID: <CANNq6FnvGAA235wyh+8bPhRWbVRDsGW_GnusPhUrYOU4W0hsXQ@mail.gmail.com>

Right. Submitting the patch won't address our near-term needs, but it'll
certainly position us better a few years from now. I am thinking that for
the near-term, we could have a fail-over mechanism. First attempt to access
the proposed ik interface (to be forward-compatible), failing that, then
attempt a ctypes interface. Failing that, fall back to our current
implementation. This gives a way forward for those in the restricted
environments to keep doing whatever has been working so far, while giving
everyone else an intermediate solution -- a usable GUI backend that will
almost always be guaranteed to work no matter in what order the packages
were installed.

Cheers!
Ben Root


On Sat, Apr 30, 2016 at 3:43 AM, Nathaniel Smith <njs at pobox.com> wrote:

> On Fri, Apr 29, 2016 at 9:23 PM, Chris Barker <chris.barker at noaa.gov>
> wrote:
> > I'm sure I missed the conversation, but as tkInter is included with
> Python
> > itself, why can't the wheels link against the same version that python
> > ships??
>
> The problem is that we're trying to make a single build of matplotlib
> that works with multiple different builds of Python, which might come
> with different, incompatible builds of tkInter -- so if we build
> against the version shipped with python A then it will be broken on
> python B and vice-versa.
>
> Or maybe not -- Matthew's seeing a segfault, and it *might* be due to
> the existence of fundamental ABI incompatibilities between different
> tk builds, but it hasn't really been characterized.
>
> >> Submitting the buffer hook to tcl/tk and/or tkinter would be nice.
> >
> > That would be the better solution, yes -- presumable to tkinter -- but
> > that's only going to help with Python 3.6 or greater.....
> >
> > (or maybe it could be back-ported)
>
> It might get backported to 3.5, maybe 3.4 if we're really quick, but
> it won't get backported to 2.7, so yeah, anything involving changing
> python upstream isn't going to be a short-term solution.
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160430/d61937e9/attachment.html>

From matthew.brett at gmail.com  Sat Apr 30 16:40:45 2016
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sat, 30 Apr 2016 16:40:45 -0400
Subject: [Matplotlib-devel] [Wheel-builders] Manylinux external library
 test case - matplotlib, tk
In-Reply-To: <CAPJVwBniC5FJn89q8EMdP3ND8hpTcGr7Su_X7W1idWMt1SRrGA@mail.gmail.com>
References: <CAH6Pt5o6+mDwyUarxVjYVKNJNAV0a6Ku0uRy4D77xOiPXuW8Tw@mail.gmail.com>
 <CAA48SF8JsQGZMUJ+Yxr3yYsQ_PhD3_NCJNJFvqtfmixt8_2yXQ@mail.gmail.com>
 <CAH6Pt5pzZOpqvrm9xk3g_+y=BNynwQwRXz1ZLWPWqGGMi4zmGA@mail.gmail.com>
 <CANNq6Fn9qUNCT0U3VPd++SnVw3bH=pzGmJaPo+7daWV2MwfPBw@mail.gmail.com>
 <CAFvE7K4K0LZ7pH=CAPKNTgg2CiZgAKBdgkDjZ2trG9j_FbJ62w@mail.gmail.com>
 <CAH6Pt5okCqF-bvBNB7JCYuf6t64i0Q-9TtKRYeTgfR5x_Rp0wQ@mail.gmail.com>
 <CAH6Pt5ruiYk+iY8ozksaJhsNKzr-WZEmgU6qNCA8RYTG2byf+Q@mail.gmail.com>
 <CAJd6-49MN9-6QB4QcRygFp=-KjbO4NQcAgYdnREBm2BiRP9gPw@mail.gmail.com>
 <CALGmxEL32b7fiN79H=v0tB2VJrrYZu4GFkksiuFm2yHu8CxVbQ@mail.gmail.com>
 <CAPJVwBniC5FJn89q8EMdP3ND8hpTcGr7Su_X7W1idWMt1SRrGA@mail.gmail.com>
Message-ID: <CAH6Pt5pEyhNNdAmB=S+2Z49h=YXA_eKh2xXbNRKekMzrnyiCwQ@mail.gmail.com>

On Sat, Apr 30, 2016 at 3:43 AM, Nathaniel Smith <njs at pobox.com> wrote:
> On Fri, Apr 29, 2016 at 9:23 PM, Chris Barker <chris.barker at noaa.gov> wrote:
>> I'm sure I missed the conversation, but as tkInter is included with Python
>> itself, why can't the wheels link against the same version that python
>> ships??
>
> The problem is that we're trying to make a single build of matplotlib
> that works with multiple different builds of Python, which might come
> with different, incompatible builds of tkInter -- so if we build
> against the version shipped with python A then it will be broken on
> python B and vice-versa.
>
> Or maybe not -- Matthew's seeing a segfault, and it *might* be due to
> the existence of fundamental ABI incompatibilities between different
> tk builds, but it hasn't really been characterized.

I'm in Cuba at the moment, so it's very difficult to run stuff remotely.

If you have access to benten.dlab.berkeley.edu, the build wheel is in
/home/mb312/dev_trees/manylinux-builds/wheelhouse - latest matplotlib
1.5.1 for Python 2.7.  Otherwise, the build recipe in manylinux-builds
should give a good clue as to how to replicate.

Cheers,

Matthew

From christophertfield at gmail.com  Sat Apr 30 12:59:36 2016
From: christophertfield at gmail.com (Christopher Field)
Date: Sat, 30 Apr 2016 16:59:36 -0000
Subject: [Matplotlib-devel] Offer of additions to subplots
Message-ID: <920E7B99-B2D7-41F3-A7FB-A3721ECDF637@gmail.com>

	I love pyplot.subplots and use it to create almost all of my graphs. I have implemented code for two subplots enhancements. Because I have never contributed to an open source project, I wanted to clear the additions before I put in the effort to learn how to make a contribution and implement all of the supporting documentation and samples.

	I found that was often writing
Fig, ax = plt.subplots( N, M, squeeze=False )
ax = ax.flatten()         or ax=ax.ravel()
	My addition provides a squeeze=?flatten? option, which always returns a 1D numpy array.  This is useful under three situations. First, there is a 2D arrangement of plots that are to be populated by indexing in a single loop. Second, there is a  1D arrangement of plots of variable number which, if squeeze=True, might return a single axis or a numpy array. Third, there is a 2D arrangement of plots that you wish to access with a single subscript.
	Does providing squeeze with bool or string values violate any rules?
	What is the clearest string to use? I have considered ?flatten?, ?flat?, ?ravel?, and ?1d?.

	The second enhancement permits sharing axis between different figures. It extends the sharex and sharey arguments to accept either an axis instance (in which case all of the new plots share the same x or y limits), or 1D or 2D numpy arrays of axis instances (in which case rows/columns are shared or each plot shares with the corresponding plot passed in.

	Should I invest the effort required to submit these? Is there a time frame in which these additions would be more or less welcome?

Thank you,
Christopher Field