Re: [matplotlib-devel] Test failure testing binary installer - any clues?
On 10/18/2013 02:11 AM, Matthew Brett wrote: > Hi, > > I'm testing the binary installer build: > > https://travis-ci.org/matthew-brett/mpl-osx-binaries/builds/12703220 > > and I'm getting a test failure on Python 3.3 (not Python 2.7): > > == > FAIL: matplotlib.tests.test_lines.test_invisible_Line_rendering.test > -- > Traceback (most recent call last): >File > "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/nose/case.py", > line 198, in runTest > self.test(*self.arg) >File > "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/testing/decorators.py", > line 73, in test > self._func() >File > "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/tests/test_lines.py", > line 54, in test_invisible_Line_rendering > assert_true(slowdown_factor < slowdown_threshold) > AssertionError: False is not true > > -- > Ran 1464 tests in 656.822s > > Is this a problem? What should I do to debug further? > I've never seen that failure before... I wonder if Pierre Haessig has any thoughts, as the author of that test... Mike -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib user guide
On Fri, Oct 4, 2013 at 1:40 PM, Russell E. Owen wrote: >> Introducing Plotting with Matplotlib >> >> Pyplot tutorial >> Controlling line properties >> Working with multiple figures and axes >> Working with text >> Interactive navigation >> Navigation Keyboard Shortcuts >> Working with text >> Text introduction >> Basic text commands >> Text properties and layout >> Writing mathematical expressions >> Text rendering With LaTeX >> Annotating text > ... > - Would you be willing to include a section on using the class API? (I'm > assuming the above is all based on using pyplot?). +inf Even better, dump pyplot and use primarily the OO API. Asside from folks that dont want to change anything when moving from Matlab, we should all be using teh primarily OO API. is it really that hard to type: ax.plot() rather than plot() ? And when you move away from interactive use (and we all should fi your typing more than 4-5 lines of code) teh OO interface is a much better way to go. (I know, iPython notebooks allow you do do a LOT with esentially an interactive interpreter, but still.) Anyway, I've always thought it was a real shame that most of the tutorials on MPL out there get people started on what I'm convinced is the wrong foot. - just my opinionated $0.02 worth... -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Directories for C/C++ extensions
Ian, > I am working on a PR to replace the use of matplotlib.delaunay with the > Qhull library. nice! -- ( though I sure wish Qhull did constrained delaunay...) > Installation will be similar to the existing packages LibAgg > and CXX in that if the system already has a sufficiently recent version of > Qhull installed then matplotlib will use that, otherwise it will build the > required library from the source code shipped with matplotlib. Why bother, why not just always build the internal version? (for that matter, same with agg) Wouldn't it be a lot easier and more robust to be sure that everyone is running the exact same code? What are the odds that folks are using qhull for something else, and even more to the point, what are the odds that the duplication of this lib would matter one wit? This isn't like LAPACK, where folks have a compellling reason to run a particular version. -- just my thoughts on how to keep things simpler. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib user guide
On Fri, Oct 18, 2013 at 2:13 PM, Chris Barker wrote: > On Fri, Oct 4, 2013 at 1:40 PM, Russell E. Owen wrote: > >> Introducing Plotting with Matplotlib > >> > >> Pyplot tutorial > >> Controlling line properties > >> Working with multiple figures and axes > >> Working with text > >> Interactive navigation > >> Navigation Keyboard Shortcuts > >> Working with text > >> Text introduction > >> Basic text commands > >> Text properties and layout > >> Writing mathematical expressions > >> Text rendering With LaTeX > >> Annotating text > > ... > > > - Would you be willing to include a section on using the class API? (I'm > > assuming the above is all based on using pyplot?). > > +inf > > Even better, dump pyplot and use primarily the OO API. Asside from > folks that dont want to change anything when moving from Matlab, we > should all be using teh primarily OO API. > > is it really that hard to type: > > ax.plot() > > rather than > > plot() ? > > And when you move away from interactive use (and we all should fi your > typing more than 4-5 lines of code) teh OO interface is a much better > way to go. > > (I know, iPython notebooks allow you do do a LOT with esentially an > interactive interpreter, but still.) > > Anyway, I've always thought it was a real shame that most of the > tutorials on MPL out there get people started on what I'm convinced is > the wrong foot. > > - just my opinionated $0.02 worth... > > -Chris > > FWIW, I think my "Anatomy of Matplotlib" tutorial I gave at SciPy 2013 struck a balance between pyplot and the OO interface. I welcome any and all feedback on that tutorial which I plan to give again next year as well as an intermediate "Anatomy of Matplotlib" tutorial. Cheers! Ben Root -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Directories for C/C++ extensions
On Oct 18, 2013 8:20 PM, "Chris Barker" wrote: > > Ian, > > > I am working on a PR to replace the use of matplotlib.delaunay with the > > Qhull library. > > nice! -- ( though I sure wish Qhull did constrained delaunay...) > > > Installation will be similar to the existing packages LibAgg > > and CXX in that if the system already has a sufficiently recent version of > > Qhull installed then matplotlib will use that, otherwise it will build the > > required library from the source code shipped with matplotlib. > > Why bother, why not just always build the internal version? > > (for that matter, same with agg) > > Wouldn't it be a lot easier and more robust to be sure that everyone > is running the exact same code? > > What are the odds that folks are using qhull for something else, and > even more to the point, what are the odds that the duplication of this > lib would matter one wit? > > This isn't like LAPACK, where folks have a compellling reason to run a > particular version. > > -- just my thoughts on how to keep things simpler. > > > -Chris >From a Linux distro packaging perspective bundled external libs are a big no-no. If a patch is needed for whatever reason packagers don't want to have to go and hunt down dozens of copies of the same library. In some cases there is no alternative but it should be avoided whenever possible. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
