Re: [matplotlib-devel] Make matplotlib running on GPU/CUDA

[Thomas Caswell]

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

> On Wed, Sep 13, 2017 at 12:31 AM, Francesco Faccenda <
> f.faccend...@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(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] backport bot

[Thomas Caswell]

Folks,

Matthias as just helped us to install the meeseeks bot than ipython /
jupyter is using to help with their backporting onto matplotlib.

For details, see https://github.com/MeeseeksBox/MeeseeksDev .

The most important command is

@MeeseeksDev backport [to] {branch}

to automatically open a PR with the backport against the correct branch.

Currently the bot will only respond to:

'tacaswell',
'QuLogic',
'anntzer',
'NelleV',
'dstansby',
'efiring',
'choldgraf'

We will open this up more as we sort out if we like this and how to use it.


Tom
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] documentation error at https://matplotlib.org/api/colorbar_api.html

[Thomas Caswell]

That wording is unclear.  Could you open a PR on github to fix that?  For
small wording changes like this you can do it through the github web
interface.

Tom

On Mon, Jul 31, 2017 at 6:52 AM  wrote:

> "*shrink* 1.0; fraction by which to shrink the colorbar"
>
>
> should be something like
>
>
> "*shrink* 1.0; fraction by which to scale the size size of the colorbar"
>
>
> since the original wording implies that a bigger shrink causes
> a smaller size.
>
>
>
> Keith
>
>
>
>
>
> --
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] this weeks phone call

[Thomas Caswell]

Folks,

Sorry for the late notice.  This weeks call have been moved to today at the
normal time (1500 EDT).

Tom
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Lists moved to python.org reminder

[Thomas Caswell]

We have moved our mailing lists hosting to python.org, the source-forge
lists should no longer be used.

The new lists are

matplotlib-de...@python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel
matplotlib-us...@python.org
https://mail.python.org/mailman/listinfo/matplotlib-users
matplotlib-annou...@python.org
https://mail.python.org/mailman/listinfo/matplotlib-announce

To unsubscribe from the current lists see
http://www.list.org/mailman-member/node14.html

The auto-responders on the source-forge lists have been set to be more
aggressive.

Tom
--
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib 1.5.1 closed path in draw_path when it is not necessary closed

[Thomas Caswell]

Did you mean 1.4.1 instead of 1.5.1 ?

Exactly which paths are you looking at and how are you generating then on
the mpl side? We have many ways to generate the paths and there maybe
inconsistence in how closed paths are handled.

Tom

On Wed, Aug 12, 2015, 1:57 PM Andrés Vargas andno...@gmail.com wrote:

 Hello,

 My name is Andres I am developing a backend for kivy. I was initially
 developing for 1.5.1 and I found that the paths are coming with the initial
 vertex at the end of the list. Does anyone know whether this is change in
 the way paths are sent ? and how can be fixed coming from 1.4.3 since I am
 developing the backend for that version.

 Thanks, Andres

 --
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Cool useage of mpl + seaborn

[Thomas Caswell]

One of my co-workers brought this to my attention:

http://savvastjortjoglou.com/nba-shot-sharts.html

Tom
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] handling labeled data

[Thomas Caswell]

Hey all,

Everyone should be aware of
https://github.com/matplotlib/matplotlib/pull/4787 which is both a very
simple, but very important change to the mpl API by providing a minimal API
to pass labeled data (that is anything that `foo[key]` return an array-like
object) into mpl plotting functions.

This is due to Fernando and Brian's persuasive case to the importance of
starting to address labeled data in mpl and it is now or in 6-9 months

The general approach follows R / seaborn / panadas and allows users to pass
in a `data` kwarg which if present, any data fields which are strings are
replaced by a call to `data[key]`.  In code

   ax.plot(labeled_data['a'], labeled_data['b'])

and

  ax.plot('a', 'b', data=labeled_data)

are equivalent.

This is the minimal change to get quality of life for users who work with
labeled data at the repl and to put a flag in the sand for the API that
down stream projects should be targeting.

Major changes to what the plotting functions do (inferring labels,
inferring what computation to do etc) are out of scope for _this_ PR which
I want to see included in 1.5.  What a higher-level API which can make use
of the additional meta-data available looks like is a much larger
discussion which will must have input from all of the stake holders (ex
IPython, pandas, bokeh, seaborn, xray).

Tom
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] build problem with current doc (about colormap) ?

[Thomas Caswell]

This should be fixed now, Thanks for reporting this!

Tom

On Fri, Jul 24, 2015 at 10:06 AM Thomas Caswell tcasw...@gmail.com wrote:

 Sorry, i must have broken that when I updated the docs to have the banner,
 i will look into fixing it asap.

 Tom

 On Fri, Jul 24, 2015, 7:04 AM Pierre Haessig pierre.haes...@crans.org
 wrote:

 Le 24/07/2015 15:10, Jens Nielsen a écrit :
  In the mean time you can use the development version of the docs up
  here: http://matplotlib.org/devdocs/users/colormaps.html that contains
  the plots.

 thanks !

 --
 Pierre



 --
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] build problem with current doc (about colormap) ?

[Thomas Caswell]

Sorry, i must have broken that when I updated the docs to have the banner,
i will look into fixing it asap.

Tom

On Fri, Jul 24, 2015, 7:04 AM Pierre Haessig pierre.haes...@crans.org
wrote:

 Le 24/07/2015 15:10, Jens Nielsen a écrit :
  In the mean time you can use the development version of the docs up
  here: http://matplotlib.org/devdocs/users/colormaps.html that contains
  the plots.

 thanks !

 --
 Pierre



 --
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [matplotlib] Replace jet as the default colormap (#875)

[Thomas Caswell]

There is a discussion over names happening in a scikit-image PR thread (
https://github.com/scikit-image/scikit-image/pull/1599)

There is a proposal for naming options A-C as {'ignis', 'ortus', 'fyrian'}
in some order.

Commenting here and copying the devel list so it gets some visibility.


On Wed, Jul 15, 2015 at 11:56 AM Nathaniel J. Smith 
notificati...@github.com wrote:

 Yep, that's the plan.

 On Wed, Jul 15, 2015 at 3:22 AM, Werner Beroux notificati...@github.com
 wrote:

  Would be nice to add also some of the alternatives on
  http://bids.github.io/colormap/ to matplotlib.
 
  —
  Reply to this email directly or view it on GitHub
  
 https://github.com/matplotlib/matplotlib/issues/875#issuecomment-121526766
 
  .
 



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

 —
 Reply to this email directly or view it on GitHub
 https://github.com/matplotlib/matplotlib/issues/875#issuecomment-121660178
 .

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] Call for new style defaults

[Thomas Caswell]

See around https://youtu.be/xAoljeRJ3lU?t=1010 for the break down in the
voting.

All four of the color maps will be included in 1.5 your default is
configurable via matplotlibrc, `rcParams` or `mpl.style.use`.

I do not think further (meta-)discussion of the new default color map is
productive.

Tom

Note: I have trimmed the

On Mon, Jul 13, 2015 at 4:54 AM Philipp A. flying-sh...@web.de wrote:

 Thomas Caswell tcasw...@gmail.com schrieb am So., 12. Juli 2015 um
 18:21 Uhr:

 The new default color map will be 'viridis' (aka option D).


 hi,

 how did you get to that decision?

 from at cursory glance at the opinions thread there didn’t seem to be a
 majority for option D as opposed to A, B, and C.

 A, B, and C were variations on a theme, so a fair vote would be ABC or D,
 and then if applicable a second one to decide which variation of ABC to use.

 best, philipp

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Call for new style defaults

[Thomas Caswell]

Hello all,

Following much discussion, we are changing the default color map and styles
in the upcoming 2.0 release!

The new default color map will be 'viridis' (aka option D).  I recommend
everyone watch Nathaniel Smith and Stéfan van der Walt's talk from
SciPy2015 introducing the new color map and providing an introduction to
the math of color perception: https://www.youtube.com/watch?v=xAoljeRJ3lU

We are soliciting proposals to change any and all other visual defaults
(including adding new rcParams as needed).

If you have a proposal please create a PR or issue with the changes to
`rcsetup.py` and `matplotlibrc.template` implementing the changes by August
9, 2015 (1 month from now). Do not worry about updating any failing tests.

At the end, Micheal Droettboom and I will decide on the new defaults.

A 'classic' style will be provided so reverting to the current default
values will be a single line of python (`mpl.style.use('classic')`).

Please distribute this as widely as possible.  We only want to do this once
and want to get feedback from as many users as possible.

Thomas Caswell

PS jet is harmful to you and those around you

See https://github.com/matplotlib/matplotlib/pull/4622 for an example
proposal PR.
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Problem with violinplot

[Thomas Caswell]

The KDE computation code is a copy of the KDE code from scipy (
https://github.com/scipy/scipy/blob/master/scipy/stats/kde.py),  I suggest
raising this issue on their mailing list/github.

I strongly suspect that violin plot should be doing data sanitation on the
way in or catching exceptions like this, but I am not familiar enough with
the math to be sure what it should do instead.

Tom

On Fri, Jul 3, 2015 at 11:41 AM elmar werling el...@net4werling.de wrote:


 Hi all,

 violinplot is crashing with singular matrix data. See example.

 Is this behaviour for a singular matrix intended or just a bug?

 Cheers
 Elmar



 #
 import numpy as np
 import matplotlib.pyplot as plt

 # data mimicing the
 # original cumsum data (may sum up to 100)
 N = 100
 y1 = np.random.randn(N) + 3.0
 y2 = np.random.randn(N) * 5.0 + 50
 y3 = np.ones(N) * 100   # data set causing violinplot problem

 plt.violinplot([y1, y2, y3])

 plt.boxplot([y1, y2, y3])  # ok
 plt.ylim(0,110)

 #

 OS: Debian
 Anaconda 2.3.0 (64-bit)
 Python 2.7.10
 numpy 2.3.0
 matplotlib 1.4.3



 --
 Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Colormap survey results

[Thomas Caswell]

We would like to tag 1.5 around scipy and it would be nice to get the new
color maps out, even if they are not yet the default.

On Wed, Jul 1, 2015, 11:13 PM Nathaniel Smith n...@pobox.com wrote:

 On Jul 1, 2015 6:31 PM, Eric Firing efir...@hawaii.edu wrote:
 
  On 2015/07/01 1:56 PM, Nathaniel Smith wrote:
   On Tue, Jun 16, 2015 at 7:14 PM, Nathaniel Smith n...@pobox.com
 wrote:
  
   [...snip discussion of how option D was the favorite of 80% of people
   in the survey...]
  
   So the next question is where we go from here.
 
  One thing we need to do is get some of these maps into  _cm.py via PR.

 We've been a bit distracted getting the software and talk together ahead
 of scipy, but PR (with names) will follow within the next week or so. The
 decision part is pretty orthogonal though I think? It's not like matplotlib
 2.0 is going to branch between now and scipy :-).

  I would prefer not to have them go in as huge tables if they can be made
  more compact, either by being function-generated or by using the
  LinearSegmentedColormap mechanism with a moderate number of breakpoints.
 
  Suggestions?

 Depends on how you define moderate, but my guess is that linear
 segmented is the best approach -- the exact colormaps have a pretty terse
 representation as bezier control points, but using this at runtime would
 require pulling in the full colorspace apparatus as a dependency. Which I
 guess has points in its favor for other reasons, but nonetheless.

 These kinds of details can be worked out in the PR review process, though.
 The blocking issue is that we need a decision :-).

 -n

 --
 Don't Limit Your Business. Reach for the Cloud.
 GigeNET's Cloud Solutions provide you with the tools and support that
 you need to offload your IT needs and focus on growing your business.
 Configured For All Businesses. Start Your Cloud Today.
 https://www.gigenetcloud.com/
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] matplotlib/cycler

[Thomas Caswell]

Hey all,

I just moved the stand alone cycler repo to be owned by the matplotlib org
in preparation for it (hopefully) be a required dep in the near future.

The plan is to get a v0.9 up on pypi ASAP and I will be pushing directly to
master for the time being.  Once it is tagged and posted I would like to go
to the standard PR work flow.

The idea is to have a tagged version in the wild for people to play with
and then tag cycler v1.0 along with mpl v1.5.

Tom
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] crash with http://matplotlib.org/examples/animation/rain.html

[Thomas Caswell]

Yes, the size related functions in collections were added in the 1.4 series.

See
http://matplotlib.org/users/whats_new.html#added-size-related-functions-to-specialized-collections

Tom

On Thu, Jun 25, 2015, 11:50 AM Benjamin Root ben.r...@ou.edu wrote:

 Which version of matplotlib are you using. The set_sizes() feature was
 added for v1.4, I think.

 On Thu, Jun 25, 2015 at 11:16 AM, keith.bri...@bt.com wrote:

  I get this error. I have previously got the error 'PathCollection'
 object has no attribute 'set_sizes' with other code, even though it is
 documented at
 http://matplotlib.org/1.4.3/api/collections_api.html?highlight=set_color#matplotlib.collections.PathCollection.set_sizes
 .


  Keith


  kbriggs:~/python python3 rain.py
 Traceback (most recent call last):
   File rain.py, line 65, in module
 animation = FuncAnimation(fig, update, interval=10)
   File /usr/lib/python3/dist-packages/matplotlib/animation.py, line
 1011, in __init__
 TimedAnimation.__init__(self, fig, **kwargs)
   File /usr/lib/python3/dist-packages/matplotlib/animation.py, line
 865, in __init__
 *args, **kwargs)
   File /usr/lib/python3/dist-packages/matplotlib/animation.py, line
 546, in __init__
 self._init_draw()
   File /usr/lib/python3/dist-packages/matplotlib/animation.py, line
 1036, in _init_draw
 self._draw_frame(next(self.new_frame_seq()))
   File /usr/lib/python3/dist-packages/matplotlib/animation.py, line
 1050, in _draw_frame
 self._drawn_artists = self._func(framedata, *self._args)
   File rain.py, line 59, in update
 scat.set_sizes(rain_drops['size'])
 AttributeError: 'PathCollection' object has no attribute 'set_sizes'





 --
 Monitor 25 network devices or servers for free with OpManager!
 OpManager is web-based network management software that monitors
 network devices and physical  virtual servers, alerts via email  sms
 for fault. Monitor 25 devices for free with no restriction. Download now
 http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



 --
 Monitor 25 network devices or servers for free with OpManager!
 OpManager is web-based network management software that monitors
 network devices and physical  virtual servers, alerts via email  sms
 for fault. Monitor 25 devices for free with no restriction. Download now
 http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] scipy sprints

[Thomas Caswell]

Who will be around for the sprints?  We should start to come up with a list
what we want to work on.  There are a number of issues tagged as
'hack-a-thon' which are good candidates for novice contributors.

A few major projects that need attention are:

 - sorting out how to reliably find freetype everywhere (we should probably
pull in someone from enthought on this if possible as they are one of the
problem cases).  This might be solved by using pkg-config everywhere?
 - through review of MEP27 and the extension of MEP22 to the rest of the
interactive backends
 - discussions with IPython folks about what rolling traitlets into Artist
would look like

Tom
--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] pypi name collisions

[Thomas Caswell]

As a heads up, there is now a `pyplot` and a `pylab` packages on pypi.

I have created an issue with the pypi folks
https://sourceforge.net/p/pypi/support-requests/512/
and with both projects
https://github.com/javipalanca/pylab/issues/1
https://github.com/sirrice/pyplot/issues/2

I found both of these via SO questions so I suspect that there is a coming
wave of confused new users who did `pip install pyplot` or `pip install
pylab`.

Tom
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Question about getters and setters.

[Thomas Caswell]

There is a proof-of-concept implementation of this by Matthias

http://carreau.github.io/posts/09-Matplotlib-And-IPython-Config.html

Tom

On Fri, May 15, 2015 at 4:40 PM Brian Granger elliso...@gmail.com wrote:

 OK i have the MEP for this on my todo list...

 On Thu, May 14, 2015 at 5:47 AM, Benjamin Root ben.r...@ou.edu wrote:

 You could start up a Pull Request describing a MEP that would outline how
 traitlets would be used. The discussion can go on there to flesh out the
 concepts and the guidance documentation. Once that is agreed upon, that PR
 would get merged, and we can then start up a new PR actually implementing
 the MEP.

 On Thu, May 14, 2015 at 3:03 AM, Brian Granger elliso...@gmail.com
 wrote:

 Great, that is exciting. What do you think is the best way forward?
 Should I open an issue on the matplotlib repo about this? Would there be
 interest in doing a Google+ hangout about this at some point?

 On Wed, May 13, 2015 at 11:57 PM, Eric Firing efir...@hawaii.edu
 wrote:

 On 2015/05/13 7:45 PM, Brian Granger wrote:

 We (ipython/jupyter) have been talking some more about integrating
 matplotlilb in deeper ways with the interactive widgets framework. That
 only thing that would be required to make this *trivial* is having a
 traitlet's based API for matplotlib. I have even started to look at
 wrapping the existing mpl OO API using traitlets to start to explore
 this. Once this was done, it would be quite easy to autogenerate UIs
 for
 any aspect of Matplotlib.

 Now that traitlets is a standalone pure python package:

 https://github.com/ipython/traitlets

 this would be much easier to pull off.

 If there is interest in this, we might even be able to help do some of
 the work. Let us know if there is enough interest to discuss this
 further.


 No question about it: there is more than enough interest.

 Eric


 Cheers,

 Brian

 On Wed, May 13, 2015 at 9:36 PM, Eric Firing efir...@hawaii.edu
 mailto:efir...@hawaii.edu wrote:

 On 2015/05/13 5:47 PM, Neil Girdhar wrote:
  You're right.  My angle is I just want the setters and getters.
 Writing
  set_ and get_ feels like the C++ prison I thought I had escaped
 :)
 
 John Hunter once commented that if he were doing it over again he
 would
 not have put in all the set_ and get_; they were a legacy of his
 origins
 as a C++ programmer.  I think he would have started with simple
 attributes, which would have been adequate in the early stages.
 Properties were very new--only introduced in Python 2.2, at the end
 of 2001.

 Eric


 --
 One dashboard for servers and applications across
 Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable
 Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 mailto:Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel




 --
 Brian E. Granger
 Cal Poly State University, San Luis Obispo
 @ellisonbg on Twitter and GitHub
 bgran...@calpoly.edu mailto:bgran...@calpoly.edu and
 elliso...@gmail.com mailto:elliso...@gmail.com





 --
 Brian E. Granger
 Cal Poly State University, San Luis Obispo
 @ellisonbg on Twitter and GitHub
 bgran...@calpoly.edu and elliso...@gmail.com


 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel





 --
 Brian E. Granger
 Cal Poly State University, San Luis Obispo
 @ellisonbg on Twitter and GitHub
 bgran...@calpoly.edu and elliso...@gmail.com

 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] relevant issue thread on pandas gh

[Thomas Caswell]

There is an on-going discussion over on the pandas issue tracker about how
to 'pipe' a dataframe into an arbitrary function.  This is relevant to mpl
as one of the primary use-case for this is plotting.

