matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] matplotlib user guide

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

On Mon, Oct 21, 2013 at 1:26 PM, Chris Barker <chr...@no...> wrote:

> On Fri, Oct 18, 2013 at 11:56 AM, Benjamin Root <ben...@ou...> wrote:
>
> > FWIW, I think my "Anatomy of Matplotlib" tutorial I gave at SciPy 2013
> > struck a balance between pyplot and the OO interface.
>
> Grat, I'll take a look.
>
> Does the ipynb linked from the tutorial site have most of the
> presentation material?
>
>
Yup. Most of it is in the notebook. Here is the repo:
https://github.com/WeatherGod/AnatomyOfMatplotlib


> As it turns out, I need to give an intro to matplotlib class this week
> -- I've been looking for some good materials to use -- why re-invent
> the wheel?
>
> I'll be sure to give you any feedback I have.
>
>
Thanks! That would be appreciated! I am glad this will (hopefully) save
time and effort on your part to get others ramped up.


> Hmmm.. this may be a time to put together a project of materials
> designed to teach matplotlib in a classroom setting -- a little
> different than a tutorial designed to be done on one's own.
>
> There is a bunch of stuff scattered among scipy tutorials, bootcamp
> lectures, etc, but having a central place to develop materials would
> be nice.
>
> -Chris
>
>
I agree with you in principle, but I think the question is "central to
whom?" The bootcamps are useful for their own purposes and audiences, while
the scipy tutorial s are useful for their own things, etc. At this point, I
think the bootcamps and SciPy and other conferences really should be the
best venues for pushing out the "classroom-oriented" type of tutorials.

Cheers!
Ben Root

Re: [matplotlib-devel] Directories for C/C++ extensions

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

> To expand slightly, with the current situation the onus is on us to ensure
> that mpl builds OK and passes all of our tests with and without each of the
> external libraries.

If you only have internal libs, then there is less to do -- it only
need to work with the version you bundle. And making sure it works
with any-old-version-that-may-not-exist-yet is a pretty formidable
challenge!

> Linux distro packagers will choose to set up qhull as a
> required dependency for their mpl package, and once they have done this can
> simply delete our directory containing the qhull source code in their mpl
> source package,

If they are going to insist on doing this, then, yes you should
certainly do it this way.

> we can all be confident that it will work correctly.

only if you've  tested against the version (maybe patched) of the
external lib they are using...

> If we always used our internal version then distro packagers would have to
> change our setup scripts to build using the external libraries.  This would
> be more time-consuming and error prone leading to less timely mpl distro
> releases.  We need to make their job as easy as possible.

it's easiest for them if they don't try to pull out an included
dependency -- but maybe you're right that that REALLY want to do that!

>The needs of the distro packagers, which are primarily security and
> stability, are sometimes at odds with the needs of scientific software,
> where the premium is on reproducibility.  The output of matplotlib depends
> on the versions of some of its dependencies, not the version of matplotlib
> alone, and that's problematic for some...

exactly -- if we know exactly which version of a lib is in use, we
know that it works the way we expect in the use cases we expect to use
it in.

But I'm not maintaining this code, so have at it in the way that makes
sense to you.

NOTE: it would be a different story if this were a netwroking protocol
lib, or something where security patches would be critical. Maybe I'm
naive, but this doesn't seem likely in this case.

-Chris





-- 

Christopher Barker, Ph.D.
Oceanographer

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

Chr...@no...

Re: [matplotlib-devel] matplotlib user guide

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

On Fri, Oct 18, 2013 at 11:56 AM, Benjamin Root <ben...@ou...> wrote:

> FWIW, I think my "Anatomy of Matplotlib" tutorial I gave at SciPy 2013
> struck a balance between pyplot and the OO interface.

Grat, I'll take a look.

Does the ipynb linked from the tutorial site have most of the
presentation material?

As it turns out, I need to give an intro to matplotlib class this week
-- I've been looking for some good materials to use -- why re-invent
the wheel?

I'll be sure to give you any feedback I have.

Hmmm.. this may be a time to put together a project of materials
designed to teach matplotlib in a classroom setting -- a little
different than a tutorial designed to be done on one's own.

There is a bunch of stuff scattered among scipy tutorials, bootcamp
lectures, etc, but having a central place to develop materials would
be nice.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

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

Chr...@no...

Re: [matplotlib-devel] ggplot for matplotlib

[Michael D. <md...@st...>]

Yes -- I reached out to the author about exactly that this morning.  It 
would be great to closely collaborate on this.

Mike

On 10/21/2013 01:06 PM, Todd wrote:
> Seems like a lot of what they are doing could be upstreamed into 
> matplotlib.  Then they could just wrap it in their own ggplot syntax.  
> That would improve matplotlib and simplify the maintainance for them.
>
>
> On Mon, Oct 21, 2013 at 5:58 PM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
>     I just learned about this today, and thought I'd share.  It's an
>     implementation of the ggplot interface on top of matplotlib:
>
>     http://blog.yhathq.com/posts/ggplot-for-python.html
>
>     -- 
>                         _
>     |\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
>     |  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
>
>     http://www.droettboom.com
>
>
>     ------------------------------------------------------------------------------
>     October Webinars: Code for Performance
>     Free Intel webinars can help you accelerate application performance.
>     Explore tips for MPI, OpenMP, advanced profiling, and more. Get
>     the most from
>     the latest Intel processors and coprocessors. See abstracts and
>     register >
>     http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Matplotlib-devel mailing list
>     Mat...@li...
>     <mailto:Mat...@li...>
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

Re: [matplotlib-devel] ggplot for matplotlib

[Todd <tod...@gm...>]

Seems like a lot of what they are doing could be upstreamed into
matplotlib.  Then they could just wrap it in their own ggplot syntax.  That
would improve matplotlib and simplify the maintainance for them.


On Mon, Oct 21, 2013 at 5:58 PM, Michael Droettboom <md...@st...> wrote:

>  I just learned about this today, and thought I'd share.  It's an
> implementation of the ggplot interface on top of matplotlib:
>
> http://blog.yhathq.com/posts/ggplot-for-python.html
>
> --
>                    _
> |\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
> |  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
> http://www.droettboom.com
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Re: [matplotlib-devel] Test failure testing binary installer - any clues?

[Michael D. <md...@st...>]

