matplotlib-devel Mailing List for matplotlib (Page 14)

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
> 

On Jul 13, 2007, at 9:14 AM, John Hunter wrote:
>
> 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
I have done all the usual tricks (wipe build, get newest numpy/mpl, 
etc).
I tried the suggestions above, and get an error for only one:
 >>> import matplotlib.backends._tkagg
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/matplotlib/backends/_tkagg.so, 2): Symbol 
not found: _Tcl_AppendResult
 Referenced from: /Library/Frameworks/Python.framework/Versions/2.5/ 
lib/python2.5/site-packages/matplotlib/backends/_tkagg.so
 Expected in: dynamic lookup
I think this is strange, because Tk works fine when I don't click- 
close a Tk window -- I.e., no errors when pylab starts, or plots, etc.
-Rob
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

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
> 

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

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.
-Rob
On Jul 13, 2007, at 1:34 AM, Fernando Perez wrote:
> On 7/12/07, Rob Hetland <he...@ta...> wrote:
>>
>> I recently updated matplotlib, and I am now getting a bus error when
>> plotting (any command) after I have already closed a matplotlib
>> window. I can open as many windows as I want, but the first plot
>> command executed after closing any window results in a bus error.
>>
>> Relavent things:
>>
>> OS: Mac OS X
>> Backend: TkAgg (same bus error with qt4, though)
>> very recent svn versions of numpy/mpl/ipython.
>
> The fact that you get this with Tk makes me suspect that for once,
> it's not ipython's fault (since Tk does NOT activate the more
> dangerous threading tricks). But it would be good to be 100% sure, by
> trying in a pure python terminal
>
> from pylab import *
> ion()
> plot(...)
>
> and see if the crash persists. That would limit the likely culprits
> to two out of three (and move this ball out of my court in the process
> :)
>
> cheers,
>
> f
>
> ---------------------------------------------------------------------- 
> ---
> 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
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

Carl Worth wrote:
> On 2007年7月12日 11:35:25 -1000, Eric Firing wrote:
>> Carl Worth wrote:
>>
[...]
> Later, you said...
> 
>> Aha! Cairo ps output is full of "initclip" commands, so it can't be
>> converted to eps without substantial reworking.
> 
> Oh, actually that should be really easy to get rid of. The cairo
> semantics match PostScript's very closely:
> 
> 	cairo_clip 	 -> clip
> 	cairo_reset_clip -> initclip
> 
> So, the only problematic case is if the application is actually
> calling cairo_reset_clip, (which could simply be made into an error
> when targeting EPS). If the application isn't, and cairo is still
> generating initclip in the PostScript output then it should be very
> simple to fix that.
I have looked at the mpl cairo backend code and at the source code for 
the pycairo package that mpl uses, and I have not figured out where the 
initclip call is coming from; it does not appear to be anything 
explicit. reset_clip is wrapped by pycairo, but an example snippet that 
generates ps with an initclip does not include any call to reset_clip. 
Nor does the mpl backend. So I conclude that it is being generated 
implicitly. I have not checked for any of the other postscript commands 
that are not allowed in eps, and I really can't pursue this any farther. 
 But thanks for the ideas and encouragement; and in turn, if you are 
interested, I certainly encourage you to pursue the better utilization 
of cairo in mpl. The author of the backend, as well as of pycairo, is 
Steve Chaplin.
Eric