matplotlib-devel Mailing List for matplotlib

It seems to be working now. Thanks!
This is a perfect example of quick response. I keep telling people 
that, sure, the scientific python suite has occasional bugs, but the 
community is *very* responsive. This is a perfect example. Thanks 
to everybody that helped,
-Rob
> Rob, you should be able to compile now as of r3515.
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

Tom Holroyd (NIH/NIMH) [E] wrote:
[...]
> If I say
> 
>>>> import matplotlib
>>>> help(matplotlib)
> 
> (This is with 0.90.0 by the way)
> 
> It basically gives me the help I'd expect for pylab. Oh, and it says 
> "the" instead of "to". It's a little weird thinking of a library as the 
> top level with the main interface as a module. I guess the interface is 
> just another component of the library. Though when I
> 
>>>> import pylab
>>>> help(pylab)
> 
> I get what looks like help for numpy. Perhaps my installation is strange?
> 
No, it is not your installation. You have identified an area that needs 
work, after we settle on a possibly new import and namespace strategy.
Eric

Christopher Barker wrote:
> John Hunter wrote:
[...]
> I do wish that:
> 
>>>> import matplotlib as mpl
>>>> import mpl.artist
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> ImportError: No module named mpl.artist
> 
> worked.
The way I have it working now (on my machine, not in svn), when you
import matplotlib as mpl
You don't need to then import mpl.artist; it is already imported, ready 
for use.
Eric
> 
> -Chris
> 
> 
> 

John Hunter wrote:
> I don't think this will work in this form. artist is a module, and it
> is not imported simply by importing matplotlib
> 
> In [1]: import matplotlib as mpl
> 
> In [2]: mpl.artist
however, this seems to work (though it looks perhaps a bit odd)
>>> import matplotlib as mpl
>>> import matplotlib.artist
>>> mpl.artist
<module 'matplotlib.artist' from
'/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/artist.pyc'>
I do like this better -- names like mpl_*** rub me the wrong way. it
looks like you really want a namespace -- and indeed you do!
maybe the real solution is to have the matplotlib called "mpl" from the
get go, like wxPython does:
import wx
wx.Whatever...
I do wish that:
>>> import matplotlib as mpl
>>> import mpl.artist
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
ImportError: No module named mpl.artist
worked.
-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...

