matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] release strategy and the color revolution

[Thomas C. <tca...@gm...>]

I have opened a PR to document this discussion.  It is meant to provide a
permanent record of the thought process leading up to color map and to
serve as a tool in making the finial decision.

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

On Mon, Mar 2, 2015 at 6:32 AM jni <jni...@gm...> wrote:

> Hi Pierre,
>
> Could you please elaborate a bit on this
>> usecase. I was thinking, naively, that when plotting a grayscale image,
>> one would simply used a gray colormap.
>>
>
> Using a colormap with hue and saturation gives you better contrast than
> pure grayscale. For natural images, that is, photographs of human-scale
> objects, indeed grayscale is a good choice, because that is how we are used
> to looking at those images. But for looking at physical quantities, for
> example, using a colormap with hue and saturation as well as lightness is
> useful. Here are some examples:
> http://www.gnuplotting.org/color-maps-from-colorbrewer/
> https://www.mrao.cam.ac.uk/~dag/CUBEHELIX/
>
> See also a "boundary probability map" for a natural image here (panel B,
> top right):
>
> http://www.frontiersin.org/files/Articles/74212/fninf-08-00034-r2/image_m/fninf-08-00034-g001.jpg
> Having the colormap makes it easier to place the intermediate levels of
> the probability map.
>
> Again, restricting the lightness range for these maps would be
> problematic, to say the least.
>
> Juan.
>
> ------------------------------
> View this message in context: Re: release strategy and the color
> revolution
> <http://matplotlib.1069221.n5.nabble.com/release-strategy-and-the-color-revolution-tp44929p45030.html>
> Sent from the matplotlib - devel mailing list archive
> <http://matplotlib.1069221.n5.nabble.com/matplotlib-devel-f28077.html> at
> Nabble.com.
> ------------------------------------------------------------
> ------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] MEP22 review request

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

To provide a bit more information for those who have forgotten, here is an
excerpt from the MEP:

Abstract

The main goal of this MEP is to make it easier to modify (add, change,
remove) the way the user interacts with the figures.

The user interaction with the figure is deeply integrated within the Canvas
and Toolbar. Making extremely difficult to do any modification.

This MEP proposes the separation of this interaction into Toolbar,
Navigation and Tools to provide independent access and reconfiguration.

This approach will make easier to create and share tools among users. In
the far future, we can even foresee a kind of Marketplace for Tools where
the most popular can be added into the main distribution.
 Detailed description

The reconfiguration of the Toolbar is complex, most of the time it requires
a custom backend.

The creation of custom Tools sometimes interferes with the Toolbar, as
example see https://github.com/matplotlib/matplotlib/issues/2694 also the
shortcuts are hardcoded and again not easily modifiable
https://github.com/matplotlib/matplotlib/issues/2699

The proposed solution is to take the actions out of the Toolbar and the
shortcuts out of the Canvas. This actions and shortcuts will be in the form
of Tools.

A new class Navigation will be the bridge between the events from the Canvas
and Toolbar and redirect them to the appropiate Tool.

At the end the user interaction will be divided into three classes:

   - NavigationBase: This class is instantiated for each FigureManager and
   connect the all user interactions with the Tools
   - ToolbarBase: This existing class is relegated only as a GUI access to
   Tools.
   - ToolBase: Is the basic definition of Tools.



On Tue, Mar 17, 2015 at 8:29 AM, Federico Ariza <ari...@gm...>
wrote:

> Hello everybody.
>
> The implementation of MEP22 is pretty much completed
>
> https://github.com/matplotlib/matplotlib/pull/3652
>
> Please give it a try it's been sitting there for quite long time.
>
> Thanks
> Federico
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

[matplotlib-devel] MEP22 review request

[Federico A. <ari...@gm...>]

Hello everybody.

The implementation of MEP22 is pretty much completed

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

Please give it a try it's been sitting there for quite long time.

Thanks
Federico

Re: [matplotlib-devel] Kivy backend

[Chris B. - N. F. <chr...@no...>]

On Mar 13, 2015, at 12:50 PM, Cyrille Rossant <cyr...@gm...> wrote:

> Exactly. Note that pushing data on the GPU is not that slow:

No -- and something has to be pushed to the video card at some point anyway.

But my experience is that if you need to push the data to the CPU,
that pretty much overwhelms the advantages you get by rendering on the
GPU.

And OpenGL only supports simple primitives -- so it's substantially
more a pain to do something as sole as render a filled polygon, let
alone a spline.

And yes, back In the day, it was faster to render on the video card,
but CPUs have gotten a lot faster, and memory busses not so much.

But whatever, I think we all agree that pushing the transformations to
the GPU is the big win.

-CHB

> in one
> second, you can send hundreds of millions of points on a modern GPU.
> However it would be a bit slow to send large amounts of data at every
> frame.
>
> GPU-based transformations are extremely fast, and you have full
> control on how they're implemented; in the end, it's just arbitrary C
> code that runs on the GPU on a per-vertex or per-pixel basis.

Re: [matplotlib-devel] Kivy backend

[Cyrille R. <cyr...@gm...>]

> Note that with OPenGL in general, its the transforming that buys you
> performance -- when you push brand new data to be rendered, it takes a lot
> of time to push that data to the video card, so drawing the first time
> doesn't buy you much. But if you need to re-render that same data in a
> different view, say zooming in or out, etc, then GL can fly -- if that
> transformation can be done on the GPU.
>
> As far as I understand it, that's what vispy is doing.

Exactly. Note that pushing data on the GPU is not that slow: in one
second, you can send hundreds of millions of points on a modern GPU.
However it would be a bit slow to send large amounts of data at every
frame.

GPU-based transformations are extremely fast, and you have full
control on how they're implemented; in the end, it's just arbitrary C
code that runs on the GPU on a per-vertex or per-pixel basis.

Re: [matplotlib-devel] Kivy backend

[Ryan M. <rm...@gm...>]

On Fri, Mar 13, 2015 at 12:53 PM, Chris Barker <chr...@no...>
wrote:

> On Fri, Mar 13, 2015 at 10:21 AM, Benjamin Root <ben...@ou...> wrote:
>
>>  Probably what I am most interested in from OpenGL is its transforms
>> stack.
>>
>
> OpenGL can't do anything with transforms that you couldn't do in python
> (or C, or Cython). What it can do is push the transform computations to the
> GPU(s) -- making for monstrously faster performance.
>
> This is the "problem" with the current MPL architecture. It does all the
> transforming outside of the back-ends, and assumes that the backends can
> only render in 2-d pixel coordinates.
>
> If we can re-factor to push the transforms to the back-end, most of them
> could use the same generic code, but you'd have the option of the back-end
> providing the transforms, which would buy you a LOT with Open GL, and could
> maybe by you some with, say, wxAgg, as you could put the transforms in
> C/C++ perhaps more efficiently.
>
> Note that with OPenGL in general, its the transforming that buys you
> performance -- when you push brand new data to be rendered, it takes a lot
> of time to push that data to the video card, so drawing the first time
> doesn't buy you much. But if you need to re-render that same data in a
> different view, say zooming in or out, etc, then GL can fly -- if that
> transformation can be done on the GPU.
>
>
Don't overestimate the cost of the data transfer, at least for non-millions
of points. Even years ago, just doing basic opengl plotting (no
sophisticated use of on-GPU memory), was a big win.

