matplotlib-devel Mailing List for matplotlib

Here is sample code demonstrating the problem I'm having with
pyhd5/numpy/matplotlib
import h5py
import numpy
import re
import sys
import os
import gtk
import pdb
import gc
from matplotlib.figure import Figure
from matplotlib.backends.backend_gtkagg import FigureCanvasGTKAgg as
FigureCanvas
def doplot(widget,box1):
 id=h5py.h5f.open("MLS-Aura_L1BRADD_v02-23-c01_2009d001.h5")
 data_id = h5py.h5d.open(id,"R1A:118.B22D:PT.S0.DACS-4")
 dataspaceID = h5py.h5d.DatasetID.get_space(data_id)
 noDims = h5py.h5s.SpaceID.get_simple_extent_ndims(dataspaceID)
 dims = h5py.h5s.SpaceID.get_simple_extent_dims(dataspaceID)
 start=tuple([0]*noDims)
 h5py.h5s.SpaceID.select_hyperslab(dataspaceID,start,dims,None,None,
 h5py.h5s.SELECT_SET)
 memory_space_id = h5py.h5s.create_simple(dims)
 data=numpy.memmap('tmpdat',dtype=numpy.float64,mode='w+',shape=dims)
 h5py.h5d.DatasetID.read(data_id,memory_space_id,dataspaceID,data)
 del data
 data=numpy.memmap('tmpdat',dtype=numpy.float64,mode='r',shape=dims)
 fig = Figure(figsize=(5,5), dpi=100)
 ax = fig.add_subplot(111)
 plot_data=data[0,0:,0]
 mif=numpy.arange(plot_data.shape[0])
 #if the next line is commented out, all is good
 ax.plot(plot_data,mif)
 canvas = FigureCanvas(fig)
 box1.pack_start(canvas, True, True, 0)
 canvas.show()
 id.close()
 del data
 del fig
 del ax
 del plot_data
 del canvas
 gc.collect()
 #the following line fails
 os.remove('tmpdat')
def delete_event(widget, event, data=None):
 return False
window = gtk.Window(gtk.WINDOW_TOPLEVEL)
window.connect("destroy", lambda x: gtk.main_quit())
box1 = gtk.HBox(False, 0)
window.add(box1)
button = gtk.Button("Hello World")
box1.pack_start(button, True, True, 0)
#window.add(box1)
button.show()
button.connect("clicked", doplot, box1)
box1.show()
window.set_default_size(500,400)
window.show()
gtk.main()

On Mon, Nov 30, 2009 at 12:14 PM, Matthew Brett <mat...@gm...> wrote:
> Hi,
>
> Can I suggest the following generalization in the make.osx make file?
> It makes it a bit easier to configure for odd builds like mine...
>
Sure -- committed to svn HEAD.
Thanks,
JDH

Hi,
Can I suggest the following generalization in the make.osx make file?
It makes it a bit easier to configure for odd builds like mine...
Thanks a lot,
Matthew

Hi,
>>  I've been having an almost identical problem with described above with
>> the MacOSX backend. When I switched to the TkAgg backend, the segfault
>> occurs when I try pylab.close() instead.
>>
> I may have had the same problem. Do you happen to be on a recent revision?
>
> Christoph Gohlke pointed out a typo introduced in r7985 (see bug report). The patch below fixed the segfaults on my system.
Yes - thanks - segfault gone for me...
Cheers,
Matthew

Andrew Straw wrote:
> I'm a little mystified as to the actual cause, but it 
> again looks like some freetype problem. Mike, do you think it could 
> somehow be related to your recent font work?
>
> 
OK, in the absence of a fix, I just checked in the images that were 
being generated. They didn't look too bad -- probably just a weird 
freetype font hinting difference between the original and re-generated 
images.
Anyhow, now all the tests are passing again, and therefore we shouldn't 
have any more severe bugs like that in r7985 creeping in unnoticed. I 
take this as evidence that it's good to fix (or disable) minor failing 
tests right away so they don't obscure more severe failures.