I think I figured out and fixed the situation with isnan.
>From http://lists.apple.com/archives/xcode-users/2005/Feb/msg00196.html
> 
> Basically the story is this:
> isnan() is a C99 extension to standard C.
> Standard C++ is based on an older standard of C.
> Hence isnan() is not part of standard C++ and may or may not work.
But std::isnan() is part of standard C++ defined in <cmath>.
Since we use C++ (which numpy doesn't) we can drop our own isnan support
and use std::isnan(). Which I just did.
The cmath header also defines isfinite and isinf. So, John, go at the
original change you wanted to make this morning, at least once the dust
settle and we're happy this will work on all target platforms (now
tested with gcc on Mac and Linux -- I'm afraid MSVC is beyond me right now).
-Andrew

Eric Firing wrote:
> John Hunter wrote:
>> On 7/13/07, Ted Drain <ted...@jp...> wrote:
>>> I think he means that the matplotlib/__init__.py file should be
>>> changed to that those things are imported.
>> but if __init__.py imports axes, and axes import matplotlib, don't we
>> still have the problem of recursive imports?
> 
> Yes, but that is not necessarily fatal. It depends on the order in which 
> things are defined and imports are made:
> 
> http://effbot.org/zone/import-confusion.htm
> 
> Is there a significant performance penalty, however, in forcing every 
> module to be imported every time any mpl script is run, regardless of 
> whether the module is used in that script?
> 
> Anyway, I *think* it is feasible to arrange matplotlib.__init__.py so 
> that it imports all the modules, and then use
> 
> import matplotlib as mpl
> ... mpl.cbook.is_iterable(x) ...
> 
> both in scripts and within mpl modules.
I have done a little experimentation, and I am pretty sure this will 
work. The problem I have run into so far is that in the initial orgy of 
importing, at the end of matplotlib/__init__, one has to be careful 
about the order so that kwdocd entries exist when they are needed.
So, John, is this the direction you would like to go? It would mean 
that a long list of module imports at the top of each module would go 
away, replaced by the single "import matplotlib as mpl". This is 
simpler, but it removes the concise information about what modules a 
given module depends on.
Eric
> 
> Whether this is the best approach is another question.
> 
> Eric
>> JDH

Eric Firing wrote:
> Tom Holroyd (NIH/NIMH) [E] wrote:
>>
>> Ted Drain wrote:
>>> I think the basic idea is that if I want to use MPL, I should import 
>>> it and go and I should not have to import a sub-module out of MPL as 
>>> the main API.
>>
>> Yeah, about that, my typical usage is actually "from pylab import *".
>> I guess I am unclear about the relationship between matplotlib and pylab.
>>
> 
> Tom,
> 
> matplotlib is the object-oriented plotting library; pylab is a module 
> within matplotlib that provides a matlab-style (state-machine) interface 
> to the library.
> 
> Eric
If I say
>>> import matplotlib
>>> help(matplotlib)
(This is with 0.90.0 by the way)
It basically gives me the help I'd expect for pylab. Oh, and it says "the" instead of "to". It's a little weird thinking of a library as the top level with the main interface as a module. I guess the interface is just another component of the library. Though when I
>>> import pylab
>>> help(pylab)
I get what looks like help for numpy. Perhaps my installation is strange?
-- 
Tom Holroyd, Ph.D.
"The fundamentally misconceived nature versus nurture debate should be
abandoned: child development is inextricably both." -- Louann Brizendine

John Hunter wrote:
> On 7/13/07, Andrew Straw <str...@as...> wrote:
>> grr. that's probably my fault. I just fiddled with the definition of
>> npy. I tested this on linux and thought I copied it pretty directly from
>> numpy, so I assumed it would work elsewhere, but it's not. I'll see what
>> I can do...
> 
> It amy also be that he got a revision in an inconsistent state. At
> one point I committed some broken isnan stuff I was testing, so make
> sure you have the latest svn and try again.
No, it looks like I screwed up - the top of numpy's umathmodule.c.src
has a lot of stuff that would be really nice if numpy made available in
a header file. This stuff is not necessary with my default compiler
settings on my linux workstation, but on Mac OS X (and surely other
platforms) it is. So, I've just reverted to our old way.
I'll see if I can add isfinite() and also re-implement a couple cleanups
I just took out after putting them in this morning.
Rob, you should be able to compile now as of r3515.

Tom Holroyd (NIH/NIMH) [E] wrote:
> 
> Ted Drain wrote:
>> I think the basic idea is that if I want to use MPL, I should import 
>> it and go and I should not have to import a sub-module out of MPL as 
>> the main API.
> 
> Yeah, about that, my typical usage is actually "from pylab import *".
> I guess I am unclear about the relationship between matplotlib and pylab.
> 
Tom,
matplotlib is the object-oriented plotting library; pylab is a module 
within matplotlib that provides a matlab-style (state-machine) interface 
to the library.
Eric

John Hunter wrote:
> On 7/13/07, Ted Drain <ted...@jp...> wrote:
>> I think he means that the matplotlib/__init__.py file should be
>> changed to that those things are imported.
> 
> but if __init__.py imports axes, and axes import matplotlib, don't we
> still have the problem of recursive imports?
Yes, but that is not necessarily fatal. It depends on the order in which 
things are defined and imports are made:
http://effbot.org/zone/import-confusion.htm
Is there a significant performance penalty, however, in forcing every 
module to be imported every time any mpl script is run, regardless of 
whether the module is used in that script?
Anyway, I *think* it is feasible to arrange matplotlib.__init__.py so 
that it imports all the modules, and then use
import matplotlib as mpl
... mpl.cbook.is_iterable(x) ...
both in scripts and within mpl modules.
Whether this is the best approach is another question.
Eric
> 
> JDH
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 7/13/07, Andrew Straw <str...@as...> wrote:
> grr. that's probably my fault. I just fiddled with the definition of
> npy. I tested this on linux and thought I copied it pretty directly from
> numpy, so I assumed it would work elsewhere, but it's not. I'll see what
> I can do...
It amy also be that he got a revision in an inconsistent state. At
one point I committed some broken isnan stuff I was testing, so make
sure you have the latest svn and try again.
JDH

Ted Drain wrote:
> I think the basic idea is that if I want to use MPL, I should import 
> it and go and I should not have to import a sub-module out of MPL as 
> the main API.
Yeah, about that, my typical usage is actually "from pylab import *".
I guess I am unclear about the relationship between matplotlib and pylab.
-- 
Tom Holroyd, Ph.D.
"The fundamentally misconceived nature versus nurture debate should be
abandoned: child development is inextricably both." -- Louann Brizendine

grr. that's probably my fault. I just fiddled with the definition of
npy. I tested this on linux and thought I copied it pretty directly from
numpy, so I assumed it would work elsewhere, but it's not. I'll see what
I can do...
Rob Hetland wrote:
> First of all, Qt4 does appear to work fine.
> 
> Second. I am trying to recompile, and I get the error attached 
> below. Somebody had mentioned needing a recent version of gcc. Is 
> this the problem here, or is it another bug?
> 
> -Rob
> 
> 
> 
> 
> 
> gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - 
> fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd - 
> fno-common -dynamic -DNDEBUG -g -O3 -Isrc -I. -I/Library/Frameworks/ 
> Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/core/ 
> include -I/usr/local/include -I/usr/include -I. -I/Library/Frameworks/ 
> Python.framework/Versions/2.5/include/python2.5 -c src/transforms.cpp 
> -o build/temp.macosx-10.3-fat-2.5/src/transforms.o
> src/transforms.cpp: In member function ‘Py::Object Bbox::update(const 
> Py::Tuple&)’:
> src/transforms.cpp:478: error: ‘isnan’ was not declared in this scope
> src/transforms.cpp: In member function ‘Py::Object Bbox::update(const 
> Py::Tuple&)’:
> src/transforms.cpp:478: error: ‘isnan’ was not declared in this scope
> src/transforms.cpp: In member function ‘Py::Object 
> Bbox::update_numerix_xy(const Py::Tuple&)’:
> src/transforms.cpp:542: error: ‘isnan’ was not declared in this 
> scopesrc/transforms.cpp: In member function ‘Py::Object 
> Bbox::update_numerix_xy(const Py::Tuple&)’:
> src/transforms.cpp:542: error: ‘isnan’ was not declared in this scope
> 
> src/transforms.cpp: In member function ‘Py::Object 
> Bbox::update_numerix(const Py::Tuple&)’:
> src/transforms.cpp:616: error: ‘isnan’ was not declared in this scope
> src/transforms.cpp: In member function ‘Py::Object 
> Bbox::update_numerix(const Py::Tuple&)’:
> src/transforms.cpp:616: error: ‘isnan’ was not declared in this scope
> src/transforms.cpp: In member function ‘Py::Object 
> Transformation::nonlinear_only_numerix(const Py::Tuple&, const 
> Py::Dict&)’:
> src/transforms.cpp:1258: error: ‘isnan’ was not declared in this scope
> src/transforms.cpp: In member function ‘Py::Object 
> Transformation::nonlinear_only_numerix(const Py::Tuple&, const 
> Py::Dict&)’:
> src/transforms.cpp:1258: error: ‘isnan’ was not declared in this scope
> lipo: can't figure out the architecture type of: /var/tmp//ccVkIyQR.out
> error: command 'gcc' failed with exit status 1
> 
> 
> 
> 
> ----
> Rob Hetland, Associate Professor
> Dept. of Oceanography, Texas A&M University
> http://pong.tamu.edu/~rob
> phone: 979-458-0096, fax: 979-845-6331
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Yes - it doesn't solve or address the recursive import problem. My 
impression was that Tom was making a user interface assertion that doing:
import matplotlib as mpl
would be simpler for people than doing:
from matplotlib import mpl
of course I could be complete wrong as well :)
I think the basic idea is that if I want to use MPL, I should import 
it and go and I should not have to import a sub-module out of MPL as 
the main API.
At 01:25 PM 7/13/2007, John Hunter wrote:
>On 7/13/07, Ted Drain <ted...@jp...> wrote:
> > I think he means that the matplotlib/__init__.py file should be
> > changed to that those things are imported.
>
>but if __init__.py imports axes, and axes import matplotlib, don't we
>still have the problem of recursive imports?
>
>JDH
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by DB2 Express
>Download DB2 Express C - the FREE version of DB2 express and take
>control of your XML. No limits. Just data. Click to get it now.
>http://sourceforge.net/powerbar/db2/
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Ted Drain Jet Propulsion Laboratory ted...@jp... 