The other win for mpl + opengl is giving a real rasterizer and depth buffer
for the mpl3d package, which is hampered by the per-artist z-ordering.

Ryan

-- 
Ryan May

Re: [matplotlib-devel] Kivy backend

[Chris B. <chr...@no...>]

On Fri, Mar 13, 2015 at 10:21 AM, Benjamin Root <ben...@ou...> wrote:

>  Probably what I am most interested in from OpenGL is its transforms stack.
>

OpenGL can't do anything with transforms that you couldn't do in python (or
C, or Cython). What it can do is push the transform computations to the
GPU(s) -- making for monstrously faster performance.

This is the "problem" with the current MPL architecture. It does all the
transforming outside of the back-ends, and assumes that the backends can
only render in 2-d pixel coordinates.

If we can re-factor to push the transforms to the back-end, most of them
could use the same generic code, but you'd have the option of the back-end
providing the transforms, which would buy you a LOT with Open GL, and could
maybe by you some with, say, wxAgg, as you could put the transforms in
C/C++ perhaps more efficiently.

Note that with OPenGL in general, its the transforming that buys you
performance -- when you push brand new data to be rendered, it takes a lot
of time to push that data to the video card, so drawing the first time
doesn't buy you much. But if you need to re-render that same data in a
different view, say zooming in or out, etc, then GL can fly -- if that
transformation can be done on the GPU.

As far as I understand it, that's what vispy is doing.

-CHB








> While matplotlib's transforms stack is fantastic, it is inherently limited
> to 2D operations. Upgrading the transforms stack in some way would be huge
> thing to me.
>
> On Fri, Mar 13, 2015 at 1:08 PM, Nicolas P. Rougier <
> Nic...@in...> wrote:
>
>>
>> It might be difficult to stick to matplotlib architecture and still
>> benefit from OpenGL speed.
>> There are a lot of GL techniques that speed up things a lot but are are
>> not really compatible.
>>
>> For example, isolines, quiver plots, image interpolations and most
>> transformations can be handled directly by the GPU
>> (see http://glumpy.github.io/gallery.html)
>>
>> But we'll try to use matplotlib public api such that things will be
>> mostly transparent for the user
>>
>> Nicolas
>>
>> > On 13 Mar 2015, at 17:33, Benjamin Root <ben...@ou...> wrote:
>> >
>> > +1 on an OpenGL backend! Especially if I can off-load a lot of mplot3d
>> stuff to it! Does vispy have any plans to eventually bring that into
>> mainline matplotlib, or does it break too much with the standard set of
>> backends to make sense in matplotlib (or maybe it is too much of a
>> maintenance/packaging burden?)
>> >
>> > Ben Root
>> >
>> > On Fri, Mar 13, 2015 at 12:12 PM, Cyrille Rossant <
>> cyr...@gm...> wrote:
>> > Kivy is all built on OpenGL, so it would probably be pretty
>> straightforward to generate teh image with AGG, then dump it to the screen
>> as an OpenGL texture. But it would be a bit sad to not take advantage of
>> OpenGL at all in that process. (and getting AGG to work with Kivy may be
>> less than trivial...)
>> >
>> > Note that vector graphics in OpenGL is a serious pain, but maybe Kivy
>> has some stuff to help?
>> >
>> > Also, the MPL back-end structure wasn't designed to push much of the
>> transforming, etc to the back -end, which is too bad, as that's what OpenGL
>> does well.
>> >
>> > But I'd still take a look at the work done to make a real OpenGL
>> back-end -- not sure how far that got, but worth a look.
>> >
>> > Or look at http://vispy.org/ -- and give up in MPL :-( -- or maybe
>> not! form teh vispy docs:
>> >
>> > "Vispy now ships a very basic and experimental OpenGL backend for
>> matplotlib."
>> >
>> >
>> > Yes, and we plan to work on this backend in the next few months. We
>> might have a couple of GSoC students working partly on the OpenGL MPL
>> backend and possibly on Kivy integration.
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> > by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> > things parallel software development, from weekly thought leadership
>> blogs to
>> > news, videos, case studies, tutorials and more. Take a look and join the
>> > conversation now. http://goparallel.sourceforge.net/
>> > _______________________________________________
>> > Matplotlib-devel mailing list
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> > by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> > things parallel software development, from weekly thought leadership
>> blogs to
>> > news, videos, case studies, tutorials and more. Take a look and join the
>> > conversation now.
>> http://goparallel.sourceforge.net/_______________________________________________
>> > Matplotlib-devel mailing list
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

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

Chr...@no...

Re: [matplotlib-devel] Fwd: SciPy 2015 CFP Email 2

[Olga B. <obo...@uc...>]

I'd be very interested in hearing a "state of matplotlib" talk.

On Fri, Mar 13, 2015, 11:29 Phil Elson <pel...@gm...> wrote:

> Orchestrating MPL tutorials and talks in this thread would be a good idea.
> I'd be happy to help anybody planning on submitting anything relating
> specifically to matplotlib, and wonder if we should do a "state of
> matplotlib" type talk similar to the one Mike did 2 years ago.
>
> On 13 March 2015 at 02:05, Benjamin Root <ben...@ou...> wrote:
>
>> Yes, I plan to submit my time-honored, and requested "Anatomy of
>> Matplotlib" tutorial. Now, I am not entirely sure I will be able to attend
>> the conference this year, so perhaps someone else might be willing to step
>> in and give it this year?
>>
>> Note that my tutorial is geared for beginners. So there is still plenty
>> of opportunity for someone else to submit a tutorial for more advanced
>> users!
>>
>> Cheers!
>> Ben Root
>>
>> On Thu, Mar 12, 2015 at 6:46 PM, Nelle Varoquaux <
>> nel...@gm...> wrote:
>>
>>> Hi everyone,
>>>
>>> Is someone submitting a tutorial on matplotlib? The call for tutorial is
>>> open, and I think it would be nice to have one on matplotlib.
>>>
>>> Cheers,
>>> N
>>>
>>> ---------- Forwarded message ----------
>>> From: SciPy 2015 Organizers <sci...@sc...>
>>> Date: 11 March 2015 at 01:02
>>> Subject: SciPy 2015 CFP Email 2
>>> To: nel...@gm...
>>>
>>>
>>>   [image: SciPy 2015 Logo]
>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/index.php%7CQ%7Ceventid%7CE%7C115969%7CA%7C>
>>>
>>>    Tick-Tock, Tick-Tock:
>>> T-Minus 6 Days for Tutorial Submissions
>>>  *Due Date: March 16, 2015*
>>>
>>> The SciPy experience kicks off with two days of tutorials
>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/115969/259288/%7CQ%7C>
>>> (July 6-7). These sessions provide extremely affordable access to expert
>>> training, and consistently receive fantastic feedback from participants.
>>> We're looking for submissions on topics from introductory to advanced -
>>> we'll have attendees across the gamut looking to learn. Plus, you can earn
>>> an instructor stipend to apply towards your conference participation. Visit
>>> the SciPy 2015 website for details
>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org>
>>> or submit a proposal here
>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>
>>> .
>>>
>>>   Submit a Tutorial Proposal Here
>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>     Talk
>>> and Poster Proposals Due April 1st
>>>
>>> There's always something new and exciting going on in the world of
>>> Science + Python, this is your chance to get up and talk about it!
>>>
>>> *Visit the SciPy 2015 website
>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/index.php%7CQ%7Ceventid%7CE%7C115969%7CA%7C>
>>> for full details or click here to submit a proposal
>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>.*
>>> Choose a topic in one of the 3 main conference tracks:
>>>
>>>    - Scientific Computing in Python (General track)
>>>    - Python in Data Science
>>>    - Quantitative and Computational Social Sciences
>>>
>>> * And/or submit for one of the 7 domain-specific mini-symposia
>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>:*
>>>
>>>    - Astronomy and astrophysics
>>>    - Computational life and medical sciences
>>>    - Engineering
>>>    - Geographic information systems (GIS)
>>>    - Geophysics
>>>    - Oceanography and meteorology
>>>    - Visualization, vision and imaging
>>>
>>>   Submit a Talk or Poster Proposal Here
>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>   Need
>>> some inspiration? Follow @SciPy on Twitter
>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=https://twitter.com/scipyconf>
>>> for highlights from previous SciPy conferences and all of the latest 2015
>>> updates.
>>>
>>>    - Previous year's conferences with talk information
>>>    <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://conference.scipy.org/past.html>
>>>     - SciPy 2014 Talk & Tutorial Video playlist
>>>    <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.youtube.com/playlist%7CQ%7Clist%7CE%7CPLYx7XA2nY5GfuhCvStxgbynFNrxr3VFog>
>>>    - SciPy 2013 Talk & Tutorial Video playlist
>>>    <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.youtube.com/playlist%7CQ%7Clist%7CE%7CPLYx7XA2nY5GeTWcUQTbXVdllyp-Ie3r-y>
>>>
>>>   Financial Scholarship Applications Now Being Accepted
>>>
>>> With the support of our sponsors, the SciPy conference provides
>>> financial assistance to attendees based on both community contribution and
>>> financial need.
>>>
>>> In 2014 we were able to support 19 applicants, including 5 diversity aid
>>> recipients, selected for their outstanding contributions to open source
>>> scientific Python projects. *If you'd like to be considered for
>>> financial scholarship, please apply here
>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/115969/259279/?&>
>>> before April 15, 2015.*
>>>   Sponsor Thank Yous! We gratefully recognize our SciPy conference
>>> sponsors, whose contributions ensure the accessibility of the conference
>>> and growth of the important work being done by the scientific Python
>>> community.
>>>
>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=www.kitware.com>
>>>
>>> *This week's sponsor highlight is silver sponsor, Kitware:*
>>> * Kitware, Inc. is a leader in the creation and support of open-source
>>> software and state of the art technology. By fostering extended,
>>> collaborative communities, Kitware is able to provide flexible,
>>> cost-effective visualization, computer vision, medical imaging, data
>>> publishing, and quality software process solutions to a variety of academic
>>> and government institutions and private corporations worldwide.*
>>>
>>> ------------------------------
>>> Know a company that might want to sponsor SciPy 2015 or provide
>>> scholarship funding? Share the sponsorship prospectus
>>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/115969/259285/?&>
>>> --------------------------------------
>>> To unsubscribe from this mailing list, please click here
>>> <https://www.eiseverywhere.com/emarketing/profile.php?id=BctbGJi3EKrTogVy7ttdnrT0TTsw6Zr%2FRzGhBzBXaDM%3D>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Dive into the World of Parallel Programming The Go Parallel Website,
>>> sponsored
>>> by Intel and developed in partnership with Slashdot Media, is your hub
>>> for all
>>> things parallel software development, from weekly thought leadership
>>> blogs to
>>> news, videos, case studies, tutorials and more. Take a look and join the
>>> conversation now. http://goparallel.sourceforge.net/
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
> ------------------------------------------------------------
> ------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] Fwd: SciPy 2015 CFP Email 2

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

