From tcaswell at gmail.com  Fri Sep  1 01:24:19 2017
From: tcaswell at gmail.com (Thomas Caswell)
Date: Fri, 01 Sep 2017 05:24:19 +0000
Subject: [Matplotlib-devel] [ANN] Matplotlib v2.1.0rc1
Message-ID: <CAA48SF80nX4=+KymByV8o_+YTmr3gSw6PtePa8vMXss4hChtww@mail.gmail.com>

Folks,

I have tagged v2.1.0rc1 !!

For an initial draft of the release notes see
http://matplotlib.org/devdocs/users/whats_new.html

This release has been long in the making, thank you to the _many_ people
who worked on this (we are ~4.8k commits that are on master, but not in the
2.0.2 release).

Wheels, source, and conda-packages should be available tomorrow.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170901/0bedc584/attachment.html>

From tcaswell at gmail.com  Sat Sep  2 00:34:21 2017
From: tcaswell at gmail.com (Thomas Caswell)
Date: Sat, 02 Sep 2017 04:34:21 +0000
Subject: [Matplotlib-devel] [ANN]: Matplotlib 2.1.0rc1
Message-ID: <CAA48SF-5zfNuOGdZ2j+Z=N0TV910a1VOkZNMjhX64jbsUFjp9A@mail.gmail.com>

Folks,

We are happy to announce 2.1.0rc1!

Wheels and and source on pypi and as a conda package via conda-forge.
Please try it out and report any issues!

See http://matplotlib.org/devdocs/users/whats_new.html for a draft of the
release notes.   This represents ~2 years of work and includes many new
features and bug fixes.