First of all, Qt4 does appear to work fine.
Second. I am trying to recompile, and I get the error attached =20
below. Somebody had mentioned needing a recent version of gcc. Is =20
this the problem here, or is it another bug?
-Rob
gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -=20
fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -=20=
fno-common -dynamic -DNDEBUG -g -O3 -Isrc -I. -I/Library/Frameworks/=20
Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/core/=20
include -I/usr/local/include -I/usr/include -I. -I/Library/Frameworks/=20=
Python.framework/Versions/2.5/include/python2.5 -c src/transforms.cpp =20=
-o build/temp.macosx-10.3-fat-2.5/src/transforms.o
src/transforms.cpp: In member function =91Py::Object Bbox::update(const =20=
Py::Tuple&)=92:
src/transforms.cpp:478: error: =91isnan=92 was not declared in this =
scope
src/transforms.cpp: In member function =91Py::Object Bbox::update(const =20=
Py::Tuple&)=92:
src/transforms.cpp:478: error: =91isnan=92 was not declared in this =
scope
src/transforms.cpp: In member function =91Py::Object =20
Bbox::update_numerix_xy(const Py::Tuple&)=92:
src/transforms.cpp:542: error: =91isnan=92 was not declared in this =20
scopesrc/transforms.cpp: In member function =91Py::Object =20
Bbox::update_numerix_xy(const Py::Tuple&)=92:
src/transforms.cpp:542: error: =91isnan=92 was not declared in this =
scope
src/transforms.cpp: In member function =91Py::Object =20
Bbox::update_numerix(const Py::Tuple&)=92:
src/transforms.cpp:616: error: =91isnan=92 was not declared in this =
scope
src/transforms.cpp: In member function =91Py::Object =20
Bbox::update_numerix(const Py::Tuple&)=92:
src/transforms.cpp:616: error: =91isnan=92 was not declared in this =
scope
src/transforms.cpp: In member function =91Py::Object =20
Transformation::nonlinear_only_numerix(const Py::Tuple&, const =20
Py::Dict&)=92:
src/transforms.cpp:1258: error: =91isnan=92 was not declared in this =
scope
src/transforms.cpp: In member function =91Py::Object =20
Transformation::nonlinear_only_numerix(const Py::Tuple&, const =20
Py::Dict&)=92:
src/transforms.cpp:1258: error: =91isnan=92 was not declared in this =
scope
lipo: can't figure out the architecture type of: /var/tmp//ccVkIyQR.out
error: command 'gcc' failed with exit status 1
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