https://github.com/pydata/pandas/issues/10129

It would be good if more mpl developers than just me had eyes on this.

Tom
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] python nightly failures

[Thomas Caswell]

The failures on python nightly are currently due to a bug in python (
http://bugs.python.org/issue24176)

Tom
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Question about getters and setters.

[Thomas Caswell]

It is my understanding that most of this code pre-dates properties and
going through and updating all of the classes is a _huge_ amount of work.
It is more a matter of time than will.


There is also a slowly simmering discussion about implementing artists in a
managed property/attribute frame work (either traitlets, param, or rolling
our own) which is related to this.



On Wed, May 13, 2015 at 11:06 PM Neil Girdhar mistersh...@gmail.com wrote:

 I don't want to ruffle any feathers, and I'm sure this comes up all the
 time, but I'm wondering why don't we have a decorator on classes that
 generates all of the boilerplate methods?

 For example:

 @generate_boilerplate([('linestyle', 'ls'), …]
 class Patch(…):

 would generate

 get_ls, set_ls to point to get_linestyle and set_linestyle and their
 docstrings

 and would generate

 linestyle = property(get_linestyle, set_linestyle) and their docstring.

 This would reduce a lot of boilerplate code and provide the modern getters
 and setters.  In the future, a user could enable an option to disable the
 old style interface and remove it from 'dir', etc.

 What's the reason for not providing the new-style getters and setters?

 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Incorporating TikZ into Matplotlib

[Thomas Caswell]

Sorry, I may have been being a bit dramatic

In mpl.patches: Arrow, FancyArrow, YAArrow, FancyArrowPatch,
ConnectionPatch  + annotation related artists + some classes in axisartist
which now that I look at them are not really general purpose arrow tools.
I had not been counting quiver (or barbs) or sankey.

Neil: Those are all great questions!  Much of the arrow related code was
written by Joe-Joon Lee who (by having read a good deal of his code) has a
habit of writing very power but very opaque python.

I believe that the line join style is controlled by `joinstyle` on the
graphics context and it is up to the backends to implement that correctly.

Tom

On Wed, May 13, 2015 at 10:58 PM Neil Girdhar mistersh...@gmail.com wrote:

 Okay, I'm looking at this in more detail and there may be some design
 concerns:

 The arrow placement is decided without asking the arrow any questions,
 such as its bounding box.  Instead, the arrow should return a bounding box
 and then the line should retreat until the bounding box no longer
 intersects the target node.  Then the arrow should be placed.  This doesn't
 matter so much when you have a simple arrow like this: , but it's a
 big deal when you have an arrow like | .  In this case, the sides of
 the arrow risk intersecting with the target node.

 I'm not keen on implementing every arrow three times: -, -, -.  This
 really should be handled by the code placing the arrows for many reasons:
 1. It should also be possible to have a different arrowhead at either end
 of the line.
 2. It should be possible to stack the arrows, for example having two heads
 one after another (to represent two kinds of relationships).  This is
 another reason to be able to ask the arrowhead its length and so on.

 I don't understand the monolithic keyword.  How can the arrow draw the
 line as well when it doesn't know the line style, color and so on?

 I think I like the design of the transmute function.  I'm curious:
 ultimately, where does the mutation_size come from?  Is it a global scale
 applied to the figure, or is it based on the linewidth, or?

 When you emit a set of lines, how are they joined?  If I draw a line
 having linewidth 0.1 from the origin to (1, 0), and back to (0, 0.5), what
 happens at the tip?  Are two rectangles drawn (each having width 0.1, but
 oriented differently)?  Is a bevel created?  A miter? Or is the tip
 rounded?  Can this be controlled?  See page 166 of the manual I sent
 earlier (search for tikz/line join).

 Best,

 Neil

 On Wed, May 13, 2015 at 10:14 PM, Neil Girdhar mistersh...@gmail.com
 wrote:

 Thanks, it works!

 I needed to add:

 import matplotlib.patches

 to one file and

 plt.show()

 to the other.

 Any word on the locations in the code of the seven arrow drawing methods?

 I've located the arrow drawing code in tikz, and so I can start porting
 it over.  I'm curious, do we know the linewidth of the edge being decorated
 by the arrow?  To make arrows scale nicely, most of the arrow dimensions
 are given in two pieces: an absolute value (in points for example) and a
 line width factor.  The dimension is the absolute value plus the line width
 factor times the line width.  The TikZ manual explains: This makes it easy
 to vary the size of an arrow tip in accordance with the line width –
 usually a very good idea since thicker lines will need thicker arrow tips.

 Best,

 Neil

 On Wed, May 13, 2015 at 10:07 PM, Benjamin Reedlunn breed...@gmail.com
 wrote:

 Neil,

 I have attached code to draw the arrowhead.

 -Ben



 On May 13, 2015, at 7:44 PM, Neil Girdhar mistersh...@gmail.com wrote:

 Do you have the code that you used to draw the arrowhead?  I'm up to
 date now on the development workflow (
 http://matplotlib.org/devel/gitwash/development_workflow.html), so I'm
 ready to start working.

 Thanks,

 Neil

 On Wed, May 13, 2015 at 9:10 PM, Benjamin Reedlunn breed...@gmail.com
 wrote:

 Yes, I fully agree that we need to unify the many different ways to
 draw arrows.

 Neil, in case an example would be helpful for you, I have attached a
 module that includes a custom arrowhead class.  The arrowhead class works
 with the with the ax.annotate() method.  (I like the annotate method
 because it allows me to easily mix and match coordinate systems for arrow
 placement.)  As you can see in the attached pdf, the custom arrowhead
 doesn't include fancy Bezier curves, but that could be added.

 -Ben



 On May 13, 2015, at 2:54 PM, Thomas Caswell tcasw...@gmail.com wrote:

 The other thing that should be done is to unify the (I think 7?!?)
 unique ways to draw arrows in mpl.

 On Wed, May 13, 2015 at 4:52 PM Neil Girdhar mistersh...@gmail.com
 wrote:

 Yes, I just noticed that as well.  That's how the tikz pgf code looks
 (a sequence of line_to and curve_to commands and so on) so it should be
 easy to port over the various shapes.

 On Wed, May 13, 2015 at 4:49 PM, Eric Firing efir...@hawaii.edu
 wrote:

 On 2015/05/13 10:12 AM, Neil Girdhar

Re: [matplotlib-devel] Why num in manager?

[Thomas Caswell]

I think that so long as you maintain the mapping of 'manager' to be 'gui
element holding the Figure' (rather than 'gui window holding figure')
numbering the managers should be ok.   That is, the tabs are the managers
and the multi-figure windows are a layer above the managers.

The notion of 'figure number' is very thoroughly a pyplot/figure manager
idea I am -1 on pushing that logic down in to the Figure class.

Tom

On Wed, May 6, 2015 at 4:42 PM Eric Firing efir...@hawaii.edu wrote:

 On 2015/05/06 9:19 AM, Federico Ariza wrote:
  Hello
 
  Is there any reason why the num property is assigned to the manager
  and not to the figure?

 I think this is because the figure is at the object-oriented API level.
   The manager is in the pyplot state-machine level.

  Pyplot.gcf is to get the current figure not the current manager.

 It is really get current managed figure, combined with the original
 idea that the manager is the pyplot layer on top of the figure, with one
 manager per figure.  The current concept comes from the state machine.

 
  In general this is not a problem. But I'm working on MEP23 where one
  manager can contain several figures. And it would be pretty nice if I
  could reference the figures by that number not the managers.
 
  A priori, do you see any problem with a PR changing that?

 It seems like it could work--but what will it do to existing user code?

 Eric

 
  Thanks
  Federico
 
 
 
 
 --
  One dashboard for servers and applications across Physical-Virtual-Cloud
  Widest out-of-the-box monitoring support with 50+ applications
  Performance metrics, stats and reports that give you Actionable Insights
  Deep dive visibility with transaction tracing using APM Insight.
  http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 
 
 
  ___
  Matplotlib-devel mailing list
  Matplotlib-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
 



 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Fwd: python data vis Slack channels?

[Thomas Caswell]

That sounds reasonable to me.  My only concern is getting enough (any?)
bandwidth from enough of the core mpl developers.

IPython and scikit image both have gitter rooms running that seem to
working well for them as well, is there any reason to go with slack over
gitter?

Tom

-- Forwarded message -
From: Bryan Van de Ven bry...@continuum.io
Date: Mon, May 4, 2015 at 11:44 AM
Subject: python data vis Slack channels?
To: Michael Droettboom md...@stsci.edu, tcasw...@gmail.com


Hi guys,

We have been experimenting/toying with the idea of using a free Slack
channel to provide a place for casual Bokeh user interactions. It occurred
that it might be nice to have a single pyvis.slack.com, that has channels
for several OSS python vis libraries in one place. Would you have any
interest in a #matplotlib channel there? If there is a better place to
submit this proposal, please let me know.

Regards,

Bryan Van de Ven
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Alternative way of specifying plot layout

[Thomas Caswell]

I am in favor of doing in in PR comments so we can to line comments.

On Sun, Apr 26, 2015 at 3:47 AM Nicolas P. Rougier nicolas.roug...@inria.fr
wrote:


 Great ! Thanks for setting this up. One comment, it would be great to have
 a README.rst in the directory to have abstract of all MEPS at once in
 github (I can make a PR).


 I've started working on MEP28 (
 https://github.com/rougier/matplotlib/blob/MEP28/doc/devel/MEP/MEP28.rst).
 I intend to make a PR once it is a bit more polished or should I make a PR
 right now to initiate the discussion on the PR ? (It is not clear to me if
 the preferred medium for discussion is the mailing list or the PR comments).


 Nicolas

  On 25 Apr 2015, at 23:04, Thomas Caswell tcasw...@gmail.com wrote:
 
  The MEP tree has been moved into the main repo
 https://github.com/matplotlib/matplotlib/tree/master/doc/devel/MEP
 
  I am pretty excited about this feature.
 
  I don't remember if this got mentioned upthread, but this ties in with
 https://github.com/matplotlib/matplotlib/issues/1109 as a nice way to set
 up all of the constraints.
 
  Tom
 
  On Thu, Mar 19, 2015 at 1:10 PM Nicolas P. Rougier 
 nicolas.roug...@inria.fr wrote:
  Ok. I'll wait for the MEP directory to start writing a proposal.
  Here is a flavor of what I think could be done (to be seen using a fixed
 width font):
 
 
  AB:
  ┌┐┌┐
  │ A  ││ B  │
  ││││
  ││││
  └┘└┘
 
  ABB:
  ┌──┐┌──┐
  │ A││ B│
  │  ││  │
  │  ││  │
  └──┘└──┘
 
  ABD
  CCD:
  ┌───┐┌───┐┌───┐
  │ A ││ B ││ D │
  │   ││   ││   │
  │   ││   ││   │
  └───┘└───┘│   │
  ┌┐│   │
  │ C  ││   │
  │││   │
  └┘└───┘
 
  AaBb:
  ┌───┐┌─┐┌───┐┌─┐
  │ A ││ ││ B ││ │
  │   ││ ││   ││ │
  │   ││ ││   ││ │
  └───┘└─┘└───┘└─┘
 
b  
  aABCc:
  ┌───┐
  └───┘
  ┌─┐┌───┐┌───┐┌───┐┌─┐
  │ ││ A ││ B ││ C ││ │
  │ ││   ││   ││   ││ │
  │ ││   ││   ││   ││ │
  └─┘└───┘└───┘└───┘└─┘
 
 
 
 
  On 19 Mar 2015, at 15:34, Benjamin Root ben.r...@ou.edu wrote:
 
  two problems with that: 1) that really doesn't make me want to use this
 approach, especially since I wouldn't know what ratios I would want in the
 first place. 2) it can't tell if I want a horizontal or vertical colorbar,
 whereas the lower-case notation could have some logic to auto-detect the
 user's intent (e.g., all lower-case letters in the last row indicates
 horizontal bars). It would also allow us to return the plotting axes
 separate from the colorbar axes, which is how axes_grid1 does it, and it is
 very nice that way.
 
  On Thu, Mar 19, 2015 at 6:31 AM, Nicolas P. Rougier 
 nicolas.roug...@inria.fr wrote:
 
  I think you could specify colorbars using: [AB]
  (B is a vertical colorbar, 1/10 of total width)
 
  Nicolas
 
 
 
   On 18 Mar 2015, at 18:52, Eric Firing efir...@hawaii.edu wrote:
  
   On 2015/03/18 7:42 AM, Benjamin Root wrote:
   A thought... could this perhaps be extended somehow to specify
 colorbars
   in the layout?
  
   A lower-case letter could indicate a colorbar-size Axes:
  
   layout = [ABc,
 DE ,
 ff ]
  
   would put a vertical think axes to the right of B, and a double-wide
   hoizontal one below D and E.
  
   All of this seems like an alternative API for gridspec and axes_grid1.
  
   I am concerned about ending up with too many ways to do things, but
 with
   subtle differences.
  
   How much control over spacing and sizing would be provided by kwargs
 or
   other adjustment mechanisms?  How would this relate to subplot_params?
  
   Eric
  
  
  
  
 --
   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
   Matplotlib-devel@lists.sourceforge.net
   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

Re: [matplotlib-devel] backporting the boxplot fix

[Thomas Caswell]

The branch 1.4.x was the branch for bug fixes that would eventually turn
into the _next_ 1.4 series release.  We do not plan on doing a 1.4.4 so the
1.4.x branch no longer is needed.  The commit used for the releases are
tagged (ex v1.4.3).  The v1.4.3-doc branch is so that we can correct any
documentation issues and re-build the website if needed.

Tom

On Sun, Apr 26, 2015 at 9:12 AM Mike Kaufman mck...@gmail.com wrote:

 So it seems I was using the old branch (now deleted?) v1.4.x rather than
 v1.4.3-doc, which does have the commit for the fix in question. I was
 naively assuming that v1.4.x was always the latest release in the v1.4
 series.

 False alarm. Sorry.

 M

 On 4/25/15 4:26 PM, Thomas Caswell wrote:
  The commit that fixes that
 
 https://github.com/matplotlib/matplotlib/commit/40720ef9fb5de75d908d0ce433d5c3bb8902884f
  should be in 1.4.1 an onward.  Exactly which version are you using?
 
  There will be no 1.4.4.
 
  On Tue, Apr 21, 2015 at 11:00 AM Michael Kaufman kaufma...@ornl.gov
  mailto:kaufma...@ornl.gov wrote:
 
  Is there any possibility of back-porting the fix to the boxplot
  positions to v1.4.x? This would be ticket #3563. I had thought that
 this
  was fixed in 1.4, but it seems to be there again. v1.5-devel (where
 the
  boxplot works fine) is not-very-usable for me due to the GTK idle
 bug.
 
  Thanks,
 
  M
 
 
  
 --
  BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
  Develop your own process in accordance with the BPMN 2 standard
  Learn Process modeling best practices with Bonita BPM through live
  exercises
  http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
  event?utm_
 
  source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
  ___
  Matplotlib-devel mailing list
  Matplotlib-devel@lists.sourceforge.net
  mailto:Matplotlib-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
 
 
 
 
 --
  One dashboard for servers and applications across Physical-Virtual-Cloud
  Widest out-of-the-box monitoring support with 50+ applications
  Performance metrics, stats and reports that give you Actionable Insights
  Deep dive visibility with transaction tracing using APM Insight.
  http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 
 
 
  ___
  Matplotlib-devel mailing list
  Matplotlib-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
 



 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] backporting the boxplot fix

[Thomas Caswell]

The commit that fixes that
https://github.com/matplotlib/matplotlib/commit/40720ef9fb5de75d908d0ce433d5c3bb8902884f
should be in 1.4.1 an onward.  Exactly which version are you using?

There will be no 1.4.4.

On Tue, Apr 21, 2015 at 11:00 AM Michael Kaufman kaufma...@ornl.gov wrote:

 Is there any possibility of back-porting the fix to the boxplot
 positions to v1.4.x? This would be ticket #3563. I had thought that this
 was fixed in 1.4, but it seems to be there again. v1.5-devel (where the
 boxplot works fine) is not-very-usable for me due to the GTK idle bug.

 Thanks,

 M


 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process in accordance with the BPMN 2 standard
 Learn Process modeling best practices with Bonita BPM through live
 exercises
 http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
 event?utm_
 source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Compile Matplotlib for Android

[Thomas Caswell]

Sorry this never got a response.  I also have no idea where to start, but
mpl depends an numpy (which has significant c code) and a number of c
extensions internally (Agg for rasterization, freetype for font rendering).

I would suggest starting with figuring out how to compile numpy as it is
required and I suspect simpler to compile.

Tom

On Sun, Mar 29, 2015 at 9:19 AM Achyut Rastogi rastogiach...@gmail.com
wrote:

 Hello,
 I want to compile matplotlib for Android, but I really don't have any clue
 where to start, well I have already stated with learning SL4A, also
 inclement sir(Alexander Taylor) says that its already been done by someone
 but I couldn't find it at all so if somebody has any information about it
 please post it here, also if you have anything else that may help in this,
 please post that here too.
 If somebody is interested in this, they can check my progress here
 http://immovableone.blogspot.in/.
 Lastly, Thank you very much for all the informative comments on the thread
 'Kivy backend', that really helped me a lot in writing  my proposal.

 --
 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
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Alternative way of specifying plot layout

[Thomas Caswell]

The MEP tree has been moved into the main repo
https://github.com/matplotlib/matplotlib/tree/master/doc/devel/MEP

I am pretty excited about this feature.

I don't remember if this got mentioned upthread, but this ties in with
https://github.com/matplotlib/matplotlib/issues/1109 as a nice way to set
up all of the constraints.

Tom

