matplotlib-users Mailing List for matplotlib

On 10/29/05 09:41, Ryan Krauss wrote:
> Here you go Ken. Thanks again. Let me know if I can do or try anything else:
I'm sorry it's taken so long to me to get back to you. I finally had some 
time to look into things this morning, and I must confess I'm stumped...
The stack trace you sent me indicates that the segfault occurs when _wxagg.cpp 
is trying to call wxPyConstructObject():
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1210517280 (LWP 10694)]
> 0xb4fa3411 in _wxagg_module::convert_agg_to_wx_bitmap (this=0x81d8108,
> args=@0xbff1ccb0) at src/_wxagg.cpp:129
> 129 PyObject *pyWxBitmap = wxPyConstructObject(bitmap,
> _T("wxBitmap"), 1---Type <return> to continue, or q <return> to
> quit---
> );
> Current language: auto; currently c++
> (gdb) bt
> #0 0xb4fa3411 in _wxagg_module::convert_agg_to_wx_bitmap (this=0x81d8108,
> args=@0xbff1ccb0) at src/_wxagg.cpp:129
This didn't make a whole lot of sense to me at first, so I did some digging. 
It turns out that wxPyConstructObject() is actually a macro that invokes the 
function pointer wxPyCoreAPIPtr->p_wxPyConstructObject(). This is a pretty 
common idiom in Python for exposing extension module APIs to other extension 
modules... Numeric and numarray both use it, for example.
So, it appears that dereferencing the either the pointer to the wxPyCoreAPIPtr 
structure itself or the p_wxPyConstructObject function pointer within that 
structure causes the segmentation fault. I've reviewed the code involved and 
I can't come up with a plausible cause for this behavior. I think this could 
be caused by a mismatch between the wxPython headers and the wxPython 
extension itself, but I'm not even sure that would do it.
Could you try reinstalling the headers from the Ubuntu source package one more 
time and rebuilding, just to make sure that isn't the problem? I haven't been 
able to reproduce this problem under Debian, so I guess I'll need to get 
Ubuntu installed somewhere and hope that I can reproduce it myself.
If anyone else has experienced similar problems while using the WxAgg 
accelerator extension, has been able to reproduce this particular problem, or 
has any idea what might be going on, please let me know! Thanks.
Ken

[snip, snip]
To summarize: the commandline is examined first, the rc file second,
> and the default array package is Numeric.
>
> In your use case is this correct, or do we need to amend the build,
> runtime or docs? According to your post, we should fall back on
> Numeric if numarray is specified but not present. Reasonable, but
> also a bit counter-intuitive since Numeric is the default and in this
> case the user would have explicitly overridden the default. In the
> case of an explicit override from the default, failing might be better
> than just working....
>
> How about a setup.py option where you can explicitly set numeric or
numarray, such as "--use=3Dnumarray"? This optional will build MPL for
numarray and modify the rc file so that it doesn't have to be edited by
hand.
-- Paul

>>>>> "Chris" == Chris Barker <Chr...@no...> writes:
 Chris> 1) I'm wondering if there's a way to pre-define different
 Chris> defaults for different platforms. For example, I built an
 Chris> OS-X installer that doesn't support GTK, but the
 Chris> .matplotlibrc still had GtkAgg as the default. Yes, I could
 Chris> have edited the .matplotlib rc in my installer, but I'd
 Chris> have to do that each time I built a new one. It would be
 Chris> nice to have something in CVS that just worked.
This is what I do for the win32 builds -- hand edit the file before
each build. A little bit of a pain, bit it works (as long as you
remember to tweak the file before the build <wink>)
 Chris> 2) Perhaps we could make the processing of matplotlibrc
 Chris> smarter. For example: if numarray is specified, but not
 Chris> installed, and Numeric is, it could roll over to
 Chris> Numeric. Same thing with back-ends. Of course, this kind of
 Chris> breaks the "explicit is better than implicit" rule, but it
 Chris> would greatly improve the "It just works" qualities of MPL.
There is a consensus that the backend selector should be smarter. One
proposal is to iterate over a list of candidates and choose the first
one that works. Another is to set the backend in the default rc file
at setup.py build time. Both could be done, and the same arguments
apply to the numerix setting (AFAIK, These are the only two rc file
settings that might be advantageously set at build time). 
I think we would readily accept a patch for either or both of these,
but there are those who already despise the amount of magic that pylab
engages in (and you are usually near the front of that chorus). Yes,
explicit is (usually) better than implicit, but this tends to conflict
with "just works".... Are you starting to experience a change of
heart :-) ?
FYI, the advertised behavior of numeric is as follows (eg
http://matplotlib.sf.net/matplotlib.numerix.html)
 numerix imports either Numeric or numarray based on various
 selectors.
 0. If the value "--numarray" or "--Numeric" is specified on the
 command line, then numerix imports the specified array package.
 1. The value of numerix in matplotlibrc: either Numeric or numarray
 2. If none of the above is done, the default array package is
 Numeric. Because the matplotlibrc always provides *some* value
 for numerix (it has it's own system of default values), this
 default is most likely never used.
 To summarize: the commandline is examined first, the rc file second,
 and the default array package is Numeric.
In your use case is this correct, or do we need to amend the build,
runtime or docs? According to your post, we should fall back on
Numeric if numarray is specified but not present. Reasonable, but
also a bit counter-intuitive since Numeric is the default and in this
case the user would have explicitly overridden the default. In the
case of an explicit override from the default, failing might be better
than just working....
JDH

>>>>> "frank" == frank h <fra...@gm...> writes:
 frank> RuntimeError: '/Library/WebServer'
 frank> is not a writable dir; you must set environment variable
 frank> HOME to be a writable dir
 frank> what am i doing wrong? any insight is appreciated thanks,
Python tracebacks are a little funny: you have to read them from the
end to make sense of them. In this case I'll quote the end of the
message you posted back to you
 RuntimeError: '/Library/WebServer' is not a writable dir; you must
 set environment variable HOME to be a writable dir
Is this not clear? If not, you need to learn a little bit about UNIX,
environment variables, and permissions. But feel free to ask
questions here along the way :-)
JDH