matplotlib-devel Mailing List for matplotlib

Andrew,
Another issue.
The zorder of the spine artists is set to 0 by default.
I notice that you're changing the zorder of its artist attribute, but
note that it has no effect as what matter is the zorder of the spine
itself.
As a related issue to what John mentioned, I think one option you can
do is to derive the Spine class itself from a real artist class,
rather than the base "Artist". With this, you don't need to implement
all other set/get method, e.g., color, etc. For example, you may
derive it from the Patch class. Note that while the Patch class is
intended for closed path, you can stroke a straight line with it.
Regards,
-JJ
On Thu, May 28, 2009 at 9:18 PM, John Hunter <jd...@gm...> wrote:
> On Wed, May 27, 2009 at 11:33 AM, Andrew Straw <str...@as...> wrote:
>> I've gone ahead and committed my arbitrary spine location implementation
>> to the trunk (svn r7144). I'd appreciate it if you could kick the tires.
>> To get you started, try the new demo:
>> examples/pylab_examples/spine_placement_demo.py
>
> I just did a quick read through of the spine code and example, and
> have two minor comments.
>
> You do an isinstance(arg, basestring) to check for string input.
> Typically, we encourage cbook.is_string_like to have a central point
> of maintenance and consistency for these checks.
>
> Also, in the example, you appear to turn off a spine by setting the
> color to 'none'. My thought it would be more natural to use the
> "visible" artist property here (or at least support both)
>
>  @allow_rasterization
>  def draw(self,renderer):
>    "draw everything that belongs to the spine"
>    if not self.get_visible() or self.color.lower()=='none' or not
> self.color:
>      # don't draw invisible spines
>      return
>    self.artist.draw(renderer)
>
> Also, I think the class of strings representing "no color" in mpl is
> larger -- it should also include self.color.lower()=='none' and the
> empty string, which I've included in the example code.
>
> JDH
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Fri, May 29, 2009 at 9:44 PM, Petr Marhoun <pet...@gm...> wrote:
> Hello,
>
> Few days ago there were new windows binaries on Sourceforge - version
> 0.98.5.3. Yesterday I also found them in Google cache (see the
> attachment - I am interested mainly in Python 2.6).
>
> But they are not now on Sourceforge. Is there a good reason for it
> (for example there could be problematic)? Or is it a Sourceforge
> mistake (I am not sure but I think that design of the Sourceforge
> download page was different)?
>
> Maybe there is another explanation - but if it is possible, could
> windows binaries be uploaded again?
The 0.98.5.3 binaries have a problem with the PNG output, so I pulled
them. Charile, do you still have the 0.98.5.2 win32 binaries to
reupload while we are sorting out this problem?
JDH

Hello,
Few days ago there were new windows binaries on Sourceforge - version
0.98.5.3. Yesterday I also found them in Google cache (see the
attachment - I am interested mainly in Python 2.6).
But they are not now on Sourceforge. Is there a good reason for it
(for example there could be problematic)? Or is it a Sourceforge
mistake (I am not sure but I think that design of the Sourceforge
download page was different)?
Maybe there is another explanation - but if it is possible, could
windows binaries be uploaded again?
Thank you,
Petr Marhoun

We still require only gtk 2.2, and consequently carry around some extra 
chunks of code to support versions before 2.4. Can we drop this and 
require 2.4 or later? Or possibly even a later version? It looks like 
2.4 came out in the fall of 2004.
Eric

I've found pyparsing rather brittle between revisions in the past, hence 
the desire to have a local copy. I don't know if recent versions have 
stabilized -- given that we have something that works, I'm not too keen 
on tinkering with it. 
Not knowing much about packaging myself, I think Debian should only go 
forward with using an external dependency if an *exact* version of 
pyparsing can be specified, rather than >=. Or at the very least, if a 
different version of pyparsing is applied, one needs to make sure that 
the mathtext examples all pass unchanged.
Mike
Sandro Tosi wrote:
> Hi guys,
>
> On Fri, May 29, 2009 at 11:51, Daniel Watkins
> <da...@da...> wrote:
> 
>> Package: python-matplotlib
>> Version: 0.98.3-5
>> Severity: normal
>>
>> python-matplotlib installs its own copy of pyparsing.py when it should
>> in fact be using the copy that is shipped in python-pyparsing.
>> 
>
> We've just receive this bug report about the internal copy of
> pyparsing included in mpl.
>
> The situation in Debian is:
>
> Stable 	 1.5.0-1
> Testing 	1.5.1-2
> Unstable 	1.5.2-1
>
> Currently mpl ship:
>
> $ grep "^__version" lib/matplotlib/pyparsing.py
> __version__ = "1.5.0"
> __versionTime__ = "28 May 2008 10:05"
>
> In the changelog I can see:
>
> $ egrep -A2 "2007-11-09.*pyparsing" CHANGELOG
> 2007年11月09日 Moved pyparsing back into matplotlib namespace. Don't use
> system pyparsing, API is too variable from one release
> to the next - DSD
>
> So there seems to be a reason for this "private" copy. The question
> is: is this reason still valid nowdays? should we (at least packagers)
> remove the private copy and rely on the system pyparsing (or at least
> introduce a "check if system has pyparsing, if not fallback on
> private" wrap)?
>
> I haven't checked, but maybe you already know the answer :)
>
> Cheers,
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi guys,
On Fri, May 29, 2009 at 11:51, Daniel Watkins
<da...@da...> wrote:
> Package: python-matplotlib
> Version: 0.98.3-5
> Severity: normal
>
> python-matplotlib installs its own copy of pyparsing.py when it should
> in fact be using the copy that is shipped in python-pyparsing.
We've just receive this bug report about the internal copy of
pyparsing included in mpl.
The situation in Debian is:
Stable 	 1.5.0-1
Testing 	1.5.1-2
Unstable 	1.5.2-1
Currently mpl ship:
$ grep "^__version" lib/matplotlib/pyparsing.py
__version__ = "1.5.0"
__versionTime__ = "28 May 2008 10:05"
In the changelog I can see:
$ egrep -A2 "2007-11-09.*pyparsing" CHANGELOG
2007年11月09日 Moved pyparsing back into matplotlib namespace. Don't use
 system pyparsing, API is too variable from one release
 to the next - DSD
So there seems to be a reason for this "private" copy. The question
is: is this reason still valid nowdays? should we (at least packagers)
remove the private copy and rely on the system pyparsing (or at least
introduce a "check if system has pyparsing, if not fallback on
private" wrap)?
I haven't checked, but maybe you already know the answer :)
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

The axes_grid examples, broken by the recent spine patch, are now
fixed in the svn.
Also, when I commit axes_grid toolkit into the trunk, I deleted a few
example under examples/pylab_examples. For example, axes_divider.py in
the error message below has been deleted.
IOError: [Errno 2] No such file or directory: 'axes_divider.py'
The doc build script somehow still try to run those script. I'll try
to look into what's going on later. If others know any trivial
solution, please go ahead and fix it.
▶◀
-JJ
On Thu, May 28, 2009 at 10:51 PM, John Hunter <jd...@gm...> wrote:
> I was just updating the site docs and a few examples are failing to
> build. Some of these are easy pickens, so if you have a quick fix,
> please put it in, and reply here when you've fixed one to avoid
> duplication of effort.
>
> JDH
>
> ================================
> File "geo_demo.py", line 9, in <module>
> File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/pyplot.py",
> line 645, in subplot
>  a = fig.add_subplot(*args, **kwargs)
> File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/figure.py",
> line 690, in add_subplot
>  a = subplot_class_factory(projection_class)(self, *args, **kwargs)
> File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/axes.py",
> line 7844, in __init__
>  self._axes_class.__init__(self, fig, self.figbox, **kwargs)
> File "custom_projection_example.py", line 35, in __init__
> File "custom_projection_example.py", line 50, in cla
> AttributeError: 'NoneType' object has no attribute 'cla'
>
> ============================================
>
> File "finance_work2.py", line 36, in <module>
> File "/usr/lib/python2.5/optparse.py", line 1387, in parse_args
>  self.error(str(err))
> File "/usr/lib/python2.5/optparse.py", line 1569, in error
>  self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg))
> File "/usr/lib/python2.5/optparse.py", line 1559, in exit
>  sys.exit(status)
> SystemExit: 2
>
>
> ===============================================
>
> directive.py", line 206, in makefig
>  runfile(fullpath)
> File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/sphinxext/plot_directive.py",
> line 141, in runfile
>  fd = open(fname)
> IOError: [Errno 2] No such file or directory: 'anchored_text.py'
>
> warnings.warn(s)
> examples/pylab_examples/annotation_demo
> *********examples/pylab_examples/annotation_demo2
> ......examples/pylab_examples/anscombe
> ***examples/pylab_examples/arctest
> ***examples/pylab_examples/arrow_demo
> ...examples/pylab_examples/aspect_loglog
> ***examples/pylab_examples/axes_demo
> ***examples/pylab_examples/axes_divider
> /home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/sphinxext/plot_directive.py:209:
> UserWarning: Exception running plot
> /home/jdhunter/mpl/doc/mpl_examples/pylab_examples/axes_divider.py
> Traceback (most recent call last):
> File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/sphinxext/plot_directive.py",
> line 206, in makefig
>  runfile(fullpath)
> File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/sphinxext/plot_directive.py",
> line 141, in runfile
>  fd = open(fname)
> IOError: [Errno 2] No such file or directory: 'axes_divider.py'
>
> warnings.warn(s)
> examples/pylab_examples/axes_grid
> /home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/sphinxext/plot_directive.py:209:
> UserWarning: Exception running plot
> /home/jdhunter/mpl/doc/mpl_examples/pylab_examples/axes_grid.py
> Traceback (most recent call last):
> File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/sphinxext/plot_directive.py",
> line 206, in makefig
>  runfile(fullpath)
> File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/sphinxext/plot_directive.py",
> line 141, in runfile
>  fd = open(fname)
> IOError: [Errno 2] No such file or directory: 'axes_grid.py'
>
> warnings.warn(s)
>
> =================================================
>
>
> File "parasite_simple.py", line 6, in <module>
> File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/axes.py",
> line 7844, in __init__
>  self._axes_class.__init__(self, fig, self.figbox, **kwargs)
> File "/home/jdhunter/dev/lib/python2.5/site-packages/mpl_toolkits/axes_grid/parasite_axes.py",
> line 189, in __init__
>  super(HostAxes, self).__init__(*kl, **kwargs)
> File "/home/jdhunter/dev/lib/python2.5/site-packages/mpl_toolkits/axes_grid/axislines.py",
> line 1244, in __init__
>  self.toggle_axisline(True)
> File "/home/jdhunter/dev/lib/python2.5/site-packages/mpl_toolkits/axes_grid/axislines.py",
> line 1252, in toggle_axisline
>  self.frame.set_visible(False)
> File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/axes.py",
> line 988, in get_frame
>  raise AttributeError('Axes.frame was removed in favor of Axes.spines')
> AttributeError: Axes.frame was removed in favor of Axes.spines
>
>
> ...and lots more like these for axes_grid
>
> ===========================================================
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

John Hunter wrote:
> I was just updating the site docs and a few examples are failing to
> build. Some of these are easy pickens, so if you have a quick fix,
> please put it in, and reply here when you've fixed one to avoid
> duplication of effort.
If you can coerce the recipe I sent this list on May 20 for running the
unit tests to run these as well, we'll see these sooner. Furthermore,
I've been busy with the spines, but I think we should check in new
baseline images in the test suite so that the builtbot waterfall goes green.
-Andrew

I was just updating the site docs and a few examples are failing to
build. Some of these are easy pickens, so if you have a quick fix,
please put it in, and reply here when you've fixed one to avoid
duplication of effort.
JDH
================================
 File "geo_demo.py", line 9, in <module>
 File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/pyplot.py",
line 645, in subplot
 a = fig.add_subplot(*args, **kwargs)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/figure.py",
line 690, in add_subplot
 a = subplot_class_factory(projection_class)(self, *args, **kwargs)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/axes.py",
line 7844, in __init__
 self._axes_class.__init__(self, fig, self.figbox, **kwargs)
 File "custom_projection_example.py", line 35, in __init__
 File "custom_projection_example.py", line 50, in cla
AttributeError: 'NoneType' object has no attribute 'cla'
============================================
 File "finance_work2.py", line 36, in <module>
 File "/usr/lib/python2.5/optparse.py", line 1387, in parse_args
 self.error(str(err))
 File "/usr/lib/python2.5/optparse.py", line 1569, in error
 self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg))
 File "/usr/lib/python2.5/optparse.py", line 1559, in exit
 sys.exit(status)
SystemExit: 2
===============================================
directive.py", line 206, in makefig
 runfile(fullpath)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/sphinxext/plot_directive.py",
line 141, in runfile
 fd = open(fname)
IOError: [Errno 2] No such file or directory: 'anchored_text.py'
 warnings.warn(s)
examples/pylab_examples/annotation_demo
*********examples/pylab_examples/annotation_demo2
......examples/pylab_examples/anscombe
***examples/pylab_examples/arctest
***examples/pylab_examples/arrow_demo
...examples/pylab_examples/aspect_loglog
***examples/pylab_examples/axes_demo
***examples/pylab_examples/axes_divider
/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/sphinxext/plot_directive.py:209:
UserWarning: Exception running plot
/home/jdhunter/mpl/doc/mpl_examples/pylab_examples/axes_divider.py
Traceback (most recent call last):
 File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/sphinxext/plot_directive.py",
line 206, in makefig
 runfile(fullpath)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/sphinxext/plot_directive.py",
line 141, in runfile
 fd = open(fname)
IOError: [Errno 2] No such file or directory: 'axes_divider.py'
 warnings.warn(s)
examples/pylab_examples/axes_grid
/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/sphinxext/plot_directive.py:209:
UserWarning: Exception running plot
/home/jdhunter/mpl/doc/mpl_examples/pylab_examples/axes_grid.py
Traceback (most recent call last):
 File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/sphinxext/plot_directive.py",
line 206, in makefig
 runfile(fullpath)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/sphinxext/plot_directive.py",
line 141, in runfile
 fd = open(fname)
IOError: [Errno 2] No such file or directory: 'axes_grid.py'
 warnings.warn(s)
=================================================
 File "parasite_simple.py", line 6, in <module>
 File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/axes.py",
line 7844, in __init__
 self._axes_class.__init__(self, fig, self.figbox, **kwargs)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/mpl_toolkits/axes_grid/parasite_axes.py",
line 189, in __init__
 super(HostAxes, self).__init__(*kl, **kwargs)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/mpl_toolkits/axes_grid/axislines.py",
line 1244, in __init__
 self.toggle_axisline(True)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/mpl_toolkits/axes_grid/axislines.py",
line 1252, in toggle_axisline
 self.frame.set_visible(False)
 File "/home/jdhunter/dev/lib/python2.5/site-packages/matplotlib/axes.py",
line 988, in get_frame
 raise AttributeError('Axes.frame was removed in favor of Axes.spines')
AttributeError: Axes.frame was removed in favor of Axes.spines
...and lots more like these for axes_grid
===========================================================

On Wed, May 27, 2009 at 11:33 AM, Andrew Straw <str...@as...> wrote:
> I've gone ahead and committed my arbitrary spine location implementation
> to the trunk (svn r7144). I'd appreciate it if you could kick the tires.
> To get you started, try the new demo:
> examples/pylab_examples/spine_placement_demo.py
I just did a quick read through of the spine code and example, and
have two minor comments.
You do an isinstance(arg, basestring) to check for string input.
Typically, we encourage cbook.is_string_like to have a central point
of maintenance and consistency for these checks.
Also, in the example, you appear to turn off a spine by setting the
color to 'none'. My thought it would be more natural to use the
"visible" artist property here (or at least support both)
 @allow_rasterization
 def draw(self,renderer):
 "draw everything that belongs to the spine"
 if not self.get_visible() or self.color.lower()=='none' or not
self.color:
 # don't draw invisible spines
 return
 self.artist.draw(renderer)
Also, I think the class of strings representing "no color" in mpl is
larger -- it should also include self.color.lower()=='none' and the
empty string, which I've included in the example code.
JDH

On Thu, May 28, 2009 at 3:32 PM, Reinier Heeres <re...@he...> wrote:
> Hi all,
>
> While trying to work on some docs for mplot3d I ran into trouble
> building them. I started with the stock ubuntu sphinx (0.5.2), but
> that ran into errors. Following the documentation suggestion I tried
> the repository at http://svn.python.org/projects/doctools/trunk
> sphinx, but that seems to be deprecated (and also didn't work for me).
> Apparently the new location is a mercurial repo at
> http://bitbucket.org/birkenfeld/sphinx/ and that's a version that did
> the trick for me.
>
Hey Reiner,
I just did an svn up and noticed the new examples for mplot3d --
thanks for adding these. May I suggest you rename them? Having file
names like contour, when mpl has a module contour, can lead to subtle
import bugs. We try and avoid these by doing fully qualified imports
inside mpl like 'import matplotlib.contour as contour' but to keep
things clear and simple I like to post fix '_demo' or something like
that on examples when the same is potentially ambiguous. Some
something like
contour3d_demo.py, scatter3d_demo.py, etc, would be preferable to me
to clearly disambiguate the modules and examples, with judicious use
of 3d to make it clear what the examples are.
Thanks,
JDH

On Thu, May 28, 2009 at 3:32 PM, Reinier Heeres <re...@he...> wrote:
> Hi all,
>
> While trying to work on some docs for mplot3d I ran into trouble
> building them. I started with the stock ubuntu sphinx (0.5.2), but
> that ran into errors. Following the documentation suggestion I tried
> the repository at http://svn.python.org/projects/doctools/trunk
> sphinx, but that seems to be deprecated (and also didn't work for me).
> Apparently the new location is a mercurial repo at
> http://bitbucket.org/birkenfeld/sphinx/ and that's a version that did
> the trick for me.
>
> My guess is people knew this already, but shall I update the docs with
> this new repo? It will be easier for new people to get the docs built.
By all means the current docs should be updated with anything that
makes it easier for new users. I often forget this stuff in the
intervals between when I have to set up new development stations, so
having easy step-by-step instructions with command lines to paste into
the shell is a definite plus
JDH

Reinier Heeres wrote:
> Hi all,
> 
> While trying to work on some docs for mplot3d I ran into trouble
> building them. I started with the stock ubuntu sphinx (0.5.2), but
> that ran into errors. Following the documentation suggestion I tried
> the repository at http://svn.python.org/projects/doctools/trunk
> sphinx, but that seems to be deprecated (and also didn't work for me).
> Apparently the new location is a mercurial repo at
> http://bitbucket.org/birkenfeld/sphinx/ and that's a version that did
> the trick for me.
> 
> My guess is people knew this already, but shall I update the docs with
> this new repo? It will be easier for new people to get the docs built.
Yes, please do.
Eric

Hi all,
While trying to work on some docs for mplot3d I ran into trouble
building them. I started with the stock ubuntu sphinx (0.5.2), but
that ran into errors. Following the documentation suggestion I tried
the repository at http://svn.python.org/projects/doctools/trunk
sphinx, but that seems to be deprecated (and also didn't work for me).
Apparently the new location is a mercurial repo at
http://bitbucket.org/birkenfeld/sphinx/ and that's a version that did
the trick for me.
My guess is people knew this already, but shall I update the docs with
this new repo? It will be easier for new people to get the docs built.
Regards,
-- 
Reinier Heeres
Bleijenburg 64
2511 VD Den Haag
The Netherlands
Tel: +31 6 10852639

On Thu, May 28, 2009 at 10:01 AM, John Hunter <jd...@gm...> wrote:
> On Thu, May 28, 2009 at 9:57 AM, Charlie Moad <cw...@gm...> wrote:
>
>> I'll have to check my home computer tonight. I never saw your note
>> about libpng either. Again, I'll poke a little more tonight once I
>> get home to my machine and update you.
>
> The debugger indicates the dreaded mscvrt is still in the binaries,
> despite your monkey patch. The only reference to that file in
> distutils cygwincompiler is::
>
>    # cygwin and mingw32 need different sets of libraries
>    if self.gcc_version == "2.91.57":
>      # cygwin shouldn't need msvcrt, but without the dlls will crash
>      # (gcc version 2.91.57) -- perhaps something about initialization
>      self.dll_libraries=["msvcrt"]
>      self.warn(
>        "Consider upgrading to a newer version of gcc")
>    else:
>      # Include the appropriate MSVC runtime library if Python was built
>      # with MSVC 7.0 or later.
>      self.dll_libraries = get_msvcr()
>
> we shouldn't be matching that version string, and your monkey patch
> *should* be overriding get_msvcr, but it is still getting in there.
> Try in the matplotlib-0.98.6svn dir::
>
> > grep -ri mscvrt .
>
> I get the following listing::
>
> Binary file ./build/lib.win32-2.6/matplotlib/backends/_backend_agg.pyd matches
> Binary file ./build/lib.win32-2.6/matplotlib/backends/_tkagg.pyd matches
> Binary file ./build/lib.win32-2.6/matplotlib/ft2font.pyd matches
> Binary file ./build/lib.win32-2.6/matplotlib/nxutils.pyd matches
> Binary file ./build/lib.win32-2.6/matplotlib/ttconv.pyd matches
> Binary file ./build/lib.win32-2.6/matplotlib/_cntr.pyd matches
> Binary file ./build/lib.win32-2.6/matplotlib/_delaunay.pyd matches
> Binary file ./build/lib.win32-2.6/matplotlib/_image.pyd matches
> Binary file ./build/lib.win32-2.6/matplotlib/_path.pyd matches
> Binary file ./build/lib.win32-2.6/matplotlib/_png.pyd matches
> Binary file ./build/lib.win32-2.6/matplotlib/_windowing.pyd matches
Hmm, not sure if this msvcrt is a red-herring or not. We may be
getting it by virtue of linking with numpy. If I run the same grep on
the numpy install from the 1.3.0 numpy binary, I get
Binary file ./core/multiarray.pyd matches
Binary file ./core/scalarmath.pyd matches
Binary file ./core/umath.pyd matches
Binary file ./core/umath_tests.pyd matches
Binary file ./core/_dotblas.pyd matches
Binary file ./core/_sort.pyd matches
./distutils/mingw32ccompiler.py: # with MSVC >= 7.0 (MinGW
standard is msvcrt)
./distutils/mingw32ccompiler.py: import msvcrt
./distutils/mingw32ccompiler.py: if hasattr(msvcrt,
"CRT_ASSEMBLY_VERSION"):
./distutils/mingw32ccompiler.py: _MSVCRVER_TO_FULLVER['90']
= msvcrt.CRT_ASSEMBLY_VERSION
./distutils/mingw32ccompiler.py: log.warn('Cannot import
msvcrt: using manifest will not be possible')
./distutils/mingw32ccompiler.py: raise ValueError("Version
%d,%d of MSVCRT not supported yet" \
Binary file ./distutils/mingw32ccompiler.pyc matches
Binary file ./distutils/mingw32ccompiler.pyo matches
Binary file ./fft/fftpack_lite.pyd matches
Binary file ./lib/_compiled_base.pyd matches
Binary file ./linalg/lapack_lite.pyd matches
Binary file ./numarray/_capi.pyd matches
./numpy.out:./distutils/mingw32ccompiler.py: # with MSVC >= 7.0
(MinGW standard is msvcrt)
./numpy.out:./distutils/mingw32ccompiler.py: import msvcrt
./numpy.out:./distutils/mingw32ccompiler.py: if hasattr(msvcrt,
"CRT_ASSEMBLY_VERSION"):
./numpy.out:./distutils/mingw32ccompiler.py:
_MSVCRVER_TO_FULLVER['90'] = msvcrt.CRT_ASSEMBLY_VERSION
./numpy.out:./distutils/mingw32ccompiler.py: log.warn('Cannot
import msvcrt: using manifest will not be possible')
./numpy.out:./distutils/mingw32ccompiler.py: raise
ValueError("Version %d,%d of MSVCRT not supported yet" \
Binary file ./random/mtrand.pyd matches
Sometimes these missing dlls are not the true cause of the segfault....
JDH

On Thu, May 28, 2009 at 9:57 AM, Charlie Moad <cw...@gm...> wrote:
> I'll have to check my home computer tonight. I never saw your note
> about libpng either. Again, I'll poke a little more tonight once I
> get home to my machine and update you.
The debugger indicates the dreaded mscvrt is still in the binaries,
despite your monkey patch. The only reference to that file in
distutils cygwincompiler is::
 # cygwin and mingw32 need different sets of libraries
 if self.gcc_version == "2.91.57":
 # cygwin shouldn't need msvcrt, but without the dlls will crash
 # (gcc version 2.91.57) -- perhaps something about initialization
 self.dll_libraries=["msvcrt"]
 self.warn(
 "Consider upgrading to a newer version of gcc")
 else:
 # Include the appropriate MSVC runtime library if Python was built
 # with MSVC 7.0 or later.
 self.dll_libraries = get_msvcr()
we shouldn't be matching that version string, and your monkey patch
*should* be overriding get_msvcr, but it is still getting in there.
Try in the matplotlib-0.98.6svn dir::
 > grep -ri mscvrt .
I get the following listing::
Binary file ./build/lib.win32-2.6/matplotlib/backends/_backend_agg.pyd matches
Binary file ./build/lib.win32-2.6/matplotlib/backends/_tkagg.pyd matches
Binary file ./build/lib.win32-2.6/matplotlib/ft2font.pyd matches
Binary file ./build/lib.win32-2.6/matplotlib/nxutils.pyd matches
Binary file ./build/lib.win32-2.6/matplotlib/ttconv.pyd matches
Binary file ./build/lib.win32-2.6/matplotlib/_cntr.pyd matches
Binary file ./build/lib.win32-2.6/matplotlib/_delaunay.pyd matches
Binary file ./build/lib.win32-2.6/matplotlib/_image.pyd matches
Binary file ./build/lib.win32-2.6/matplotlib/_path.pyd matches
Binary file ./build/lib.win32-2.6/matplotlib/_png.pyd matches
Binary file ./build/lib.win32-2.6/matplotlib/_windowing.pyd matches
JDH

On Thu, May 28, 2009 at 10:52 AM, John Hunter <jd...@gm...> wrote:
> On Thu, May 28, 2009 at 9:37 AM, Charlie Moad <cw...@gm...> wrote:
>
>> I think setuptools should be a requirement in the same way numpy is.
>>
>> The latest "ez_setup.py" script has 2.6 included.
>> http://peak.telecommunity.com/dist/ez_setup.py
>>
>> You should be able to do the normal, "python ez_setup.py"
>
> OK, I got the thing to build and updated the README with instructions
> for dummies like me. I tested the install and we are still getting
> the libpng triggered segfault. I removed the win32 binaries from the
> website yesterday since they showed the same problem. So now we have
> to drill into this problem. Do you recall what version of libpng you
> used for the 98.5.2 builds. I may try regressing and see if that
> helps.
I'll have to check my home computer tonight. I never saw your note
about libpng either. Again, I'll poke a little more tonight once I
get home to my machine and update you.
- Charlie

On Thu, May 28, 2009 at 9:37 AM, Charlie Moad <cw...@gm...> wrote:
> I think setuptools should be a requirement in the same way numpy is.
>
> The latest "ez_setup.py" script has 2.6 included.
> http://peak.telecommunity.com/dist/ez_setup.py
>
> You should be able to do the normal, "python ez_setup.py"
OK, I got the thing to build and updated the README with instructions
for dummies like me. I tested the install and we are still getting
the libpng triggered segfault. I removed the win32 binaries from the
website yesterday since they showed the same problem. So now we have
to drill into this problem. Do you recall what version of libpng you
used for the 98.5.2 builds. I may try regressing and see if that
helps.
JDH

On Thu, May 28, 2009 at 10:34 AM, John Hunter <jd...@gm...> wrote:
> On Thu, May 28, 2009 at 9:25 AM, John Hunter <jd...@gm...> wrote:
>> On Thu, May 28, 2009 at 9:06 AM, John Hunter <jd...@gm...> wrote:
>>> On Thu, May 28, 2009 at 8:57 AM, Charlie Moad <cw...@gm...> wrote:
>>>> Another note. I ran into problems when trying to create the build in
>>>> a directory that had spaces. (e.g. C:\Documents and Settings\....).
>>>> Try running everything in a top level dir.
>>>
>>> That's not it -- I avoid spaces like the plague.
>>>
>>> I am now getting a "cannot exec 'cc1plus'" error when I try and build
>>> mpl itself (zlib, png, freetype and tcltl built fine). I can do::
>>>
>>> > gcc --version
>>>
>>> but not::
>>>
>>> > g++ --version
>>>
>>> Did you install something extra for g++ -- I installed mingw 5.1.4,
>>> MSYS and wget as instructed....)
>>
>> Never mind -- just reran the mingw-5.1.4.exe installer and it prompted
>> me for additional compilers. I selected g++ and now I have it
>
> Now I am hitting a missing setuptools import from setupwinegg.py.
> Apparently python2.6 doesn't come with setuptools on windows (Is this
> expected? It surprised me, I thought setuptools was supposed to be a
> standard....)
>
> Anyhow, a quick google takes me to
>
> http://www.python-forum.org/pythonforum/viewtopic.php?f=15&t=10175
>
> which suggests
>
> 1. Download setuptools-0.6c9.tar.gz
> 2. Download setuptools-0.6c9-py2.6.egg to a folder(directory) outside
> your Windows Python installation folder
> 3. Use 7-zip to extract ez_setup.py in the same folder as
> setuptools-0.6c9-py2.6.egg
> 4. Go to the corresponding dos prompt and run python ez_setup.py
> setuptools-0.6c9-py2.6.egg from the command prompt
> 5. Ensure that your PATH includes the appropriate C:\Python2X\Scripts directory
>
> Is this really the path of least resistance? Whatever happened to the
> easy in ez_setup....
I think setuptools should be a requirement in the same way numpy is.
The latest "ez_setup.py" script has 2.6 included.
http://peak.telecommunity.com/dist/ez_setup.py
You should be able to do the normal, "python ez_setup.py"

On Thu, May 28, 2009 at 10:25 AM, John Hunter <jd...@gm...> wrote:
> On Thu, May 28, 2009 at 9:06 AM, John Hunter <jd...@gm...> wrote:
>> On Thu, May 28, 2009 at 8:57 AM, Charlie Moad <cw...@gm...> wrote:
>>> Another note. I ran into problems when trying to create the build in
>>> a directory that had spaces. (e.g. C:\Documents and Settings\....).
>>> Try running everything in a top level dir.
>>
>> That's not it -- I avoid spaces like the plague.
>>
>> I am now getting a "cannot exec 'cc1plus'" error when I try and build
>> mpl itself (zlib, png, freetype and tcltl built fine). I can do::
>>
>> > gcc --version
>>
>> but not::
>>
>> > g++ --version
>>
>> Did you install something extra for g++ -- I installed mingw 5.1.4,
>> MSYS and wget as instructed....)
>
> Never mind -- just reran the mingw-5.1.4.exe installer and it prompted
> me for additional compilers. I selected g++ and now I have it
You found it. That's probably worth adding to the readme as well as
the "spaces in build path" issue. I think I did add some comments
after testing, btw.

On Thu, May 28, 2009 at 9:25 AM, John Hunter <jd...@gm...> wrote:
> On Thu, May 28, 2009 at 9:06 AM, John Hunter <jd...@gm...> wrote:
>> On Thu, May 28, 2009 at 8:57 AM, Charlie Moad <cw...@gm...> wrote:
>>> Another note. I ran into problems when trying to create the build in
>>> a directory that had spaces. (e.g. C:\Documents and Settings\....).
>>> Try running everything in a top level dir.
>>
>> That's not it -- I avoid spaces like the plague.
>>
>> I am now getting a "cannot exec 'cc1plus'" error when I try and build
>> mpl itself (zlib, png, freetype and tcltl built fine). I can do::
>>
>> > gcc --version
>>
>> but not::
>>
>> > g++ --version
>>
>> Did you install something extra for g++ -- I installed mingw 5.1.4,
>> MSYS and wget as instructed....)
>
> Never mind -- just reran the mingw-5.1.4.exe installer and it prompted
> me for additional compilers. I selected g++ and now I have it
Now I am hitting a missing setuptools import from setupwinegg.py.
Apparently python2.6 doesn't come with setuptools on windows (Is this
expected? It surprised me, I thought setuptools was supposed to be a
standard....)
Anyhow, a quick google takes me to
http://www.python-forum.org/pythonforum/viewtopic.php?f=15&t=10175
which suggests
1. Download setuptools-0.6c9.tar.gz
2. Download setuptools-0.6c9-py2.6.egg to a folder(directory) outside
your Windows Python installation folder
3. Use 7-zip to extract ez_setup.py in the same folder as
setuptools-0.6c9-py2.6.egg
4. Go to the corresponding dos prompt and run python ez_setup.py
setuptools-0.6c9-py2.6.egg from the command prompt
5. Ensure that your PATH includes the appropriate C:\Python2X\Scripts directory
Is this really the path of least resistance? Whatever happened to the
easy in ez_setup....
JDH

On Thu, May 28, 2009 at 9:06 AM, John Hunter <jd...@gm...> wrote:
> On Thu, May 28, 2009 at 8:57 AM, Charlie Moad <cw...@gm...> wrote:
>> Another note. I ran into problems when trying to create the build in
>> a directory that had spaces. (e.g. C:\Documents and Settings\....).
>> Try running everything in a top level dir.
>
> That's not it -- I avoid spaces like the plague.
>
> I am now getting a "cannot exec 'cc1plus'" error when I try and build
> mpl itself (zlib, png, freetype and tcltl built fine). I can do::
>
> > gcc --version
>
> but not::
>
> > g++ --version
>
> Did you install something extra for g++ -- I installed mingw 5.1.4,
> MSYS and wget as instructed....)
Never mind -- just reran the mingw-5.1.4.exe installer and it prompted
me for additional compilers. I selected g++ and now I have it
JDH

On Wed, May 27, 2009 at 11:08 PM, Charlie Moad <cw...@gm...> wrote:
> I've spent the last couple of days writing the win32 equivalent
> of John's osx release scripts for MinGW. It patches distutils at
> runtime to exclude the msvcr link, hence we should no longer need to
> modify distutils. I have tested it on Python 2.6 and it should work
> on 2.4 and 2.5 as well. It's too late for me to test those right now,
> but I trust they should work. Instructions can be found in
> release/win32/README.txt. It required removing a link to "gw32" in
> "setupext.py" so it only works trunk sdists. All interested, please
> give it a try.
I'm in the process of testing this -- one problem I encountered was
some trailing spaces after the version numbers and before the comments
which broke the build. nfortunately some of the compiler error
messages were fairly cryptic (c compiler cannot create executables)
which sent me down some false trails before I figured it out from the
libpng config.log. I've committed the fix (first use of tortoisesvn
-- woohoo).
My sdist command in mingw is creating zip files by default -- any way
to force it to make the tar.gz that the build script is expecting ? I
can hack around this by creating my own tarball.....
JDH

On Thu, May 28, 2009 at 8:57 AM, Charlie Moad <cw...@gm...> wrote:
> Another note. I ran into problems when trying to create the build in
> a directory that had spaces. (e.g. C:\Documents and Settings\....).
> Try running everything in a top level dir.
That's not it -- I avoid spaces like the plague.
I am now getting a "cannot exec 'cc1plus'" error when I try and build
mpl itself (zlib, png, freetype and tcltl built fine). I can do::
 > gcc --version
but not::
 > g++ --version
Did you install something extra for g++ -- I installed mingw 5.1.4,
MSYS and wget as instructed....)

On Thu, May 28, 2009 at 8:56 AM, Charlie Moad <cw...@gm...> wrote:
> It's strange that I didn't run into spacing issues.
>
> sdist --formats=gztar
Did you maybe add the comments after you had built the dependencies,
so that branch wasn't executed when you compiled?
Thanks for the sdist flag -- I'll update the README.
I forgot to say -- thanks a lot for doing this. It will be a
tremendous boon for windows users (and us) and should help us plug
win32 into the buildbot down the road. BTW, have you tested these
builds with the png save error I CCd you on earlier? I'll test when I
finish the build...
JDH