Please checkout our updated documentation (
http://matplotlib.org/devdocs/index.html), particularly the  examples (
http://matplotlib.org/devdocs/gallery/index.html ) and tutorials (
http://matplotlib.org/devdocs/tutorials/index.html) .  Re-organizing,
updating, and migrating the examples to sphinx-gallery was a huge effort
led by Nelle Varoquaux and  Chris Holdgraf.

A big thanks to the many (~280) people who contributed to this release.

Installation instructions (via pip into existing venv):

  pip install --upgrade --pre matplotlib

or (via conda into a new venv)

  conda create -n mpl_rc matplotlib ipython -c conda-forge/label/rc -c
conda-forge

or(via conda into an existing venv)

 conda install -c conda-forge/label/rc matplotlib -c conda-forge

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170902/e2b67d80/attachment.html>

From tcaswell at gmail.com  Sat Sep  2 00:48:15 2017
From: tcaswell at gmail.com (Thomas Caswell)
Date: Sat, 02 Sep 2017 04:48:15 +0000
Subject: [Matplotlib-devel] current branches
Message-ID: <CAA48SF-GN53VfEcpOS8ZV3cRqG51EmnvwikBNbNffGFEYq9jgg@mail.gmail.com>

Folks,

As part of tagging the rc I created a v2.1.x branch.  Please direct bug
fixes for 2.1 to that branch and remember to backport PRs again.

If someone has the bandwidth to do so, looking into getting jupyter's
backport bot setup is probably a good idea.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170902/1efc2e66/attachment.html>

From rmay31 at gmail.com  Mon Sep  4 17:45:17 2017
From: rmay31 at gmail.com (Ryan May)
Date: Mon, 4 Sep 2017 15:45:17 -0600
Subject: [Matplotlib-devel] current branches
In-Reply-To: <CAA48SF-GN53VfEcpOS8ZV3cRqG51EmnvwikBNbNffGFEYq9jgg@mail.gmail.com>
References: <CAA48SF-GN53VfEcpOS8ZV3cRqG51EmnvwikBNbNffGFEYq9jgg@mail.gmail.com>
Message-ID: <CAKH0P+UG636a=7BM00COE6Wa7+S-D8z_RE5VYp5kzCxadxXttw@mail.gmail.com>

This is the bot in question:

https://github.com/MeeseeksBox/MeeseeksDev

Ryan

On Fri, Sep 1, 2017 at 10:48 PM, Thomas Caswell <tcaswell at gmail.com> wrote:

> Folks,
>
> As part of tagging the rc I created a v2.1.x branch.  Please direct bug
> fixes for 2.1 to that branch and remember to backport PRs again.
>
> If someone has the bandwidth to do so, looking into getting jupyter's
> backport bot setup is probably a good idea.
>
> Tom
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
>


-- 
Ryan May
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170904/c6f60299/attachment.html>

From bussonniermatthias at gmail.com  Mon Sep  4 18:38:19 2017
From: bussonniermatthias at gmail.com (Matthias Bussonnier)
Date: Mon, 4 Sep 2017 15:38:19 -0700
Subject: [Matplotlib-devel] current branches
In-Reply-To: <CAKH0P+UG636a=7BM00COE6Wa7+S-D8z_RE5VYp5kzCxadxXttw@mail.gmail.com>
References: <CAA48SF-GN53VfEcpOS8ZV3cRqG51EmnvwikBNbNffGFEYq9jgg@mail.gmail.com>
 <CAKH0P+UG636a=7BM00COE6Wa7+S-D8z_RE5VYp5kzCxadxXttw@mail.gmail.com>
Message-ID: <CANJQusWj0Ve0Orjz4erDG5NERXsp0FHcUYi6n7d4wXzkSdWq8g@mail.gmail.com>

Happy to give access to the repository and the heroku deployment to
anyone from Matplotlib dev that want it.

Right now the list of people that can trigger the bot is hardcoded
(just in case). And I've pushed a commit a few minutes ago that
should handle matplotlib branch names (prefixed with v).

So once someone from the core have enable the bot here:
https://github.com/apps/meeseeksdev, and the bot is restarted, you
should be able to start using it.

On Mon, Sep 4, 2017 at 2:45 PM, Ryan May <rmay31 at gmail.com> wrote:
> This is the bot in question:
>
> https://github.com/MeeseeksBox/MeeseeksDev
>
> Ryan
>
> On Fri, Sep 1, 2017 at 10:48 PM, Thomas Caswell <tcaswell at gmail.com> wrote:
>>
>> Folks,
>>
>> As part of tagging the rc I created a v2.1.x branch.  Please direct bug
>> fixes for 2.1 to that branch and remember to backport PRs again.
>>
>> If someone has the bandwidth to do so, looking into getting jupyter's
>> backport bot setup is probably a good idea.
>>
>> Tom
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>
>
>
>
> --
> Ryan May
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>

From jklymak at uvic.ca  Fri Sep  8 13:49:43 2017
From: jklymak at uvic.ca (Jody Klymak)
Date: Fri, 08 Sep 2017 10:49:43 -0700
Subject: [Matplotlib-devel] Python 2.7 build failing due to Unicode
 characters...
Message-ID: <6F802B84-29C7-4C74-9FDA-EC8E029D2139@uvic.ca>

Hi all,

Very sorry to be ignorant, but my python 2.7 build of the 
[constrained_layout 
manager](https://github.com/matplotlib/matplotlib/pull/9082) is failing 
because the underlying functions don?t accept unicode strings.  i.e. 
`boo(?test?)` fails with a warning: `TypeError: Expected object of 
type `float, int, or long`. Got object of type unicode instead.`  OK, 
the warning is a little confused - strings get converted to floats 
inside this fcn, but you get the idea?

Am I supposed to put `# -*- coding: utf-8 -*-` at the top of every 
source that might create a string that calls these functions?  Or should 
I convert the string somehow in my wrappers before passing down?  Or 
does `from __future__ import unicode_literals` do this?

Thanks for bearing with me,   Jody
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170908/ab495c8a/attachment.html>

From ben.v.root at gmail.com  Fri Sep  8 14:07:15 2017
From: ben.v.root at gmail.com (Benjamin Root)
Date: Fri, 8 Sep 2017 14:07:15 -0400
Subject: [Matplotlib-devel] Python 2.7 build failing due to Unicode
 characters...
In-Reply-To: <6F802B84-29C7-4C74-9FDA-EC8E029D2139@uvic.ca>
References: <6F802B84-29C7-4C74-9FDA-EC8E029D2139@uvic.ca>
Message-ID: <CANNq6Fm=xUEXR0Q9X0j07yj28UmKsqJitTo7RCeM8soUbiov1w@mail.gmail.com>

as a general rule, we have a set of __future__'s that we put at the top of
every python source:

```
from __future__ import (absolute_import, division, print_function,
                        unicode_literals)
```

Now, whether or not this would fix your problem or not, I haven't a clue.

On Fri, Sep 8, 2017 at 1:49 PM, Jody Klymak <jklymak at uvic.ca> wrote:

> Hi all,
>
> Very sorry to be ignorant, but my python 2.7 build of the constrained_layout
> manager <https://github.com/matplotlib/matplotlib/pull/9082> is failing
> because the underlying functions don?t accept unicode strings. i.e.
> boo(?test?) fails with a warning: TypeError: Expected object of typefloat,
> int, or long. Got object of type unicode instead. OK, the warning is a
> little confused - strings get converted to floats inside this fcn, but you
> get the idea?
>
> Am I supposed to put # -*- coding: utf-8 -*- at the top of every source
> that might create a string that calls these functions? Or should I convert
> the string somehow in my wrappers before passing down? Or does from
> __future__ import unicode_literals do this?
>
> Thanks for bearing with me, Jody
>
> _______________________________________________
> 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/20170908/ea933799/attachment.html>

From jklymak at uvic.ca  Fri Sep  8 17:11:15 2017
From: jklymak at uvic.ca (Jody Klymak)
Date: Fri, 08 Sep 2017 14:11:15 -0700
Subject: [Matplotlib-devel] Python 2.7 build failing due to Unicode
 characters...
In-Reply-To: <CANNq6Fm=xUEXR0Q9X0j07yj28UmKsqJitTo7RCeM8soUbiov1w@mail.gmail.com>
References: <6F802B84-29C7-4C74-9FDA-EC8E029D2139@uvic.ca>
 <CANNq6Fm=xUEXR0Q9X0j07yj28UmKsqJitTo7RCeM8soUbiov1w@mail.gmail.com>
Message-ID: <7910BE3B-43EE-4711-8FE5-B15F1927DE85@uvic.ca>



On 8 Sep 2017, at 11:07, Benjamin Root wrote:

> as a general rule, we have a set of __future__'s that we put at the 
> top of
> every python source:
>
> ```
> from __future__ import (absolute_import, division, print_function,
>                         unicode_literals)

Thanks!

Unfortunately, that is the problem.  `kiwi`, which is written in CPP, 
has a check for python version:

```
#if PY_MAJOR_VERSION >= 3
#define FROM_STRING PyUnicode_FromString
#else
#define FROM_STRING PyString_FromString
#endif
```

So it can handle Unicode, but has no way to know it *should* handle 
Unicode if we are using python 2.7 and `unicode_literals`.  I?ve 
opened [an issue with them,](https://github.com/nucleic/kiwi/issues/39) 
though of course if someone here had expertise in this it?d be very 
helpful.  Worst case scenario I can just cast every call to `str`, it 
just makes the code a bit of a mess.

Thanks a lot,   Jody


> ```
>
> Now, whether or not this would fix your problem or not, I haven't a 
> clue.
>
> On Fri, Sep 8, 2017 at 1:49 PM, Jody Klymak <jklymak at uvic.ca> wrote:
>
>> Hi all,
>>
>> Very sorry to be ignorant, but my python 2.7 build of the 
>> constrained_layout
>> manager <https://github.com/matplotlib/matplotlib/pull/9082> is 
>> failing
>> because the underlying functions don?t accept unicode strings. i.e.
>> boo(?test?) fails with a warning: TypeError: Expected object of 
>> typefloat,
>> int, or long. Got object of type unicode instead. OK, the warning is 
>> a
>> little confused - strings get converted to floats inside this fcn, 
>> but you
>> get the idea?
>>
>> Am I supposed to put # -*- coding: utf-8 -*- at the top of every 
>> source
>> that might create a string that calls these functions? Or should I 
>> convert
>> the string somehow in my wrappers before passing down? Or does from
>> __future__ import unicode_literals do this?
>>
>> Thanks for bearing with me, Jody
>>
>> _______________________________________________
>> 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/20170908/12300f77/attachment.html>

From chris.barker at noaa.gov  Mon Sep 11 16:56:17 2017
From: chris.barker at noaa.gov (Chris Barker)
Date: Mon, 11 Sep 2017 13:56:17 -0700
Subject: [Matplotlib-devel] Python 2.7 build failing due to Unicode
 characters...
In-Reply-To: <7910BE3B-43EE-4711-8FE5-B15F1927DE85@uvic.ca>
References: <6F802B84-29C7-4C74-9FDA-EC8E029D2139@uvic.ca>
 <CANNq6Fm=xUEXR0Q9X0j07yj28UmKsqJitTo7RCeM8soUbiov1w@mail.gmail.com>
 <7910BE3B-43EE-4711-8FE5-B15F1927DE85@uvic.ca>
Message-ID: <CALGmxEJ0Y+FwFo6R_5S6jAHkgbzZSkFi12YKwfQw=syezr6=3Q@mail.gmail.com>

On Fri, Sep 8, 2017 at 2:11 PM, Jody Klymak <jklymak at uvic.ca> wrote:

> Unfortunately, that is the problem. kiwi, which is written in CPP, has a
> check for python version:
>
> #if PY_MAJOR_VERSION >= 3
> #define FROM_STRING PyUnicode_FromString
> #else
> #define FROM_STRING PyString_FromString
> #endif
>
> ouch! IMHO, they made a major mistake here -- they should have used
Unicode in both versions, and cast a py2 string to unicode if need be.

> So it can handle Unicode, but has no way to know it *should* handle
> Unicode if we are using python 2.7 and unicode_literals.
>

actually, this looks like it can't handle unicode in the CPP code under py2
at all :-(

> I?ve opened an issue with them,
> <https://github.com/nucleic/kiwi/issues/39> though of course if someone
> here had expertise in this it?d be very helpful. Worst case scenario I can
> just cast every call to str, it just makes the code a bit of a mess.
>
unless they change the cpp, I think you'll have to do that. Then prepare
yourself for mysterious encoding errors to pop up later on ....

:-(

-CHB


> Now, whether or not this would fix your problem or not, I haven't a clue.
>
> the error is:
TypeError: Expected object of typefloat,
int, or long. Got object of type unicode instead.

are you sure this is a unicode instead of string problem? MAybe you need to
call float() or int() on the value before passing it in.

-CHB

> Am I supposed to put # -*- coding: utf-8 -*- at the top of every source
> that might create a string that calls these functions?
>
> that will make no difference.

> Or should I convert
> the string somehow in my wrappers before passing down?
>
> yeah, probably.

> Or does from
> __future__ import unicode_literals do this?
>
> what that does is make text literals, like:

"this is some  text"

a unicode object, rather than a py2string object -- but if the string comes
from somewhere else, it makes no difference.

But if that IS in the source, then you will get a lot more unicode objects
getting passed around.

-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/20170911/95a3377d/attachment.html>

From jklymak at uvic.ca  Mon Sep 11 17:00:18 2017
From: jklymak at uvic.ca (Jody Klymak)
Date: Mon, 11 Sep 2017 14:00:18 -0700
Subject: [Matplotlib-devel] Python 2.7 build failing due to Unicode
 characters...
In-Reply-To: <CALGmxEJ0Y+FwFo6R_5S6jAHkgbzZSkFi12YKwfQw=syezr6=3Q@mail.gmail.com>
References: <6F802B84-29C7-4C74-9FDA-EC8E029D2139@uvic.ca>
 <CANNq6Fm=xUEXR0Q9X0j07yj28UmKsqJitTo7RCeM8soUbiov1w@mail.gmail.com>
 <7910BE3B-43EE-4711-8FE5-B15F1927DE85@uvic.ca>
 <CALGmxEJ0Y+FwFo6R_5S6jAHkgbzZSkFi12YKwfQw=syezr6=3Q@mail.gmail.com>
Message-ID: <F1A3B4D4-8BED-41FE-AE2E-CEBDA75A36B5@uvic.ca>

Hi Chris,

We (they) are fixing it, though it quickly got out of my depth?  If 
you had any suggestions for them, I?m sure they would listen.  They 
are actively interested in addressing this.

https://github.com/nucleic/kiwi/pull/40

Thanks!   Jody



On 11 Sep 2017, at 13:56, Chris Barker wrote:

> On Fri, Sep 8, 2017 at 2:11 PM, Jody Klymak <jklymak at uvic.ca> wrote:
>
>> Unfortunately, that is the problem. kiwi, which is written in CPP, 
>> has a
>> check for python version:
>>
>> #if PY_MAJOR_VERSION >= 3
>> #define FROM_STRING PyUnicode_FromString
>> #else
>> #define FROM_STRING PyString_FromString
>> #endif
>>
>> ouch! IMHO, they made a major mistake here -- they should have used
> Unicode in both versions, and cast a py2 string to unicode if need be.
>
>> So it can handle Unicode, but has no way to know it *should* handle
>> Unicode if we are using python 2.7 and unicode_literals.
>>
>
> actually, this looks like it can't handle unicode in the CPP code 
> under py2
> at all :-(
>
>> I?ve opened an issue with them,
>> <https://github.com/nucleic/kiwi/issues/39> though of course if 
>> someone
>> here had expertise in this it?d be very helpful. Worst case 
>> scenario I can
>> just cast every call to str, it just makes the code a bit of a mess.
>>
> unless they change the cpp, I think you'll have to do that. Then 
> prepare
> yourself for mysterious encoding errors to pop up later on ....
>
> :-(
>
> -CHB
>
>
>> Now, whether or not this would fix your problem or not, I haven't a 
>> clue.
>>
>> the error is:
> TypeError: Expected object of typefloat,
> int, or long. Got object of type unicode instead.
>
> are you sure this is a unicode instead of string problem? MAybe you 
> need to
> call float() or int() on the value before passing it in.
>
> -CHB
>
>> Am I supposed to put # -*- coding: utf-8 -*- at the top of every 
>> source
>> that might create a string that calls these functions?
>>
>> that will make no difference.
>
>> Or should I convert
>> the string somehow in my wrappers before passing down?
>>
>> yeah, probably.
>
>> Or does from
>> __future__ import unicode_literals do this?
>>
>> what that does is make text literals, like:
>
> "this is some  text"
>
> a unicode object, rather than a py2string object -- but if the string 
> comes
> from somewhere else, it makes no difference.
>
> But if that IS in the source, then you will get a lot more unicode 
> objects
> getting passed around.
>
> -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/20170911/a0176bed/attachment-0001.html>

From f.faccenda86 at gmail.com  Wed Sep 13 03:31:35 2017
From: f.faccenda86 at gmail.com (Francesco Faccenda)
Date: Wed, 13 Sep 2017 09:31:35 +0200
Subject: [Matplotlib-devel] [matplotlib-devel] Make matplotlib running
 on GPU/CUDA
In-Reply-To: <CALGmxE+bset2QfPcOfyHMckNH1ko1M3EqWQeadiRS9EU6+g2Lg@mail.gmail.com>
References: <CAPp_WOqVavvXJoF255iTmdzZ0E9Dk2QQP3t3P3XkcgNpZz2o+A@mail.gmail.com>
 <CALGmxE+bset2QfPcOfyHMckNH1ko1M3EqWQeadiRS9EU6+g2Lg@mail.gmail.com>
Message-ID: <CAPp_WOpsGjMJFGc3Q6+TyD3im+StRraPAfMCz+jhehBGd+Byiw@mail.gmail.com>

Thank you Chris for your reply.

I have to admit I already stumbled on VisPy while doing my research on the
web. Still, I've got a lot of code already working with *matplotlib*.
Indeed, not only I plot data with it, but i manage a lot of *mpl events* to
provide the users usefool tools, like lines picking, tooltips, lines
copy/paste, square selectors for multiple selections, context menu and so
on. Moreover, I got matplotlib *embedded *on *wxpython *as well. While at
the beginning few lines were managed and noone complained, now that big
amout of data has to be displayed, the non-GPU core of the library is
starting to show its limits.

Since matplotlib is a reference library for this kind of  applications, I
thought it deserved an update in this direction. If anyone is willing to do
so, I'm available to discuss possible solutions and also provide any help I
can give.

Best regards,
Francesco Faccenda

2017-09-13 0:46 GMT+02:00 Chris Barker <chris.barker at noaa.gov>:

> On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda <
> f.faccenda86 at gmail.com> wrote:
>
>> But there?s a good news, I have a nice GPU available (an NVIDIA Tesla
>> K40c), so I?d like to know if there is a way to make matplotlib run on it,
>> or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.
>>
>
> I tihnk you want VisPy:
>
> https://vispy.readthedocs.io/en/latest/
>
> It's a plotting package with a kinda like  matplotlib API, built on OpenGL.
>
> Unfortunately, it doesn't look like it's been updated in a while -- from
> teh docs. But the gitHub project is active:
>
> https://github.com/vispy/vispy
>
> So maybe it's only the docs that haven't been updated!
>
> But probably  a much better option than trying to shoehorn GPU rendering
> into MPL.
>
> The problem is that while MPL was designed to be "backend" independent --
> so it is "easy" to plug in an alternative renderer, the rendering model is
> not really well suited to GPU rendering -- it would take a lot of
> refactoring to really be able to take advantage of the graphics card.
>
> -CHB
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE
> <https://maps.google.com/?q=7600+Sand+Point+Way+NE&entry=gmail&source=g>
>   (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/20170913/8c419f09/attachment.html>

From ben.v.root at gmail.com  Wed Sep 13 10:21:05 2017
From: ben.v.root at gmail.com (Benjamin Root)
Date: Wed, 13 Sep 2017 10:21:05 -0400
Subject: [Matplotlib-devel] [matplotlib-devel] Make matplotlib running
 on GPU/CUDA
In-Reply-To: <CAPp_WOpsGjMJFGc3Q6+TyD3im+StRraPAfMCz+jhehBGd+Byiw@mail.gmail.com>
References: <CAPp_WOqVavvXJoF255iTmdzZ0E9Dk2QQP3t3P3XkcgNpZz2o+A@mail.gmail.com>
 <CALGmxE+bset2QfPcOfyHMckNH1ko1M3EqWQeadiRS9EU6+g2Lg@mail.gmail.com>
 <CAPp_WOpsGjMJFGc3Q6+TyD3im+StRraPAfMCz+jhehBGd+Byiw@mail.gmail.com>
Message-ID: <CANNq6Fmmqstwi_BEVvGm37NnnzQ6xwPTAEi=O+dbd+qtiv=3Cg@mail.gmail.com>

A bit of background regarding efforts in this area...

A long time ago, some experiments were done to see if an opengl backend
could be made for matplotlib. The results weren't that great, particularly
for text rendering, so the effort was dropped. The core developers all
agree that an opengl backend would be neat to have, but we all have
limited, if any, experience developing opengl. Furthermore, such a backend
would likely require a lot of rapid development and trial-n-error. So, we
encouraged others to go develop a package or two separately, with the eye
for bringing it back into matplotlib when it was ready. Glumpy and a few
other projects were born from that prodding.

VisPy was an attempt to consolidate the development efforts for those
projects. The matplotlib devs had very fruitful discussions with some VisPy
devs back at SciPy 2015, but the project became non-responsive shortly
afterwards.

Ben Root


On Wed, Sep 13, 2017 at 3:31 AM, Francesco Faccenda <f.faccenda86 at gmail.com>
wrote:

> Thank you Chris for your reply.
>
> I have to admit I already stumbled on VisPy while doing my research on the
> web. Still, I've got a lot of code already working with *matplotlib*.
> Indeed, not only I plot data with it, but i manage a lot of *mpl events*
> to provide the users usefool tools, like lines picking, tooltips, lines
> copy/paste, square selectors for multiple selections, context menu and so
> on. Moreover, I got matplotlib *embedded *on *wxpython *as well. While at
> the beginning few lines were managed and noone complained, now that big
> amout of data has to be displayed, the non-GPU core of the library is
> starting to show its limits.
>
> Since matplotlib is a reference library for this kind of  applications, I
> thought it deserved an update in this direction. If anyone is willing to do
> so, I'm available to discuss possible solutions and also provide any help I
> can give.
>
> Best regards,
> Francesco Faccenda
>
> 2017-09-13 0:46 GMT+02:00 Chris Barker <chris.barker at noaa.gov>:
>
>> On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda <
>> f.faccenda86 at gmail.com> wrote:
>>
>>> But there?s a good news, I have a nice GPU available (an NVIDIA Tesla
>>> K40c), so I?d like to know if there is a way to make matplotlib run on it,
>>> or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.
>>>
>>
>> I tihnk you want VisPy:
>>
>> https://vispy.readthedocs.io/en/latest/
>>
>> It's a plotting package with a kinda like  matplotlib API, built on
>> OpenGL.
>>
>> Unfortunately, it doesn't look like it's been updated in a while -- from
>> teh docs. But the gitHub project is active:
>>
>> https://github.com/vispy/vispy
>>
>> So maybe it's only the docs that haven't been updated!
>>
>> But probably  a much better option than trying to shoehorn GPU rendering
>> into MPL.
>>
>> The problem is that while MPL was designed to be "backend" independent --
>> so it is "easy" to plug in an alternative renderer, the rendering model is
>> not really well suited to GPU rendering -- it would take a lot of
>> refactoring to really be able to take advantage of the graphics card.
>>
>> -CHB
>>
>>
>> --
>>
>> Christopher Barker, Ph.D.
>> Oceanographer
>>
>> Emergency Response Division
>> NOAA/NOS/OR&R            (206) 526-6959   voice
>> 7600 Sand Point Way NE
>> <https://maps.google.com/?q=7600+Sand+Point+Way+NE&entry=gmail&source=g>
>>   (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/20170913/ab39dca3/attachment.html>

From f.faccenda86 at gmail.com  Thu Sep 14 09:34:02 2017
From: f.faccenda86 at gmail.com (Francesco Faccenda)
Date: Thu, 14 Sep 2017 15:34:02 +0200
Subject: [Matplotlib-devel] [matplotlib-devel] Make matplotlib running
 on GPU/CUDA
In-Reply-To: <CANNq6Fmmqstwi_BEVvGm37NnnzQ6xwPTAEi=O+dbd+qtiv=3Cg@mail.gmail.com>
References: <CAPp_WOqVavvXJoF255iTmdzZ0E9Dk2QQP3t3P3XkcgNpZz2o+A@mail.gmail.com>
 <CALGmxE+bset2QfPcOfyHMckNH1ko1M3EqWQeadiRS9EU6+g2Lg@mail.gmail.com>
 <CAPp_WOpsGjMJFGc3Q6+TyD3im+StRraPAfMCz+jhehBGd+Byiw@mail.gmail.com>
 <CANNq6Fmmqstwi_BEVvGm37NnnzQ6xwPTAEi=O+dbd+qtiv=3Cg@mail.gmail.com>
Message-ID: <CAPp_WOpzq78gOKXfFeR7qN-mBE0gauM2odGxqGN3gMkdR=RT4A@mail.gmail.com>

Thank you, Ben.

unfortunately I don't have experience developing opengl neither, but I'd
like to make an attempt riesuming this subject.

I am starting from this: https://github.com/ChrisBeaumont/mplgl

Can anyone confirm this is the last update we have for this project?

Francesco Faccenda

2017-09-13 16:21 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:

> A bit of background regarding efforts in this area...
>
> A long time ago, some experiments were done to see if an opengl backend
> could be made for matplotlib. The results weren't that great, particularly
> for text rendering, so the effort was dropped. The core developers all
> agree that an opengl backend would be neat to have, but we all have
> limited, if any, experience developing opengl. Furthermore, such a backend
> would likely require a lot of rapid development and trial-n-error. So, we
> encouraged others to go develop a package or two separately, with the eye
> for bringing it back into matplotlib when it was ready. Glumpy and a few
> other projects were born from that prodding.
>
> VisPy was an attempt to consolidate the development efforts for those
> projects. The matplotlib devs had very fruitful discussions with some VisPy
> devs back at SciPy 2015, but the project became non-responsive shortly
> afterwards.
>
> Ben Root
>
>
> On Wed, Sep 13, 2017 at 3:31 AM, Francesco Faccenda <
> f.faccenda86 at gmail.com> wrote:
>
>> Thank you Chris for your reply.
>>
>> I have to admit I already stumbled on VisPy while doing my research on
>> the web. Still, I've got a lot of code already working with *matplotlib*.
>> Indeed, not only I plot data with it, but i manage a lot of *mpl events*
>> to provide the users usefool tools, like lines picking, tooltips, lines
>> copy/paste, square selectors for multiple selections, context menu and so
>> on. Moreover, I got matplotlib *embedded *on *wxpython *as well. While
>> at the beginning few lines were managed and noone complained, now that big
>> amout of data has to be displayed, the non-GPU core of the library is
>> starting to show its limits.
>>
>> Since matplotlib is a reference library for this kind of  applications, I
>> thought it deserved an update in this direction. If anyone is willing to do
>> so, I'm available to discuss possible solutions and also provide any help I
>> can give.
>>
>> Best regards,
>> Francesco Faccenda
>>
>> 2017-09-13 0:46 GMT+02:00 Chris Barker <chris.barker at noaa.gov>:
>>
>>> On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda <
>>> f.faccenda86 at gmail.com> wrote:
>>>
>>>> But there?s a good news, I have a nice GPU available (an NVIDIA Tesla
>>>> K40c), so I?d like to know if there is a way to make matplotlib run on it,
>>>> or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.
>>>>
>>>
>>> I tihnk you want VisPy:
>>>
>>> https://vispy.readthedocs.io/en/latest/
>>>
>>> It's a plotting package with a kinda like  matplotlib API, built on
>>> OpenGL.
>>>
>>> Unfortunately, it doesn't look like it's been updated in a while -- from
>>> teh docs. But the gitHub project is active:
>>>
>>> https://github.com/vispy/vispy
>>>
>>> So maybe it's only the docs that haven't been updated!
>>>
>>> But probably  a much better option than trying to shoehorn GPU rendering
>>> into MPL.
>>>
>>> The problem is that while MPL was designed to be "backend" independent
>>> -- so it is "easy" to plug in an alternative renderer, the rendering model
>>> is not really well suited to GPU rendering -- it would take a lot of
>>> refactoring to really be able to take advantage of the graphics card.
>>>
>>> -CHB
>>>
>>>
>>> --
>>>
>>> Christopher Barker, Ph.D.
>>> Oceanographer
>>>
>>> Emergency Response Division
>>> NOAA/NOS/OR&R            (206) 526-6959   voice
>>> 7600 Sand Point Way NE
>>> <https://maps.google.com/?q=7600+Sand+Point+Way+NE&entry=gmail&source=g>
>>>   (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/20170914/faafcb0e/attachment.html>

From ben.v.root at gmail.com  Thu Sep 14 09:50:53 2017
From: ben.v.root at gmail.com (Benjamin Root)
Date: Thu, 14 Sep 2017 09:50:53 -0400
Subject: [Matplotlib-devel] [matplotlib-devel] Make matplotlib running
 on GPU/CUDA
In-Reply-To: <CAPp_WOpzq78gOKXfFeR7qN-mBE0gauM2odGxqGN3gMkdR=RT4A@mail.gmail.com>
References: <CAPp_WOqVavvXJoF255iTmdzZ0E9Dk2QQP3t3P3XkcgNpZz2o+A@mail.gmail.com>
 <CALGmxE+bset2QfPcOfyHMckNH1ko1M3EqWQeadiRS9EU6+g2Lg@mail.gmail.com>
 <CAPp_WOpsGjMJFGc3Q6+TyD3im+StRraPAfMCz+jhehBGd+Byiw@mail.gmail.com>
 <CANNq6Fmmqstwi_BEVvGm37NnnzQ6xwPTAEi=O+dbd+qtiv=3Cg@mail.gmail.com>
 <CAPp_WOpzq78gOKXfFeR7qN-mBE0gauM2odGxqGN3gMkdR=RT4A@mail.gmail.com>
Message-ID: <CANNq6Fm3kigJZAGjgzKY8PkFuzBH6e_1aa1_tAA6qSfCiKqovQ@mail.gmail.com>

That was one of the old attempts (but not the oldest). It doesn't seem like
it ever intersected with the vispy project, though, so it is likely all
that exists.

I would also look at https://www.youtube.com/watch?v=_3YoaeoiIFI
Luke does a nice job providing an overview of the vispy package. One of the
most exciting things that the matplotlib and vispy devs were discussing at
scipy 2015 was the possibility of making a matplotlib backend out of some
parts from vispy. It was attractive because the vispy folks were actively
working on improving their opengl code and packaging to make it work on a
wide variety of hardware and setups. They had supposedly even implemented a
headless opengl mode, too, which was very important for us.

Cheers!
Ben Root


On Thu, Sep 14, 2017 at 9:34 AM, Francesco Faccenda <f.faccenda86 at gmail.com>
wrote:

> Thank you, Ben.
>
> unfortunately I don't have experience developing opengl neither, but I'd
> like to make an attempt riesuming this subject.
>
> I am starting from this: https://github.com/ChrisBeaumont/mplgl
>
> Can anyone confirm this is the last update we have for this project?
>
> Francesco Faccenda
>
> 2017-09-13 16:21 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:
>
>> A bit of background regarding efforts in this area...
>>
>> A long time ago, some experiments were done to see if an opengl backend
>> could be made for matplotlib. The results weren't that great, particularly
>> for text rendering, so the effort was dropped. The core developers all
>> agree that an opengl backend would be neat to have, but we all have
>> limited, if any, experience developing opengl. Furthermore, such a backend
>> would likely require a lot of rapid development and trial-n-error. So, we
>> encouraged others to go develop a package or two separately, with the eye
>> for bringing it back into matplotlib when it was ready. Glumpy and a few
>> other projects were born from that prodding.
>>
>> VisPy was an attempt to consolidate the development efforts for those
>> projects. The matplotlib devs had very fruitful discussions with some VisPy
>> devs back at SciPy 2015, but the project became non-responsive shortly
>> afterwards.
>>
>> Ben Root
>>
>>
>> On Wed, Sep 13, 2017 at 3:31 AM, Francesco Faccenda <
>> f.faccenda86 at gmail.com> wrote:
>>
>>> Thank you Chris for your reply.
>>>
>>> I have to admit I already stumbled on VisPy while doing my research on
>>> the web. Still, I've got a lot of code already working with *matplotlib*.
>>> Indeed, not only I plot data with it, but i manage a lot of *mpl events*
>>> to provide the users usefool tools, like lines picking, tooltips, lines
>>> copy/paste, square selectors for multiple selections, context menu and so
>>> on. Moreover, I got matplotlib *embedded *on *wxpython *as well. While
>>> at the beginning few lines were managed and noone complained, now that big
>>> amout of data has to be displayed, the non-GPU core of the library is
>>> starting to show its limits.
>>>
>>> Since matplotlib is a reference library for this kind of  applications,
>>> I thought it deserved an update in this direction. If anyone is willing to
>>> do so, I'm available to discuss possible solutions and also provide any
>>> help I can give.
>>>
>>> Best regards,
>>> Francesco Faccenda
>>>
>>> 2017-09-13 0:46 GMT+02:00 Chris Barker <chris.barker at noaa.gov>:
>>>
>>>> On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda <
>>>> f.faccenda86 at gmail.com> wrote:
>>>>
>>>>> But there?s a good news, I have a nice GPU available (an NVIDIA Tesla
>>>>> K40c), so I?d like to know if there is a way to make matplotlib run on it,
>>>>> or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.
>>>>>
>>>>
>>>> I tihnk you want VisPy:
>>>>
>>>> https://vispy.readthedocs.io/en/latest/
>>>>
>>>> It's a plotting package with a kinda like  matplotlib API, built on
>>>> OpenGL.
>>>>
>>>> Unfortunately, it doesn't look like it's been updated in a while --
>>>> from teh docs. But the gitHub project is active:
>>>>
>>>> https://github.com/vispy/vispy
>>>>
>>>> So maybe it's only the docs that haven't been updated!
>>>>
>>>> But probably  a much better option than trying to shoehorn GPU
>>>> rendering into MPL.
>>>>
>>>> The problem is that while MPL was designed to be "backend" independent
>>>> -- so it is "easy" to plug in an alternative renderer, the rendering model
>>>> is not really well suited to GPU rendering -- it would take a lot of
>>>> refactoring to really be able to take advantage of the graphics card.
>>>>
>>>> -CHB
>>>>
>>>>
>>>> --
>>>>
>>>> Christopher Barker, Ph.D.
>>>> Oceanographer
>>>>
>>>> Emergency Response Division
>>>> NOAA/NOS/OR&R            (206) 526-6959   voice
>>>> 7600 Sand Point Way NE
>>>> <https://maps.google.com/?q=7600+Sand+Point+Way+NE&entry=gmail&source=g>
>>>>   (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/20170914/9ef4dbe5/attachment-0001.html>

From f.faccenda86 at gmail.com  Thu Sep 14 10:37:41 2017
From: f.faccenda86 at gmail.com (Francesco Faccenda)
Date: Thu, 14 Sep 2017 16:37:41 +0200
Subject: [Matplotlib-devel] [matplotlib-devel] Make matplotlib running
 on GPU/CUDA
In-Reply-To: <CANNq6Fm3kigJZAGjgzKY8PkFuzBH6e_1aa1_tAA6qSfCiKqovQ@mail.gmail.com>
References: <CAPp_WOqVavvXJoF255iTmdzZ0E9Dk2QQP3t3P3XkcgNpZz2o+A@mail.gmail.com>
 <CALGmxE+bset2QfPcOfyHMckNH1ko1M3EqWQeadiRS9EU6+g2Lg@mail.gmail.com>
 <CAPp_WOpsGjMJFGc3Q6+TyD3im+StRraPAfMCz+jhehBGd+Byiw@mail.gmail.com>
 <CANNq6Fmmqstwi_BEVvGm37NnnzQ6xwPTAEi=O+dbd+qtiv=3Cg@mail.gmail.com>
 <CAPp_WOpzq78gOKXfFeR7qN-mBE0gauM2odGxqGN3gMkdR=RT4A@mail.gmail.com>
 <CANNq6Fm3kigJZAGjgzKY8PkFuzBH6e_1aa1_tAA6qSfCiKqovQ@mail.gmail.com>
Message-ID: <CAPp_WOp-x_Py=A1Q+x_i_o8j_NTtQg--qim8_0PxV7fEb7OyVw@mail.gmail.com>

I'll take a look, thank you.

So you are suggesting me to start form the VisPy code? Is there someone who
I can refer in case I will need some clarification?

Francesco Faccenda

2017-09-14 15:50 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:

> That was one of the old attempts (but not the oldest). It doesn't seem
> like it ever intersected with the vispy project, though, so it is likely
> all that exists.
>
> I would also look at https://www.youtube.com/watch?v=_3YoaeoiIFI
> Luke does a nice job providing an overview of the vispy package. One of
> the most exciting things that the matplotlib and vispy devs were discussing
> at scipy 2015 was the possibility of making a matplotlib backend out of
> some parts from vispy. It was attractive because the vispy folks were
> actively working on improving their opengl code and packaging to make it
> work on a wide variety of hardware and setups. They had supposedly even
> implemented a headless opengl mode, too, which was very important for us.
>
> Cheers!
> Ben Root
>
>
> On Thu, Sep 14, 2017 at 9:34 AM, Francesco Faccenda <
> f.faccenda86 at gmail.com> wrote:
>
>> Thank you, Ben.
>>
>> unfortunately I don't have experience developing opengl neither, but I'd
>> like to make an attempt riesuming this subject.
>>
>> I am starting from this: https://github.com/ChrisBeaumont/mplgl
>>
>> Can anyone confirm this is the last update we have for this project?
>>
>> Francesco Faccenda
>>
>> 2017-09-13 16:21 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:
>>
>>> A bit of background regarding efforts in this area...
>>>
>>> A long time ago, some experiments were done to see if an opengl backend
>>> could be made for matplotlib. The results weren't that great, particularly
>>> for text rendering, so the effort was dropped. The core developers all
>>> agree that an opengl backend would be neat to have, but we all have
>>> limited, if any, experience developing opengl. Furthermore, such a backend
>>> would likely require a lot of rapid development and trial-n-error. So, we
>>> encouraged others to go develop a package or two separately, with the eye
>>> for bringing it back into matplotlib when it was ready. Glumpy and a few
>>> other projects were born from that prodding.
>>>
>>> VisPy was an attempt to consolidate the development efforts for those
>>> projects. The matplotlib devs had very fruitful discussions with some VisPy
>>> devs back at SciPy 2015, but the project became non-responsive shortly
>>> afterwards.
>>>
>>> Ben Root
>>>
>>>
>>> On Wed, Sep 13, 2017 at 3:31 AM, Francesco Faccenda <
>>> f.faccenda86 at gmail.com> wrote:
>>>
>>>> Thank you Chris for your reply.
>>>>
>>>> I have to admit I already stumbled on VisPy while doing my research on
>>>> the web. Still, I've got a lot of code already working with
>>>> *matplotlib*. Indeed, not only I plot data with it, but i manage a lot
>>>> of *mpl events* to provide the users usefool tools, like lines
>>>> picking, tooltips, lines copy/paste, square selectors for multiple
>>>> selections, context menu and so on. Moreover, I got matplotlib *embedded
>>>> *on *wxpython *as well. While at the beginning few lines were managed
>>>> and noone complained, now that big amout of data has to be displayed, the
>>>> non-GPU core of the library is starting to show its limits.
>>>>
>>>> Since matplotlib is a reference library for this kind of  applications,
>>>> I thought it deserved an update in this direction. If anyone is willing to
>>>> do so, I'm available to discuss possible solutions and also provide any
>>>> help I can give.
>>>>
>>>> Best regards,
>>>> Francesco Faccenda
>>>>
>>>> 2017-09-13 0:46 GMT+02:00 Chris Barker <chris.barker at noaa.gov>:
>>>>
>>>>> On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda <
>>>>> f.faccenda86 at gmail.com> wrote:
>>>>>
>>>>>> But there?s a good news, I have a nice GPU available (an NVIDIA Tesla
>>>>>> K40c), so I?d like to know if there is a way to make matplotlib run on it,
>>>>>> or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.
>>>>>>
>>>>>
>>>>> I tihnk you want VisPy:
>>>>>
>>>>> https://vispy.readthedocs.io/en/latest/
>>>>>
>>>>> It's a plotting package with a kinda like  matplotlib API, built on
>>>>> OpenGL.
>>>>>
>>>>> Unfortunately, it doesn't look like it's been updated in a while --
>>>>> from teh docs. But the gitHub project is active:
>>>>>
>>>>> https://github.com/vispy/vispy
>>>>>
>>>>> So maybe it's only the docs that haven't been updated!
>>>>>
>>>>> But probably  a much better option than trying to shoehorn GPU
>>>>> rendering into MPL.
>>>>>
>>>>> The problem is that while MPL was designed to be "backend" independent
>>>>> -- so it is "easy" to plug in an alternative renderer, the rendering model
>>>>> is not really well suited to GPU rendering -- it would take a lot of
>>>>> refactoring to really be able to take advantage of the graphics card.
>>>>>
>>>>> -CHB
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Christopher Barker, Ph.D.
>>>>> Oceanographer
>>>>>
>>>>> Emergency Response Division
>>>>> NOAA/NOS/OR&R            (206) 526-6959   voice
>>>>> 7600 Sand Point Way NE
>>>>> <https://maps.google.com/?q=7600+Sand+Point+Way+NE&entry=gmail&source=g>
>>>>>   (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/20170914/c5c732e1/attachment.html>

From ben.v.root at gmail.com  Thu Sep 14 10:47:00 2017
From: ben.v.root at gmail.com (Benjamin Root)
Date: Thu, 14 Sep 2017 10:47:00 -0400
Subject: [Matplotlib-devel] [matplotlib-devel] Make matplotlib running
 on GPU/CUDA
In-Reply-To: <CAPp_WOp-x_Py=A1Q+x_i_o8j_NTtQg--qim8_0PxV7fEb7OyVw@mail.gmail.com>
References: <CAPp_WOqVavvXJoF255iTmdzZ0E9Dk2QQP3t3P3XkcgNpZz2o+A@mail.gmail.com>
 <CALGmxE+bset2QfPcOfyHMckNH1ko1M3EqWQeadiRS9EU6+g2Lg@mail.gmail.com>
 <CAPp_WOpsGjMJFGc3Q6+TyD3im+StRraPAfMCz+jhehBGd+Byiw@mail.gmail.com>
 <CANNq6Fmmqstwi_BEVvGm37NnnzQ6xwPTAEi=O+dbd+qtiv=3Cg@mail.gmail.com>
 <CAPp_WOpzq78gOKXfFeR7qN-mBE0gauM2odGxqGN3gMkdR=RT4A@mail.gmail.com>
 <CANNq6Fm3kigJZAGjgzKY8PkFuzBH6e_1aa1_tAA6qSfCiKqovQ@mail.gmail.com>
 <CAPp_WOp-x_Py=A1Q+x_i_o8j_NTtQg--qim8_0PxV7fEb7OyVw@mail.gmail.com>
Message-ID: <CANNq6FkSb8mttAPs6hoT3wbDczMNn7vdVtYTWHx2R9fPry5VFQ@mail.gmail.com>

The person who has been most responsive to me in the past would be Nicolas
Rougier <http://www.loria.fr/%7Erougier/index.html>, who developed glumpy.
He might also be able to give you a better sense of where to start.

Ben Root

On Thu, Sep 14, 2017 at 10:37 AM, Francesco Faccenda <f.faccenda86 at gmail.com
> wrote:

> I'll take a look, thank you.
>
> So you are suggesting me to start form the VisPy code? Is there someone
> who I can refer in case I will need some clarification?
>
> Francesco Faccenda
>
> 2017-09-14 15:50 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:
>
>> That was one of the old attempts (but not the oldest). It doesn't seem
>> like it ever intersected with the vispy project, though, so it is likely
>> all that exists.
>>
>> I would also look at https://www.youtube.com/watch?v=_3YoaeoiIFI
>> Luke does a nice job providing an overview of the vispy package. One of
>> the most exciting things that the matplotlib and vispy devs were discussing
>> at scipy 2015 was the possibility of making a matplotlib backend out of
>> some parts from vispy. It was attractive because the vispy folks were
>> actively working on improving their opengl code and packaging to make it
>> work on a wide variety of hardware and setups. They had supposedly even
>> implemented a headless opengl mode, too, which was very important for us.
>>
>> Cheers!
>> Ben Root
>>
>>
>> On Thu, Sep 14, 2017 at 9:34 AM, Francesco Faccenda <
>> f.faccenda86 at gmail.com> wrote:
>>
>>> Thank you, Ben.
>>>
>>> unfortunately I don't have experience developing opengl neither, but I'd
>>> like to make an attempt riesuming this subject.
>>>
>>> I am starting from this: https://github.com/ChrisBeaumont/mplgl
>>>
>>> Can anyone confirm this is the last update we have for this project?
>>>
>>> Francesco Faccenda
>>>
>>> 2017-09-13 16:21 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:
>>>
>>>> A bit of background regarding efforts in this area...
>>>>
>>>> A long time ago, some experiments were done to see if an opengl backend
>>>> could be made for matplotlib. The results weren't that great, particularly
>>>> for text rendering, so the effort was dropped. The core developers all
>>>> agree that an opengl backend would be neat to have, but we all have
>>>> limited, if any, experience developing opengl. Furthermore, such a backend
>>>> would likely require a lot of rapid development and trial-n-error. So, we
>>>> encouraged others to go develop a package or two separately, with the eye
>>>> for bringing it back into matplotlib when it was ready. Glumpy and a few
>>>> other projects were born from that prodding.
>>>>
>>>> VisPy was an attempt to consolidate the development efforts for those
>>>> projects. The matplotlib devs had very fruitful discussions with some VisPy
>>>> devs back at SciPy 2015, but the project became non-responsive shortly
>>>> afterwards.
>>>>
>>>> Ben Root
>>>>
>>>>
>>>> On Wed, Sep 13, 2017 at 3:31 AM, Francesco Faccenda <
>>>> f.faccenda86 at gmail.com> wrote:
>>>>
>>>>> Thank you Chris for your reply.
>>>>>
>>>>> I have to admit I already stumbled on VisPy while doing my research on
>>>>> the web. Still, I've got a lot of code already working with
>>>>> *matplotlib*. Indeed, not only I plot data with it, but i manage a
>>>>> lot of *mpl events* to provide the users usefool tools, like lines
>>>>> picking, tooltips, lines copy/paste, square selectors for multiple
>>>>> selections, context menu and so on. Moreover, I got matplotlib *embedded
>>>>> *on *wxpython *as well. While at the beginning few lines were managed
>>>>> and noone complained, now that big amout of data has to be displayed, the
>>>>> non-GPU core of the library is starting to show its limits.
>>>>>
>>>>> Since matplotlib is a reference library for this kind of
>>>>> applications, I thought it deserved an update in this direction. If anyone
>>>>> is willing to do so, I'm available to discuss possible solutions and also
>>>>> provide any help I can give.
>>>>>
>>>>> Best regards,
>>>>> Francesco Faccenda
>>>>>
>>>>> 2017-09-13 0:46 GMT+02:00 Chris Barker <chris.barker at noaa.gov>:
>>>>>
>>>>>> On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda <
>>>>>> f.faccenda86 at gmail.com> wrote:
>>>>>>
>>>>>>> But there?s a good news, I have a nice GPU available (an NVIDIA
>>>>>>> Tesla K40c), so I?d like to know if there is a way to make matplotlib run
>>>>>>> on it, or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.
>>>>>>>
>>>>>>
>>>>>> I tihnk you want VisPy:
>>>>>>
>>>>>> https://vispy.readthedocs.io/en/latest/
>>>>>>
>>>>>> It's a plotting package with a kinda like  matplotlib API, built on
>>>>>> OpenGL.
>>>>>>
>>>>>> Unfortunately, it doesn't look like it's been updated in a while --
>>>>>> from teh docs. But the gitHub project is active:
>>>>>>
>>>>>> https://github.com/vispy/vispy
>>>>>>
>>>>>> So maybe it's only the docs that haven't been updated!
>>>>>>
>>>>>> But probably  a much better option than trying to shoehorn GPU
>>>>>> rendering into MPL.
>>>>>>
>>>>>> The problem is that while MPL was designed to be "backend"
>>>>>> independent -- so it is "easy" to plug in an alternative renderer, the
>>>>>> rendering model is not really well suited to GPU rendering -- it would take
>>>>>> a lot of refactoring to really be able to take advantage of the graphics
>>>>>> card.
>>>>>>
>>>>>> -CHB
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Christopher Barker, Ph.D.
>>>>>> Oceanographer
>>>>>>
>>>>>> Emergency Response Division
>>>>>> NOAA/NOS/OR&R            (206) 526-6959   voice
>>>>>> 7600 Sand Point Way NE
>>>>>> <https://maps.google.com/?q=7600+Sand+Point+Way+NE&entry=gmail&source=g>
>>>>>>   (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/20170914/c372b2f7/attachment-0001.html>

From Nicolas.Rougier at inria.fr  Thu Sep 14 11:03:54 2017
From: Nicolas.Rougier at inria.fr (Nicolas Rougier)
Date: Thu, 14 Sep 2017 17:03:54 +0200
Subject: [Matplotlib-devel] [matplotlib-devel] Make matplotlib running
 on GPU/CUDA
In-Reply-To: <CANNq6FkSb8mttAPs6hoT3wbDczMNn7vdVtYTWHx2R9fPry5VFQ@mail.gmail.com>
References: <CAPp_WOqVavvXJoF255iTmdzZ0E9Dk2QQP3t3P3XkcgNpZz2o+A@mail.gmail.com>
 <CALGmxE+bset2QfPcOfyHMckNH1ko1M3EqWQeadiRS9EU6+g2Lg@mail.gmail.com>
 <CAPp_WOpsGjMJFGc3Q6+TyD3im+StRraPAfMCz+jhehBGd+Byiw@mail.gmail.com>
 <CANNq6Fmmqstwi_BEVvGm37NnnzQ6xwPTAEi=O+dbd+qtiv=3Cg@mail.gmail.com>
 <CAPp_WOpzq78gOKXfFeR7qN-mBE0gauM2odGxqGN3gMkdR=RT4A@mail.gmail.com>
 <CANNq6Fm3kigJZAGjgzKY8PkFuzBH6e_1aa1_tAA6qSfCiKqovQ@mail.gmail.com>
 <CAPp_WOp-x_Py=A1Q+x_i_o8j_NTtQg--qim8_0PxV7fEb7OyVw@mail.gmail.com>
 <CANNq6FkSb8mttAPs6hoT3wbDczMNn7vdVtYTWHx2R9fPry5VFQ@mail.gmail.com>
Message-ID: <DF1C9FAA-2BA6-41CB-83D0-FB61A212C535@inria.fr>


As as matter of fact, I?m currently writing a (open access) book about Python, OpenGL and scientific visualization that explains pretty much everything. I hope to be able to release by the end of the year.

Concerning Vispy, the code might be a bit hard to handle at first but the project is still alive with new contributors. 
Concerning glumpy, I still maintain it and it is less complex than Vispy but it does not offer the high-level interface of vispy. I usually make the comparison numpy/scipy and glumpy/vispy. But the two projects are independent (even if I transferred a lot of code from glumpy to vispy).

For a starter on OpenGL, you can have a look at glumpy documentation: http://glumpy.readthedocs.io/en/latest/

Nicolas



> On 14 Sep 2017, at 16:47, Benjamin Root <ben.v.root at gmail.com> wrote:
> 
> The person who has been most responsive to me in the past would be Nicolas Rougier, who developed glumpy. He might also be able to give you a better sense of where to start.
> 
> Ben Root
> 
> On Thu, Sep 14, 2017 at 10:37 AM, Francesco Faccenda <f.faccenda86 at gmail.com> wrote:
> I'll take a look, thank you.
> 
> So you are suggesting me to start form the VisPy code? Is there someone who I can refer in case I will need some clarification?
> 
> Francesco Faccenda
> 
> 2017-09-14 15:50 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:
> That was one of the old attempts (but not the oldest). It doesn't seem like it ever intersected with the vispy project, though, so it is likely all that exists.
> 
> I would also look at https://www.youtube.com/watch?v=_3YoaeoiIFI
> Luke does a nice job providing an overview of the vispy package. One of the most exciting things that the matplotlib and vispy devs were discussing at scipy 2015 was the possibility of making a matplotlib backend out of some parts from vispy. It was attractive because the vispy folks were actively working on improving their opengl code and packaging to make it work on a wide variety of hardware and setups. They had supposedly even implemented a headless opengl mode, too, which was very important for us.
> 
> Cheers!
> Ben Root
> 
> 
> On Thu, Sep 14, 2017 at 9:34 AM, Francesco Faccenda <f.faccenda86 at gmail.com> wrote:
> Thank you, Ben.
> 
> unfortunately I don't have experience developing opengl neither, but I'd like to make an attempt riesuming this subject.
> 
> I am starting from this: https://github.com/ChrisBeaumont/mplgl
> 
> Can anyone confirm this is the last update we have for this project?
> 
> Francesco Faccenda
> 
> 2017-09-13 16:21 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:
> A bit of background regarding efforts in this area...
> 
> A long time ago, some experiments were done to see if an opengl backend could be made for matplotlib. The results weren't that great, particularly for text rendering, so the effort was dropped. The core developers all agree that an opengl backend would be neat to have, but we all have limited, if any, experience developing opengl. Furthermore, such a backend would likely require a lot of rapid development and trial-n-error. So, we encouraged others to go develop a package or two separately, with the eye for bringing it back into matplotlib when it was ready. Glumpy and a few other projects were born from that prodding.
> 
> VisPy was an attempt to consolidate the development efforts for those projects. The matplotlib devs had very fruitful discussions with some VisPy devs back at SciPy 2015, but the project became non-responsive shortly afterwards.
> 
> Ben Root
> 
> 
> On Wed, Sep 13, 2017 at 3:31 AM, Francesco Faccenda <f.faccenda86 at gmail.com> wrote:
> Thank you Chris for your reply.
> 
> I have to admit I already stumbled on VisPy while doing my research on the web. Still, I've got a lot of code already working with matplotlib. Indeed, not only I plot data with it, but i manage a lot of mpl events to provide the users usefool tools, like lines picking, tooltips, lines copy/paste, square selectors for multiple selections, context menu and so on. Moreover, I got matplotlib embedded on wxpython as well. While at the beginning few lines were managed and noone complained, now that big amout of data has to be displayed, the non-GPU core of the library is starting to show its limits.
> 
> Since matplotlib is a reference library for this kind of  applications, I thought it deserved an update in this direction. If anyone is willing to do so, I'm available to discuss possible solutions and also provide any help I can give.
> 
> Best regards,
> Francesco Faccenda
> 
> 2017-09-13 0:46 GMT+02:00 Chris Barker <chris.barker at noaa.gov>:
> On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda <f.faccenda86 at gmail.com> wrote:
> But there?s a good news, I have a nice GPU available (an NVIDIA Tesla K40c), so I?d like to know if there is a way to make matplotlib run on it, or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.
> 
> 
> I tihnk you want VisPy:
> 
> https://vispy.readthedocs.io/en/latest/
> 
> It's a plotting package with a kinda like  matplotlib API, built on OpenGL.
> 
> Unfortunately, it doesn't look like it's been updated in a while -- from teh docs. But the gitHub project is active:
> 
> https://github.com/vispy/vispy
> 
> So maybe it's only the docs that haven't been updated!
> 
> But probably  a much better option than trying to shoehorn GPU rendering into MPL.
> 
> The problem is that while MPL was designed to be "backend" independent -- so it is "easy" to plug in an alternative renderer, the rendering model is not really well suited to GPU rendering -- it would take a lot of refactoring to really be able to take advantage of the graphics card.
> 
> -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
> 
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel


From antony.lee at berkeley.edu  Thu Sep 14 16:25:34 2017
From: antony.lee at berkeley.edu (Antony Lee)
Date: Thu, 14 Sep 2017 13:25:34 -0700
Subject: [Matplotlib-devel] [matplotlib-devel] Make matplotlib running
 on GPU/CUDA
In-Reply-To: <DF1C9FAA-2BA6-41CB-83D0-FB61A212C535@inria.fr>
References: <CAPp_WOqVavvXJoF255iTmdzZ0E9Dk2QQP3t3P3XkcgNpZz2o+A@mail.gmail.com>
 <CALGmxE+bset2QfPcOfyHMckNH1ko1M3EqWQeadiRS9EU6+g2Lg@mail.gmail.com>
 <CAPp_WOpsGjMJFGc3Q6+TyD3im+StRraPAfMCz+jhehBGd+Byiw@mail.gmail.com>
 <CANNq6Fmmqstwi_BEVvGm37NnnzQ6xwPTAEi=O+dbd+qtiv=3Cg@mail.gmail.com>
 <CAPp_WOpzq78gOKXfFeR7qN-mBE0gauM2odGxqGN3gMkdR=RT4A@mail.gmail.com>
 <CANNq6Fm3kigJZAGjgzKY8PkFuzBH6e_1aa1_tAA6qSfCiKqovQ@mail.gmail.com>
 <CAPp_WOp-x_Py=A1Q+x_i_o8j_NTtQg--qim8_0PxV7fEb7OyVw@mail.gmail.com>
 <CANNq6FkSb8mttAPs6hoT3wbDczMNn7vdVtYTWHx2R9fPry5VFQ@mail.gmail.com>
 <DF1C9FAA-2BA6-41CB-83D0-FB61A212C535@inria.fr>
Message-ID: <CAGRr6BH_u_Zg=ikcSvtM16Hg=UmhZ0E6x1qJugqKy4Wj8OKWSg@mail.gmail.com>

One possibility for which I'd certainly appreciate some help is to see
whether we can use cairo's gl backend (which is sadly quite
underdocumented) in https://github.com/anntzer/mpl_cairo -- which can
currently use cairo's raster ("image") and X11 backends, with pretty good
performance (much better than the builtin gtk3cairo, and generally better
than the builtin Agg backends).
Antony

2017-09-14 8:03 GMT-07:00 Nicolas Rougier <Nicolas.Rougier at inria.fr>:

>
> As as matter of fact, I?m currently writing a (open access) book about
> Python, OpenGL and scientific visualization that explains pretty much
> everything. I hope to be able to release by the end of the year.
>
> Concerning Vispy, the code might be a bit hard to handle at first but the
> project is still alive with new contributors.
> Concerning glumpy, I still maintain it and it is less complex than Vispy
> but it does not offer the high-level interface of vispy. I usually make the
> comparison numpy/scipy and glumpy/vispy. But the two projects are
> independent (even if I transferred a lot of code from glumpy to vispy).
>
> For a starter on OpenGL, you can have a look at glumpy documentation:
> http://glumpy.readthedocs.io/en/latest/
>
> Nicolas
>
>
>
> > On 14 Sep 2017, at 16:47, Benjamin Root <ben.v.root at gmail.com> wrote:
> >
> > The person who has been most responsive to me in the past would be
> Nicolas Rougier, who developed glumpy. He might also be able to give you a
> better sense of where to start.
> >
> > Ben Root
> >
> > On Thu, Sep 14, 2017 at 10:37 AM, Francesco Faccenda <
> f.faccenda86 at gmail.com> wrote:
> > I'll take a look, thank you.
> >
> > So you are suggesting me to start form the VisPy code? Is there someone
> who I can refer in case I will need some clarification?
> >
> > Francesco Faccenda
> >
> > 2017-09-14 15:50 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:
> > That was one of the old attempts (but not the oldest). It doesn't seem
> like it ever intersected with the vispy project, though, so it is likely
> all that exists.
> >
> > I would also look at https://www.youtube.com/watch?v=_3YoaeoiIFI
> > Luke does a nice job providing an overview of the vispy package. One of
> the most exciting things that the matplotlib and vispy devs were discussing
> at scipy 2015 was the possibility of making a matplotlib backend out of
> some parts from vispy. It was attractive because the vispy folks were
> actively working on improving their opengl code and packaging to make it
> work on a wide variety of hardware and setups. They had supposedly even
> implemented a headless opengl mode, too, which was very important for us.
> >
> > Cheers!
> > Ben Root
> >
> >
> > On Thu, Sep 14, 2017 at 9:34 AM, Francesco Faccenda <
> f.faccenda86 at gmail.com> wrote:
> > Thank you, Ben.
> >
> > unfortunately I don't have experience developing opengl neither, but I'd
> like to make an attempt riesuming this subject.
> >
> > I am starting from this: https://github.com/ChrisBeaumont/mplgl
> >
> > Can anyone confirm this is the last update we have for this project?
> >
> > Francesco Faccenda
> >
> > 2017-09-13 16:21 GMT+02:00 Benjamin Root <ben.v.root at gmail.com>:
> > A bit of background regarding efforts in this area...
> >
> > A long time ago, some experiments were done to see if an opengl backend
> could be made for matplotlib. The results weren't that great, particularly
> for text rendering, so the effort was dropped. The core developers all
> agree that an opengl backend would be neat to have, but we all have
> limited, if any, experience developing opengl. Furthermore, such a backend
> would likely require a lot of rapid development and trial-n-error. So, we
> encouraged others to go develop a package or two separately, with the eye
> for bringing it back into matplotlib when it was ready. Glumpy and a few
> other projects were born from that prodding.
> >
> > VisPy was an attempt to consolidate the development efforts for those
> projects. The matplotlib devs had very fruitful discussions with some VisPy
> devs back at SciPy 2015, but the project became non-responsive shortly
> afterwards.
> >
> > Ben Root
> >
> >
> > On Wed, Sep 13, 2017 at 3:31 AM, Francesco Faccenda <
> f.faccenda86 at gmail.com> wrote:
> > Thank you Chris for your reply.
> >
> > I have to admit I already stumbled on VisPy while doing my research on
> the web. Still, I've got a lot of code already working with matplotlib.
> Indeed, not only I plot data with it, but i manage a lot of mpl events to
> provide the users usefool tools, like lines picking, tooltips, lines
> copy/paste, square selectors for multiple selections, context menu and so
> on. Moreover, I got matplotlib embedded on wxpython as well. While at the
> beginning few lines were managed and noone complained, now that big amout
> of data has to be displayed, the non-GPU core of the library is starting to
> show its limits.
> >
> > Since matplotlib is a reference library for this kind of  applications,
> I thought it deserved an update in this direction. If anyone is willing to
> do so, I'm available to discuss possible solutions and also provide any
> help I can give.
> >
> > Best regards,
> > Francesco Faccenda
> >
> > 2017-09-13 0:46 GMT+02:00 Chris Barker <chris.barker at noaa.gov>:
> > On Tue, Sep 12, 2017 at 8:47 AM, Francesco Faccenda <
> f.faccenda86 at gmail.com> wrote:
> > But there?s a good news, I have a nice GPU available (an NVIDIA Tesla
> K40c), so I?d like to know if there is a way to make matplotlib run on it,
> or maybe wrap it on some GPU/CUDA wrapper and make it run smoothly.
> >
> >
> > I tihnk you want VisPy:
> >
> > https://vispy.readthedocs.io/en/latest/
> >
> > It's a plotting package with a kinda like  matplotlib API, built on
> OpenGL.
> >
> > Unfortunately, it doesn't look like it's been updated in a while -- from
> teh docs. But the gitHub project is active:
> >
> > https://github.com/vispy/vispy
> >
> > So maybe it's only the docs that haven't been updated!
> >
> > But probably  a much better option than trying to shoehorn GPU rendering
> into MPL.
> >
> > The problem is that while MPL was designed to be "backend" independent
> -- so it is "easy" to plug in an alternative renderer, the rendering model
> is not really well suited to GPU rendering -- it would take a lot of
> refactoring to really be able to take advantage of the graphics card.
> >
> > -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
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Matplotlib-devel at python.org
> > https://mail.python.org/mailman/listinfo/matplotlib-devel
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Matplotlib-devel at python.org
> > https://mail.python.org/mailman/listinfo/matplotlib-devel
>
> _______________________________________________
> 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/20170914/6ba397d6/attachment.html>

From anntzer.lee at gmail.com  Sat Sep 16 05:10:31 2017
From: anntzer.lee at gmail.com (Antony Lee)
Date: Sat, 16 Sep 2017 02:10:31 -0700
Subject: [Matplotlib-devel] mpl_cairo manylinux wheel available
Message-ID: <CAGRr6BHOXXXJ=94N=KJ5NkxYAOA6scgO0RbYyMBX2coiQ+fC2w@mail.gmail.com>

Hi all,
A manylinux wheel for mpl_cairo (https://github.com/anntzer/mpl_cairo) is
now available (under GitHub releases).  mpl_cairo is a new, cairo-based
backend for Matplotlib, that offers several improvements over the current
default, Agg-based backend.  See the README on GitHub for more details :-)
I would be interested in hearing your feedback.
Antony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170916/75cfabb8/attachment.html>

From matthew.brett at gmail.com  Sat Sep 16 05:43:48 2017
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sat, 16 Sep 2017 10:43:48 +0100
Subject: [Matplotlib-devel] mpl_cairo manylinux wheel available
In-Reply-To: <CAGRr6BHOXXXJ=94N=KJ5NkxYAOA6scgO0RbYyMBX2coiQ+fC2w@mail.gmail.com>
References: <CAGRr6BHOXXXJ=94N=KJ5NkxYAOA6scgO0RbYyMBX2coiQ+fC2w@mail.gmail.com>
Message-ID: <CAH6Pt5qnCAnmpos5Gc+CVjkuaxvpR46iEdW6kPrc=ZaC+gRv8w@mail.gmail.com>

On Sat, Sep 16, 2017 at 10:10 AM, Antony Lee <anntzer.lee at gmail.com> wrote:
> Hi all,
> A manylinux wheel for mpl_cairo (https://github.com/anntzer/mpl_cairo) is
> now available (under GitHub releases).  mpl_cairo is a new, cairo-based
> backend for Matplotlib, that offers several improvements over the current
> default, Agg-based backend.  See the README on GitHub for more details :-)
> I would be interested in hearing your feedback.

Nice!  Any plans for an OSX build?  Or are they hard?

Cheers,

Matthew

From anntzer.lee at gmail.com  Sat Sep 16 12:12:05 2017
From: anntzer.lee at gmail.com (Antony Lee)
Date: Sat, 16 Sep 2017 09:12:05 -0700
Subject: [Matplotlib-devel] mpl_cairo manylinux wheel available
In-Reply-To: <CAH6Pt5qnCAnmpos5Gc+CVjkuaxvpR46iEdW6kPrc=ZaC+gRv8w@mail.gmail.com>
References: <CAGRr6BHOXXXJ=94N=KJ5NkxYAOA6scgO0RbYyMBX2coiQ+fC2w@mail.gmail.com>
 <CAH6Pt5qnCAnmpos5Gc+CVjkuaxvpR46iEdW6kPrc=ZaC+gRv8w@mail.gmail.com>
Message-ID: <CAGRr6BEpBKLC1VW0ZBUDDOLS8zz3YQ4SOcN_V==T+t8J+_Drcg@mail.gmail.com>

I don't think that would be particularly hard (there isn't anything really
specific to Linux in the code, AFAICT), but I don't have access to an OSX
machine with a C++ compiler capable of compiling C++17.  <wink>
Antony

2017-09-16 2:43 GMT-07:00 Matthew Brett <matthew.brett at gmail.com>:

> On Sat, Sep 16, 2017 at 10:10 AM, Antony Lee <anntzer.lee at gmail.com>
> wrote:
> > Hi all,
> > A manylinux wheel for mpl_cairo (https://github.com/anntzer/mpl_cairo)
> is
> > now available (under GitHub releases).  mpl_cairo is a new, cairo-based
> > backend for Matplotlib, that offers several improvements over the current
> > default, Agg-based backend.  See the README on GitHub for more details
> :-)
> > I would be interested in hearing your feedback.
>
> Nice!  Any plans for an OSX build?  Or are they hard?
>
> Cheers,
>
> Matthew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170916/df837965/attachment.html>

From ndbecker2 at gmail.com  Sun Sep 17 11:26:31 2017
From: ndbecker2 at gmail.com (Neal Becker)
Date: Sun, 17 Sep 2017 11:26:31 -0400
Subject: [Matplotlib-devel] mpl_cairo manylinux wheel available
References: <CAGRr6BHOXXXJ=94N=KJ5NkxYAOA6scgO0RbYyMBX2coiQ+fC2w@mail.gmail.com>
 <CAH6Pt5qnCAnmpos5Gc+CVjkuaxvpR46iEdW6kPrc=ZaC+gRv8w@mail.gmail.com>
Message-ID: <opm46v$b0l$1@blaine.gmane.org>

Matthew Brett wrote:

> On Sat, Sep 16, 2017 at 10:10 AM, Antony Lee
> <anntzer.lee at gmail.com> wrote:
>> Hi all,
>> A manylinux wheel for mpl_cairo (https://github.com/anntzer/mpl_cairo) is
>> now available (under GitHub releases).  mpl_cairo is a new, cairo-based
>> backend for Matplotlib, that offers several improvements over the current
>> default, Agg-based backend.  See the README on GitHub for more details
>> :-) I would be interested in hearing your feedback.
> 
> Nice!  Any plans for an OSX build?  Or are they hard?
> 
> Cheers,
> 
> Matthew
I'm interested in trying this on Fedora linux - but I don't want to use 
anaconda.  Any suggestions?


From antony.lee at berkeley.edu  Sun Sep 17 16:20:02 2017
From: antony.lee at berkeley.edu (Antony Lee)
Date: Sun, 17 Sep 2017 13:20:02 -0700
Subject: [Matplotlib-devel] mpl_cairo manylinux wheel available
In-Reply-To: <opm46v$b0l$1@blaine.gmane.org>
References: <CAGRr6BHOXXXJ=94N=KJ5NkxYAOA6scgO0RbYyMBX2coiQ+fC2w@mail.gmail.com>
 <CAH6Pt5qnCAnmpos5Gc+CVjkuaxvpR46iEdW6kPrc=ZaC+gRv8w@mail.gmail.com>
 <opm46v$b0l$1@blaine.gmane.org>
Message-ID: <CAGRr6BGRjz+a62mAx47SSeqwNH0-mUJ5W3t0DD=34u8zic0r4w@mail.gmail.com>

Yes, you can use this without conda (I usually don't use conda, it's just
an easy way for me to make sure people can install pycairo...).

There are two possibilites: compile the package yourself, or use the wheel
available under github releases.  In either case you need to install
Matplotlib with PR#8771 (so I'd suggest doing this in a venv); there are
(fairly standard) instructions for this in the README or in Matplotlib's
devdocs.  Assuming that you have installed the patched Matplotlib, you can
now do one of the following:

1. Compile the package yourself

According to pkgs.org,
  - g++ 7.1 is available in Fedora 26.
  - pycairo>=1.12 ("python3-cairo") is only available in Fedora Rawhide
(Fedora 26 has pycairo 1.10).

If you can install these dependencies, you should be able to just do the
standard `pip install .` or `pip install -e .` (in the same environment as
the patched Matplotlib) and you're good to go.

If you're stuck on Fedora 26, it looks like that version has cairo 1.14
(which is what we *really* care about).  So you should be able to get away
with installing the latest pycairo and cairo (1.14), and manually removing
the dependency on pycairo>=1.12 in mpl_cairo's setup.py.

2. Use the compiled wheel.

Basically everything under the "Installation (Linux only)" example still
applies -- just replace the invocation of conda with your dnf (and the
appropriate package names).  However in that case you will not be able to
edit the dependency in the wheel (which, again, requires pycairo>=1.12).
Let me know if this is the case, if so then I will build a wheel with a
lower dependency bound.

Antony

2017-09-17 8:26 GMT-07:00 Neal Becker <ndbecker2 at gmail.com>:

> Matthew Brett wrote:
>
> > On Sat, Sep 16, 2017 at 10:10 AM, Antony Lee
> > <anntzer.lee at gmail.com> wrote:
> >> Hi all,
> >> A manylinux wheel for mpl_cairo (https://github.com/anntzer/mpl_cairo)
> is
> >> now available (under GitHub releases).  mpl_cairo is a new, cairo-based
> >> backend for Matplotlib, that offers several improvements over the
> current
> >> default, Agg-based backend.  See the README on GitHub for more details
> >> :-) I would be interested in hearing your feedback.
> >
> > Nice!  Any plans for an OSX build?  Or are they hard?
> >
> > Cheers,
> >
> > Matthew
> I'm interested in trying this on Fedora linux - but I don't want to use
> anaconda.  Any suggestions?
>
> _______________________________________________
> 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/20170917/9011db0a/attachment.html>

From antony.lee at berkeley.edu  Sun Sep 17 16:35:59 2017
From: antony.lee at berkeley.edu (Antony Lee)
Date: Sun, 17 Sep 2017 13:35:59 -0700
Subject: [Matplotlib-devel] mpl_cairo manylinux wheel available
In-Reply-To: <CAGRr6BGRjz+a62mAx47SSeqwNH0-mUJ5W3t0DD=34u8zic0r4w@mail.gmail.com>
References: <CAGRr6BHOXXXJ=94N=KJ5NkxYAOA6scgO0RbYyMBX2coiQ+fC2w@mail.gmail.com>
 <CAH6Pt5qnCAnmpos5Gc+CVjkuaxvpR46iEdW6kPrc=ZaC+gRv8w@mail.gmail.com>
 <opm46v$b0l$1@blaine.gmane.org>
 <CAGRr6BGRjz+a62mAx47SSeqwNH0-mUJ5W3t0DD=34u8zic0r4w@mail.gmail.com>
Message-ID: <CAGRr6BEUCy12EuxNoJLKb0MqDy96mh=gbz3PP6GfrTdzdHQ4hQ@mail.gmail.com>

(or actually, in the last case, you can just install with pip install
--no-deps, which will also bypass the version check).
Antony

2017-09-17 13:20 GMT-07:00 Antony Lee <antony.lee at berkeley.edu>:

> Yes, you can use this without conda (I usually don't use conda, it's just
> an easy way for me to make sure people can install pycairo...).
>
> There are two possibilites: compile the package yourself, or use the wheel
> available under github releases.  In either case you need to install
> Matplotlib with PR#8771 (so I'd suggest doing this in a venv); there are
> (fairly standard) instructions for this in the README or in Matplotlib's
> devdocs.  Assuming that you have installed the patched Matplotlib, you can
> now do one of the following:
>
> 1. Compile the package yourself
>
> According to pkgs.org,
>   - g++ 7.1 is available in Fedora 26.
>   - pycairo>=1.12 ("python3-cairo") is only available in Fedora Rawhide
> (Fedora 26 has pycairo 1.10).
>
> If you can install these dependencies, you should be able to just do the
> standard `pip install .` or `pip install -e .` (in the same environment as
> the patched Matplotlib) and you're good to go.
>
> If you're stuck on Fedora 26, it looks like that version has cairo 1.14
> (which is what we *really* care about).  So you should be able to get away
> with installing the latest pycairo and cairo (1.14), and manually removing
> the dependency on pycairo>=1.12 in mpl_cairo's setup.py.
>
> 2. Use the compiled wheel.
>
> Basically everything under the "Installation (Linux only)" example still
> applies -- just replace the invocation of conda with your dnf (and the
> appropriate package names).  However in that case you will not be able to
> edit the dependency in the wheel (which, again, requires pycairo>=1.12).
> Let me know if this is the case, if so then I will build a wheel with a
> lower dependency bound.
>
> Antony
>
> 2017-09-17 8:26 GMT-07:00 Neal Becker <ndbecker2 at gmail.com>:
>
>> Matthew Brett wrote:
>>
>> > On Sat, Sep 16, 2017 at 10:10 AM, Antony Lee
>> > <anntzer.lee at gmail.com> wrote:
>> >> Hi all,
>> >> A manylinux wheel for mpl_cairo (https://github.com/anntzer/mpl_cairo)
>> is
>> >> now available (under GitHub releases).  mpl_cairo is a new, cairo-based
>> >> backend for Matplotlib, that offers several improvements over the
>> current
>> >> default, Agg-based backend.  See the README on GitHub for more details
>> >> :-) I would be interested in hearing your feedback.
>> >
>> > Nice!  Any plans for an OSX build?  Or are they hard?
>> >
>> > Cheers,
>> >
>> > Matthew
>> I'm interested in trying this on Fedora linux - but I don't want to use
>> anaconda.  Any suggestions?
>>
>> _______________________________________________
>> 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/20170917/1dc0deae/attachment.html>

From f.faccenda86 at gmail.com  Mon Sep 18 05:06:59 2017
From: f.faccenda86 at gmail.com (Francesco Faccenda)
Date: Mon, 18 Sep 2017 11:06:59 +0200
Subject: [Matplotlib-devel] mpl_cairo manylinux wheel available
In-Reply-To: <CAGRr6BHOXXXJ=94N=KJ5NkxYAOA6scgO0RbYyMBX2coiQ+fC2w@mail.gmail.com>
References: <CAGRr6BHOXXXJ=94N=KJ5NkxYAOA6scgO0RbYyMBX2coiQ+fC2w@mail.gmail.com>
Message-ID: <CAPp_WOocoK_pCVKD5drOuk+8VOigAPOxrLsfyUKiFHs0buAGyQ@mail.gmail.com>

This is a good news, thank you. I have two main doubts now:

   1. Would it be hard to have a Windows version of it? Since I am quite
   new to this, I'm not sure how to do it myself. Is there a good tutorial you
   would suggest?
   2. Would it work with matplotlib embedded on a wxpython stage or I'm
   going to run in some issue if I use this backend?


Regards,
Francesco Faccenda


2017-09-16 11:10 GMT+02:00 Antony Lee <anntzer.lee at gmail.com>:

> Hi all,
> A manylinux wheel for mpl_cairo (https://github.com/anntzer/mpl_cairo) is
> now available (under GitHub releases).  mpl_cairo is a new, cairo-based
> backend for Matplotlib, that offers several improvements over the current
> default, Agg-based backend.  See the README on GitHub for more details :-)
> I would be interested in hearing your feedback.
> Antony
>
> _______________________________________________
> 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/20170918/2bbd1b82/attachment-0001.html>

From anntzer.lee at gmail.com  Mon Sep 18 11:46:21 2017
From: anntzer.lee at gmail.com (Antony Lee)
Date: Mon, 18 Sep 2017 08:46:21 -0700
Subject: [Matplotlib-devel] mpl_cairo manylinux wheel available
In-Reply-To: <CAPp_WOocoK_pCVKD5drOuk+8VOigAPOxrLsfyUKiFHs0buAGyQ@mail.gmail.com>
References: <CAGRr6BHOXXXJ=94N=KJ5NkxYAOA6scgO0RbYyMBX2coiQ+fC2w@mail.gmail.com>
 <CAPp_WOocoK_pCVKD5drOuk+8VOigAPOxrLsfyUKiFHs0buAGyQ@mail.gmail.com>
Message-ID: <CAGRr6BEV0tsYmqmRo6cBYxBYdE4FG6VdNW3TTJeiFvrzx0t+=Q@mail.gmail.com>

Hi,

I looked into compiling on Windows yesterday and it appears that MSVC does
not support yet all the required C++17 features (at least, guaranteed copy
elision and template argument deduction for class templates -- see
https://blogs.msdn.microsoft.com/vcblog/2017/08/11/c17-features-and-stl-fixes-in-vs-2017-15-3/).
>From some quick googling, it is apparently expected that full support will
happen "soon" (before the end of 2017) so I may decide to just wait for it
rather than downgrade the code (depending on how much time I want to spend
on this...) but as a consequence, tinkering with mplcairo on Windows would
right now require not only good familiarity with how to compile extension
modules on Windows, but also with C++ to understand how to downgrade the
code, so overall it may be quite tricky for you.

Wx support would require refactoring the wx backend code so that the
rendering part gets strictly decoupled from the windowing part -- this is
e.g. the purpose of PR#8771 that does the same for Qt.  Actually, given
that Wx already supports both "native" Wx rendering and Agg rendering, I
expect this to be "relatively" easy, as the separation already mostly
exists (basically we need to replace mentions of Agg by cairo in
backend_wxagg.py).  As always, PRs would be welcome.

Antony

2017-09-18 2:06 GMT-07:00 Francesco Faccenda <f.faccenda86 at gmail.com>:

> This is a good news, thank you. I have two main doubts now:
>
>    1. Would it be hard to have a Windows version of it? Since I am quite
>    new to this, I'm not sure how to do it myself. Is there a good tutorial you
>    would suggest?
>    2. Would it work with matplotlib embedded on a wxpython stage or I'm
>    going to run in some issue if I use this backend?
>
>
> Regards,
> Francesco Faccenda
>
>
> 2017-09-16 11:10 GMT+02:00 Antony Lee <anntzer.lee at gmail.com>:
>
>> Hi all,
>> A manylinux wheel for mpl_cairo (https://github.com/anntzer/mpl_cairo)
>> is now available (under GitHub releases).  mpl_cairo is a new, cairo-based
>> backend for Matplotlib, that offers several improvements over the current
>> default, Agg-based backend.  See the README on GitHub for more details :-)
>> I would be interested in hearing your feedback.
>> Antony
>>
>> _______________________________________________
>> 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/20170918/93d8b6c1/attachment.html>

From anntzer.lee at gmail.com  Tue Sep 19 00:26:55 2017
From: anntzer.lee at gmail.com (Antony Lee)
Date: Mon, 18 Sep 2017 21:26:55 -0700
Subject: [Matplotlib-devel] mpl_cairo manylinux wheel available
In-Reply-To: <CAGRr6BEV0tsYmqmRo6cBYxBYdE4FG6VdNW3TTJeiFvrzx0t+=Q@mail.gmail.com>
References: <CAGRr6BHOXXXJ=94N=KJ5NkxYAOA6scgO0RbYyMBX2coiQ+fC2w@mail.gmail.com>
 <CAPp_WOocoK_pCVKD5drOuk+8VOigAPOxrLsfyUKiFHs0buAGyQ@mail.gmail.com>
 <CAGRr6BEV0tsYmqmRo6cBYxBYdE4FG6VdNW3TTJeiFvrzx0t+=Q@mail.gmail.com>
Message-ID: <CAGRr6BFEXELPY6wZ9cu2jQyeeCjaGidOhZCY+FKdh0_coAmJVQ@mail.gmail.com>

{ https://github.com/matplotlib/matplotlib/pull/9202 + mplcairo master }
now implement a wx-cairo backend.
Antony

2017-09-18 8:46 GMT-07:00 Antony Lee <anntzer.lee at gmail.com>:

> Hi,
>
> I looked into compiling on Windows yesterday and it appears that MSVC does
> not support yet all the required C++17 features (at least, guaranteed copy
> elision and template argument deduction for class templates -- see
> https://blogs.msdn.microsoft.com/vcblog/2017/08/11/c17-
> features-and-stl-fixes-in-vs-2017-15-3/).  From some quick googling, it
> is apparently expected that full support will happen "soon" (before the end
> of 2017) so I may decide to just wait for it rather than downgrade the code
> (depending on how much time I want to spend on this...) but as a
> consequence, tinkering with mplcairo on Windows would right now require not
> only good familiarity with how to compile extension modules on Windows, but
> also with C++ to understand how to downgrade the code, so overall it may be
> quite tricky for you.
>
> Wx support would require refactoring the wx backend code so that the
> rendering part gets strictly decoupled from the windowing part -- this is
> e.g. the purpose of PR#8771 that does the same for Qt.  Actually, given
> that Wx already supports both "native" Wx rendering and Agg rendering, I
> expect this to be "relatively" easy, as the separation already mostly
> exists (basically we need to replace mentions of Agg by cairo in
> backend_wxagg.py).  As always, PRs would be welcome.
>
> Antony
>
> 2017-09-18 2:06 GMT-07:00 Francesco Faccenda <f.faccenda86 at gmail.com>:
>
>> This is a good news, thank you. I have two main doubts now:
>>
>>    1. Would it be hard to have a Windows version of it? Since I am quite
>>    new to this, I'm not sure how to do it myself. Is there a good tutorial you
>>    would suggest?
>>    2. Would it work with matplotlib embedded on a wxpython stage or I'm
>>    going to run in some issue if I use this backend?
>>
>>
>> Regards,
>> Francesco Faccenda
>>
>>
>> 2017-09-16 11:10 GMT+02:00 Antony Lee <anntzer.lee at gmail.com>:
>>
>>> Hi all,
>>> A manylinux wheel for mpl_cairo (https://github.com/anntzer/mpl_cairo)
>>> is now available (under GitHub releases).  mpl_cairo is a new, cairo-based
>>> backend for Matplotlib, that offers several improvements over the current
>>> default, Agg-based backend.  See the README on GitHub for more details :-)
>>> I would be interested in hearing your feedback.
>>> Antony
>>>
>>> _______________________________________________
>>> 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/20170918/7d58dc9d/attachment.html>

From f.faccenda86 at gmail.com  Tue Sep 19 04:08:51 2017
From: f.faccenda86 at gmail.com (Francesco Faccenda)
Date: Tue, 19 Sep 2017 10:08:51 +0200
Subject: [Matplotlib-devel] mpl_cairo manylinux wheel available
In-Reply-To: <CAGRr6BFEXELPY6wZ9cu2jQyeeCjaGidOhZCY+FKdh0_coAmJVQ@mail.gmail.com>
References: <CAGRr6BHOXXXJ=94N=KJ5NkxYAOA6scgO0RbYyMBX2coiQ+fC2w@mail.gmail.com>
 <CAPp_WOocoK_pCVKD5drOuk+8VOigAPOxrLsfyUKiFHs0buAGyQ@mail.gmail.com>
 <CAGRr6BEV0tsYmqmRo6cBYxBYdE4FG6VdNW3TTJeiFvrzx0t+=Q@mail.gmail.com>
 <CAGRr6BFEXELPY6wZ9cu2jQyeeCjaGidOhZCY+FKdh0_coAmJVQ@mail.gmail.com>
Message-ID: <CAPp_WOodp6ExskVevZW1YJcFAExN5GHdgKqX39v1r5hr5CXqEQ@mail.gmail.com>

Thank you Antony for your effort and for such good news. I'm looking
forward to the MSVC full support. In the meanwhile I'll take a look on the
wx-cairo implementation.
Please, let us know any update about this subject, it would be very
appreciable.

Best regards,
Francesco Faccenda

2017-09-19 6:26 GMT+02:00 Antony Lee <anntzer.lee at gmail.com>:

> { https://github.com/matplotlib/matplotlib/pull/9202 + mplcairo master }
> now implement a wx-cairo backend.
> Antony
>
> 2017-09-18 8:46 GMT-07:00 Antony Lee <anntzer.lee at gmail.com>:
>
>> Hi,
>>
>> I looked into compiling on Windows yesterday and it appears that MSVC
>> does not support yet all the required C++17 features (at least, guaranteed
>> copy elision and template argument deduction for class templates -- see
>> https://blogs.msdn.microsoft.com/vcblog/2017/08/11/c17-featu
>> res-and-stl-fixes-in-vs-2017-15-3/).  From some quick googling, it is
>> apparently expected that full support will happen "soon" (before the end of
>> 2017) so I may decide to just wait for it rather than downgrade the code
>> (depending on how much time I want to spend on this...) but as a
>> consequence, tinkering with mplcairo on Windows would right now require not
>> only good familiarity with how to compile extension modules on Windows, but
>> also with C++ to understand how to downgrade the code, so overall it may be
>> quite tricky for you.
>>
>> Wx support would require refactoring the wx backend code so that the
>> rendering part gets strictly decoupled from the windowing part -- this is
>> e.g. the purpose of PR#8771 that does the same for Qt.  Actually, given
>> that Wx already supports both "native" Wx rendering and Agg rendering, I
>> expect this to be "relatively" easy, as the separation already mostly
>> exists (basically we need to replace mentions of Agg by cairo in
>> backend_wxagg.py).  As always, PRs would be welcome.
>>
>> Antony
>>
>> 2017-09-18 2:06 GMT-07:00 Francesco Faccenda <f.faccenda86 at gmail.com>:
>>
>>> This is a good news, thank you. I have two main doubts now:
>>>
>>>    1. Would it be hard to have a Windows version of it? Since I am
>>>    quite new to this, I'm not sure how to do it myself. Is there a good
>>>    tutorial you would suggest?
>>>    2. Would it work with matplotlib embedded on a wxpython stage or I'm
>>>    going to run in some issue if I use this backend?
>>>
>>>
>>> Regards,
>>> Francesco Faccenda
>>>
>>>
>>> 2017-09-16 11:10 GMT+02:00 Antony Lee <anntzer.lee at gmail.com>:
>>>
>>>> Hi all,
>>>> A manylinux wheel for mpl_cairo (https://github.com/anntzer/mpl_cairo)
>>>> is now available (under GitHub releases).  mpl_cairo is a new, cairo-based
>>>> backend for Matplotlib, that offers several improvements over the current
>>>> default, Agg-based backend.  See the README on GitHub for more details :-)
>>>> I would be interested in hearing your feedback.
>>>> Antony
>>>>
>>>> _______________________________________________
>>>> 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/20170919/fdb26a48/attachment.html>

From chris.barker at noaa.gov  Thu Sep 21 17:13:17 2017
From: chris.barker at noaa.gov (Chris Barker)
Date: Thu, 21 Sep 2017 14:13:17 -0700
Subject: [Matplotlib-devel] [matplotlib-devel] Make matplotlib running
 on GPU/CUDA
In-Reply-To: <CAPp_WOpsGjMJFGc3Q6+TyD3im+StRraPAfMCz+jhehBGd+Byiw@mail.gmail.com>
References: <CAPp_WOqVavvXJoF255iTmdzZ0E9Dk2QQP3t3P3XkcgNpZz2o+A@mail.gmail.com>
 <CALGmxE+bset2QfPcOfyHMckNH1ko1M3EqWQeadiRS9EU6+g2Lg@mail.gmail.com>
 <CAPp_WOpsGjMJFGc3Q6+TyD3im+StRraPAfMCz+jhehBGd+Byiw@mail.gmail.com>
Message-ID: <CALGmxEK6myDg7-X+GJkwrDTVpHhUpkijj+LB=pn-bGQcWn_G=g@mail.gmail.com>

On Wed, Sep 13, 2017 at 12:31 AM, Francesco Faccenda <f.faccenda86 at gmail.com
> wrote:

> I have to admit I already stumbled on VisPy while doing my research on the
> web. Still, I've got a lot of code already working with *matplotlib*.
> Indeed, not only I plot data with it, but i manage a lot of *mpl events*
> to provide the users usefool tools, like lines picking, tooltips, lines
> copy/paste, square selectors for multiple selections, context menu and so
> on. Moreover, I got matplotlib *embedded *on *wxpython *as well. While at
> the beginning few lines were managed and noone complained, now that big
> amout of data has to be displayed, the non-GPU core of the library is
> starting to show its limits.
>
> Since matplotlib is a reference library for this kind of  applications, I
> thought it deserved an update in this direction.
>

Well, As I understand it, VisPY made some effort to be compatible with the
MPL API -- but that is going to depend on how much you use the lower-level
parts f the API -- things like the transform, etc. to take advantage of GPU
rendering, all the transforms, etc needs to be pushed to the GPU, so the
architecture (and API) needs to be quite different.


> If anyone is willing to do so, I'm available to discuss possible solutions
> and also provide any help I can give.
>

As Ben pointed out, and I was trying to make clear -- it really isn't a
matter of "just" writing an OpenGL backend -- there really needs to be a
major restructuring.

And VisPy is pretty much that project. Whether it is feature complete,
robust and maintained enough for your use-cases, I have no idea, but even
if not -- you'll probably be better off contributing to that effort than
starting all over with trying to make an GPU_based OPenGL back-end.

However -- maybe there is another option:

Taking full advantage of GPUs does require a full restructuring, but maybe
there are other ways to get better performance -- for instance, optimizing
the transform code, etc:

Using the GPU with PyCuda or [what the heck is the name of the more general
GPU-using lib??]

using numba

Maybe there is still room for Cython, etc....

In short, profiling MPL carefully, to see where the performance bottlenecks
are:

With modern hardware, actually rendering stuff is no longer the slow part
of visualization. Rather, it's pushing data to the renderer, transforming
data etc.

This is why to take advantage of the GPU, you need to do the
transformations, etc on the GPU -- which the MPL architecture doesn't make
easy by dropping in a new back-end.

Which is why VisPy built a new architecture from the bottom up.

-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/20170921/157481ca/attachment.html>

From chris.barker at noaa.gov  Thu Sep 21 17:18:45 2017
From: chris.barker at noaa.gov (Chris Barker)
Date: Thu, 21 Sep 2017 14:18:45 -0700
Subject: [Matplotlib-devel] mpl_cairo manylinux wheel available
In-Reply-To: <CAPp_WOocoK_pCVKD5drOuk+8VOigAPOxrLsfyUKiFHs0buAGyQ@mail.gmail.com>
References: <CAGRr6BHOXXXJ=94N=KJ5NkxYAOA6scgO0RbYyMBX2coiQ+fC2w@mail.gmail.com>
 <CAPp_WOocoK_pCVKD5drOuk+8VOigAPOxrLsfyUKiFHs0buAGyQ@mail.gmail.com>
Message-ID: <CALGmxEJxQAO8GjxXMLb393Y1-XC3+5Kr0BGf-2y_Fhfy802-2g@mail.gmail.com>

On Mon, Sep 18, 2017 at 2:06 AM, Francesco Faccenda <f.faccenda86 at gmail.com>
wrote:

>
>    1.
>    Would it work with matplotlib embedded on a wxpython stage or I'm
>    going to run in some issue if I use this backend?\
>
> This from the README:

The backend can be selected by setting the MPLBACKEND environment variable
to one of

   - module://mplcairo.qt (Qt5 widget, copying data from a cairo image
   surface),
   - module://mplcairo.wx (wx widget, copying data from a cairo image
   surface),
   - module://mplcairo.gtk3_native (GTK3 widget, directly drawn onto as a
   native surface),
   - module://mplcairo.base (No GUI, but can output to EPS, PDF, PS, SVG,
   and SVGZ using cairo's implementation, rather than Matplotlib's).

looks like wx is covered :-)

-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/20170921/f0cd9078/attachment.html>

From jklymak at uvic.ca  Thu Sep 21 18:50:46 2017
From: jklymak at uvic.ca (Jody Klymak)
Date: Thu, 21 Sep 2017 15:50:46 -0700
Subject: [Matplotlib-devel] Travis artifacts?
Message-ID: <7E27F079-C79D-4BFC-BACC-1AADDC3853A2@uvic.ca>


Hi all,

Does Travis upload artifacts to amazon or some such?  How do I access?  
I?m trying to see why I have a few image failures, and before I scrap 
the tests, I?d like to at least see what is going on.

Thanks a lot,   Jody

From tcaswell at gmail.com  Thu Sep 21 22:36:58 2017
From: tcaswell at gmail.com (Thomas Caswell)
Date: Fri, 22 Sep 2017 02:36:58 +0000
Subject: [Matplotlib-devel] [matplotlib-devel] Make matplotlib running
 on GPU/CUDA
In-Reply-To: <CALGmxEK6myDg7-X+GJkwrDTVpHhUpkijj+LB=pn-bGQcWn_G=g@mail.gmail.com>
References: <CAPp_WOqVavvXJoF255iTmdzZ0E9Dk2QQP3t3P3XkcgNpZz2o+A@mail.gmail.com>
 <CALGmxE+bset2QfPcOfyHMckNH1ko1M3EqWQeadiRS9EU6+g2Lg@mail.gmail.com>
 <CAPp_WOpsGjMJFGc3Q6+TyD3im+StRraPAfMCz+jhehBGd+Byiw@mail.gmail.com>
 <CALGmxEK6myDg7-X+GJkwrDTVpHhUpkijj+LB=pn-bGQcWn_G=g@mail.gmail.com>
Message-ID: <CAA48SF-_G_varHFfUi=4=46vDF5GUercq2ChCaSQVwx3GXk0rw@mail.gmail.com>

Depending on the exact use case you can get pretty good mileage out of
blitting (See http://matplotlib.org/api/animation_api.html#funcanimation for
an explanation or how it is used in the widgets module).

The best way to make things faster is to just do less work :)

Tom

On Thu, Sep 21, 2017 at 5:14 PM Chris Barker <chris.barker at noaa.gov> wrote:

> On Wed, Sep 13, 2017 at 12:31 AM, Francesco Faccenda <
> f.faccenda86 at gmail.com> wrote:
>
>> I have to admit I already stumbled on VisPy while doing my research on
>> the web. Still, I've got a lot of code already working with *matplotlib*.
>> Indeed, not only I plot data with it, but i manage a lot of *mpl events*
>> to provide the users usefool tools, like lines picking, tooltips, lines
>> copy/paste, square selectors for multiple selections, context menu and so
>> on. Moreover, I got matplotlib *embedded *on *wxpython *as well. While
>> at the beginning few lines were managed and noone complained, now that big
>> amout of data has to be displayed, the non-GPU core of the library is
>> starting to show its limits.
>>
>> Since matplotlib is a reference library for this kind of  applications, I
>> thought it deserved an update in this direction.
>>
>
> Well, As I understand it, VisPY made some effort to be compatible with the
> MPL API -- but that is going to depend on how much you use the lower-level
> parts f the API -- things like the transform, etc. to take advantage of GPU
> rendering, all the transforms, etc needs to be pushed to the GPU, so the
> architecture (and API) needs to be quite different.
>
>
>> If anyone is willing to do so, I'm available to discuss possible
>> solutions and also provide any help I can give.
>>
>
> As Ben pointed out, and I was trying to make clear -- it really isn't a
> matter of "just" writing an OpenGL backend -- there really needs to be a
> major restructuring.
>
> And VisPy is pretty much that project. Whether it is feature complete,
> robust and maintained enough for your use-cases, I have no idea, but even
> if not -- you'll probably be better off contributing to that effort than
> starting all over with trying to make an GPU_based OPenGL back-end.
>
> However -- maybe there is another option:
>
> Taking full advantage of GPUs does require a full restructuring, but maybe
> there are other ways to get better performance -- for instance, optimizing
> the transform code, etc:
>
> Using the GPU with PyCuda or [what the heck is the name of the more
> general GPU-using lib??]
>
> using numba
>
> Maybe there is still room for Cython, etc....
>
> In short, profiling MPL carefully, to see where the performance
> bottlenecks are:
>
> With modern hardware, actually rendering stuff is no longer the slow part
> of visualization. Rather, it's pushing data to the renderer, transforming
> data etc.
>
> This is why to take advantage of the GPU, you need to do the
> transformations, etc on the GPU -- which the MPL architecture doesn't make
> easy by dropping in a new back-end.
>
> Which is why VisPy built a new architecture from the bottom up.
>
> -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
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170922/e0aa10c5/attachment-0001.html>

From tcaswell at gmail.com  Mon Sep 25 18:35:18 2017
From: tcaswell at gmail.com (Thomas Caswell)
Date: Mon, 25 Sep 2017 22:35:18 +0000
Subject: [Matplotlib-devel] v2.1 schedule
Message-ID: <CAA48SF_wX6hwjxAOJZCsz9105aZfEQn0N0p6b9uTF6ad_aTeYA@mail.gmail.com>

Folks,

We are currently waiting on 2 PR (
https://github.com/matplotlib/matplotlib/pull/9199 and
https://github.com/matplotlib/matplotlib/pull/9068 ) and then I will cut
2.1 tonight.

It will probably take a few more days to finish writing up the release
notes and some final edits to the rst files.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170925/aede9bff/attachment.html>

From tcaswell at gmail.com  Mon Sep 25 18:32:13 2017
From: tcaswell at gmail.com (Thomas Caswell)
Date: Mon, 25 Sep 2017 22:32:13 +0000
Subject: [Matplotlib-devel] new committer
Message-ID: <CAA48SF_0+=yUxZ1bZEry7yJFfH-GXoZ+_d0KrcBSjmpVvafsuA@mail.gmail.com>

Folks,

Please welcome Jody Klymak (@jklymak on github) to the team!

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170925/01380f6a/attachment.html>

From matthew.brett at gmail.com  Mon Sep 25 18:38:48 2017
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 25 Sep 2017 23:38:48 +0100
Subject: [Matplotlib-devel] v2.1 schedule
In-Reply-To: <CAA48SF_wX6hwjxAOJZCsz9105aZfEQn0N0p6b9uTF6ad_aTeYA@mail.gmail.com>
References: <CAA48SF_wX6hwjxAOJZCsz9105aZfEQn0N0p6b9uTF6ad_aTeYA@mail.gmail.com>
Message-ID: <CAH6Pt5on5XBZ23AiKJQjqzhqT=_1GeUipOP=MYQH=L=yg=_FOA@mail.gmail.com>

Hi,

On Mon, Sep 25, 2017 at 11:35 PM, Thomas Caswell <tcaswell at gmail.com> wrote:
> Folks,
>
> We are currently waiting on 2 PR
> (https://github.com/matplotlib/matplotlib/pull/9199 and
> https://github.com/matplotlib/matplotlib/pull/9068 ) and then I will cut 2.1
> tonight.
>
> It will probably take a few more days to finish writing up the release notes
> and some final edits to the rst files.

Sorry to ask - but where did we get to on the subprocess32 problem?

Cheers,

Matthew

From tcaswell at gmail.com  Tue Sep 26 09:46:37 2017
From: tcaswell at gmail.com (Thomas Caswell)
Date: Tue, 26 Sep 2017 13:46:37 +0000
Subject: [Matplotlib-devel] v2.1 schedule
In-Reply-To: <CAH6Pt5on5XBZ23AiKJQjqzhqT=_1GeUipOP=MYQH=L=yg=_FOA@mail.gmail.com>
References: <CAA48SF_wX6hwjxAOJZCsz9105aZfEQn0N0p6b9uTF6ad_aTeYA@mail.gmail.com>
 <CAH6Pt5on5XBZ23AiKJQjqzhqT=_1GeUipOP=MYQH=L=yg=_FOA@mail.gmail.com>
Message-ID: <CAA48SF84Ab5R6H_JHtFrV-qi7Y89Zoq_N9wP_Z7xwS09UuBaDg@mail.gmail.com>

Still at an impasse with the subprocess32 dev.

We are between:

 - document the known issues (meaning wheel-installing mac users have to
install xcode and people on very old linux need to install from the
subprocess32 master branch, and general linux users need to have a gcc
installed)
 - hope subprocess32 does a release and adopts Matthew's wheels soon

I am pretty strongly -1 on vendoring it and -0 on publishing a
mpl-subprocess32 wheel.

See http://matplotlib.org/devdocs/users/installing.html#macos and
http://matplotlib.org/devdocs/users/installing.html#linux for how this is
documented.

Tom



On Mon, Sep 25, 2017 at 6:39 PM Matthew Brett <matthew.brett at gmail.com>
wrote:

> Hi,
>
> On Mon, Sep 25, 2017 at 11:35 PM, Thomas Caswell <tcaswell at gmail.com>
> wrote:
> > Folks,
> >
> > We are currently waiting on 2 PR
> > (https://github.com/matplotlib/matplotlib/pull/9199 and
> > https://github.com/matplotlib/matplotlib/pull/9068 ) and then I will
> cut 2.1
> > tonight.
> >
> > It will probably take a few more days to finish writing up the release
> notes
> > and some final edits to the rst files.
>
> Sorry to ask - but where did we get to on the subprocess32 problem?
>
> Cheers,
>
> Matthew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170926/e6e618af/attachment.html>

From ben.v.root at gmail.com  Tue Sep 26 10:41:50 2017
From: ben.v.root at gmail.com (Benjamin Root)
Date: Tue, 26 Sep 2017 10:41:50 -0400
Subject: [Matplotlib-devel] new committer
In-Reply-To: <CAA48SF_0+=yUxZ1bZEry7yJFfH-GXoZ+_d0KrcBSjmpVvafsuA@mail.gmail.com>
References: <CAA48SF_0+=yUxZ1bZEry7yJFfH-GXoZ+_d0KrcBSjmpVvafsuA@mail.gmail.com>
Message-ID: <CANNq6FnFeRqo-7pz4nNaoToq4vxGq01DwB1GCGnJwWQQ2TsRcg@mail.gmail.com>

Congratulations, Jody! Welcome to the team!

Ben Root

On Mon, Sep 25, 2017 at 6:32 PM, Thomas Caswell <tcaswell at gmail.com> wrote:

> Folks,
>
> Please welcome Jody Klymak (@jklymak on github) to the team!
>
> Tom
>
> _______________________________________________
> 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/20170926/43537ae5/attachment.html>

From tcaswell at gmail.com  Tue Sep 26 13:22:34 2017
From: tcaswell at gmail.com (Thomas Caswell)
Date: Tue, 26 Sep 2017 17:22:34 +0000
Subject: [Matplotlib-devel] CI: only run macosx on travis cron jobs / only
 branches
Message-ID: <CAA48SF9_dD=1PEit7DGiH96ZhehKF8ff=ohiSZs0MG-249YaOw@mail.gmail.com>

Folks,

https://blog.travis-ci.com/2017-09-22-macos-update

Due to the travis OSX infrastructure not being able to keep up with demand
they are going to limit concurrency of jobs that us osx.

We have not seen many (any?) mac specific issues which I think means we are
not getting much value out of running all of the PRs on OSX.

We can probably get better linux concurrency (and help lighten the load on
travis) if we do test on OSX less.

Thoughts?

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170926/3ef7153b/attachment.html>

From dstansby at gmail.com  Tue Sep 26 13:30:34 2017
From: dstansby at gmail.com (David Stansby)
Date: Tue, 26 Sep 2017 18:30:34 +0100
Subject: [Matplotlib-devel] CI: only run macosx on travis cron jobs /
 only branches
In-Reply-To: <CAA48SF9_dD=1PEit7DGiH96ZhehKF8ff=ohiSZs0MG-249YaOw@mail.gmail.com>
References: <CAA48SF9_dD=1PEit7DGiH96ZhehKF8ff=ohiSZs0MG-249YaOw@mail.gmail.com>
Message-ID: <CAGm9cHC5hSH7UMhrLgMmoe=Y7mBckQOC3e_k9q3N_4GkAWrCpg@mail.gmail.com>

"If you are using Linux only on .org, you will still have access to all
five concurrent builds, but if you are running both, only two of the five
concurrent builds can be used for macOS at any one time."

It sounds like they're only limiting concurrent macOS builds, so in theory
since we only have 1 we won't be affected. (I may have read the post
wrong?). If macOS jobs build up I presume that blocks other builds from
starting though?

I'm neutral either way - just testing in branches sounds like a reasonable
compromise if we'll be affected by this.

David

On 26 Sep 2017 6:22 pm, "Thomas Caswell" <tcaswell at gmail.com> wrote:

> Folks,
>
> https://blog.travis-ci.com/2017-09-22-macos-update
>
> Due to the travis OSX infrastructure not being able to keep up with demand
> they are going to limit concurrency of jobs that us osx.
>
> We have not seen many (any?) mac specific issues which I think means we
> are not getting much value out of running all of the PRs on OSX.
>
> We can probably get better linux concurrency (and help lighten the load on
> travis) if we do test on OSX less.
>
> Thoughts?
>
> Tom
>
> _______________________________________________
> 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/20170926/4f945219/attachment.html>

From efiring at hawaii.edu  Tue Sep 26 13:52:05 2017
From: efiring at hawaii.edu (Eric Firing)
Date: Tue, 26 Sep 2017 07:52:05 -1000
Subject: [Matplotlib-devel] CI: only run macosx on travis cron jobs /
 only branches
In-Reply-To: <CAA48SF9_dD=1PEit7DGiH96ZhehKF8ff=ohiSZs0MG-249YaOw@mail.gmail.com>
References: <CAA48SF9_dD=1PEit7DGiH96ZhehKF8ff=ohiSZs0MG-249YaOw@mail.gmail.com>
Message-ID: <be0e285b-c983-2046-ae67-4b66c3b95893@hawaii.edu>

On 2017/09/26 7:22 AM, Thomas Caswell wrote:
> Folks,
> 
> https://blog.travis-ci.com/2017-09-22-macos-update
> 
> Due to the travis OSX infrastructure not being able to keep up with 
> demand they are going to limit concurrency of jobs that us osx.
> 
> We have not seen many (any?) mac specific issues which I think means we 
> are not getting much value out of running all of the PRs on OSX.
> 
> We can probably get better linux concurrency (and help lighten the load 
> on travis) if we do test on OSX less.
> 
> Thoughts?
> 
> Tom

I agree with the suggestion to reduce OSX testing.

Eric

From tune.kamae at gmail.com  Mon Sep 25 05:40:42 2017
From: tune.kamae at gmail.com (Tune Kamae)
Date: Mon, 25 Sep 2017 18:40:42 +0900
Subject: [Matplotlib-devel] Producing plots with objects
Message-ID: <59c8cf19.d469240a.fe850.512c@mx.google.com>

Hi,

My knowledge on matplotlib is limited and may be using wrong terminology.
However my goal is quite clear. What I don?t know is where to post my question.
If this is not the right mailing list, please forgive me and suggest the right mailing list.

My goal:
1) Make a plot with all elements accessible as objects like the one Excel produces.
2) Then by touching anywhere on screen (assuming Win10 with a touch screen), one will know how close is the touch location to a curve or the x-axis.
3) If such a plot can be put out, I can program for the blind students follow a line by producing sound.
4) They can follow any one of multiple curves in a plot and can feel what a sinusoidal curve is.

I would greatly appreciate if someone can guide me along this direction.

Tune Kamae

Windows 10 ?????????

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

From jklymak at uvic.ca  Tue Sep 26 17:16:00 2017
From: jklymak at uvic.ca (Jody Klymak)
Date: Tue, 26 Sep 2017 14:16:00 -0700
Subject: [Matplotlib-devel] Producing plots with objects
In-Reply-To: <59c8cf19.d469240a.fe850.512c@mx.google.com>
References: <59c8cf19.d469240a.fe850.512c@mx.google.com>
Message-ID: <449BBFAD-A332-4EEE-B384-9A26C0F49147@uvic.ca>

Sure you can do this, plus or minus the Windows 10 interaction which I 
know nothing about.  Once you figure to how to plot what you want, have 
a look at:

https://matplotlib.org/users/event_handling.html

to see how to make the plot respond to `button_press_event` or 
`motion_notify_event`.

Cheers,   Jody

On 25 Sep 2017, at 2:40, Tune Kamae wrote:

> Hi,
>
> My knowledge on matplotlib is limited and may be using wrong 
> terminology.
> However my goal is quite clear. What I don?t know is where to post 
> my question.
> If this is not the right mailing list, please forgive me and suggest 
> the right mailing list.
>
> My goal:
> 1) Make a plot with all elements accessible as objects like the one 
> Excel produces.
> 2) Then by touching anywhere on screen (assuming Win10 with a touch 
> screen), one will know how close is the touch location to a curve or 
> the x-axis.
> 3) If such a plot can be put out, I can program for the blind students 
> follow a line by producing sound.
> 4) They can follow any one of multiple curves in a plot and can feel 
> what a sinusoidal curve is.
>
> I would greatly appreciate if someone can guide me along this 
> direction.
>
> Tune Kamae
>
> Windows 10 ?????????


> _______________________________________________
> 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/20170926/9b5ab2bb/attachment.html>

From tcaswell at gmail.com  Wed Sep 27 01:11:52 2017
From: tcaswell at gmail.com (Thomas Caswell)
Date: Wed, 27 Sep 2017 05:11:52 +0000
Subject: [Matplotlib-devel] Producing plots with objects
In-Reply-To: <449BBFAD-A332-4EEE-B384-9A26C0F49147@uvic.ca>
References: <59c8cf19.d469240a.fe850.512c@mx.google.com>
 <449BBFAD-A332-4EEE-B384-9A26C0F49147@uvic.ca>
Message-ID: <CAA48SF8XCxJtoKL8D-OkzJ07YBU3TcmxBJYXYuW3KB-4-bbR0Q@mail.gmail.com>

Ben Root wrote a book on interactive figures
https://www.amazon.com/Interactive-Applications-using-Matplotlib-Benjamin/dp/1783988843

Also see the 03 tutorial on picking in
https://github.com/tacaswell/interactive_mpl_tutorial

Tom

On Tue, Sep 26, 2017 at 2:16 PM Jody Klymak <jklymak at uvic.ca> wrote:

> Sure you can do this, plus or minus the Windows 10 interaction which I
> know nothing about. Once you figure to how to plot what you want, have a
> look at:
>
> https://matplotlib.org/users/event_handling.html
>
> to see how to make the plot respond to button_press_event or
> motion_notify_event.
>
> Cheers, Jody
>
> On 25 Sep 2017, at 2:40, Tune Kamae wrote:
>
> Hi,
>
>
>
> My knowledge on matplotlib is limited and may be using wrong terminology.
>
> However my goal is quite clear. What I don?t know is where to post my
> question.
>
> If this is not the right mailing list, please forgive me and suggest the
> right mailing list.
>
>
>
> My goal:
>
>    1. Make a plot with all elements accessible as objects like the one
>    Excel produces.
>    2. Then by touching anywhere on screen (assuming Win10 with a touch
>    screen), one will know how close is the touch location to a curve or the
>    x-axis.
>    3. If such a plot can be put out, I can program for the blind students
>    follow a line by producing sound.
>    4. They can follow any one of multiple curves in a plot and can feel
>    what a sinusoidal curve is.
>
>
>
> I would greatly appreciate if someone can guide me along this direction.
>
>
>
> Tune Kamae
>
>
>
> Windows 10 ????? <https://go.microsoft.com/fwlink/?LinkId=550986>????
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
> _______________________________________________
> 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/20170927/7a61f7cd/attachment-0001.html>

From ben.v.root at gmail.com  Wed Sep 27 12:38:53 2017
From: ben.v.root at gmail.com (Benjamin Root)
Date: Wed, 27 Sep 2017 12:38:53 -0400
Subject: [Matplotlib-devel] Producing plots with objects
In-Reply-To: <CAA48SF8XCxJtoKL8D-OkzJ07YBU3TcmxBJYXYuW3KB-4-bbR0Q@mail.gmail.com>
References: <59c8cf19.d469240a.fe850.512c@mx.google.com>
 <449BBFAD-A332-4EEE-B384-9A26C0F49147@uvic.ca>
 <CAA48SF8XCxJtoKL8D-OkzJ07YBU3TcmxBJYXYuW3KB-4-bbR0Q@mail.gmail.com>
Message-ID: <CANNq6FmSh4JYznRGN8TZ0-TAizyGMsV4qGbgHrZDumryNTzNbg@mail.gmail.com>

Tune,

That sounds like a fantastic project, and I absolutely *love* the idea! As
a low-vision person myself, I understand the need for such applications.
The last time I did anything like this for other visually-impaired
students, I used foam pads and a mixture of sand and glue to teach students
the shape of the letters of the alphabet by tracing their fingers along the
rough parts of the foam pad. Luckily, the alphabet doesn't change, so I can
just have a single set of them. But for mathematical formulas, you would
certainly need something dynamic to help with exploration of the many kinds
of mathematical formulas.

The basic idea here would be a program that would have a some plotted curve
(fetched from the object returned by the call to `plt.plot()`), and a
callback function attached to the 'button_press' event (assuming that is
what a touchscreen reports screen touches as). In the callback function,
you would have the x/y coordinates of the press event, and you would have
the curve as a stored object (either as a global or some such). You would
then calculate the distance between the x/y of the event, and the curve,
and then activate a tone (I would assume python has some sort of
sound-playing package somewhere). You can then deactivate the tone on the
'button_release' event (a second callback). There is also a 'mouse_move'
event, if I remember correctly, so you can update the tone as the finger
drags along the screen.

Let me know if you have more questions!

Cheers!
Ben Root



On Wed, Sep 27, 2017 at 1:11 AM, Thomas Caswell <tcaswell at gmail.com> wrote:

> Ben Root wrote a book on interactive figures https://www.amazon.com/
> Interactive-Applications-using-Matplotlib-Benjamin/dp/1783988843
>
> Also see the 03 tutorial on picking in https://github.com/
> tacaswell/interactive_mpl_tutorial
>
> Tom
>
> On Tue, Sep 26, 2017 at 2:16 PM Jody Klymak <jklymak at uvic.ca> wrote:
>
>> Sure you can do this, plus or minus the Windows 10 interaction which I
>> know nothing about. Once you figure to how to plot what you want, have a
>> look at:
>>
>> https://matplotlib.org/users/event_handling.html
>>
>> to see how to make the plot respond to button_press_event or
>> motion_notify_event.
>>
>> Cheers, Jody
>>
>> On 25 Sep 2017, at 2:40, Tune Kamae wrote:
>>
>> Hi,
>>
>>
>>
>> My knowledge on matplotlib is limited and may be using wrong terminology.
>>
>> However my goal is quite clear. What I don?t know is where to post my
>> question.
>>
>> If this is not the right mailing list, please forgive me and suggest the
>> right mailing list.
>>
>>
>>
>> My goal:
>>
>>    1. Make a plot with all elements accessible as objects like the one
>>    Excel produces.
>>    2. Then by touching anywhere on screen (assuming Win10 with a touch
>>    screen), one will know how close is the touch location to a curve or the
>>    x-axis.
>>    3. If such a plot can be put out, I can program for the blind
>>    students follow a line by producing sound.
>>    4. They can follow any one of multiple curves in a plot and can feel
>>    what a sinusoidal curve is.
>>
>>
>>
>> I would greatly appreciate if someone can guide me along this direction.
>>
>>
>>
>> Tune Kamae
>>
>>
>>
>> Windows 10 ????? <https://go.microsoft.com/fwlink/?LinkId=550986>????
>>
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>
>
> _______________________________________________
> 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/20170927/aa773109/attachment.html>

From tune.kamae at gmail.com  Thu Sep 28 12:01:57 2017
From: tune.kamae at gmail.com (tune.kamae at gmail.com)
Date: Fri, 29 Sep 2017 01:01:57 +0900
Subject: [Matplotlib-devel] Producing plots with objects
In-Reply-To: <CANNq6FmSh4JYznRGN8TZ0-TAizyGMsV4qGbgHrZDumryNTzNbg@mail.gmail.com>
References: <59c8cf19.d469240a.fe850.512c@mx.google.com>
 <449BBFAD-A332-4EEE-B384-9A26C0F49147@uvic.ca>
 <CAA48SF8XCxJtoKL8D-OkzJ07YBU3TcmxBJYXYuW3KB-4-bbR0Q@mail.gmail.com>
 <CANNq6FmSh4JYznRGN8TZ0-TAizyGMsV4qGbgHrZDumryNTzNbg@mail.gmail.com>
Message-ID: <016701d33873$1e4fd820$5aef8860$@gmail.com>

Ben and other developers

 

I confirmed that the interactive Matplotlib has most basic functions I need. I wrote a simple javascript to speak English or Japanese and also to recognize voice like x-axis, y-axis, line-1 etc. I haven?t written code to make beep sounds changing volume and tone.

 

With my limited knowledge, I couldn?t figure out mixing javascript with python in a same Jupyter cell. So I have been thinking to use the execjs package and define functions for TTS and voice recognition.  Then I can call these functions from python.

 

Once I understand these basic strategy I would like to find a coding pro and ask to make a prototype package. 

 

Meantime I am exploring some way to voice Jupyter Notebook. The easiest way for me is to convert the notebook to an html in which links are made to individual cells. If there is a way to set Jupyter ignore <a href ?>, my scheme may work.

 

Thank you for assistance.

 

Tune Kamae

 

From: Benjamin Root [mailto:ben.v.root at gmail.com] 
Sent: Thursday, September 28, 2017 1:39 AM
To: Thomas Caswell <tcaswell at gmail.com>
Cc: Jody Klymak <jklymak at uvic.ca>; Tune Kamae <tune.kamae at gmail.com>; matplotlib-devel at python.org
Subject: Re: [Matplotlib-devel] Producing plots with objects

 

Tune,

That sounds like a fantastic project, and I absolutely *love* the idea! As a low-vision person myself, I understand the need for such applications. The last time I did anything like this for other visually-impaired students, I used foam pads and a mixture of sand and glue to teach students the shape of the letters of the alphabet by tracing their fingers along the rough parts of the foam pad. Luckily, the alphabet doesn't change, so I can just have a single set of them. But for mathematical formulas, you would certainly need something dynamic to help with exploration of the many kinds of mathematical formulas.

The basic idea here would be a program that would have a some plotted curve (fetched from the object returned by the call to `plt.plot()`), and a callback function attached to the 'button_press' event (assuming that is what a touchscreen reports screen touches as). In the callback function, you would have the x/y coordinates of the press event, and you would have the curve as a stored object (either as a global or some such). You would then calculate the distance between the x/y of the event, and the curve, and then activate a tone (I would assume python has some sort of sound-playing package somewhere). You can then deactivate the tone on the 'button_release' event (a second callback). There is also a 'mouse_move' event, if I remember correctly, so you can update the tone as the finger drags along the screen.

Let me know if you have more questions!

Cheers!

Ben Root

 

 

On Wed, Sep 27, 2017 at 1:11 AM, Thomas Caswell <tcaswell at gmail.com <mailto:tcaswell at gmail.com> > wrote:

Ben Root wrote a book on interactive figures https://www.amazon.com/Interactive-Applications-using-Matplotlib-Benjamin/dp/1783988843

 

Also see the 03 tutorial on picking in https://github.com/tacaswell/interactive_mpl_tutorial

 

Tom

 

On Tue, Sep 26, 2017 at 2:16 PM Jody Klymak <jklymak at uvic.ca <mailto:jklymak at uvic.ca> > wrote:

Sure you can do this, plus or minus the Windows 10 interaction which I know nothing about. Once you figure to how to plot what you want, have a look at:

https://matplotlib.org/users/event_handling.html

to see how to make the plot respond to button_press_event or motion_notify_event.

Cheers, Jody

On 25 Sep 2017, at 2:40, Tune Kamae wrote:

Hi,

 

My knowledge on matplotlib is limited and may be using wrong terminology.

However my goal is quite clear. What I don?t know is where to post my question.

If this is not the right mailing list, please forgive me and suggest the right mailing list.

 

My goal:

1.	Make a plot with all elements accessible as objects like the one Excel produces.
2.	Then by touching anywhere on screen (assuming Win10 with a touch screen), one will know how close is the touch location to a curve or the x-axis.
3.	If such a plot can be put out, I can program for the blind students follow a line by producing sound.
4.	They can follow any one of multiple curves in a plot and can feel what a sinusoidal curve is.

 

I would greatly appreciate if someone can guide me along this direction.

 

Tune Kamae

 

Windows 10 ?? <https://go.microsoft.com/fwlink/?LinkId=550986> ???????

 

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org> 
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org> 
https://mail.python.org/mailman/listinfo/matplotlib-devel


_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org <mailto: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/20170929/8bc6dfee/attachment-0001.html>

From ben.v.root at gmail.com  Thu Sep 28 12:35:51 2017
From: ben.v.root at gmail.com (Benjamin Root)
Date: Thu, 28 Sep 2017 12:35:51 -0400
Subject: [Matplotlib-devel] Producing plots with objects
In-Reply-To: <016701d33873$1e4fd820$5aef8860$@gmail.com>
References: <59c8cf19.d469240a.fe850.512c@mx.google.com>
 <449BBFAD-A332-4EEE-B384-9A26C0F49147@uvic.ca>
 <CAA48SF8XCxJtoKL8D-OkzJ07YBU3TcmxBJYXYuW3KB-4-bbR0Q@mail.gmail.com>
 <CANNq6FmSh4JYznRGN8TZ0-TAizyGMsV4qGbgHrZDumryNTzNbg@mail.gmail.com>
 <016701d33873$1e4fd820$5aef8860$@gmail.com>
Message-ID: <CANNq6F=+MW0=ffFNrkNUnag67Exp_18Tg17EA9Lq1zhve9vhNg@mail.gmail.com>

Tune,

If you are already working in the jupyter notebook and doing javascript,
then you should look into utilizing jupyter widgets, which I think is
javascript based and should integrate well with matplotlib. Jupyter widgets
aren't covered in my book, though, and they are a bit of a moving target,
API-wise.

Ben Root


On Thu, Sep 28, 2017 at 12:01 PM, <tune.kamae at gmail.com> wrote:

> Ben and other developers
>
>
>
> I confirmed that the interactive Matplotlib has most basic functions I
> need. I wrote a simple javascript to speak English or Japanese and also to
> recognize voice like x-axis, y-axis, line-1 etc. I haven?t written code to
> make beep sounds changing volume and tone.
>
>
>
> With my limited knowledge, I couldn?t figure out mixing javascript with
> python in a same Jupyter cell. So I have been thinking to use the execjs
> package and define functions for TTS and voice recognition.  Then I can
> call these functions from python.
>
>
>
> Once I understand these basic strategy I would like to find a coding pro
> and ask to make a prototype package.
>
>
>
> Meantime I am exploring some way to voice Jupyter Notebook. The easiest
> way for me is to convert the notebook to an html in which links are made to
> individual cells. If there is a way to set Jupyter ignore <a href ?>, my
> scheme may work.
>
>
>
> Thank you for assistance.
>
>
>
> Tune Kamae
>
>
>
> *From:* Benjamin Root [mailto:ben.v.root at gmail.com]
> *Sent:* Thursday, September 28, 2017 1:39 AM
> *To:* Thomas Caswell <tcaswell at gmail.com>
> *Cc:* Jody Klymak <jklymak at uvic.ca>; Tune Kamae <tune.kamae at gmail.com>;
> matplotlib-devel at python.org
> *Subject:* Re: [Matplotlib-devel] Producing plots with objects
>
>
>
> Tune,
>
> That sounds like a fantastic project, and I absolutely *love* the idea! As
> a low-vision person myself, I understand the need for such applications.
> The last time I did anything like this for other visually-impaired
> students, I used foam pads and a mixture of sand and glue to teach students
> the shape of the letters of the alphabet by tracing their fingers along the
> rough parts of the foam pad. Luckily, the alphabet doesn't change, so I can
> just have a single set of them. But for mathematical formulas, you would
> certainly need something dynamic to help with exploration of the many kinds
> of mathematical formulas.
>
> The basic idea here would be a program that would have a some plotted
> curve (fetched from the object returned by the call to `plt.plot()`), and a
> callback function attached to the 'button_press' event (assuming that is
> what a touchscreen reports screen touches as). In the callback function,
> you would have the x/y coordinates of the press event, and you would have
> the curve as a stored object (either as a global or some such). You would
> then calculate the distance between the x/y of the event, and the curve,
> and then activate a tone (I would assume python has some sort of
> sound-playing package somewhere). You can then deactivate the tone on the
> 'button_release' event (a second callback). There is also a 'mouse_move'
> event, if I remember correctly, so you can update the tone as the finger
> drags along the screen.
>
> Let me know if you have more questions!
>
> Cheers!
>
> Ben Root
>
>
>
>
>
> On Wed, Sep 27, 2017 at 1:11 AM, Thomas Caswell <tcaswell at gmail.com>
> wrote:
>
> Ben Root wrote a book on interactive figures https://www.amazon.com/
> Interactive-Applications-using-Matplotlib-Benjamin/dp/1783988843
>
>
>
> Also see the 03 tutorial on picking in https://github.com/
> tacaswell/interactive_mpl_tutorial
>
>
>
> Tom
>
>
>
> On Tue, Sep 26, 2017 at 2:16 PM Jody Klymak <jklymak at uvic.ca> wrote:
>
> Sure you can do this, plus or minus the Windows 10 interaction which I
> know nothing about. Once you figure to how to plot what you want, have a
> look at:
>
> https://matplotlib.org/users/event_handling.html
>
> to see how to make the plot respond to button_press_event or
> motion_notify_event.
>
> Cheers, Jody
>
> On 25 Sep 2017, at 2:40, Tune Kamae wrote:
>
> Hi,
>
>
>
> My knowledge on matplotlib is limited and may be using wrong terminology.
>
> However my goal is quite clear. What I don?t know is where to post my
> question.
>
> If this is not the right mailing list, please forgive me and suggest the
> right mailing list.
>
>
>
> My goal:
>
>    1. Make a plot with all elements accessible as objects like the one
>    Excel produces.
>    2. Then by touching anywhere on screen (assuming Win10 with a touch
>    screen), one will know how close is the touch location to a curve or the
>    x-axis.
>    3. If such a plot can be put out, I can program for the blind students
>    follow a line by producing sound.
>    4. They can follow any one of multiple curves in a plot and can feel
>    what a sinusoidal curve is.
>
>
>
> I would greatly appreciate if someone can guide me along this direction.
>
>
>
> Tune Kamae
>
>
>
> Windows 10 ????? <https://go.microsoft.com/fwlink/?LinkId=550986>????
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
>
> _______________________________________________
> 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/20170928/53ab0601/attachment-0001.html>

From anntzer.lee at gmail.com  Fri Sep 29 02:55:37 2017
From: anntzer.lee at gmail.com (Antony Lee)
Date: Thu, 28 Sep 2017 23:55:37 -0700
Subject: [Matplotlib-devel] mpl_cairo manylinux wheel available
In-Reply-To: <CAH6Pt5qnCAnmpos5Gc+CVjkuaxvpR46iEdW6kPrc=ZaC+gRv8w@mail.gmail.com>
References: <CAGRr6BHOXXXJ=94N=KJ5NkxYAOA6scgO0RbYyMBX2coiQ+fC2w@mail.gmail.com>
 <CAH6Pt5qnCAnmpos5Gc+CVjkuaxvpR46iEdW6kPrc=ZaC+gRv8w@mail.gmail.com>
Message-ID: <CAGRr6BHg6pGwpummPOR=-8R3Vu+uL4K8mFZm07Y=YxD9a=Hvbg@mail.gmail.com>

A friend kindly lent me their MacBook (thank you!) and I managed to build a
wheel there too -- it is now uploaded (under Github releases as well), and
the setup.py and instructions have been updated accordingly (TL;DR: clang 5
from homebrew works).
I only did limited testing though, and know very little about compatibility
across OSX versions (all I know is that the wheel installed correctly on
that laptop), so no guarantees.
Antony

2017-09-16 2:43 GMT-07:00 Matthew Brett <matthew.brett at gmail.com>:

> On Sat, Sep 16, 2017 at 10:10 AM, Antony Lee <anntzer.lee at gmail.com>
> wrote:
> > Hi all,
> > A manylinux wheel for mpl_cairo (https://github.com/anntzer/mpl_cairo)
> is
> > now available (under GitHub releases).  mpl_cairo is a new, cairo-based
> > backend for Matplotlib, that offers several improvements over the current
> > default, Agg-based backend.  See the README on GitHub for more details
> :-)
> > I would be interested in hearing your feedback.
>
> Nice!  Any plans for an OSX build?  Or are they hard?
>
> Cheers,
>
> Matthew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170928/613a43ea/attachment.html>

From rogier.delporte at gmail.com  Fri Sep 29 09:57:08 2017
From: rogier.delporte at gmail.com (Rogier Delporte)
Date: Fri, 29 Sep 2017 15:57:08 +0200
Subject: [Matplotlib-devel] feature request
Message-ID: <CAPAMuMcWgZdfQhgW0F0X1Kv65qbDdY4Xgt5HXA7z7m-XZu7Xpg@mail.gmail.com>

Dear maintainer(s)
Dear developpers

I would like to request a new matplotlib feature. The current version of
matplotlib shows the coordinates of the cursor in the bottom right corner.
It would be great if some option or mode could be added which snaps the
cursor to data points. This would take some guesswork out of reading a plot
with a lot of points.

I know this feature is similar to the mpldatacursor toolkit, but
mpldatacursor does not provide a smooth and fast way to pinpoint a data
point.

I hope someone would like to implement this feature, because I don't have
sufficient programming skills to implement this myself.

Thanks for the awesomeness that is matplotlib!

Rogier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170929/555210a2/attachment.html>

From jklymak at uvic.ca  Fri Sep 29 17:24:56 2017
From: jklymak at uvic.ca (Jody Klymak)
Date: Fri, 29 Sep 2017 14:24:56 -0700
Subject: [Matplotlib-devel] feature request
In-Reply-To: <CAPAMuMcWgZdfQhgW0F0X1Kv65qbDdY4Xgt5HXA7z7m-XZu7Xpg@mail.gmail.com>
References: <CAPAMuMcWgZdfQhgW0F0X1Kv65qbDdY4Xgt5HXA7z7m-XZu7Xpg@mail.gmail.com>
Message-ID: <82B4C2EE-90F3-4E14-A4AF-7DED20A30DE6@uvic.ca>

Hi Rogier,

You can already do this by writing a `format_coord` function and setting 
`ax.format_coord` property of the axis with your data in it.

http://matplotlib.org/examples/api/image_zcoord.html

Cheers,   Jody

On 29 Sep 2017, at 6:57, Rogier Delporte wrote:

> Dear maintainer(s)
> Dear developpers
>
> I would like to request a new matplotlib feature. The current version 
> of
> matplotlib shows the coordinates of the cursor in the bottom right 
> corner.
> It would be great if some option or mode could be added which snaps 
> the
> cursor to data points. This would take some guesswork out of reading a 
> plot
> with a lot of points.
>
> I know this feature is similar to the mpldatacursor toolkit, but
> mpldatacursor does not provide a smooth and fast way to pinpoint a 
> data
> point.
>
> I hope someone would like to implement this feature, because I don't 
> have
> sufficient programming skills to implement this myself.
>
> Thanks for the awesomeness that is matplotlib!
>
> Rogier
> _______________________________________________
> 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/20170929/09a81e87/attachment.html>

From antony.lee at berkeley.edu  Fri Sep 29 17:35:27 2017
From: antony.lee at berkeley.edu (Antony Lee)
Date: Fri, 29 Sep 2017 14:35:27 -0700
Subject: [Matplotlib-devel] feature request
In-Reply-To: <82B4C2EE-90F3-4E14-A4AF-7DED20A30DE6@uvic.ca>
References: <CAPAMuMcWgZdfQhgW0F0X1Kv65qbDdY4Xgt5HXA7z7m-XZu7Xpg@mail.gmail.com>
 <82B4C2EE-90F3-4E14-A4AF-7DED20A30DE6@uvic.ca>
Message-ID: <CAGRr6BH_TKe-OduRoarXwOKpphYYW=UivuEX0sFN7s8oC9-92g@mail.gmail.com>

Hi,
You may also want to look at mplcursors's hover mode (
https://mplcursors.readthedocs.io/en/latest/examples/hover.html#sphx-glr-examples-hover-py
).
Antony