On Fri, Jul 13, 2007 at 03:06:45PM -0500, John Hunter wrote:
> Because the mpl_ prefix occurs nowhere else, we can easily change this
> to whatever we want with a single search replace.
I haven't sync'd with the repository yet so I can check this assertion:
 h123063:~/src/matplotlib$ find . -name "*.py" | xargs grep mpl_ | wc
 191 627 20498
These are mostly mpl_connect and mpl_disconnect, so not too bad. 
The only other use of mpl_ is the following:
 h123063:~/src/matplotlib$ find . -name "*.py" | xargs grep mpl_ | grep -v mpl_connect | grep -v mpl_disconnect
 ./examples/mpl_with_glade.py: self.widgets = gtk.glade.XML('mpl_with_glade.glade')
 ./lib/matplotlib/backends/backend_wx.py: - mpl_with_glade.py | N/A (2) | N/A (2) |
 ./OME/python/matplotlib/backends/backend_wx.py: - mpl_with_glade.py | N/A (2) | N/A (2) |
- Paul

On 7/13/07, Ted Drain <ted...@jp...> wrote:
> I think he means that the matplotlib/__init__.py file should be
> changed to that those things are imported.
but if __init__.py imports axes, and axes import matplotlib, don't we
still have the problem of recursive imports?
JDH

