matplotlib-devel Mailing List for matplotlib (Page 4)

I'll be more than happy to provide similar help testing on Windows 7.
-paul

On Sun, Feb 26, 2012 at 5:52 PM, John Hunter <jd...@gm...> wrote:
>
>
> On Sun, Feb 26, 2012 at 6:16 PM, Mark Lawrence <bre...@ya...>
> wrote:
>>
>> On 25/02/2012 17:13, John Hunter wrote:
>>
>> > After we get the bugfix out I'd like to gear up for a major python3
>> > release.
>>
>> Huge +1.
>>
>> I understand that the majority of Python and hence matplotlib people
>> work on *nix boxes, so if you'd like a hand with testing, or anything
>> else come to think of it, on my Windows Vista box feel free to ask, as
>> I've been using matplotlib for around seven years and don't mind trying
>> to put a bit back in.
>>
>
> That would be great-- you can cut your teeth testing the release candidates
> for the bugfix release in the current cycle, familiarize yourself with how
> to run the tests, etc.
>
> We definitely have a shortage of OSX and windows testing, especially the
> latter, because few people run from git HEAD  on windows, but lots of people
> do on linux.
>
> Just chime in when you see the announcements for "rc" release candidates on
> the users or devel lists.
>
> Thanks!
> JDH
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Fri, Mar 2, 2012 at 10:21, Nicolas Rougier <Nic...@in...> wrote:
>
> Sorry, same for me. I was only suggesting potential ideas for GSoC.
>
> On Mar 2, 2012, at 10:37 , Jason Grout wrote:
>
>> On 3/2/12 3:31 AM, Nick Barnes wrote:
>>
>>> My organization is looking for projects which contribute to our own
>>> goal (to promote the public understanding of climate science): in this
>>> context we're helping climate scientists adopt open source techniques
>>> and tools.  For matplotlib that means asking climate scientists for
>>> their ideas (which is where the colormap tool idea came from).
>>>
>>> For general-purpose matplotlib projects, I recommend that matplotlib
>>> apply to be a mentoring organization.  The application window closes
>>> on the 6th.
>>
>> Sorry; I didn't mean to imply that *you* should take up these other
>> projects.  I was replying to the other suggestion about openGL and
>> augmenting it with related ideas, for someone else that might be
>> interested in the subject of the thread "matplotlib and GSOC".
>>
>> Jason

No need to apologize!  I was just encouraging matplotlib to become a
mentoring org so some of these good ideas can get taken up.
-- 
Nick Barnes, Climate Code Foundation, http://climatecode.org/

Sorry, same for me. I was only suggesting potential ideas for GSoC.

Nicolas


On Mar 2, 2012, at 10:37 , Jason Grout wrote:

> On 3/2/12 3:31 AM, Nick Barnes wrote:
> 
>> My organization is looking for projects which contribute to our own
>> goal (to promote the public understanding of climate science): in this
>> context we're helping climate scientists adopt open source techniques
>> and tools.  For matplotlib that means asking climate scientists for
>> their ideas (which is where the colormap tool idea came from).
>> 
>> For general-purpose matplotlib projects, I recommend that matplotlib
>> apply to be a mentoring organization.  The application window closes
>> on the 6th.
> 
> Sorry; I didn't mean to imply that *you* should take up these other 
> projects.  I was replying to the other suggestion about openGL and 
> augmenting it with related ideas, for someone else that might be 
> interested in the subject of the thread "matplotlib and GSOC".
> 
> Jason
> 
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 3/2/12 3:31 AM, Nick Barnes wrote:

> My organization is looking for projects which contribute to our own
> goal (to promote the public understanding of climate science): in this
> context we're helping climate scientists adopt open source techniques
> and tools.  For matplotlib that means asking climate scientists for
> their ideas (which is where the colormap tool idea came from).
>
> For general-purpose matplotlib projects, I recommend that matplotlib
> apply to be a mentoring organization.  The application window closes
> on the 6th.

Sorry; I didn't mean to imply that *you* should take up these other 
projects.  I was replying to the other suggestion about openGL and 
augmenting it with related ideas, for someone else that might be 
interested in the subject of the thread "matplotlib and GSOC".

Jason