On Thu, Mar 19, 2015 at 1:10 PM Nicolas P. Rougier nicolas.roug...@inria.fr
wrote:

 Ok. I'll wait for the MEP directory to start writing a proposal.
 Here is a flavor of what I think could be done (to be seen using a fixed
 width font):


 AB:
 ┌┐┌┐
 │ A  ││ B  │
 ││││
 ││││
 └┘└┘

 ABB:
 ┌──┐┌──┐
 │ A││ B│
 │  ││  │
 │  ││  │
 └──┘└──┘

 ABD
 CCD:
 ┌───┐┌───┐┌───┐
 │ A ││ B ││ D │
 │   ││   ││   │
 │   ││   ││   │
 └───┘└───┘│   │
 ┌┐│   │
 │ C  ││   │
 │││   │
 └┘└───┘

 AaBb:
 ┌───┐┌─┐┌───┐┌─┐
 │ A ││ ││ B ││ │
 │   ││ ││   ││ │
 │   ││ ││   ││ │
 └───┘└─┘└───┘└─┘

   b  
 aABCc:
 ┌───┐
 └───┘
 ┌─┐┌───┐┌───┐┌───┐┌─┐
 │ ││ A ││ B ││ C ││ │
 │ ││   ││   ││   ││ │
 │ ││   ││   ││   ││ │
 └─┘└───┘└───┘└───┘└─┘




 On 19 Mar 2015, at 15:34, Benjamin Root ben.r...@ou.edu wrote:

 two problems with that: 1) that really doesn't make me want to use this
 approach, especially since I wouldn't know what ratios I would want in the
 first place. 2) it can't tell if I want a horizontal or vertical colorbar,
 whereas the lower-case notation could have some logic to auto-detect the
 user's intent (e.g., all lower-case letters in the last row
 indicates horizontal bars). It would also allow us to return the plotting
 axes separate from the colorbar axes, which is how axes_grid1 does it, and
 it is very nice that way.

 On Thu, Mar 19, 2015 at 6:31 AM, Nicolas P. Rougier 
 nicolas.roug...@inria.fr wrote:

 I think you could specify colorbars using: [AB]
 (B is a vertical colorbar, 1/10 of total width)

 Nicolas



  On 18 Mar 2015, at 18:52, Eric Firing efir...@hawaii.edu wrote:
 
  On 2015/03/18 7:42 AM, Benjamin Root wrote:
  A thought... could this perhaps be extended somehow to specify colorbars
  in the layout?
 
  A lower-case letter could indicate a colorbar-size Axes:
 
  layout = [ABc,
DE ,
ff ]
 
  would put a vertical think axes to the right of B, and a double-wide
  hoizontal one below D and E.
 
  All of this seems like an alternative API for gridspec and axes_grid1.
 
  I am concerned about ending up with too many ways to do things, but with
  subtle differences.
 
  How much control over spacing and sizing would be provided by kwargs or
  other adjustment mechanisms?  How would this relate to subplot_params?
 
  Eric
 
 
 
 
 --
  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
  Matplotlib-devel@lists.sourceforge.net
  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
 Matplotlib-devel@lists.sourceforge.net
 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
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [PATCH 0/2] remove unused code

[Thomas Caswell]

Kelvin,

Thank you for your work. Would it be possible for you to open a pull
request on git hub with these changes (that is where we so almost all of
our code review recently and is hooked in to a continuous integration
service).

I have not looked at the diff yet (still on my phone), but from looking at
the file list I am a bit concerned. The backends have a good number of
imports that are there for compatibility reasons.

This might also conflict with the mep27 related pr #4143.

There is also an open pr working on the wx backend that this may conflict
with (#3421).

Tom

On Mon, Apr 20, 2015, 02:07 Kelvin Li ltwis...@gmail.com wrote:

 First ever patch submission. Here I propose cleaning up some unused
 variables
 and imports.

 Kelvin Li (2):
   remove unused variable cmd_split
   backends: remove unnecessary import statements

  lib/matplotlib/backends/backend_agg.py |  2 --
  lib/matplotlib/backends/backend_cairo.py   |  5 ++--
  lib/matplotlib/backends/backend_gdk.py |  9 ---
  lib/matplotlib/backends/backend_gtk.py |  7 +++--
  lib/matplotlib/backends/backend_gtk3agg.py |  1 -
  lib/matplotlib/backends/backend_gtk3cairo.py   |  2 --
  lib/matplotlib/backends/backend_gtkagg.py  |  7 +
  lib/matplotlib/backends/backend_gtkcairo.py|  3 ---
  lib/matplotlib/backends/backend_macosx.py  | 11 +++-
  lib/matplotlib/backends/backend_mixed.py   |  2 --
  lib/matplotlib/backends/backend_nbagg.py   |  2 --
  lib/matplotlib/backends/backend_pgf.py |  2 --
  lib/matplotlib/backends/backend_ps.py  | 26 +++
  lib/matplotlib/backends/backend_qt4.py | 36
 ++
  lib/matplotlib/backends/backend_qt4agg.py  | 11 
  lib/matplotlib/backends/backend_qt5agg.py  |  9 ---
  lib/matplotlib/backends/backend_svg.py | 12 -
  lib/matplotlib/backends/backend_template.py|  4 ---
  lib/matplotlib/backends/backend_tkagg.py   | 13 +++---
  lib/matplotlib/backends/backend_webagg.py  |  1 -
  lib/matplotlib/backends/backend_webagg_core.py |  4 ---
  lib/matplotlib/backends/backend_wx.py  |  2 --
  lib/matplotlib/backends/backend_wxagg.py   |  9 +++
  lib/matplotlib/backends/tkagg.py   |  3 ---
  lib/matplotlib/backends/windowing.py   |  2 --
  lib/matplotlib/texmanager.py   |  6 -
  26 files changed, 26 insertions(+), 165 deletions(-)

 --
 2.1.4





 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process in accordance with the BPMN 2 standard
 Learn Process modeling best practices with Bonita BPM through live
 exercises
 http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
 event?utm_
 source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[Thomas Caswell]

+1 from me.  I suspect many people got their start learning mpl from you on
SO ;)

Tom

On Mon, Mar 30, 2015 at 7:17 PM Joe Kington joferking...@gmail.com wrote:

 If you don't mind a non-core person doing the tutorial, I'll be there
 this year, and I'd be happy to be Ben's backup for teaching it.
 Cheers!
 -Joe

 On Sun, Mar 29, 2015 at 9:17 PM, Thomas Caswell tcasw...@gmail.com
 wrote:

 Ben,

 Have you sorted out if you can make scipy this year and does anyone want
 to be back up on teaching the tutorial?

 It seems a shame to not have a mpl tutorial available.

 I am probably going to submit a 'state of the library' talk and do not
 want to do both.

 Tom

 On Thu, Mar 26, 2015 at 5:06 PM Michael Droettboom md...@stsci.edu
 wrote:

  This sounds great.  Unfortunately, I can't attend Scipy this year due
 to a family commitment, but would be more than happy to help put together
 and review materials beforehand.

 Cheers,
 Mike


 On 03/26/2015 10:59 AM, Thomas Caswell wrote:


  I also think we should have a 'state of the library' talk.

 We definitely have a few important things to announce/show off:
   - FSA
   - nbagg/notebook
   - new default colors
   - style module

  and should have a couple more by July
   - sane serialize/deserialize + interop with plotly/bokeh
   - better toolbar
   - better interactive OO
   - improved docs

  I will be there for the main conference and the sprints and am willing
 to give this talk, but will defer if someone else wants to do it.

  Does anyone want to volunteer to be Ben's second on his tutorial?



 On Fri, Mar 13, 2015 at 2:46 PM Olga Botvinnik obotv...@ucsd.edu
 wrote:

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

 On Fri, Mar 13, 2015, 11:29 Phil Elson pelson@gmail.com 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.r...@ou.edu 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 
 nelle.varoqu...@gmail.com 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 scipy-organiz...@scipy.org
 Date: 11 March 2015 at 01:02
 Subject: SciPy 2015 CFP Email 2
 To: nelle.varoqu...@gmail.com


[image: SciPy 2015 Logo]
 https://www.eiseverywhere.com/emarketing/go.php?i=182077e=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=182077e=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=182077e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==l=http://scipy2015.scipy.org
 or submit a proposal here
 https://www.eiseverywhere.com/emarketing/go.php?i=182077e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969
 .

   Submit a Tutorial Proposal Here
 https://www.eiseverywhere.com/emarketing/go.php?i=182077e=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=182077e=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=182077e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==l=http

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

[Thomas Caswell]

Ben,

Have you sorted out if you can make scipy this year and does anyone want to
be back up on teaching the tutorial?

It seems a shame to not have a mpl tutorial available.

I am probably going to submit a 'state of the library' talk and do not want
to do both.

Tom

On Thu, Mar 26, 2015 at 5:06 PM Michael Droettboom md...@stsci.edu wrote:

  This sounds great.  Unfortunately, I can't attend Scipy this year due to
 a family commitment, but would be more than happy to help put together and
 review materials beforehand.

 Cheers,
 Mike


 On 03/26/2015 10:59 AM, Thomas Caswell wrote:


  I also think we should have a 'state of the library' talk.

 We definitely have a few important things to announce/show off:
   - FSA
   - nbagg/notebook
   - new default colors
   - style module

  and should have a couple more by July
   - sane serialize/deserialize + interop with plotly/bokeh
   - better toolbar
   - better interactive OO
   - improved docs

  I will be there for the main conference and the sprints and am willing
 to give this talk, but will defer if someone else wants to do it.

  Does anyone want to volunteer to be Ben's second on his tutorial?



 On Fri, Mar 13, 2015 at 2:46 PM Olga Botvinnik obotv...@ucsd.edu wrote:

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

 On Fri, Mar 13, 2015, 11:29 Phil Elson pelson@gmail.com 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.r...@ou.edu 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 
 nelle.varoqu...@gmail.com 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 scipy-organiz...@scipy.org
 Date: 11 March 2015 at 01:02
 Subject: SciPy 2015 CFP Email 2
 To: nelle.varoqu...@gmail.com


[image: SciPy 2015 Logo]
 https://www.eiseverywhere.com/emarketing/go.php?i=182077e=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=182077e=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=182077e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==l=http://scipy2015.scipy.org
 or submit a proposal here
 https://www.eiseverywhere.com/emarketing/go.php?i=182077e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969
 .

   Submit a Tutorial Proposal Here
 https://www.eiseverywhere.com/emarketing/go.php?i=182077e=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=182077e=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=182077e=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=182077e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==l=http

[matplotlib-devel] Move MEPs into main documentation

[Thomas Caswell]

I am proposing to move the MEPs from the wiki into the main documentation.

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

The main benifits to this are to make preserve the MEPs long term, to keep
a better history of their development, and to improve the discussion around
them.

The motivation behind using the wiki was to reduce the barriers to working
on the MEP, but it has not worked out as well as hoped.  Having to modify
MEPs via a PR does increase the barriers on working on them, but it allows
us to apply the tools we already use for code review to them.

Tom
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[Thomas Caswell]

I also think we should have a 'state of the library' talk.

We definitely have a few important things to announce/show off:
  - FSA
  - nbagg/notebook
  - new default colors
  - style module

and should have a couple more by July
  - sane serialize/deserialize + interop with plotly/bokeh
  - better toolbar
  - better interactive OO
  - improved docs

I will be there for the main conference and the sprints and am willing to
give this talk, but will defer if someone else wants to do it.

Does anyone want to volunteer to be Ben's second on his tutorial?



On Fri, Mar 13, 2015 at 2:46 PM Olga Botvinnik obotv...@ucsd.edu wrote:

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

 On Fri, Mar 13, 2015, 11:29 Phil Elson pelson@gmail.com 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.r...@ou.edu 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 
 nelle.varoqu...@gmail.com 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 scipy-organiz...@scipy.org
 Date: 11 March 2015 at 01:02
 Subject: SciPy 2015 CFP Email 2
 To: nelle.varoqu...@gmail.com


   [image: SciPy 2015 Logo]
 https://www.eiseverywhere.com/emarketing/go.php?i=182077e=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=182077e=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=182077e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==l=http://scipy2015.scipy.org
 or submit a proposal here
 https://www.eiseverywhere.com/emarketing/go.php?i=182077e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969
 .

   Submit a Tutorial Proposal Here
 https://www.eiseverywhere.com/emarketing/go.php?i=182077e=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=182077e=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=182077e=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=182077e=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=182077e=bmVsbGUudmFyb3F1YXV4QGdtYWlsLmNvbQ==l=http://www.scipy2015.scipy.org/eselectv2/frontend/index/115969
Need
 some inspiration? Follow @SciPy on Twitter
 

Re: [matplotlib-devel] 1.4.3 does not build on Ubuntu 14 with python3

[Thomas Caswell]

Also see https://github.com/matplotlib/matplotlib/issues/3889

On Wed, Mar 18, 2015 at 10:22 AM Benjamin Root ben.r...@ou.edu wrote:

 Please update your install of setuptools.

 On Wed, Mar 18, 2015 at 10:01 AM, keith.bri...@bt.com wrote:

 kbriggs:~/Downloads/matplotlib-1.4.3 python3 setup.py build
 
 Edit setup.cfg to change the build options

 BUILDING MATPLOTLIB
 matplotlib: yes [1.4.3]
 python: yes [3.4.0 (default, Apr 11 2014, 13:05:11)  [GCC
 4.8.2]]
   platform: yes [linux]

 REQUIRED DEPENDENCIES AND EXTENSIONS
  numpy: yes [version 1.8.2]
six: yes [using six version 1.5.2]
   dateutil: yes [dateutil was not found. It is required for
 date
 axis support. pip/easy_install may attempt to
 install it after matplotlib.]
   pytz: yes [pytz was not found. pip will attempt to
 install
 it after matplotlib.]
tornado: yes [tornado was not found. It is required for the
 WebAgg backend. pip/easy_install may attempt to
 install it after matplotlib.]
  pyparsing: yes [using pyparsing version 2.0.1]
  pycxx: yes [Official versions of PyCXX are not compatible
 with matplotlib on Python 3.x, since they lack
 support for the buffer object.  Using local copy]
 libagg: yes [pkg-config information for 'libagg' could not
 be found. Using local copy.] Traceback (most
 recent call last):
   File setup.py, line 155, in module
 result = package.check()
   File /home/kbriggs/Downloads/matplotlib-1.4.3/setupext.py, line 961,
 in check
 min_version='2.3', version=version)
   File /home/kbriggs/Downloads/matplotlib-1.4.3/setupext.py, line 445,
 in _check_for_pkg_config
 if (not is_min_version(version, min_version)):
   File /home/kbriggs/Downloads/matplotlib-1.4.3/setupext.py, line 173,
 in is_min_version
 return found_version = expected_version
   File /usr/lib/python3.4/distutils/version.py, line 76, in __ge__
 c = self._cmp(other)
   File /usr/lib/python3.4/distutils/version.py, line 343, in _cmp
 if self.version  other.version:
 TypeError: unorderable types: str()  int()



 --
 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
 Matplotlib-devel@lists.sourceforge.net
 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
 Matplotlib-devel@lists.sourceforge.net
 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Alternative way of specifying plot layout

[Thomas Caswell]

Cool.  I think it make sense to put this in to `pyplot.py` next to
`subplots`

Tom

On Wed, Mar 18, 2015 at 1:14 PM Nicolas P. Rougier nicolas.roug...@inria.fr
wrote:


 Hi,

 I've been experimenting with a simple idea for specifying plot layout in a
 rather intuitive way.
 The idea is simply to draw your layout using strings.

 Examples:

 layout = [AB]
 - means two plots side by side with equal width

 layout = [AAAB]
 - means two plots side by side A being 3 times wider than B

 layout = [AB,
   CC]
 - means two plots (A  B) side by side and C below with full width

 layout = [AB,
   C ]
 - means two plots (A  B) side by side and C below A (same width)

 etc... (have a look at sources)

 I guess you cannot express every layout but it might work for most common
 ones.

 If you think this might a good addition I can try to make a PR but I'm not
 sure where to insert it.
 My idea would be to have a layout function such that you can write:

 A,B,C = plt.layout([AB, CC], border=0.01)
 A.plot(...)
 B.plot(...)
 C.plot(...)


 Nicolas


 
 --
 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
 Matplotlib-devel@lists.sourceforge.net
 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Alternative way of specifying plot layout

[Thomas Caswell]

Currently we are doing MEPs on the wiki (
https://github.com/matplotlib/matplotlib/wiki/MEPTemplate) , but I would
like to move them to be in the docs (make a MEP folder next to 'users'?) as
the visibility on the wiki is low, there isn't a great way to leave line
comments, and we should have these documents in the official docs
eventually.

Tom

On Wed, Mar 18, 2015 at 1:45 PM Nicolas P. Rougier nicolas.roug...@inria.fr
wrote:


 Yes, a MEP makes sense to discuss the proposal.
 What's the procedure to open a MEP (i.e. where) ?

 Nicolas


  On 18 Mar 2015, at 18:44, Benjamin Root ben.r...@ou.edu wrote:
 
  Also, perhaps it makes sense to make this a MEP to finalize and document
 the spec?
 
  On Wed, Mar 18, 2015 at 1:42 PM, Benjamin Root ben.r...@ou.edu wrote:
  That is neat. I would be sure to put in some ..seealso:: lines in
 places like plt.subplots and GridSpec and such.
 
  A thought... could this perhaps be extended somehow to specify colorbars
 in the layout? I am not sure how I would do that, but if we could come up
 with a way to do it, *that* would make this a killer feature. But even
 without that, this is still pretty useful.
 
  On Wed, Mar 18, 2015 at 1:20 PM, Thomas Caswell tcasw...@gmail.com
 wrote:
  Cool.  I think it make sense to put this in to `pyplot.py` next to
 `subplots`
 
  Tom
 
  On Wed, Mar 18, 2015 at 1:14 PM Nicolas P. Rougier 
 nicolas.roug...@inria.fr wrote:
 
  Hi,
 
  I've been experimenting with a simple idea for specifying plot layout in
 a rather intuitive way.
  The idea is simply to draw your layout using strings.
 
  Examples:
 
  layout = [AB]
  - means two plots side by side with equal width
 
  layout = [AAAB]
  - means two plots side by side A being 3 times wider than B
 
  layout = [AB,
CC]
  - means two plots (A  B) side by side and C below with full width
 
  layout = [AB,
C ]
  - means two plots (A  B) side by side and C below A (same width)
 
  etc... (have a look at sources)
 
  I guess you cannot express every layout but it might work for most
 common ones.
 
  If you think this might a good addition I can try to make a PR but I'm
 not sure where to insert it.
  My idea would be to have a layout function such that you can write:
 
  A,B,C = plt.layout([AB, CC], border=0.01)
  A.plot(...)
  B.plot(...)
  C.plot(...)
 
 
  Nicolas
 
 
  
 --
  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
  Matplotlib-devel@lists.sourceforge.net
  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
  Matplotlib-devel@lists.sourceforge.net
  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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[Thomas Caswell]

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.s...@gmail.com 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
 Matplotlib-devel@lists.sourceforge.net
 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Kivy backend

[Thomas Caswell]

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 nicolas.roug...@inria.fr
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.r...@ou.edu 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 
 cyrille.ross...@gmail.com 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
  Matplotlib-devel@lists.sourceforge.net
  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
  Matplotlib-devel@lists.sourceforge.net
  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
 Matplotlib-devel@lists.sourceforge.net
 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[Thomas Caswell]

Right on no longer supporting 1.5, but this code never got updated.

This is a bit of a bigger job than I first anticipated as numpy has
deprecated the norm kwarg, so we probably should too.

On Tue, Mar 10, 2015, 07:19 OceanWolf juichenieder-n...@yahoo.co.uk wrote:

 Tom, ``When we drop numpy 1.5''?  I thought we already had... I mean we
 only test numpy 1.6 on Travis...

 For the rebinning exercise, I don't have time to look, but I would
 expect a similar trick to imshow, quiver, etcetera when I want to
 compare to a baseline (e.g. for animation).  Namely I calculate the
 normalisation parameters first, and then apply those parameters on
 subsequent plots.

 To ease the user, we could add a method to return the binning parameters
 from a single binning exercise, and then give an option to pass those
 params in to subsequent plots.

 
 --
 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
 Matplotlib-devel@lists.sourceforge.net
 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] First release of an object oriented style system

[Thomas Caswell]

