matplotlib-devel Mailing List for matplotlib

Hi Mike and John,
 I've got a question about the functionality about axes3d.plot_surface:
When I set the linewidths to 0 (in the patch I'm working on) I get an image looking like this:
http://static.ryanjwagner.com/mpl_patches/lw0.png
I don't think this looks correct to me, as I can still see the grid. I have a workaround in place so if linewidth=0 then the image looks like this:
http://static.ryanjwagner.com/mpl_patches/lw0_fix.png
Would you agree that this should be the expected functionality or should I leave this alone, or should it be a new keyword?
WRT to the previous conversation about the gradients, I have been wishing for that for a while myself, but I understand the difficulty in doing the interpolations. In my own work I end up interpolating the data much finer and it looks better since the polygons are so small you can't notice the single colored polys:
http://static.ryanjwagner.com/mpl_patches/animation.gif
But I think this looks even better now that I'm able to do it without the visible wiremesh.
-Ryan

> I think this happens in all mpl graphs, you just don't see it. The
> axis limits are set to -2..2, and the sine is draw from -2..2. The
> linewidth extends beyond 2, so it is clipped by the axes clipping to
> the bounding rectangle. Normally you don't see this, because visually
> it is under the surrounding axes black edge.
Yes, I saw that it looks like it happens under the axes clipping.
> You can either set the
> ylimits wider:
>
 ax.set_ylim(-2.1, 2.1)
>
But would this also make the spine have the larger limits? Basically, I
want know if the spines can be used to create Tufte-style range-frames. Am
I correct in thinking that these spines provide that? Or is there another
way to get a range-frame?
> or turn clipping off
>
> ax.plot(x,y, clip_on=False)
>
This looks hopeful and I will give it a shot.
Cheers,
Brian

On Thu, Aug 6, 2009 at 2:03 PM, John Hunter <jd...@gm...> wrote:
> On Thu, Aug 6, 2009 at 1:59 PM, Ryan May<rm...@gm...> wrote:
> > On Thu, Aug 6, 2009 at 1:55 PM, John Hunter <jd...@gm...> wrote:
> >>
> >> On Thu, Aug 6, 2009 at 1:50 PM, Ryan May<rm...@gm...> wrote:
> >> >
> >> > On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever <gok...@gm...>
> >> > wrote:
> >> >>
> >> >> Shouldn't colorbar_doc name be hidden from users? It doesn't look
> like
> >> >> the
> >> >> rest other function documentation in pyplot.py file.
> >> >>
> >> >> In [10]: color
> >> >> colorbar colorbar_doc colormaps colors
> >> >
> >> > Good catch. Fixed in 7406.
> >>
> >> Just reading this, it looks like you missed the import
> >> matplotlib.colorbar part, no? Or am I missing something?
> >
> > On my machine, the import didn't seem to be necessary.
> matplotlib.colorbar
> > is available just with:
> >
> > import matplotlib
>
> Strange...
>
> j> python
> Python 2.4.5 (#4, Apr 12 2008, 09:09:16)
> [GCC 3.4.1] on sunos5
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import matplotlib
> >>> matplotlib.colorbar
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> AttributeError: 'module' object has no attribute 'colorbar'
> >>> matplotlib.__version__
> '1.0.svn'
>
Stranger still (or it is to me):
Python 2.6.2 (r262:71600, Aug 3 2009, 10:34:14)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib
>>> matplotlib.colorbar
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'colorbar'
>>> from matplotlib import pyplot
>>> matplotlib.colorbar
<module 'matplotlib.colorbar' from
'/home/rmay/.local/lib/python2.6/site-packages/matplotlib/colorbar.pyc'>
>
> > Would it be better to explicitly import matplotlib.colorbar anyways?
>
> Yes
>
Clearly.
>> When possible, could you make bugfixes to the branch and merge to the
>> trunk? I know this is a bit of a hassle, but we often live on a
>> release branch for several bug fix release cycles, so it is nice to
>> put the simple fixes there
>>
>> http://matplotlib.sourceforge.net/devel/coding_guide.html
>
> Yeah, my bad. I just remembered after committing to trunk and was working
> on checking out the new branch and applying there when you made your fix.
> So what n ow?
Ahh, now the pain begins. I believe the easiest path is to put the
> change in the branch, svn commit, go over to the trunk, svnmerge,
> resolve any conflicts and commit. Now wasn't that easy?
I remember doing this before now. I don't think there will be any problems
with making the changes outside of svnmerge. The alternative is to change
trunk back and use svnmerge. I don't mind doing either. Got a preference
on which way to handle colorbar_doc?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States

On Thu, Aug 6, 2009 at 1:59 PM, Ryan May<rm...@gm...> wrote:
> On Thu, Aug 6, 2009 at 1:55 PM, John Hunter <jd...@gm...> wrote:
>>
>> On Thu, Aug 6, 2009 at 1:50 PM, Ryan May<rm...@gm...> wrote:
>> >
>> > On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever <gok...@gm...>
>> > wrote:
>> >>
>> >> Shouldn't colorbar_doc name be hidden from users? It doesn't look like
>> >> the
>> >> rest other function documentation in pyplot.py file.
>> >>
>> >> In [10]: color
>> >> colorbar   colorbar_doc colormaps   colors
>> >
>> > Good catch. Fixed in 7406.
>>
>> Just reading this, it looks like you missed the import
>> matplotlib.colorbar part, no? Or am I missing something?
>
> On my machine, the import didn't seem to be necessary. matplotlib.colorbar
> is available just with:
>
>   import matplotlib
Strange...
 j> python
 Python 2.4.5 (#4, Apr 12 2008, 09:09:16)
 [GCC 3.4.1] on sunos5
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import matplotlib
 >>> matplotlib.colorbar
 Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 AttributeError: 'module' object has no attribute 'colorbar'
 >>> matplotlib.__version__
 '1.0.svn'
> Would it be better to explicitly import matplotlib.colorbar anyways?
Yes
>> When possible, could you make bugfixes to the branch and merge to the
>> trunk? I know this is a bit of a hassle, but we often live on a
>> release branch for several bug fix release cycles, so it is nice to
>> put the simple fixes there
>>
>> http://matplotlib.sourceforge.net/devel/coding_guide.html
>
> Yeah, my bad. I just remembered after committing to trunk and was working
> on checking out the new branch and applying there when you made your fix.
> So what n ow?
Ahh, now the pain begins. I believe the easiest path is to put the
change in the branch, svn commit, go over to the trunk, svnmerge,
resolve any conflicts and commit. Now wasn't that easy?
JDH

On Thu, Aug 6, 2009 at 1:55 PM, John Hunter <jd...@gm...> wrote:
> On Thu, Aug 6, 2009 at 1:50 PM, Ryan May<rm...@gm...> wrote:
> >
> > On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever <gok...@gm...>
> wrote:
> >>
> >> Shouldn't colorbar_doc name be hidden from users? It doesn't look like
> the
> >> rest other function documentation in pyplot.py file.
> >>
> >> In [10]: color
> >> colorbar colorbar_doc colormaps colors
> >
> > Good catch. Fixed in 7406.
>
> Just reading this, it looks like you missed the import
> matplotlib.colorbar part, no? Or am I missing something?
On my machine, the import didn't seem to be necessary. matplotlib.colorbar
is available just with:
 import matplotlib
Would it be better to explicitly import matplotlib.colorbar anyways?
> When possible, could you make bugfixes to the branch and merge to the
> trunk? I know this is a bit of a hassle, but we often live on a
> release branch for several bug fix release cycles, so it is nice to
> put the simple fixes there
>
> http://matplotlib.sourceforge.net/devel/coding_guide.html
>
Yeah, my bad. I just remembered after committing to trunk and was working
on checking out the new branch and applying there when you made your fix.
So what n ow?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States

On Thu, Aug 6, 2009 at 1:50 PM, Ryan May<rm...@gm...> wrote:
>
> On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever <gok...@gm...> wrote:
>>
>> Shouldn't colorbar_doc name be hidden from users? It doesn't look like the
>> rest other function documentation in pyplot.py file.
>>
>> In [10]: color
>> colorbar   colorbar_doc colormaps   colors
>
> Good catch. Fixed in 7406.
Just reading this, it looks like you missed the import
matplotlib.colorbar part, no? Or am I missing something?
When possible, could you make bugfixes to the branch and merge to the
trunk? I know this is a bit of a hassle, but we often live on a
release branch for several bug fix release cycles, so it is nice to
put the simple fixes there
http://matplotlib.sourceforge.net/devel/coding_guide.html
JDH

John Hunter wrote:
> On Thu, Aug 6, 2009 at 1:06 PM, Michael Droettboom<md...@st...> wrote:
> 
>> I looked into this a while ago wrt 2D quad meshes, and it didn't look like
>> there was anything built-in to do something like that. All the gradients
>> are 1-dimensional (i.e. between two colors, or a 1-dimensional lookup table
>> of colors). There's nothing to do a 4-way blend like this. So it would
>> have to be from scratch, at least for the colored part -- we can still use
>> Agg to render the quad shapes themselves.
>> 
>
> What about for other backends (PS, PDF, SVG)? If there was support in
> the gradient spec for these, it might be worth it to try and write a
> custom gradient function in agg, as suggested by Maxim at the end of
> this tutorial:
>
> http://www.antigrain.com/tips/gradients_tutorial/gradients_tutorial.agdoc.html
> 
Even with this, the gradient infrastructure in Agg assumes a 
one-dimensional map, and here we need to at least interpolate between 
the three points of a triangle. It's not impossible, as it's easy 
enough to make a custom shader, it's just that the gradient code won't 
help us.
A possible workaround is suggested by this paper:
 http://www.svgopen.org/2005/papers/Converting3DFaceToSVG/index.html
That is, rather than doing a single Gourad triangle interpolation, just 
overlap three linear gradient patches with alpha blending. At the very 
least it presents a way to support this in SVG which doesn't currently 
have Gourad interpolation.
PDF and PS support Gourad triangles directly, though supporting it looks 
-- um -- "fun".
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever<gok...@gm...> wrote:
> Shouldn't colorbar_doc name be hidden from users? It doesn't look like the
> rest other function documentation in pyplot.py file.
>
> In [10]: color
> colorbar   colorbar_doc colormaps   colors
>
> at rev 7405.
We are not very good about using the __all__ designation in our
modules. I will change this to
 from matplotlib.colorbar import colorbar_doc as _colorbar_doc
in pyplot so it doesn't show up in normal tab completions, etc.
JDH

On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever <gok...@gm...> wrote:
> Shouldn't colorbar_doc name be hidden from users? It doesn't look like the
> rest other function documentation in pyplot.py file.
>
> In [10]: color
> colorbar colorbar_doc colormaps colors
Good catch. Fixed in 7406.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, OK, United States

Shouldn't colorbar_doc name be hidden from users? It doesn't look like the
rest other function documentation in pyplot.py file.
In [10]: color
colorbar colorbar_doc colormaps colors
at rev 7405.
In [10]: colorbar_doc
Out[10]: "\n\nAdd a colorbar to a plot.\n\nFunction signatures for the
:mod:`~matplotlib.pyplot` interface; all\nbut the first are also method
signatures for the\n:meth:`~matplotlib.figure.Figure.colorbar` method::\n\n
colorbar(**kwargs)\n colorbar(mappable, **kwargs)\n colorbar(mappable,
cax=cax, **kwargs)\n colorbar(mappable, ax=ax, **kwargs)\n\narguments:\n\n
*mappable*\n the :class:`~matplotlib.image.Image`,\n
:class:`~matplotlib.contour.ContourSet`, etc. to\n which the colorbar
applies; this argument is mandatory for the\n
:meth:`~matplotlib.figure.Figure.colorbar` method but optional for the\n
:func:`~matplotlib.pyplot.colorbar` function, which sets the\n default to
the current image.\n\nkeyword arguments:\n\n *cax*\n None | axes object
into which the colorbar will be drawn\n *ax*\n None | parent axes object
from which space for a new\n colorbar axes will be stolen\n\n\nAdditional
keyword arguments are of two kinds:\n\n axes properties:\n\n\n
============= ====================================================\n
Property Description\n =============
====================================================\n *orientation*
vertical or horizontal\n *fraction* 0.15; fraction of original axes to
use for colorbar\n *pad* 0.05 if vertical, 0.15 if horizontal;
fraction\n of original axes between colorbar and new image
axes\n *shrink* 1.0; fraction by which to shrink the colorbar\n
*aspect* 20; ratio of long to short dimensions\n =============
====================================================\n\n\n colorbar
properties:\n\n\n ===========
====================================================\n Property
Description\n ===========
====================================================\n *extend* [
'neither' | 'both' | 'min' | 'max' ]\n If not 'neither',
make pointed end(s) for out-of-\n range values. These are
set for a given colormap\n using the colormap set_under and
set_over methods.\n *spacing* [ 'uniform' | 'proportional'
]\n Uniform spacing gives each discrete color the
same\n space; proportional makes the space proportional
to\n the data interval.\n *ticks* [ None | list of
ticks | Locator object ]\n If None, ticks are determined
automatically from the\n input.\n *format* [ None |
format string | Formatter object ]\n If None,
the\n :class:`~matplotlib.ticker.ScalarFormatter` is
used.\n If a format string is given, e.g. '%.3f', that
is\n used. An alternative\n
:class:`~matplotlib.ticker.Formatter` object may be\n given
instead.\n *drawedges* [ False | True ] If true, draw lines at
color\n boundaries.\n ===========
====================================================\n\n The following
will probably be useful only in the context of\n indexed colors (that is,
when the mappable has norm=NoNorm()),\n or other unusual
circumstances.\n\n ============
===================================================\n Property
Description\n ============
===================================================\n *boundaries* None
or a sequence\n *values* None or a sequence which must be of length
1 less\n than the sequence of *boundaries*. For each
region\n delimited by adjacent entries in *boundaries*,
the\n color mapped to the corresponding value in
values\n will be used.\n ============
===================================================\n\n\n\nIf *mappable* is
a :class:`~matplotlib.contours.ContourSet`, its *extend*\nkwarg is included
automatically.\n\nNote that the *shrink* kwarg provides a simple way to keep
a vertical\ncolorbar, for example, from being taller than the axes of the
mappable\nto which the colorbar is attached; but it is a manual method
requiring\nsome trial and error. If the colorbar is too tall (or a
horizontal\ncolorbar is too wide) use a smaller value of *shrink*.\n\nFor
more precise control, you can manually specify the positions of\nthe axes
objects in which the mappable and the colorbar are drawn. In\nthis case, do
not use any of the axes properties kwargs.\n\nreturns:\n
:class:`~matplotlib.colorbar.Colorbar` instance; see also its base
class,\n :class:`~matplotlib.colorbar.ColorbarBase`. Call the\n
:meth:`~matplotlib.colorbar.ColorbarBase.set_label` method\n to label the
colorbar.\n\n"
-- 
Gökhan

On Thu, Aug 6, 2009 at 1:06 PM, Michael Droettboom<md...@st...> wrote:
> I looked into this a while ago wrt 2D quad meshes, and it didn't look like
> there was anything built-in to do something like that. All the gradients
> are 1-dimensional (i.e. between two colors, or a 1-dimensional lookup table
> of colors). There's nothing to do a 4-way blend like this. So it would
> have to be from scratch, at least for the colored part -- we can still use
> Agg to render the quad shapes themselves.
What about for other backends (PS, PDF, SVG)? If there was support in
the gradient spec for these, it might be worth it to try and write a
custom gradient function in agg, as suggested by Maxim at the end of
this tutorial:
http://www.antigrain.com/tips/gradients_tutorial/gradients_tutorial.agdoc.html
JDH

On Thu, Aug 6, 2009 at 1:01 PM, Brian Granger<ell...@gm...> wrote:
> Hi,
>
> Congrats on the latest matplotlib release. Looks like there are some
> *really* impressive new things in there. I was just looking at the spines
> docs:
>
> http://matplotlib.sourceforge.net/examples/pylab_examples/spine_placement_demo.html
>
> And I noticed that on spines that are range limited (to the data) in the y
> direction, the blueish line of the graph is actually cut off near the
> limit. It is not obvious, but one you see it, you notice it in all the
> examples (look at the peaks and troughs of the sin curve).
>
> Is this a known issue or can this be prevented?
I think this happens in all mpl graphs, you just don't see it. The
axis limits are set to -2..2, and the sine is draw from -2..2. The
linewidth extends beyond 2, so it is clipped by the axes clipping to
the bounding rectangle. Normally you don't see this, because visually
it is under the surrounding axes black edge. You can either set the
ylimits wider:
 ax.set_ylim(-2.1, 2.1)
or turn clipping off
 ax.plot(x,y, clip_on=False)
JDH

I looked into this a while ago wrt 2D quad meshes, and it didn't look 
like there was anything built-in to do something like that. All the 
gradients are 1-dimensional (i.e. between two colors, or a 1-dimensional 
lookup table of colors). There's nothing to do a 4-way blend like 
this. So it would have to be from scratch, at least for the colored 
part -- we can still use Agg to render the quad shapes themselves.
Mike
John Hunter wrote:
> On Thu, Aug 6, 2009 at 11:51 AM, Ryan Wagner<rw...@vn...> wrote:
> 
>> Hi,
>> I'd like to propose adding a SHADES keyword to the mplot3D routines where you can supply your own
>> 
>
> The other thing that would be really nice is to have smooth
> interpolation along each face. Michael, do you have a sense how hard
> it would be in agg (and other backends) to do a linear gradient
> interpolation over a quadrilateral with one RGBA at each vertex?
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
Congrats on the latest matplotlib release. Looks like there are some
*really* impressive new things in there. I was just looking at the spines
docs:
http://matplotlib.sourceforge.net/examples/pylab_examples/spine_placement_demo.html
And I noticed that on spines that are range limited (to the data) in the y
direction, the blueish line of the graph is actually cut off near the
limit. It is not obvious, but one you see it, you notice it in all the
examples (look at the peaks and troughs of the sin curve).
Is this a known issue or can this be prevented?
Cheers,
Brian

Mike,
When I eliminate the cuts from filled contour paths, I do find 
pathological cases where the filling works correctly with the cuts in 
place, but not without them. Attached are a data file and a script to 
plot it, illustrating the problem. Is this due to a known limitation of 
filled paths? In the example, the top two holes are connected to the 
lower hole, instead of being connected directly to the outer boundary of 
the filled region. Is this illegal? If so, I think we are stuck, 
because rearranging the paths that cntr makes to eliminate this type of 
case would likely be very difficult.
Eric

I've added this to the sourceforge bug tracker, ID 2832896.
Mike
On Aug 5, 2009, at 3:32 PM, Michael Fitzgerald wrote:
>
> Hi all,
>
> I've come across an apparent bug in imshow when outputting to PDF 
> and EPS files. (I haven't tested other vector formats.) It 
> manifests as a small scaling error between the raster image and the 
> axes coordinates.
>
> I have attached a test script to illustrate the problem. The 
> (correct) PNG output file shows a green 'X' at the common point 
> between four pixels near the center of the raster image. The 
> extent is chosen such that the coordinates refer to pixel centers. 
> The PDF and EPS output files show a misalignment between the X and 
> the pixel boundaries -- zoom in to see it clearly. Also, the 
> topmost row and rightmost column appear truncated.
>
> I am using svn r7395.
>
> Thanks for the attention,
> Mike
>
> <test_image_offset.py>

On Thu, Aug 6, 2009 at 11:51 AM, Ryan Wagner<rw...@vn...> wrote:
> Hi,
>  I'd like to propose adding a SHADES keyword to the mplot3D routines where you can supply your own
The other thing that would be really nice is to have smooth
interpolation along each face. Michael, do you have a sense how hard
it would be in agg (and other backends) to do a linear gradient
interpolation over a quadrilateral with one RGBA at each vertex?

Ok, I forgot my attachments would be stripped. Links:
Output of surface3d_demo.py (should explain why I want this patch)
http://static.ryanjwagner.com/mpl_patches/lightSource.png
Example code
http://static.ryanjwagner.com/mpl_patches/surface3d_demo.py
Edited mpl source... just proof of concept... still has to be cleaned up.
http://static.ryanjwagner.com/mpl_patches/axes3d.py
Also, upon looking at colors.LightSource, I think this doesn't really need to be changed for 3D except it would only work for regularly spaced data... might be a nice enhancement to supply the X and Y arrays as well as Z so it can calculate gradients for irregularly spaced grids.
-Ryan

Hi, 
 I'd like to propose adding a SHADES keyword to the mplot3D routines where you can supply your own colors for each polygon. There are cases where I do not want the surfaces to be shaded by the Z value, so this cannot be achieved with colormaps. This would also allow light-source shading if LightSource.shade is upgraded to 3D (my next goal). I already have this patch for axes3D.plot_surface written, but would like some discussion about it before I submit an enhancement request/patch.
As of right now I have a demo that works as follows:
l = LightSource(azdeg=100)
t = l.shade(Z, cm.jet)
ax.plot_surface(X, Y, Z, rstride=1, cstride=1, shades=t) 
I would also like to add a linewidth keyword to specify the width of the wireframe in the 3dSurface command.
I'd be interested in hearing anyone's comments about this. I've attached a pre-lim version of this code.. (still has to be cleaned up and variable names changed).
-Ryan Wagner

On Tue, Aug 4, 2009 at 5:33 AM, Jonathan
Demaeyer<jon...@ho...> wrote:
> Hello,
>
> Thank you for your answer. When I explicitly give None as renderer argument, everything work well.
> Now I guess the question is why the default value is not used by the method?
>
The Axes.draw is the only the "draw" method that has a default value
for renderer argument. Well, we'd better have a separate decoratorfor
Axes.draw.
> By the way, rasterization support wasn't introduced earlier than the 0.98.3 version?
Yes, the rasterization support was there for a while.
I was talking about the support for rasterization "per aritst" by
decorating the draw methods of individual artists.
-JJ
>
> Regards,
>
> Jonathan
>
>
> Jae-Joon Lee a écrit :
>> I guess this is related with the decorator introduced by rasterization support.
>> While most of the artist seems to explicitly require the renderer
>> instance as the second argument of the draw method, the draw method in
>> the Axes class have default value of None.
>> The easiest fix seems to let the decorator returns the method with
>> renderer=None as in the Axes.
>>
>> By the way, Jonathan, I guess the easiest workaround for you is to
>> modify your code so that it explicitly gives the renderer argument. As
>> you see the default value for renderer is None. Just call it as
>> draw(None).
>>
>> Regards,
>>
>> -JJ
>>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I did the following and now matplotlib 0.99.0 rc2 runs fine on my home 
computer:
- I reverted my site-packages to its state before running the 
matplotlib-0.99.0.rc2-py2.5-macosx10.5.mpkg installer
 (I had saved a zip file just in case anything went wrong)
- I found I had numpy 1.2.1 installed, so I upgraded to 1.3.0
- I found I had some version of pytz and dateutil installed, so I 
deleted them (in case there was a conflict with the versions 
matplotlib wanted to use)
- I ran the matplotlib-0.99.0.rc2-py2.5-macosx10.5.mpkg again (from a 
dmg that I'd created)
Now it all works!
I hope that numpy was too old, since I don't see how the other changes 
could possibly be relevant.
By the way: the ReadMe in the matplotlib Mac binary installer is for 
the source distro, and so not very relevant to the Mac installer. If 
and when you have time I suggest writing one for the Mac. Relevant 
info includes:
- which back ends are supported in this build
- minimum required versions for wxPython (if using wxAgg), numpy, Tcl/ 
Tk, GTK (if relevant), etc.
I will send you the file I used to use when I built a matplotlib 
installer. bdist_mpkg has a --readme flag or you can just copy it 
manually, overwriting whatever it put in there. Please feel free to do 
as you like with the file; I have no proprietary feelings about it.
Thank you very, very much for making the installer and being willing 
to work on the Tcl/Tk crash. It's great that you have figured out an 
automated way to build it that works and supports Tcl/Tk. My process 
was manual and rather a pain (copying object libraries into /usr/local/ 
lib, bdist_mpkg, removing the libraries again...).
Regards,
-- Russell
On Aug 5, 2009, at 3:27 AM, John Hunter wrote:
> On Tue, Aug 4, 2009 at 11:04 PM, Russell 
> Owen<rowen@u.washington.edu> wrote:
>
>> Thank you very much. Unfortunately it doesn't work for me. Trying 
>> to import
>> pylab results in a bus error (I appended the log in case it has 
>> anything
>> useful in it).
>>
>> My configuration:
>> - Intel Mac
>> - MacOS X 10.5.7
>> - Python 2.5.2 (in /Library/Frameworks... from python.org)
>> - Tcl/Tk 8.4.19 (in /Library/Frameworks... from ActiveState)
>> - this occurs with or without a ~/.matplotlib/matplotlibrc file 
>> (that uses
>> TkAgg) and with or without a ~/.matplotlib directory at all
>> I have confirmed that Tkinter works fine.\
>
> Can you create a small test script that creates an mpl figure and
> saves it with savefig, and run it with
>
>> python myscript.py -dTkAgg
>
>> python myscript.py -dWXAgg
>
>> python myscript.py -dAgg
>
>> python myscript.py -dmacosx
>
> and let me know if all segfault, and if not, which ones do?
>
> JDH