2017-09-29 14:24 GMT-07:00 Jody Klymak <jklymak at uvic.ca>:

> Hi Rogier,
>
> You can already do this by writing a format_coord function and setting
> ax.format_coord property of the axis with your data in it.
>
> http://matplotlib.org/examples/api/image_zcoord.html
>
> Cheers, Jody
>
> On 29 Sep 2017, at 6:57, Rogier Delporte wrote:
>
> Dear maintainer(s)
> Dear developpers
>
> I would like to request a new matplotlib feature. The current version of
> matplotlib shows the coordinates of the cursor in the bottom right corner.
> It would be great if some option or mode could be added which snaps the
> cursor to data points. This would take some guesswork out of reading a plot
> with a lot of points.
>
> I know this feature is similar to the mpldatacursor toolkit, but
> mpldatacursor does not provide a smooth and fast way to pinpoint a data
> point.
>
> I hope someone would like to implement this feature, because I don't have
> sufficient programming skills to implement this myself.
>
> Thanks for the awesomeness that is matplotlib!
>
> Rogier
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>
>
> _______________________________________________
> 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/20170929/36bae775/attachment.html>

From jklymak at uvic.ca  Fri Sep 29 18:39:10 2017
From: jklymak at uvic.ca (Jody Klymak)
Date: Fri, 29 Sep 2017 15:39:10 -0700
Subject: [Matplotlib-devel] Help with constrained_layout
Message-ID: <22E06583-8210-40B7-B970-456135D4C52D@uvic.ca>