Cool.

There is a lot of code there to digest so I don't have anything technically
sensible to say yet, but in principle/abstract this seems like a good idea.

This also ties back into the MEP25 (figure serialization) discussion and
the discussion I was having with Eric Firing in the comments of
https://github.com/matplotlib/matplotlib/pull/4172 (yes, a less than ideal
place) about adopting a more structured framework for mpl artists
attributes(ex make them into IPython Configurable/use traitlets) and the
larger discussion started at scipy last year about providing style sheets.

The current style library and rcparams tools provide (several) context
managers so you can mostly avoid damaging the global state.

The ability to apply style once the figure has been drawn is a feature
request I have seen go by several times.

Another major limitation of the rcparam approach is that to add new
parameters can modifying code pretty deep in the core of the library.

Tom

On Sat, Mar 7, 2015 at 9:39 PM Drain, Theodore R (392P) 
theodore.r.dr...@jpl.nasa.gov wrote:

 Last year we implemented an object oriented plotting style system for our
 users and I was able to convince our management that we should open source
 it.  You can find it here:  https://github.com/nasa/mplStyle

 Many (most?) of the existing MPL style systems seem to be built around RC
 parameters which doesn't work very well for us.  For a large system that
 can create plots in many different scripts/GUI's, we really can't change
 global settings (RC's) to affect how a plot looks as it ends up screwing up
 plots in other areas.  So we designed an OO based style system that allows
 you to create/save/load styles and apply them to individual plot elements
 (text, lines, axes, figures, etc).

 This code was extracted from a much larger project so it wasn't really
 written as a standalone library or designed to follow MPL's naming and
 coding conventions.  i.e. don't assume the internals exhibit any great
 design - I was mostly concerned with getting a stand alone package that
 worked in the minimum amount of effort.  It does work fine, every method
 has documentation, and test cases are included (feel free to email me or
 use github if you find any problems) but my real hope is that it either
 serves as an inspiration for building a standard MPL OO style system (or
 perhaps it can be morphed into that over time).

 Some of the features include:
 - Object oriented style objects (no changes to global RC parameters)
 - Apply styles to whole figures or to individual plot elements (artists,
 patches, axes, etc)
 - Save and load styles into human editable files
 - Apply styles by name or by style object
 - Styles remember what they were applied to and can be told to re-apply
 after changes.  This is great way to try out style settings without having
 to regenerate a plot.
 - Plot elements can be tagged with a name.  The tag name can later be used
 as a target in the style application.  This is great feature for plotting
 libraries as it allows a script to create plot elements with a set of names
 and the caller can apply various styles to the plot elements by using those
 names.  This separates plot creation from plot styling and makes plotting
 code much easier to reuse as users don't need to edit the plotting script
 just to change the style of a line.

 Please take a look and let us know what you think.
 Ted
 ps: FYI for clarity I wasn't the primary author of this code - James Evans
 get's that honor with various contributions from a variety of people who
 work on our development team.
 
 --
 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
 Matplotlib-devel@lists.sourceforge.net
 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[Thomas Caswell]

Paul,

Note that by zoom the op means they are changing the bins, not actual
zooming(by just changing the x axis).

I was going to say we deal with normalization by delegating to numpy, but
we actually handle it internally (with a note that when we drop np 1.5 to
make numpy do it).
I think the best course of action here is to do that conversion and forward
this feature request to numpy (if it does not already do this).

Tom

On Sat, Mar 7, 2015, 18:29 Paul Hobson pmhob...@gmail.com wrote:

 IMO, this seems like a bug. I would expect bars to change height with
 zoom/limit levels.
 -p

 —
 Sent from Mailbox https://www.dropbox.com/mailbox


 On Sat, Mar 7, 2015 at 4:20 PM, Tomo Lazovich lazov...@gmail.com wrote:

 Hello matplotlib developers,

 I'm not sure if this is the right mailing list for this question, so
 please re-direct me if it is not.

 I am wondering whether it is possible to have a histogram in pyplot
 normalized to the total length of the list input, rather than just the bins
 showing on the plot (i.e. include those entries in the overflow and
 underflow, off the right and left edges of the plot). As far as I can
 tell, the normed option of pyplot.hist currently makes it so that the area
 under the bins showing is 1. This can lead to a situation like the one
 pasted below, where when I look at the whole histogram the bins have
 certain values but when I try to zoom in to see one part of the plot better
 those values change.

 I can think of two ways to solve this as of now:

 1) Use the weights option to scale each entry by 1/len(input) rather than
 using normed=True.
 2) Somehow add the contents of the overflow to the last bin of the plot,
 which would keep the normalizations constant for earlier bins even if you
 extend the axes.

 Is there a better way of doing this? If the option does not currently
 exist, I am also happy to help implement it if the community would find it
 desirable.

 Thanks for your help!

 Tomo Lazovich

 P.S. Here is a toy example of what I mean:

   import numpy as np
  import matplotlib.pyplot as plt
  h1 = [0, 0, 0, 1, 1, 2, 3]
  my_bins = np.linspace(-0.5, 4.5, 6)
  plt.hist(h1, bins=my_bins, normed=True)
  plt.show()

 gives

  image.png


 Now, if I change the range on the x axis that I would like plot:

   my_bins2 = np.linspace(-0.5, 1.5, 3)
  plt.hist(h1, bins=my_bins2, normed=True)
  plt.show()

  image.png


 The y values have changed to 0.6 and 0.4 because the normalization does
 not include the values that are cut off to the right of the plot.


 
 --
 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
 Matplotlib-devel@lists.sourceforge.net
 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Kivy backend

[Thomas Caswell]

Achyut,

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

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.  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 rastogiach...@gmail.com
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
 Matplotlib-devel@lists.sourceforge.net
 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Animate Contourf with only new frames

[Thomas Caswell]

This should probably be changed to use the new and improved container class
(along with error bar), but I should read the code to be sure.

On Mon, Feb 23, 2015, 11:44 Benjamin Root ben.r...@ou.edu wrote:

 Huh, how about that. ContourSet subclasses ScalarMappable, but not Artist.
 I don't know if that is intentional or not, but given that most plotting
 functions return artists, this would seem to be an anomaly. FuncAnimation
 expects a list of Artists. Since QuadContourSet is (apparently) not an
 Artist, then that is why it isn't working quite right.

 As for blitting, I doubt you are going to need it here. Blitting is really
 only advantagous if the computation/draw time of the animated portion is
 comparable to the computation/draw time of the unanimated portion.
 Contouring tends to be time-consuming (relatively speaking), so I doubt you
 will gain much benefit from blitting it.

 Ben Root

 On Mon, Feb 23, 2015 at 8:53 AM, Ignat Harczuk igna...@gmail.com wrote:

 Firstly I would like to apologize in case this should belong in the
 matplotlib-users, I'm not sure if this is dev or users related.


 Let us say we want to animate a 2D contour plot, then passing the blit =
 True argument to FuncAnimation fails since the QuadContourSet has no axes
 attribute.

 Is it for some specific it is implemented like this? And maybe there a
 hack to get this to work?

 A working code example with the actually wanted one commented out.

 import numpy as np
 import matplotlib.animation as animation
 from matplotlib import pyplot as plt

 fig, ax = plt.subplots()

 x = np.linspace( -np.pi, np.pi, 50 )
 y = np.linspace( -np.pi, np.pi, 50 )
 X, Y = np.meshgrid( x, y )
 Z = np.zeros( X.shape )

 def init():
 cont = ax.contourf( X, Y, Z )
 cbar = plt.colorbar( cont )
 return cont,

 def animate( t ):
 k = np.array( [1,1] )
 omega = 0.5

 x = np.linspace( -np.pi, np.pi, 50 )
 y = np.linspace( -np.pi, np.pi, 50 )
 X, Y = np.meshgrid( x, y )
 Z = np.exp( 1j * (omega* t - X*k[0] ) ) * np.exp( - 1j * k[1]*Y )
 cont = ax.contourf( X, Y, Z )
 return cont,

 #ani = animation.FuncAnimation( fig, animate, frames = 100, interval = 1,
 repeat = False, blit = True, init_func = init,)
 ani = animation.FuncAnimation( fig, animate, frames = 100, interval = 1,
 repeat = False,  init_func = init,)
 plt.show()



 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE

 http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


 
 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=190641631;
 iu=/4140/ostg.clktrk___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

[Thomas Caswell]

@Nathaniel I think developing the color-overhaul as a maintenance release
is a decent compromise.  All non-color changes get directed at the master
branch and we can cherry-picked back bug-fixes as needed.
The next feature release is planned for July/August,  I _really_ hope
sorting out the colors does not take that much longer. if we start to Paint
a Bike Shed that just needs to be shut down.

I am not sure how I feel about a _default_ non-trivial style-cycle.  +1 on
providing the machinery and rcparams to do it and agnostic which branch it
goes on.

@Olga  I think there are two separate issues, the default color map used by
ScalarMappable and the default color cycle that `ax.plot` and company use.
I think both should be up for discussion and do not _need_ to use the same
colors.

Tom

On Wed Feb 18 2015 at 7:43:31 PM Olga Botvinnik obotv...@ucsd.edu wrote:

 FYI the notebook isn't working for me in IPython 2.2.0

 I agree with Michael's sentiment that from a marketing perspective, a
 matplotlib-only colormap is advantageous to maintain a consistent brand.

 Will these colormaps also be used for non-imshow/colormesh/pcolormesh
 data, as in for line colors as well? I think that's a great idea! It'll
 make the black and white versions easier to understand since the changing
 colors will monotonically increase/decrease in darkness rather than
 randomly changing.

 RE: Nathaniel - I'm not as much of a fan of changing line styles in
 addition to colors, but that's my personal preference for plotting lines
 specifically. When plotting scatters, I think it does make sense, since the
 room to perceive a change in color is so small, that a change in shape
 helps too.

 On Wed Feb 18 2015 at 9:40:00 AM Michael Waskom mwas...@stanford.edu
 wrote:

 I've made a second notebook that uses the IPython interactive machinery
 to let anyone play with the parameters and explore different ways of
 setting them. you can download the notebook with that here:
 http://nbviewer.ipython.org/gist/mwaskom/842d1497b6892d081bfb (I made it
 using IPython 3.0rc1; I'm not certain if it will work on the 2.x series;
 sorry if that is the case).

 This stays with the general approach in the original notebook of using a
 linear ramp for chroma, which again maybe is not what we want. But it
 should let you get a better sense for the parameter space.

 As I said in the email to Olga, I think (a) I would advocate fairly
 strongly that matplotlib should design a custom colormap as its default,
 and (b) I think this approach (a cubehelix-like map in Hcl space) is a
 principled way of doing so (though maybe not optimal). But both of those
 points are independent of whether you end up going with the particular
 parameters that I used to generate the original proposal -- I have my own
 domain on which to impose my personal aesthetic preferences, and I don't
 need to take over matplotlib too :)

 (But I do think it's worth distinguishing the matplotlib default from the
 matlab default.)

 Michael

 
 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/
 4140/ostg.clktrk___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

 
 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/
 4140/ostg.clktrk___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] API Documentation usability

[Thomas Caswell]

At risk of sounding defensive, all of the core developers are working mpl
on a mostly volunteer basis and only have so much bandwidth. This leads to
both thing falling through the cracks (we have close to 100 open PRs, that
is _way_ too many) and major re-factors (which every one agrees should be
done) not being done.

I fully agree the docs are less than ideal.  Some of what you suggest is
already on the radar (giving each plotting function it's own page) and a
complete overhaul of the webpage is (very slowly) in the works.
http://matplotlib.org/api/pyplot_summary.html covers some of the use-case
of the table of contents.

The reason that plotting methods appear in both `Axes` and in `pyplot` is
due to the layered design of mpl.  The actual plotting logic is implemented
as methods on the Axes object and the pyplot layer provides a MATLAB-like
state machine to make plotting convenient.  The fact that you have the same
functions in both places is a feature, not a bug ;).  We don't use
decorators for `pyplot.py` because that code pre-dates fully functional
decorators.

This part of the design, the plotting logic being _methods_ on the `Axes`
object, is why the `Axes` class is so large and I do not think can be
broken up in any sensible way (at the code level) short of abandoning it
all together and moving to modules of functions with signatures like
`fun(ax, data, style)`.  This has been discussed, but it is a HUGE change
to the architecture of the library and we are (rightly) moving slowly on
it.  MPL is a widely used mature library which means one of the most
important things we have to do is not break existing user code.

Providing human curation to the docs (a-la numpy) would be great, the main
problem is time.  The core-devs (who seem to enjoy very drudgery) are
already over whelmed, 'update the docs' is not really an exciting thing
that new contributors will jump on, and fixing the docs does require a good
deal of familiarity with the library (so you know where the docs are
wrong/misleading/missing!).

@Fabio  That bit of the already seems pretty modular, but I am not super
familiar with it.  What would you change?

If anyone wants to help with MEP10 that would be great!

Tom

On Mon Feb 16 2015 at 7:02:13 AM Fabio Zanini fabio.zan...@tuebingen.mpg.de
wrote:

 Dear Sebastian,

 I agree with your impression. I made a pull request for some axis
 functionality (logit scales) and the PR got lost. I am convinced that:

 1. working on things like axes, ticker, scales, locators would be a lot
 easier with a little refactoring of the code

 2. with a more modular codebase, my PR would be accepted by now, instead
 of living in limbo waiting to be forgotten.

 So I am in general in favour of your proposal.

 See also: https://github.com/matplotlib/matplotlib/pull/3753

 Cheers,
 Fabio

 PS: if Thomas or anybody else is still willing to accept my PR itself,
 I'd be in favour too. But please do not make me rebase another 3 times
 before that ;-)

 On 02/16/2015 11:42 AM, Sebastian Werhausen wrote:
  I'm a newcomer to the MPL code, and getting an overview is not easy.
  Especially the API part of the documentation [1] has a lot of room for
  improvement. The functionality of the MPL sources seems to be
  scattered quite loosely among the sources and their structure is
  directly mirrored in the doc. Some observations:
 
  1. Many functions like quiver() or bar() are in multiple places
  (pyplot and axes)
  2. Some entries (like axes) are enormous, making them very hard to use
  to get an overview
  3. The API start page is just a lose list of classes, without
  indication what's inside
 
  Ideally I feel like the code itself should be organized in smaller
  chunks, but that's probably unrealistic. A quick improvement for 2.
  could be to add a table of contents at the top of every class
  documentation. For axes, that could work like [2] and look like [3].
  Thoughts? I wanted to test the waters before making pull requests.
 
  Another way could be to organize the documentation not by classes, but
  by functionality. The Numpy docs [4] seem much more usable in that
  regard. That'll be less automatic of course but could help with
  observation 3.
 
  I've also found the Mep10 [5] on the Wiki with many good ideas, but
  not sure if that lead somewhere.
 
  Sebastian
 
 
  [1] http://matplotlib.org/api/index.html
  [2] https://github.com/s9w/matplotlib/commit/
 053179c9491637609775e21855f21e977580a0a1
  [3] http://i.imgur.com/d1uTjfS.png
  [4] http://docs.scipy.org/doc/numpy/reference/
  [5] https://github.com/matplotlib/matplotlib/wiki/Mep10
 
  
 --
  Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
  from Actuate! Instantly Supercharge Your Business Reports and Dashboards
  with Interactivity, Sharing, Native Excel Exports, App Integration  more
  Get technology previously reserved for billion-dollar corporations, FREE
  

[matplotlib-devel] matplotlib v1.4.3

[Thomas Caswell]

Hello all,

We are pleased to announce the release of matplotlib v1.4.3!

Wheels, windows binaries and the source tarball are available through both
source-forge [1]  and pypi (via pip).  Additionally the source is available
tarball is available from github [2] and mac-wheels from
http://wheels.scikit-image.org/.

This is the last planned bug-fix release in the 1.4 series.

Many bugs are fixed including:

   - fixing drawing of edge-only markers in AGG
   - fix run-away memory usage when using %inline or saving with a tight
   bounding box with QuadMesh artists
   - improvements to wx and tk gui backends

Additionally the webagg and nbagg backends were brought closer to
feature parity with the desktop backends with the addition of keyboard
and scroll events thanks to Steven Silvester.

The next planned release will be based on the 1.4.x series but will change
the default colors and be tagged as version v2.0. The target release date
is in the next month or two.

The next feature release will be v2.1 targeted for around SciPy in July.

Tom


[1]
https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.4.3/

[2] https://github.com/matplotlib/matplotlib/releases/tag/v1.4.3
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] v1.4.3

[Thomas Caswell]

Hey all,

I have tagged 1.4.3.

Once the binaries are built I will get everything pushed up to pypi and
make a wider announcement.

As discussed before, this will be the last planned release in the 1.4
series.

Tom
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Release planning/milestones

[Thomas Caswell]

Ah, no I mean the exact opposite!

My proposal is to cut 2.0 off of what ever the current stable release is
(ex, 1.4.3) and then merge that into master.  The next minor release would
then be 2.1 and there would be no new 1.Y releases.

Tom



On Sun Feb 08 2015 at 2:04:24 PM Sandro Tosi mo...@debian.org wrote:

 Hi all!

 On Sun, Feb 8, 2015 at 12:13 AM, Thomas Caswell tcasw...@gmail.com
 wrote:
  Hey all,
 
  To start with, the 2.0 release is pending a choice of new default color
 map.
  I think that when we pick that we should cut 2.0 off of the last release
 and
  then the next minor release turns into 2.1.  If we want to do other
 breaking
  changes we will just do a 3.0 when that happens.  It makes sense to me to
  bundle default color changes as one set of breaking changes and code API
  changes as another.
 
  Eric made the case in an issue that we should not continue the 1.4.x
 series
  and start working 1.5.0, which fits well with aiming for a 6month
 scheduled
  release cycle (minor release in July, bug-fix release in February).

 Do I understand correctly you plan to maintain 2 separate development
 lines (like Python with 2.x and 3.x) as 1.5.x and 2.x ?

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

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] v1.4.3rc1

[Thomas Caswell]

Sandro,

Well, creating the tarball on GH is a lot easier for us as it happens
automatically!  I don't want to unilaterally change policy so I will create
the files on SF.

If you want to tracking GH for debian instead of SF I don't think that
would be a bad idea, but I don't know how much of a hassle that would be
for you.

Tom

On Sat Feb 07 2015 at 4:14:36 PM Sandro Tosi mo...@debian.org wrote:

 On Sat, Feb 7, 2015 at 9:05 PM, Thomas Caswell tcasw...@gmail.com wrote:
  Sandro,
 
  Can you use the tarball from github
  (https://github.com/matplotlib/matplotlib/archive/v1.4.3rc1.tar.gz ?)

 Sure I can, but since all the previous release (even RC) were done one
 SF, we have our tools to monitor and download new releases pointing to
 SF: do you plan to switch to GH for releasing tarballs too?

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

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] v1.4.3rc1

[Thomas Caswell]

Sandro,