On Fri, Mar 2, 2012 at 07:30, Jason Grout <jas...@cr...> wrote:
> On 3/2/12 12:44 AM, Nicolas Rougier wrote:
>>
>> An OpenGL backend would be a nice project also. I've gathered some experience with glumpy and I can help/mentor but I suspect I'm not familiar enough with all the matplotlib internals to do this alone.
>
> Similar to this, a webGL backend would be great (for example, you could
> use three.js, or you could use straight webGL/OpenGL).
>
> (of course, there's also the html5 backend that is not quite finished, I
> believe...)
>
> Work on the 3d graphics backend in general would be cool to see too, and
> could likely be added to a openGL project.

My organization is looking for projects which contribute to our own
goal (to promote the public understanding of climate science): in this
context we're helping climate scientists adopt open source techniques
and tools.  For matplotlib that means asking climate scientists for
their ideas (which is where the colormap tool idea came from).

For general-purpose matplotlib projects, I recommend that matplotlib
apply to be a mentoring organization.  The application window closes
on the 6th.
-- 
Nick Barnes, Climate Code Foundation, http://climatecode.org/

On 3/2/12 12:44 AM, Nicolas Rougier wrote:
>
>
> An OpenGL backend would be a nice project also. I've gathered some experience with glumpy and I can help/mentor but I suspect I'm not familiar enough with all the matplotlib internals to do this alone.
>

Similar to this, a webGL backend would be great (for example, you could 
use three.js, or you could use straight webGL/OpenGL).

(of course, there's also the html5 backend that is not quite finished, I 
believe...)

Work on the 3d graphics backend in general would be cool to see too, and 
could likely be added to a openGL project.

Jason

An OpenGL backend would be a nice project also. I've gathered some experience with glumpy and I can help/mentor but I suspect I'm not familiar enough with all the matplotlib internals to do this alone.


Nicolas



On Mar 1, 2012, at 23:12 , Eric Firing wrote:

> On 03/01/2012 07:18 AM, John Hunter wrote:
>> 
>> 
>> 
>> 
>> On Mar 1, 2012, at 9:01 AM, Nick Barnes<nb...@cl...>  wrote:
>> 
>>> May I ask whether matplotlib is taking part in this year's GSoC?
>>> I'm canvassing ideas for the Climate Code Foundation's
>>> participation, and some scientists have suggested
>>> matplotlib-related improvements (e.g. a GUI tool for constructing
>>> and managing segmented colormaps).  Some might be specific to
>>> climate science, others might be more generally useful to other
>>> matplotlib users.  In any case, if a student embarked on something
>>> like that, they'd need to join the matplotlib development community
>>> as well as ours, so I thought I'd drop by and see whether
>>> GSoC-sponsored development would be welcome.
>> 
>> They would certainly be welcome. We haven't solicited proposals, but
>> we could mentor one to three students who were interested. A colormap
>> GUI tool would be welcome, but it doesn't sound like an entire summer
>> would be needed, so we might want to bolt on some stuff (like general
>> improvements in mpl widgets and events to support design of such a
>> tool in native mpl rather than, or in addition to, a UI specific
>> tool)
>> JDH
> 
> I agree. I would just add that a segmented colormap tool is something 
> that has occurred to me several times as a good wish-list item, and that 
> as a physical oceanographer I certainly support expanded use of the 
> python stack in climate science.
> 
> Eric
> 
>> ------------------------------------------------------------------------------
>> Virtualization&  Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

At present all people buliding matplotlib on Mac OS X must edit 
setupext.py. I have modified setupext.py to make it work with Mac OS X 
("darwin") for Apple's python, python.org python and presumably Homebrew 
python (since that uses /usr/local).

I also included instructions for users of Fink and MacPorts (though 
perhaps those should go in a readme somewhere, instead).

Here are the changes:
<https://github.com/r-owen/matplotlib/compare/fix-setupext-for-darwin>

I would appreciate a review, so I can submit a pull request.

-- Russell