Hi all,

I know a lot of bandwidth has been taken up w/ the 2.1 release, but that 
seems to be settling down now. I?ve been working hard on the 
constraint-driven layout.  This is an alternate to `tight_layout`, and 
based on [kiwi-solver](https://github.com/nucleic/kiwi/tree/master/py)  
I think its mostly feature-complete at this point, and handles numerous 
situations not handled by `tight_layout` like `suptitle`, over-spilling 
legends, colorbars that belong to a group of axes (as opposed to just 
one axis), nested gridspecs, etc.  (Conversely, it doesn?t work at all 
w/ `plt.subplot` or `plt.subplot2grid` because each call to these 
functions makes their own gridspec, and we do the layout within 
individual gridspecs).

I?m writing to appeal for some help testing this, or coming up with 
situations that I didn?t think about.  There is one request for 
AnchoredOffsetBoxes, which I haven?t done yet, but I think that is a 
0.2 feature once folks think the basic idea is OK. I?m also more than 
open to addressing any implementation concerns/suggestions.

Right now, automatic installation only works with python 3.6 because we 
require kiwi-solver gitub master version for python 2.7.  But you should 
be able to install with `pip install .` into a virtualenv.

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

There is also a guide in 
`tutorials/intermediate/constrainedlayout_guide.py`.  It probably still 
has some rough edges, but suggestions welcome.

Thanks for any help.

Cheers,   Jody
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20170929/c5804853/attachment-0001.html>

From rogier.delporte at gmail.com  Sat Sep 30 02:45:46 2017
From: rogier.delporte at gmail.com (Rogier Delporte)
Date: Sat, 30 Sep 2017 08:45:46 +0200
Subject: [Matplotlib-devel] feature request
In-Reply-To: <CAGRr6BH_TKe-OduRoarXwOKpphYYW=UivuEX0sFN7s8oC9-92g@mail.gmail.com>
References: <CAPAMuMcWgZdfQhgW0F0X1Kv65qbDdY4Xgt5HXA7z7m-XZu7Xpg@mail.gmail.com>
 <82B4C2EE-90F3-4E14-A4AF-7DED20A30DE6@uvic.ca>
 <CAGRr6BH_TKe-OduRoarXwOKpphYYW=UivuEX0sFN7s8oC9-92g@mail.gmail.com>
Message-ID: <CAPAMuMct-BAuc6w9z6cBvhzCO3P5gjh_OM3VXsM40WR1AGyWdQ@mail.gmail.com>

Thanks, I'll check it out.

Op 29 sep. 2017 11:35 p.m. schreef "Antony Lee" <antony.lee at berkeley.edu>:

> Hi,
> You may also want to look at mplcursors's hover mode (https://mplcursors.
> readthedocs.io/en/latest/examples/hover.html#sphx-glr-examples-hover-py).
> Antony
>
> 2017-09-29 14:24 GMT-07:00 Jody Klymak <jklymak at uvic.ca>:
>
>> Hi Rogier,
>>
>> You can already do this by writing a format_coord function and setting
>> ax.format_coord property of the axis with your data in it.
>>
>> http://matplotlib.org/examples/api/image_zcoord.html
>>
>> Cheers, Jody
>>
>> On 29 Sep 2017, at 6:57, Rogier Delporte wrote:
>>
>> Dear maintainer(s)
>> Dear developpers
>>
>> I would like to request a new matplotlib feature. The current version of
>> matplotlib shows the coordinates of the cursor in the bottom right corner.
>> It would be great if some option or mode could be added which snaps the
>> cursor to data points. This would take some guesswork out of reading a
>> plot
>> with a lot of points.
>>
>> I know this feature is similar to the mpldatacursor toolkit, but
>> mpldatacursor does not provide a smooth and fast way to pinpoint a data
>> point.
>>
>> I hope someone would like to implement this feature, because I don't have
>> sufficient programming skills to implement this myself.
>>
>> Thanks for the awesomeness that is matplotlib!
>>
>> Rogier
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>
>>
>> _______________________________________________
>> 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/20170930/fc860f28/attachment.html>