Can you use the tarball from github (
https://github.com/matplotlib/matplotlib/archive/v1.4.3rc1.tar.gz ?)

Tom

On Sat Feb 07 2015 at 4:01:01 PM Sandro Tosi mo...@debian.org wrote:

 Hi Thomas,

 On Mon, Feb 2, 2015 at 5:37 AM, Thomas Caswell tcasw...@gmail.com wrote:
  Evening all,
 
  I have tagged the first release candidate for v1.4.3
  (https://github.com/matplotlib/matplotlib/releases/tag/v1.4.3rc1).
 ...
  Please kick the tires and give it a try!  If there are no major issues,
 the
  plan is to target 1.4.3 for next weekend.

 could you also release a tarball on SF, so I can start updating the
 debian package and give it a spin on our distro?

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

--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Release planning/milestones

[Thomas Caswell]

Hey all,

To start with, the 2.0 release is pending a choice of new default color
map.  I think that when we pick that we should cut 2.0 off of the last
release and then the next minor release turns into 2.1.  If we want to do
other breaking changes we will just do a 3.0 when that happens.  It makes
sense to me to bundle default color changes as one set of breaking changes
and code API changes as another.

Eric made the case in an issue that we should not continue the 1.4.x series
and start working 1.5.0, which fits well with aiming for a 6month scheduled
release cycle (minor release in July, bug-fix release in February).

To this end, I have clean out and close the 1.4.x milestone (most of issues
just got moved 1.5.0) and created a 1.5.0 milestone.  I set a target for
1.5.0 to be released at scipy as that seems like a reasonable thing to.
Targeting just after SciPy also makes sense so we have a clear list of
things to work on at the sprints.  Thoughts?

My internal list of what we should try to get in for 1.5.0 are:

 - visitor pattern on all artists + recreating figure from it's visited
artists.  This gets us a) proper serialization of our figures instead of
going through pickles and b) makes interoperability with plotly/b3/bokeh
easier

 - pyplot overhaul (use decorators, provide decorators as part of public
API)

 - navigation by events (PR #3652 + MEP22)

 - making OO interface easier to use interactively (if interactive,
auto-redraw at sensible time)

 - pull the pyplot state machine out of backend_bases and expose the
figure_manager classes

 - overhaul the website

Anything else people think should be on the list or any protests to this
list?

Tom
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] python write up in nature

[Thomas Caswell]

May be of interest:

http://www.nature.com/news/programming-pick-up-python-1.16833

We get mention down towards the bottom.

Tom
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Job posting

[Thomas Caswell]

Hey all,

If anyone is interested, there is a software position open at BNL in the
group I work with:

https://www.bnl.gov/hr/careers/jobs/?cpUrl=https://careers.peopleclick.com/careerscp/Client_BrookhavenLab/external/en_US/gateway.do?functionName=viewFromLinklocaleCode=en-usjobPostId=525

Please forward this to anyone who might be interested.

Tom
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] ginput in nbagg backend to use in IPython Notebooks

[Thomas Caswell]

I would keep an eye on scikit-image and their viewer work.  One of the
drivers behind Steven working on the nbagg backend was prep work to port
their imageviewer code over to using nbagg from than qt.

I think it is also possible to interact between ipython widgets and
figure/axes objects with nbagg.

Tom

On Tue Jan 27 2015 at 12:20:32 PM Eric Firing efir...@hawaii.edu wrote:

 On 2015/01/27 6:51 AM, Mark wrote:
  ginput works fine in a GUI window, but there is no matplotlib widget
  where I can type text or numbers in a box. Like the FloatTextWidget in
  IPython. Or am I missing something?

 I think you are correct.  John Hunter explicitly avoided the temptation
 to keep adding backend-independent widgets to mpl; we have a hard enough
 time trying to maintain and improve the plotting capabilities without
 trying to turn mpl into a wxwidgets work-alike.  If you need more than
 the very minimal widgets presently on offer, you have to choose a gui
 toolkit and use it directly, embedding matplotlib in it.

 Eric

 
  Sent from my iPhone
 
  On Jan 27, 2015, at 17:34, Paul Hobson pmhob...@gmail.com
  mailto:pmhob...@gmail.com wrote:
 
  I'm 99% sure you can do this in a GUI window. Does your solution have
  to be in the notebook?
 
  On Tue, Jan 27, 2015 at 12:37 AM, Mark Bakker mark...@gmail.com
  mailto:mark...@gmail.com wrote:
 
  Thanks, Tom.
 
  I want to use ginput to draw a straight line on a graph.
  The line is used to select a cross-section of a contour plot.
 
  I was afraid it wasn't going to be easy.
 
  Getting to it from the other side, is there a matplotlib widget in
  the works where I can type text or numbers in a box? Like
  the FloatTextWidget in IPython?
 
  Problem is I want to make a small GUI that includes both a text
  widget (which is available in IPython) and a 'select points in
  graph' widget like ginput in matplotlib.
 
  Mark
 
 
  On Mon, Jan 26, 2015 at 11:47 PM, Thomas Caswell
  tcasw...@gmail.com mailto:tcasw...@gmail.com wrote:
 
  nbagg is always running in the IPython event loop (as I
  understand it), so I am not sure how to integrate that with
  the blocking.
 
  On the 1.4.x/master branch we have support for (almost, one PR
  still pending) all mouse and keyboard events so all of the mpl
  widgets should work (big thanks to Steven Silvester).  T
 
  What do you want to use that relies on ginput?
 
  You can fake up a non-blocking version something like:
 
  from collections import deque
  ```
  class accumulator(object):
  def __init__(self, n=5):
  self.list_of_points = deque(maxlen=n)
  def on_event(self, event):
  self.list_of_points.append(event)
 
  import matplotlib
  import itertools
  import numpy as np
  matplotlib.use('nbagg')
  import matplotlib.pyplot as plt
  plt.close('all')
  fig, ax = plt.subplots()
  x = np.linspace(0,10,1)
  y = np.sin(x)
  ln, = ax.plot(x,y)
 
  dd = accumulator(15)
  fig.canvas.mpl_connect('button_press_event', dd.on_event)
  plt.show()
  ```
 
  and then get the points by
 
  ```
  dd.lest_of_points
  ```
 
  This code obviously needs lots of bells and whistles, but
  points in the right direction.
 
  Tom
 
  On Mon Jan 26 2015 at 2:45:45 PM Mark Bakker
  mark...@gmail.com mailto:mark...@gmail.com wrote:
 
  Hello List,
 
  Are there any plans to make ginput work in the nbagg
 backend?
 
  It would be so cool if I could use that in an IPython
  Notebook together with the other widgets.
 
  Thanks,
 
  Mark
  --
 __--__--
 
 
 
  
 --
  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
  Matplotlib-devel@lists.sourceforge.net
  mailto:Matplotlib-devel@lists.sourceforge.net
  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

Re: [matplotlib-devel] using waffle.io for issue management

[Thomas Caswell]

The column asignments are tags + open/close status.

https://waffle.io/matplotlib/matplotlib/settings/columns _should_ drop you
to the webpage that lets you see how they are controlled (you might need to
log in to see it).  It has been set up for a while now and no one has
complained about GH breaking, so I think it is pretty side-effect less.

Tom

On Tue Jan 20 2015 at 5:10:47 PM Eric Firing efir...@hawaii.edu wrote:

 Looks good to me.  As far as I can see, it is not doing anything that
 would interfere with ordinary direct github use.

 What determines the column assignments?  A combination of tags and
 open/closed status?  Is there something else going on?

 Eric

 On 2015/01/20 6:13 AM, Michael Droettboom wrote:
  I like it.  I could make some nitpicks, but I think it's clearly
  superior to raw github alone, and on that basis I have no objections.  I
  think we should make sure we don't make the experience using github
  alone any worse, though, as I'm sure for some the familiarity there from
  other projects will be most important.  It doesn't *seem* like it does,
  but I think it's important to consider.
 
  Mike
 
  On 01/18/2015 04:52 PM, R Hattersley wrote:
  You need an extra matplotlib ... https://waffle.io/matplotlib/
 matplotlib
 
  On 17 January 2015 at 19:29, Thomas Caswell tcasw...@gmail.com
  mailto:tcasw...@gmail.com wrote:
 
  Hey all,
 
  We have set up waffle.io http://waffle.io to try and help manage
  our issues: https://waffle.io/matplotlib/
 
  If you have commit rights, you should be able to move the cards
  around.
 
  Any thoughts on this tool? I would like to use this to keep track
  of the review state of PRs.
 
  Tom
 
  
 --
  New Year. New Location. New Benefits. New Data Center in Ashburn,
 VA.
  GigeNET is offering a free month of service with a new server in
  Ashburn.
  Choose from 2 high performing configs, both with 100TB of bandwidth.
  Higher redundancy.Lower latency.Increased capacity.Completely
  compliant.
  http://p.sf.net/sfu/gigenet
  ___
  Matplotlib-devel mailing list
  Matplotlib-devel@lists.sourceforge.net
  mailto:Matplotlib-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
 
 
 
 
  
 --
  New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
  GigeNET is offering a free month of service with a new server in
 Ashburn.
  Choose from 2 high performing configs, both with 100TB of bandwidth.
  Higher redundancy.Lower latency.Increased capacity.Completely compliant.
  http://p.sf.net/sfu/gigenet
 
 
  ___
  Matplotlib-devel mailing list
  Matplotlib-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
 
 
  --
  Michael Droettboom
  Science Software Branch
  Space Telescope Science Institute
 
  http://www.droettboom.com
 
 
 
  
 --
  New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
  GigeNET is offering a free month of service with a new server in Ashburn.
  Choose from 2 high performing configs, both with 100TB of bandwidth.
  Higher redundancy.Lower latency.Increased capacity.Completely compliant.
  http://p.sf.net/sfu/gigenet
 
 
 
  ___
  Matplotlib-devel mailing list
  Matplotlib-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
 


 
 --
 New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely compliant.
 http://p.sf.net/sfu/gigenet
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] using waffle.io for issue management

[Thomas Caswell]

Hey all,

We have set up waffle.io to try and help manage our issues:
https://waffle.io/matplotlib/

If you have commit rights, you should be able to move the cards around.

Any thoughts on this tool? I would like to use this to keep track of the
review state of PRs.

Tom
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] v1.4.3 prep

[Thomas Caswell]

Hello all,

I would like to try to hit the Feb 1 target date for 1.4.3 and plan to do
an RC next Monday (Jan 19).

Any major protests from anyone on this timeline?

If people could take a look at the 1.4.3 and 1.4.x milestones on github and
either move stuff around (in terms of finding any blockers) or to get some
of the issues (in particular the quiver and documentation related ones)
taken care of that would be great!

Tom
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Date overhaul?

[Thomas Caswell]

One of the other driving factors to over-haul the default date handling is
that floats do not have enough precision to deal with nano-second
resolution data (which is what I think drove pandas to use datetime64).

It sounds like the correct solution

Is the unit framework documented anywhere and are those custom classes
public?

Tom

On Thu Jan 08 2015 at 12:59:17 PM Drain, Theodore R (392P) 
theodore.r.dr...@jpl.nasa.gov wrote:

  I agree w/ the original poster that it would help to have a MEP to
 clearly define what the goals of the overhaul are



 Something else to keep in mind: we at least don't normally plot dates in
 earth based time systems.  ~10 years ago we contracted with John Hunter
 to add the arbitrary unit system to MPL.  This allows users to plot in
 their own data types and define a converter to handle the conversion to MPL
 types and labeling.  We have our own date time like class which handles
 relativistic time scales (TDB, TT, TAI, GPS, Mars time, etc) at extremely
 high precision.  We register a unit converter w/ MPL which allows our users
 to plot these types natively and use the xunits keyword (or yunits) to
 control how the plot looks.  So we can do this:



 plot( x, y, xunits=GPS, yunits=km/s )

 plot( x, y, xunits=PST, yunits=mph )



 It would also be pretty easy to add a time zone aware unit converter with
 the existing MPL code which would allow you to do things w/ datetime like
 this:



 plot( x, y, xunits=UTC+8 )

 plot( x, y, xunits=EST )



 I guess the point of this is to remind folks that not everyone plots dates
 in time zone based systems...



 Ted


  --
 *From:* Chris Barker [chris.bar...@noaa.gov]
 *Sent:* Thursday, January 08, 2015 9:00 AM
 *To:* matplotlib-devel@lists.sourceforge.net
 *Subject:* Re: [matplotlib-devel] Date overhaul?

On Thu, Jan 8, 2015 at 7:04 AM, Skip Montanaro s...@pobox.com wrote:

 I'm real naive about this stuff, but I have always wondered why
 matplotlib didn't just use datetime objects, or at least use
 timezone-aware datetime objects as an interchange format to get the
 timezone stuff right.


  Time zone handling is a pain in the %}€*

  And the definitions keep changing.

  So you need a complex DB and library that needs frequent updating.

  This is why neither the standard library nor numpy support time zone
 handling out of the box.

  But the datetime object does support a hook to add timezone info.

  The numpy datetime64 may implementation   _may_ provide a similar hook
 in the future.

  There is the pytz package, which MPL could choose to depend on.

  But even that is a bit ugly--e.g. from the pytz docs:

  Unfortunately using the tzinfo argument of the standard datetime
 constructors ‘’does not work’’ with pytz for many timezones.

 So my suggestion is that MPL punts, and stick with leaving time zone
 handling up to the user, I.e only use datetimes that are timezone naive.
 What this means is that MPL would always a assume all datetimes interacting
 with each other are in the same time zone (including same DST status).

 Anyway, I'm being a bit lazy here, so I may be wrong, but I think the
 issue at hand is that MPL currently uses a float array to store and
 manipulate datetimes, and the thought is that it may be better to use
 numpy datetime64 arrays -- that would give us more consistent precision,
 and less code to convert to/from various datetime formats.
 I'm a bit on the fence about whether it's time to do it, as datetime64
 does have issues with the locale timezone, but as any implementation would
 want to work with not-just-the-latest numpy anyway, it may make sense to
 start now.

 -Chris






  --

 Christopher Barker, Ph.D.
 Oceanographer

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

 chris.bar...@noaa.gov
   
 --
 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
 Matplotlib-devel@lists.sourceforge.net
 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. 

Re: [matplotlib-devel] Date overhaul?

[Thomas Caswell]

I was hoping for something a bit more extensive of the intenals.  I have
tried to understand the units code a couple of times now and always hit a
brick wall.

On Thu Jan 08 2015 at 2:07:02 PM Drain, Theodore R (392P) 
theodore.r.dr...@jpl.nasa.gov wrote:

  Google search matplotlib units yields:
 http://matplotlib.org/api/units_api.html



 So it sounds like the update is to make MPL's internal date system higher
 resolution which would be great.   We would just need to update our
 converters to convert to that format instead of the current floating point
 format.  Our custom classes are not public (and can't really be made
 public) but they aren't very complicated so we can certainly talk about the
 implementation if that helps.


  --
 *From:* Thomas Caswell [tcasw...@gmail.com]
 *Sent:* Thursday, January 08, 2015 10:57 AM
 *To:* Drain, Theodore R (392P); matplotlib-devel@lists.sourceforge.net

 *Subject:* Re: [matplotlib-devel] Date overhaul?
  One of the other driving factors to over-haul the default date handling
 is that floats do not have enough precision to deal with nano-second
 resolution data (which is what I think drove pandas to use datetime64).

  It sounds like the correct solution

  Is the unit framework documented anywhere and are those custom classes
 public?

  Tom

 On Thu Jan 08 2015 at 12:59:17 PM Drain, Theodore R (392P) 
 theodore.r.dr...@jpl.nasa.gov wrote:

  I agree w/ the original poster that it would help to have a MEP to
 clearly define what the goals of the overhaul are



 Something else to keep in mind: we at least don't normally plot dates in
 earth based time systems.  ~10 years ago we contracted with John Hunter
 to add the arbitrary unit system to MPL.  This allows users to plot in
 their own data types and define a converter to handle the conversion to MPL
 types and labeling.  We have our own date time like class which handles
 relativistic time scales (TDB, TT, TAI, GPS, Mars time, etc) at extremely
 high precision.  We register a unit converter w/ MPL which allows our users
 to plot these types natively and use the xunits keyword (or yunits) to
 control how the plot looks.  So we can do this:



 plot( x, y, xunits=GPS, yunits=km/s )

 plot( x, y, xunits=PST, yunits=mph )



 It would also be pretty easy to add a time zone aware unit converter with
 the existing MPL code which would allow you to do things w/ datetime like
 this:



 plot( x, y, xunits=UTC+8 )

 plot( x, y, xunits=EST )



 I guess the point of this is to remind folks that not everyone plots
 dates in time zone based systems...



 Ted


  --
 *From:* Chris Barker [chris.bar...@noaa.gov]
 *Sent:* Thursday, January 08, 2015 9:00 AM
 *To:* matplotlib-devel@lists.sourceforge.net
 *Subject:* Re: [matplotlib-devel] Date overhaul?

   On Thu, Jan 8, 2015 at 7:04 AM, Skip Montanaro s...@pobox.com
 wrote:

 I'm real naive about this stuff, but I have always wondered why
 matplotlib didn't just use datetime objects, or at least use
 timezone-aware datetime objects as an interchange format to get the
 timezone stuff right.


  Time zone handling is a pain in the %}€*

  And the definitions keep changing.

  So you need a complex DB and library that needs frequent updating.

  This is why neither the standard library nor numpy support time zone
 handling out of the box.

  But the datetime object does support a hook to add timezone info.

  The numpy datetime64 may implementation   _may_ provide a similar hook
 in the future.

  There is the pytz package, which MPL could choose to depend on.

  But even that is a bit ugly--e.g. from the pytz docs:

  Unfortunately using the tzinfo argument of the standard datetime
 constructors ‘’does not work’’ with pytz for many timezones.

 So my suggestion is that MPL punts, and stick with leaving time zone
 handling up to the user, I.e only use datetimes that are timezone naive.
 What this means is that MPL would always a assume all datetimes interacting
 with each other are in the same time zone (including same DST status).

 Anyway, I'm being a bit lazy here, so I may be wrong, but I think the
 issue at hand is that MPL currently uses a float array to store and
 manipulate datetimes, and the thought is that it may be better to use
 numpy datetime64 arrays -- that would give us more consistent precision,
 and less code to convert to/from various datetime formats.
 I'm a bit on the fence about whether it's time to do it, as datetime64
 does have issues with the locale timezone, but as any implementation would
 want to work with not-just-the-latest numpy anyway, it may make sense to
 start now.

 -Chris






  --

 Christopher Barker, Ph.D.
 Oceanographer

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

 chris.bar...@noaa.gov

Re: [matplotlib-devel] Who runs our twitter account?

[Thomas Caswell]

We have a Twitter account?!?

On Fri, Dec 19, 2014, 20:05 Benjamin Root ben.r...@ou.edu wrote:

 I just realized today that people have been posting questions to a
 matplotlib handle on twitter, but it hasn't posted any tweets since April.

 Same issue for numpy as well, it seems.

 Ben Root
 
 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=164703151;
 iu=/4140/ostg.clktrk___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] whats_new and api_changes

[Thomas Caswell]