Tony S Yu wrote:
>
> On Nov 30, 2009, at 4:34 AM, Andrew Straw wrote:
>> However, with svn r7985, the trunk fails to find the tests. This is so
>> weird. There's nothing in that commit that I can see that should cause
>> the failure, but it seems repeatable. r7984 doesn't have it and r7985
>> does. And it appears to be more or less the issue that the scons branch
>> had. Sigh.
>
> Could this failure be related to the bug filed by Christoph Gohlke 
> (see tracker 
> <http://sourceforge.net/tracker/?func=detail&aid=2903596&group_id=80706&atid=560720>)? 
> The change corresponds to r7985 and affects setupext.py. I'm not sure 
> if the numscons build uses setupext.py, but it may be worth checking out.
Thanks Tony (and Christoph) -- this fixed it.
I wonder why I wasn't getting a more severe error on linux? This might 
offer a clue as to the testing weirdness we've been experiencing lately.
Anyhow, I got the tests passing on the buildbots again so that we should 
immediately be notified upon new failures. I think we need to work hard 
to keep the buildbots green so we can catch things like this.
-Andrew

On Nov 30, 2009, at 9:09 AM, Jcmottram wrote:
> 
> Hi,
> I've been having an almost identical problem with described above with
> the MacOSX backend. When I switched to the TkAgg backend, the segfault
> occurs when I try pylab.close() instead. 
> 
> 
I may have had the same problem. Do you happen to be on a recent revision?
Christoph Gohlke pointed out a typo introduced in r7985 (see bug report). The patch below fixed the segfaults on my system.
Best,
-Tony
Index: setupext.py
===================================================================
--- setupext.py	(revision 7987)
+++ setupext.py	(working copy)
@@ -122,7 +122,7 @@
 'backend': None}
 
 defines = [
-	('PY_ARRAYAUNIQUE_SYMBOL', 'MPL_ARRAY_API'),
+	('PY_ARRAY_UNIQUE_SYMBOL', 'MPL_ARRAY_API'),
 	('PYCXX_ISO_CPP_LIB', '1')]
 
 # Based on the contents of setup.cfg, determine the build options

Sorry this thread fell through the cracks. Thanks for the reminder.
The error is not actually on importing and parsing the .py file (it 
seems to do that just fine). The error is on printing to the console, 
at which point it tries to convert the Unicode string to ascii (which 
fails because it has character points > 127). One way around this is to 
encode Unicode as UTF-8 (which seems to be the default for most modern 
Linux X terminals etc.), eg.:
 print(u"accent aigus é".encode("utf8"))
Mike
On 11/25/2009 02:11 PM, Sébastien Barthélemy wrote:
> Hi,
>
> just wanted to raise this problem on the devel list, where it probably 
> belongs. Also, if nobody has time to look at it now and you prefer me 
> to file a bug, please don't hesitate to tell it.
>
> the original post is there: 
> http://thread.gmane.org/gmane.comp.python.matplotlib.general/20411
>
> Cheers
>
> Le 21 novembre 2009 17:50, Sébastien Barthélemy <bar...@cr... 
> <mailto:bar...@cr...>> a écrit :
>
> Le 18 novembre 2009 17:24, Michael Droettboom <md...@st...
> <mailto:md...@st...>> a écrit :
>
> This is a bug -- but it has a fairly straightforward fix: to
> use Sphinx's "include" directive rather than roll our own as
> we currently do. This has been fixed in SVN r7972.
> plot-directive now takes an "encoding" option, exactly like
> the Sphinx include directive. It does not do automatic
> encoding detection (meaning it ignores the "# coding: latin1"
> comments), just as the Sphinx include directive does.
>
>
> Hello Michael,
>
> thank you for your fast reply and action. I just tried with the
> version from trunk (r7978) and I still have an encoding problem on
> the same test case. It seems to happen when the file is ran (to
> produce the figure) rather than when it is included. I had a look
> at the code, but cannot understand what is happenning, I would
> have expected imp to proprely guess the encoding.
>
> Could you tell me if you have the same problem ? Do you have any
> idea of what is going on ?
>
> Thanks !
>
> $ git clone git://github.com/sbarthelemy/SphinxEncoding.git
> <http://github.com/sbarthelemy/SphinxEncoding.git>
> $ cd SphinxEncoding/
> $ make html
> sphinx-build -b html -d _build/doctrees . _build/html
> Making output directory...
> Running Sphinx v0.6.2
> loading pickled environment... not found
> building [html]: targets for 1 source files that are out of date
> updating environment: 1 added, 0 changed, 0 removed
> /home/barthelemy/.local/lib/python2.6/site-packages/matplotlib/sphinxext/plot_directive.py:273:
> UserWarning: Exception running plot ./fileutf8.py
> Traceback (most recent call last):
> File
> "/home/barthelemy/.local/lib/python2.6/site-packages/matplotlib/sphinxext/plot_directive.py",
> line 270, in render_figures
> run_code(plot_path, function_name, plot_code)
> File
> "/home/barthelemy/.local/lib/python2.6/site-packages/matplotlib/sphinxext/plot_directive.py",
> line 182, in run_code
> "__plot__", fd, fname, ('py', 'r', imp.PY_SOURCE))
> File "fileutf8.py", line 2, in <module>
> print(u"accent aigus é")
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9'
> in position 13: ordinal not in range(128)
>
>

On Nov 30, 2009, at 4:34 AM, Andrew Straw wrote:
> However, with svn r7985, the trunk fails to find the tests. This is so 
> weird. There's nothing in that commit that I can see that should cause 
> the failure, but it seems repeatable. r7984 doesn't have it and r7985 
> does. And it appears to be more or less the issue that the scons branch 
> had. Sigh.
Could this failure be related to the bug filed by Christoph Gohlke (see tracker)? The change corresponds to r7985 and affects setupext.py. I'm not sure if the numscons build uses setupext.py, but it may be worth checking out.
-Tony

Hi,
 I've been having an almost identical problem with described above with
the MacOSX backend. When I switched to the TkAgg backend, the segfault
occurs when I try pylab.close() instead. 
Do you get the segmentation fault also with other backends (e.g. Tkagg) or
only with the MacOSX backend?
-- 
View this message in context: http://old.nabble.com/Segmentation-fault-from-fresh-OSX-snow-leopard-build-tp26560316p26575340.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Do you get the segmentation fault also with other backends (e.g. Tkagg) or only with the MacOSX backend?
--Michiel.
--- On Sun, 11/29/09, Matthew Brett <mat...@gm...> wrote:
> From: Matthew Brett <mat...@gm...>
> Subject: Re: [matplotlib-devel] Segmentation fault from fresh OSX snow leopard build
> To: mat...@li...
> Date: Sunday, November 29, 2009, 1:26 PM
> On Sun, Nov 29, 2009 at 9:49 AM,
> Jouni K. Seppänen <jk...@ik...> wrote:
> > Matthew Brett <mat...@gm...>
> > writes:
> >
> >>> Can you get a backtrace in gdb?
> >>
> >> Program received signal EXC_BAD_ACCESS, Could not
> access memory.
> >> Reason: 13 at address: 0x0000000000000000
> >> 0x0000000102d96ffb in
> py_to_agg_transformation_matrix
> >> (obj=0x102d794d0, errors=false) at
> src/agg_py_transforms.cpp:21
> >> 21      matrix = (PyArrayObject*)
> PyArray_FromObject(obj,
> >> PyArray_DOUBLE, 2, 2);
> >
> > Can you type "bt" in gdb at this point to see the
> whole call stack?
> 
> Sorry - yes - here:
> 
> Program received signal EXC_BAD_ACCESS, Could not access
> memory.
> Reason: 13 at address: 0x0000000000000000
> 0x0000000102cf703b in py_to_agg_transformation_matrix
> (obj=0x102cde590, errors=false) at
> src/agg_py_transforms.cpp:21
> 21      matrix =
> (PyArrayObject*) PyArray_FromObject(obj,
> PyArray_DOUBLE, 2, 2);
> (gdb) bt
> #0 0x0000000102cf703b in
> py_to_agg_transformation_matrix
> (obj=0x102cde590, errors=false) at
> src/agg_py_transforms.cpp:21
> #1 0x0000000102cf762c in get_path_iterator
> (path=0x102cde710,
> trans=<value temporarily unavailable, due to
> optimizations>,
> remove_nans=1, do_clip=0, rect=0x7fff5fbf9480,
> quantize_mode=QUANTIZE_AUTO, do_simplify=1) at
> src/path_cleanup.cpp:58
> #2 0x0000000102ce9e90 in GraphicsContext_draw_path
> (self=0x102cd19d0,
> args=<value temporarily unavailable, due to
> optimizations>) at
> src/_macosx.m:881
> #3 0x00000001000b31d8 in PyEval_EvalFrameEx
> (f=0x102b65f50,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:3706
> #4 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x102cd0be8,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x102b61900, argcount=5, kws=0x102b61928, kwcount=0,
> defs=0x102cde1a8, defcount=1, closure=0x0) at
> Python/ceval.c:2968
> #5 0x00000001000b1f1d in fast_function [inlined] ()
> at
> /Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3802
> #6 0x00000001000b1f1d in PyEval_EvalFrameEx
> (f=0x102b61720,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:3727
> #7 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x10180ceb8,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x102cae2a8, argcount=2, kws=0x0, kwcount=0,
> defs=0x0,
> defcount=0, closure=0x0) at Python/ceval.c:2968
> #8 0x00000001000362a5 in function_call
> (func=0x101839b18,
> arg=0x102cae290, kw=0x0) at Objects/funcobject.c:524
> #9 0x0000000100006fe2 in PyObject_Call
> (func=0x101839b18,
> arg=0x102cae290, kw=0x0) at Objects/abstract.c:2492
> #10 0x00000001000ae352 in PyEval_EvalFrameEx
> (f=0x102b61530,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:4019
> #11 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x1014647b0,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x102b61100, argcount=2, kws=0x102b61110, kwcount=0,
> defs=0x0,
> defcount=0, closure=0x101825dc0) at Python/ceval.c:2968
> #12 0x00000001000b1f1d in fast_function [inlined] () at
> /Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3802
> #13 0x00000001000b1f1d in PyEval_EvalFrameEx
> (f=0x102b60f00,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:3727
> #14 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x102c90288,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x102cae260, argcount=2, kws=0x0, kwcount=0,
> defs=0x0,
> defcount=0, closure=0x0) at Python/ceval.c:2968
> #15 0x00000001000362a5 in function_call (func=0x102cad1b8,
> arg=0x102cae248, kw=0x0) at Objects/funcobject.c:524
> #16 0x0000000100006fe2 in PyObject_Call (func=0x102cad1b8,
> arg=0x102cae248, kw=0x0) at Objects/abstract.c:2492
> #17 0x00000001000ae352 in PyEval_EvalFrameEx
> (f=0x102b607f0,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:4019
> #18 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x1014647b0,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x102cae218, argcount=2, kws=0x0, kwcount=0,
> defs=0x0,
> defcount=0, closure=0x102c8d6e0) at Python/ceval.c:2968
> #19 0x00000001000362a5 in function_call (func=0x102cad320,
> arg=0x102cae200, kw=0x0) at Objects/funcobject.c:524
> #20 0x0000000100006fe2 in PyObject_Call (func=0x102cad320,
> arg=0x102cae200, kw=0x0) at Objects/abstract.c:2492
> #21 0x000000010001905d in instancemethod_call
> (func=0x102cad320,
> arg=0x102cae200, kw=0x0) at Objects/classobject.c:2579
> #22 0x0000000100006fe2 in PyObject_Call (func=0x102aa7fa0,
> arg=0x100438c90, kw=0x0) at Objects/abstract.c:2492
> #23 0x000000010000a760 in call_function_tail [inlined] ()
> at
> /Users/mb312/stable_trees/Python-2.6.4/Objects/abstract.c:2524
> #24 0x000000010000a760 in PyObject_CallMethod (o=<value
> temporarily
> unavailable, due to optimizations>, name=<value
> temporarily
> unavailable, due to optimizations>, format=0x102cfd504
> "O") at
> Objects/abstract.c:2601
> #25 0x0000000102ce5653 in -[View drawRect:]
> (self=0x102b50960,
> _cmd=<value temporarily unavailable, due to
> optimizations>,
> rect={origin = {x = 0, y = 0}, size = {width = 640, height
> = 480}}) at
> src/_macosx.m:4517
> #26 0x00007fff8676afae in -[NSView _drawRect:clip:] ()
> #27 0x00007fff86769c21 in -[NSView
> _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
> #28 0x00007fff86769f8b in -[NSView
> _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
> #29 0x00007fff86769f8b in -[NSView
> _recursiveDisplayAllDirtyWithLockFocus:visRect:] ()
> #30 0x00007fff867682f3 in -[NSView
> _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
> ()
> #31 0x00007fff86767e17 in -[NSThemeFrame
> _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
> ()
> #32 0x00007fff867646bf in -[NSView
> _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:]
> ()
> #33 0x00007fff866ddf37 in -[NSView displayIfNeeded] ()
> #34 0x00007fff866a5f87 in -[NSWindow
> _reallyDoOrderWindow:relativeTo:findKey:forCounter:force:isModal:]
> ()
> #35 0x00007fff866a5b1c in -[NSWindow
> orderWindow:relativeTo:] ()
> #36 0x00007fff866a349e in -[NSWindow makeKeyAndOrderFront:]
> ()
> #37 0x0000000102ce490e in FigureManager_init
> (self=0x102d30908,
> args=<value temporarily unavailable, due to
> optimizations>,
> kwds=<value temporarily unavailable, due to
> optimizations>) at
> src/_macosx.m:3338
> #38 0x000000010006533c in wrap_init (self=<value
> temporarily
> unavailable, due to optimizations>, args=<value
> temporarily
> unavailable, due to optimizations>, wrapped=<value
> temporarily
> unavailable, due to optimizations>, kwds=<value
> temporarily
> unavailable, due to optimizations>) at
> Objects/typeobject.c:4694
> #39 0x0000000100006fe2 in PyObject_Call (func=0x102cde6d0,
> arg=0x102cae1b8, kw=0x0) at Objects/abstract.c:2492
> #40 0x00000001000ab047 in PyEval_CallObjectWithKeywords
> (func=0x102cde6d0, arg=0x102cae1b8, kw=0x0) at
> Python/ceval.c:3575
> #41 0x0000000100024164 in wrapperdescr_call
> (descr=<value temporarily
> unavailable, due to optimizations>, args=0x102cae1b8,
> kwds=0x0) at
> Objects/descrobject.c:304
> #42 0x0000000100006fe2 in PyObject_Call (func=0x102cbecd0,
> arg=0x102c72b40, kw=0x0) at Objects/abstract.c:2492
> #43 0x00000001000af47e in do_call [inlined] () at
> /Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3924
> #44 0x00000001000af47e in call_function [inlined] () at
> /Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3729
> #45 0x00000001000af47e in PyEval_EvalFrameEx
> (f=0x102b56400,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:2389
> #46 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x102cd5f30,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x3, argcount=3, kws=0x0, kwcount=0, defs=0x0,
> defcount=0,
> closure=0x0) at Python/ceval.c:2968
> #47 0x00000001000362a5 in function_call (func=0x102cdfc80,
> arg=0x1002a4910, kw=0x0) at Objects/funcobject.c:524
> #48 0x0000000100006fe2 in PyObject_Call (func=0x102cdfc80,
> arg=0x1002a4910, kw=0x0) at Objects/abstract.c:2492
> #49 0x000000010001905d in instancemethod_call
> (func=0x102cdfc80,
> arg=0x1002a4910, kw=0x0) at Objects/classobject.c:2579
> #50 0x0000000100006fe2 in PyObject_Call (func=0x102aa7e60,
> arg=0x102c84128, kw=0x0) at Objects/abstract.c:2492
> #51 0x000000010006bf18 in slot_tp_init (self=<value
> temporarily
> unavailable, due to optimizations>, args=0x102c84128,
> kwds=0x0) at
> Objects/typeobject.c:5638
> #52 0x0000000100068b65 in type_call (type=0x102b44b30,
> args=0x102c84128, kwds=0x0) at Objects/typeobject.c:745
> #53 0x0000000100006fe2 in PyObject_Call (func=0x102b44b30,
> arg=0x102c84128, kw=0x0) at Objects/abstract.c:2492
> #54 0x00000001000af47e in do_call [inlined] () at
> /Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3924
> #55 0x00000001000af47e in call_function [inlined] () at
> /Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3729
> #56 0x00000001000af47e in PyEval_EvalFrameEx
> (f=0x102b3d120,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:2389
> #57 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x102cd5738,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x102cce848, argcount=1, kws=0x102b48370, kwcount=6,
> defs=0x0,
> defcount=0, closure=0x0) at Python/ceval.c:2968
> #58 0x00000001000363ad in function_call (func=0x102cdf6e0,
> arg=0x100421450, kw=0x101526720) at
> Objects/funcobject.c:524
> #59 0x0000000100006fe2 in PyObject_Call (func=0x102cdf6e0,
> arg=0x100421450, kw=0x101526720) at
> Objects/abstract.c:2492
> #60 0x00000001000ae352 in PyEval_EvalFrameEx
> (f=0x101526a60,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:4019
> #61 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x102cb5a08,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x8, argcount=0, kws=0x102b48188, kwcount=0,
> defs=0x102ccea08,
> defcount=7, closure=0x0) at Python/ceval.c:2968
> #62 0x00000001000b1f1d in fast_function [inlined] () at
> /Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3802
> #63 0x00000001000b1f1d in PyEval_EvalFrameEx
> (f=0x102b48000,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:3727
> #64 0x00000001000b237a in PyEval_EvalFrameEx
> (f=0x100357cf0,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:3792
> #65 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x102cb84e0,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x10035a950, argcount=0, kws=0x10035a950, kwcount=0,
> defs=0x0,
> defcount=0, closure=0x0) at Python/ceval.c:2968
> #66 0x00000001000b1f1d in fast_function [inlined] () at
> /Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3802
> #67 0x00000001000b1f1d in PyEval_EvalFrameEx
> (f=0x10035a7a0,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:3727
> #68 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x102cc4738,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x102cc0c30, argcount=2, kws=0x100359160, kwcount=1,
> defs=0x0,
> defcount=0, closure=0x0) at Python/ceval.c:2968
> #69 0x00000001000b1f1d in fast_function [inlined] () at
> /Users/mb312/stable_trees/Python-2.6.4/Python/ceval.c:3802
> #70 0x00000001000b1f1d in PyEval_EvalFrameEx
> (f=0x100358fd0,
> throwflag=<value temporarily unavailable, due to
> optimizations>) at
> Python/ceval.c:3727
> #71 0x00000001000b3f30 in PyEval_EvalCodeEx
> (co=0x100426f30,
> globals=<value temporarily unavailable, due to
> optimizations>,
> locals=<value temporarily unavailable, due to
> optimizations>,
> args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
> defcount=0,
> closure=0x0) at Python/ceval.c:2968
> #72 0x00000001000b4016 in PyEval_EvalCode (co=<value
> temporarily
> unavailable, due to optimizations>, globals=<value
> temporarily
> unavailable, due to optimizations>, locals=<value
> temporarily
> unavailable, due to optimizations>) at
> Python/ceval.c:522
> #73 0x00000001000d8a5e in run_mod [inlined] () at
> /Users/mb312/stable_trees/Python-2.6.4/Python/pythonrun.c:1335
> #74 0x00000001000d8a5e in PyRun_FileExFlags
> (fp=0x7fff7092be80,
> filename=0x7fff5fbfe17a
> "scipybuild/matplotlib/examples/pylab_examples/simple_plot.py",
> start=<value temporarily unavailable, due to
> optimizations>,
> globals=0x100312ec0, locals=0x100312ec0, closeit=1,
> flags=0x7fff5fbfdfb0) at Python/pythonrun.c:1321
> #75 0x00000001000d8d19 in PyRun_SimpleFileExFlags
> (fp=0x7fff7092be80,
> filename=0x7fff5fbfe17a
> "scipybuild/matplotlib/examples/pylab_examples/simple_plot.py",
> closeit=1, flags=0x7fff5fbfdfb0) at Python/pythonrun.c:931
> #76 0x00000001000e835c in Py_Main (argc=2523360,
> argv=0x7fff5fbfe010)
> at Modules/main.c:599
> #77 0x0000000100001544 in start ()
> Current language: auto; currently c++
> 
> 
> Mathew
> 
> ------------------------------------------------------------------------------
> 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
> 
 

David Cournapeau wrote:
> Andrew Straw wrote:
> 
>> I looked a little further, and it depends on the directory that the
>> tests are run from -- if I manually log into the build slave, I can
>> get the tests to run (in fact, one segfaults) if I try from a
>> different working directory. Anyhow, now that I have a handle on it, I
>> think I can probably get it working... Give me a couple days.
>> 
>
> great.
> 
Well, now the scons branch tests run properly (until they hit a segfault 
on matplotlib.tests.test_axes.test_basic_annotate)
However, with svn r7985, the trunk fails to find the tests. This is so 
weird. There's nothing in that commit that I can see that should cause 
the failure, but it seems repeatable. r7984 doesn't have it and r7985 
does. And it appears to be more or less the issue that the scons branch 
had. Sigh.
Don't forget to pass on your sourceforge username to John to get svn 
commit access. I think the scons build option should get merged into the 
trunk.
-Andrew