matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] MEP22 review request

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

Federico,

Just to make sure you know that I haven't forgotten about this MEP. In
about a week, I'll be done the animation chapter of my book and will be
moving on to the widgets and tools chapter. Then I'll have the right mental
context to assess and comment on this MEP.

Cheers!
Ben Root

On Thu, Sep 4, 2014 at 5:07 PM, Federico Ariza <ari...@gm...>
wrote:

> Hello everyone.
>
> I had made a couple of small changes to MEP22 and I think it's in good
> shape.
>
> I would really appreciate some feedback. I would really like to finish
> this to pass to MEP23
>
> The working PR is
> https://github.com/matplotlib/matplotlib/pull/2759
>
> Thanks
> Federico
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

[matplotlib-devel] Purpose of doc/conda-recipes ?

[Sandro T. <mo...@de...>]

Hello,
I've noticed in 1.4.0 the presence of doc/conda-recipes dir; from what
I got from the doc it's a build system for Anaconda Continuum systems.

May I ask what is the purpose of this directory? if it's for building,
why is it in the doc subtree?

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

[matplotlib-devel] Ten Simple Rules for Better Figures

[Nicolas P. R. <Nic...@in...>]

Hi all,

I'm very pleased to announce the publication of a paper I've written with Michael Droettboom and Philip E. Bourne.

Ten Simple Rules for Better Figures
Nicolas P. Rougier, Michael Droettboom, Philip E. Bourne
PLOS Computational Biology
URL: http://www.ploscompbiol.org/article/info:doi/10.1371/journal.pcbi.1003833


All the figures have been made using matplotlib and sources are available from:

https://github.com/rougier/ten-rules

We even managed to use the XKCD filter !
Thanks a lot for this great library.



Nicolas

[matplotlib-devel] Compatibility with WX 3.0

[Sandro T. <mo...@de...>]

Hello,
in Debian we are moving to WX 3.0 also from the POV of Python
bindings. I dont see mentioned anywhere the compat/incompat of mpl
with such WX version, can you please shine some light on it.

No pressure but we aim at freezing the current unstable branch on
early November this year :)

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

Re: [matplotlib-devel] MEP26: Artist-level stylesheets

[jamesramm <jam...@gm...>]

It would be great if we can see the code for the style system.

However, for integration into MPL, rather than something which 'sits on top'
of the existing API (I presume you are therefore working with getter/setter
functions), the MEP I'm proposing is also trying to achieve the seperation
of the 'style' of artists from their data/logic. The idea being that it
heads towards a more streamlined and extensible API. 

Some of the techniques you are describing seem to cover some of the ideas
put forth in the MEP, so if you can make the code available, it would be a
great resource. 



--
View this message in context: http://matplotlib.1069221.n5.nabble.com/MEP26-Artist-level-stylesheets-tp43664p43893.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Re: [matplotlib-devel] scribbling tool (eg for labeling markers)

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

Steven

I just had a look at image_inspector.
The `Tools` (in mpl jargon are `widgets`) look great.

Some replicate what we already have but more modern (for me this is
positive improvement).

Regarding the roi_inspector, this is a great fit for MEP22 tools (Almost
done).

My suggestion would be to take a look at `matplotlib.widgets.Widget` and
`matplotlib.widgets.AxesWidget` to see how easy/hard would it be to adapt
or integrate your tools (widgets) there.

Personally I don't like the idea of a separate sibling repo. It makes just
things more confusing.

Federico
 On 4 Sep 2014 23:42, "Thomas Caswell" <tca...@gm...> wrote:

> Steven,
>
> I would love to get to as much of that functionality into mpl proper
> as possible.  Please open an issue / make a MEP for this.
>
> Unfortunately I have not had a chance to take a close look at
> image_inspector yet and I am a tad concerned about the potential for
> re-invented wheels between yours tools and the existing widgets (and
> to be fair, I only have a cursory understanding of those widgets).  I
> agree all the functionality should be in mpl (or as much as we can
> shove down through our gui frame work independent filter), but don't
> want to get pinned down to committing to specific implementation
> details.
>
> Another option might be to put all of these tools in a sibling repo to
> mpl under the mpl organization.
>
> I have cc'd the mpl-dev list.
>
> Tom
>
>
> On Thu, Sep 4, 2014 at 9:28 PM, Steven Silvester
> <ste...@gm...> wrote:
> > Thomas,
> >
> > How about the broader discussion of incorporating the tools in
> > https://github.com/blink1073/image_inspector into mpl (ideally as a
> > replacement or alternative for some of the existing tools)?  If I combine
> > that with paint tool and we get those pushed into mpl proper, then we can
> > just use them as-is for skimage.  Should I open an mpl issue to discuss?
> >
> > - Steve
> >
> > On Thursday, September 4, 2014 4:49:28 PM UTC-5, Thomas Caswell wrote:
> >>
> >> If you are doing this with matplotlib, can you actually push the tools
> >> back upstream?
> >>
> >> Tom (a mpl dev)
> >>
> >> On Thu, Sep 4, 2014 at 5:36 PM, Stéfan van der Walt <ste...@sun.ac.za>
> >> wrote:
> >> > On Thu, Sep 4, 2014 at 10:01 PM, Emmanuelle Gouillart
> >> > <emmanuelle...@nsup.org> wrote:
> >> >> Answering my own question: I had forgotten that the viewer examples
> >> >> include such kind of example, inside watershed_demo.py. Thanks Tony
> >> >> for the example!
> >> >
> >> > I think this is an important enough use-case to make it a utility
> >> > function--feel free to add an issue!
> >> >
> >> > Stéfan
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> > Groups "scikit-image" group.
> >> > To unsubscribe from this group and stop receiving emails from it, send
> >> > an email to scikit-image...@googlegroups.com.
> >> > For more options, visit https://groups.google.com/d/optout.
> >>
> >>
> >>
> >> --
> >> Thomas Caswell
> >> tcas...@gmail.com
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "scikit-image" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to sci...@go....
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Thomas Caswell
> tca...@gm...
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] scribbling tool (eg for labeling markers)

[Thomas C. <tca...@gm...>]

Steven,

I would love to get to as much of that functionality into mpl proper
as possible.  Please open an issue / make a MEP for this.

Unfortunately I have not had a chance to take a close look at
image_inspector yet and I am a tad concerned about the potential for
re-invented wheels between yours tools and the existing widgets (and
to be fair, I only have a cursory understanding of those widgets).  I
agree all the functionality should be in mpl (or as much as we can
shove down through our gui frame work independent filter), but don't
want to get pinned down to committing to specific implementation
details.

Another option might be to put all of these tools in a sibling repo to
mpl under the mpl organization.

I have cc'd the mpl-dev list.

Tom


On Thu, Sep 4, 2014 at 9:28 PM, Steven Silvester
<ste...@gm...> wrote:
> Thomas,
>
> How about the broader discussion of incorporating the tools in
> https://github.com/blink1073/image_inspector into mpl (ideally as a
> replacement or alternative for some of the existing tools)?  If I combine
> that with paint tool and we get those pushed into mpl proper, then we can
> just use them as-is for skimage.  Should I open an mpl issue to discuss?
>
> - Steve
>
> On Thursday, September 4, 2014 4:49:28 PM UTC-5, Thomas Caswell wrote:
>>
>> If you are doing this with matplotlib, can you actually push the tools
>> back upstream?
>>
>> Tom (a mpl dev)
>>
>> On Thu, Sep 4, 2014 at 5:36 PM, Stéfan van der Walt <ste...@sun.ac.za>
>> wrote:
>> > On Thu, Sep 4, 2014 at 10:01 PM, Emmanuelle Gouillart
>> > <emmanuelle...@nsup.org> wrote:
>> >> Answering my own question: I had forgotten that the viewer examples
>> >> include such kind of example, inside watershed_demo.py. Thanks Tony
>> >> for the example!
>> >
>> > I think this is an important enough use-case to make it a utility
>> > function--feel free to add an issue!
>> >
>> > Stéfan
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "scikit-image" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an email to scikit-image...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Thomas Caswell
>> tcas...@gmail.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "scikit-image" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sci...@go....
> For more options, visit https://groups.google.com/d/optout.



-- 
Thomas Caswell
tca...@gm...

[matplotlib-devel] MEP22 review request

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

Hello everyone.

I had made a couple of small changes to MEP22 and I think it's in good
shape.

I would really appreciate some feedback. I would really like to finish this
to pass to MEP23

The working PR is
https://github.com/matplotlib/matplotlib/pull/2759

Thanks
Federico

[matplotlib-devel] blit support in webagg / nbagg backends?

[Eric B. <eri...@gm...>]

I see that supports_blit=False in FigureCanvasWebAggCore. Is there a
technical limitation that prevents this, or is it a matter of someone
finding time to do the implementation? Absence of blit support doesn't seem
to crash code that uses it (in my case, a lasso tool), but I also see no
output to the screen.

Thanks,
Eric

Re: [matplotlib-devel] getting a DOI for v1.4.0

[Nathaniel S. <nj...@po...>]

On Sun, Aug 24, 2014 at 2:42 AM, Thomas Caswell <tca...@gm...> wrote:
> Hey all,
>
> Github has made it possible to get a DOI for a release (
> https://guides.github.com/activities/citable-code/ ).
>
> I am inclined to do this for 1.4.0.  I think doing this is a good
> first step towards being good (leading?) citizens in the reproducible
> science community.

FYI, since I just spent half an hour figuring this out:

To use the Zenodo magic DOI feature you have to:

1) Attach Zenodo to the repository like it says in the tutorial.

2) Create a "release" on github, which is *not* the same as a tag,
even though the github UI claims that they are identical. See all of
these releases that are listed on your github releases page?
    https://github.com/matplotlib/matplotlib/releases
None of them are actually releases in the sense that Zenodo wants.

Here's an example of what it looks like after you've made Zenodo happy:
    https://github.com/pydata/patsy/releases

The trick is to click "draft a new release", and then type in the name
of your existing tag. You can add some release notes if desired, which
will be copied to the archived Zenodo page, which will look like this:
   https://zenodo.org/record/11445
(The text "See release notes: <url>" is what I typed into the Github
release description box.) And then click "Publish release" obviously.
This will convert your existing release tag into an *extra-special*
release tag, which AFAICT works the same as before except that (a) it
gets snazzier graphics in the github UI, and (b) Zenodo will archive
it.

-n

-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

Re: [matplotlib-devel] getting a DOI for v1.4.0

[Thomas C. <tca...@gm...>]

https://zenodo.org/record/11451#.U_z6ckREvfQ

And yes, I will create an issue for updating the citation page.

Tom

On Tue, Aug 26, 2014 at 5:08 PM, Benjamin Root <ben...@ou...> wrote:
> In case you weren't already thinking of this, we might want to update this
> page:
> http://matplotlib.org/citing.html
>
>
> On Tue, Aug 26, 2014 at 5:01 PM, Thomas Caswell <tca...@gm...> wrote:
>>
>> Thanks! This hasn't been done yet because I was confused by zenodo and
>> hadn't taken the tune to sort this out.
>>
>> Tom
>>
>> On Aug 26, 2014 4:54 PM, "Nathaniel Smith" <nj...@po...> wrote:
>>>
>>> On Sun, Aug 24, 2014 at 2:42 AM, Thomas Caswell <tca...@gm...>
>>> wrote:
>>> > Hey all,
>>> >
>>> > Github has made it possible to get a DOI for a release (
>>> > https://guides.github.com/activities/citable-code/ ).
>>> >
>>> > I am inclined to do this for 1.4.0.  I think doing this is a good
>>> > first step towards being good (leading?) citizens in the reproducible
>>> > science community.
>>>
>>> FYI, since I just spent half an hour figuring this out:
>>>
>>> To use the Zenodo magic DOI feature you have to:
>>>
>>> 1) Attach Zenodo to the repository like it says in the tutorial.
>>>
>>> 2) Create a "release" on github, which is *not* the same as a tag,
>>> even though the github UI claims that they are identical. See all of
>>> these releases that are listed on your github releases page?
>>>     https://github.com/matplotlib/matplotlib/releases
>>> None of them are actually releases in the sense that Zenodo wants.
>>>
>>> Here's an example of what it looks like after you've made Zenodo happy:
>>>     https://github.com/pydata/patsy/releases
>>>
>>> The trick is to click "draft a new release", and then type in the name
>>> of your existing tag. You can add some release notes if desired, which
>>> will be copied to the archived Zenodo page, which will look like this:
>>>    https://zenodo.org/record/11445
>>> (The text "See release notes: <url>" is what I typed into the Github
>>> release description box.) And then click "Publish release" obviously.
>>> This will convert your existing release tag into an *extra-special*
>>> release tag, which AFAICT works the same as before except that (a) it
>>> gets snazzier graphics in the github UI, and (b) Zenodo will archive
>>> it.
>>>
>>> -n
>>>
>>> --
>>> Nathaniel J. Smith
>>> Postdoctoral researcher - Informatics - University of Edinburgh
>>> http://vorpus.org
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Slashdot TV.
>> Video for Nerds.  Stuff that matters.
>> http://tv.slashdot.org/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>



-- 
Thomas Caswell
tca...@gm...

Re: [matplotlib-devel] getting a DOI for v1.4.0

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

In case you weren't already thinking of this, we might want to update this
page:
http://matplotlib.org/citing.html


On Tue, Aug 26, 2014 at 5:01 PM, Thomas Caswell <tca...@gm...> wrote:

> Thanks! This hasn't been done yet because I was confused by zenodo and
> hadn't taken the tune to sort this out.
>
> Tom
> On Aug 26, 2014 4:54 PM, "Nathaniel Smith" <nj...@po...> wrote:
>
>>  On Sun, Aug 24, 2014 at 2:42 AM, Thomas Caswell <tca...@gm...>
>> wrote:
>> > Hey all,
>> >
>> > Github has made it possible to get a DOI for a release (
>> > https://guides.github.com/activities/citable-code/ ).
>> >
>> > I am inclined to do this for 1.4.0.  I think doing this is a good
>> > first step towards being good (leading?) citizens in the reproducible
>> > science community.
>>
>> FYI, since I just spent half an hour figuring this out:
>>
>> To use the Zenodo magic DOI feature you have to:
>>
>> 1) Attach Zenodo to the repository like it says in the tutorial.
>>
>> 2) Create a "release" on github, which is *not* the same as a tag,
>> even though the github UI claims that they are identical. See all of
>> these releases that are listed on your github releases page?
>>     https://github.com/matplotlib/matplotlib/releases
>> None of them are actually releases in the sense that Zenodo wants.
>>
>> Here's an example of what it looks like after you've made Zenodo happy:
>>     https://github.com/pydata/patsy/releases
>>
>> The trick is to click "draft a new release", and then type in the name
>> of your existing tag. You can add some release notes if desired, which
>> will be copied to the archived Zenodo page, which will look like this:
>>    https://zenodo.org/record/11445
>> (The text "See release notes: <url>" is what I typed into the Github
>> release description box.) And then click "Publish release" obviously.
>> This will convert your existing release tag into an *extra-special*
>> release tag, which AFAICT works the same as before except that (a) it
>> gets snazzier graphics in the github UI, and (b) Zenodo will archive
>> it.
>>
>> -n
>>
>> --
>> Nathaniel J. Smith
>> Postdoctoral researcher - Informatics - University of Edinburgh
>> http://vorpus.org
>>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Re: [matplotlib-devel] getting a DOI for v1.4.0

[Thomas C. <tca...@gm...>]

Thanks! This hasn't been done yet because I was confused by zenodo and
hadn't taken the tune to sort this out.

Tom
On Aug 26, 2014 4:54 PM, "Nathaniel Smith" <nj...@po...> wrote:

> On Sun, Aug 24, 2014 at 2:42 AM, Thomas Caswell <tca...@gm...>
> wrote:
> > Hey all,
> >
> > Github has made it possible to get a DOI for a release (
> > https://guides.github.com/activities/citable-code/ ).
> >
> > I am inclined to do this for 1.4.0.  I think doing this is a good
> > first step towards being good (leading?) citizens in the reproducible
> > science community.
>
> FYI, since I just spent half an hour figuring this out:
>
> To use the Zenodo magic DOI feature you have to:
>
> 1) Attach Zenodo to the repository like it says in the tutorial.
>
> 2) Create a "release" on github, which is *not* the same as a tag,
> even though the github UI claims that they are identical. See all of
> these releases that are listed on your github releases page?
>     https://github.com/matplotlib/matplotlib/releases
> None of them are actually releases in the sense that Zenodo wants.
>
> Here's an example of what it looks like after you've made Zenodo happy:
>     https://github.com/pydata/patsy/releases
>
> The trick is to click "draft a new release", and then type in the name
> of your existing tag. You can add some release notes if desired, which
> will be copied to the archived Zenodo page, which will look like this:
>    https://zenodo.org/record/11445
> (The text "See release notes: <url>" is what I typed into the Github
> release description box.) And then click "Publish release" obviously.
> This will convert your existing release tag into an *extra-special*
> release tag, which AFAICT works the same as before except that (a) it
> gets snazzier graphics in the github UI, and (b) Zenodo will archive
> it.
>
> -n
>
> --
> Nathaniel J. Smith
> Postdoctoral researcher - Informatics - University of Edinburgh
> http://vorpus.org
>

[matplotlib-devel] getting a DOI for v1.4.0

[Tobias S. <tob...@gm...>]

Hi Thomas!

Can you send out the DOI once you have it?

-Tobias

[matplotlib-devel] matplotlib v1.4.0 released

[Thomas C. <tca...@gm...>]

We are pleased to announce the release of matplotlib 1.4.0!

This release has contributions from ~170 authors
(http://matplotlib.org/users/github_stats.html).

This release contains many bug fixes as will as a number of new
features.  For the full list see
http://matplotlib.org/users/whats_new.html#new-in-matplotlib-1-4.
Some highlights are:

  - style module : experimental package to make managing the style of
matplotlib figures easier
  - nbagg : interactive figures in ipython notebooks backed by the AGG renderer
  - full python 3 support (including cairo backends)
  - Qt5 support (for python 3 only)
  - violin plots and 3D quiver plots (projects done for a course at
University of Toronto, Scarborough)
  - new box plot interface (as bxp)

The release can be installed via pip (but requires local compilation)

Tarballs are available at:
  - http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.4.0/matplotlib-1.4.0.tar.gz
  - https://github.com/matplotlib/matplotlib/archive/v1.4.0.tar.gz
  - https://pypi.python.org/packages/source/m/matplotlib/matplotlib-1.4.0.tar.gz

Windows install binaries and wheels are available (thanks to Christoph
Gohlke) at http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.4.0/
.

Mac OSX wheels are available (thanks to Matthew Brett) from
http://wheels.scikit-image.org .


The Matplotlib Team

Re: [matplotlib-devel] v1.4.0

[Christoph G. <cg...@uc...>]

On 8/25/2014 8:25 PM, Thomas Caswell wrote:
> I have tagged 1.4.0, posted the source tarball to sf, updated pypi,
> updated the docs, and kicked off building the mac wheels.
>
> Holding off on announcing to the rest of the lists until the windows
> binaries get built.
>
> Created a v1.4.0-doc branch on the main repo to put documentation
> updates in.  One of the big issues from 1.3.1 was the incorrect
> documentation for the windows install that was wrong for many months,
> hopefully this will give us a way to deal with future situations
> rapidly.
>
> Tom
>

Hi Tom,

I uploaded the Windows installers, wheels, and compiled help file to SF. 
As usual the release version binaries do not include the tests or sample 
data. Built against numpy versions 1.6.2 (Python <= 3.2), 1.7.2 (Python 
3.3) and 1.8.2 (Python 3.4).

Christoph

[matplotlib-devel] v1.4.0

[Thomas C. <tca...@gm...>]

I have tagged 1.4.0, posted the source tarball to sf, updated pypi,
updated the docs, and kicked off building the mac wheels.

Holding off on announcing to the rest of the lists until the windows
binaries get built.

Created a v1.4.0-doc branch on the main repo to put documentation
updates in.  One of the big issues from 1.3.1 was the incorrect
documentation for the windows install that was wrong for many months,
hopefully this will give us a way to deal with future situations
rapidly.

Tom

-- 
Thomas Caswell
tca...@gm...

Re: [matplotlib-devel] Getting started?

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

I know this is a bit cliche-ish, but documentation is always a great place
to start.

1) Fresh perspective is always valuable. As developers get
"self-indoctrinated", we get used to various gaps in the documentation such
that they become blind spots for us. This is why the sign of a healthy
project is infusion of new blood.

2) In-depth documentation review is a great way to figure out deviations
between code and documentation. When I was developing my "Anatomy of
Matplotlib" tutorial, I came across a number of errors and omissions
because of it.

There are also MEPs that are awaiting further review (I think the toolbar
refactor is getting close to being ready for final acceptance). MEP reviews
by newcomers are great because it helps to make sure that some major new
feature are actually considered as useful by newcomers and also make sense
to them (see "self-indoctrination").

Welcome to the party!
Ben Root



On Sun, Aug 24, 2014 at 3:57 PM, Paul Ganssle <pga...@gm...> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Howdy,
>
>   I've been a matplotlib user for some time, and I've been thinking
> about contributing to the project. I poked around in the github issues
> list, particularly the low-hanging fruit tag
> (https://github.com/matplotlib/matplotlib/labels/low%20hanging%20fruit),
> but nothing immediately struck my fancy, and I don't want to step on
> any toes / reduplicate any significant efforts, so I thought I'd throw
> it out there to the devs - do you guys have anything to point me
> towards that I could get started and at least get into the swing of
> things?
>
>           Thanks,
>                  Paul
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iQIcBAEBAgAGBQJT+kOXAAoJEM1U/OPZZL77bGkP/Rt5MXXvLJlkjgbAtlyHdriO
> F2s3CKG6WLeU9eQJf/RloJWHr21lGW829aaNz+jG//N7f3HJXURhSNJFWF0vlWQJ
> dgsAptVr3v/5Ckhb1AkrmBFqb2uSfw0RXzMgSi+g7P/MicHYpXr2k8JE+BWmeZTq
> iO2cEFl2YWA+To3ZWKaOwdxxuj615ccq3oZyeEpdU1YCO7pPjW7PCy1Jhb2Rw/yD
> V8IyRsm2Tgvr3AZwijPzJnsGPFLxRP8gkvi1M2iW+gvRC+NYA5PsAL++uLgeHNTp
> Y1RCp5R4X6SuLwO0IkNpxM5ffHgPQimjvYN1/AweMG2NiuAROkSOnbhzHCfQWlN5
> /z1TSnU33+anldeK89V1E2Nsp7mecAVbKqUTXS4NSomWn325wFEr+Uc4lSYdEd6n
> t4Ce8MIYx9qSCHE0BrN2RsIT5Q6pMhLC8sf/7s26ZeQELxVUzAxU7WQcAsovtB64
> GwVAdozVpIepPUe+Y+2MHH1JqohsUENDjPUtxbYlBmBgEIoxFqWsTBG5GkFtSnOu
> AqSF4XoAt9IOxXvuIpcy6UADnoJ+qpVb4CY1gTByCONQCDOnE+41BomV4vnVy7jL
> SgkenaCKA2VBwatAda0DlGZDWYdc5hmUiGUFyjTh4Q6LRUIJyuvy7gneadJiAWZw
> fm74noPQwH9RWtu1+QBi
> =ehqZ
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] getting a DOI for v1.4.0

[Yaron de L. <jd...@gm...>]

+1 from me too


On 24 August 2014 20:49, Benjamin Root <ben...@ou...> wrote:

> +1
>
>
> On Sat, Aug 23, 2014 at 9:42 PM, Thomas Caswell <tca...@gm...>
> wrote:
>
>> Hey all,
>>
>> Github has made it possible to get a DOI for a release (
>> https://guides.github.com/activities/citable-code/ ).
>>
>> I am inclined to do this for 1.4.0.  I think doing this is a good
>> first step towards being good (leading?) citizens in the reproducible
>> science community.
>>
>> Any other thoughts?
>>
>> Tom
>>
>> --
>> Thomas Caswell
>> tca...@gm...
>>
>>
>> ------------------------------------------------------------------------------
>> Slashdot TV.
>> Video for Nerds.  Stuff that matters.
>> http://tv.slashdot.org/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

[matplotlib-devel] Getting started?

[Paul G. <pga...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Howdy,

  I've been a matplotlib user for some time, and I've been thinking
about contributing to the project. I poked around in the github issues
list, particularly the low-hanging fruit tag
(https://github.com/matplotlib/matplotlib/labels/low%20hanging%20fruit),
but nothing immediately struck my fancy, and I don't want to step on
any toes / reduplicate any significant efforts, so I thought I'd throw
it out there to the devs - do you guys have anything to point me
towards that I could get started and at least get into the swing of
things?

          Thanks,
                 Paul
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQIcBAEBAgAGBQJT+kOXAAoJEM1U/OPZZL77bGkP/Rt5MXXvLJlkjgbAtlyHdriO
F2s3CKG6WLeU9eQJf/RloJWHr21lGW829aaNz+jG//N7f3HJXURhSNJFWF0vlWQJ
dgsAptVr3v/5Ckhb1AkrmBFqb2uSfw0RXzMgSi+g7P/MicHYpXr2k8JE+BWmeZTq
iO2cEFl2YWA+To3ZWKaOwdxxuj615ccq3oZyeEpdU1YCO7pPjW7PCy1Jhb2Rw/yD
V8IyRsm2Tgvr3AZwijPzJnsGPFLxRP8gkvi1M2iW+gvRC+NYA5PsAL++uLgeHNTp
Y1RCp5R4X6SuLwO0IkNpxM5ffHgPQimjvYN1/AweMG2NiuAROkSOnbhzHCfQWlN5
/z1TSnU33+anldeK89V1E2Nsp7mecAVbKqUTXS4NSomWn325wFEr+Uc4lSYdEd6n
t4Ce8MIYx9qSCHE0BrN2RsIT5Q6pMhLC8sf/7s26ZeQELxVUzAxU7WQcAsovtB64
GwVAdozVpIepPUe+Y+2MHH1JqohsUENDjPUtxbYlBmBgEIoxFqWsTBG5GkFtSnOu
AqSF4XoAt9IOxXvuIpcy6UADnoJ+qpVb4CY1gTByCONQCDOnE+41BomV4vnVy7jL
SgkenaCKA2VBwatAda0DlGZDWYdc5hmUiGUFyjTh4Q6LRUIJyuvy7gneadJiAWZw
fm74noPQwH9RWtu1+QBi
=ehqZ
-----END PGP SIGNATURE-----

Re: [matplotlib-devel] getting a DOI for v1.4.0

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

+1


On Sat, Aug 23, 2014 at 9:42 PM, Thomas Caswell <tca...@gm...> wrote:

> Hey all,
>
> Github has made it possible to get a DOI for a release (
> https://guides.github.com/activities/citable-code/ ).
>
> I am inclined to do this for 1.4.0.  I think doing this is a good
> first step towards being good (leading?) citizens in the reproducible
> science community.
>
> Any other thoughts?
>
> Tom
>
> --
> Thomas Caswell
> tca...@gm...
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

[matplotlib-devel] getting a DOI for v1.4.0

[Thomas C. <tca...@gm...>]

Hey all,

Github has made it possible to get a DOI for a release (
https://guides.github.com/activities/citable-code/ ).

I am inclined to do this for 1.4.0.  I think doing this is a good
first step towards being good (leading?) citizens in the reproducible
science community.

Any other thoughts?

Tom

-- 
Thomas Caswell
tca...@gm...

Re: [matplotlib-devel] mac osx dmg files

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

Hi,

On 8/22/14, Thomas Caswell <tca...@gm...> wrote:
> Are we planning to make and distribute .dmg (damage?!?) files for 1.4?
>  If so who is making them?  If not, we should remove that section form
> `installing_faq.rst`.

I can build them, but they are a bit frightening because they
unconditionally replace any pre-installed versions of the
dependencies.

I seem to remember there were still some people who would like these
though.  Is that right?

Cheers,

Matthew

[matplotlib-devel] mac osx dmg files

[Thomas C. <tca...@gm...>]

Are we planning to make and distribute .dmg (damage?!?) files for 1.4?
 If so who is making them?  If not, we should remove that section form
`installing_faq.rst`.

Tom

-- 
Thomas Caswell
tca...@gm...

Re: [matplotlib-devel] [Anaconda Support] OSX: why not make "python" invoke the framework?

[Chris B. <bea...@ha...>]

There are some idiosyncrasies to Anaconda's pythonw -- for example, the
behavior of "-c":

python -c "print 1+2" -> 3
pythonw -c "print 1+2" -> Nothing
/usr/bin/pythonw -c "print 1+2" -> 3

chris

On Thu, Aug 21, 2014 at 6:59 PM, Chris Barker <chr...@no...> wrote:

> On Thu, Aug 21, 2014 at 3:53 PM, Aaron Meurer <aar...@co...>
> wrote:
>
>> The only potential issue I can think of for making python=pythonw is
>> that pythonw is a shell script:
>>
>
> I agree -- that could create issues (though will mostly work, I suppose)
>
> But somehow the python.org build has managed to make a pythonw that IS a
> proper executable:
>
> ORRW-M-1275474:bin chris.barker$ pwd
> /Library/Frameworks/Python.framework/Versions/2.7/bin
>
> ORRW-M-1275474:bin chris.barker$ ls -l pythonw
> lrwxr-xr-x  1 root  wheel  8 Jul 16  2013 pythonw -> pythonw2
>
> ORRW-M-1275474:bin chris.barker$ ls -l pythonw2
> lrwxr-xr-x  1 root  wheel  10 Jul 16  2013 pythonw2 -> pythonw2.7
>
> ORRW-M-1275474:bin chris.barker$ ls -l pythonw2.7
> -rwxr-xr-x  1 chris.barker  admin  9180 May 13  2013 pythonw2.7
>
> ORRW-M-1275474:bin chris.barker$ file  pythonw2.7
> pythonw2.7: Mach-O executable i386
>
> (yes, ti works for 64 bit too -- this just happens to be what I have)
>
> It would be nice if Anaconda would do it the same way.
>
> -Chris
>
>
>
>
>
>
>
>> #!/bin/bash
>> export PYTHONEXECUTABLE=/Users/aaronmeurer/anaconda/bin/python
>> /Users/aaronmeurer/anaconda/python.app/Contents/MacOS/python $@
>>
>> This is needed because otherwise Python thinks its sys.prefix is
>> ../../ from the executable, i.e.,
>> /Users/aaronmeurer/anaconda/python.app/Contents/MacOS
>>
>> $~/anaconda/python.app/Contents/MacOS/python
>> Python 3.4.1 |Continuum Analytics, Inc.| (default, Aug 11 2014, 14:17:03)
>> [GCC 4.2.1 (Apple Inc. build 5577)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import sys
>> >>> sys.prefix
>> '/Users/aaronmeurer/anaconda/python.app/Contents'
>>
>> I'm not sure what kinds of issues this would cause having python be a
>> shell script rather than a Mach-O 64-bit x86_64 executable (or a
>> symlink to a Mach-O 64-bit x86_64 executable).
>>
>> I suppose you could do this (replace 3.4 with 2.7 if you use Python 2):
>>
>> $mv ~/anaconda/bin/python3.4 ~/anaconda/bin/python3.4-orig
>> $ln -s ~/anaconda/bin/pythonw /Users/aaronmeurer/anaconda/bin/python3.4
>>
>> and see if anything breaks (or if you don't want to risk breaking your
>> main Python install, do it in a separate conda environment).
>>
>> Aaron Meurer
>>
>>
>> On Fri, Aug 15, 2014 at 2:37 PM, Derek Homeier
>> <de...@as...> wrote:
>> > On 14 Aug 2014, at 11:40 pm, Chris Barker <chr...@no...>
>> wrote:
>> >
>> >> On Thu, Aug 14, 2014 at 12:07 PM, Eric Firing <efi...@gm...>
>> wrote:
>> >>  but as far as I can see, on OSX, there is no *advantage* to
>> non-framework python.  Is this correct?
>> >>
>> >> Suggestion for anaconda:
>> >> make bin/python a link to ../python.app/Contents/MacOS/python
>> >>
>> >> NOTE: the python.org python build has been doing this (or something
>> like it) for years and many versions -- I had gotten pretty used to it and
>> was pretty annoyed when I discovered Anaconda keeps anon-framework binary
>> as the default.
>> >>
>> >> It was annoying enough that I had to explicitly call pythonw (or alter
>> the #! line) for my wxPython scripts, but with ipython it's even worse --
>> how would I start up ipython with a framework build?
>> >>
>> >> NOTE: if the Anaconda folks really think there is a real downside to
>> using the framework executable for the default python, maybe the ipython
>> start up script could use pythonw ?
>> >>
>> >> Eric - have you tried recent MPL with the python.org builds to
>> confirm the issue? I'm a bit surprised that it would even semi-work -- when
>> I try wxPython with the regular executable, I get an error message and it
>> wont run at all.
>> >>
>> > Just to make sure I understand - this is about whether the MPL macosx
>> backend would run with non-framework
>> > Python at all? It certainly should not, as _macosx.m has been enforcing
>> an error in this case for some versions.
>> > That put aside, when I disable the error at the end of _macosx.m I
>> found the OSX backend to still work as it used
>> > to under OS X 10.9 with the Fink Python installation (which is not
>> built as a framework, and unfortunately unlikely
>> > to change in foreseeable time). I.e. the only obvious problem is the
>> lack of control by the window manager.
>> > Overall I still find it to perform better than any of the alternative
>> backends. But having switched to PyQT4 as the
>> > default backend due to the above Fink troubles, I did notice some
>> oddities under Mavericks. I have no idea if they
>> > are related to the problems Eric had originally reported, but they are
>> clearly Mavericks-specific:
>> >
>> > When using MPL with ipython --pylab and the Quartz version of PyQT4,
>> the interpreter seems to be slow down
>>
>> > extremely after running for a little while. Weirdly this is not
>> connected to any graphics display and in fact happens
>> > even without any plotting window opened, i.e. the ipython shell just
>> randomly becomes completely unresponsive
>> > and hangs for several seconds on simple tasks like typing or navigating
>> through history. The plotting itself actually
>> > does not appear to perform any worse than it used to under Mountain
>> Lion.
>> > None of this seems to occur with the X11 variant of PyQT4.
>> > When launching ipython without the --pylab flag and loading MPL later
>> (e.g. with 'import matplotlib' in the ipython
>>
>> > profile), none of these stalls or hangups occur, but plots sometimes
>> seem not to refresh properly even with a
>> > plt.draw() and one has to manually resize the plot window to force
>> redrawing of the figure.
>> > This might be primarily a PyQT4 or Ipython issue, but obviously it is
>> somehow connected to the pylab mode of Ipython.
>> >
>> > Cheers,
>> >                                         Derek
>> >
>> > --
>> > Anaconda Community Support Group Brought to you by Continuum Analytics
>> > ---
>> > You received this message because you are subscribed to the Google
>> Groups "Anaconda - Public" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an email to ana...@co....
>> > To post to this group, send email to ana...@co....
>> > Visit this group at
>> http://groups.google.com/a/continuum.io/group/anaconda/.
>>
>
>
>
> --
>
> 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...
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>


-- 
*************************************
Chris Beaumont
Senior Software Engineer
Harvard Center for Astrophysics
60 Garden Street, MS 42
Cambridge, MA 02138
chrisbeaumont.org
*************************************