There should be an automatic process, but no one has written it yet. I
think IPython has code we can adapt in their doc build process. I had
planned to deal with this when we cut the next minor/major release.

Tom

On Thu, Nov 27, 2014, 04:18 Ian Thomas ianthoma...@gmail.com wrote:

 Fellow developers,

 I know we are now encouraged when writing a PR not to alter
 doc/users/whats_new.rst and doc/api/api_changes.rst directly, but rather to
 create files in the doc/users/whats_new and doc/api/api_changes directories
 instead.  When building the master branch docs I was expecting the contents
 of these new files to be automagically incorporated in the appropriate doc
 sections, but this does not happen on my development system (ubuntu 14.04,
 python 2.7, sphinx 1.2.2).

 I figure either I am doing something wrong, or this is a bug, or there is
 manual process at release time to cut and paste the new files into the
 parent files.  Which is it?

 Ian
 
 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=157005751;
 iu=/4140/ostg.clktrk___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] whats_new and api_changes

[Thomas Caswell]

For reference, the IPython script is in tools/update_whatsnew.py



On Thu Nov 27 2014 at 11:58:40 AM Ian Thomas ianthoma...@gmail.com wrote:

 On 27 November 2014 at 16:16, Thomas Caswell tcasw...@gmail.com wrote:

 There should be an automatic process, but no one has written it yet. I
 think IPython has code we can adapt in their doc build process. I had
 planned to deal with this when we cut the next minor/major release.

 Tom


 Thanks for letting me know Tom.

 Ian

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Matplotlib's new default colormap

[Thomas Caswell]

That is super cool.  I was thinking about doing something similar, glad it
has already been so well done.

The example figures at the bottom bring up another point, we should have a
canonical set of test figures, both for the color map and the defaults in
general, I think that will really help with this discussion.

That example could also be reused as a standard show-case for style-files.

Tom


On Mon Nov 24 2014 at 11:32:41 AM Michael Droettboom md...@stsci.edu
wrote:

  I, for one, would love to see a pull request for this if you're game.

 Mike


 On 11/24/2014 04:27 AM, Lion Krischer wrote:

 Hi all,

 I was made aware of this thread and thought I’d share a notebook I
 recently made for a similar purpose:

 http://nbviewer.ipython.org/gist/krischer/d35096a9d3b6da5846a5 (takes a
 while to load…)

 It attempts to “optimize colormaps by defining optimality as having a
 linear lightness across the colormap in LAB color space. It is very simple
 and not a proper optimization procedure. It just goes to LAB space, sets
 the lightness to the target lightness, and goes back to sRGB space. This
 does not always work as the LAB color space is much bigger than the RGB one
 but in many cases it produces fairly good results.

 The nice thing about this is that the lightness range can be chosen so it
 is does not always have to be stark white or black at the ends and some hue
 can be preserved.

 I am not sure if some similar functionality is useful to include into
 matplotlib (I don’t really think so) but if yes, let me know and I’ll give
 it a try. I guess it could also be extended to optimize towards monotonic
 changes in hue.

 Cheers and all the best!

  Lion



 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, 
 FREEhttp://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk



 ___
 Matplotlib-devel mailing 
 listMatplotlib-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/matplotlib-devel



 --
 Michael Droettboom
 Science Software Branch
 Space Telescope Science Institute
 http://www.droettboom.com

  
 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/
 4140/ostg.clktrk___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Matplotlib's new default colormap

[Thomas Caswell]

The contents of that talk are also in our documentation
http://matplotlib.org/users/colormaps.html

Tom

On Sat Nov 22 2014 at 9:33:11 AM gary ruben gary.ru...@gmail.com wrote:

 There was a talk by Kristen Thyng at scipy2014 that might be a good
 backgrounder for this:
 http://pyvideo.org/video/2769/perceptions-of-matplotlib-colormaps

 At the end she references this site http://mycarta.wordpress.com/ of
 Matteo Niccoli which is full of good content. I wonder if it's worth
 contacting Kristen or Matteo to let them know there's a discussion going on
 here that they might be interested in?


 On 22 November 2014 at 09:53, Eric Firing efir...@hawaii.edu wrote:

 On 2014/11/21, 4:42 PM, Nathaniel Smith wrote:
  On Fri, Nov 21, 2014 at 5:46 PM, Darren Dale dsdal...@gmail.com
 wrote:
  On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson pelson@gmail.com
 wrote:
 
  Please use this thread to discuss the best choice for a new default
  matplotlib colormap.
 
  This follows on from a discussion on the matplotlib-devel mailing list
  entitled How to move beyond JET as the default matplotlib colormap.
 
 
  I remember reading a (peer-reviewed, I think) article about how jet
 was a
  very unfortunate choice of default. I can't find the exact article
 now, but
  I did find some other useful ones:
 
 
 http://cresspahl.blogspot.com/2012/03/expanded-control-of-octaves-colormap.html
  http://www.sandia.gov/~kmorel/documents/ColorMaps/
 
 http://www.sandia.gov/~kmorel/documents/ColorMaps/ColorMapsExpanded.pdf
 
  Those are good articles. There's a lot of literature on the problems
  with jet, and lots of links in the matplotlib issue [1]. For those
  trying to get up to speed quickly, MathWorks recently put together a
  nice review of the literature [2]. One particularly striking paper
  they cite studied a group of medical students and found that (a) they
  were used to/practiced at using jet, (b) when given a choice of
  colormaps they said that they preferred jet, (c) they nonetheless made
  more *medical diagnostic errors* when using jet than with better
  designed colormaps (Borkin et al, 2011).
 
  I won't suggest a specific colormap, but I do propose that whatever we
  chose satisfy the following criteria:
 
  - it should be a sequential colormap, because diverging colormaps are
  really misleading unless you know where the center of the data is,
  and for a default colormap we generally won't.
 
  - it should be perceptually uniform, i.e., human subjective judgements
  of how far apart nearby colors are should correspond as linearly as
  possible to the difference between the numerical values they
  represent, at least locally. There's lots of research on how to
  measure perceptual distance -- a colleague and I happen to have
  recently implemented a state-of-the-art model of this for another
  project, in case anyone wants to play with it [3], or just using
  good-old-L*a*b* is a reasonable quick-and-dirty approximation.
 
  - it should have a perceptually uniform luminance ramp, i.e. if you
  convert to greyscale it should still be uniform. This is useful both
  in practical terms (greyscale printers are still a thing!) and because
  luminance is a very strong and natural cue to magnitude.
 
  - it should also have some kind of variation in hue, because hue
  variation is a really helpful additional cue to perception, having two
  cues is better than one, and there's no reason not to do it.
 
  - the hue variation should be chosen to produce reasonable results
  even for viewers with the more common types of colorblindness. (Which
  rules out things like red-to-green.)
 
  And, for bonus points, it would be nice to choose a hue ramp that
  still works if you throw away the luminance variation, because then we
  could use the version with varying luminance for 2d plots, and the
  version with just hue variation for 3d plots. (In 3d plots you really
  want to reserve the luminance channel for lighting/shading, because
  your brain is *really* good at extracting 3d shape from luminance
  variation. If the 3d surface itself has massively varying luminance
  then this screws up the ability to see shape.)
 
  Do these seem like good requirements?

 Goals, yes, though I wouldn't put much weight on the bonus criterion.
   I would add that it should be aesthetically pleasing, or at least
 comfortable, to most people.  Perfection might not be attainable, and
 some tradeoffs may be required. Is anyone set up to produce test images
 and/or metrics for judging existing colormaps, or newly designed ones,
 on all of these criteria?

 Eric

 
  -n
 
  [1] https://github.com/matplotlib/matplotlib/issues/875
  [2]
 http://uk.mathworks.com/company/newsletters/articles/rainbow-color-map-critiques-an-overview-and-annotated-bibliography.html
  [3] https://github.com/njsmith/pycam02ucs ; install (or just run out
  of the source tree) and then use pycam02ucs.deltaEp_sRGB to compute
  the perceptual distance between two RGB colors. It's 

Re: [matplotlib-devel] How to move beyond JET as the default matplotlib colormap

[Thomas Caswell]

I am a bit wary of doing a 2.0 _just_ to change the color map, but when
every I try to write out why, they don't sound convincing.  We may end up
with a 3.0 within a year or so due to the possible plotting API/pyplot work
that is (hopefully) coming.

If we are going to do this, I think we should do the 1.4.3 release
(scheduled for Feb 1, RCs in mid January), then put one commit to change
the color map on top of that, tag 2.0 and then master turns into 2.1.x
(targeted for right after scipy?).

There is also the thought to get the major c++ refactor work tagged and
released sooner rather than later so maybe we want to do 1.4.3, 1.5.0 and
2.0 in Feb with 2.0 based off of 1.5 not 1.4.

On Fri Nov 21 2014 at 12:52:03 PM Benjamin Root ben.r...@ou.edu wrote:

 As a point of clarification, is this proposed 2.0 release different from
 the 1.5 release?

 On Fri, Nov 21, 2014 at 12:32 PM, Phil Elson pelson@gmail.com wrote:

 Many of you will be aware of there has been an ongoing issue (#875,
 http://goo.gl/xLZvuL) which recommends the removal of Jet as the default
 colormap in matplotlib.

 The argument against Jet is compelling and I think that as a group who
 care about high quality visualisation we should be seriously discussing how
 matplotlib can move beyond Jet.

 There was recently an open letter to the climate science community
 http://www.climate-lab-book.ac.uk/2014/end-of-the-rainbow/ asking for
 scientists to pledge against using rainbow like colormaps (such as Jet),
 and there are similar initiatives in other scientific fields, as well as
 there being a plethora of well researched literature on the subject.

 As such, it's time to agree on a solution on how matplotlib can reach the
 end of the rainbow.


 The two major hurdles, AFAICS, to replacing the three little characters
 which control the default colormap of matplotlib are:

  * We haven't had a clear (decisive) discussion about what we should
 replace Jet with.
  * There are concerns about changing the default as it would change the
 existing widespread behaviour.

 To address the first point I'll start a new mailinglist thread (entitled
 Matplotlib's new default colormap) where new default colormap suggestions
 can be made. The thread should strictly avoid +1 type comments, and
 generally try to stick to reference-able/demonstrable fact, rather than
 opinion. There *will* be a difference of opinion, however the final
 decision has to come down to the project lead (sorry Mike) who I know will
 do whatever is necessary to make the best choice for matplotlib.

 The second point is a reasonable response when we consider that
 matplotlib as a project has no *clear* statement on backwards
 compatibility. As a result, matplotlib is highly change averse between
 minor releases (to use semantic versioning terms) and therefore changing
 the default colormap is unpalatable in the v1.x release series. As a result
 I'd like to propose that the next release of matplotlib be called 2.0, with
 the *only* major backwards-incompatible change be the removal of Jet as
 the default colormap.

 As a project matplotlib mustn't get caught up in the trap of shying away
 from a major version release when the need arises, and in my opinion
 helping our users to avoid using a misleading colormap is a worthy cause
 for a v2.0.

 Please try to keep this thread on the how, and not on the what of the
 replacement default colormap, for which there is a dedicated thread.

 Thanks,

 Phil

 (#endrainbow)


 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE

 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


 
 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=157005751;
 iu=/4140/ostg.clktrk___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with 

Re: [matplotlib-devel] Axes.scatter call fails since removal of PyCXX

[Thomas Caswell]

Ah, never mind then, I just got out of sync.

On Wed, Nov 19, 2014, 04:04 Joel B. Mohler j...@kiwistrawberry.us wrote:

 On 11/18/2014 08:29 PM, Thomas Caswell wrote:

 Is there an issue for this (and if not can you make one)?


 This is https://github.com/matplotlib/matplotlib/pull/3811 which is fixed
 and merged.  Should it still be an issue?



 On Mon, Nov 17, 2014, 09:56 Joel B. Mohler j...@kiwistrawberry.us wrote:

 On Mon, Nov 17, 2014 at 09:36:50AM -0500, Joel B. Mohler wrote:
  I think I see a breakage of the scatter call that I think should work
 and did
  work before
 
 https://github.com/matplotlib/matplotlib/commit/be34210a8c09fcd639ece583eb5c0acb855222b6
 
  This is running on windows 7 (32 bit) with numpy 1.8 and current master.

 Ugh, I tried this same example on my ubuntu box and it works.  I update
 this
 diagnosis to scatter is broken on windows since removing PyCXX; note
 that I
 do not get a traceback with the code below if I replace scatter with
 plot.

 Being that windows devs are scarce, I'll be digging into this more.  I
 certainly welcome any clues as it seems very bizarre to me so far.

 Joel

 
  The example is:
 
  ***
  import numpy
  from matplotlib.backends.backend_agg import FigureCanvasAgg as
 FigureCanvas
  from matplotlib.figure import Figure
 
  POINTS = 500
 
  figure = Figure(figsize=(6, 6), dpi=72)
  ax = figure.add_subplot(1, 1, 1, projection=None)
  scat = ax.scatter(numpy.arange(POINTS), numpy.sin(numpy.arange(POINTS)))
  ***
 
  I get on current master
 
  ***
  Traceback (most recent call last):
File C:\work\mpl_scatter_example.py, line 9, in module
  scat = ax.scatter(numpy.arange(POINTS),
 numpy.sin(numpy.arange(POINTS)))
File C:\Python27\lib\site-packages\matplotlib\axes\_axes.py, line
 3690, in scatter
  self.add_collection(collection)
File C:\Python27\lib\site-packages\matplotlib\axes\_base.py, line
 1459, in add_collection
  self.update_datalim(collection.get_datalim(self.transData))
File C:\Python27\lib\site-packages\matplotlib\collections.py, line
 198, in get_datalim
  offsets, transOffset.frozen())
File C:\Python27\lib\site-packages\matplotlib\path.py, line 977, in
 get_path_collection_extents
  master_transform, paths, transforms, offsets,offset_transform))
  ValueError: object too deep for desired array
  ***
 
  I did very little troubleshooting beyond confirming that this works
 before the
  merge mentioned in the first paragraph.
 
  Joel


 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE

 http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Axes.scatter call fails since removal of PyCXX

[Thomas Caswell]

Is there an issue for this (and if not can you make one)?

On Mon, Nov 17, 2014, 09:56 Joel B. Mohler j...@kiwistrawberry.us wrote:

 On Mon, Nov 17, 2014 at 09:36:50AM -0500, Joel B. Mohler wrote:
  I think I see a breakage of the scatter call that I think should work
 and did
  work before
  https://github.com/matplotlib/matplotlib/commit/
 be34210a8c09fcd639ece583eb5c0acb855222b6
 
  This is running on windows 7 (32 bit) with numpy 1.8 and current master.

 Ugh, I tried this same example on my ubuntu box and it works.  I update
 this
 diagnosis to scatter is broken on windows since removing PyCXX; note
 that I
 do not get a traceback with the code below if I replace scatter with
 plot.

 Being that windows devs are scarce, I'll be digging into this more.  I
 certainly welcome any clues as it seems very bizarre to me so far.

 Joel

 
  The example is:
 
  ***
  import numpy
  from matplotlib.backends.backend_agg import FigureCanvasAgg as
 FigureCanvas
  from matplotlib.figure import Figure
 
  POINTS = 500
 
  figure = Figure(figsize=(6, 6), dpi=72)
  ax = figure.add_subplot(1, 1, 1, projection=None)
  scat = ax.scatter(numpy.arange(POINTS), numpy.sin(numpy.arange(POINTS)))
  ***
 
  I get on current master
 
  ***
  Traceback (most recent call last):
File C:\work\mpl_scatter_example.py, line 9, in module
  scat = ax.scatter(numpy.arange(POINTS),
 numpy.sin(numpy.arange(POINTS)))
File C:\Python27\lib\site-packages\matplotlib\axes\_axes.py, line
 3690, in scatter
  self.add_collection(collection)
File C:\Python27\lib\site-packages\matplotlib\axes\_base.py, line
 1459, in add_collection
  self.update_datalim(collection.get_datalim(self.transData))
File C:\Python27\lib\site-packages\matplotlib\collections.py, line
 198, in get_datalim
  offsets, transOffset.frozen())
File C:\Python27\lib\site-packages\matplotlib\path.py, line 977, in
 get_path_collection_extents
  master_transform, paths, transforms, offsets,offset_transform))
  ValueError: object too deep for desired array
  ***
 
  I did very little troubleshooting beyond confirming that this works
 before the
  merge mentioned in the first paragraph.
 
  Joel

 
 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=157005751;
 iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] tk backend broken (somehow?)

[Thomas Caswell]

Have a look at the recipe in conda-rescipes for matplotlib, they might be
doing some funny patching.

On Mon, Nov 17, 2014, 22:48 Benjamin Root ben.r...@ou.edu wrote:

 Ok, I am just really confused now. I have confirmed that using the
 matplotlib supplied by miniconda (v1.4.2) works just fine. Ripping that out
 and building version 1.4.2 from source results in the traceback. Same thing
 for v1.3.1. I have even tried checking out PR#3811 which addresses the
 weird constructor issues we found today, and I still get the segfault.

 Maybe I should try getting out of the conda environment entirely and try
 EPD instead to see if that makes a difference?

 Ben Root

 On Mon, Nov 17, 2014 at 5:17 AM, Phil Elson pelson@gmail.com wrote:

 Mike made some changes to this recently.
 https://github.com/matplotlib/matplotlib/pull/3778

 May be the cause.

 On 16 November 2014 18:12, Benjamin Root ben.r...@ou.edu wrote:

 And with my continuing saga of backend-specific things...

 I was using conda, but because it does not ship with pygtk support, I
 had to manually install pygtk into the conda environment and then install
 matplotlib from source. All that seemed to work fine when I worked on Wx
 and Gtk examples for my book.

 I went back to a (previously working) Tk example to polish it, and I get
 all sorts of errors now. I have tried multiple releases of matplotlib from
 source (doing a git clean -fxd between them), all with similar errors. In
 fact, with master, the error causes a segfault:

 ben@tigger:~/Documents/InteractiveMPL$ python chp5/slider_tk.py
 Exception in Tkinter callback
 Traceback (most recent call last):
   File /home/ben/miniconda/lib/python2.7/lib-tk/Tkinter.py, line 1486,
 in __call__
 return self.func(*args)
   File
 /home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.x-py2.7-linux-x86_64.egg/matplotlib/backends/backend_tkagg.py,
 line 278, in resize
 self.show()
   File
 /home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.x-py2.7-linux-x86_64.egg/matplotlib/backends/backend_tkagg.py,
 line 350, in draw
 tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2)
   File
 /home/ben/miniconda/lib/python2.7/site-packages/matplotlib-1.5.x-py2.7-linux-x86_64.egg/matplotlib/backends/tkagg.py,
 line 30, in blit
 id(data), colormode, id(bbox_array))
 TclError
 alloc: invalid block: 0x2cfe3b0: 0 0
 Aborted (core dumped)

 The line in question is (at least in v1.3.1, it is slightly different in
 more recent versions):
 tk.call(PyAggImagePhoto, photoimage, id(aggimage), colormode,
 id(bbox_array))

 This happens regardless of what example I use (my own or otherwise).
 There is no blit-specific code in the examples. All of this worked with the
 conda-supplied matplotlib, but never the
 from-source-into-a-conda-environment install.

 Thoughts?
 Ben Root


 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.

 http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



 
 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=157005751;
 iu=/4140/ostg.clktrk___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] SpanSelector with gtk3cairo backend