On 10/19/2013 04:24 PM, Matthew Brett wrote:
> Hi,
>
> On Fri, Oct 18, 2013 at 4:47 AM, Michael Droettboom <md...@st...> wrote:
>> On 10/18/2013 02:11 AM, Matthew Brett wrote:
>>> Hi,
>>>
>>> I'm testing the binary installer build:
>>>
>>> https://travis-ci.org/matthew-brett/mpl-osx-binaries/builds/12703220
>>>
>>> and I'm getting a test failure on Python 3.3 (not Python 2.7):
>>>
>>> ======================================================================
>>> FAIL: matplotlib.tests.test_lines.test_invisible_Line_rendering.test
>>> ----------------------------------------------------------------------
>>> Traceback (most recent call last):
>>>     File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/nose/case.py",
>>> line 198, in runTest
>>>       self.test(*self.arg)
>>>     File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/testing/decorators.py",
>>> line 73, in test
>>>       self._func()
>>>     File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/tests/test_lines.py",
>>> line 54, in test_invisible_Line_rendering
>>>       assert_true(slowdown_factor < slowdown_threshold)
>>> AssertionError: False is not true
>>>
>>> ----------------------------------------------------------------------
>>> Ran 1464 tests in 656.822s
>>>
>>> Is this a problem?  What should I do to debug further?
>>>
>> I've never seen that failure before...
>>
>> I wonder if Pierre Haessig has any thoughts, as the author of that test...
>>
>> Mike
> Thanks.  I get the same error running under Python 2.7 on a clean 10.6 machine.
>
> Also I get:
>
> ======================================================================
> FAIL: matplotlib.tests.test_contour.test_contour_manual_labels.test
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py",
> line 197, in runTest
>      self.test(*self.arg)
>    File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/testing/decorators.py",
> line 40, in failer
>      result = f(*args, **kwargs)
>    File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/testing/decorators.py",
> line 159, in do_test
>      '(RMS %(rms).3f)'%err)
> ImageComparisonFailure: images not close:
> /Users/mb312/mpkg-test/mpl-test/result_images/test_contour/contour_manual_labels.png
> vs. /Users/mb312/mpkg-test/mpl-test/result_images/test_contour/contour_manual_labels-expected.png
> (RMS 15.521)
>
> The images look identical to me...
Can you send me the failed image?  If we both agree they are the same, 
it may just need to have the RMS increased to account for font differences.

Also Cc'ing Pierre about the above issue.

Mike

-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

Re: [matplotlib-devel] Directories for C/C++ extensions

[Michael D. <md...@st...>]

On 10/19/2013 04:14 AM, Ian Thomas wrote:
> On 18 October 2013 19:18, Chris Barker <chr...@no... 
> <mailto:chr...@no...>> wrote:
>
>     Ian,
>
>     > I am working on a PR to replace the use of matplotlib.delaunay
>     with the
>     > Qhull library.
>
>     nice! -- ( though I sure wish Qhull did constrained delaunay...)
>
>     > Installation will be similar to the existing packages LibAgg
>     > and CXX in that if the system already has a sufficiently recent
>     version of
>     > Qhull installed then matplotlib will use that, otherwise it will
>     build the
>     > required library from the source code shipped with matplotlib.
>
>     Why bother, why not just always build the internal version?
>
>     (for that matter, same with agg)
>
>     Wouldn't it be a lot easier and more robust to be sure that everyone
>     is running the exact same code?
>
>     What are the odds that folks are using qhull for something else, and
>     even more to the point, what are the odds that the duplication of this
>     lib would matter one wit?
>
>     This isn't like LAPACK, where folks have a compellling reason to run a
>     particular version.
>
>     -- just my thoughts on how to keep things simpler.
>
>
> Chris,
>
> Todd has hit the nail on the head.
>
> To expand slightly, with the current situation the onus is on us to 
> ensure that mpl builds OK and passes all of our tests with and without 
> each of the external libraries. Linux distro packagers will choose to 
> set up qhull as a required dependency for their mpl package, and once 
> they have done this can simply delete our directory containing the 
> qhull source code in their mpl source package, and it will build OK 
> without any further changes and we can all be confident that it will 
> work correctly.
>
> If we always used our internal version then distro packagers would 
> have to change our setup scripts to build using the external 
> libraries.  This would be more time-consuming and error prone leading 
> to less timely mpl distro releases.  We need to make their job as easy 
> as possible.

Agreed on all of these points, and I'm not advocating a change from what 
Ian is doing.  However, as get on in years, I'm starting to more and 
more feel like the needs of the distro packagers, which are primarily 
security and stability, are sometimes at odds with the needs of 
scientific software, where the premium is on reproducibility.  The 
output of matplotlib depends on the versions of some of its 
dependencies, not the version of matplotlib alone, and that's 
problematic for some...  Anyway, just food for thought. I still think 
the most practical approach is the one we're taking (shipping 
dependencies, but making it easy to use the system libraries when 
available).

Mike

-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

[matplotlib-devel] ggplot for matplotlib

[Michael D. <md...@st...>]

I just learned about this today, and thought I'd share.  It's an 
implementation of the ggplot interface on top of matplotlib:

http://blog.yhathq.com/posts/ggplot-for-python.html

-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

Re: [matplotlib-devel] matplotlib user guide

[mark <ma...@me...>]

hi matplotlib developers

as I previously posted, I have thought about structure and flow of the
user guide

my fist cut of a change set is viewable here:
https://github.com/marqh/matplotlib/compare/userGuideShape

it keeps all of the same content as the current user guide but
subdivides some sections into categories:
   configuration
   beginner's guide
   advanced guide

So, all feedback very gratefully received, but a particular focus
requested on:
  - sub-section headings
  - sub-section contents (scope)
  - ordering

I would like to focus on getting the categorisation and ordering
helpful for this piece of work.

I feel that this will give us more accessible ways into adding new
sections or adapting sections but that this should wait for a follow up
activity.

many thanks
mark

On Wed, 25 Sep 2013 08:19:59 +0000
mark <ma...@me...> wrote:

> hi matplotlib developers
> 
> I have been considering the matplotlib user guide structure and it
> has occured to me that there are two user guides interleaved here:
>   1. Introduction for new users
>   2. Library tour for developers
> 
> I think that this structure makes it challenging for new users to
> benefit from the user guide as much as they could.  
> 
> I would like to see the user guide separated into two sections, with
> the two different audiences in mind.  I feel this would enable new
> users of the library to have a more targeted introduction to some of
> the neat features without getting bogged down in details they are
> unlikely to need (or comprehend). 
> 
> I am very happy to have a go at this and put up a set of suggested
> changes but I would value input from the community on this approach
> and my category suggestions before I submit a pull request.
> 
> many thanks
> mark
> 
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> most from the latest Intel processors and coprocessors. See abstracts
> and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
> _______________________________________________ Matplotlib-devel
> mailing list Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Pull request

