[matplotlib-devel] backend_macosx framework check fails with 64bit Python
Hi again, cc'ing the matplotlib list this time, for the latter: when building matplotlib against a fink-installed python compiled in 64bit mode I found the check for a framework-installed Python (rev 8365) fails, and matplotlib fails to load, because the MacOS module is not available in 64bit. Actually Apple seems to have made it still available in their system Python, but it's likely to be a general problem on 64bit OS X installations, and will be for python3 as well. I believe I have fixed the patch file issue that came from an accidental edit of the patch file (off by 1 space character). For the issues below, can you give me some examples that show the behavior that is broken now, but fixed into your updated patch? I haven't used matplotlib in a long time. thanks, the fixed patch in unstable compiles and runs now. Sorry for the late reply; I found that the issue that my extra patch addressed actually only seems to exist for x86_64 on Snow Leopard. It is in fact not directly related to python being built as a framework, but the "import MacOS" used to check for the framework version fails, since the MacOS module is not available in 64bit. Or so the python docs state, but Apple seems to have retrofitted it somehow into their system python, so my test for "import MacOS" worked with /usr/bin/python even on Snow Leopard. So the test for MacOS.WMAvailable() that my patch removed can obviously stay there for 32bit installations, and it would probably be better to just catch the import error on 64bit systems. I'll try to work something out along those lines, and probably send it upstream to the matplotlib folks as well, since this should be a general problem on 64bit systems; and also the MacOS module is going to be removed altogether in python3.x. I'll keep you posted. I've put the import inside the check now and have it print the warning in both cases (assuming Python is not a framework installation if it lacks the MacOS module). I don't know if there might be an alternative way to check for the framework property for later, and I just picked an error to raise that seemed sensible - feel free to change that as necessary. Cheers, Derek MacOS-64bit.patch Description: Binary data -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] backend_macosx framework check fails with 64bit Python
Hi Friedrich, >> for the latter: when building matplotlib against a fink-installed python >> compiled in 64bit mode >> I found the check for a framework-installed Python (rev 8365) fails, and >> matplotlib fails to load, >> because the MacOS module is not available in 64bit. > > Hmm, do you claim that MacOS is in general not available in x86_64? I intended to, since the fink porting description for Python under OS X 10.6 states so, and I was also mislead by the statement "not available in 64-bit mode" in http://docs.python.org/library/macos.html , but the latter, I realised, applied just to individual functions (in this case, the last one in the list). You are right, in principle MacOS.WMAvailable() should still be available (;-) on x86_64. > Just my 2 cents: > > pb-d-128-141-26-145:~ Friedrich$ python-32 > Python 2.6.5 (r265:79063, Jul 18 2010, 12:14:53) > [GCC 4.2.1 (Apple Inc. build 5659)] on darwin > Type "help", "copyright", "credits" or "license" for more information. >>>> import MacOS >>>> ^D > pb-d-128-141-26-145:~ Friedrich$ python-64 > Python 2.6.5 (r265:79063, Jul 18 2010, 12:14:53) > [GCC 4.2.1 (Apple Inc. build 5659)] on darwin > Type "help", "copyright", "credits" or "license" for more information. >>>> import MacOS >>>> ^D > > This is a self-compiled python.org Python 2.6.5 residing in > /Library/Frameworks/Python.framwork: > ./configure --enable-framework --with-universal-archs=intel > --enable-universalsdk=/ > with > MACOSX_DEPLOYMENT_TARGET=10.4 > GCC=gcc-4.2 > > Please bear with me, but how does framework/not-framework interfere > with the build of the MacOS module? >> (assuming Python is not a framework installation if it lacks the MacOS >> module). > > Are there more implications? I always thought framework build just > means to put it in /Library/Framworks/Python.framework. Good question - all I can tell at this point is that in fink, python is not built as a framework, merely with ./configure --enable-shared and on Snow Leopard this fails: miranda:2843> /sw/bin/python2.6 Python 2.6.5 (r265:79063, Jul 19 2010, 02:30:51) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import MacOS Traceback (most recent call last): File "", line 1, in ImportError: No module named MacOS miranda:2844> /usr/bin/python Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. Traceback (most recent call last): File "/Users/derek/.pythonrc", line 22, in readline.read_history_file(historyPath) IOError: [Errno 2] No such file or directory >>> import MacOS >>> MacOS.WMAvailable() True >>> ^D There is no patch that would have explicitly removed the module in the fink install, so all I can think of is that not enabling framework and/or SDK build is responsible. I did not find any hint in the Mac build documentation towards this, though. If this is a fink-related problem only, of course we'd just need to apply the patch I've created to the fink package. But matplotlib will probably have to deal with it whenever it is going to be python3-ready. Cheers, Derek -- - Derek Homeier Institut für Astrophysik Göttingen Georg-August-Universität Phone: +49 551 39-7980 Friedrich-Hund-Platz 1Fax: +49 551 39-5043 D-37077 Göttingen, GermanyFeet: E.04.104 Web: http://www.astro.physik.uni-goettingen.de/~derek/ - -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib 1.0.1rc available for testing, building
On 04.01.2011, at 1:49AM, Russell E. Owen wrote:
I have uploaded Mac installers for python.org Python 2.6 and 32-bit
Python 2.7.
I'm not sure what to do about 64-bit Python 2.7. It does not even
support Mac OS X 10.5 due to tcl/tk issues that I think were resolved
too late for python 2.7.1. In my opinion a matplotlib built against
ActiveState's Python 2.7 (which is 64-bit and supports 10.5 and 10.6)
might be of more use. Opinions?
I cannot provide much input on those Python installations, but I've
built rc1
against the fink installations of python/numpy for Intel and PPC 10.5
as well
as Intel 10.6. I could not reproduce the
missing .matplotlib/.fontconfig-related
crashes with this build.
With the 64-bit installation on 10.6 I encountered a problem discussed
a few months
ago on the list, due to the MacOS module being removed from standard
64-bit Python
builds (and being generally deprecated for Python 3); this had been
resolved by
Michiel de Hoon in r8624 (and some parts in r8710, it seems), but
those changes did
not make it into rc1. I have attached the patch in the form working
for me.
HTH,
Derek
matplotlib-py.patch
Description: Binary data
P.S. Test outcome is somewhat different between calling pylab.test()
from the interpreter
Python 2.6.6 (r266:84292, Jan 3 2011, 20:49:26)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import pylab
>>> pylab.test('full')
Running unit tests for numpy.linalg
/sw/lib/python2.6/site-packages/nose/plugins/manager.py:407:
UserWarning: Module dap was already imported from None, but /sw/lib/
python2.6/site-packages is being added to sys.path
import pkg_resources
NumPy version 1.5.1
NumPy is installed in /sw/lib/python2.6/site-packages/numpy
Python version 2.6.6 (r266:84292, Jan 3 2011, 20:49:26) [GCC 4.2.1
(Apple Inc. build 5664)]
nose version 0.11.4
S
...
--
Ran 156 tests in 0.374s
or directly calling nosetests in the matplotlib directory (same errors
occurring with python2.7 and on
10.5 x86/ppc, just the FAIL:
matplotlib.tests.test_mlab.test_recarray_csv_roundtrip only appears
on 64-bit 10.6):
> nosetests2.6
/sw/bin/nosetests2.6:5: UserWarning: Module dap was already imported
from None, but /sw/lib/python2.6/site-packages is being added to
sys.path
from pkg_resources import load_entry_point
/sw/lib/python2.6/site-packages/matplotlib/rcsetup.py:302:
UserWarning: tk.pythoninspect is obsolete, and has no effect
warnings.warn("tk.pythoninspect is obsolete, and has no effect")
/sw/lib/python2.6/site-packages/matplotlib/numerix/__init__.py:18:
DeprecationWarning:
**
matplotlib.numerix and all its subpackages are deprecated.
They will be removed soon. Please use numpy instead.
**
warnings.warn(msg, DeprecationWarning)
.Warning: divide by zero
encountered in log
.Warning: divide by zero encountered in log
.Warning: divide by zero encountered in log
EE/sw/lib/python2.6/site-packages/
matplotlib/axes.py:2381: UserWarning: Attempting to set identical
left==right results
in singular transformations; automatically expanding.
left=730139.0, right=730139.0
+ 'left=%s, right=%s') % (left, right))
...EE.Warning: invalid value encountered in
absolute
Warning: invalid value encountered in absolute
F./sw/lib/python2.6/site-packages/
matplotlib/font_manager.py:1242: UserWarning: findfont: Font family
['Foo'] not found. Falling back to Bitstream Vera Sans
(prop.get_family(), self.defaultFamily[fontext]))
E.E
==
ERROR: matplotlib.tests.test_axes.test_pcolormesh
--
Traceback (most recent call last):
File "/sw/lib/python2.6/site-packages/nose/case.py", line 186, in
runTest
self.test(*self.arg)
File "/sw/lib/python2.6/site-packages/matplotlib/testing/
decorators.py", line 32, in failer
result = f(*args, **kwargs)
File "/sw/lib/python2.6/site-packages/matplotlib/testing/
decorators.py", line 126, in decorated_compare_images
'(RMS %(rms).3f)'%err)
ImageComparisonFailure: images not close: /sw/lib/python2.6/site-
packages/matplotlib/result_images/test_axes/pcolormesh.png vs. /sw/lib/
python2.6/site-packages/matplotlib/result_images/test_axes/expected-
pcolormesh.png (RMS 116.512)
==
ERROR: matplotli
Re: [matplotlib-devel] Help
On 16 Mar 2011, at 09:48, Georges Arsouze wrote: > I'am working with Python3.1 under Mac Os Snow Leopard > I download matplotlib with > http://www.cgl.ucsf.edu/Outreach/pc204/matplotlib.html > > It doesn't work > Can you help me ? > That package, as the site states (though maybe not clearly enough), has been built for Snow Leopard's system Python 2.6.2, so it cannot work with Python3.1. If you call python2.6 or /usr/bin/python, you should be able to use matplotlib. But if you need Python3.1, I am afraid you are stuck for the moment, since the latest release does not support Python3 yet. I think support is in the works, and may be partly available in the development version, but unless you have considerable experience in building your own installation, I would not recommend that road. HTH, Derek -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday
Hi Sandro,
> On Fri, Mar 23, 2012 at 03:18, John Hunter wrote:
>> The tarballs for the v1.1.1 release candidate 1 (rc1) are uploaded to and
>> are available for testing and building binaries
>>
>>
>> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1/
>>
>> After the binaries are up, I'll send out a notice to the users list
>> requesting wider testing, but intrepid developers can begin now.
>
> I'll start testing debian packaging right away; for our package we
> also need the sampledata tarball: can I reuse the one for 1.1.0 or is
> a new one needed?
I used the 1.1.0 version to build with the fink Python installation on MaxOS X
and everything seems to work there, passing the tests at least (does
pylab.test('full')
execute all tests? It seems a rather small number…).
I have another question - I am trying to build a fink package with the
documentation
and am wondering if "python make.py --small html" actually has any effect?
This still creates more than 70 MB of documentation, 24 MB in the _images
subdir
alone, which increases the .deb size by a factor of ~2.5. How are you handling
this
for the Debian package?
Cheers,
Derek
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday
On 24.03.2012, at 8:16PM, Sandro Tosi wrote:
>
> to run tests I use:
>
> python -c "import matplotlib as m ; m.test(verbosity=1)"
>
Ah, thanks for the reminder; that looks much more comprehensive!
Actually the fink testing command requires an exit value of 1 or higher to
detect errors, so I am using something like
"… r=m.test(verbosity=1); sys.exit(len(r.errors+r.failures))"
>> I have another question - I am trying to build a fink package with the
>> documentation
>> and am wondering if "python make.py --small html"
>
> In debian I use:
>
> ./make.py --small all
>
>> actually has any effect?
>
> what do you mean?
>
>> This still creates more than 70 MB of documentation, 24 MB in the _images
>> subdir
>> alone, which increases the .deb size by a factor of ~2.5. How are you
>> handling this
>> for the Debian package?
>
> well, yes, the doc is huge (the debian package size is 52M compressed)
> and that is good; --small helped reducing the package size, setting
>
>if small_docs:
>options = "-D plot_formats=\"[('png', 80)]\""
>
> which reduced the type and size of the output images.
Indeed, I seemed to remember the regular output was not that much larger,
but I must have missed all the hires.png and pdf images in the mpl_examples.
They do account for additional 60-70 MB...
I was also curious if you had considered moving the docs to a separate package.
I will propose one for fink; since there probably more people are building
their
packages themselves, the savings in build time might already justify that.
Cheers,
Derek
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday
On 26.03.2012, at 7:43PM, John Hunter wrote:
> On Mon, Mar 26, 2012 at 12:00 PM, Russell Owen wrote:
> On Mar 24, 2012, at 12:16 PM, Sandro Tosi wrote:
>
> > On Sat, Mar 24, 2012 at 18:13, Derek Homeier
> > wrote:
> >> I used the 1.1.0 version to build with the fink Python installation on
> >> MaxOS X
> >> and everything seems to work there, passing the tests at least (does
> >> pylab.test('full')
> >> execute all tests? It seems a rather small number…).
> >
> > to run tests I use:
> >
> > python -c "import matplotlib as m ; m.test(verbosity=1)"
>
> Thank you for the test instructions. That's a much more complete test than I
> had been using. I get the following one failure on Mac OS X 10.6 using my new
> binary installer (results are appended). I'm also concerned about the
> complaint:
> """
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/__init__.py:921:
> UserWarning: This call to matplotlib.use() has no effect
> because the the backend has already been chosen;
> matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
> or matplotlib.backends is imported for the first time.
> """
> which suggests a test that is mis-written.
>
> At the end of the tests we try and switch back to the users original backend
> (we switch into agg at the start) in case the user is running interactively.
> This warning is mostly harmless, and doesn't indicate a problem with any
> tests. It appears you have just the one failure on fonts-styles.
>
I also had two failures of this type on my first attempt to test the package;
now when
testing within the fink build environment, everything passes. This might have
to do
with the fontconfig setup, not sure if I can reproduce it any more or nail it
further down.
> Ran 1061 tests in 344.859s
>
> FAILED (KNOWNFAIL=541, failures=1)
Russel, you may also want to check the testing dependencies mentioned in
connection
with the tests under Windows in this thread - installing inkscape in addition
to ghostscript
and pil got me rid of the Known Failures (due to missing functionality for
comparing PDF
and SVG output) as well.
Does anyone see a problem with running the tests with 'python -B'? Otherwise
I'd need to
get rid of the byte-compiled files in the build directory afterwards, as they
would cause the
package validation to fail.
Cheers,
Derek
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday
Hi Sandro, > yes, Debian has a separate package for documentation (since it > requires to be build just on time, whilc mpl requires to be built on > each architecture we support, so splitting the package results in a > lot of saved space). JFYR this is the layout of packages in Debian: > > python-matplotlib - the python module > python-matplotlib-data - mpl-data dir + sampeldata + config files + nib + > fonts > python-matplotlib-dbg - debug symbols for python extensions > python-matplotlib-doc - all the built doc, in html and pdf formats thanks for the info; currently fink only has extra packages for the basemap toolkit. While there are not that many actual architectures, there are still up to 4 or 5 Python versions to support, so a single doc package could also save a lot (although I am not sure how to setup such a build yet…). The actual matplotlib module could also be reduced much further in size when building from the _notests tar ball. I am not sure how much demand there is for normal users to be able to run the complete test suite. Or is this just a temporary option for the rc builds anyway? Cheers, Derek -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.1.1rc2 tarballs are up
On 01.07.2012, at 12:17AM, Sandro Tosi wrote: >> >> Just out of curiosity, what is the mismatch? (I believe you, I just >> know very little about the debian process). > > These are the rules: http://release.debian.org/wheezy/freeze_policy.html > > And none of the rules match this situation. RC2 will be :) What about the very last one? "For packages which missed the freeze only for reasons outside of the control of the maintainers, we might be generous, but you need to contact us on your own, and you need to contact us soon." Cheers, Derek -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.1.1rc2 tarballs are up
On 06.07.2012, at 3:49PM, Damon McDougall wrote: >> >> When I tested on Mac OS X 10.6 I found that most unit tests were somehow >> missing. Rather than try to diagnose the problem, I built a new binary >> on 10.6, confirmed that it installed properly (with all unit tests) on >> 10.6 and 10.7, then uploaded it to replace the earlier 10.6 binary. >> >> The same test I mentioned in my previous post still fails using the new >> binary, on both 10.6 and 10.7. >> >> -- Russell >> > > I did a git checkout of the v1.1.1 tag and compiled a 64-bit version. I > have attached output from the following command: > > python -c "import matplotlib as m ; m.test(verbosity=1)" > > Note that some of the tests fail with satuses: KEFKK. > I have the following requirements installed: > > nose: version 1.1.2 > PIL: version 1.1.7 > ghsotscript: version 9.05 > inkscape: 0.48.3.1 > > All of these were installed using the latest version of macports. > Is there anything I can do to improve the output of the tests? I see the same 3 known failures building with fink and the same versions of the above dependencies, and also get the already mentioned Stix failure. Everything else succeeds on 10.5, but I get a different inkscape error on 10.7: + IOError: Conversion command failed: inkscape -z /scratch.noindex/fink.build/matplotlib-py27-1.1.1-1/matplotlib-1.1.1/result_images/test_legend/legend_auto2.svg --export-png /scratch.noindex/fink.build/matplotlib-py27-1.1.1-1/matplotlib-1.1.1/result_images/test_legend/legend_auto2_svg.png Standard output: Background RRGGBBAA: ff00 Area 0:0:720:540 exported to 720 x 540 pixels (90 dpi) Bitmap saved as: /scratch.noindex/fink.build/matplotlib-py27-1.1.1-1/matplotlib-1.1.1/result_images/test_legend/legend_auto2_svg.png Standard error: (inkscape:25527): libgnomevfs-WARNING **: Unable to create ~/.gnome2 directory: Permission denied File display/nr-arena-item.cpp line 147 (?): Assertion child->parent == NULL failed ** ERROR:sp-clippath.cpp:308:void sp_clippath_hide(SPClipPath*, unsigned int): code should not be reached Emergency save activated! Emergency save completed. Inkscape will close now. If you can reproduce this crash, please file a bug at www.inkscape.org with a detailed description of the steps leading to the crash, so we can fix it. ** Message: Error: Inkscape encountered an internal error and will close now. + This is obviously an inscape bug to be reported it to its respective maintainers. I found that on the Inkscape web site 0.48.2 is advertised as the stable release, so I tried downgrading to that version, but just get a similar crash on a different file. Cheers, Derek -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] 1.2.0rc2 is tagged and uploaded
On 20.09.2012, at 7:23PM, Benjamin Root wrote: > Is it just me, or are colors looking duller? > > I attached before (v1.1.x) and after (v1.2.x) images. Is this the same colour map? To me it looks like jet or rainbow vs. coolwarm. The latter had been endorsed by a number of people here for its visualisation qualities [http://www.sandia.gov/~kmorel/documents/ColorMaps/]; maybe it has just become the new default? Cheers, Derek -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Planning for 1.3.0
On 11.04.2013, at 6:38PM, Michael Droettboom wrote: > Congrats to everyone on a successful 1.2.1 -- there was a relatively > small influx of bug reports following it -- perhaps a sign of improving > quality? Thanks and congratulations to everyone involved as well; I've built 1.2.1 on MacOS X with fink for Python2.6-3.2 without any failures in the test suite! I did run into a problem though that has actually existed since the first 1.2 release - with the MacOSX backend line plots of somewhat larger arrays with significant "high-frequency" power had extremely degraded, e.g. something like x = np.linspace(0,10,1.e6) y = np.cos(x)+0.2*np.sin(x*3.e3)+0.1*np.cos(x*4.e4)*np.random.rand(1.e6) plt.plot(x, y) would display within less than 2 seconds with 1.1.1, but with 1.2.x you literally have to wait minutes, and it takes similarly long to zoom in as long as you have a substantial part of the line in the window. I found in the current HEAD (9e477b3) this has finally been fixed - thanks for that as well, whatever the problem was, but now in the 1.3 branch the _macosx backend has been altogether disabled! I verified after removing that RuntimeError from _macosx.m that the backend still works and is indeed up to its old speed; but if that change stays in, it won't be usable from non-framework Python installs like the fink ones. Personally, I am aware of the problems with the missing window manager control, and occasionally am annoyed by hunting for a plot window that has sneaked somewhere underneath other windows, but with that in mind I still prefer the MacOSX backend to any of the others, and I would suggest to leave it at a warning rather than an error, so users can still decide for themselves if they want to put up with the possible troubles. Cheers, Derek -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Planning for 1.3.0
Hi Michiel, On 13.04.2013, at 1:30AM, Michiel de Hoon wrote: > The slow speed for long paths like the one in your example was due to a > limitation to Quartz itself. This was solved by breaking the path up into > subpaths of up to 100 points. But you mentioned that releases before 1.2 were > not slow (and I verified this with matplotlib 1.1.1), suggesting that > something else is going on. Can you check which change between 1.1.1 and 1.2 > is causing the slowdown for your example? It's the passing of set_dpi (commit 6533674) - that's still unchanged in master, but I don't see any speed penalty compared to 1.1.1 any more. I don't know if the change you mentioned above completely fixed this or just made up for it by speeding it up otherwise… I have just merged all updates to backend_maxosx.py and _macosx.m back into 1.2.1, and this seems to solve the issue and passes all tests as well. Cheers, Derek -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Planning for 1.3.0
Hi Michiel, > That is good to hear. > The slowdown was caused by the performance of Quartz itself, but it depends > strongly on the line width. In your example, the plot appears immediately if > you use linewidth=0.9, but (with matplotlib 1.2.1) takes minutes to appear if > you use linewidth=1.0. The change in set_dpi caused the line width actually > used for drawing to increase slightly. The increase was very small, but big > enough to trigger the ultraslow behavior of Quartz. As I mentioned, we solved > this by breaking up the path into many subpaths, which solved the problem > (without having to change set_dpi back). > Anyway, if I understand your mail correctly, the problem has been fixed in > HEAD. Is the 1.3 branch also OK now? In your first post you mentioned that > there was some RuntimeError. I saw a couple of warnings with Friday's checkout on 10.8, but the current one seems to work fine (now on 10.7 however…). I've run the full test suite and only had three failures in test_font_styles (basically all created fonts look like 'light'/'condensed'). The same with python3.2 after I upgraded pyparsing, only at the end of 'setup.py install' there was an additional error, but this did not seem to affect the install (appended below). The RuntimeError was enforced by the #ifdef WITH_NEXT_FRAMEWORK check that does not allow to use the backend at all, so I had to change this to a RuntimeWarning to be able to test the backend in the 1.3 branch. Cheers, Derek -- Processing matplotlib-1.3.x-py3.2-macosx-10.7-x86_64.egg creating /Users/derek/lib/python3.2/site-packages/matplotlib-1.3.x-py3.2-macosx-10.7-x86_64.egg Extracting matplotlib-1.3.x-py3.2-macosx-10.7-x86_64.egg to /Users/derek/lib/python3.2/site-packages Adding matplotlib 1.3.x to easy-install.pth file Installed /Users/derek/lib/python3.2/site-packages/matplotlib-1.3.x-py3.2-macosx-10.7-x86_64.egg Processing dependencies for matplotlib==1.3.x Traceback (most recent call last): File "setup.py", line 228, in 'KnownFailure = matplotlib.testing.noseclasses:KnownFailure' File "/sw/lib/python3.2/distutils/core.py", line 148, in setup dist.run_commands() File "/sw/lib/python3.2/distutils/dist.py", line 917, in run_commands self.run_command(cmd) File "/sw/lib/python3.2/distutils/dist.py", line 936, in run_command cmd_obj.run() File "/sw/lib/python3.2/site-packages/setuptools/command/install.py", line 73, in run self.do_egg_install() File "/sw/lib/python3.2/site-packages/setuptools/command/install.py", line 101, in do_egg_install cmd.run() File "/sw/lib/python3.2/site-packages/setuptools/command/easy_install.py", line 358, in run self.easy_install(spec, not self.no_deps) File "/sw/lib/python3.2/site-packages/setuptools/command/easy_install.py", line 582, in easy_install return self.install_item(None, spec, tmpdir, deps, True) File "/sw/lib/python3.2/site-packages/setuptools/command/easy_install.py", line 634, in install_item self.process_distribution(spec, dist, deps) File "/sw/lib/python3.2/site-packages/setuptools/command/easy_install.py", line 686, in process_distribution [requirement], self.local_index, self.easy_install File "/sw/lib/python3.2/site-packages/pkg_resources.py", line 586, in resolve dist = best[req.key] = env.best_match(req, self, installer) File "/sw/lib/python3.2/site-packages/pkg_resources.py", line 829, in best_match for dist in self[req.key]: File "/sw/lib/python3.2/site-packages/pkg_resources.py", line 799, in __getitem__ _sort_dists(dists) File "/sw/lib/python3.2/site-packages/pkg_resources.py", line 2613, in _sort_dists tmp.sort() TypeError: unorderable types: NoneType() < str() -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Planning for 1.3.0
Hi Michiel, > This RuntimeError is there for a reason: If your Python is not installed as > a framework, the backend will not work correctly (and if you ignore the > RuntimeError, you won't know if any problems you encounter are real bugs, or > simply due to your Python not being installed as a framework). I have used the MacOSX backend ever since I started working with Python, and there only was a warning for the last 3 years or so. Other than my plot windows evading the control of Exposé/Application switcher I have never noticed any problems with this. Thus my request in my initial post to leave it as a mere warning, since I'd think people can switch on their own decision if they do not like the interaction (or lack thereof) with the window manager. Otherwise I would have to grudgingly switch to another backend (seems now that I could live with QT4Agg-Quartz or the like though), since installation as as framework is not an option with Fink. Of course if there are any other possible negative effects besides the window handling, I'd take your point. Best, Derek -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Planning for 1.3.0
Hi Michiel, On 15.04.2013, at 6:03AM, Michiel de Hoon wrote: > --- On Sun, 4/14/13, Derek Homeier > wrote: >> Of course if there are any other possible negative effects >> besides the window handling, I'd take your point. > > Several bugs have been reported in the past that turned out to be due to > Python not being installed as a framework. For example, the file selection > window when saving a figure doesn't respond. This has been a major hassle, > since each of those bug reports take time to investigate before realizing > that it is due to the Python installation. OK, that is a valid reason! I vaguely remember some problems with that in the past, though haven't experienced any of that in a long time (just tested 'Save File', and I've been regularly using 'Configure Subplots'). But this is probably a case where a Warning might not keep all users from filing a bug. :-( The QT4Agg backend has its ups as well, though there still seem to be some quirks, too (e.g. the zoom rectangle only shows up with the left and lower border); I will probably become a fan of the line configuration tool that allows you to switch back to linear from a log axis scale (in the command line there seems to be no return from plt.semilogy() or plt.loglog())! Cheers, Derek -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Planning for 1.3.0
Hi Michiel, On 16.04.2013, at 12:03AM, Michiel de Hoon wrote: > Can you perhaps ask the Fink developers to provide a framework installation > of Python? Most matplotlib users who ran into framework-related bugs were > Fink users. I've already looked for that in the list archives and it seems this topic comes up about once a year when some other package broke with the non-framework build. Changing the build does not seem a particular problem, but was always declined as it would mean all (or a large number) of the other Python-dependent packages would have to be fixed at the same time. But I can of course bring this up for discussion again pointing out that the macosx backend support is going to be discontinued. Cheers, Derek -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Numpy-discussion] matplotlib user survey 2013
On 03.07.2013, at 10:03PM, Damon McDougall wrote:
> On Tue, Jul 2, 2013 at 11:39 AM, Michael Droettboom wrote:
> [Apologies for cross-posting]
>
> The matplotlib developers want to hear from you!
>
> We are conducting a user survey to determine how and where matplotlib is
> being used in order to focus its further development.
>
> This should only take a couple of minutes. To fill it out, visit:
>
> https://docs.google.com/spreadsheet/viewform?fromEmail=true&formkey=dHpQS25pcTZIRWdqX0pNckNSU01sMHc6MQ
>
> Please forward to your colleagues, particularly those who don't read these
> mailing lists.
>
> The question, "You *primarily* use matplotlib for..." informs me to "check
> all that apply", but the answers are radio buttons, not check boxes.
>
> I'm not sure I have rights to change it.
>
But you really only can use it for one thing primarily, right? The "check all
that apply" seems out of place here.
Cheers,
Derek
--
Derek Homeier Centre de Recherche Astrophysique de Lyon
ENS Lyon 46, Allée d'Italie
69364 Lyon Cedex 07, France +33 47272-8894
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Anaconda Support] OSX: why not make "python" invoke the framework?
On 14 Aug 2014, at 11:40 pm, Chris Barker wrote: > On Thu, Aug 14, 2014 at 12:07 PM, Eric Firing 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 -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OSX framework detection
On 15 Aug 2014, at 10:39 pm, Eric Firing 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 -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OSX framework detection
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 -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Better defaults all around?
On 26 Nov 2014, at 07:53 pm, Chris Barker wrote:
> On Wed, Nov 26, 2014 at 1:30 AM, Todd wrote:
>> About this, I am not expert so forgive me if this is nonsensical. However,
>> it would seem to me that these requirements are basically the same as the
>> requirements for the new default colormap that prompted this whole
>> discussion. So, rather than create two inconsistent set of colors that
>> accomplish similar goals, might it be better to instead use the default
>> colormap for the line colors? You could pick "N" equally-spaced colors from
>> the colormap and use those as the line colors.
>>
> I'm no expert either, but while similar principles about colorblind
> compatibility, etc apply, you want to sue a different scheme to represent a
> continuous range of colors and a set of distinct colors that aren't intended
> to be ranked.
>
I’ve also become throughly annoyed with the default colour cycle, especially
with its
glaring cyan-magenta contrast, and found it desirable to have an easier way to
customise this either explicitly or by changing color_cycle.
As there are already a couple of sequences existing in the available colourmaps
that
could be useful for different purposes or tastes, what’s lacking in particular
in my view
is an easier-to-use interface to draw colours from those maps; I think that’s
along the
lines of what Todd also has suggested further down in his mail.
I’ve written a little utility I’m simply appending because it’s so short, which
returns an
array of colours of specified length that could be passed to axes.color_cycle
or just
explicitly used as crange[i]. Also useful to colour scatter plot markers
according to a
certain quantity (pass this quantity as “values” to crange).
Regarding to the above, I think sometimes the line colour requirements are
similar to
those for a general colourmap, e.g. I often want to plot a series of lines like
different
spectra, which are easily enough distinguishable, but should IMO reflect a
certain
continuous trend like different temperatures - are ranked, IOW - and thus would
be well
represented by a sequence of values from “heat" or “coolwarm". However there
are still
some additional requirements, as you’d generally want every colour to have
enough
contrast on a white or bright background canvas. In the example below I’ve
added a
“max_lum” keyword to darken whitish or yellow colours appropriately.
This is probably not extremely sophisticated in terms of colour physiology, but
if you
have a suggestion if and where it could be added to matplotlib, I could go
ahead and
make a pull request (and try to find the time to add some tests and examples).
Cheers,
Derek
def crange(cmap, values, max_lum=1, start=0, stop=255, vmin=None, vmax=None):
"""
Returns RGBA colour array of length values from colormap cmap
cmap: valid matplotlib.cm colormap name or instance
values: either int - number of colour values to return or
array of values to be mapped on colormap range
max_lum: restrict colours to maximum brightness (1=white)
start,stop: range of colormap to use (full range 0-255)
vmin,vmax: input values mapped to start/stop (default actual data limits)
"""
try:
if np.isscalar(values):
vrange = np.linspace(start,stop,np.int(values))
else:
v = np.array(values).astype(np.float)
vmin = vmin or v.min()
vmax = vmax or v.max()
vrange = start+(v-vmin)*(stop-start)/(vmax-vmin)
except (ValueError, TypeError) as err:
print("invalid input values: must be no. of colours or array: %s" %
err)
return None
vrange = np.uint8(np.round(vrange))
cmap = matplotlib.cm.get_cmap(cmap)
lcor = (1.0-max_lum) / 9
crange = cmap(vrange)
crange[:,:3] *= (1-crange[:,:3].sum(axis=1)**2*lcor).reshape(-1,1)
return crange
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] v1.4.3rc1
Thanks for the great work!
On 02 Feb 2015, at 11:58 am, Jens Nielsen wrote:
> I ran the test suite on OSX 10.10 with both python 2.7.8 and 3.4.2 including
> the tex and QT4 tests that are skipped on Travis.
> Everything passes as expected.
>
I’ve tested on OS X 10.9 with Fink Python 3.4.2, 3.3.6, 2.7.9
Ran 4778 tests in 540.937s
OK (KNOWNFAIL=9, SKIP=1)
OK (KNOWNFAIL=8, SKIP=1)
One error with python2.7:
FAILED (KNOWNFAIL=9, SKIP=1, errors=1)
ERROR: matplotlib.tests.test_style.test_use_url
--
Traceback (most recent call last):
File "/sw/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
File
"/scratch.noindex/fink.build/matplotlib-py27-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.9-x86_64-2.7/matplotlib/tests/test_style.py",
line 58, in test_use_url
with style.context('https://gist.github.com/adrn/6590261/raw'):
File "/sw/lib/python2.7/contextlib.py", line 17, in __enter__
return self.gen.next()
File
"/scratch.noindex/fink.build/matplotlib-py27-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.9-x86_64-2.7/matplotlib/style/core.py",
line 86, in context
use(name)
File
"/scratch.noindex/fink.build/matplotlib-py27-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.9-x86_64-2.7/matplotlib/style/core.py",
line 66, in use
raise ValueError(msg % style)
ValueError: 'https://gist.github.com/adrn/6590261/raw' not found in the style
library and input is not a valid URL or path. See `style.available` for list of
available styles.
On 10.10 there are a number of additional errors (I’ve checked the
save_animation
errors are not due to permission problems):
ERROR: matplotlib.tests.test_animation.test_save_animation_smoketest('ffmpeg',
'mp4')
--
Traceback (most recent call last):
File "/sw/lib/python3.4/site-packages/nose/case.py", line 198, in runTest
self.test(*self.arg)
File
"/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/testing/decorators.py",
line 110, in wrapped_function
func(*args, **kwargs)
File
"/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/tests/test_animation.py",
line 57, in check_save_animation
anim.save(F.name, fps=30, writer=writer, bitrate=500)
File
"/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/animation.py",
line 767, in save
writer.grab_frame(**savefig_kwargs)
File
"/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/animation.py",
line 222, in grab_frame
dpi=self.dpi, **savefig_kwargs)
File
"/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/figure.py",
line 1476, in savefig
self.canvas.print_figure(*args, **kwargs)
File
"/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/backend_bases.py",
line 2211, in print_figure
**kwargs)
File
"/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/backends/backend_agg.py",
line 513, in print_raw
renderer._renderer.write_rgba(filename_or_obj)
RuntimeError: Error writing to file
==
ERROR:
matplotlib.tests.test_animation.test_save_animation_smoketest('ffmpeg_file',
'mp4')
--
Traceback (most recent call last):
File "/sw/lib/python3.4/site-packages/nose/case.py", line 198, in runTest
self.test(*self.arg)
File
"/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/testing/decorators.py",
line 110, in wrapped_function
func(*args, **kwargs)
File
"/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/tests/test_animation.py",
line 57, in check_save_animation
anim.save(F.name, fps=30, writer=writer, bitrate=500)
File
"/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/animation.py",
line 767, in save
writer.grab_frame(**savefig_kwargs)
File "/sw/lib/python3.4/contextlib.py", line 66, in __exit__
next(self.gen)
File
"/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/animation.py",
line 188, in saving
self.finish()
File
"/scratch.noindex/fink.build/matplotlib-py34-1.4.3rc1-1/matplotlib-1.4.3rc1/build/lib.macosx-10.10-x86_64-3.4/matplotlib/animation.py",
li
Re: [matplotlib-devel] v1.4.3rc1
> On 7 Feb 2015, at 10:18 pm, Thomas Caswell wrote:
>
> raise ValueError(msg % style)
> ValueError: 'https://gist.github.com/adrn/6590261/raw' not found in the style
> library and input is not a valid URL or path. See `style.available` for list
> of available styles.
>
> Is your computer connected to the internet? Can you get to that url in any
> other way? This works on my machine and on the travis (both linux and osx
> https://travis-ci.org/MacPython/scipy-stack-osx-testing). Unfortunately the
> code currently snarfs all exceptions so this makes it hard to sort out what
> exactly is going wrong.
>
Yes, the "not found in the style library and input is not a valid URL or path”
message is not exactly
clear about that. Both with lynx and wget I am getting a warning about an
invalid ssl certificate for
that URL, so I need to explicitly override it or use ‘wget
—no-check-certificate’. Curl seems to have
some issues of its own, does not download the raw file anyway, though silently
unless given ‘-v':
> curl -v -O https://gist.github.com/adrn/6590261/raw
>
* Hostname was NOT found in DNS cache
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0*
Trying 192.30.252.143...
0 00 00 0 0 0 --:--:-- 0:00:02 --:--:-- 0*
Connected to gist.github.com (192.30.252.143) port 443 (#0)
0 00 00 0 0 0 --:--:-- 0:00:03 --:--:-- 0*
TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
* Server certificate: *.github.com
* Server certificate: DigiCert SHA2 High Assurance Server CA
* Server certificate: DigiCert High Assurance EV Root CA
> GET /adrn/6590261/raw HTTP/1.1
> User-Agent: curl/7.37.1
> Host: gist.github.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Content-length: 0
< Location: https://gist.githubusercontent.com/adrn/6590261/raw
< Connection: close
<
0 00 00 0 0 0 --:--:-- 0:00:03 --:--:-- 0
* Closing connection 0
> wget https://gist.github.com/adrn/6590261/raw
>
--2015-02-09 01:38:16-- https://gist.github.com/adrn/6590261/raw
Resolving gist.github.com (gist.github.com)... 192.30.252.143
Connecting to gist.github.com (gist.github.com)|192.30.252.143|:443...
connected.
ERROR: cannot verify gist.github.com's certificate, issued by ‘/C=US/O=DigiCert
Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA’:
Unable to locally verify the issuer's authority.
To connect to gist.github.com insecurely, use `--no-check-certificate’.
I don’t know if this is only due to something peculiar with my proxy or cache
settings, but the mpl error
comes down to python2.7’s urllib rejecting this certificate
>>> from urllib2 import urlopen
>>> fp = urlopen('https://gist.github.com/adrn/6590261/raw')
Traceback (most recent call last):
File "", line 1, in
File "/sw/lib/python2.7/urllib2.py", line 154, in urlopen
return opener.open(url, data, timeout)
File "/sw/lib/python2.7/urllib2.py", line 431, in open
response = self._open(req, data)
File "/sw/lib/python2.7/urllib2.py", line 449, in _open
'_open', req)
File "/sw/lib/python2.7/urllib2.py", line 409, in _call_chain
result = func(*args)
File "/sw/lib/python2.7/urllib2.py", line 1240, in https_open
context=self._context)
File "/sw/lib/python2.7/urllib2.py", line 1197, in do_open
raise URLError(err)
urllib2.URLError:
(even when using ‘http://...' in the URL), while python3.4 urllib apparently
has no problems with it:
>>> from urllib.request import urlopen
>>> fp = urlopen('https://gist.github.com/adrn/6590261/raw')
>>> fp
>>> fp.read()
b'axes.facecolor : adeade’
MacOS X’s own /usr/bin/python (2.7.6) works as well, and Safari displays that
URL as encrypted with a trusted
certificate from DigiCert SHA2 High Assurance Server CA.
An obvious suspect would be the latter two using Mac OS X’s system ssl, which
is OpenSSL 0.9.8za, while
lynx, wget and fink python all use fink’s OpenSSL 1.0.2; on a Linux machine
with OpenSSL 1.0.1e wget and
python2.7 can resolve the URL as well (though curl doesn’t download anything
there either).
But Fink’s python3.4 is using the same OpenSSL 1.0.2 as it’s python2.7, and
accepts the certificate as well!
Anyway this is obviously not a matplotlib problem.
> On 10.10 there are a number of additional errors (I’ve checked the
> save_animation
> errors are not due to permission problems):
>
> ERROR:
> matplotlib.tests.test_animation.test_save_animation_smoketest('ffmpeg', 'mp4')
> --
...
> To be clear, th