[Thomas Caswell]

Not sure what you mean about agg + py3k, it should work fine (as we test
it).

The issue is that the cairo backend is a vector backend, which does not
have a notion of blitting, which is something that span selector uses to
make it nice and snappy.  Should be able to get it to work by passing the
kwarg `useblit=False` to the constructor.

Tom
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Matplotlib on Android

[Thomas Caswell]

I (personally) would prefer you not use the work 'pylab' in your app name.
There is enough confusion related to the term 'pylab' as it is with out
adding another (some what orthogonal) meaning.

I am speaking for my self in this email.

Tom

On Fri, Nov 7, 2014 at 8:21 AM, Apps Embedded apps.embed...@gmail.com
wrote:

 Hi,

 We are about to publish an Android app released under GPL v3 with full
 source access
 giving the SciPy environnement to any Android devices.

 We would like to call this app Pylab Console on a freemium model with a
 free and premium version.
 This app will give graphics support in its premium version.
 And thus it will use Matplotlib version 1.4.2

 From a legal point of view, are we able to use the term Pylab in our
 Android App name ?

 Moreover, as Python is a trademark, should we need to ask the PSF the
 authorisation of publishing such an app ?

 Thanks for your help.

 Apps Embedded Team.


 --

 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel




-- 
Thomas Caswell
tcasw...@gmail.com
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] remove old branches

[Thomas Caswell]

I am -1 on removing old tags.  The _point_ of tags is they don't move.

IPython is a younger project, moving much faster, and have an interest in
keeping everyone close to the bleeding edge, we don't have that luxury.
For a long time debian shipped an rc (1.3.1rc1 iirc) so there is evidence
of people in the wild caring about arbitrary tags.

Tom

On Wed Nov 05 2014 at 10:01:51 AM Jens Nielsen jenshniel...@gmail.com
wrote:

 I removed the rgb2lab_local branch now (I decided that this is not the way
 to go and I have a local copy in my own remote of this). On a related note
 should be consider removing tags for old release candidates? I know that
 IPython does this and it does clean up the tags quite a bit since
 approximately half the tags are for release candidates.


 Jens

 On Sat, Nov 1, 2014 at 7:56 PM, Thomas Caswell tcasw...@gmail.com wrote:

 This is done now.  All of the branches were fully merged except for
 v1.1.x which had a single line change to contents.rst which ended up on the
 main branch through other means.

 I have local branches pointing to all of the removed branches so if there
 is panic about their removal and _everyone_ runs a prune command on the
 upstream repos we still have this information around.

 I left rgb2lab_local because there is still an open PR against it, but
 will go away when we close that PR.

 Tom

 On Sat Nov 01 2014 at 2:32:19 PM Eric Firing efir...@hawaii.edu wrote:

 On 2014/11/01, 5:49 AM, Thomas Caswell wrote:
  Does anyone protest to removing all of the branches from the main repo
  except:
 
- master
- v1.4.x
- v1.4.2-doc
 
  Having old branches around can lead to confusion (see
  https://github.com/matplotlib/matplotlib/pull/3748#issuecomm
 ent-61372162).
 
  Tom

 Seems to me like a good idea.

 Eric


 
 --
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



 --

 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


 
 --
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] remove old branches

[Thomas Caswell]

We probably should promote all of the 'major' tags to release + get DOIs
for all of the old releases.

I can take care of this, but if someone wants to beat me to it, please do :)

tom


On Wed Nov 05 2014 at 11:32:13 AM Jens Nielsen jenshniel...@gmail.com
wrote:

 That makes sense. I would consider deleting 1.3.1 which is the same
 commit as v1.3.1

 @Benjamin Github allows highlighting releases at
 https://github.com/matplotlib/matplotlib/releases which have
 release notes. Perhaps we should add release notes for releases before
 1.4.0 from the change log to separate them from the release candidates.


 Jens

 On Wed, Nov 5, 2014 at 4:15 PM, Benjamin Root ben.r...@ou.edu wrote:

 Same here. I like the old tags for historical research purposes. Now, if
 there was a way for github to only display the N most recent tags, I would
 go for that...

 On Wed, Nov 5, 2014 at 10:32 AM, Thomas Caswell tcasw...@gmail.com
 wrote:

 I am -1 on removing old tags.  The _point_ of tags is they don't move.

 IPython is a younger project, moving much faster, and have an interest
 in keeping everyone close to the bleeding edge, we don't have that luxury.
   For a long time debian shipped an rc (1.3.1rc1 iirc) so there is evidence
 of people in the wild caring about arbitrary tags.

 Tom

 On Wed Nov 05 2014 at 10:01:51 AM Jens Nielsen jenshniel...@gmail.com
 wrote:

 I removed the rgb2lab_local branch now (I decided that this is not the
 way to go and I have a local copy in my own remote of this). On a related
 note should be consider removing tags for old release candidates? I know
 that IPython does this and it does clean up the tags quite a bit since
 approximately half the tags are for release candidates.


 Jens

 On Sat, Nov 1, 2014 at 7:56 PM, Thomas Caswell tcasw...@gmail.com
 wrote:

 This is done now.  All of the branches were fully merged except for
 v1.1.x which had a single line change to contents.rst which ended up on 
 the
 main branch through other means.

 I have local branches pointing to all of the removed branches so if
 there is panic about their removal and _everyone_ runs a prune command on
 the upstream repos we still have this information around.

 I left rgb2lab_local because there is still an open PR against it, but
 will go away when we close that PR.

 Tom

 On Sat Nov 01 2014 at 2:32:19 PM Eric Firing efir...@hawaii.edu
 wrote:

 On 2014/11/01, 5:49 AM, Thomas Caswell wrote:
  Does anyone protest to removing all of the branches from the main
 repo
  except:
 
- master
- v1.4.x
- v1.4.2-doc
 
  Having old branches around can lead to confusion (see
  https://github.com/matplotlib/matplotlib/pull/3748#issuecomm
 ent-61372162).
 
  Tom

 Seems to me like a good idea.

 Eric


 
 --
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



 --

 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


 
 --
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



 --

 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



 
 --
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] logit scale for frequencies

[Thomas Caswell]

Please create a pull request.

This sounds reasonable to me, but I have never seen a plot with that scale
and don't really understand it from your description. Seeing the code
usually clarifies things.

Tom

On Mon, Nov 3, 2014, 05:58 Fabio Zanini fabio.zan...@tuebingen.mpg.de
wrote:

 Dear all,

 I've been using matplotlib with great satisfaction for a few years, but
 one feature I've been missing is a logit scale. This is essentially a
 nonlinear scale that is log both towards 0+ and log towards 1-. It is
 useful when one has frequencies in a population (i.e. floats between 0
 and 1) and both rare events and very common ones are interesting.

 For instance, say you ask about the fraction of people with blue eyes in
 various world populations, you want to spot even tiny deviations from
 zero or one.

 I have coded a scale according to matplotlib's documentation and it
 works well, so I was wondering whether you are interested into merging
 it into the the main repository. I think it'd be useful because lots of
 people have such frequency data, especially now that matplotlib is
 becoming popular in the biology/social sciences research communities.

 If there is interest, I'll just start a pull request on github and try
 to adapt the code to your coding style. It's already PEP8 and similia.

 Thanks. Cheers,
 Fabio

 
 --
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] remove old branches

[Thomas Caswell]

Does anyone protest to removing all of the branches from the main repo
except:

 - master
 - v1.4.x
 - v1.4.2-doc

Having old branches around can lead to confusion (see
https://github.com/matplotlib/matplotlib/pull/3748#issuecomment-61372162).

Tom
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] remove old branches

[Thomas Caswell]

This is done now.  All of the branches were fully merged except for v1.1.x
which had a single line change to contents.rst which ended up on the main
branch through other means.

I have local branches pointing to all of the removed branches so if there
is panic about their removal and _everyone_ runs a prune command on the
upstream repos we still have this information around.

I left rgb2lab_local because there is still an open PR against it, but will
go away when we close that PR.

Tom

On Sat Nov 01 2014 at 2:32:19 PM Eric Firing efir...@hawaii.edu wrote:

 On 2014/11/01, 5:49 AM, Thomas Caswell wrote:
  Does anyone protest to removing all of the branches from the main repo
  except:
 
- master
- v1.4.x
- v1.4.2-doc
 
  Having old branches around can lead to confusion (see
  https://github.com/matplotlib/matplotlib/pull/3748#issuecomment-61372162
 ).
 
  Tom

 Seems to me like a good idea.

 Eric


 
 --
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Interesting mpl wrapper

[Thomas Caswell]

https://github.com/HamsterHuey/easyplot?utm_content=buffer48700utm_medium=socialutm_source=twitter.comutm_campaign=buffer

I have not looked at it carefully, but it is something we might want to be
aware of when thinking about API re-designs.

Tom

-- 
Thomas Caswell
tcasw...@gmail.com
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Improving axis spine joins and final tick placement

[Thomas Caswell]

Andy,

The issue of the axes frame corners _should_ be fixed in 1.4

The user mailing list is still a going concern, the SF archives are just
broken.  They know (and the archive pages are _less_ broken than they used
to be), but have not fixed it yet.

Tom

On Sun, Oct 26, 2014 at 11:50 AM, Andy Buckley a...@insectnation.org
wrote:

 Hi all,

 I have a question/request about improving a minor aspect of plot
 cosmetics, namely that axis spines seem to be rendered as 4 individual
 lines, meaning that the corners of the axes boundary do not match up
 with a neat corner but have a stair appearance. I've attached a
 screenshot from a zoomed PDF showing this effect, made with MPL 1.3.1
 from Ubuntu 14.04... so apologies if it's already fixed in the latest
 1.4.x versions. This effect is also visible in PNG output, as just a
 couple of pixels in the corners that look ragged. Would it be possible
 to tidy this up... or point me to where in the code this rendering is
 done, if it's something easy that I could maybe help with?

 At the same time, I note in this zoom that the axis is showing tick
 marks at the very end(s) of the axis, where they overlap with the other
 axis/plot boundary line: is there an automatic way to elide tick marks
 in that redundant position?

 Apologies if this isn't a good place for these queries/requests -- I had
 a look at the matplotlib-user and -announce list archives linked from
 the web page and they seem to have gone defunct in 2012, hence coming
 here. I am happy to do a bit of development to address little cosmetic
 tweaks like this, but am not yet familiar with MPL internals.

 Thanks!
 Andy

 PS. I also have a question about how to enable old-style figures in a
 font when using the TeX/PGF rendering backed, cf.
 \usepackage[osf]{mathpazo}, but I'll wait to see if this is an
 appropriate place for such questions before troubling you with that!

 --
 Dr Andy Buckley, Royal Society University Research Fellow
 Particle Physics Expt Group, University of Glasgow / PH Dept, CERN



 --

 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel




-- 
Thomas Caswell
tcasw...@gmail.com
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] matplotlib v1.4.2

[Thomas Caswell]

Hot on the tails of v1.4.1, we have a v1.4.2 due to an error in the boxplot
api in pyplot.py

The only changes between 1.4.1 and 1.4.2 are:

 - corrected boxplot in pyplot.py
 - added extra paths to default search paths for freetype

Tom

-- 
Thomas Caswell
tcasw...@gmail.com
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] matplotlib v1.4.1 released

[Thomas Caswell]

Yes, pyplot didn't get regenerated after one of the boxplot fixes.

On Thu, Oct 23, 2014 at 9:17 AM, Sandro Tosi mo...@debian.org wrote:
 I see a 1.4.2 already?

 On Sun, Oct 19, 2014 at 3:54 AM, Thomas Caswell tcasw...@gmail.com wrote:
 Hello,

 We are pleased to announce the release of matplotlib 1.4.1.

 This is a bug-fix release for the 1.4 series.

  - reverts the changes to interactive plotting so ion will work as
 before in all cases fixed boxplot regressions
  - fixes for finding freetype and libpng
  - sundry unicode fixes (looking up user folders, importing
 seaborn/pandas/networkx with macosx backend)
  - nbagg works with python 3 + new font awesome
  - fixed saving dialogue in QT5

 Source tarballs are available on sourceforge, github, and pypi.  In
 addition wheels for both mac and windows are available on both pypi
 and source forge and windows executable installers are available on
 source forge.

 http://matplotlib.org/downloads.html

 https://pypi.python.org/pypi/matplotlib/1.4.1

 The matplotlib dev team

 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://p.sf.net/sfu/Zoho
 ___
 Matplotlib-users mailing list
 matplotlib-us...@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-users

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

 --
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



-- 
Thomas Caswell
tcasw...@gmail.com

--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] google summer of code student

[Thomas Caswell]

We should be a mentoring organization for next summer.

The organization application period is coming up in a few months
(http://www.google-melange.com/gsoc/events/google/gsoc2015), and if we
are going to do this we need to have a list of viable projects for a
summer student.  I suspect that these will have to have a balance
between importance (to justify doing it) and shiny-ness (to get
students to _want_ to do it).

Thing that comes to my mind immediately

  - work on implementing what ever comes out of
https://github.com/matplotlib/matplotlib/issues/3424
  - The laundry list of work on 3D plotting enhancements


Tom

-- 
Thomas Caswell
tcasw...@gmail.com

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] savefig for entire canvas?

[Thomas Caswell]

I would guess that that would be very backend dependent and would
involve walking up the widget tree to find the QMainWindow (in qt
speak) and grabbing it's RGBA buffer.

Tom

On Sat, Oct 18, 2014 at 3:36 PM, Benjamin Root ben.r...@ou.edu wrote:
 I am *this* close to completing an interactive session recorder example
 for my book using the animation framework (yeah, you read that right...).
 However, since it is based on the usual savefig() action, you don't see the
 buttons or the coordinate display in the corner. Is there a way to save
 frames of the entire canvas? It doesn't have to use savefig().

 Cheers!
 Ben Root

 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://p.sf.net/sfu/Zoho
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel




-- 
Thomas Caswell
tcasw...@gmail.com

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] matplotlib v1.4.1 released

[Thomas Caswell]

Hello,

We are pleased to announce the release of matplotlib 1.4.1.

This is a bug-fix release for the 1.4 series.

 - reverts the changes to interactive plotting so ion will work as
before in all cases fixed boxplot regressions
 - fixes for finding freetype and libpng
 - sundry unicode fixes (looking up user folders, importing
seaborn/pandas/networkx with macosx backend)
 - nbagg works with python 3 + new font awesome
 - fixed saving dialogue in QT5

Source tarballs are available on sourceforge, github, and pypi.  In
addition wheels for both mac and windows are available on both pypi
and source forge and windows executable installers are available on
source forge.

http://matplotlib.org/downloads.html

https://pypi.python.org/pypi/matplotlib/1.4.1

The matplotlib dev team

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] 1.4.1rc1 feedback

[Thomas Caswell]

I have heard no complaints about the release candidate.  Unless I hear
otherwise I plan to tag and release 1.4.1 tomorrow.

Tom

-- 
Thomas Caswell
tcasw...@gmail.com

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] gmail/youtube account

[Thomas Caswell]

Does anyone on the list know the pass word (or control the recovery
email address) for the matplotlib gmail account?  I would like to set
up google analytics on our web site to see a) how much traffic we get
and b) where people are going.

Tom

-- 
Thomas Caswell
tcasw...@gmail.com

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] v1.4.1rc1

[Thomas Caswell]

Awesome, thanks!

On Thu, Oct 16, 2014 at 8:14 AM, Sandro Tosi mo...@debian.org wrote:
 Hi!
 I just uploaded mpl 1.4.1-rc1 in Debian, so it can geta  bit of
 exposure even on the weird HW we still support.

 Cheers,
 Sandro

 On Tue, Oct 14, 2014 at 5:40 PM, Thomas Caswell tcasw...@gmail.com wrote:
 I am happy to announce that I have tagged a release candidate for
 1.4.1.  This is a bug-fix release which fixes most of the bug that
 popped up in 1.4.0 including:

  - setup.py does not die when freetype is not installed
  - reverts the changes to interactive plotting so `ion` will work as expected
  - sundry unicode fixes (looking up user folders, importing
 seaborn/pandas/networkx with macosx backend
  - fixed boxplot regressions

 The tarball is available from github, sourceforge and can be install via

pip install matplotlib==1.4.1rc1

 Tom



 --
 Thomas Caswell
 tcasw...@gmail.com

 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://p.sf.net/sfu/Zoho
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



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



-- 
Thomas Caswell
tcasw...@gmail.com

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Review PR #3564 so we can tag 1.4.1

[Thomas Caswell]

Can someone please review 3564?

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

It fixes the fact that there were ways to get values into rcparams
that side-stepped all of the validation code which lead to some very
long standing bugs.

It raises warnings in the case of values that now fail validation, but
used to sneak in.  The plan is to change the warnings to exceptions at
a later date.

Tom

-- 
Thomas Caswell
tcasw...@gmail.com

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] trouble building on red hat.

[Thomas Caswell]

I think this is a bug that had been fixed on both master and 1.4.x.