[Todd <tod...@gm...>]

On Mon, Oct 21, 2013 at 3:13 PM, Pierre Haessig <pie...@cr...>wrote:

> Hi,
>
> Le 20/10/2013 09:45, Todd a écrit :
> > I submitted a pull request #2522 [1].  It includes support for more
> > basic spectrum plots like magnitude and phase spectrums.  These are
> > extremely commonly used in signal processing, acoustics, and many
> > other fields, but are also very important for educational usage since
> > pretty much anyone going through one of several engineering degrees
> > like electrical engineering has to learn these types of plots.  I have
> > heard a number of colleagues complaining about the lack of these plots
> > in matlab.
>
> Having specific signal processing functions is indeed important. I hust
> have a question about "phase" vs. "angle" spectrum. From browsing
> quickly through you doc, it seems that the difference is just about
> *unwrapping the phase*. If that's indeed the case, I've two
> questions/remarks:
>
> 1) is the terminology "phase" vs. "angle" spectrum standardized ? I must
> say I've never heard of one meaning "wrapped" and the other "unwrapped".
> I didn't find similar terms in Matlab docs, but I didn't search that
> thoroughly.
>

The "angle" function in numpy returns the wrapped angle, while the "unwrap"
function documentation talks about phase, so it is consistent with the
usage in numpy.   Further, in signal processing, phases can have any value,
while "angle" often refers to the angle between two lines, which must be
wrapped.

There may be some ambiguity, but I made sure to explain it in the
documentation and provide links between the two functions so people know
what they should do if they want to use the other approach.


> 2) Should there be two separate functions for these two, or just one
> function, with a switch argument `unwrap` ? (I guess it would be True by
> default)
>

I originally was going to do that, but decided against it.  The problem is
with specgram.  Here, I thought it would be needlessly complicated to add
an "unwrap" parameter that is only useful for one "mode".  To make it
obvious to users, I wanted to keep specgram as similar as possible to the
other plot types, and that involved keeping the parameter.

Further, this approach is simpler to code and easier to maintain. Having to
deal with the "unwrap" parameter would have been more difficult to
program.  Dealing with both an "unwrap" parameter in some cases and a
separate "mode" in others would have been even more complicated.

Further, _spectral_helper and specgram already have a huge number of
arguments.  This way I was able to get away with just adding one new
argument rather than two.

Re: [matplotlib-devel] Pull request

[Pierre H. <pie...@cr...>]

Hi,

Le 20/10/2013 09:45, Todd a écrit :
> I submitted a pull request #2522 [1].  It includes support for more
> basic spectrum plots like magnitude and phase spectrums.  These are
> extremely commonly used in signal processing, acoustics, and many
> other fields, but are also very important for educational usage since
> pretty much anyone going through one of several engineering degrees
> like electrical engineering has to learn these types of plots.  I have
> heard a number of colleagues complaining about the lack of these plots
> in matlab.

Having specific signal processing functions is indeed important. I hust
have a question about "phase" vs. "angle" spectrum. From browsing
quickly through you doc, it seems that the difference is just about
*unwrapping the phase*. If that's indeed the case, I've two
questions/remarks:

1) is the terminology "phase" vs. "angle" spectrum standardized ? I must
say I've never heard of one meaning "wrapped" and the other "unwrapped".
I didn't find similar terms in Matlab docs, but I didn't search that
thoroughly.

2) Should there be two separate functions for these two, or just one
function, with a switch argument `unwrap` ? (I guess it would be True by
default)

best,
Pierre

[matplotlib-devel] Pull request

[Todd <tod...@gm...>]

Hello,

I submitted a pull request #2522 [1].  It includes support for more basic
spectrum plots like magnitude and phase spectrums.  These are extremely
commonly used in signal processing, acoustics, and many other fields, but
are also very important for educational usage since pretty much anyone
going through one of several engineering degrees like electrical
engineering has to learn these types of plots.  I have heard a number of
colleagues complaining about the lack of these plots in matlab.

It has been up for 5 days, but I haven't received any comments on its
content or structure.  I understand that it is a pretty substantial patch,
but I think the features are very useful.

I am also a bit concerned that patches covering the same code might be
submitted and accepted while I am waiting for this, since such changes
would be hard to merge into my branch.

So does anyone have any thoughts on the patch?

[1] https://github.com/matplotlib/matplotlib/pull/2522

Re: [matplotlib-devel] Test failure testing binary installer - any clues?

[Matthew B. <mat...@gm...>]

Hi,

On Fri, Oct 18, 2013 at 4:47 AM, Michael Droettboom <md...@st...> wrote:
> On 10/18/2013 02:11 AM, Matthew Brett wrote:
>> Hi,
>>
>> I'm testing the binary installer build:
>>
>> https://travis-ci.org/matthew-brett/mpl-osx-binaries/builds/12703220
>>
>> and I'm getting a test failure on Python 3.3 (not Python 2.7):
>>
>> ======================================================================
>> FAIL: matplotlib.tests.test_lines.test_invisible_Line_rendering.test
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>    File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/nose/case.py",
>> line 198, in runTest
>>      self.test(*self.arg)
>>    File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/testing/decorators.py",
>> line 73, in test
>>      self._func()
>>    File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/tests/test_lines.py",
>> line 54, in test_invisible_Line_rendering
>>      assert_true(slowdown_factor < slowdown_threshold)
>> AssertionError: False is not true
>>
>> ----------------------------------------------------------------------
>> Ran 1464 tests in 656.822s
>>
>> Is this a problem?  What should I do to debug further?
>>
>
> I've never seen that failure before...
>
> I wonder if Pierre Haessig has any thoughts, as the author of that test...
>
> Mike

Thanks.  I get the same error running under Python 2.7 on a clean 10.6 machine.

Also I get:

======================================================================
FAIL: matplotlib.tests.test_contour.test_contour_manual_labels.test
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py",
line 197, in runTest
    self.test(*self.arg)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/testing/decorators.py",
line 40, in failer
    result = f(*args, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/testing/decorators.py",
line 159, in do_test
    '(RMS %(rms).3f)'%err)
ImageComparisonFailure: images not close:
/Users/mb312/mpkg-test/mpl-test/result_images/test_contour/contour_manual_labels.png
vs. /Users/mb312/mpkg-test/mpl-test/result_images/test_contour/contour_manual_labels-expected.png
(RMS 15.521)

The images look identical to me...

Cheers,

Matthew

Re: [matplotlib-devel] Directories for C/C++ extensions

[Ian T. <ian...@gm...>]

On 18 October 2013 19:18, Chris Barker <chr...@no...> wrote:

> Ian,
>
> > I am working on a PR to replace the use of matplotlib.delaunay with the
> > Qhull library.
>
> nice! -- ( though I sure wish Qhull did constrained delaunay...)
>
> > Installation will be similar to the existing packages LibAgg
> > and CXX in that if the system already has a sufficiently recent version
> of
> > Qhull installed then matplotlib will use that, otherwise it will build
> the
> > required library from the source code shipped with matplotlib.
>
> Why bother, why not just always build the internal version?
>
> (for that matter, same with agg)
>
> Wouldn't it be a lot easier and more robust to be sure that everyone
> is running the exact same code?
>
> What are the odds that folks are using qhull for something else, and
> even more to the point, what are the odds that the duplication of this
> lib would matter one wit?
>
> This isn't like LAPACK, where folks have a compellling reason to run a
> particular version.
>
> -- just my thoughts on how to keep things simpler.
>

Chris,

Todd has hit the nail on the head.

To expand slightly, with the current situation the onus is on us to ensure
that mpl builds OK and passes all of our tests with and without each of the
external libraries.  Linux distro packagers will choose to set up qhull as
a required dependency for their mpl package, and once they have done this
can simply delete our directory containing the qhull source code in their
mpl source package, and it will build OK without any further changes and we
can all be confident that it will work correctly.

If we always used our internal version then distro packagers would have to
change our setup scripts to build using the external libraries.  This would
be more time-consuming and error prone leading to less timely mpl distro
releases.  We need to make their job as easy as possible.

Ian

Re: [matplotlib-devel] Directories for C/C++ extensions

[Todd <tod...@gm...>]

On Oct 18, 2013 8:20 PM, "Chris Barker" <chr...@no...> wrote:
>
> Ian,
>
> > I am working on a PR to replace the use of matplotlib.delaunay with the
> > Qhull library.
>
> nice! -- ( though I sure wish Qhull did constrained delaunay...)
>
> > Installation will be similar to the existing packages LibAgg
> > and CXX in that if the system already has a sufficiently recent version
of
> > Qhull installed then matplotlib will use that, otherwise it will build
the
> > required library from the source code shipped with matplotlib.
>
> Why bother, why not just always build the internal version?
>
> (for that matter, same with agg)
>
> Wouldn't it be a lot easier and more robust to be sure that everyone
> is running the exact same code?
>
> What are the odds that folks are using qhull for something else, and
> even more to the point, what are the odds that the duplication of this
> lib would matter one wit?
>
> This isn't like LAPACK, where folks have a compellling reason to run a
> particular version.
>
> -- just my thoughts on how to keep things simpler.
>
>
> -Chris

>From a Linux distro packaging perspective bundled external libs are a big
no-no. If a patch is needed for whatever reason packagers don't want to
have to go and hunt down dozens of copies of the same library.  In some
cases there is no alternative but it should be avoided whenever possible.

Re: [matplotlib-devel] matplotlib user guide

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

On Fri, Oct 18, 2013 at 2:13 PM, Chris Barker <chr...@no...> wrote:

> On Fri, Oct 4, 2013 at 1:40 PM, Russell E. Owen <ro...@uw...> wrote:
> >> Introducing Plotting with Matplotlib
> >>
> >>     Pyplot tutorial
> >>         Controlling line properties
> >>         Working with multiple figures and axes
> >>         Working with text
> >>     Interactive navigation
> >>         Navigation Keyboard Shortcuts
> >>     Working with text
> >>         Text introduction
> >>         Basic text commands
> >>         Text properties and layout
> >>         Writing mathematical expressions
> >>         Text rendering With LaTeX
> >>         Annotating text
> > ...
>
> > - Would you be willing to include a section on using the class API? (I'm
> > assuming the above is all based on using pyplot?).
>
> +inf
>
> Even better, dump pyplot and use primarily the OO API. Asside from
> folks that dont want to change anything when moving from Matlab, we
> should all be using teh primarily OO API.
>
> is it really that hard to type:
>
> ax.plot()
>
> rather than
>
> plot() ?
>
> And when you move away from interactive use (and we all should fi your
> typing more than 4-5 lines of code) teh OO interface is a much better
> way to go.
>
> (I know, iPython notebooks allow you do do a LOT with esentially an
> interactive interpreter, but still.....)
>
> Anyway, I've always thought it was a real shame that most of the
> tutorials on MPL out there get people started on what I'm convinced is
> the wrong foot.
>
> - just my opinionated $0.02 worth...
>
> -Chris
>
>
FWIW, I think my "Anatomy of Matplotlib" tutorial I gave at SciPy 2013
struck a balance between pyplot and the OO interface. I welcome any and all
feedback on that tutorial which I plan to give again next year as well as
an intermediate "Anatomy of Matplotlib" tutorial.

Cheers!
Ben Root

Re: [matplotlib-devel] Directories for C/C++ extensions

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

Ian,

> I am working on a PR to replace the use of matplotlib.delaunay with the
> Qhull library.

nice! -- ( though I sure wish Qhull did constrained delaunay...)

> Installation will be similar to the existing packages LibAgg
> and CXX in that if the system already has a sufficiently recent version of
> Qhull installed then matplotlib will use that, otherwise it will build the
> required library from the source code shipped with matplotlib.

Why bother, why not just always build the internal version?

(for that matter, same with agg)

Wouldn't it be a lot easier and more robust to be sure that everyone
is running the exact same code?

What are the odds that folks are using qhull for something else, and
even more to the point, what are the odds that the duplication of this
lib would matter one wit?

This isn't like LAPACK, where folks have a compellling reason to run a
particular version.

-- just my thoughts on how to keep things simpler.


-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

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

Chr...@no...

Re: [matplotlib-devel] matplotlib user guide

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