I think he means that the matplotlib/__init__.py file should be 
changed to that those things are imported.
At 01:12 PM 7/13/2007, John Hunter wrote:
>On 7/13/07, Tom Holroyd (NIH/NIMH) [E] <to...@ku...> wrote:
>
> > import matplotlib as mpl
> >
> > and use mpl.artist, etc.
>
>I don't think this will work in this form. artist is a module, and it
>is not imported simply by importing matplotlib
>
>In [1]: import matplotlib as mpl
>
>In [2]: mpl.artist
>------------------------------------------------------------
>Traceback (most recent call last):
> File "<ipython console>", line 1, in ?
>AttributeError: 'module' object has no attribute 'artist'
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by DB2 Express
>Download DB2 Express C - the FREE version of DB2 express and take
>control of your XML. No limits. Just data. Click to get it now.
>http://sourceforge.net/powerbar/db2/
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Ted Drain Jet Propulsion Laboratory ted...@jp... 

On 7/13/07, Tom Holroyd (NIH/NIMH) [E] <to...@ku...> wrote:
> import matplotlib as mpl
>
> and use mpl.artist, etc.
I don't think this will work in this form. artist is a module, and it
is not imported simply by importing matplotlib
In [1]: import matplotlib as mpl
In [2]: mpl.artist
------------------------------------------------------------
Traceback (most recent call last):
 File "<ipython console>", line 1, in ?
AttributeError: 'module' object has no attribute 'artist'

John Hunter wrote:
> from matplotlib import artist as mpl_artist
> from matplotlib import agg as mpl_agg
> from matplotlib import axis as mpl_axis
> from matplotlib import cbook as mpl_cbook
> from matplotlib import collections as mpl_collections
> from matplotlib import colors as mpl_colors
> from matplotlib import contour as mpl_contour
might as well
import matplotlib as mpl
and use mpl.artist, etc.

I just removed the last vestiges of the numerix extension code layer.
The conditional imports are gone from the extension code, the -D flags
are gone from the compile, as is the _ns_ module naming scheme. This
is a fairly major change, so please blow away your install and build
dirs after updating to r3513
I also numpified axes.py, by far the biggest and most complicated
module, and fixed all of the imports as we discussed in an earlier
thread. One problem I ran into. With the proposed
from matplotlib import lines # and friends
there is a lot of possibility for name clashes. Eg, in some places we
also have a variable names "lines", which isn't life threatening but
certainly can lead to confusion and bugs. Or for module legend, we
also have an Axes function.legend. I decided to go with a foolish
consistency that was unambiguous:
from matplotlib import artist as mpl_artist
from matplotlib import agg as mpl_agg
from matplotlib import axis as mpl_axis
from matplotlib import cbook as mpl_cbook
from matplotlib import collections as mpl_collections
from matplotlib import colors as mpl_colors
from matplotlib import contour as mpl_contour
and then
mpl_cbook.iterable # and so on
Because the mpl_ prefix occurs nowhere else, we can easily change this
to whatever we want with a single search replace.
I also added a module mpl which simply imports all the modules, so API
or pylab users can
 >>> from pylab import mpl
or
 >>> from matplotlib import mpl
and have all of the API in one place (mpl.dates, mpl.figure,
mpl.ticker, etc...) -- nice with tab completion an online help in
ipython when you aren't sure where to find something....
I was hoping we could use this in the matplotlib code itself. Eg if
axes could import mpl, then we could replace the somewhat ugly
mpl_cbook with the nice and pretty mpl.cbook, but there is the problem
of recursive imports. Is there a way to do this with some python
magic, so that one "mpl" API module could serve all of the modules?
Something in the back of my mind is telling me there is something in
EGGS with an api module..... Any ideas?
JDH

