matplotlib-users Mailing List for matplotlib

I wonder if it's commit 6b827cbf.

Can you do:

    git checkout 6b827cbf
    python setup.py build
    # confirm it fails

    git checkout 6b827cbf^
    python setup.py build
    # Does this work?

Mike

On 08/30/2013 01:06 PM, Nils Wagner wrote:
> Hi Michael,
>
> Thank you for your note.
> If I remember correctly I was able to build matplotlib a week ago.
> I am using opensuse12.3
>
> Nils
>
> rpm -qi python-cxx
> Name        : python-cxx
> Version     : 6.2.3
> Release     : 2.2
> Architecture: noarch
> Install Date: Sa 27 Jul 2013 15:48:45 CEST
> Group       : Development/Languages/Python
> Size        : 9783
> License     : GPL
> Signature   : RSA/SHA1, Mo 22 Jul 2013 20:26:22 CEST, Key ID 
> 45a1d0671abd1afb
> Source RPM  : python-cxx-6.2.3-2.2.src.rpm
> Build Date  : Mo 22 Jul 2013 15:27:08 CEST
> Build Host  : swkj07
> Relocations : (not relocatable)
> Packager    : pa...@li... <mailto:pa...@li...>
> Vendor      : http://packman.links2linux.de
> URL         : http://CXX.sourceforge.net/
> Summary     : Write Python extensions in C++
> Description :
> PyCXX is a set of classes to help create extensions of Python in the C
> language. The first part encapsulates the Python C API taking care of
> exceptions and ref counting. The second part supports the building of 
> Python
> extension modules in C++.
> Distribution: Extra / openSUSE_12.3
>
>
>
> On Fri, Aug 30, 2013 at 6:46 PM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
>     It looks like a version mismatch with PyCXX.  Was it recently
>     updated or changed?  What version of PyCXX do you have?  What was
>     the last version of matplotlib that worked for you?
>
>     You can force matplotlib to use its local copy of PyCXX by
>     uninstalling PyCXX, or adding the following lines to the top of
>     PyCXX::check in setupext.py:
>
>             self.__class__.found_external = False
>             return "Couldn't import.  Using local copy."
>
>     (But really, we should update setupext so users can specify the
>     local override in setup.cfg).
>
>     Mike
>
>
>     On 08/30/2013 12:35 PM, Nils Wagner wrote:
>>     Hi all,
>>
>>     I cannot build the latest matplotlib from git. The build log is
>>     attached.
>>
>>     Nils
>>
>>
>>
>>     ------------------------------------------------------------------------------
>>     Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>>     Discover the easy way to master current and previous Microsoft technologies
>>     and advance your career. Get an incredible 1,500+ hours of step-by-step
>>     tutorial videos with LearnDevNow. Subscribe today and save!
>>     http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>>
>>
>>     _______________________________________________
>>     Matplotlib-users mailing list
>>     Mat...@li...  <mailto:Mat...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>     ------------------------------------------------------------------------------
>     Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
>     Discover the easy way to master current and previous Microsoft
>     technologies
>     and advance your career. Get an incredible 1,500+ hours of
>     step-by-step
>     tutorial videos with LearnDevNow. Subscribe today and save!
>     http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Matplotlib-users mailing list
>     Mat...@li...
>     <mailto:Mat...@li...>
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

It looks like a version mismatch with PyCXX.  Was it recently updated or 
changed?  What version of PyCXX do you have?  What was the last version 
of matplotlib that worked for you?

You can force matplotlib to use its local copy of PyCXX by uninstalling 
PyCXX, or adding the following lines to the top of PyCXX::check in 
setupext.py:

         self.__class__.found_external = False
         return "Couldn't import.  Using local copy."

(But really, we should update setupext so users can specify the local 
override in setup.cfg).

Mike

On 08/30/2013 12:35 PM, Nils Wagner wrote:
> Hi all,
>
> I cannot build the latest matplotlib from git. The build log is attached.
>
> Nils
>
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi all,

I cannot build the latest matplotlib from git. The build log is attached.

Nils

BTW: I've got uploading of test results to S3 working on the main 
matplotlib repository.  It would be cool to do that here, too, but I 
believe the encrypted keys are specific to the github repo.  We can 
coordinate off-line once the repo is transferred about how to do this.

Mike

On 08/29/2013 01:01 PM, Matt Terry wrote:
>
> (Replying to the list, rather than just George)
> On Aug 29, 2013 8:18 AM, "Matt Terry" <mat...@gm... 
> <mailto:mat...@gm...>> wrote:
> >
> > I have 15/17 variants working.  each pulling binaries/source from 
> some combination of macports/brew/python.org/pip 
> <http://python.org/pip> on python 2.6, 2.7, 3.2, and 3.3.
> >
> > https://travis-ci.org/mrterry/mpl_on_travis_mac/builds/10733852
> >
> > I need to add python27 and python33 variants that install XQuartz.  
> Other than that, are there any builds that should be added?  For 
> reference,
> >
> > python.org <http://python.org> 27 / pip numpy
> > python.org <http://python.org> 27 / numpy dmg
> > python.org <http://python.org> 33 / pip numpy (no official python3 
> numpy installer)
> > (all built with static versions of libpng/freetype)
> >
> > system python + brew dependencies
> > system python + brew dependencies*
> >
> > brew python27
> > brew python27*
> >
> > brew python33
> > brew python33*
> >
> > macports py26
> > macports py27
> > macports py32
> > macports py33
> > macports py26*
> > macports py27*
> > macports py32*
> > macports py33*
> >
> > * = virtual envs. python & c dependencies installed from package 
> manager; macports, numpy from macports. --with-site-packages
> >
> >
> > I'm having a strange installation issue involving dateutil on python 
> 3.3 (only).  It is a bytes vs unicode (fight!) that manifests on 
> installation.  I can't reproduce the issue on my machine, but it may 
> have something to do with dateutil v2.1. Anyone seen something like 
> this?  installing dateutil via macports cleans up the issue (it 
> installs 2.0, i think).
> >
> > -matt
> >
> >
> >
> >
> > On Thu, Aug 29, 2013 at 4:47 AM, George Nurser <gn...@gm... 
> <mailto:gn...@gm...>> wrote:
> >>
> >> It might be useful to see how macports does it -- their builds have 
> always worked for me.
> >>
> >> George Nurser.
> >>
> >>
> >> On 23 August 2013 18:53, Chris Barker - NOAA Federal 
> <chr...@no... <mailto:chr...@no...>> wrote:
> >>>
> >>> On Fri, Aug 23, 2013 at 8:14 AM, Matt Terry <mat...@gm... 
> <mailto:mat...@gm...>> wrote:
> >>> > I'm banging away at installing MPL on top of python.org 
> <http://python.org>'s python.
> >>>
> >>> This is why binary installers are good idea!
> >>>
> >>> > the libfreetype/freetype issue.
> >>>
> >>> yeah, that's kind of ugly....and where is doesn't "just work" for 
> me...
> >>>
> >>> > 1) install libpng[1] and freetype[2] from source
> >>>
> >>> libpng and freetype are different, though install from source may be
> >>> the way to go:
> >>>
> >>> libpng is there, but is not properly installed, I'm not sure it's got
> >>> the header for the same version as the lib, and libpng-config is
> >>> either not there or not for the right version or somethign ugly. It
> >>> look, form messages at build time, that someone has hacked some code
> >>> into the MPL build that figures all that out, but for other stuff I'm
> >>> doing, I just punt and build libpng -- that's pretty straighforward,
> >>> at least. But teh solution in the MPL code now seems to work.
> >>>
> >>> > 2) install XQuartz[3] and twiddle /opt/X11, /usr/X11 (per Russell's
> >>> > directions[4]) so MPL finds XQuartz's libpng/freetype
> >>>
> >>> I _think_ that OS-X now ships with X11, which has freetype (though
> >>> installed weirdly once again...) we certainly should NOT expect people
> >>> to install anything big to build MPL, and binaries should not depend
> >>> on anything not shipped by Apple by default.
> >>>
> >>> According to Russell, you do need to install something, so I think 
> that's out.
> >>>
> >>> > 4) create the MPL binary installer and use that
> >>>
> >>> That's what most people should do -- but one of us needs to build it.
> >>>
> >>> > Option 1 seems simple-est, but installing freetype requires more 
> than
> >>> > ./configure && make && sudo make install.
> >>>
> >>> darn. But hopefully we can figure it out.
> >>>
> >>> > Option 4: This would require some input from whoever (Gohlke?, 
> Owen?) makes
> >>> > the binary installers.
> >>>
> >>> I think Russell has been doing it for MPL lately.
> >>>
> >>> My thoughts:
> >>>
> >>> We want to support two user-bases:
> >>>
> >>> 1) folks that don't mind a little command line work, and probably need
> >>> other scientific libs, etc anyway, an want an MPL that runs on their
> >>> machine:
> >>>    - these folks should use homebrew or macports to build the
> >>> dependencies (or even hand-compile them). Ideally we have setup.py
> >>> that will find those libs, and test to see that the builds work once
> >>> in a while.
> >>>
> >>> 2) folks that "just want to use it" and/or want a binary they can
> >>> re-distribute via py2app, etc.
> >>>   - for these folks, we need to provide binaries. These binaries 
> should:
> >>>    1) Match the python.org <http://python.org> python builds. 
> (probably only the Intel ones now...)
> >>>    2) statically link the non-sytem libs
> >>>
> >>> This has been done for a while, off and on, most recently by 
> Russell, AFAIK.
> >>>
> >>> But this is not a problem unique to MPL. All sorts of python packages
> >>> need this, and only some of the package maintainers do it (well).
> >>> Also, a bunch of packages require the same dependencies (i.e. PIL and
> >>> MPL both need png and freetype)
> >>>
> >>> So, rather than re-inventing the wheel over and over again, It would
> >>> be great to have a central repository where we can develop build
> >>> scripts, etc that share an infrustructure for building these binaries.
> >>>
> >>> I've started one:
> >>>
> >>> https://github.com/MacPython/mac-builds
> >>>
> >>> there is not much there, only a couple things I'm working on at the
> >>> moment (netCDF4, which is of interest to scipy folks, and py_gd, which
> >>> is my own simple drawing lib, that no one else uses (yet?)
> >>>
> >>> If anyone wants to join the project let me know -- if I know you from
> >>> your work with this community, I'll gladly add you.
> >>>
> >>> I'm using the gattai build system:
> >>> (https://sourceforge.net/projects/gattai/). I decided to do that, as I
> >>> was sick of re-writing essentially the same build scripts, and I kept
> >>> adding features to mine that would have resulted in re-implementing
> >>> gattai anyway. I've been hacking at gattai, and its author is quite
> >>> open to moving it forward.
> >>>
> >>> That being said, there is no reason that we need to use the same build
> >>> system -- we could easily have custom build scripts for a project, and
> >>> still have it share the dependencies.
> >>>
> >>> I was planning on getting it all further along before announcing the
> >>> project and looking for help, but since is came up...
> >>>
> >>> -Chris
> >>>
> >>> --
> >>>
> >>> Christopher Barker, Ph.D.
> >>> Oceanographer
> >>>
> >>> Emergency Response Division
> >>> NOAA/NOS/OR&R            (206) 526-6959   voice
> >>> 7600 Sand Point Way NE   (206) 526-6329   fax
> >>> Seattle, WA  98115       (206) 526-6317   main reception
> >>>
> >>> Chr...@no... <mailto:Chr...@no...>
> >>>
> >>> 
> ------------------------------------------------------------------------------
> >>> Introducing Performance Central, a new site from SourceForge and
> >>> AppDynamics. Performance Central is your source for news, insights,
> >>> analysis and resources for efficient Application Performance 
> Management.
> >>> Visit us today!
> >>> 
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> >>> _______________________________________________
> >>> Matplotlib-users mailing list
> >>> Mat...@li... 
> <mailto:Mat...@li...>
> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >>
> >>
> >>
> >> 
> ------------------------------------------------------------------------------
> >> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> >> Discover the easy way to master current and previous Microsoft 
> technologies
> >> and advance your career. Get an incredible 1,500+ hours of step-by-step
> >> tutorial videos with LearnDevNow. Subscribe today and save!
> >> 
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> >>
> >> _______________________________________________
> >> Matplotlib-users mailing list
> >> Mat...@li... 
> <mailto:Mat...@li...>
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >>
> >
>
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Very impressive!  This is really great.

That does sure look like a dateutil bug.  Maybe we try reporting it over 
there?

As for transferring the repository...  I've added you as a developer in 
the matplotlib organization, so you can work over there.  And it looks 
like you are the only one who can do the transfer, see here: 
https://help.github.com/articles/how-to-transfer-a-repository

I'll ping Travis again about how multi-OS testing might work, because it 
would be *absolutely killer* to get this going on matplotlib PRs.

Mike

On 08/29/2013 01:01 PM, Matt Terry wrote:
>
> (Replying to the list, rather than just George)
> On Aug 29, 2013 8:18 AM, "Matt Terry" <mat...@gm... 
> <mailto:mat...@gm...>> wrote:
> >
> > I have 15/17 variants working.  each pulling binaries/source from 
> some combination of macports/brew/python.org/pip 
> <http://python.org/pip> on python 2.6, 2.7, 3.2, and 3.3.
> >
> > https://travis-ci.org/mrterry/mpl_on_travis_mac/builds/10733852
> >
> > I need to add python27 and python33 variants that install XQuartz.  
> Other than that, are there any builds that should be added?  For 
> reference,
> >
> > python.org <http://python.org> 27 / pip numpy
> > python.org <http://python.org> 27 / numpy dmg
> > python.org <http://python.org> 33 / pip numpy (no official python3 
> numpy installer)
> > (all built with static versions of libpng/freetype)
> >
> > system python + brew dependencies
> > system python + brew dependencies*
> >
> > brew python27
> > brew python27*
> >
> > brew python33
> > brew python33*
> >
> > macports py26
> > macports py27
> > macports py32
> > macports py33
> > macports py26*
> > macports py27*
> > macports py32*
> > macports py33*
> >
> > * = virtual envs. python & c dependencies installed from package 
> manager; macports, numpy from macports. --with-site-packages
> >
> >
> > I'm having a strange installation issue involving dateutil on python 
> 3.3 (only).  It is a bytes vs unicode (fight!) that manifests on 
> installation.  I can't reproduce the issue on my machine, but it may 
> have something to do with dateutil v2.1. Anyone seen something like 
> this?  installing dateutil via macports cleans up the issue (it 
> installs 2.0, i think).
> >
> > -matt
> >
> >
> >
> >
> > On Thu, Aug 29, 2013 at 4:47 AM, George Nurser <gn...@gm... 
> <mailto:gn...@gm...>> wrote:
> >>
> >> It might be useful to see how macports does it -- their builds have 
> always worked for me.
> >>
> >> George Nurser.
> >>
> >>
> >> On 23 August 2013 18:53, Chris Barker - NOAA Federal 
> <chr...@no... <mailto:chr...@no...>> wrote:
> >>>
> >>> On Fri, Aug 23, 2013 at 8:14 AM, Matt Terry <mat...@gm... 
> <mailto:mat...@gm...>> wrote:
> >>> > I'm banging away at installing MPL on top of python.org 
> <http://python.org>'s python.
> >>>
> >>> This is why binary installers are good idea!
> >>>
> >>> > the libfreetype/freetype issue.
> >>>
> >>> yeah, that's kind of ugly....and where is doesn't "just work" for 
> me...
> >>>
> >>> > 1) install libpng[1] and freetype[2] from source
> >>>
> >>> libpng and freetype are different, though install from source may be
> >>> the way to go:
> >>>
> >>> libpng is there, but is not properly installed, I'm not sure it's got
> >>> the header for the same version as the lib, and libpng-config is
> >>> either not there or not for the right version or somethign ugly. It
> >>> look, form messages at build time, that someone has hacked some code
> >>> into the MPL build that figures all that out, but for other stuff I'm
> >>> doing, I just punt and build libpng -- that's pretty straighforward,
> >>> at least. But teh solution in the MPL code now seems to work.
> >>>
> >>> > 2) install XQuartz[3] and twiddle /opt/X11, /usr/X11 (per Russell's
> >>> > directions[4]) so MPL finds XQuartz's libpng/freetype
> >>>
> >>> I _think_ that OS-X now ships with X11, which has freetype (though
> >>> installed weirdly once again...) we certainly should NOT expect people
> >>> to install anything big to build MPL, and binaries should not depend
> >>> on anything not shipped by Apple by default.
> >>>
> >>> According to Russell, you do need to install something, so I think 
> that's out.
> >>>
> >>> > 4) create the MPL binary installer and use that
> >>>
> >>> That's what most people should do -- but one of us needs to build it.
> >>>
> >>> > Option 1 seems simple-est, but installing freetype requires more 
> than
> >>> > ./configure && make && sudo make install.
> >>>
> >>> darn. But hopefully we can figure it out.
> >>>
> >>> > Option 4: This would require some input from whoever (Gohlke?, 
> Owen?) makes
> >>> > the binary installers.
> >>>
> >>> I think Russell has been doing it for MPL lately.
> >>>
> >>> My thoughts:
> >>>
> >>> We want to support two user-bases:
> >>>
> >>> 1) folks that don't mind a little command line work, and probably need
> >>> other scientific libs, etc anyway, an want an MPL that runs on their
> >>> machine:
> >>>    - these folks should use homebrew or macports to build the
> >>> dependencies (or even hand-compile them). Ideally we have setup.py
> >>> that will find those libs, and test to see that the builds work once
> >>> in a while.
> >>>
> >>> 2) folks that "just want to use it" and/or want a binary they can
> >>> re-distribute via py2app, etc.
> >>>   - for these folks, we need to provide binaries. These binaries 
> should:
> >>>    1) Match the python.org <http://python.org> python builds. 
> (probably only the Intel ones now...)
> >>>    2) statically link the non-sytem libs
> >>>
> >>> This has been done for a while, off and on, most recently by 
> Russell, AFAIK.
> >>>
> >>> But this is not a problem unique to MPL. All sorts of python packages
> >>> need this, and only some of the package maintainers do it (well).
> >>> Also, a bunch of packages require the same dependencies (i.e. PIL and
> >>> MPL both need png and freetype)
> >>>
> >>> So, rather than re-inventing the wheel over and over again, It would
> >>> be great to have a central repository where we can develop build
> >>> scripts, etc that share an infrustructure for building these binaries.
> >>>
> >>> I've started one:
> >>>
> >>> https://github.com/MacPython/mac-builds
> >>>
> >>> there is not much there, only a couple things I'm working on at the
> >>> moment (netCDF4, which is of interest to scipy folks, and py_gd, which
> >>> is my own simple drawing lib, that no one else uses (yet?)
> >>>
> >>> If anyone wants to join the project let me know -- if I know you from
> >>> your work with this community, I'll gladly add you.
> >>>
> >>> I'm using the gattai build system:
> >>> (https://sourceforge.net/projects/gattai/). I decided to do that, as I
> >>> was sick of re-writing essentially the same build scripts, and I kept
> >>> adding features to mine that would have resulted in re-implementing
> >>> gattai anyway. I've been hacking at gattai, and its author is quite
> >>> open to moving it forward.
> >>>
> >>> That being said, there is no reason that we need to use the same build
> >>> system -- we could easily have custom build scripts for a project, and
> >>> still have it share the dependencies.
> >>>
> >>> I was planning on getting it all further along before announcing the
> >>> project and looking for help, but since is came up...
> >>>
> >>> -Chris
> >>>
> >>> --
> >>>
> >>> Christopher Barker, Ph.D.
> >>> Oceanographer
> >>>
> >>> Emergency Response Division
> >>> NOAA/NOS/OR&R            (206) 526-6959   voice
> >>> 7600 Sand Point Way NE   (206) 526-6329   fax
> >>> Seattle, WA  98115       (206) 526-6317   main reception
> >>>
> >>> Chr...@no... <mailto:Chr...@no...>
> >>>
> >>> 
> ------------------------------------------------------------------------------
> >>> Introducing Performance Central, a new site from SourceForge and
> >>> AppDynamics. Performance Central is your source for news, insights,
> >>> analysis and resources for efficient Application Performance 
> Management.
> >>> Visit us today!
> >>> 
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> >>> _______________________________________________
> >>> Matplotlib-users mailing list
> >>> Mat...@li... 
> <mailto:Mat...@li...>
> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >>
> >>
> >>
> >> 
> ------------------------------------------------------------------------------
> >> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> >> Discover the easy way to master current and previous Microsoft 
> technologies
> >> and advance your career. Get an incredible 1,500+ hours of step-by-step
> >> tutorial videos with LearnDevNow. Subscribe today and save!
> >> 
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> >>
> >> _______________________________________________
> >> Matplotlib-users mailing list
> >> Mat...@li... 
> <mailto:Mat...@li...>
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >>
> >
>
>
>
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi Eric,

Le 29/08/2013 19:51, Eric Frederich a écrit :
> I took the example that ships with 1.3.0 and have modified it to use a
> grid layout and show 9 graphs in a 3x3 grid.
> When I do this it, other widgets become rather unresponsive.
> Is there a way to fix this?
> Somehow offload whatever is hogging CPU onto another thread or something?
I just ran your code on my computer and I don't get the unresponsive
widgets problem. The program takes 6% of one CPU.

Yet the slider is not totally fluid. It gets better if I slowdown the
plot update timer.

Do you run your code on a powerful computer ?

best,
Pierre