On Fri, Oct 4, 2013 at 1:40 PM, Russell E. Owen <ro...@uw...> wrote:
>> Introducing Plotting with Matplotlib
>>
>>     Pyplot tutorial
>>         Controlling line properties
>>         Working with multiple figures and axes
>>         Working with text
>>     Interactive navigation
>>         Navigation Keyboard Shortcuts
>>     Working with text
>>         Text introduction
>>         Basic text commands
>>         Text properties and layout
>>         Writing mathematical expressions
>>         Text rendering With LaTeX
>>         Annotating text
> ...

> - Would you be willing to include a section on using the class API? (I'm
> assuming the above is all based on using pyplot?).

+inf

Even better, dump pyplot and use primarily the OO API. Asside from
folks that dont want to change anything when moving from Matlab, we
should all be using teh primarily OO API.

is it really that hard to type:

ax.plot()

rather than

plot() ?

And when you move away from interactive use (and we all should fi your
typing more than 4-5 lines of code) teh OO interface is a much better
way to go.

(I know, iPython notebooks allow you do do a LOT with esentially an
interactive interpreter, but still.....)

Anyway, I've always thought it was a real shame that most of the
tutorials on MPL out there get people started on what I'm convinced is
the wrong foot.

- just my opinionated $0.02 worth...

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

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

Chr...@no...

Re: [matplotlib-devel] Test failure testing binary installer - any clues?

[Michael D. <md...@st...>]

On 10/18/2013 02:11 AM, Matthew Brett wrote:
> Hi,
>
> I'm testing the binary installer build:
>
> https://travis-ci.org/matthew-brett/mpl-osx-binaries/builds/12703220
>
> and I'm getting a test failure on Python 3.3 (not Python 2.7):
>
> ======================================================================
> FAIL: matplotlib.tests.test_lines.test_invisible_Line_rendering.test
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>    File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/nose/case.py",
> line 198, in runTest
>      self.test(*self.arg)
>    File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/testing/decorators.py",
> line 73, in test
>      self._func()
>    File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/tests/test_lines.py",
> line 54, in test_invisible_Line_rendering
>      assert_true(slowdown_factor < slowdown_threshold)
> AssertionError: False is not true
>
> ----------------------------------------------------------------------
> Ran 1464 tests in 656.822s
>
> Is this a problem?  What should I do to debug further?
>

I've never seen that failure before...

I wonder if Pierre Haessig has any thoughts, as the author of that test...

Mike

-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

[matplotlib-devel] Test failure testing binary installer - any clues?

[Matthew B. <mat...@gm...>]

Hi,

I'm testing the binary installer build:

https://travis-ci.org/matthew-brett/mpl-osx-binaries/builds/12703220

and I'm getting a test failure on Python 3.3 (not Python 2.7):

======================================================================
FAIL: matplotlib.tests.test_lines.test_invisible_Line_rendering.test
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/nose/case.py",
line 198, in runTest
    self.test(*self.arg)
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/testing/decorators.py",
line 73, in test
    self._func()
  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/tests/test_lines.py",
line 54, in test_invisible_Line_rendering
    assert_true(slowdown_factor < slowdown_threshold)
AssertionError: False is not true

----------------------------------------------------------------------
Ran 1464 tests in 656.822s

Is this a problem?  What should I do to debug further?

Cheers,

Matthew

Re: [matplotlib-devel] IPython Comm backend

[Jason G. <jas...@cr...>]