If I recall correctly this is an issue with free type (#3471 fixes it). The
other work around is to install freetype-dev.

Tom

(From phone so chasing siren details is hard)
On Oct 12, 2014 3:16 PM, Andy Davidson a...@santacruzintegration.com
wrote:

 I am having a heck of time getting matplotlib installed on my amazon ec2
 cluster. (I am new to python)


 I wonder if the problem is /usr/python points to an old version of python.
 I need to use /usr/bin/python2.7


 I have tried using yum, yum-builddep, pip2.7, downloading the the source
 , and even cloning the master


 Yum see to know about /usr/bin/python which is an old version I need to
 use /usr/bin/python2.7.


 I tried searching for a RPM (
 http://rpm.pbone.net/index.php3/stat/3/srodzaj/1/search/python-matplotlib)
 how ever I only found really old version.



 I have tried editing File setupext.py, line 940, in check, looks like
 the min version is 2.4 I have 2.3.x


 But still can not figure out what the problem is


 Any suggestions would be greatly appreciated.


 Andy


 root@ip-172-31-17-158 matplotlib-1.4.0]$ pip2.7 install matplotlib

 Downloading/unpacking matplotlib

   Downloading matplotlib-1.4.0.tar.gz (51.2MB): 51.2MB downloaded

   Running setup.py (path:/tmp/pip_build_root/matplotlib/setup.py) egg_info
 for package matplotlib


 

 Edit setup.cfg to change the build options



 BUILDING MATPLOTLIB

 matplotlib: yes [1.4.0]

 python: yes [2.7.5 (default, Sep 15 2014, 17:30:20)
 [GCC

 4.8.2 20140120 (Red Hat 4.8.2-16)]]

   platform: yes [linux2]



 REQUIRED DEPENDENCIES AND EXTENSIONS

  numpy: yes [version 1.9.0]

six: yes [using six version 1.8.0]

   dateutil: yes [using dateutil version 2.2]

tornado: yes [using tornado version 4.0.2]

  pyparsing: yes [using pyparsing version 2.0.3]

  pycxx: yes [Couldn't import.  Using local copy.]

 libagg: yes [pkg-config information for 'libagg' could
 not

 be found. Using local copy.]

 Traceback (most recent call last):

   File string, line 17, in module

   File /tmp/pip_build_root/matplotlib/setup.py, line 154, in module

 result = package.check()

   File setupext.py, line 940, in check

 if 'No such file or directory\ngrep:' in version:

 TypeError: argument of type 'NoneType' is not iterable

 Complete output from command python setup.py egg_info:


 


 Edit setup.cfg to change the build options




 BUILDING MATPLOTLIB


 matplotlib: yes [1.4.0]


 python: yes [2.7.5 (default, Sep 15 2014, 17:30:20)  [GCC


 4.8.2 20140120 (Red Hat 4.8.2-16)]]


   platform: yes [linux2]




 REQUIRED DEPENDENCIES AND EXTENSIONS


  numpy: yes [version 1.9.0]


six: yes [using six version 1.8.0]


   dateutil: yes [using dateutil version 2.2]


tornado: yes [using tornado version 4.0.2]


  pyparsing: yes [using pyparsing version 2.0.3]


  pycxx: yes [Couldn't import.  Using local copy.]


 libagg: yes [pkg-config information for 'libagg' could not


 be found. Using local copy.]


 Traceback (most recent call last):


   File string, line 17, in module


   File /tmp/pip_build_root/matplotlib/setup.py, line 154, in module


 result = package.check()


   File setupext.py, line 940, in check


 if 'No such file or directory\ngrep:' in version:


 TypeError: argument of type 'NoneType' is not iterable


 

 Cleaning up...

 Command python setup.py egg_info failed with error code 1 in
 /tmp/pip_build_root/matplotlib

 Storing debug log for failure in /root/.pip/pip.log

 root@ip-172-31-17-158 matplotlib-1.4.0]$



 This is the bottom of the debug log


 ---

 Cleaning up...

   Removing temporary dir /tmp/pip_build_root...

 Command python setup.py egg_info failed with error code 1 in
 /tmp/pip_build_root/matplotlib

 Exception information:

 Traceback (most recent call last):

   File
 /usr/lib/python2.7/site-packages/pip-1.5.6-py2.7.egg/pip/basecommand.py,
 line 122, in main

 status = self.run(options, args)

   File
 /usr/lib/python2.7/site-packages/pip-1.5.6-py2.7.egg/pip/commands/install.py,
 line 278, in run

 requirement_set.prepare_files(finder, force_root_egg_info=self.bundle,
 bundle=self.bundle)

   File /usr/lib/python2.7/site-packages/pip-1.5.6-py2.7.egg/pip/req.py,
 line 1229, in 

[matplotlib-devel] v1.4.1rc1 delayed :(

[Thomas Caswell]

Hello all,

We are going to miss the deadline on 1.4.1 as there is 2-3 blocker issues:

  - #3470 / PR#3564  which started as issues with the macosx backend
and spiralled into discovering that we were only validating input to
rcparams about half of the time.

 - #3505 The changes to disable interactive mode when not at a repl.
It turns out a lot of people use it and we should un-break them.

 - #3517 which is related to non-ascii paths in font look up which
causes matplotlib to blow up on import.

I am open to arguments that any of these should not be blockers.

Tom

-- 
Thomas Caswell
tcasw...@gmail.com

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] trouble installing matplotlib on redhat

[Thomas Caswell]

]


  pycxx: yes [Couldn't import.  Using local copy.]


 libagg: yes [pkg-config information for 'libagg' could not


 be found. Using local copy.]


   freetype: no  [Requires freetype2 2.4 or later.  Found


 2.3.11.]


png: yes [version 1.2.49]


  qhull: yes [pkg-config information for 'qhull' could not be


 found. Using local copy.]




 OPTIONAL SUBPACKAGES


sample_data: yes [installing]


   toolkits: yes [installing]


  tests: yes [using nose version 1.3.4 / mock is required to


 run the matplotlib test suite.  pip/easy_install may


 attempt to install it after matplotlib.]


 toolkits_tests: yes [using nose version 1.3.4 / mock is required to


 run the matplotlib test suite.  pip/easy_install may


 attempt to install it after matplotlib.]




 OPTIONAL BACKEND EXTENSIONS


 macosx: no  [Mac OS-X only]


 qt5agg: no  [PyQt5 not found]


 qt4agg: no  [PyQt4 not found]


 pyside: no  [PySide not found]


gtk3agg: no  [Requires pygobject to be installed.]


  gtk3cairo: no  [Requires cairocffi or pycairo to be installed.]


 gtkagg: no  [Requires pygtk]


  tkagg: no  [TKAgg requires Tkinter.]


  wxagg: no  [requires wxPython]


gtk: no  [Requires pygtk]


agg: yes [installing]


  cairo: no  [cairocffi or pycairo not found]


  windowing: no  [Microsoft Windows only]




 OPTIONAL LATEX DEPENDENCIES


 dvipng: no


ghostscript: yes [version 8.70]


  latex: yes [version 3.141592]


pdftops: no




 


 * The following required packages can not be built:


 * freetype


 

 Cleaning up...

 Command python setup.py egg_info failed with error code 1 in
 /tmp/pip_build_root/matplotlib

 Storing debug log for failure in /root/.pip/pip.log

 ec2-user@ip-172-31-15-87 root]$



 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel




-- 
Thomas Caswell
tcasw...@gmail.com

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] pyplot-OO convergence

[Thomas Caswell]

I am against pushing the pyplot style title/xlabel/.. function down
into the OO layer, I really do not like the different behaviour and
returns depending on the arguments.   That has always struck me as a
MATLAB-ism that should be dropped, but we are stuck with to maintain
back-compatibility.

I have been thinking about going a very different route and pulling
almost all of the plotting function _off_ of the axes objects and just
having functions with signatures like

def plotter_function(ax, data1, data2, style1, style2,...)
art = create_artists(...)
ax.add_artists(art)
return art_list

And then almost all of pyplot can be replaced with a wrapper function:

def wrap_for_pyplot(func):
def inner(*args, **kwargs)
ax = plt.gca()
art_list = func(ax, *args, **kwargs)
if plt.is_interactive():
 ax.figure.canvas.draw()

inner.__name__ = func.__name__
inner.__doc__ = strip_ax_arg(func.__doc__)
return inner

for f in funcs_to_wrap:
pyplot.setattr(f.__name__, wrap_for_pyplot(f))

Which pushes all of the interactive/global state related stuff up to
one place and removes the need for keywords to suppress re-drawing/the
need to manage that.   This will make embedding a lot easier as well.

I have also been thinking quite a bit about the semantic
artist/manager layer of objects which I think would also go a long way
making the library easier to use, but that is a different story.

Tom


On Sat, Sep 27, 2014 at 7:40 PM, Eric Firing efir...@hawaii.edu wrote:
 One of the biggest causes of controversy in mpl, and of difficulty in
 teaching and learning mpl, is the divide between pyplot and the rest of
 the library.  There are at least two aspects:

 1) plt.title() versus ax.set_title(), etc; that is, all the clunky
 getters and setters on the OO side.  JDH used to note that they were a
 side-effect of his C++ heritage, and that he probably wouldn't have used
 them if he had had more Python experience when he started mpl.

 2) For interactive use, such as in the ipython console, one really wants
 pyplot's draw_if_interactive() functionality; one doesn't want to have
 to type explicit plt.draw() commands.  Worse, plt.draw() operates on the
 current figure, which might not be the figure that one just updated with
 ax2.set_title('the other plot').

 I think that both of these speed bumps can be removed fairly easily, in
 an entirely backwards-compatible way.

 The first is just a matter of propagating some shorter-form pyplot
 function names back to Axes and Figure.  This idea is mentioned at the
 end of MEP 13, as an alternative to properties.

 The second requires accepting some behavior in the Axes and Figure
 classes that is conditional on the backend and the interactive state.  I
 think it would look *roughly* like this:

 Add a method to Figure:

 def draw_if_interactive():
  if not is_interactive:
  return
  if not isinstance(self.canvas, interactive_canvases):
  return
  self.canvas.draw()

 Append this method to suitable Figure methods such as suptitle().

 Add a method to Axes:

 def draw_if_interactive():
  self.figure.draw_if_interactive()

 Append this method to suitable Axes methods--all those that execute
 changes, or at least those with corresponding pyplot functions.

 Some additional logic (either a kwarg, or temporary manipulation of the
 interactive flag, or of an Axes instance flag) would be needed to
 block the drawing at intermediate stages--e.g., when boxplot is drawing
 all its bits and pieces.

 After these changes, the pyplot functions could be simplified; they
 would not need their own draw_if_interactive calls.

 Am I missing some major impediment?  If not, I think this set of changes
 would make it much easier to use and teach the OO interface, with pyplot
 still being used where it is most helpful, such as in the subplots() call.

 Eric

 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



-- 
Thomas Caswell
tcasw...@gmail.com

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140

Re: [matplotlib-devel] bug in boxplot() xticklabels

[Thomas Caswell]

Can you please make an issue on github?

On Wed, Sep 24, 2014 at 1:51 PM, Michael Kaufman kaufma...@ornl.gov wrote:
 Hi all,

 There's a bug with the xticklabels using boxplot:

 a = [[1,2,3,4],[1,2,3,4],[1,2,3,4]]
 clf()
 boxplot(a, False, 'k', positions=[1000,1500,2000], widths=50)
 xlim(750,2250)
 draw()

 With master branch, I see the xticklabels show as 1, 2, 3
 with 1.3.x I see 1000, 1500, 2000 as expected.

 M

 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



-- 
Thomas Caswell
tcasw...@gmail.com

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] bad formatting on main page

[Thomas Caswell]

https://github.com/matplotlib/matplotlib/pull/3543 has a fix

On Fri, Sep 19, 2014 at 4:49 PM, Thomas Caswell tcasw...@gmail.com wrote:
 I don't remember intending to do that

 On Fri, Sep 19, 2014 at 4:27 PM, Paul Ivanov p...@berkeley.edu wrote:
 Looks like Thomas Caswell changed  what used to be tt tags to be pre
 tags, and those are getting their own lines. The fix would be to either
 change them back to tt tags, or adjust the CSS to wrap pre elements
 (instead of line breaking them)

 On Fri, Sep 19, 2014 at 1:16 PM, Benjamin Root ben.v.r...@gmail.com wrote:

 I just took a peek at the matplotlib.org page, and there is something
 wonky going on. The word pyplot in one of the paragraphs is getting a line
 all to itself. Similarly, a reference to IPython is also getting a line
 for itself.

 Ben Root


 --
 Slashdot TV.  Video for Nerds.  Stuff that Matters.

 http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



 --
 Slashdot TV.  Video for Nerds.  Stuff that Matters.
 http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel




 --
 Thomas Caswell
 tcasw...@gmail.com



-- 
Thomas Caswell
tcasw...@gmail.com

--
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Purpose of doc/conda-recipes ?

[Thomas Caswell]

I appaerently goofed when making the tarball and did not run enough
`git cleans` (or something?).

If they are in the tarball, that is my mistake (and they should not
be).  I am hesitant to change the tarball on SF now as there maybe
people validating on that hash, but please remove those files when
building for debian.

I will make sure that the files for 1.4.1 (end of the month) are clean.

Tom

On Mon, Sep 15, 2014 at 3:46 PM, Sandro Tosi mo...@debian.org wrote:
 On Mon, Sep 15, 2014 at 5:33 PM, Chris Barker chris.bar...@noaa.gov wrote:
 On Thu, Sep 11, 2014 at 1:07 PM, Sandro Tosi mo...@debian.org wrote:

 Hello,
 I've noticed in 1.4.0 the presence of doc/conda-recipes dir; from what
 I got from the doc it's a build system for Anaconda Continuum systems.


 yes conda is that -- but it's also open-source and can be used outside of
 Anaconda. I think it makes a lot of sense to have a conda recipe in with the
 package source.

 May I ask what is the purpose of this directory? if it's for building,
 why is it in the doc subtree?

 Nothing against it, but have you checked the dir I mentioned? it's in
 doc and it seems to contain build scripts for ~500 projects, maybe a
 bit too much? :D

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

 --
 Want excitement?
 Manually upgrade your production database.
 When you want reliability, choose Perforce
 Perforce version control. Predictably reliable.
 http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel



-- 
Thomas Caswell
tcasw...@gmail.com

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] scribbling tool (eg for labeling markers)

[Thomas Caswell]

Steven,

I would love to get to as much of that functionality into mpl proper
as possible.  Please open an issue / make a MEP for this.

Unfortunately I have not had a chance to take a close look at
image_inspector yet and I am a tad concerned about the potential for
re-invented wheels between yours tools and the existing widgets (and
to be fair, I only have a cursory understanding of those widgets).  I
agree all the functionality should be in mpl (or as much as we can
shove down through our gui frame work independent filter), but don't
want to get pinned down to committing to specific implementation
details.

Another option might be to put all of these tools in a sibling repo to
mpl under the mpl organization.

I have cc'd the mpl-dev list.

Tom


On Thu, Sep 4, 2014 at 9:28 PM, Steven Silvester
steven.silves...@gmail.com wrote:
 Thomas,

 How about the broader discussion of incorporating the tools in
 https://github.com/blink1073/image_inspector into mpl (ideally as a
 replacement or alternative for some of the existing tools)?  If I combine
 that with paint tool and we get those pushed into mpl proper, then we can
 just use them as-is for skimage.  Should I open an mpl issue to discuss?

 - Steve

 On Thursday, September 4, 2014 4:49:28 PM UTC-5, Thomas Caswell wrote:

 If you are doing this with matplotlib, can you actually push the tools
 back upstream?

 Tom (a mpl dev)

 On Thu, Sep 4, 2014 at 5:36 PM, Stéfan van der Walt ste...@sun.ac.za
 wrote:
  On Thu, Sep 4, 2014 at 10:01 PM, Emmanuelle Gouillart
  emmanuelle...@nsup.org wrote:
  Answering my own question: I had forgotten that the viewer examples
  include such kind of example, inside watershed_demo.py. Thanks Tony
  for the example!
 
  I think this is an important enough use-case to make it a utility
  function--feel free to add an issue!
 
  Stéfan
 
  --
  You received this message because you are subscribed to the Google
  Groups scikit-image group.
  To unsubscribe from this group and stop receiving emails from it, send
  an email to scikit-image...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.



 --
 Thomas Caswell
 tcas...@gmail.com

 --
 You received this message because you are subscribed to the Google Groups
 scikit-image group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to scikit-image+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.



-- 
Thomas Caswell
tcasw...@gmail.com

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] matplotlib v1.4.0 released

[Thomas Caswell]

We are pleased to announce the release of matplotlib 1.4.0!

This release has contributions from ~170 authors
(http://matplotlib.org/users/github_stats.html).

This release contains many bug fixes as will as a number of new
features.  For the full list see
http://matplotlib.org/users/whats_new.html#new-in-matplotlib-1-4.
Some highlights are:

  - style module : experimental package to make managing the style of
matplotlib figures easier
  - nbagg : interactive figures in ipython notebooks backed by the AGG renderer
  - full python 3 support (including cairo backends)
  - Qt5 support (for python 3 only)
  - violin plots and 3D quiver plots (projects done for a course at
University of Toronto, Scarborough)
  - new box plot interface (as bxp)

The release can be installed via pip (but requires local compilation)

Tarballs are available at:
  - 
http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.4.0/matplotlib-1.4.0.tar.gz
  - https://github.com/matplotlib/matplotlib/archive/v1.4.0.tar.gz
  - https://pypi.python.org/packages/source/m/matplotlib/matplotlib-1.4.0.tar.gz

Windows install binaries and wheels are available (thanks to Christoph
Gohlke) at 
http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.4.0/
.

Mac OSX wheels are available (thanks to Matthew Brett) from
http://wheels.scikit-image.org .


The Matplotlib Team

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] getting a DOI for v1.4.0

[Thomas Caswell]

https://zenodo.org/record/11451#.U_z6ckREvfQ

And yes, I will create an issue for updating the citation page.

Tom

On Tue, Aug 26, 2014 at 5:08 PM, Benjamin Root ben.r...@ou.edu wrote:
 In case you weren't already thinking of this, we might want to update this
 page:
 http://matplotlib.org/citing.html


 On Tue, Aug 26, 2014 at 5:01 PM, Thomas Caswell tcasw...@gmail.com wrote:

 Thanks! This hasn't been done yet because I was confused by zenodo and
 hadn't taken the tune to sort this out.

 Tom

 On Aug 26, 2014 4:54 PM, Nathaniel Smith n...@pobox.com wrote:

 On Sun, Aug 24, 2014 at 2:42 AM, Thomas Caswell tcasw...@gmail.com
 wrote:
  Hey all,
 
  Github has made it possible to get a DOI for a release (
  https://guides.github.com/activities/citable-code/ ).
 
  I am inclined to do this for 1.4.0.  I think doing this is a good
  first step towards being good (leading?) citizens in the reproducible
  science community.

 FYI, since I just spent half an hour figuring this out:

 To use the Zenodo magic DOI feature you have to:

 1) Attach Zenodo to the repository like it says in the tutorial.

 2) Create a release on github, which is *not* the same as a tag,
 even though the github UI claims that they are identical. See all of
 these releases that are listed on your github releases page?
 https://github.com/matplotlib/matplotlib/releases
 None of them are actually releases in the sense that Zenodo wants.

 Here's an example of what it looks like after you've made Zenodo happy:
 https://github.com/pydata/patsy/releases

 The trick is to click draft a new release, and then type in the name
 of your existing tag. You can add some release notes if desired, which
 will be copied to the archived Zenodo page, which will look like this:
https://zenodo.org/record/11445
 (The text See release notes: url is what I typed into the Github
 release description box.) And then click Publish release obviously.
 This will convert your existing release tag into an *extra-special*
 release tag, which AFAICT works the same as before except that (a) it
 gets snazzier graphics in the github UI, and (b) Zenodo will archive
 it.

 -n

 --
 Nathaniel J. Smith
 Postdoctoral researcher - Informatics - University of Edinburgh
 http://vorpus.org



 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 Matplotlib-devel mailing list
 Matplotlib-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel





-- 
Thomas Caswell
tcasw...@gmail.com

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] v1.4.0

[Thomas Caswell]

I have tagged 1.4.0, posted the source tarball to sf, updated pypi,
updated the docs, and kicked off building the mac wheels.

Holding off on announcing to the rest of the lists until the windows
binaries get built.

Created a v1.4.0-doc branch on the main repo to put documentation
updates in.  One of the big issues from 1.3.1 was the incorrect
documentation for the windows install that was wrong for many months,
hopefully this will give us a way to deal with future situations
rapidly.

Tom

-- 
Thomas Caswell
tcasw...@gmail.com

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel