matplotlib-devel Mailing List for matplotlib

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

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

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

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

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
>

Hi Thomas!
Can you send out the DOI once you have it?
-Tobias

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

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

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

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
>

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

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

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

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

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

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

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

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

I have gone through and assigned a milestone to every open issue and PR.
The rough filter I used was 1.4.x if it was a bug I thought could be
fixed in a back-compatible way and to 1.5.x if it was a new feature or
something that I thought would require a good deal of work to fix. I
tagged the 'change the default colors' an 2.0 so it was someplace.
I suspect that we have more feature requests than we can get done in
the near future, particularly if the plan for 1.5 is going to stay
working on the semantic/high level plotting objects. I suspect that
we should make a 1.x to for feature requests that we do not want to
commit to getting done.
Please re-milestone anything you think I got wrong and apply
milestones to new issues/PRs as they come in.
Tom
-- 
Thomas Caswell
tca...@gm...

Release candidate 4 has been tagged.
To sound like a broken record, I hope this is the last one.
Tom
-- 
Thomas Caswell
tca...@gm...

On 2014年08月15日, 10:53 AM, Derek Homeier wrote:
> On 15 Aug 2014, at 10:39 pm, Eric Firing <efi...@gm...>
> wrote:
>
>> On 2014年08月15日, 9:37 AM, Derek Homeier wrote:
>>
>>> 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).
>>
>> It sounds like whatever mechanism _macosx.m has been using to
>> determine whether it is running inside a Python Quartz app, does
>> not work in all cases--I gather it works with Fink, but it
>> certainly does not with Anaconda. Any idea why, and how this might
>> be fixed? Wx does detect this correctly, and refuses to run if in
>> a script invoked with Anaconda's python rather than pythonw, for
>> example. (As an aside, wx is not available yet for python 3 except
>> in phoenix development daily builds, so my comment above is based
>> on a test some time ago with python 2.7)
>
> I don’t know much about Anaconda, but since this is hardcoded in
> macros, the only way I see this failing is if they somehow
> incorrectly define WITH_NEXT_FRAMEWORK in pyconfig.h without actually
> building the framework. Though, if I understand correctly, Anaconda
> provides a framework version of the interpreter pythonw and a
> non-frameworked python? But matplotlib is probably only built against
> one of them, thus not getting the correct header version...
Not exactly. Anaconda builds python without the --enable-framework 
option, and then somehow makes their own python.app directory and 
binary. Their bin/python has no connection to framework things; their 
bin/pythonw and bin/python.app point to an executable inside their 
framework directory, which is also named python.app, but is of course in 
a different location. No clue as to why they do it this way; they might 
have had a good reason. In any case, WITH_NEXT_FRAMEWORK is not defined 
in sysconfig. Nevertheless, when I was running their buggy ipython, 
which was being run with python rather than pythonw (or equivalent), 
matplotlib was *not* objecting to using the macosx backend--it was the 
default--and it was not segfaulting, but neither was it producing usable 
plot windows.
They have fixed their ipython on python 3, so now the osx backend works.
Eric
>
> Cheers,			Derek
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi Chris,
> the framework. Though, if I understand correctly, Anaconda provides a framework version of the interpreter
> pythonw and a non-frameworked python?
> 
> This is right -- the GUI backends to matplotlib cause python to crash, but not pythonw. This is annoying, since the two binaries
> are equivalent under most other python installs. E.g. the mac system python manpage reads:
> 
> To support multiple versions, the programs named python and pythonw now
> just select the real version of Python to run, depending on various set-
> tings. (As of Python 2.5, python and pythonw are interchangeable; both
> execute Python in the context of an application bundle, which means they
> have access to the Graphical User Interface; thus both can, when properly
> programmed, display windows, dialogs, etc.) 
> 
> So people don't usually think to invoke different anaconda python commands, leading to unexpected crashes (especially when using tools like pytest, which invoke python, run a test that needs MPL, and crash).
> 
well, the way it is currently designed to would be to ‘crash’ resp. exit with an error right on starting up the
non-framework interpreter. But besides that it’s curious that its python actually crashes with the macosx
backend, which I have never seen with Fink’s non-framework Python. Just tested this with 1.4.0rc3 and
Python2.7 (previously with 1.5.x HEAD in Python3.4), and it works the same - the same little quirks,
but no signs of performance or stability problems.
> This definitely seems like Anaconda's problem rather than matplotlib's (it affects any program that tries to import Qt, e.g.)
> 
So it affects other backends besides macosx or even all? Yes, this seems to be rather Anaconda-specific.
I’ve looked for anything special in the build options, but besides adding the right include and linker paths
there isn’t really anything.
Cheers,
					Derek

Hi Derek,
> the framework. Though, if I understand correctly, Anaconda provides a
> framework version of the interpreter
> pythonw and a non-frameworked python?
This is right -- the GUI backends to matplotlib cause python to crash, but
not pythonw. This is annoying, since the two binaries
are equivalent under most other python installs. E.g. the mac system python
manpage reads:
 To support multiple versions, the programs named python and pythonw now
 just select the real version of Python to run, depending on various
set-
 tings. (As of Python 2.5, python and pythonw are interchangeable; both
 execute Python in the context of an application bundle, which means
they
 have access to the Graphical User Interface; thus both can, when
properly
 programmed, display windows, dialogs, etc.)
So people don't usually think to invoke different anaconda python commands,
leading to unexpected crashes (especially when using tools like pytest,
which invoke python, run a test that needs MPL, and crash).
This definitely seems like Anaconda's problem rather than matplotlib's (it
affects any program that tries to import Qt, e.g.)
chris

---------- Forwarded message ----------
From: Jens Nielsen <jen...@gm...>
Date: Fri, Aug 15, 2014 at 10:05 PM
Subject: Re: [IPython-dev] ipython slowdown with qt
To: IPython developers list <ipy...@sc...>
While I can reproduce the issue using %gui qt I can also reproduce it with
the WX backend (%qui wx) with more or less the same symptoms. However, I
don't see the issue with either of the 'tk' or the 'osx' backends. And yes
the issue is reproducible in a python installation without any mpl
installed.
/Jens
On Fri, Aug 15, 2014 at 9:22 PM, Eric Firing <ef...@ha...> wrote:
> On 2014年08月15日, 9:37 AM, Derek Homeier wrote:
> > 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.
>
> [I'm switching the subject because my comments below relate to ipython
> and matplotlib, and are no longer Anaconda-specific.]
>
> Derek,
>
> Thanks. A few days ago, when I switched from testing on linux to
> testing on osx, exactly this ipython slowdown was happening to me--but I
> lost track of what combination of versions and invocations was causing
> it. Therefore I have been concentrating on the severe problem which
> was, for me, 100% repeatable, and involved macosx backend, not Qt. I
> expect the macosx-relatec problem will go away after Ilan uploads the
> revised Anaconda ipython for python 3.
>
> Now I find I can repeat the ipython problem on Homebrew python 3
> (framework--with Quartz app) and Anaconda with the un-fixed ipython
> (which is running without starting a Quartz app):
>
> ipython --pylab=qt
>
> Leave it alone for a bit. Try scrolling through history. Long delay,
> even in responding to Ctrl-C. Evidently key events are stacking up and
> not being processed. Now try:
>
> ipython
> %pylab qt
>
> I see the slowdown with this, also. The response delay seems to get
> worse with time. It renders the session unusable after only a few minutes.
>
> ipython
> %gui qt
>
> And I still see it, so this appears to be a problem in ipython's PyQt4
> gui handling, not directly related to matplotlib. All on Mavericks,
> running ipython from Apple's terminal.
>
> Eric
>
>
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPy...@sc...
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>

On 15 Aug 2014, at 10:39 pm, Eric Firing <efi...@gm...> wrote:
> On 2014年08月15日, 9:37 AM, Derek Homeier wrote:
> 
>> 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).
> 
> It sounds like whatever mechanism _macosx.m has been using to determine whether it is running inside a Python Quartz app, does not work in all cases--I gather it works with Fink, but it certainly does not with Anaconda. Any idea why, and how this might be fixed? Wx does detect this correctly, and refuses to run if in a script invoked with Anaconda's python rather than pythonw, for example. (As an aside, wx is not available yet for python 3 except in phoenix development daily builds, so my comment above is based on a test some time ago with python 2.7)
I don’t know much about Anaconda, but since this is hardcoded in macros, the only way I see this failing
is if they somehow incorrectly define WITH_NEXT_FRAMEWORK in pyconfig.h without actually building
the framework. Though, if I understand correctly, Anaconda provides a framework version of the interpreter
pythonw and a non-frameworked python? But matplotlib is probably only built against one of them, thus
not getting the correct header version...
Cheers,
					Derek