On 10/16/13 1:58 PM, Michael Droettboom wrote:
> Sorry to take so long to get to this. This is a nice piece of work.
>
> The most obvious thing is that this is a copy-and-paste of the existing
> WebAgg backend -- and maintaining the two is going to be much harder
> than building both out of the same pieces.  As of 6389d14f, the WebAgg
> backend was refactored so that the transport that it uses to communicate
> to the browser is no longer hard coded.  This was done in large part to
> support working with IPyhton in this way.  (That is, it used to only
> communicate with the browser through Tornado, but now it can be anything
> that can send bits back and forth).  There's an example of this in
> `examples/user_interfaces/embedding_webagg.py` that shows how to do this
> (using Tornado, but again, it doesn't have to be). There's no guarantees
> that this interface is sufficient, so it may require some back and forth
> on this to make it all work.
>
> I think the first thing I would do would be to refactor this to use
> that.  It's a little hard to tell what you've changed from the original
> WebAgg backend to get it to support IPython.  If it were built on top
> of, rather than in addition to, WebAgg, that would be more obvious.

Thanks for the feedback.  I was thinking that a refactor to pull out the 
communication layer would be really nice.

I didn't change the WebAgg backend because I figured you wanted it 
around still.  I figured a plain old diff with the file would reveal 
changes.

Anyways, thanks for the pointer to the refactor commit.  I hope to look 
at this again sometime soon.

Jason

Re: [matplotlib-devel] IPython Comm backend

[Michael D. <md...@st...>]

Sorry to take so long to get to this. This is a nice piece of work.

The most obvious thing is that this is a copy-and-paste of the existing 
WebAgg backend -- and maintaining the two is going to be much harder 
than building both out of the same pieces.  As of 6389d14f, the WebAgg 
backend was refactored so that the transport that it uses to communicate 
to the browser is no longer hard coded.  This was done in large part to 
support working with IPyhton in this way.  (That is, it used to only 
communicate with the browser through Tornado, but now it can be anything 
that can send bits back and forth).  There's an example of this in 
`examples/user_interfaces/embedding_webagg.py` that shows how to do this 
(using Tornado, but again, it doesn't have to be). There's no guarantees 
that this interface is sufficient, so it may require some back and forth 
on this to make it all work.

I think the first thing I would do would be to refactor this to use 
that.  It's a little hard to tell what you've changed from the original 
WebAgg backend to get it to support IPython.  If it were built on top 
of, rather than in addition to, WebAgg, that would be more obvious.

Mike

On 10/10/2013 06:08 PM, Jason Grout wrote:
> I've been working on a backend based on the webagg backend, but that
> uses the IPython Comm architecture at
> https://github.com/ipython/ipython/pull/4195 to send messages instead of
> starting a server and opening websocket connections.  I have an initial
> version in my github ipython-comm branch (see
> https://github.com/jasongrout/matplotlib/compare/ipython-comm).  I'm
> getting confused about how the backend infrastructure works, though,
> like what the purpose for the FigureManager class is, etc.  I'm running
> out of time to work on this now, and I'm hoping that someone will take
> what work I've done here and get it working properly with the matplotlib
> architecture.  If not, I'll probably tinker with this more later.
>
> Thanks,
>
> Jason
>
> --
> Jason Grout
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

[matplotlib-devel] Google Hangout Agenda

[Michael D. <md...@st...>]

I've created a wiki page to brainstorm agenda ideas for next week's meeting.

https://github.com/matplotlib/matplotlib/wiki/Hangout-2013-10-24

-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

Re: [matplotlib-devel] Gtk3 app that calls matplotlib

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

Looking through the code I realize that in interactive mode (ipython)
there is no call to show() by default.
And if you call it, it does not call mailoop because is_interactive==Tr
ue
So why is there the restriction to call only once Gtk.main in mailoop?
if it is not called anyway

Why not make that restriction to call Gtk.main in  mainloop dependant
on is_interactive? as the call Gtk.main_quit is in the destroy method


Federico

On Fri, Oct 11, 2013 at 4:15 PM, Federico Ariza
<ari...@gm...> wrote:
> Sorry, the replay-all is not my default.
>
> In that case it is easier for me to monkey patch just the mainloop to
> invoke Gtk.main everytime.
>
> But again, even if we are talking about interactive (ipython), why is
> it unbalanced?
> I mean calls Gtk.main vs Gtk.main_quit?
>
> Federico
>
>
>
> On Fri, Oct 11, 2013 at 3:28 PM, Thomas A Caswell <tca...@uc...> wrote:
>> Please keep all emails in-band
>>
>> I was commenting that the issue you are having with getting easy-to-use
>> pre-built figures in a non-interactive program without dragging pyplot in is
>> the same as what I think the root of 2503 is and the re-factor I proposed to
>> make your life easier would also help that case (I think).
>>
>> The gui backends were (as I understand it, someone please correct me if I am
>> wrong) built to play nice with ipython to put together a MATLAB-like
>> interface.  The fact that you can then embed the gui-framework dependent
>> bits of matplotlib in other gui applications is a nice side-effect, but not
>> one of the initial design goals.  This is why the `figure_manager` code is
>> (too-)tightly coupled to _pylab_helpers.
>>
>> See the examples at http://matplotlib.org/examples/user_interfaces/  making
>> a window with a canvas + tool bar is pretty easy.
>>
>> A quick and dirty solution might be to just monkey patch the
>> figure_manager.destroy function when your app starts up to remove the check
>> that shuts down the main loop.
>>
>> Tom
>>
>>
>> On Fri, Oct 11, 2013 at 1:40 PM, Federico Ariza <ari...@gm...>
>> wrote:
>>>
>>> Sorry I don't get it.
>>> Are you suggesting to explain this little predicament in the PR to
>>> give another point of view? or
>>> You want me to check the PR and try to use the solutions proposed there?
>>>
>>> Federico
>>>
>>> On Fri, Oct 11, 2013 at 1:32 PM, Thomas A Caswell <tca...@uc...>
>>> wrote:
>>> > embedding vs launching is a distinction without a difference, you are
>>> > integrating matplotlib with your own gui application.
>>> >
>>> > That said, it would be nice to re-factor the figure_manager classes so
>>> > they
>>> > they make no reference to `Gcf` or anything associated with pylab and
>>> > could
>>> > be easily re-used.
>>> >
>>> > I think that would also help with the issues in
>>> > https://github.com/matplotlib/matplotlib/pull/2503
>>> >
>>> > Tom
>>> >
>>> >
>>> > On Fri, Oct 11, 2013 at 12:14 PM, Federico Ariza
>>> > <ari...@gm...>
>>> > wrote:
>>> >>
>>> >> Again
>>> >>
>>> >> In the example the plotting is inside the callback (just for
>>> >> simplicity), but in reality, the plotting is in another class,
>>> >> somewhere else that can be called standalone to produce the plots.
>>> >>
>>> >> Federico
>>> >>
>>> >> On Fri, Oct 11, 2013 at 1:12 PM, Federico Ariza
>>> >> <ari...@gm...> wrote:
>>> >> > I am not embedding, just launching, as the example shows.
>>> >> >
>>> >> > Federico
>>> >> >
>>> >> > On Fri, Oct 11, 2013 at 1:11 PM, Thomas A Caswell
>>> >> > <tca...@uc...> wrote:
>>> >> >> If you are embedding matplotlib, do not import `pyplot`.  `pyplot`
>>> >> >> sets
>>> >> >> up a
>>> >> >> bunch of gui-magic (tm) in the background (as you found in
>>> >> >> `figure_manager`).
>>> >> >>
>>> >> >> Tom
>>> >> >>
>>> >> >>
>>> >> >> On Fri, Oct 11, 2013 at 11:57 AM, Federico Ariza
>>> >> >> <ari...@gm...>
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> Hello everybody
>>> >> >>>
>>> >> >>> Working on one GTK3 app, that calls matplotlib to plot some
>>> >> >>> figures, I
>>> >> >>> found that closing all the figures from matplotlib kills my app
>>> >> >>> also.
>>> >> >>> The problem....
>>> >> >>>
>>> >> >>> Gtk.main() is called only if there is no previous invocation, in my
>>> >> >>> case, my Gtk3 app invokes main, so the mainloop won't call it
>>> >> >>> again.
>>> >> >>>
>>> >> >>> #in backend_gtk3.py
>>> >> >>> #
>>> >> >>> class Show(ShowBase):
>>> >> >>>     def mainloop(self):
>>> >> >>>         if Gtk.main_level() == 0:
>>> >> >>>             Gtk.main()
>>> >> >>>
>>> >> >>> But in the "destroy" method of the figure manager calls
>>> >> >>> Gtk.main_quit
>>> >> >>> everytime that there are no more figures
>>> >> >>>
>>> >> >>> #in backend_gtk3.py inside destroy method of FigureManagerGTK3
>>> >> >>> #
>>> >> >>> if Gcf.get_num_fig_managers()==0 and \
>>> >> >>>                not matplotlib.is_interactive() and \
>>> >> >>>                Gtk.main_level() >= 1:
>>> >> >>>             Gtk.main_quit()
>>> >> >>>
>>> >> >>>
>>> >> >>> So basically we are not calling Gtk.main but we are Gtk.calling
>>> >> >>> main_quit.
>>> >> >>> Isn't it more natural to call Gtk.main the same amount of times
>>> >> >>> that
>>> >> >>> we are going to call Gtk.main_quit?
>>> >> >>>
>>> >> >>> Adding matplotlib.rcParams['interactive'] = True doesn't help
>>> >> >>>
>>> >> >>> Here is my little testing code
>>> >> >>>
>>> >> >>> ##############################
>>> >> >>> #file myapp.py
>>> >> >>>
>>> >> >>> import matplotlib
>>> >> >>> matplotlib.rcParams['interactive'] = True
>>> >> >>> matplotlib.use('GTK3AGG')
>>> >> >>> import matplotlib.pyplot as plt
>>> >> >>>
>>> >> >>> from gi.repository import Gtk
>>> >> >>>
>>> >> >>> class MyWindow(Gtk.Window):
>>> >> >>>
>>> >> >>>     def __init__(self):
>>> >> >>>         Gtk.Window.__init__(self, title="Hello World")
>>> >> >>>
>>> >> >>>         self.button = Gtk.Button(label="Click Here")
>>> >> >>>         self.button.connect("clicked", self.on_button_clicked)
>>> >> >>>         self.add(self.button)
>>> >> >>>
>>> >> >>>     def on_button_clicked(self, widget):
>>> >> >>>         fig = plt.figure()
>>> >> >>>         ax = fig.add_subplot(111)
>>> >> >>>         ax.plot([1,2,3])
>>> >> >>>         plt.show()
>>> >> >>>
>>> >> >>> win = MyWindow()
>>> >> >>> win.connect("delete-event", Gtk.main_quit)
>>> >> >>> win.show_all()
>>> >> >>> Gtk.main()
>>> >> >>> #########################
>>> >> >>>
>>> >> >>> I know this is related to interactive mode, but running from
>>> >> >>> console
>>> >> >>> >>> python myapp.py
>>> >> >>> reproduces the problem
>>> >> >>>
>>> >> >>> Why hasattr(sys, 'ps1') is False? if I am running it from console?
>>> >> >>> how
>>> >> >>> do I change this?
>>> >> >>>
>>> >> >>>
>>> >> >>> Thanks
>>> >> >>> Federico
>>> >> >>>
>>> >> >>> P.S. Does anybody had the time to check my PR for
>>> >> >>> multi-figure-manager?
>>> >> >>> https://github.com/matplotlib/matplotlib/pull/2465
>>> >> >>>
>>> >> >>> --
>>> >> >>> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>>> >> >>>
>>> >> >>> -- Antonio Alducin --
>>> >> >>>
>>> >> >>>
>>> >> >>>
>>> >> >>>
>>> >> >>> ------------------------------------------------------------------------------
>>> >> >>> October Webinars: Code for Performance
>>> >> >>> Free Intel webinars can help you accelerate application
>>> >> >>> performance.
>>> >> >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>>> >> >>> most
>>> >> >>> from
>>> >> >>> the latest Intel processors and coprocessors. See abstracts and
>>> >> >>> register >
>>> >> >>>
>>> >> >>>
>>> >> >>>
>>> >> >>> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
>>> >> >>> _______________________________________________
>>> >> >>> Matplotlib-devel mailing list
>>> >> >>> Mat...@li...
>>> >> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Thomas A Caswell
>>> >> >> PhD Candidate University of Chicago
>>> >> >> Nagel and Gardel labs
>>> >> >> tca...@uc...
>>> >> >> jfi.uchicago.edu/~tcaswell
>>> >> >> o: 773.702.7204
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>>> >> >
>>> >> > -- Antonio Alducin --
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>>> >>
>>> >> -- Antonio Alducin --
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Thomas A Caswell
>>> > PhD Candidate University of Chicago
>>> > Nagel and Gardel labs
>>> > tca...@uc...
>>> > jfi.uchicago.edu/~tcaswell
>>> > o: 773.702.7204
>>>
>>>
>>>
>>> --
>>> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>>>
>>> -- Antonio Alducin --
>>
>>
>>
>>
>> --
>> Thomas A Caswell
>> PhD Candidate University of Chicago
>> Nagel and Gardel labs
>> tca...@uc...
>> jfi.uchicago.edu/~tcaswell
>> o: 773.702.7204
>
>
>
> --
> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>
> -- Antonio Alducin --



-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

Re: [matplotlib-devel] Gtk3 app that calls matplotlib

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

Sorry, the replay-all is not my default.

In that case it is easier for me to monkey patch just the mainloop to
invoke Gtk.main everytime.

But again, even if we are talking about interactive (ipython), why is
it unbalanced?
I mean calls Gtk.main vs Gtk.main_quit?

Federico



On Fri, Oct 11, 2013 at 3:28 PM, Thomas A Caswell <tca...@uc...> wrote:
> Please keep all emails in-band
>
> I was commenting that the issue you are having with getting easy-to-use
> pre-built figures in a non-interactive program without dragging pyplot in is
> the same as what I think the root of 2503 is and the re-factor I proposed to
> make your life easier would also help that case (I think).
>
> The gui backends were (as I understand it, someone please correct me if I am
> wrong) built to play nice with ipython to put together a MATLAB-like
> interface.  The fact that you can then embed the gui-framework dependent
> bits of matplotlib in other gui applications is a nice side-effect, but not
> one of the initial design goals.  This is why the `figure_manager` code is
> (too-)tightly coupled to _pylab_helpers.
>
> See the examples at http://matplotlib.org/examples/user_interfaces/  making
> a window with a canvas + tool bar is pretty easy.
>
> A quick and dirty solution might be to just monkey patch the
> figure_manager.destroy function when your app starts up to remove the check
> that shuts down the main loop.
>
> Tom
>
>
> On Fri, Oct 11, 2013 at 1:40 PM, Federico Ariza <ari...@gm...>
> wrote:
>>
>> Sorry I don't get it.
>> Are you suggesting to explain this little predicament in the PR to
>> give another point of view? or
>> You want me to check the PR and try to use the solutions proposed there?
>>
>> Federico
>>
>> On Fri, Oct 11, 2013 at 1:32 PM, Thomas A Caswell <tca...@uc...>
>> wrote:
>> > embedding vs launching is a distinction without a difference, you are
>> > integrating matplotlib with your own gui application.
>> >
>> > That said, it would be nice to re-factor the figure_manager classes so
>> > they
>> > they make no reference to `Gcf` or anything associated with pylab and
>> > could
>> > be easily re-used.
>> >
>> > I think that would also help with the issues in
>> > https://github.com/matplotlib/matplotlib/pull/2503
>> >
>> > Tom
>> >
>> >
>> > On Fri, Oct 11, 2013 at 12:14 PM, Federico Ariza
>> > <ari...@gm...>
>> > wrote:
>> >>
>> >> Again
>> >>
>> >> In the example the plotting is inside the callback (just for
>> >> simplicity), but in reality, the plotting is in another class,
>> >> somewhere else that can be called standalone to produce the plots.
>> >>
>> >> Federico
>> >>
>> >> On Fri, Oct 11, 2013 at 1:12 PM, Federico Ariza
>> >> <ari...@gm...> wrote:
>> >> > I am not embedding, just launching, as the example shows.
>> >> >
>> >> > Federico
>> >> >
>> >> > On Fri, Oct 11, 2013 at 1:11 PM, Thomas A Caswell
>> >> > <tca...@uc...> wrote:
>> >> >> If you are embedding matplotlib, do not import `pyplot`.  `pyplot`
>> >> >> sets
>> >> >> up a
>> >> >> bunch of gui-magic (tm) in the background (as you found in
>> >> >> `figure_manager`).
>> >> >>
>> >> >> Tom
>> >> >>
>> >> >>
>> >> >> On Fri, Oct 11, 2013 at 11:57 AM, Federico Ariza
>> >> >> <ari...@gm...>
>> >> >> wrote:
>> >> >>>
>> >> >>> Hello everybody
>> >> >>>
>> >> >>> Working on one GTK3 app, that calls matplotlib to plot some
>> >> >>> figures, I
>> >> >>> found that closing all the figures from matplotlib kills my app
>> >> >>> also.
>> >> >>> The problem....
>> >> >>>
>> >> >>> Gtk.main() is called only if there is no previous invocation, in my
>> >> >>> case, my Gtk3 app invokes main, so the mainloop won't call it
>> >> >>> again.
>> >> >>>
>> >> >>> #in backend_gtk3.py
>> >> >>> #
>> >> >>> class Show(ShowBase):
>> >> >>>     def mainloop(self):
>> >> >>>         if Gtk.main_level() == 0:
>> >> >>>             Gtk.main()
>> >> >>>
>> >> >>> But in the "destroy" method of the figure manager calls
>> >> >>> Gtk.main_quit
>> >> >>> everytime that there are no more figures
>> >> >>>
>> >> >>> #in backend_gtk3.py inside destroy method of FigureManagerGTK3
>> >> >>> #
>> >> >>> if Gcf.get_num_fig_managers()==0 and \
>> >> >>>                not matplotlib.is_interactive() and \
>> >> >>>                Gtk.main_level() >= 1:
>> >> >>>             Gtk.main_quit()
>> >> >>>
>> >> >>>
>> >> >>> So basically we are not calling Gtk.main but we are Gtk.calling
>> >> >>> main_quit.
>> >> >>> Isn't it more natural to call Gtk.main the same amount of times
>> >> >>> that
>> >> >>> we are going to call Gtk.main_quit?
>> >> >>>
>> >> >>> Adding matplotlib.rcParams['interactive'] = True doesn't help
>> >> >>>
>> >> >>> Here is my little testing code
>> >> >>>
>> >> >>> ##############################
>> >> >>> #file myapp.py
>> >> >>>
>> >> >>> import matplotlib
>> >> >>> matplotlib.rcParams['interactive'] = True
>> >> >>> matplotlib.use('GTK3AGG')
>> >> >>> import matplotlib.pyplot as plt
>> >> >>>
>> >> >>> from gi.repository import Gtk
>> >> >>>
>> >> >>> class MyWindow(Gtk.Window):
>> >> >>>
>> >> >>>     def __init__(self):
>> >> >>>         Gtk.Window.__init__(self, title="Hello World")
>> >> >>>
>> >> >>>         self.button = Gtk.Button(label="Click Here")
>> >> >>>         self.button.connect("clicked", self.on_button_clicked)
>> >> >>>         self.add(self.button)
>> >> >>>
>> >> >>>     def on_button_clicked(self, widget):
>> >> >>>         fig = plt.figure()
>> >> >>>         ax = fig.add_subplot(111)
>> >> >>>         ax.plot([1,2,3])
>> >> >>>         plt.show()
>> >> >>>
>> >> >>> win = MyWindow()
>> >> >>> win.connect("delete-event", Gtk.main_quit)
>> >> >>> win.show_all()
>> >> >>> Gtk.main()
>> >> >>> #########################
>> >> >>>
>> >> >>> I know this is related to interactive mode, but running from
>> >> >>> console
>> >> >>> >>> python myapp.py
>> >> >>> reproduces the problem
>> >> >>>
>> >> >>> Why hasattr(sys, 'ps1') is False? if I am running it from console?
>> >> >>> how
>> >> >>> do I change this?
>> >> >>>
>> >> >>>
>> >> >>> Thanks
>> >> >>> Federico
>> >> >>>
>> >> >>> P.S. Does anybody had the time to check my PR for
>> >> >>> multi-figure-manager?
>> >> >>> https://github.com/matplotlib/matplotlib/pull/2465
>> >> >>>
>> >> >>> --
>> >> >>> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>> >> >>>
>> >> >>> -- Antonio Alducin --
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> ------------------------------------------------------------------------------
>> >> >>> October Webinars: Code for Performance
>> >> >>> Free Intel webinars can help you accelerate application
>> >> >>> performance.
>> >> >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>> >> >>> most
>> >> >>> from
>> >> >>> the latest Intel processors and coprocessors. See abstracts and
>> >> >>> register >
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
>> >> >>> _______________________________________________
>> >> >>> Matplotlib-devel mailing list
>> >> >>> Mat...@li...
>> >> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Thomas A Caswell
>> >> >> PhD Candidate University of Chicago
>> >> >> Nagel and Gardel labs
>> >> >> tca...@uc...
>> >> >> jfi.uchicago.edu/~tcaswell
>> >> >> o: 773.702.7204
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>> >> >
>> >> > -- Antonio Alducin --
>> >>
>> >>
>> >>
>> >> --
>> >> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>> >>
>> >> -- Antonio Alducin --
>> >
>> >
>> >
>> >
>> > --
>> > Thomas A Caswell
>> > PhD Candidate University of Chicago
>> > Nagel and Gardel labs
>> > tca...@uc...
>> > jfi.uchicago.edu/~tcaswell
>> > o: 773.702.7204
>>
>>
>>
>> --
>> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>>
>> -- Antonio Alducin --
>
>
>
>
> --
> Thomas A Caswell
> PhD Candidate University of Chicago
> Nagel and Gardel labs
> tca...@uc...
> jfi.uchicago.edu/~tcaswell
> o: 773.702.7204



-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --