matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

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

On Oct 24, 2013 8:40 PM, "Chris Barker" <chr...@no...> wrote:
>
> On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom <md...@st...>
wrote:
> > Here are the notes with action items from the meeting:
>
> thanks for posting that. I see:
>
> pylab - should it stay or should it go?
>
> Comment from the peanut gallery:
>
> Go.

I agree, but that leads to another question: go where?

Some of the stuff there is clearly redundant and should be removed entirely.

Others I think are functionality that should be merged into numpy, although
whether they would agree I don't know.

Others are useful but I don't know exactly where they could end up.

I think we need to go through on a case-by-case basis and figure out what
to do with each class and function.

I think it would probably be good to do something similar with cbook.  Both
are dumping grounds for largely unrelated functions. At the very least they
should be organized into modules by their purpose, but I do think some
should be dropped or upstreamed.

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

[Thomas A C. <tca...@uc...>]

There needs to be layers to the interface.  At the bottom there is super
general stuff that will cover (we hope) 100% of use cases.  However, the
cost is a very verbose interface with lots of knobs.  To cope with this
there are higher level function which can deal with 90% of the use cases
and do so by hiding some of the knobs (compare making a 3x3 grid
`subplots(3, 3)` with using  `GridSpec` to figuring out where the axes
edges should go and using `add_subplot([t, l, w, h])` ).  I want to make an
analogy to projecting from a higher dimensional parameter space to a lower
one.

The 'proper' api to use is the simplest one that achieves your goal.  If
you just need a grid of evenly spaced equal size axes use `subplots`, if
you need a grid but with some axes that span columns/rows use `GridSpec`,
if you need 5 axes that partially overlap in the shape of your school logo,
use `add_subplot`.

The point of the high-level APIs is to be easy to use.  If that means
matching the MATLAB api to make it easier for people to switch, then fine.
 I am sympathetic to the notion that the state-machine interface is
confusing (because it maintains hidden state), but it is in fact very
convenient.


On Fri, Oct 25, 2013 at 10:26 AM, Daniele Nicolodi <da...@gr...>wrote:

> On 25/10/2013 15:34, Benjamin Root wrote:
>
> > This has already been done. We have the GridSpec API that everything
> > else maps to, for compatibility. But most people still like
> > add_subplot() and subplots() for some odd reason... I think the primary
> > issue is one of documentation, and we are currently in the process of
> > upgrading that. We always welcome contributions to that effort!
>
> Hello Benjamin,
>
> thanks for your comments.  I'm aware of the solutions you propose, but I
> maintain that the status quo is confusing for new users.
>
> The fact that there are multiple ways of doing the same thing, through
> apparently unrelated interfaces makes the API more difficult to learn
> and less discoverable that it needs to be.  This is probably a
> conseqence of the organic growth of the library with time.
>
> I agree that the primary issue is the documentation, but at the root of
> that I also feel there is the lack of well established best practices
> for the use of Matplotlib. For example you write that people still like
> add_subplot() and subplots() for odd reasons, which are the methods
> others in the lists pointed to. What would be the proper API to use in
> your opinion?  I believe convergence on best practices is paramount to
> the update of the documentation.
>
> I also don't really buy the argument that it is desirable to keep and
> promote APIs that try to emulate the Matlab interface.  Matplotlib is
> different enough to make a 1:1 translation difficult and the Matlab
> design is anyhow broken, IMHO.
>
> Best,
> Daniele
>
> PS: with a new job also came the possibility to finally drop Matlab and
> embrace Python as the main data analysis tool. This means that I can
> dedicate some (at the moment very few) spare cycles to contribute to
> Matplotlib. I would be happy to do so!
>
>
>
> ------------------------------------------------------------------------------
> 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=60135991&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

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

[Daniele N. <da...@gr...>]

On 25/10/2013 15:34, Benjamin Root wrote:

> This has already been done. We have the GridSpec API that everything
> else maps to, for compatibility. But most people still like
> add_subplot() and subplots() for some odd reason... I think the primary
> issue is one of documentation, and we are currently in the process of
> upgrading that. We always welcome contributions to that effort!

Hello Benjamin,

thanks for your comments.  I'm aware of the solutions you propose, but I
maintain that the status quo is confusing for new users.

The fact that there are multiple ways of doing the same thing, through
apparently unrelated interfaces makes the API more difficult to learn
and less discoverable that it needs to be.  This is probably a
conseqence of the organic growth of the library with time.

I agree that the primary issue is the documentation, but at the root of
that I also feel there is the lack of well established best practices
for the use of Matplotlib. For example you write that people still like
add_subplot() and subplots() for odd reasons, which are the methods
others in the lists pointed to. What would be the proper API to use in
your opinion?  I believe convergence on best practices is paramount to
the update of the documentation.

I also don't really buy the argument that it is desirable to keep and
promote APIs that try to emulate the Matlab interface.  Matplotlib is
different enough to make a 1:1 translation difficult and the Matlab
design is anyhow broken, IMHO.

Best,
Daniele

PS: with a new job also came the possibility to finally drop Matlab and
embrace Python as the main data analysis tool. This means that I can
dedicate some (at the moment very few) spare cycles to contribute to
Matplotlib. I would be happy to do so!

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

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

Daniele,

On Fri, Oct 25, 2013 at 8:45 AM, Daniele Nicolodi <da...@gr...>wrote:

> On 24/10/2013 21:26, Paul Ivanov wrote:
> > One quick reply:
> >
> > Daniele Nicolodi, on 2013-10-24 21:03,  wrote:
> >> One thing I dislike is, for example, the add_subplot() method:
> >>
> >> f = plt.figure()
> >> a = f.add_subplot(111)
> >> a.plot(x, y)
> >>
> >> it feels completely out of place (why I need to add a subplot if the
> >> only thing I want to do is to create a figure with a single plot in it?)
> >> and kind of magic (what is the number 111?).
> >
> >   f, a = plt.subplots()
> >   a.plot(x, y)
>
> That's better, however to create _sub_ plots to have a single plot into
> a figure still feels weird,


It doesn't feel weird. It feels generalized. It is the same way to add any
number of plots, regardless if it is just one, or twenty. If you don't want
to do it that way, you can just simply do:

fig = plt.figure()
ax = fig.gca()  # "get current axes" automatically creates an axes if one
doesn't exist already

You also have
http://matplotlib.org/api/figure_api.html#matplotlib.figure.Figure.add_axes


> also I would expect it to be a method of the
> Figure class and not a top level function.


It does:
http://matplotlib.org/api/figure_api.html#matplotlib.figure.Figure.add_subplot
This is *the* function that does axes creation for a figure, whether it is
one, or many.



>  Furthermore, most
> documentation refers to add_subplot() and not subplots() which has a
> more understandable function signature.
>
>
subplots() is a recent addition. We are in the process of updating our
documentation. But add_subplot() is not going away because it works just
fine, and it is very familiar to users of Matlab and Octave.



> In principle I think the current API violates the "There should be one--
> and preferably only one --obvious way to do it" rule here, and elsewhere
> :-)
>
>
I feel the way forward should be to create a cleaner API and map the
> current one through a compatibility layer to that.
>
>
This has already been done. We have the GridSpec API that everything else
maps to, for compatibility. But most people still like add_subplot() and
subplots() for some odd reason... I think the primary issue is one of
documentation, and we are currently in the process of upgrading that. We
always welcome contributions to that effort!

Cheers!
Ben Root

Re: [matplotlib-devel] Pull request

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

Le 25/10/2013 14:57, Pierre Haessig a écrit :
> 2) default NFFT value being hidden from views
>
> used to be def specgram(x, NFFT=256,  Fs=2, ...
> now is     def specgram(x, NFFT=None, Fs=None
>
> I think that NFFT is an important parameter of the spectrum
> computation. It should not be /hidden from the immediate view of the
> user/. The fact it is set to 256 is an arbitrary choice and I think it
> even teaches something to the user (if he doesn't know what it is).
> Such a fixed value is an "invitation to change it". Now with
> NFFT=None, it is more likely to imply "a good choice was made for
> you", which is not true (because there is no such good choice for all
> datasets).
My, mistake, this 2nd point is pointless!

I got confused because I'm not familiar with the docstring convention
which make signatures are hard-written in the docstring. Thanks Todd for
pointing me this.

best,
Pierre

Re: [matplotlib-devel] Pull request

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

Hi,

Le 21/10/2013 15:58, Todd a écrit :
>
>     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.

You've convinced me. I didn't have the big picture of your PR when
writing my previous messages. I like the approach you took for specgram,
which put "magnitude", "phase", "angle" on the same level. This indeed
reduce the number of keywords.

Coming back to the readability, what do you think of replacing "phase",
"angle" by "unwrapped phase", "phase". Beyond readability, it also
emphasizes for the reader the idea of "postprocessing" to get the
unwrapped phase, i.e. a something that can have it's issue.

best,
Pierre

Re: [matplotlib-devel] Pull request

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

Hello,


Now that that PR #2522 is merged, I don't know how much futher
commenting is useful, but I think there are two API details that I feel
could be better :

1) API dissymetry

The new pyplot/axes API is now:

 * 1 function *spectgram* now uses a mode argument to tune this behavior :

*mode*: [ 'default' | 'psd' | 'magnitude' | 'angle' | 'phase' ]
             What sort of spectrum to use.  Default is 'psd'. which takes
             the power spectral density.  'complex' returns the
complex-valued
             frequency spectrum.  'magnitude' returns the magnitude
spectrum.
            'angle' returns the phase spectrum without unwrapping.  'phase'
             returns the phase spectrum with unwrapping.

* 3 new functions *phase_spectrum, angle_spectrum, magnitude_spectrum*
which complement the exising psd/csd

-> I think this contributes to overcrowding axes/pyplot API. I like much
better what is done with specgram so I would propose to add just one new
function, for example *spectrum*(...mode='magnitude/angle/phase'). Using
the same /mode /keyword as for specgram would increase the coherence of
the API.



2) default NFFT value being hidden from views

used to be def specgram(x, NFFT=256,  Fs=2, ...
now is     def specgram(x, NFFT=None, Fs=None

I think that NFFT is an important parameter of the spectrum computation.
It should not be /hidden from the immediate view of the user/. The fact
it is set to 256 is an arbitrary choice and I think it even teaches
something to the user (if he doesn't know what it is). Such a fixed
value is an "invitation to change it". Now with NFFT=None, it is more
likely to imply "a good choice was made for you", which is not true
(because there is no such good choice for all datasets).



best,
Pierre

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

[Daniele N. <da...@gr...>]

On 24/10/2013 21:26, Paul Ivanov wrote:
> One quick reply:
> 
> Daniele Nicolodi, on 2013-10-24 21:03,  wrote:
>> One thing I dislike is, for example, the add_subplot() method:
>>
>> f = plt.figure()
>> a = f.add_subplot(111)
>> a.plot(x, y)
>>
>> it feels completely out of place (why I need to add a subplot if the
>> only thing I want to do is to create a figure with a single plot in it?)
>> and kind of magic (what is the number 111?).
>  
>   f, a = plt.subplots()
>   a.plot(x, y)

That's better, however to create _sub_ plots to have a single plot into
a figure still feels weird, also I would expect it to be a method of the
Figure class and not a top level function.  Furthermore, most
documentation refers to add_subplot() and not subplots() which has a
more understandable function signature.

In principle I think the current API violates the "There should be one--
and preferably only one --obvious way to do it" rule here, and elsewhere :-)

I feel the way forward should be to create a cleaner API and map the
current one through a compatibility layer to that.

Cheers,
Daniele

Re: [matplotlib-devel] Pull request

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

Hi,

Le 22/10/2013 19:14, Todd a écrit :
>
>     Thanks for the feedback. I agree that your documentation does make
>     clear the distinction between "phase" and "angle" and that it has
>     a consistency. I just feel that this distinction does not exist
>     "outside" ...
>
>     But beyond this question of phase vs. angle, I must say I don't
>     see that big a use case for phase/angle spectrums[*] (as opposed
>     to magnitude which are much used). 
>
>
> I personally use phase and angle spectrums a huge amount.  In signal
> processing it is extremely important.  It is a critical component in
> acoustics.  It is also used a lot to separate out signals that have
> been mixed together.  Knowing the phases of signals can also be very
> important in certain optics applications and for radio signals and
> RADAR.  Changes in the phase spectrum over time (like you would get
> from a phase spectrogram) is important for doppler analysis both with
> optical and acoustic signals.
>
> Also, from an educational perspective, anyone taking a digital signal
> processing course will need to produce magnitude/phase plots, probably
> both with and without wrapping (since any decent digital signal
> processing course will teach you about the pitfalls that occur due to
> phase wrapping).  So this will make matplotlib much more useful for
> such courses.
>  
>
>     Also, in many cases, "spectrum" is synonymous with spectral
>     density, which implies "magnitude". In the end I wonder whether
>     the notion of phase even makes sense for a spectrogram ?
>
>
> Yes, particularly electrical engineering.  But there are many other
> fields where spectral density is rarely used, and where more
> "ordinary" magnitude and phase plots are the norm, as I explained in
> the previous paragraphs.
Thanks for dealing with my ignorance. It's true that I have a biased
view on these frequency functions, because I mostly deal with random
signals these days.

In fact I'd like to understand a bit more how phase spectorgram works.
Since the signal must be cut into chunks to make the plot along time,
how is the phase computations "synchronised", that is, how does it use a
common time reference. (because I would imagine that otherwise the phase
would make "jumps" between each window frame). Do you have a pointer for
how this is solved ? (or is this problem just non-existing?).

best,
Pierre

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

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

On Thu, Oct 24, 2013 at 12:03 PM, Daniele Nicolodi <da...@gr...> wrote:

> PS: Chris, would you mind sharing the material you put together and
> links to material from which you stole from? Thanks!

I honestly don't think my stuff is any better than the originals: I like these:

Ben Root's Scipy Tutorial -- really nice, Ben!
  https://github.com/WeatherGod/AnatomyOfMatplotlib

>From the software carpentry site:
  https://github.com/swcarpentry/bc/tree/gh-pages/lessons/thw-matplotlib
(apparently originally from Katy and Antony)

-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 Hangout today at 14:00 UTC (10:00am ET)

[Paul I. <pi...@be...>]

Michael Droettboom, on 2013-10-24 09:41,  wrote:
> I'll post a public URL to watch along once it begins as well.

Here's the youtube video link (which I got from Mike's G+):
https://www.youtube.com/watch?feature=player_embedded&v=hWA6dMiSUiU

best,
-- 
                   _
                  / \
                A*   \^   -
             ,./   _.`\\ / \
            / ,--.S    \/   \
           /  `"~,_     \    \
     __o           ?
   _ \<,_         /:\
--(_)/-(_)----.../ | \
--------------.......J
Paul Ivanov
http://pirsquared.org

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

[Paul I. <pi...@be...>]

One quick reply:

Daniele Nicolodi, on 2013-10-24 21:03,  wrote:
> One thing I dislike is, for example, the add_subplot() method:
> 
> f = plt.figure()
> a = f.add_subplot(111)
> a.plot(x, y)
>
> it feels completely out of place (why I need to add a subplot if the
> only thing I want to do is to create a figure with a single plot in it?)
> and kind of magic (what is the number 111?).
 
  f, a = plt.subplots()
  a.plot(x, y)

that's the way to go there. And if you need to make a regular
grid of subplots, you can pass it the number of rows and number
of columns, and get a 2D array of subplots out for the second
argument.

  f, axes = plt.subplots(2,3)
  axes[0,2].plot(range(10))
  axes[1,1].plot(-np.arange(10))
  f.canvas.draw()

best,
-- 
                   _
                  / \
                A*   \^   -
             ,./   _.`\\ / \
            / ,--.S    \/   \
           /  `"~,_     \    \
     __o           ?
   _ \<,_         /:\
--(_)/-(_)----.../ | \
--------------.......J
Paul Ivanov
http://pirsquared.org

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

[Daniele N. <da...@gr...>]

On 24/10/2013 20:39, Chris Barker wrote:
> On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom <md...@st...> wrote:
>> Here are the notes with action items from the meeting:
> 
> thanks for posting that. I see:
> 
> pylab - should it stay or should it go?
> 
> Comment from the peanut gallery:
> 
> Go.
> 
> But beyond that, matplotlib.pyplot is a big mess of both the
> matlab-style state-machine current figure, current axis stuff, and
> what you need to do (at least reasonably on the command line) OO
> interface.
> 
> This makes it really hard to teach to newbies -- I just did this last
> night, and made a point to use tutorials that emphasize the OO
> interface (Thanks Ben Root, Katy Huff, and Antony Scopatz, and I'm
> sure others that helped put the materials together that I stole
> from...). However, there were still a number of examples in there that
> just called "plot()" or whatever, and even if there were not, the
> namespace is really cluttered with stuff!
> 
> Anyone like the idea of an matplotlib.ooplot namespace that would have
> just what you need to use the oo style?

Hello,

I agree that the matlab like API should be at least discouraged, however
I think there are some shortcomings both in the documentation and
examples and in the object oriented API and functions exposed through
the pyplot namespace that make switching more cumbersome that it has to bee.

One thing I dislike is, for example, the add_subplot() method:

f = plt.figure()
a = f.add_subplot(111)
a.plot(x, y)

it feels completely out of place (why I need to add a subplot if the
only thing I want to do is to create a figure with a single plot in it?)
and kind of magic (what is the number 111?).

The API is also very old fashion python (getter and setter methods for
example) and many methods try to emulate too much of the bad API design
of matlab (doing completely different things depending on the kind and
number of parameters).

I believe it would be possible to come up with a more modern and lean
API that would be easier and nicer to use.  If we have to deprecate the
matlab style API, maybe it would be worth to replace it with something
substantially better.

PS: Chris, would you mind sharing the material you put together and
links to material from which you stole from? Thanks!


Cheers,
Daniele

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

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

On Thu, Oct 24, 2013 at 8:29 AM, Michael Droettboom <md...@st...> wrote:
> Here are the notes with action items from the meeting:

thanks for posting that. I see:

pylab - should it stay or should it go?

Comment from the peanut gallery:

Go.

But beyond that, matplotlib.pyplot is a big mess of both the
matlab-style state-machine current figure, current axis stuff, and
what you need to do (at least reasonably on the command line) OO
interface.

This makes it really hard to teach to newbies -- I just did this last
night, and made a point to use tutorials that emphasize the OO
interface (Thanks Ben Root, Katy Huff, and Antony Scopatz, and I'm
sure others that helped put the materials together that I stole
from...). However, there were still a number of examples in there that
just called "plot()" or whatever, and even if there were not, the
namespace is really cluttered with stuff!

Anyone like the idea of an matplotlib.ooplot namespace that would have
just what you need to use the oo style?

-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...

[matplotlib-devel] Next Google Hangout: 2013-11-14

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

Three weeks time... see you all there!

(I've also added it to the matplotlib Google Calendar here: 
https://www.google.com/calendar/feeds/79hk8jhvlks8jn8ds4ri1e6q4g%40group.calendar.google.com/public/basic)

Mike

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

http://www.droettboom.com

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

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

Here are the questions I asked during the hangouts session (paraphrased):

-------------------------------------------------------------
Regarding continuous integration:

Has looked into OBS? (open build server, https://build.opensuse.org/)  It
can be installed on a local machine or server, supports automatically
creating and deleting fresh images with each build, and supposedly works
with osX as well as Linux although I haven't tested it (it does need a Mac
OsX VM).


-------------------------------------------------------------
Regarding bug handling:

It might be possible to do something with this with Google Code-in (
https://developers.google.com/open-source/gci/), although I am not 100%
sure this would be acceptable there.

Another possibility would be to allow volunteer triagers who may not be
developers but can at least handle basic stuff like finding duplicates and
following up with the reporters of old bugs.



-------------------------------------------------------------
Regarding embedding:

Perhaps there could be a generic "figure" widget for each backend.  The
widget would automatically handle all the backend-specific stuff necessary
to create a figure object and display it in the widget (including resizing
and such).  It would provide access to the low-level backend-specific parts
to make it possible to subclass it or change the details of how it works.
The figure windows would have this widget as their central widget, and
would probably access it using these low-level components.

However, for basic usage each widget would also have a "figure" attribute,
which would contain a single generic figure object.  Basic users who just
want to embed a regular plot could access that figure object and use it in
the normal way.

These could probably all be accessed from a single module, although they
probably would all live in their own backend-specific modules.

It wouldn't allow people to use pyplot, but if this was the documented way
to do embedding and the documentation made it clear you needed to use the
OO interface when embedding I think it would greatly reduce the amount of
trouble people have.

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

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

Hi,
For the CI stuff, I think it would be worth discussing this with the
Enthought guys, specifically Didrik Pinte and David Cournapeau.
>From what I understood, they are developping some stuff to
automatically build canopy from projects hosted on github. Hence, they
have to run all the tests, on different plateforms, and they are OK
with chatting with some of us.
Cheers,
N

On 24 October 2013 17:29, Michael Droettboom <md...@st...> wrote:
> Here are the notes with action items from the meeting:
>
> https://docs.google.com/document/d/1nVM9qDooU5nX6WSKWPTYd2kN6wBxqOWZZTNOM1k0FdA/edit?usp=sharing
>
> Sorry about not seeing questions posted from non-participants. I'll try
> to work out that kink for next time.
>
> Mike
>
> On 10/24/2013 09:41 AM, Michael Droettboom wrote:
>> Just a reminder, we are having a general matplotlib development hangout
>> today.  Everyone that responded to the Doodle poll from a few weeks ago
>> will get an invite, along with Matthew Terry and Matthew Brett if they
>> can make it to discuss their work with testing and builds.
>>
>> We have a few extra spots, so let me know if you'd like an invite (first
>> come, first served).
>>
>> I'll post a public URL to watch along once it begins as well.
>>
>> Mike
>>
>
>
> --
>                     _
> |\/|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=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

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

Here are the notes with action items from the meeting:

https://docs.google.com/document/d/1nVM9qDooU5nX6WSKWPTYd2kN6wBxqOWZZTNOM1k0FdA/edit?usp=sharing

Sorry about not seeing questions posted from non-participants. I'll try 
to work out that kink for next time.

Mike

On 10/24/2013 09:41 AM, Michael Droettboom wrote:
> Just a reminder, we are having a general matplotlib development hangout
> today.  Everyone that responded to the Doodle poll from a few weeks ago
> will get an invite, along with Matthew Terry and Matthew Brett if they
> can make it to discuss their work with testing and builds.
>
> We have a few extra spots, so let me know if you'd like an invite (first
> come, first served).
>
> I'll post a public URL to watch along once it begins as well.
>
> Mike
>


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

http://www.droettboom.com

Re: [matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

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

Was anyone looking at the questions?  I posted a bunch of questions but
nobody seemed to notice them.


On Thu, Oct 24, 2013 at 3:41 PM, Michael Droettboom <md...@st...> wrote:

> Just a reminder, we are having a general matplotlib development hangout
> today.  Everyone that responded to the Doodle poll from a few weeks ago
> will get an invite, along with Matthew Terry and Matthew Brett if they
> can make it to discuss their work with testing and builds.
>
> We have a few extra spots, so let me know if you'd like an invite (first
> come, first served).
>
> I'll post a public URL to watch along once it begins as well.
>
> Mike
>
> --
>                     _
> |\/|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=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

[matplotlib-devel] matplotlib Hangout today at 14:00 UTC (10:00am ET)

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

Just a reminder, we are having a general matplotlib development hangout 
today.  Everyone that responded to the Doodle poll from a few weeks ago 
will get an invite, along with Matthew Terry and Matthew Brett if they 
can make it to discuss their work with testing and builds.

We have a few extra spots, so let me know if you'd like an invite (first 
come, first served).

I'll post a public URL to watch along once it begins as well.

Mike

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

http://www.droettboom.com

Re: [matplotlib-devel] OS-X binaries?

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

Hi,

On Wed, Oct 23, 2013 at 12:37 PM, Chris Barker <chr...@no...> wrote:
> On Wed, Oct 23, 2013 at 11:30 AM, Russell E. Owen <ro...@uw...> wrote:
>> The last ones I got from you worked very well: just a few test failures
>> and the current one seems to be doing about the same.
>
> worked well for me too (something odd with wx back end re-rendering,
> but I doubt that's a Mac build issue...)
>
> I tok a quick look at your waf scripts and I couldn't tell how you are
> handling the external compiled dependencies (png, zlib, freetype) --
> are these statically linked in?

Yup:

https://github.com/matthew-brett/mpl-osx-binaries/blob/master/wscript#L20

through line 44 define the build rules for the libraries.

I then (this came from John H's make script I think) delete any shared
libraries:

https://github.com/matthew-brett/mpl-osx-binaries/blob/master/wscript#L183

and force mpl to link against these libraries first by setting
'basedir' in 'setup.cfg':

https://github.com/matthew-brett/mpl-osx-binaries/blob/master/wscript#L183

I should probably disable building the shared libraries as Matt T does
in his builds.

Cheers,

Matthew

Re: [matplotlib-devel] OS-X binaries?

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

On Wed, Oct 23, 2013 at 11:30 AM, Russell E. Owen <ro...@uw...> wrote:
> The last ones I got from you worked very well: just a few test failures
> and the current one seems to be doing about the same.

worked well for me too (something odd with wx back end re-rendering,
but I doubt that's a Mac build issue...)

I tok a quick look at your waf scripts and I couldn't tell how you are
handling the external compiled dependencies (png, zlib, freetype) --
are these statically linked in?

It'll be good to see these posted on the MPL download site.

-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] OS-X binaries?

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

On 10/23/2013 02:41 PM, Matthew Brett wrote:
> Hi,
>
> On Wed, Oct 23, 2013 at 11:30 AM, Russell E. Owen <ro...@uw...> wrote:
>> In article
>> <CAH...@ma...>,
>>   Matthew Brett <mat...@gm...>
>>   wrote:
>>
>>> Hi Chris,
>>>
>>> On Tue, Oct 22, 2013 at 9:03 AM, Chris Barker - NOAA Federal
>>> <chr...@no...> wrote:
>>>> Are there recent binaries for OS-X anywhere? There don't seem to be
>>>> any for recent releases on the MPL download page.
>>>>
>>>> I know we had a discussion about this a whole back, but don't remember
>>>> the outcome. But I hope we'll continue to put them up-- macports and
>>>> friends really aren't the best solutions for everyone.
>>> I hope I have this cracked now, at least in principle.
>>>
>>> The latest versions are here:
>>>
>>> http://nipy.bic.berkeley.edu/scipy_installers/
>>>
>>> Following Matt Terry's example, I'm testing the builds and then the
>>> installers here:
>>>
>>> https://travis-ci.org/matthew-brett/mpl-osx-binaries
>> The last ones I got from you worked very well: just a few test failures
>> and the current one seems to be doing about the same.
>>
>> Thank you very much for providing these! I hope you will post them to
>> the matplotlib official site.
> I'd be happy to - I think I'm waiting for some agreement that that is
> OK.  I suppose I don't have permission to do that at the moment.

Let's talk about this at tomorrow's meeting -- or offline if you can't 
make the meeting.  Ideally, yes, these should be posted with the other 
files.  We can sort out the required permissions etc. offlist.

>
>> One odd failure (in both of them) that I don't remember seeing before:
>> /2.7/lib/python2.7/site-packages/matplotlib/projections/geo.py:485:
>> RuntimeWarning: invalid value encountered in arcsin
>>    theta = np.arcsin(y / np.sqrt(2))
>>
>> There's a complaint about an invalid font name, but I've seen that for
>> quite some time:
>> Ekpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '
>>
>> FAILED (KNOWNFAIL=2, SKIP=1, errors=2)
>>
>> One small suggestion: if it's not too much trouble, might you make them
>> .dmgs? It's a bit more convenient then having to unzip them to use them.
>> But if it's too much work don't bother; zipped mpkg are fine and it's
>> wonderful to have complete binary installers.
> Yes - sure - I'll build the DMGs - was just trying to save myself some
> effort while waiting for feedback - and - thanks for the feedback ...


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

http://www.droettboom.com

Re: [matplotlib-devel] OS-X binaries?

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

Hi,

On Wed, Oct 23, 2013 at 11:30 AM, Russell E. Owen <ro...@uw...> wrote:
> In article
> <CAH...@ma...>,
>  Matthew Brett <mat...@gm...>
>  wrote:
>
>> Hi Chris,
>>
>> On Tue, Oct 22, 2013 at 9:03 AM, Chris Barker - NOAA Federal
>> <chr...@no...> wrote:
>> > Are there recent binaries for OS-X anywhere? There don't seem to be
>> > any for recent releases on the MPL download page.
>> >
>> > I know we had a discussion about this a whole back, but don't remember
>> > the outcome. But I hope we'll continue to put them up-- macports and
>> > friends really aren't the best solutions for everyone.
>>
>> I hope I have this cracked now, at least in principle.
>>
>> The latest versions are here:
>>
>> http://nipy.bic.berkeley.edu/scipy_installers/
>>
>> Following Matt Terry's example, I'm testing the builds and then the
>> installers here:
>>
>> https://travis-ci.org/matthew-brett/mpl-osx-binaries
>
> The last ones I got from you worked very well: just a few test failures
> and the current one seems to be doing about the same.
>
> Thank you very much for providing these! I hope you will post them to
> the matplotlib official site.

I'd be happy to - I think I'm waiting for some agreement that that is
OK.  I suppose I don't have permission to do that at the moment.

> One odd failure (in both of them) that I don't remember seeing before:
> /2.7/lib/python2.7/site-packages/matplotlib/projections/geo.py:485:
> RuntimeWarning: invalid value encountered in arcsin
>   theta = np.arcsin(y / np.sqrt(2))
>
> There's a complaint about an invalid font name, but I've seen that for
> quite some time:
> Ekpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '
>
> FAILED (KNOWNFAIL=2, SKIP=1, errors=2)
>
> One small suggestion: if it's not too much trouble, might you make them
> .dmgs? It's a bit more convenient then having to unzip them to use them.
> But if it's too much work don't bother; zipped mpkg are fine and it's
> wonderful to have complete binary installers.

Yes - sure - I'll build the DMGs - was just trying to save myself some
effort while waiting for feedback - and - thanks for the feedback ...

Cheers,

Matthew

Re: [matplotlib-devel] OS-X binaries?

[Russell E. O. <ro...@uw...>]

In article 
<CAH...@ma...>,
 Matthew Brett <mat...@gm...> 
 wrote:

> Hi Chris,
> 
> On Tue, Oct 22, 2013 at 9:03 AM, Chris Barker - NOAA Federal
> <chr...@no...> wrote:
> > Are there recent binaries for OS-X anywhere? There don't seem to be
> > any for recent releases on the MPL download page.
> >
> > I know we had a discussion about this a whole back, but don't remember
> > the outcome. But I hope we'll continue to put them up-- macports and
> > friends really aren't the best solutions for everyone.
> 
> I hope I have this cracked now, at least in principle.
> 
> The latest versions are here:
> 
> http://nipy.bic.berkeley.edu/scipy_installers/
> 
> Following Matt Terry's example, I'm testing the builds and then the
> installers here:
> 
> https://travis-ci.org/matthew-brett/mpl-osx-binaries

The last ones I got from you worked very well: just a few test failures 
and the current one seems to be doing about the same.

Thank you very much for providing these! I hope you will post them to 
the matplotlib official site.

One odd failure (in both of them) that I don't remember seeing before:
/2.7/lib/python2.7/site-packages/matplotlib/projections/geo.py:485: 
RuntimeWarning: invalid value encountered in arcsin
  theta = np.arcsin(y / np.sqrt(2))

There's a complaint about an invalid font name, but I've seen that for 
quite some time:
Ekpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '

FAILED (KNOWNFAIL=2, SKIP=1, errors=2)

One small suggestion: if it's not too much trouble, might you make them 
.dmgs? It's a bit more convenient then having to unzip them to use them. 
But if it's too much work don't bother; zipped mpkg are fine and it's 
wonderful to have complete binary installers.

-- Russell