On 03/01/2012 07:18 AM, John Hunter wrote:
>
>
>
>
> On Mar 1, 2012, at 9:01 AM, Nick Barnes<nb...@cl...>  wrote:
>
>> May I ask whether matplotlib is taking part in this year's GSoC?
>> I'm canvassing ideas for the Climate Code Foundation's
>> participation, and some scientists have suggested
>> matplotlib-related improvements (e.g. a GUI tool for constructing
>> and managing segmented colormaps).  Some might be specific to
>> climate science, others might be more generally useful to other
>> matplotlib users.  In any case, if a student embarked on something
>> like that, they'd need to join the matplotlib development community
>> as well as ours, so I thought I'd drop by and see whether
>> GSoC-sponsored development would be welcome.
>
> They would certainly be welcome. We haven't solicited proposals, but
> we could mentor one to three students who were interested. A colormap
> GUI tool would be welcome, but it doesn't sound like an entire summer
> would be needed, so we might want to bolt on some stuff (like general
> improvements in mpl widgets and events to support design of such a
> tool in native mpl rather than, or in addition to, a UI specific
> tool)
> JDH

I agree. I would just add that a segmented colormap tool is something 
that has occurred to me several times as a good wish-list item, and that 
as a physical oceanographer I certainly support expanded use of the 
python stack in climate science.

Eric

> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Mar 1, 2012, at 9:01 AM, Nick Barnes <nb...@cl...> wrote:

> May I ask whether matplotlib is taking part in this year's GSoC?  I'm
> canvassing ideas for the Climate Code Foundation's participation, and
> some scientists have suggested matplotlib-related improvements (e.g. a
> GUI tool for constructing and managing segmented colormaps).  Some
> might be specific to climate science, others might be more generally
> useful to other matplotlib users.  In any case, if a student embarked
> on something like that, they'd need to join the matplotlib development
> community as well as ours, so I thought I'd drop by and see whether
> GSoC-sponsored development would be welcome.

They would certainly be welcome. We haven't solicited proposals, but we could mentor one to three students who were interested. A colormap GUI tool would be welcome, but it doesn't sound like an entire summer would be needed, so we might want to bolt on some stuff (like general improvements in mpl widgets and events to support design of such a tool in native mpl rather than, or in addition to, a UI specific tool)

JDH

May I ask whether matplotlib is taking part in this year's GSoC?  I'm
canvassing ideas for the Climate Code Foundation's participation, and
some scientists have suggested matplotlib-related improvements (e.g. a
GUI tool for constructing and managing segmented colormaps).  Some
might be specific to climate science, others might be more generally
useful to other matplotlib users.  In any case, if a student embarked
on something like that, they'd need to join the matplotlib development
community as well as ours, so I thought I'd drop by and see whether
GSoC-sponsored development would be welcome.
-- 
Nick Barnes, Climate Code Foundation, http://climatecode.org/

On Tue, Feb 28, 2012 at 2:04 PM, Benjamin Root <ben...@ou...> wrote:

>
>
> On Tue, Feb 28, 2012 at 1:00 PM, Tony Yu <ts...@gm...> wrote:
>
>>
>>
>> On Tue, Feb 28, 2012 at 11:44 AM, Benjamin Root <ben...@ou...> wrote:
>>
>>> On Mon, Feb 27, 2012 at 9:45 PM, Tony Yu <ts...@gm...> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Feb 17, 2012 at 12:17 PM, Benjamin Root <ben...@ou...>wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Feb 17, 2012 at 11:06 AM, Ryan May <rm...@gm...> wrote:
>>>>>
>>>>>> On Fri, Feb 17, 2012 at 10:14 AM, Benjamin Root <ben...@ou...>
>>>>>> wrote:
>>>>>> > Hello all,
>>>>>> >
>>>>>> > I tracked down an annoying problem in one of applications to the
>>>>>> Lasso
>>>>>> > widget I was using.  The widget constructor lets you specify a
>>>>>> function to
>>>>>> > call when the lasso operation is complete.  So, when I create a
>>>>>> Lasso, I set
>>>>>> > the canvas's widget lock to the new lasso, and the release function
>>>>>> will
>>>>>> > unlock it when it is done.  What would occassionally happen is that
>>>>>> the
>>>>>> > canvas wouldn't get unlocked and I wouldn't be able to use any
>>>>>> other widget
>>>>>> > tools.
>>>>>> >
>>>>>> > It turns out that the release function is not called if the number
>>>>>> of
>>>>>> > vertices collected is not more than 2.  So, accidental clicks that
>>>>>> activate
>>>>>> > the lasso never get cleaned up.  Because of this design, it would be
>>>>>> > impossible to guarantee a proper cleanup.  One could add another
>>>>>> > button_release callback to clean up if the canvas is still locked,
>>>>>> but there
>>>>>> > is no guarantee that that callback is not called before the lasso's
>>>>>> > callback, thereby creating a race condition.
>>>>>> >
>>>>>> > The only solution I see is to guarantee that the release callback
>>>>>> will be
>>>>>> > called regardless of the length of the vertices array.  Does
>>>>>> anybody see a
>>>>>> > problem with that?
>>>>>>
>>>>>> Not having looked at the Lasso code, wouldn't it be possible to use
>>>>>> one internal callback for the button_release event, and have this
>>>>>> callback call the users' callbacks if points > 2 and always handle the
>>>>>> unlocking of the canvas?
>>>>>>
>>>>>> Ryan
>>>>>>
>>>>>>
>>>>> The problem is that the constructor does not establish the lock.  It
>>>>> is the user's responsibility to establish a lock and release the locks for
>>>>> these widgets.  Plus, if the user's callback has cleanup code (such as mine
>>>>> did), not guaranteeing that the callback is done can leave behind a mess.
>>>>>
>>>>> Now, if we were to change the paradigm so that the Widget class
>>>>> establishes and releases the lock, and that the user should never handle
>>>>> that, then that might be a partial solution, but still leaves unsolved the
>>>>> user's cleanup needs.
>>>>>
>>>>> Ben Root
>>>>>
>>>>> I just started looking at the Lasso widget for some other changes, and
>>>> I agree: the `points > 2` check should be removed.
>>>>
>>>> As for the design of Lasso, I don't quite understand why it disconnects
>>>> the callbacks after a single call. If the onpress event from the lasso
>>>> demo<http://matplotlib.sourceforge.net/examples/event_handling/lasso_demo.html>was made a method of Lasso, then you could reuse the Lasso widget instead
>>>> of having to create a new one for each selection. Of course, this might
>>>> complicate the widget lock used in the demo, but that's true for all other
>>>> widgets, right?
>>>>
>>>> -Tony
>>>>
>>>>
>>> The Lasso disconnects itself after the button_release event because
>>> that's what indicates that you are done.  The user gets back a single
>>> Line2D object that is assumed to represent a single path with no breaks.
>>> Reusing the Lasso widget would be a situation that would require a
>>> different idiom for user interaction.  I wouldn't be against a "MultiLasso"
>>> widget that works differently from Lasso, but I really wouldn't want to
>>> make changes to existing user widgets.  It is iffy enough about whether to
>>> remove the point-count-check.
>>>
>>> Ben Root
>>>
>>>
>> Wouldn't this argument suggest that `RectangleSelector` and
>> `SpanSelector` should disconnect as well? I think their functionalities and
>> their behaviors are (or should be) pretty similar.
>>
>
> Hadn't thought about that, and I don't use them, so I hadn't noticed.
>
>
>>
>> In any case, I agree that changing this behavior of `Lasso` is not
>> desirable for compatibility reasons. I'll write up something that looks
>> more like `RectangleSelector` and `SpanSelector`. Maybe `LassoSelector`?
>>
>
> Actually, I like that idea.  It gives a consistent naming scheme.
>
> Ben Root
>
>
I just added a PR for
LassoSelector<https://github.com/matplotlib/matplotlib/pull/730>
.

As I mention in the PR notes, only the last commit adds the LassoSelector
widget<https://github.com/tonysyu/matplotlib/commit/8345d4c6afcd8afa9d646d554440de27fcc7d49c>.
The rest of the commits in the PR comes from branching off PR
724<https://github.com/matplotlib/matplotlib/pull/724>
.

Ben: I don't think you asked for justification of this functionality, but
as I was testing out this code, I decided it would be fun to demonstrate my
use case.

My example use case:
======================
I have some code to track particles flowing near a wall, but sometimes the
detected trajectories are wrong. One way to verify the trajectories is to
plot the velocity components (horizontal and vertical), and valid
velocities should cluster together (plot on left in linked images).
Nevertheless, the picture this presents isn't definitive, so it'd be nice
to pick data with specific values of velocity components and then display
the particle trajectories (plot on right in linked images).

Here are images from an interactive data explorer that uses LassoSelector:
http://imgur.com/a/OnGPo

-Tony