Orchestrating MPL tutorials and talks in this thread would be a good idea.
I'd be happy to help anybody planning on submitting anything relating
specifically to matplotlib, and wonder if we should do a "state of
matplotlib" type talk similar to the one Mike did 2 years ago.

On 13 March 2015 at 02:05, Benjamin Root <ben...@ou...> wrote:

> Yes, I plan to submit my time-honored, and requested "Anatomy of
> Matplotlib" tutorial. Now, I am not entirely sure I will be able to attend
> the conference this year, so perhaps someone else might be willing to step
> in and give it this year?
>
> Note that my tutorial is geared for beginners. So there is still plenty of
> opportunity for someone else to submit a tutorial for more advanced users!
>
> Cheers!
> Ben Root
>
> On Thu, Mar 12, 2015 at 6:46 PM, Nelle Varoquaux <
> nel...@gm...> wrote:
>
>> Hi everyone,
>>
>> Is someone submitting a tutorial on matplotlib? The call for tutorial is
>> open, and I think it would be nice to have one on matplotlib.
>>
>> Cheers,
>> N
>>
>> ---------- Forwarded message ----------
>> From: SciPy 2015 Organizers <sci...@sc...>
>> Date: 11 March 2015 at 01:02
>> Subject: SciPy 2015 CFP Email 2
>> To: nel...@gm...
>>
>>
>>   [image: SciPy 2015 Logo]
>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/index.php%7CQ%7Ceventid%7CE%7C115969%7CA%7C>
>>
>>    Tick-Tock, Tick-Tock:
>> T-Minus 6 Days for Tutorial Submissions
>>  *Due Date: March 16, 2015*
>>
>> The SciPy experience kicks off with two days of tutorials
>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/115969/259288/%7CQ%7C>
>> (July 6-7). These sessions provide extremely affordable access to expert
>> training, and consistently receive fantastic feedback from participants.
>> We're looking for submissions on topics from introductory to advanced -
>> we'll have attendees across the gamut looking to learn. Plus, you can earn
>> an instructor stipend to apply towards your conference participation. Visit
>> the SciPy 2015 website for details
>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org>
>> or submit a proposal here
>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>
>> .
>>
>>   Submit a Tutorial Proposal Here
>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>     Talk
>> and Poster Proposals Due April 1st
>>
>> There's always something new and exciting going on in the world of
>> Science + Python, this is your chance to get up and talk about it!
>>
>> *Visit the SciPy 2015 website
>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/index.php%7CQ%7Ceventid%7CE%7C115969%7CA%7C>
>> for full details or click here to submit a proposal
>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>.*
>> Choose a topic in one of the 3 main conference tracks:
>>
>>    - Scientific Computing in Python (General track)
>>    - Python in Data Science
>>    - Quantitative and Computational Social Sciences
>>
>> * And/or submit for one of the 7 domain-specific mini-symposia
>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>:*
>>
>>    - Astronomy and astrophysics
>>    - Computational life and medical sciences
>>    - Engineering
>>    - Geographic information systems (GIS)
>>    - Geophysics
>>    - Oceanography and meteorology
>>    - Visualization, vision and imaging
>>
>>   Submit a Talk or Poster Proposal Here
>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>   Need
>> some inspiration? Follow @SciPy on Twitter
>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=https://twitter.com/scipyconf>
>> for highlights from previous SciPy conferences and all of the latest 2015
>> updates.
>>
>>    - Previous year's conferences with talk information
>>    <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://conference.scipy.org/past.html>
>>     - SciPy 2014 Talk & Tutorial Video playlist
>>    <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.youtube.com/playlist%7CQ%7Clist%7CE%7CPLYx7XA2nY5GfuhCvStxgbynFNrxr3VFog>
>>    - SciPy 2013 Talk & Tutorial Video playlist
>>    <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.youtube.com/playlist%7CQ%7Clist%7CE%7CPLYx7XA2nY5GeTWcUQTbXVdllyp-Ie3r-y>
>>
>>   Financial Scholarship Applications Now Being Accepted
>>
>> With the support of our sponsors, the SciPy conference provides financial
>> assistance to attendees based on both community contribution and financial
>> need.
>>
>> In 2014 we were able to support 19 applicants, including 5 diversity aid
>> recipients, selected for their outstanding contributions to open source
>> scientific Python projects. *If you'd like to be considered for
>> financial scholarship, please apply here
>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/115969/259279/?&>
>> before April 15, 2015.*
>>   Sponsor Thank Yous! We gratefully recognize our SciPy conference
>> sponsors, whose contributions ensure the accessibility of the conference
>> and growth of the important work being done by the scientific Python
>> community.
>>
>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=www.kitware.com>
>>
>> *This week's sponsor highlight is silver sponsor, Kitware:*
>> * Kitware, Inc. is a leader in the creation and support of open-source
>> software and state of the art technology. By fostering extended,
>> collaborative communities, Kitware is able to provide flexible,
>> cost-effective visualization, computer vision, medical imaging, data
>> publishing, and quality software process solutions to a variety of academic
>> and government institutions and private corporations worldwide.*
>>
>> ------------------------------
>> Know a company that might want to sponsor SciPy 2015 or provide
>> scholarship funding? Share the sponsorship prospectus
>> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/115969/259285/?&>
>> --------------------------------------
>> To unsubscribe from this mailing list, please click here
>> <https://www.eiseverywhere.com/emarketing/profile.php?id=BctbGJi3EKrTogVy7ttdnrT0TTsw6Zr%2FRzGhBzBXaDM%3D>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

[matplotlib-devel] [ANN] Cartopy v0.12 release candidate

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

I'm pleased to announce that cartopy v0.12.0rc1 has been tagged.

This release has focused on improving the geometry projection stability,
improving interfaces for data ingestion, rounding
off Python 3 support, and generally improving the breadth of the gallery.
A full overview of what's new in this release can be found at
http://scitools.org.uk/cartopy/docs/v0.12/whats_new.html.

About cartopy
--------------

Cartopy is a Python package designed to make drawing maps for data analysis
and visualisation easy.

It features:

   - object-oriented projection definitions
   - point, line, polygon, vector and image transformations between
   projections
   - integration to expose advanced mapping in matplotlib with a simple and
   intuitive interface
   - powerful vector data handling by integrating shapefile reading with
   Shapely capabilities


Installing cartopy
-----------------

Installation of the release candidate and its dependencies with conda:

*conda install cartopy** --channel scitools/channel/dev*

Installing cartopy using pip requires GEOS and proj4 to be installed prior
to running:

*pip install cartopy*

Thanks to everybody who contributed towards this release,

Best,

Phil Elson
(github: @pelson | twitter: @pypelson)

Re: [matplotlib-devel] Kivy backend

[Cyrille R. <cyr...@gm...>]

2015-03-13 18:21 GMT+01:00 Benjamin Root <ben...@ou...>:

> Quite honestly, I am not all that concerned about speed (at least, I am
> not talking about achieving gaming level performance). I am most concerned
> about compatibility, quality of the image rendering, quality of the text
> rendering, and consistency across platforms. Probably what I am most
> interested in from OpenGL is its transforms stack. While matplotlib's
> transforms stack is fantastic, it is inherently limited to 2D operations.
> Upgrading the transforms stack in some way would be huge thing to me.
>

Modern shader-based OpenGL no longer has transform stacks: we need to
implement GPU transforms ourselves. This is all handled by VisPy, and we
have total control on that architecture. We do want to support 2D and 3D
simultaneously. We are still in the process of designing this architecture
though, and I guess it would certainly make sense for matplotlib devs to be
involved in the discussions...

Re: [matplotlib-devel] Kivy backend

[Nicolas P. R. <Nic...@in...>]

By speed I meant to be able to render "big" plot (like a million point scatter plot or having 10 000 isolines, etc.)

Concerning output quality, I think we're almost done. We have antialiases lines, markers and polygons (equivalent to agg), 2D agg-quality text (same techniques) and 3D decent text quality (see http://glumpy.github.io/_static/screenshots/lorenz.png). It is now a matter of integrating all this together and of course to debug it...

Nicolas



> On 13 Mar 2015, at 18:21, Benjamin Root <ben...@ou...> wrote:
> 
> Quite honestly, I am not all that concerned about speed (at least, I am not talking about achieving gaming level performance). I am most concerned about compatibility, quality of the image rendering, quality of the text rendering, and consistency across platforms. Probably what I am most interested in from OpenGL is its transforms stack. While matplotlib's transforms stack is fantastic, it is inherently limited to 2D operations. Upgrading the transforms stack in some way would be huge thing to me.
> 
> On Fri, Mar 13, 2015 at 1:08 PM, Nicolas P. Rougier <Nic...@in...> wrote:
> 
> It might be difficult to stick to matplotlib architecture and still benefit from OpenGL speed.
> There are a lot of GL techniques that speed up things a lot but are are not really compatible.
> 
> For example, isolines, quiver plots, image interpolations and most transformations can be handled directly by the GPU
> (see http://glumpy.github.io/gallery.html)
> 
> But we'll try to use matplotlib public api such that things will be mostly transparent for the user
> 
> Nicolas
> 
> > On 13 Mar 2015, at 17:33, Benjamin Root <ben...@ou...> wrote:
> >
> > +1 on an OpenGL backend! Especially if I can off-load a lot of mplot3d stuff to it! Does vispy have any plans to eventually bring that into mainline matplotlib, or does it break too much with the standard set of backends to make sense in matplotlib (or maybe it is too much of a maintenance/packaging burden?)
> >
> > Ben Root
> >
> > On Fri, Mar 13, 2015 at 12:12 PM, Cyrille Rossant <cyr...@gm...> wrote:
> > Kivy is all built on OpenGL, so it would probably be pretty straightforward to generate teh image with AGG, then dump it to the screen as an OpenGL texture. But it would be a bit sad to not take advantage of OpenGL at all in that process. (and getting AGG to work with Kivy may be less than trivial...)
> >
> > Note that vector graphics in OpenGL is a serious pain, but maybe Kivy has some stuff to help?
> >
> > Also, the MPL back-end structure wasn't designed to push much of the transforming, etc to the back -end, which is too bad, as that's what OpenGL does well.
> >
> > But I'd still take a look at the work done to make a real OpenGL back-end -- not sure how far that got, but worth a look.
> >
> > Or look at http://vispy.org/ -- and give up in MPL :-( -- or maybe not! form teh vispy docs:
> >
> > "Vispy now ships a very basic and experimental OpenGL backend for matplotlib."
> >
> >
> > Yes, and we plan to work on this backend in the next few months. We might have a couple of GSoC students working partly on the OpenGL MPL backend and possibly on Kivy integration.
> >
> >
> > ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> > by Intel and developed in partnership with Slashdot Media, is your hub for all
> > things parallel software development, from weekly thought leadership blogs to
> > news, videos, case studies, tutorials and more. Take a look and join the
> > conversation now. http://goparallel.sourceforge.net/
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
> > ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> > by Intel and developed in partnership with Slashdot Media, is your hub for all
> > things parallel software development, from weekly thought leadership blogs to
> > news, videos, case studies, tutorials and more. Take a look and join the
> > conversation now. http://goparallel.sourceforge.net/_______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 

Re: [matplotlib-devel] Kivy backend

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

Quite honestly, I am not all that concerned about speed (at least, I am not
talking about achieving gaming level performance). I am most concerned
about compatibility, quality of the image rendering, quality of the text
rendering, and consistency across platforms. Probably what I am most
interested in from OpenGL is its transforms stack. While matplotlib's
transforms stack is fantastic, it is inherently limited to 2D operations.
Upgrading the transforms stack in some way would be huge thing to me.

On Fri, Mar 13, 2015 at 1:08 PM, Nicolas P. Rougier <
Nic...@in...> wrote:

>
> It might be difficult to stick to matplotlib architecture and still
> benefit from OpenGL speed.
> There are a lot of GL techniques that speed up things a lot but are are
> not really compatible.
>
> For example, isolines, quiver plots, image interpolations and most
> transformations can be handled directly by the GPU
> (see http://glumpy.github.io/gallery.html)
>
> But we'll try to use matplotlib public api such that things will be mostly
> transparent for the user
>
> Nicolas
>
> > On 13 Mar 2015, at 17:33, Benjamin Root <ben...@ou...> wrote:
> >
> > +1 on an OpenGL backend! Especially if I can off-load a lot of mplot3d
> stuff to it! Does vispy have any plans to eventually bring that into
> mainline matplotlib, or does it break too much with the standard set of
> backends to make sense in matplotlib (or maybe it is too much of a
> maintenance/packaging burden?)
> >
> > Ben Root
> >
> > On Fri, Mar 13, 2015 at 12:12 PM, Cyrille Rossant <
> cyr...@gm...> wrote:
> > Kivy is all built on OpenGL, so it would probably be pretty
> straightforward to generate teh image with AGG, then dump it to the screen
> as an OpenGL texture. But it would be a bit sad to not take advantage of
> OpenGL at all in that process. (and getting AGG to work with Kivy may be
> less than trivial...)
> >
> > Note that vector graphics in OpenGL is a serious pain, but maybe Kivy
> has some stuff to help?
> >
> > Also, the MPL back-end structure wasn't designed to push much of the
> transforming, etc to the back -end, which is too bad, as that's what OpenGL
> does well.
> >
> > But I'd still take a look at the work done to make a real OpenGL
> back-end -- not sure how far that got, but worth a look.
> >
> > Or look at http://vispy.org/ -- and give up in MPL :-( -- or maybe not!
> form teh vispy docs:
> >
> > "Vispy now ships a very basic and experimental OpenGL backend for
> matplotlib."
> >
> >
> > Yes, and we plan to work on this backend in the next few months. We
> might have a couple of GSoC students working partly on the OpenGL MPL
> backend and possibly on Kivy integration.
> >
> >
> >
> ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> > by Intel and developed in partnership with Slashdot Media, is your hub
> for all
> > things parallel software development, from weekly thought leadership
> blogs to
> > news, videos, case studies, tutorials and more. Take a look and join the
> > conversation now. http://goparallel.sourceforge.net/
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
> >
> ------------------------------------------------------------------------------
> > Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> > by Intel and developed in partnership with Slashdot Media, is your hub
> for all
> > things parallel software development, from weekly thought leadership
> blogs to
> > news, videos, case studies, tutorials and more. Take a look and join the
> > conversation now.
> http://goparallel.sourceforge.net/_______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Re: [matplotlib-devel] Kivy backend

[Thomas C. <tca...@gm...>]

MEP 25 is working towards providing a way to serialize the contents of a
figure in a more controlled way.  The main target of this is
saving/reopening figures and export to bokeh/plotly/d3, but I think this
would also work well for exporting everything off to an opengl backend.

Tom

On Fri, Mar 13, 2015 at 1:09 PM Nicolas P. Rougier <Nic...@in...>
wrote:

>
> It might be difficult to stick to matplotlib architecture and still
> benefit from OpenGL speed.
> There are a lot of GL techniques that speed up things a lot but are are
> not really compatible.
>
> For example, isolines, quiver plots, image interpolations and most
> transformations can be handled directly by the GPU
> (see http://glumpy.github.io/gallery.html)
>
> But we'll try to use matplotlib public api such that things will be mostly
> transparent for the user
>
> Nicolas
>
> > On 13 Mar 2015, at 17:33, Benjamin Root <ben...@ou...> wrote:
> >
> > +1 on an OpenGL backend! Especially if I can off-load a lot of mplot3d
> stuff to it! Does vispy have any plans to eventually bring that into
> mainline matplotlib, or does it break too much with the standard set of
> backends to make sense in matplotlib (or maybe it is too much of a
> maintenance/packaging burden?)
> >
> > Ben Root
> >
> > On Fri, Mar 13, 2015 at 12:12 PM, Cyrille Rossant <
> cyr...@gm...> wrote:
> > Kivy is all built on OpenGL, so it would probably be pretty
> straightforward to generate teh image with AGG, then dump it to the screen
> as an OpenGL texture. But it would be a bit sad to not take advantage of
> OpenGL at all in that process. (and getting AGG to work with Kivy may be
> less than trivial...)
> >
> > Note that vector graphics in OpenGL is a serious pain, but maybe Kivy
> has some stuff to help?
> >
> > Also, the MPL back-end structure wasn't designed to push much of the
> transforming, etc to the back -end, which is too bad, as that's what OpenGL
> does well.
> >
> > But I'd still take a look at the work done to make a real OpenGL
> back-end -- not sure how far that got, but worth a look.
> >
> > Or look at http://vispy.org/ -- and give up in MPL :-( -- or maybe not!
> form teh vispy docs:
> >
> > "Vispy now ships a very basic and experimental OpenGL backend for
> matplotlib."
> >
> >
> > Yes, and we plan to work on this backend in the next few months. We
> might have a couple of GSoC students working partly on the OpenGL MPL
> backend and possibly on Kivy integration.
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> > by Intel and developed in partnership with Slashdot Media, is your hub
> for all
> > things parallel software development, from weekly thought leadership
> blogs to
> > news, videos, case studies, tutorials and more. Take a look and join the
> > conversation now. http://goparallel.sourceforge.net/
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> > by Intel and developed in partnership with Slashdot Media, is your hub
> for all
> > things parallel software development, from weekly thought leadership
> blogs to
> > news, videos, case studies, tutorials and more. Take a look and join the
> > conversation now. http://goparallel.sourceforge.
> net/_______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> ------------------------------------------------------------
> ------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] Kivy backend

[Nicolas P. R. <Nic...@in...>]

It might be difficult to stick to matplotlib architecture and still benefit from OpenGL speed.
There are a lot of GL techniques that speed up things a lot but are are not really compatible.

For example, isolines, quiver plots, image interpolations and most transformations can be handled directly by the GPU
(see http://glumpy.github.io/gallery.html)

But we'll try to use matplotlib public api such that things will be mostly transparent for the user

Nicolas

> On 13 Mar 2015, at 17:33, Benjamin Root <ben...@ou...> wrote:
> 
> +1 on an OpenGL backend! Especially if I can off-load a lot of mplot3d stuff to it! Does vispy have any plans to eventually bring that into mainline matplotlib, or does it break too much with the standard set of backends to make sense in matplotlib (or maybe it is too much of a maintenance/packaging burden?)
> 
> Ben Root
> 
> On Fri, Mar 13, 2015 at 12:12 PM, Cyrille Rossant <cyr...@gm...> wrote:
> Kivy is all built on OpenGL, so it would probably be pretty straightforward to generate teh image with AGG, then dump it to the screen as an OpenGL texture. But it would be a bit sad to not take advantage of OpenGL at all in that process. (and getting AGG to work with Kivy may be less than trivial...)
> 
> Note that vector graphics in OpenGL is a serious pain, but maybe Kivy has some stuff to help?
> 
> Also, the MPL back-end structure wasn't designed to push much of the transforming, etc to the back -end, which is too bad, as that's what OpenGL does well.
> 
> But I'd still take a look at the work done to make a real OpenGL back-end -- not sure how far that got, but worth a look.
> 
> Or look at http://vispy.org/ -- and give up in MPL :-( -- or maybe not! form teh vispy docs: 
> 
> "Vispy now ships a very basic and experimental OpenGL backend for matplotlib."
> 
> 
> Yes, and we plan to work on this backend in the next few months. We might have a couple of GSoC students working partly on the OpenGL MPL backend and possibly on Kivy integration. 
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/_______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Kivy backend

[Cyrille R. <cyr...@gm...>]

I don't think it would work like the other backends. Last time I checked,
the MPL backend system would not let us achieve high performance. Currently
we use Jake Vanderplas' mplexporter system that was developed for mpld3.

Eventually, I guess we could expose the same interface as mpld3, i.e.
replace `plt.show()` by something like `vispy.show()`. This would display a
matplotlib figure with VisPy (which supports Qt, wx, and other GUI
toolkits) instead of one of matplotlib's backends. In the notebook,
something like `vispy.enable_notebook()` could replace matplotlib's inline
PNG by a dynamic WebGL canvas.

2015-03-13 17:33 GMT+01:00 Benjamin Root <ben...@ou...>:

> +1 on an OpenGL backend! Especially if I can off-load a lot of mplot3d
> stuff to it! Does vispy have any plans to eventually bring that into
> mainline matplotlib, or does it break too much with the standard set of
> backends to make sense in matplotlib (or maybe it is too much of a
> maintenance/packaging burden?)
>
> Ben Root
>
> On Fri, Mar 13, 2015 at 12:12 PM, Cyrille Rossant <
> cyr...@gm...> wrote:
>
>> Kivy is all built on OpenGL, so it would probably be pretty
>>> straightforward to generate teh image with AGG, then dump it to the screen
>>> as an OpenGL texture. But it would be a bit sad to not take advantage of
>>> OpenGL at all in that process. (and getting AGG to work with Kivy may be
>>> less than trivial...)
>>>
>>> Note that vector graphics in OpenGL is a serious pain, but maybe Kivy
>>> has some stuff to help?
>>>
>>> Also, the MPL back-end structure wasn't designed to push much of the
>>> transforming, etc to the back -end, which is too bad, as that's what OpenGL
>>> does well.
>>>
>>> But I'd still take a look at the work done to make a real OpenGL
>>> back-end -- not sure how far that got, but worth a look.
>>>
>>> Or look at http://vispy.org/ -- and give up in MPL :-( -- or maybe not!
>>> form teh vispy docs:
>>>
>>> "Vispy now ships a very basic and experimental OpenGL backend for
>>> matplotlib."
>>>
>>>
>> Yes, and we plan to work on this backend in the next few months. We might
>> have a couple of GSoC students working partly on the OpenGL MPL backend and
>> possibly on Kivy integration.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>

Re: [matplotlib-devel] Kivy backend

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

+1 on an OpenGL backend! Especially if I can off-load a lot of mplot3d
stuff to it! Does vispy have any plans to eventually bring that into
mainline matplotlib, or does it break too much with the standard set of
backends to make sense in matplotlib (or maybe it is too much of a
maintenance/packaging burden?)

Ben Root

On Fri, Mar 13, 2015 at 12:12 PM, Cyrille Rossant <cyr...@gm...
> wrote:

> Kivy is all built on OpenGL, so it would probably be pretty
>> straightforward to generate teh image with AGG, then dump it to the screen
>> as an OpenGL texture. But it would be a bit sad to not take advantage of
>> OpenGL at all in that process. (and getting AGG to work with Kivy may be
>> less than trivial...)
>>
>> Note that vector graphics in OpenGL is a serious pain, but maybe Kivy has
>> some stuff to help?
>>
>> Also, the MPL back-end structure wasn't designed to push much of the
>> transforming, etc to the back -end, which is too bad, as that's what OpenGL
>> does well.
>>
>> But I'd still take a look at the work done to make a real OpenGL back-end
>> -- not sure how far that got, but worth a look.
>>
>> Or look at http://vispy.org/ -- and give up in MPL :-( -- or maybe not!
>> form teh vispy docs:
>>
>> "Vispy now ships a very basic and experimental OpenGL backend for
>> matplotlib."
>>
>>
> Yes, and we plan to work on this backend in the next few months. We might
> have a couple of GSoC students working partly on the OpenGL MPL backend and
> possibly on Kivy integration.
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Re: [matplotlib-devel] Kivy backend

[Cyrille R. <cyr...@gm...>]

>
> Kivy is all built on OpenGL, so it would probably be pretty
> straightforward to generate teh image with AGG, then dump it to the screen
> as an OpenGL texture. But it would be a bit sad to not take advantage of
> OpenGL at all in that process. (and getting AGG to work with Kivy may be
> less than trivial...)
>
> Note that vector graphics in OpenGL is a serious pain, but maybe Kivy has
> some stuff to help?
>
> Also, the MPL back-end structure wasn't designed to push much of the
> transforming, etc to the back -end, which is too bad, as that's what OpenGL
> does well.
>
> But I'd still take a look at the work done to make a real OpenGL back-end
> -- not sure how far that got, but worth a look.
>
> Or look at http://vispy.org/ -- and give up in MPL :-( -- or maybe not!
> form teh vispy docs:
>
> "Vispy now ships a very basic and experimental OpenGL backend for
> matplotlib."
>
>
Yes, and we plan to work on this backend in the next few months. We might
have a couple of GSoC students working partly on the OpenGL MPL backend and
possibly on Kivy integration.

Re: [matplotlib-devel] Kivy backend

[Chris B. <chr...@no...>]

On Sat, Mar 7, 2015 at 4:17 PM, Thomas Caswell <tca...@gm...> wrote:

> Thank your for your interest, mpl on touch devices sounds super cool!
>

Indeed!


> The easiest course is probably to develop a backend modeled after the
> {qt,wx,gtk}Agg backends which embed an Agg backend into the gui framework
> of choice.  In those cases we rely on Agg to handle the mpl specific
> drawing tasks and then embed the resulting bitmap into the GUI.
>

Kivy is all built on OpenGL, so it would probably be pretty straightforward
to generate teh image with AGG, then dump it to the screen as an OpenGL
texture. But it would be a bit sad to not take advantage of OpenGL at all
in that process. (and getting AGG to work with Kivy may be less than
trivial...)

Note that vector graphics in OpenGL is a serious pain, but maybe Kivy has
some stuff to help?

Also, the MPL back-end structure wasn't designed to push much of the
transforming, etc to the back -end, which is too bad, as that's what OpenGL
does well.

But I'd still take a look at the work done to make a real OpenGL back-end
-- not sure how far that got, but worth a look.

Or look at http://vispy.org/ -- and give up in MPL :-( -- or maybe not!
form teh vispy docs:

"Vispy now ships a very basic and experimental OpenGL backend for
matplotlib."

HTH,
  -Chris







> A majority of the work in the gui backends deals window/widget creation
> and the plumbing required to convert interaction events from the GUI into
> the internal events mpl uses.
>
> Tom
>
> On Sat, Mar 7, 2015 at 4:15 PM Achyut Rastogi <ras...@gm...>
> wrote:
>
>> Hello , I am a novice gsoc aspirant and I want to write a backend for
>> kivy, I read some of the other conversations on the mailing list and I know
>> about the template you guys provide but I am having trouble getting
>> started, can you please help me get up-to speed. I would be great help if
>> you could tell me what all I need to know of matplotlib  to write a good
>> backend.
>> Thank You
>> Achyut Rastogi
>> ------------------------------------------------------------
>> ------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

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

Chr...@no...

Re: [matplotlib-devel] Fwd: SciPy 2015 CFP Email 2

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

Yes, I plan to submit my time-honored, and requested "Anatomy of
Matplotlib" tutorial. Now, I am not entirely sure I will be able to attend
the conference this year, so perhaps someone else might be willing to step
in and give it this year?

Note that my tutorial is geared for beginners. So there is still plenty of
opportunity for someone else to submit a tutorial for more advanced users!

Cheers!
Ben Root

On Thu, Mar 12, 2015 at 6:46 PM, Nelle Varoquaux <nel...@gm...>
wrote:

> Hi everyone,
>
> Is someone submitting a tutorial on matplotlib? The call for tutorial is
> open, and I think it would be nice to have one on matplotlib.
>
> Cheers,
> N
>
> ---------- Forwarded message ----------
> From: SciPy 2015 Organizers <sci...@sc...>
> Date: 11 March 2015 at 01:02
> Subject: SciPy 2015 CFP Email 2
> To: nel...@gm...
>
>
>   [image: SciPy 2015 Logo]
> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/index.php%7CQ%7Ceventid%7CE%7C115969%7CA%7C>
>
>    Tick-Tock, Tick-Tock:
> T-Minus 6 Days for Tutorial Submissions
>  *Due Date: March 16, 2015*
>
> The SciPy experience kicks off with two days of tutorials
> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/115969/259288/%7CQ%7C>
> (July 6-7). These sessions provide extremely affordable access to expert
> training, and consistently receive fantastic feedback from participants.
> We're looking for submissions on topics from introductory to advanced -
> we'll have attendees across the gamut looking to learn. Plus, you can earn
> an instructor stipend to apply towards your conference participation. Visit
> the SciPy 2015 website for details
> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org>
> or submit a proposal here
> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>
> .
>
>   Submit a Tutorial Proposal Here
> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>     Talk
> and Poster Proposals Due April 1st
>
> There's always something new and exciting going on in the world of Science
> + Python, this is your chance to get up and talk about it!
>
> *Visit the SciPy 2015 website
> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/index.php%7CQ%7Ceventid%7CE%7C115969%7CA%7C>
> for full details or click here to submit a proposal
> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>.*
> Choose a topic in one of the 3 main conference tracks:
>
>    - Scientific Computing in Python (General track)
>    - Python in Data Science
>    - Quantitative and Computational Social Sciences
>
> * And/or submit for one of the 7 domain-specific mini-symposia
> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>:*
>
>    - Astronomy and astrophysics
>    - Computational life and medical sciences
>    - Engineering
>    - Geographic information systems (GIS)
>    - Geophysics
>    - Oceanography and meteorology
>    - Visualization, vision and imaging
>
>   Submit a Talk or Poster Proposal Here
> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>   Need
> some inspiration? Follow @SciPy on Twitter
> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=https://twitter.com/scipyconf>
> for highlights from previous SciPy conferences and all of the latest 2015
> updates.
>
>    - Previous year's conferences with talk information
>    <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://conference.scipy.org/past.html>
>     - SciPy 2014 Talk & Tutorial Video playlist
>    <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.youtube.com/playlist%7CQ%7Clist%7CE%7CPLYx7XA2nY5GfuhCvStxgbynFNrxr3VFog>
>    - SciPy 2013 Talk & Tutorial Video playlist
>    <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.youtube.com/playlist%7CQ%7Clist%7CE%7CPLYx7XA2nY5GeTWcUQTbXVdllyp-Ie3r-y>
>
>   Financial Scholarship Applications Now Being Accepted
>
> With the support of our sponsors, the SciPy conference provides financial
> assistance to attendees based on both community contribution and financial
> need.
>
> In 2014 we were able to support 19 applicants, including 5 diversity aid
> recipients, selected for their outstanding contributions to open source
> scientific Python projects. *If you'd like to be considered for financial
> scholarship, please apply here
> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/115969/259279/?&>
> before April 15, 2015.*
>   Sponsor Thank Yous! We gratefully recognize our SciPy conference
> sponsors, whose contributions ensure the accessibility of the conference
> and growth of the important work being done by the scientific Python
> community.
>
> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=www.kitware.com>
>
> *This week's sponsor highlight is silver sponsor, Kitware:*
> * Kitware, Inc. is a leader in the creation and support of open-source
> software and state of the art technology. By fostering extended,
> collaborative communities, Kitware is able to provide flexible,
> cost-effective visualization, computer vision, medical imaging, data
> publishing, and quality software process solutions to a variety of academic
> and government institutions and private corporations worldwide.*
>
> ------------------------------
> Know a company that might want to sponsor SciPy 2015 or provide
> scholarship funding? Share the sponsorship prospectus
> <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/115969/259285/?&>
> --------------------------------------
> To unsubscribe from this mailing list, please click here
> <https://www.eiseverywhere.com/emarketing/profile.php?id=BctbGJi3EKrTogVy7ttdnrT0TTsw6Zr%2FRzGhBzBXaDM%3D>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

[matplotlib-devel] Fwd: SciPy 2015 CFP Email 2

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

Hi everyone,

Is someone submitting a tutorial on matplotlib? The call for tutorial is
open, and I think it would be nice to have one on matplotlib.

Cheers,
N

---------- Forwarded message ----------
From: SciPy 2015 Organizers <sci...@sc...>
Date: 11 March 2015 at 01:02
Subject: SciPy 2015 CFP Email 2
To: nel...@gm...


  [image: SciPy 2015 Logo]
<https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/index.php%7CQ%7Ceventid%7CE%7C115969%7CA%7C>

   Tick-Tock, Tick-Tock:
T-Minus 6 Days for Tutorial Submissions
 *Due Date: March 16, 2015*

The SciPy experience kicks off with two days of tutorials
<https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/115969/259288/%7CQ%7C>
(July 6-7). These sessions provide extremely affordable access to expert
training, and consistently receive fantastic feedback from participants.
We're looking for submissions on topics from introductory to advanced -
we'll have attendees across the gamut looking to learn. Plus, you can earn
an instructor stipend to apply towards your conference participation. Visit
the SciPy 2015 website for details
<https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org>
or submit a proposal here
<https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>
.

  Submit a Tutorial Proposal Here
<https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>
    Talk
and Poster Proposals Due April 1st

There's always something new and exciting going on in the world of Science
+ Python, this is your chance to get up and talk about it!

*Visit the SciPy 2015 website
<https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/index.php%7CQ%7Ceventid%7CE%7C115969%7CA%7C>
for full details or click here to submit a proposal
<https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>.*
Choose a topic in one of the 3 main conference tracks:

   - Scientific Computing in Python (General track)
   - Python in Data Science
   - Quantitative and Computational Social Sciences

* And/or submit for one of the 7 domain-specific mini-symposia
<https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>:*

   - Astronomy and astrophysics
   - Computational life and medical sciences
   - Engineering
   - Geographic information systems (GIS)
   - Geophysics
   - Oceanography and meteorology
   - Visualization, vision and imaging

  Submit a Talk or Poster Proposal Here
<https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969>
  Need
some inspiration? Follow @SciPy on Twitter
<https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=https://twitter.com/scipyconf>
for highlights from previous SciPy conferences and all of the latest 2015
updates.

   - Previous year's conferences with talk information
   <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://conference.scipy.org/past.html>
    - SciPy 2014 Talk & Tutorial Video playlist
   <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.youtube.com/playlist%7CQ%7Clist%7CE%7CPLYx7XA2nY5GfuhCvStxgbynFNrxr3VFog>
   - SciPy 2013 Talk & Tutorial Video playlist
   <https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://www.youtube.com/playlist%7CQ%7Clist%7CE%7CPLYx7XA2nY5GeTWcUQTbXVdllyp-Ie3r-y>

  Financial Scholarship Applications Now Being Accepted

With the support of our sponsors, the SciPy conference provides financial
assistance to attendees based on both community contribution and financial
need.

In 2014 we were able to support 19 applicants, including 5 diversity aid
recipients, selected for their outstanding contributions to open source
scientific Python projects. *If you'd like to be considered for financial
scholarship, please apply here
<https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/115969/259279/?&>
before April 15, 2015.*
  Sponsor Thank Yous! We gratefully recognize our SciPy conference
sponsors, whose contributions ensure the accessibility of the conference
and growth of the important work being done by the scientific Python
community.

<https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=www.kitware.com>

*This week's sponsor highlight is silver sponsor, Kitware:*
* Kitware, Inc. is a leader in the creation and support of open-source
software and state of the art technology. By fostering extended,
collaborative communities, Kitware is able to provide flexible,
cost-effective visualization, computer vision, medical imaging, data
publishing, and quality software process solutions to a variety of academic
and government institutions and private corporations worldwide.*

------------------------------
Know a company that might want to sponsor SciPy 2015 or provide scholarship
funding? Share the sponsorship prospectus
<https://www.eiseverywhere.com/emarketing/go.php?i=182077&e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==&l=http://scipy2015.scipy.org/ehome/115969/259285/?&>
--------------------------------------
To unsubscribe from this mailing list, please click here
<https://www.eiseverywhere.com/emarketing/profile.php?id=BctbGJi3EKrTogVy7ttdnrT0TTsw6Zr%2FRzGhBzBXaDM%3D>

Re: [matplotlib-devel] Kivy backend

[Achyut R. <ras...@gm...>]

Thanks OceanWolf

On Tue, Mar 10, 2015 at 3:13 PM, OceanWolf <jui...@ya...>
wrote:

> One thing to note, that the backend structure will hopefully change soon
> with a huge refactor of the backends.
>
> Take a look https://github.com/matplotlib/matplotlib/pull/4143 for the
> current progress and feel free to give your comments.
>
> As a status update, I currently work on the WebAgg backend (which of the
> backends I have converted, seems the most obfuscated of them all) and
> have just finished reading through, and marking up the code with TODOs
> ready for refactor of that backend.  I will also update the MEP page to
> flesh out parts that I feel need more detail.
>
> Best,
> OceanWolf
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] Histogram normalization and overflow bins

[OceanWolf <jui...@ya...>]

Yes, you have almost got what I want.  I know of both line comments in 
the pull interface, and raising DeprecationWarnings.  The problem with 
the warnings that they only want to get used when you have an alternate 
in place and want to remove old code soon.  The problem here lies in not 
knowing how long the life-cycle will last for an indeterminate amount of 
time, such as numpy-1.5 here, or python-2.7.  Lots of such items can 
stack up, and easily get forgotten about, as we see here.

On 10/03/15 17:12, Paul Hobson wrote:
> You can comment on specific lines of code in the pull request 
> interface, but that's not what I think you're describing. A better 
> practice, IMO is to raise a DeprecationWarning when the 
> soon-to-be-removed code is executed. Then you can just grep for those 
> and get cracking.
> -p
>
> On Tue, Mar 10, 2015 at 8:51 AM OceanWolf 
> <jui...@ya... <mailto:jui...@ya...>> 
> wrote:
>
>     Slightly off-topic, does github allow for one to tag lines/code-blocks
>     with notes to the future like ``numpy1.5 removal'', similar to
>     tags for
>     issues and milestones?  This would save us from trawling through the
>     code looking for comments.  If github does not have this feature,
>     do you
>     think github would add that as a feature if asked?
>
>     ------------------------------------------------------------------------------
>     Dive into the World of Parallel Programming The Go Parallel
>     Website, sponsored
>     by Intel and developed in partnership with Slashdot Media, is your
>     hub for all
>     things parallel software development, from weekly thought
>     leadership blogs to
>     news, videos, case studies, tutorials and more. Take a look and
>     join the
>     conversation now. http://goparallel.sourceforge.net/
>     _______________________________________________
>     Matplotlib-devel mailing list
>     Mat...@li...
>     <mailto:Mat...@li...>
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] Histogram normalization and overflow bins

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

You can comment on specific lines of code in the pull request interface,
but that's not what I think you're describing. A better practice, IMO is to
raise a DeprecationWarning when the soon-to-be-removed code is executed.
Then you can just grep for those and get cracking.
-p

On Tue, Mar 10, 2015 at 8:51 AM OceanWolf <jui...@ya...>
wrote:

> Slightly off-topic, does github allow for one to tag lines/code-blocks
> with notes to the future like ``numpy1.5 removal'', similar to tags for
> issues and milestones?  This would save us from trawling through the
> code looking for comments.  If github does not have this feature, do you
> think github would add that as a feature if asked?
>
> ------------------------------------------------------------
> ------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] Histogram normalization and overflow bins

[OceanWolf <jui...@ya...>]

Slightly off-topic, does github allow for one to tag lines/code-blocks 
with notes to the future like ``numpy1.5 removal'', similar to tags for 
issues and milestones?  This would save us from trawling through the 
code looking for comments.  If github does not have this feature, do you 
think github would add that as a feature if asked?