John, Darren,
Yes, the STIX schedule is still slip-sliding away...
Eric

On 7/13/07, BOONTHANOME NOUANESENGSY <nou...@os...> wrote:
> r = math.sqrt((y2-y1)**2. + (x2-x1)**2.)
>
> This change seemed to fix the errors I was getting
Fixed in svn. Thanks for the report.
JDH

hello,
I'm writing a program where the user can create annotations while interactively zooming and panning the graph. I kept getting errors when my panning would for the arrows to point toward the right. you can recreate the error by going to the example 'annotation_demo.py' and try to make the arrow in Figure 1 point toward the right.
I looked in the source files and I think I've found the cause. A line in file patches.py, class YAArrow, function get_verts(self) needs to be changed from
r = math.sqrt((y2-y1)**2. + (x2-x1)*2.)
to
r = math.sqrt((y2-y1)**2. + (x2-x1)**2.)
This change seemed to fix the errors I was getting.
Boonth

This looks like that was introduced by a patching error when fixing the 
Tk save figure bug recently. The bug tracker added an extraneous 
newline to my patch submitted as a comment. (That's the last time I do 
that ;)
http://sourceforge.net/tracker/index.php?func=detail&aid=1716732&group_id=80706&atid=560720 
The segfault was happening because it was trying to blit to a window 
that had been destroyed (and the figure manager wasn't creating a new 
window as it should have.)
I've committed a fix on the Python end, and also a check to the C side 
(_tkagg.cpp), so that if we get ourselves into that situation again, 
we'll get a Python exception rather than a segfault.
If you still see crashes with the Qt backend, also let us know. This 
fix doesn't affect Qt at all.
Cheers,
Mike
Michael Droettboom wrote:
> FWIW, I'm able to reproduce this here. I have a hunch it may be related 
> to my recent Tk memory leak "improvements". I'll look into this further 
> and get back soon.
>
> Cheers,
> Mike
>
> John Hunter wrote:
> 
>> On 7/13/07, Rob Hetland <he...@ta...> wrote:
>> 
>> 
>>> Nope -- the same occurs in the regular terminal, so it's not
>>> iPython's fault.
>>>
>>> Also, although I though I remembered this happening with qt4 (as
>>> posted below), I do not seem to be able to reproduce this now..
>>>
>>> Also, clearing and closing the figure works fine -- only clicking it
>>> away triggers the bug.
>>> So: Almost surely MPL, probably Tk, is my guess.
>>> 
>>> 
>> Included below are our standard segfault instructions. The first
>> thing to do is to make sure you blow away your build dir and installed
>> mpl and get a clean build. Secondly, make sure you are using numpy
>> and your rc numerix setting is numpy. Here are the instructions::
>>
>>
>> # How to diagnose where a segfault is occurring
>>
>> First thing to try is simply rm -rf the site-packages/matplotlib and
>> build subdirs and get a clean install. Installing a new version over
>> a pretty old version has been known to cause trouble, segfault, etc.
>>
>> Try importing these packages individually
>>
>> import matplotlib._image
>> import matplotlib._transforms
>>
>> #one of these three depending on which numerix package you are using
>> import matplotlib.backends._na_backend_agg # for numarray
>> import matplotlib.backends._nc_backend_agg # for Numeric
>> import matplotlib.backends._ns_backend_agg # for numpy
>>
>> import matplotlib.backends._tkagg
>> import matplotlib._agg
>>
>>
>> If the last two work and the others don't, it is likely you need to
>> upgrade your gcc, because on some platforms (OS X for sure) old
>> versions of gcc cannot compile new versions of pycxx, which matplotlib
>> uses for building some but not all of it's extensions. Report back
>> which if any work or segfault or raise tracebacks,
>>
>> If that shed additional light, again flush the build and install dirs,
>> and try setting VERBOSE=True in setup.py before doing a clean install.
>> The VERBOSE setting will generate lots of extra output and may help
>> indicate where the segfault is occurring
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>> 
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>