matplotlib-devel Mailing List for matplotlib (Page 3)

On Thu, Nov 15, 2012 at 2:24 PM, Cyrille Rossant
<cyr...@gm...>wrote:
> Hi all,
>
> I am developing a high-performance interactive visualization package in
> Python based on PyOpenGL (http://rossant.github.com/galry/). It is
> primarily meant to be used as a framework for developing complex
> interactive GUIs (in QT) that deal with very large amounts of data (tens of
> millions of points). But it may also be used, like matplotlib, as a
> high-level interactive library to plot and visualize data.
>
> The low-level interface is mostly done at this point (the code is still in
> an experimental stage though), and I'm now focusing on my current research
> project which is to write a scientific GUI based on this interface.
> However, I think people (including myself!) may be interested in a
> matplotlib-like high-level interface. I was first thinking about writing
> such an interface from scratch, by implementing a very small fraction of
> the matplotlib interface (basic commands like figure(), plot(), subplot(),
> show(), etc.). One could then quickly visualize huge datasets with the same
> commands than matplotlib.
>
> Another solution would be to write a matplotlib backend based on this
> library. I am not familar enough with the internals of matplotlib to know
> how complicated it could be. I may do it myself, but it would probably take
> a long time since it is currently not my highest priority. I would be glad
> if someone experienced in writing backends was interested in working on it.
> Actually I could do everything that is specific to my library, which
> already provides commands to plot points, lines, textures, etc. The canvas
> is based on QT and may be similar to what is already implemented in the QT
> backend.
>
> Of course, it would already be great if only the most basic plotting
> features were available in the backend. A first step could be for example
> to have a simplistic example "plot(x, sin(x))" working (with interactive
> navigation).
>
> I am looking forward to your feedback.
>
> Best,
> Cyrille Rossant
>
>
Great to hear another person interested in bringing opengl to matplotlib!
Another project you might be interested in collaborating with is Glumpy:
http://code.google.com/p/glumpy/
>From my limited knowledge of OpenGL, what my vision is that any of the
existing backends have support for an OpenGL object, so we just need to be
able to instantiate the opengl object in any figure object, and know how to
send it the appropriate commands and data. So, it is not exactly a
backend, more of a "middling". Anyway, I think the dev at Glumpy would be
happy to have help, and probably have much more developed ideas on how to
integrate with matplotlib.
Cheers!
Ben Root

On Wed, Nov 14, 2012 at 7:37 PM, Mike Kaufman <mc...@gm...> wrote:
> Hi all,
>
> I don't have time to make a patch at the moment, but I thought I'd point
> it out for anyone to give it a go...
>
> tick_params(axis='both', **kwargs)
> Change the appearance of ticks and tick labels.
>
> Keyword arguments:
>
> ...
>
> *direction* : ['in' | 'out']
> Puts ticks inside or outside the axes.
>
> I just found that *direction* accepts 'inout' as well, which
> does indeed place the tick on both sides of the spine. So the
> documentation should be updated to reflect this.
Thanks for the report, Mike, here's a PR for the patch:
https://github.com/matplotlib/matplotlib/pull/1503
> If it were me, I'd allow 'both' to work as well.
>
I'm amenable to that, just not sure if that counts as a new feature and
should go into master, or a bugfix and go into v1.2.x.
I can add this functionality to #1503 if that makes sense to go to v1.2.x
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

Hello Ian,
Thank you for your second proposition ; I find it very interesting in fact.
(But beware that, as I do not feel able to do this on my own, your code
exemple / guidance would be needed for sure... )
I will have a look at http://matplotlib.org/devel/index.html
I think your idea of having a separate TriFinder class is quite good. My
search algo. is not optimised, only avoiding a O(N) for interpolations
along a path or line.
Some other parts of the code (especially the loop over the (x,y) points in
__call__() ) may also be performance-critical, at least for the 'cubic'
interpolator. But I dont have a clear picture on how to embed C++ code in
python so I would need your example to figure out what is possible.
Regards
Geoffroy.
2012年11月14日 Ian Thomas <ian...@gm...>
> Hi Geoffroy,
>
> I have had some time to look at your TriLinearInterpolator in some detail
> (the other two files only briefly). I would indeed like to add something
> like this to matplotlib - the mesh refinement looks very nice and the
> interpolators would be useful to many people.
>
> As you suspected, the code does need significant changes before we can
> include it. Some are merely cosmetic, as all code must adhere to PEP8 and
> the matplotlib coding guidelines, but there are also some functional and
> performance improvements. For example, your wavefront method for finding
> the triangle containing a certain point must be able to deal with masked
> triangulations and indeed triangulations that are discontinuous, for
> example two islands in a masked-out ocean, which is unusual but must be
> supported. In terms of performance, there is much explicit looping within
> numpy arrays that could be improved using other numpy array commands, and
> would also reduce the length of the source code. There is an argument for
> some of the performance-critical code to be in C/C++.
>
> I think the code used to determine which triangle contains a certain point
> should be factored out into its own TriFinder class, so that (1) it does
> not need to be replicated in the two interpolator classes, and (2)
> different algorithms can be easily swapped if necessary. I have a C++
> TriFinder class that I could modify to work within matplotlib, and it is
> O(log N) so should be faster than your version for typical use cases.
>
> I expect that this is probably more work than you anticipated when you
> asked if the code needed any improvement! I propose the following: if you
> are happy to give matplotlib your source code as it stands and for us to
> include it under our BSD-style license, then I will take on the
> responsibility of getting it into a form that will be accepted by the other
> developers. I will acknowledge your contribution in both the source code
> and on the web site, something like "based on code contributed by Geoffroy
> Billotey".
>
> Alternatively, if you would like to use this as an excuse to learn how to
> contribute to matplotlib more actively but don't want to take on
> everything, then we could divide up the work so that first I write my C++
> log(N) TriFinder class and the linear interpolator that uses it, and then
> you could modify the cubic interpolator following the format of the linear
> interpolator and using my guidance as and when you need it.
>
> Let me know your preference,
> Ian
>
> P.S. Never apologise for not being a computer scientist! Many of our
> developers, myself included, are proper scientists or engineers!!!
>
>
>
> On 29 October 2012 09:37, Ian Thomas <ian...@gm...> wrote:
>
>> Hi Geoffroy
>>
>> This will certainly be very useful. I need to spend some time looking at
>> it and seeing how it would best fit within the matplotlib framework,
>> particularly as only a few days ago I committed to writing a triangular
>> grid interpolator for quad grids and it would be sensible to group these
>> interpolators together in some way.
>>
>> I'll get back to you when I've had time to look at it.
>>
>> Thanks for your efforts!
>> Ian
>>
>>
>>
>> On 28 October 2012 20:17, GBillotey <geo...@gm...> wrote:
>>
>>> Hi!
>>>
>>>
>>> I had recently to develop interpolators for a function defined at the
>>> nodes
>>> of a user-specified triangular mesh.
>>> (Beside interpolation, it can help producing higher-quality tricontour
>>> plots, using interpolation on a refined mesh and matplotlib tricontour
>>> function.)
>>>
>>> Being a regular user of matplotlib, I would be happy if it can be useful
>>> to
>>> others...
>>> The code is hosted here:
>>> https://github.com/GBillotey/trimesh-interpolator.git
>>>
>>>
>>> Please let me know if it this dev. can be useful and if the code needs
>>> some
>>> cleaning (I am not a computer scientist, only a mechanical engineer)
>>>
>>>
>>> Cheers,
>>> Geoffroy.
>>>
>>
>

Hi all,
I am developing a high-performance interactive visualization package in
Python based on PyOpenGL (http://rossant.github.com/galry/). It is
primarily meant to be used as a framework for developing complex
interactive GUIs (in QT) that deal with very large amounts of data (tens of
millions of points). But it may also be used, like matplotlib, as a
high-level interactive library to plot and visualize data.
The low-level interface is mostly done at this point (the code is still in
an experimental stage though), and I'm now focusing on my current research
project which is to write a scientific GUI based on this interface.
However, I think people (including myself!) may be interested in a
matplotlib-like high-level interface. I was first thinking about writing
such an interface from scratch, by implementing a very small fraction of
the matplotlib interface (basic commands like figure(), plot(), subplot(),
show(), etc.). One could then quickly visualize huge datasets with the same
commands than matplotlib.
Another solution would be to write a matplotlib backend based on this
library. I am not familar enough with the internals of matplotlib to know
how complicated it could be. I may do it myself, but it would probably take
a long time since it is currently not my highest priority. I would be glad
if someone experienced in writing backends was interested in working on it.
Actually I could do everything that is specific to my library, which
already provides commands to plot points, lines, textures, etc. The canvas
is based on QT and may be similar to what is already implemented in the QT
backend.
Of course, it would already be great if only the most basic plotting
features were available in the backend. A first step could be for example
to have a simplistic example "plot(x, sin(x))" working (with interactive
navigation).
I am looking forward to your feedback.
Best,
Cyrille Rossant

Hi all,
I don't have time to make a patch at the moment, but I thought I'd point 
it out for anyone to give it a go...
tick_params(axis='both', **kwargs)
 Change the appearance of ticks and tick labels.
 Keyword arguments:
...
 *direction* : ['in' | 'out']
 Puts ticks inside or outside the axes.
I just found that *direction* accepts 'inout' as well, which
does indeed place the tick on both sides of the spine. So the 
documentation should be updated to reflect this. If it were me, I'd 
allow 'both' to work as well.
M

Hi Geoffroy,
I have had some time to look at your TriLinearInterpolator in some detail
(the other two files only briefly). I would indeed like to add something
like this to matplotlib - the mesh refinement looks very nice and the
interpolators would be useful to many people.
As you suspected, the code does need significant changes before we can
include it. Some are merely cosmetic, as all code must adhere to PEP8 and
the matplotlib coding guidelines, but there are also some functional and
performance improvements. For example, your wavefront method for finding
the triangle containing a certain point must be able to deal with masked
triangulations and indeed triangulations that are discontinuous, for
example two islands in a masked-out ocean, which is unusual but must be
supported. In terms of performance, there is much explicit looping within
numpy arrays that could be improved using other numpy array commands, and
would also reduce the length of the source code. There is an argument for
some of the performance-critical code to be in C/C++.
I think the code used to determine which triangle contains a certain point
should be factored out into its own TriFinder class, so that (1) it does
not need to be replicated in the two interpolator classes, and (2)
different algorithms can be easily swapped if necessary. I have a C++
TriFinder class that I could modify to work within matplotlib, and it is
O(log N) so should be faster than your version for typical use cases.
I expect that this is probably more work than you anticipated when you
asked if the code needed any improvement! I propose the following: if you
are happy to give matplotlib your source code as it stands and for us to
include it under our BSD-style license, then I will take on the
responsibility of getting it into a form that will be accepted by the other
developers. I will acknowledge your contribution in both the source code
and on the web site, something like "based on code contributed by Geoffroy
Billotey".
Alternatively, if you would like to use this as an excuse to learn how to
contribute to matplotlib more actively but don't want to take on
everything, then we could divide up the work so that first I write my C++
log(N) TriFinder class and the linear interpolator that uses it, and then
you could modify the cubic interpolator following the format of the linear
interpolator and using my guidance as and when you need it.
Let me know your preference,
Ian
P.S. Never apologise for not being a computer scientist! Many of our
developers, myself included, are proper scientists or engineers!!!
On 29 October 2012 09:37, Ian Thomas <ian...@gm...> wrote:
> Hi Geoffroy
>
> This will certainly be very useful. I need to spend some time looking at
> it and seeing how it would best fit within the matplotlib framework,
> particularly as only a few days ago I committed to writing a triangular
> grid interpolator for quad grids and it would be sensible to group these
> interpolators together in some way.
>
> I'll get back to you when I've had time to look at it.
>
> Thanks for your efforts!
> Ian
>
>
>
> On 28 October 2012 20:17, GBillotey <geo...@gm...> wrote:
>
>> Hi!
>>
>>
>> I had recently to develop interpolators for a function defined at the
>> nodes
>> of a user-specified triangular mesh.
>> (Beside interpolation, it can help producing higher-quality tricontour
>> plots, using interpolation on a refined mesh and matplotlib tricontour
>> function.)
>>
>> Being a regular user of matplotlib, I would be happy if it can be useful
>> to
>> others...
>> The code is hosted here:
>> https://github.com/GBillotey/trimesh-interpolator.git
>>
>>
>> Please let me know if it this dev. can be useful and if the code needs
>> some
>> cleaning (I am not a computer scientist, only a mechanical engineer)
>>
>>
>> Cheers,
>> Geoffroy.
>>
>

[...]
 > > On Mon, Sep 24, 2012 at 3:33 PM, Todd <toddrjen@...> wrote:
[...]
 > >> I tentatively am calling the plot type an "EventRaster" plot
 > >> (name suggestions, along with any other suggestions, are
 > >> welcome). The plot is made up if horizontal rows of identical
 > >> vertical lines and/or markers. Each line or marker represents a
 > >> discrete event, and each row represents a single sequence of
 > >> events (such as a trial). The x-axis position of the line or
 > >> marker identifies the location of the event by some measure. An
 > >> example of what such a plot often looks like is below.
 > >>
 > >> http://hebb.mit.edu/courses/9.29/2003/athena/dylanh/quad-rast.gif
 > >>
 > >> This sort of plot is used ubiquitously in neuroscience. It is
 > >> used to show the time of discrete neural (brain cell) events
 > >> (called "spikes") over time in repeated trials, and is generally
 > >> called a spike raster, raster plot, or raster graph. However,
 > >> it can be used in any situation where you are only concerned
 > >> with the position of events but not their amplitude, especially
 > >> if you want to look for patterns in those events or look for
 > >> differences between multiple sequences of events.
[...]
 > Assuming we go with the name, here is my proposed call signature:
 > 
 > EventRaster(x, offset=0, height=1, **kargs)
 > 
 > x is a 1D or 2D array. If a 1D array, it create a single row of
 > lines. If it is a 2D array, it creates one row of lines for each row
 > in the array.
Dear Todd,
I saw your posts on this idea with interest. I recently had similar,
but more intricate plotting needs and came up with a brute-force
solution calling "barh" for each of the vertical bars. It is
attached. It is not "nice" code because it mixes program logic,
visual tweaks, and plotting, but maybe you can take it as an example
of what can already be done and should probably be wrapped in a clean
API. This is already a simplified stand-along version, there is a
more involved production code behind.
It is a timing graph (that's what I think of, maybe "timing" could be
an appropriate name as I too agree that "raster" is a bit confusing)
of events with the following requirements:
- An event has a start and a finish (or, equivalently, a start and a
 duration), so the vertical bars must be drawn with varying widths.
- The bars may be colored differently (in the concrete application,
 the color scheme was green/yellow/red with green for tasks which are
 processed in their allocated time slice, yellow for the overrun into
 the next slice, and red (not show in example below) if allowable
 delay tolerances are violated; it is easy to imagine very different
 applications and coloring schemes).
- The bars may have different vertical heights (in the application
 representing channel capacities; in the attached example they are
 all the same, but in general they might be different); it is easy to
 imagine applications (maybe like the "rug plots" mentioned in the
 thread) where the vertical height of individual bars needs to be
 specified.
- There are discrete clock ticks which are indicated by vertical grid
 lines.
I am not sure if this gets too general, but maybe it makes sense to
fold some or all of the above into the API of what you are working
on.
With best regards,
Marcel
PS.: I initially sent a post like this one from a wrong email address,
so it got stuck in moderation. It appears that sadly John Hunter is
still moderating the list, so it will probably never get approved. If
someone else has access to moderation, please just cancel that post,
it's the same in different words. I blew my one chance to cancel it
and now am stuck with an invalid confirmation URL for the list server.
---------------------------------------------------------------------
Marcel Oliver Phone: +49-421-200-3212 
School of Engineering and Science Fax: +49-421-200-3103
Jacobs University m.o...@ja...
Campus Ring 1 ol...@me... 
28759 Bremen, Germany http://math.jacobs-university.de/oliver
---------------------------------------------------------------------

On 12 November 2012 20:52, Benjamin Root <ben...@ou...> wrote:
> There are other git workflows, which are all perfectly valid. If you can
> convince us to use another, feel free to propose one. However, we have
> done a couple of releases with gitwash, and it has worked quite well for us
> given how small our maintenance overhead is. Just have to remember to
> regularly merge the maintenance branch to master. That's all.
For what it's worth, what Paul describes is essentially the process we use
in IPython. All pull requests target master, and critical fixes are
backported if we decide we're going to do another maintenance release. This
is easier for contributors, because all pull requests work the same way,
but I think it does take some time for someone to go through the issues
tagged for backporting and cherry-pick the commits. Min tackled that for
our recent maintenance releases.
We use pull request testing to keep master reasonably stable, although we
don't make any promises about it.
Best wishes,
Thomas

On Mon, Nov 12, 2012 at 2:17 PM, Paul Ivanov <piv...@gm...> wrote:
> On Mon, Nov 12, 2012 at 7:36 AM, Michael Droettboom <md...@st...> wrote:
>> On 11/11/2012 11:51 PM, Todd wrote:
>>> Now that 1.2 is out, can we revisit this? I would like to get it
>>> implemented for the next feature release.
>>>
>>
>> Absolutely. I think the next step, once you have an implementation,
>> would be to submit a pull request and we can all help with a review.
>
> This hasn't been mentioned yet, but Todd will hopefully find our
> developer docs useful:
> http://matplotlib.org/devel/index.html
>
> In particular, there's a section on writing a new pyplot function:
> http://matplotlib.org/devel/coding_guide.html#writing-a-new-pyplot-function
Thanks for that, Paul.
Todd, there's also a section on writing tests for matplotlib on the
page Paul pointed out. For a new feature there should be a couple of
tests to go with it to make sure everything passes sanity checks.
Thanks for spending your time contributing!
-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

On Mon, Nov 12, 2012 at 2:52 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Mon, Nov 12, 2012 at 3:44 PM, Paul Ivanov <piv...@gm...> wrote:
>>
>> Hey everyone,
>>
>> So I don't have a clear picture in my head of our development cycle, and I
>> don't think it's well documented. I didn't want thread jack, but in another
>> thread Mike wrote:
>>
>> On Mon, Nov 12, 2012 at 7:36 AM, Michael Droettboom <md...@st...>
>> wrote:
>> > (BTW -- feel free to submit pull requests at any point in a release
>> > cycle -- we have both a master and a maintenance branch, so we can work
>> > on new stuff and stable stuff at the same time).
>>
>> My first question is, how are these two branches related, because I've
>> been submitting things against master, and then switching it to be against
>> 1.2.x when I was asked. From what I have gathered, 1.2.x is for bugfixes,
>> and master is for new features.
>>
>
> That is correct.
>
>>
>> Can someone clarify the current process, with a section like "Submitting
>> new Pull Requests" - this should probably go into one of these places:
>> http://matplotlib.org/devel/coding_guide.html
>> http://matplotlib.org/devel/gitwash/index.html
>>
>
> This is the essence of the gitwash process. Perhaps it needs to be clearer.
>
>>
>> My second question is that, if I do have the right idea about the current
>> process, and the distinction between master and 1.2.x, should we change
>> this? (I think we should).
>>
>> The trouble is that it seems to me now for a bugfix, if it is submitted
>> against 1.2.x, it won't be fixed in master until changes from 1.2.x are
>> merged back into master. So now as a developer trying to follow "bleeding
>> edge" matplotlib, I either have to live with bugs that have been fixed in
>> 1.2.x if I want the features from master, or if I want the bug fixes and
>> follow 1.2.x, I miss the new features in master.
>>
>
> A general rule is that whoever merges a bugfix to the maintenance branch
> should then also manually merge the maintenance branch down to master.
>
>>
>> I think that the mental picture is sufficiently clearer if *everything*
>> (bugfixes and new features) go into master, and then we backport the
>> critical bugfixes against 1.2.x. This would be easier to do if the core
>> developer merging the bugfix into master at least opens an issue for as a
>> placeholder / reminder for the bugfix being a candidate to go into the
>> maintenance branch. Because it seems like at this point, we aren't even sure
>> if we're going to do a 1.2.1 release...
>>
>
> There are other git workflows, which are all perfectly valid. If you can
> convince us to use another, feel free to propose one. However, we have done
> a couple of releases with gitwash, and it has worked quite well for us given
> how small our maintenance overhead is. Just have to remember to regularly
> merge the maintenance branch to master. That's all.
Personally, I use this one:
http://nvie.com/posts/a-successful-git-branching-model/
It does involve a little more effort, it does also mean that someone
installing from the master branch (which is the default branch) will
always get a stable release. My feeling is that the master branch
shouldn't contain any unstable code. Also, it means that the user can
just clone the git repository without having floating tarballs all
over their home directory.
I'm not necessarily proposing we should change it, I just wanted to
point out a different approach. The git branching workflow we use for
matplotlib is perfectly valid and I'm happy using it.
-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

On Mon, Nov 12, 2012 at 10:52 AM, Fernando Perez <fpe...@gm...> wrote:
> Hi folks,
>
> On Sun, Nov 11, 2012 at 1:20 PM, Damon McDougall
> <dam...@gm...> wrote:
>> Yeah that's a great idea. Get the word out.
>
> I did:
>
> https://speakerdeck.com/fperez/science-and-python-a-interactively-biased-retrospective-of-a-mostly-successful-decade?slide=17
>
> and the crowd actually erupted into spontaneous applause when I
> pointed out the py3 support!
That's what I like to hear. I played no part in the py3 support, but
it's a pretty herculean effort. In general I feel the 1.2.0 release is
an extremely robust release.
> So good job to the whole team.
>
> I also put in a slide about John pointing people to the memorial fund:
>
> https://speakerdeck.com/fperez/science-and-python-a-interactively-biased-retrospective-of-a-mostly-successful-decade?slide=50
Thanks Fernando.
-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

On Mon, Nov 12, 2012 at 3:44 PM, Paul Ivanov <piv...@gm...> wrote:
> Hey everyone,
>
> So I don't have a clear picture in my head of our development cycle, and I
> don't think it's well documented. I didn't want thread jack, but in another
> thread Mike wrote:
>
> On Mon, Nov 12, 2012 at 7:36 AM, Michael Droettboom <md...@st...>
> wrote:
> > (BTW -- feel free to submit pull requests at any point in a release
> > cycle -- we have both a master and a maintenance branch, so we can work
> > on new stuff and stable stuff at the same time).
>
> My first question is, how are these two branches related, because I've
> been submitting things against master, and then switching it to be against
> 1.2.x when I was asked. From what I have gathered, 1.2.x is for bugfixes,
> and master is for new features.
>
>
That is correct.
> Can someone clarify the current process, with a section like "Submitting
> new Pull Requests" - this should probably go into one of these places:
> http://matplotlib.org/devel/coding_guide.html
> http://matplotlib.org/devel/gitwash/index.html
>
>
This is the essence of the gitwash process. Perhaps it needs to be clearer.
> My second question is that, if I do have the right idea about the current
> process, and the distinction between master and 1.2.x, should we change
> this? (I think we should).
>
> The trouble is that it seems to me now for a bugfix, if it is submitted
> against 1.2.x, it won't be fixed in master until changes from 1.2.x are
> merged back into master. So now as a developer trying to follow "bleeding
> edge" matplotlib, I either have to live with bugs that have been fixed in
> 1.2.x if I want the features from master, or if I want the bug fixes and
> follow 1.2.x, I miss the new features in master.
>
>
A general rule is that whoever merges a bugfix to the maintenance branch
should then also manually merge the maintenance branch down to master.
> I think that the mental picture is sufficiently clearer if *everything*
> (bugfixes and new features) go into master, and then we backport the
> critical bugfixes against 1.2.x. This would be easier to do if the core
> developer merging the bugfix into master at least opens an issue for as a
> placeholder / reminder for the bugfix being a candidate to go into
> the maintenance branch. Because it seems like at this point, we aren't even
> sure if we're going to do a 1.2.1 release...
>
>
There are other git workflows, which are all perfectly valid. If you can
convince us to use another, feel free to propose one. However, we have
done a couple of releases with gitwash, and it has worked quite well for us
given how small our maintenance overhead is. Just have to remember to
regularly merge the maintenance branch to master. That's all.
Cheers!
Ben Root

Hey everyone,
So I don't have a clear picture in my head of our development cycle, and I
don't think it's well documented. I didn't want thread jack, but in another
thread Mike wrote:
On Mon, Nov 12, 2012 at 7:36 AM, Michael Droettboom <md...@st...> wrote:
> (BTW -- feel free to submit pull requests at any point in a release
> cycle -- we have both a master and a maintenance branch, so we can work
> on new stuff and stable stuff at the same time).
My first question is, how are these two branches related, because I've been
submitting things against master, and then switching it to be against 1.2.x
when I was asked. From what I have gathered, 1.2.x is for bugfixes, and
master is for new features.
Can someone clarify the current process, with a section like "Submitting
new Pull Requests" - this should probably go into one of these places:
http://matplotlib.org/devel/coding_guide.html
http://matplotlib.org/devel/gitwash/index.html
My second question is that, if I do have the right idea about the current
process, and the distinction between master and 1.2.x, should we change
this? (I think we should).
The trouble is that it seems to me now for a bugfix, if it is submitted
against 1.2.x, it won't be fixed in master until changes from 1.2.x are
merged back into master. So now as a developer trying to follow "bleeding
edge" matplotlib, I either have to live with bugs that have been fixed in
1.2.x if I want the features from master, or if I want the bug fixes and
follow 1.2.x, I miss the new features in master.
I think that the mental picture is sufficiently clearer if *everything*
(bugfixes and new features) go into master, and then we backport the
critical bugfixes against 1.2.x. This would be easier to do if the core
developer merging the bugfix into master at least opens an issue for as a
placeholder / reminder for the bugfix being a candidate to go into
the maintenance branch. Because it seems like at this point, we aren't even
sure if we're going to do a 1.2.1 release...
better,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

On Mon, Nov 12, 2012 at 7:36 AM, Michael Droettboom <md...@st...> wrote:
> On 11/11/2012 11:51 PM, Todd wrote:
>> Now that 1.2 is out, can we revisit this? I would like to get it
>> implemented for the next feature release.
>>
>
> Absolutely. I think the next step, once you have an implementation,
> would be to submit a pull request and we can all help with a review.
This hasn't been mentioned yet, but Todd will hopefully find our
developer docs useful:
http://matplotlib.org/devel/index.html
In particular, there's a section on writing a new pyplot function:
http://matplotlib.org/devel/coding_guide.html#writing-a-new-pyplot-function
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

Hi folks,
On Sun, Nov 11, 2012 at 1:20 PM, Damon McDougall
<dam...@gm...> wrote:
> Yeah that's a great idea. Get the word out.
I did:
https://speakerdeck.com/fperez/science-and-python-a-interactively-biased-retrospective-of-a-mostly-successful-decade?slide=17
and the crowd actually erupted into spontaneous applause when I
pointed out the py3 support!
So good job to the whole team.
I also put in a slide about John pointing people to the memorial fund:
https://speakerdeck.com/fperez/science-and-python-a-interactively-biased-retrospective-of-a-mostly-successful-decade?slide=50
Cheers,
f

On 11/11/2012 11:51 PM, Todd wrote:
> On Thu, Sep 27, 2012 at 8:18 PM, Todd <tod...@gm...> wrote:
>> On Thu, Sep 27, 2012 at 1:44 PM, Todd <tod...@gm...> wrote:
>>> On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall
>>> <dam...@gm...> wrote:
>>>> Hi Todd,
>>>>
>>>> Firstly, thanks for taking the time to crystallise your thoughts in
>>>> words first. This is one of my bad habits; I tend to rush into things.
>>>>
>>>> I have some feedback for you, hopefully we can all work together to
>>>> get this right. It's difficult when something new gets implemented and
>>>> someone expects it to do something and the only way to resolve it is
>>>> to break the calling API.
>>> Where is API broken?
>>>
>>>> Anyway, I hope you'll find my comments
>>>> helpful at the least. I also encourage others to weigh in with
>>>> opinions and ideas.
>>> Okay, I will discuss the rationale. I will snip out anything you
>>> agree on for brevity.
>>>
>>>>> Assuming we go with the name, here is my proposed call signature:
>>>>>
>>>>> EventRaster(x, offset=0, height=1, **kargs)
>>>> CamelCase is discouraged for method names. Perhaps 'eventraster'?
>>> Fair enough.
>>>
>>>> Also, we could also let **kwargs swallow the 'offset' and 'height'
>>>> keyword arguments. Then the user isn't constrained by which order to
>>>> put them in. The downside of this approach is that introspection is
>>>> more difficult.
>>> I don't understand the advantage of this approach. If you use keyword
>>> arguments, then the order doesn't matter. So with the approach above
>>> you can use keyword arguments, in which case you can use whatever
>>> order they want, or you can use positional arguments. On the other
>>> hand putting it in **kwargs, we lose the ability to use positional
>>> arguments. So we lose nothing by allowing both positional and keyword
>>> arguments. It is also easier to implement.
>>>
>>>>> offset determines the positions of the rows. By default, the first
>>>>> row is placed with the line center y=0, and subsequent rows are placed
>>>>> with the line centers at increasing 1-unit increments. If offset is
>>>>> defined and is a scalar, the first row is placed at the offset, and
>>>>> subsequent rows are placed at increasing 1-unit increments. If offset
>>>>> is an array, it must be a 1D array of the same length as the second
>>>>> dimension of x. In this case each element in offset determines the
>>>>> center of the corresponding row in the plot.
>>>> How about letting offset be either: a) a scalar, determining the
>>>> offset of all rows equally; or b) an array, determining the offset of
>>>> each row individually.
>>> Because people are almost never going to want to have all the lines
>>> stacked right on top of each other. The plot would be indecipherable
>>> that way. The defaults are chosen to handle the most common use-cases
>>> most easily.
>>>
>>>> In fact, why plot each row at integer y
>>>> coordinates? Could we allow for an optional y-coordinate array, each
>>>> element of which would be the y-coordinate at which to plot a row of
>>>> lines. Then you wouldn't need offset.
>>> That is exactly what offset does if you pass an array.
>>>
>>>>> If this is going to be used to implement rug plots, it would need some
>>>>> way to handle columns of horizontal lines in addition to rows of
>>>>> vertical lines. I see two ways to implement this. First is to have
>>>>> to plot types, perhaps HEventRaster and VEventRaster. The first would
>>>>> be as described above, while the second would be similar but
>>>>> everything rotated 90 degrees. Another possibility is to change the
>>>>> call signature to this:
>>>>>
>>>>> EventRaster(x, y=None, offset=0, height=1, **kargs)
>>>> I think accepting an 'orientation' kwarg, which can take either
>>>> 'horizontal' or 'vertical', determining the orientation of the lines
>>>> and reversing the roles of the x and y arrays.
>>> That would work as well. Probably cleaner that way
>>>
>>>>> The function will return a list of a new collection type I am
>>>>> tentatively calling EventCollection. My thinking would be this would
>>>>> be a subclass of a new collection type called GenericLineCollection,
>>>>> which the current LineCollection would also subclass. They would
>>>>> share things like the color handling and segment handling, however the
>>>>> segment handling will be a "private" method that LineCollection will
>>>>> have a public wrapper for. On the other hand methods to set or add
>>>>> segments will remain private in EventCollection, although there will
>>>>> be a method to return the segments if an artist really wants to
>>>>> manipulate individual segments.
>>>> Why can't we just use LineCollection? I don't see a good reason to
>>>> create a new collection class here; the plot is simple.
>>> Explained below.
>>>
>>>>> The reason for doing it this way is that manipulating individual rows
>>>>> of events should be very common, such as changing their position,
>>>>> color, marker, width, and so on. On the other hand manipulating lines
>>>>> individually should not be as common, although still supported.
>>>> Fair enough, then maybe a better idea is to create your own
>>>> EventRaster class (note camel case) to hold all the relevant data in
>>>> arrays. Then make a 'construct_raster' method could return a
>>>> LineCollection. Then again, weren't you passing extra kwargs to
>>>> 'plot'? This approach would surely use ax.add_lines or
>>>> ax.add_linecollection something (I can't remember what it's called).
>>> The whole point of creating a new collection type is that artists will
>>> be able to manipulate individual sets of events.
>>>
>>> For example, with an ordinary LineCollection it will be extremely
>>> difficult to change the marker type, since doing so will change the
>>> marker for all 3 points on each segment rather than just the middle
>>> point. So if someone makes the plot, than wants to set rows to have
>>> different marker types instead of being lines, they can do that if we
>>> use a new collection class. But if we use LineCollection this becomes
>>> much more difficult.
>>>
>>> Similarly, with a LineCollection the lines lose their status as
>>> objects with a single distinct position. They become objects with 3
>>> 2D coordinates. So if someone wants to add more events to the end,
>>> they need to take care of handling the x and y coordinates, making
>>> sure the x coordinates are the same and taking the y coordinates from
>>> one of the existing lines. Similarly changing the height or vertical
>>> position of all the objects is complicated, having to manually
>>> calculate and modify the y coordinates of each point in each segment.
>>>
>>> Again, the idea here is to make the most common use-cases as easy as
>>> possible. LineCollection objects aren't really suited to the sort of
>>> artistic changes that are typical with this sort of plot.
>>>
>>> In fact I would say that having a separate collection class is central
>>> to this idea. If users aren't able to manipulate the set of events as
>>> such after they create the plot, then there really isn't any advantage
>>> over just using a vlines plot. Calculating the ymin and ymax is one
>>> line of code each, it is the artistic changes that save many lines of
>>> code and a lot of complexity.
>> I would also like to add that the new collection object would be
>> useful outside of this plot type.
>>
>> For example if someone wanted to create a rug plot as Nathaniel
>> described, and they want those along the same axes as the main plot,
>> then they would most likely not be be using the plot function, but
>> rather creating two individual collection objects in an existing
>> figure.
>>
>> I can imagine other cases besides a strict rug plot where adding such
>> a collection object could be useful.
> Now that 1.2 is out, can we revisit this? I would like to get it
> implemented for the next feature release.
>
Absolutely. I think the next step, once you have an implementation, 
would be to submit a pull request and we can all help with a review.
(BTW -- feel free to submit pull requests at any point in a release 
cycle -- we have both a master and a maintenance branch, so we can work 
on new stuff and stable stuff at the same time).
Mike

On Thu, Sep 27, 2012 at 8:18 PM, Todd <tod...@gm...> wrote:
> On Thu, Sep 27, 2012 at 1:44 PM, Todd <tod...@gm...> wrote:
>> On Thu, Sep 27, 2012 at 1:12 PM, Damon McDougall
>> <dam...@gm...> wrote:
>>> Hi Todd,
>>>
>>> Firstly, thanks for taking the time to crystallise your thoughts in
>>> words first. This is one of my bad habits; I tend to rush into things.
>>>
>>> I have some feedback for you, hopefully we can all work together to
>>> get this right. It's difficult when something new gets implemented and
>>> someone expects it to do something and the only way to resolve it is
>>> to break the calling API.
>>
>> Where is API broken?
>>
>>> Anyway, I hope you'll find my comments
>>> helpful at the least. I also encourage others to weigh in with
>>> opinions and ideas.
>>
>> Okay, I will discuss the rationale. I will snip out anything you
>> agree on for brevity.
>>
>>>> Assuming we go with the name, here is my proposed call signature:
>>>>
>>>> EventRaster(x, offset=0, height=1, **kargs)
>>>
>>> CamelCase is discouraged for method names. Perhaps 'eventraster'?
>>
>> Fair enough.
>>
>>> Also, we could also let **kwargs swallow the 'offset' and 'height'
>>> keyword arguments. Then the user isn't constrained by which order to
>>> put them in. The downside of this approach is that introspection is
>>> more difficult.
>>
>> I don't understand the advantage of this approach. If you use keyword
>> arguments, then the order doesn't matter. So with the approach above
>> you can use keyword arguments, in which case you can use whatever
>> order they want, or you can use positional arguments. On the other
>> hand putting it in **kwargs, we lose the ability to use positional
>> arguments. So we lose nothing by allowing both positional and keyword
>> arguments. It is also easier to implement.
>>
>>>> offset determines the positions of the rows. By default, the first
>>>> row is placed with the line center y=0, and subsequent rows are placed
>>>> with the line centers at increasing 1-unit increments. If offset is
>>>> defined and is a scalar, the first row is placed at the offset, and
>>>> subsequent rows are placed at increasing 1-unit increments. If offset
>>>> is an array, it must be a 1D array of the same length as the second
>>>> dimension of x. In this case each element in offset determines the
>>>> center of the corresponding row in the plot.
>>>
>>> How about letting offset be either: a) a scalar, determining the
>>> offset of all rows equally; or b) an array, determining the offset of
>>> each row individually.
>>
>> Because people are almost never going to want to have all the lines
>> stacked right on top of each other. The plot would be indecipherable
>> that way. The defaults are chosen to handle the most common use-cases
>> most easily.
>>
>>> In fact, why plot each row at integer y
>>> coordinates? Could we allow for an optional y-coordinate array, each
>>> element of which would be the y-coordinate at which to plot a row of
>>> lines. Then you wouldn't need offset.
>>
>> That is exactly what offset does if you pass an array.
>>
>>>> If this is going to be used to implement rug plots, it would need some
>>>> way to handle columns of horizontal lines in addition to rows of
>>>> vertical lines. I see two ways to implement this. First is to have
>>>> to plot types, perhaps HEventRaster and VEventRaster. The first would
>>>> be as described above, while the second would be similar but
>>>> everything rotated 90 degrees. Another possibility is to change the
>>>> call signature to this:
>>>>
>>>> EventRaster(x, y=None, offset=0, height=1, **kargs)
>>>
>>> I think accepting an 'orientation' kwarg, which can take either
>>> 'horizontal' or 'vertical', determining the orientation of the lines
>>> and reversing the roles of the x and y arrays.
>>
>> That would work as well. Probably cleaner that way
>>
>>>> The function will return a list of a new collection type I am
>>>> tentatively calling EventCollection. My thinking would be this would
>>>> be a subclass of a new collection type called GenericLineCollection,
>>>> which the current LineCollection would also subclass. They would
>>>> share things like the color handling and segment handling, however the
>>>> segment handling will be a "private" method that LineCollection will
>>>> have a public wrapper for. On the other hand methods to set or add
>>>> segments will remain private in EventCollection, although there will
>>>> be a method to return the segments if an artist really wants to
>>>> manipulate individual segments.
>>>
>>> Why can't we just use LineCollection? I don't see a good reason to
>>> create a new collection class here; the plot is simple.
>>
>> Explained below.
>>
>>>> The reason for doing it this way is that manipulating individual rows
>>>> of events should be very common, such as changing their position,
>>>> color, marker, width, and so on. On the other hand manipulating lines
>>>> individually should not be as common, although still supported.
>>>
>>> Fair enough, then maybe a better idea is to create your own
>>> EventRaster class (note camel case) to hold all the relevant data in
>>> arrays. Then make a 'construct_raster' method could return a
>>> LineCollection. Then again, weren't you passing extra kwargs to
>>> 'plot'? This approach would surely use ax.add_lines or
>>> ax.add_linecollection something (I can't remember what it's called).
>>
>> The whole point of creating a new collection type is that artists will
>> be able to manipulate individual sets of events.
>>
>> For example, with an ordinary LineCollection it will be extremely
>> difficult to change the marker type, since doing so will change the
>> marker for all 3 points on each segment rather than just the middle
>> point. So if someone makes the plot, than wants to set rows to have
>> different marker types instead of being lines, they can do that if we
>> use a new collection class. But if we use LineCollection this becomes
>> much more difficult.
>>
>> Similarly, with a LineCollection the lines lose their status as
>> objects with a single distinct position. They become objects with 3
>> 2D coordinates. So if someone wants to add more events to the end,
>> they need to take care of handling the x and y coordinates, making
>> sure the x coordinates are the same and taking the y coordinates from
>> one of the existing lines. Similarly changing the height or vertical
>> position of all the objects is complicated, having to manually
>> calculate and modify the y coordinates of each point in each segment.
>>
>> Again, the idea here is to make the most common use-cases as easy as
>> possible. LineCollection objects aren't really suited to the sort of
>> artistic changes that are typical with this sort of plot.
>>
>> In fact I would say that having a separate collection class is central
>> to this idea. If users aren't able to manipulate the set of events as
>> such after they create the plot, then there really isn't any advantage
>> over just using a vlines plot. Calculating the ymin and ymax is one
>> line of code each, it is the artistic changes that save many lines of
>> code and a lot of complexity.
>
> I would also like to add that the new collection object would be
> useful outside of this plot type.
>
> For example if someone wanted to create a rug plot as Nathaniel
> described, and they want those along the same axes as the main plot,
> then they would most likely not be be using the plot function, but
> rather creating two individual collection objects in an existing
> figure.
>
> I can imagine other cases besides a strict rug plot where adding such
> a collection object could be useful.
Now that 1.2 is out, can we revisit this? I would like to get it
implemented for the next feature release.
-Todd

On Thursday, November 8, 2012, Carl Michal wrote:
> Hello,
>
> I noticed that a program I had that uses canvas.blit() to do animated
> graphs
> with the gtkagg backend was leaking memory.
>
> I tracked this down to gtk gc's being allocated in agg_to_gtk_drawable with
> gdk_gc_new(), but never being destroyed.
>
> The leak can be seen using the 'Animating selected plot elements' example
> from:
>
> http://www.scipy.org/Cookbook/Matplotlib/Animations
>
> (if it is modified to run forever, rather than just 50 plots and also
> changing numerix to numpy). After a few minutes, it is clear from ps that
> the
> memory usage is slowly but steadily climbing.
>
> Patch below (against matplotlib-1.1.1.) fixes it.
>
> Carl
>
> --- _gtkagg.cpp~ 2012年06月30日 12:37:00.000000000 -0700
> +++ _gtkagg.cpp 2012年11月08日 14:30:23.000000000 -0800
> @@ -121,6 +121,7 @@
> destbuffer,
> deststride);
>
> + gdk_gc_destroy(gc);
> if (needfree)
> {
> delete [] destbuffer;
>
>
>
>
If you are willing, would you like to file a PR against the v1.2.x branch?
Ben Root

On Sun, Nov 11, 2012 at 12:19 PM, Fernando Perez <fpe...@gm...> wrote:
> On Sun, Nov 11, 2012 at 11:47 AM, Benjamin Root <ben...@ou...> wrote:
>> Don't see why not. Thanks for the advertising!
>
> OK, so it will be! Thanks again for everyone who made this possible!
>
> f
Yeah that's a great idea. Get the word out.
-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

On Sun, Nov 11, 2012 at 11:47 AM, Benjamin Root <ben...@ou...> wrote:
> Don't see why not. Thanks for the advertising!
OK, so it will be! Thanks again for everyone who made this possible!
f

On Thu, Nov 8, 2012 at 6:18 PM, Michael Droettboom <md...@st...> wrote:
> Thanks again to everyone for all of their hard work. This release has
> been tagged and uploaded.
1.2.0 Debian packages has just landed in Debian experimental! Cheers :)
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Sunday, November 11, 2012, Fernando Perez wrote:
> On Thu, Nov 8, 2012 at 7:18 PM, Damon McDougall
> <dam...@gm... <javascript:;>> wrote:
> >> IIRC matplotlib is currently third in the list of libraries most wanted
> >> by users waiting for Python3 compatibility. I'd guess that many
> >> scientific users are aware of this wonderful milestone, but to spread
> >> the news at a minimum I'd put this on the main Python mailing list and
> >
> > +1 for this
>
> I'm giving the closing keynote at PyCon Canada today, can I announce
> 1.2.0 offiical with py3 support then? It would be a fitting tribute
> to John and the amazing work you have all put in moving the project
> forward!
>
> f
Don't see why not. Thanks for the advertising!
Ben Root

Hi all,
On Mon, Jan 17, 2011 at 11:45 PM, Sandro Tosi <mo...@de...> wrote:
> On Tue, Jan 4, 2011 at 19:11, Jakub Wilk <jw...@de...> wrote:
>> Package: python-matplotlib-doc
>> Version: 0.99.3-1
>> Severity: minor
>>
>> There are several "Exception occurred rendering plot" warnings in the
>> generated documentation:
>>
>> $ cd /usr/share/doc/python-matplotlib-doc/html/ && grep -r 'Exception
>> occurred' .
I'm not exactly sure how this has fixed itself, but now the above
command returns nothing (on 1.2.0 -doc package):
$ cd /usr/share/doc/python-matplotlib-doc/html/ && grep -r 'Exception
occurred' .
$
Hence closing this report.
Regards,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Thu, Nov 8, 2012 at 7:18 PM, Damon McDougall
<dam...@gm...> wrote:
>> IIRC matplotlib is currently third in the list of libraries most wanted
>> by users waiting for Python3 compatibility. I'd guess that many
>> scientific users are aware of this wonderful milestone, but to spread
>> the news at a minimum I'd put this on the main Python mailing list and
>
> +1 for this
I'm giving the closing keynote at PyCon Canada today, can I announce
1.2.0 offiical with py3 support then? It would be a fitting tribute
to John and the amazing work you have all put in moving the project
forward!
f

Hi all again,
On Fri, Nov 9, 2012 at 11:53 PM, Sandro Tosi <mo...@de...> wrote:
> Hello,
> for the Debian package, we install sample_data directory in a custom
> location, /usr/share/matplotlib/sample_data/ .
>
> Pre-1.2.0 we could specify the examples.directory rcParam, but now
> that parameter has been removed.
>
> If we want to keep shipping sample_data in /usr/share/matplotlib/ , it
> seems the only solution is to patch cbook.get_sample_data() to set
>
> root = '/usr/share/matplotlib/'
Just hardcoding the path made the doc compilation failing to provide
the images for examples using get_sample_data() because it refers to a
directory still not populated (it will be at install time, not build
time). So i brought it up to
https://github.com/matplotlib/matplotlib/issues/1478
We can keep discussing it there.
Cheers,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi