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,
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 wrote:
> From: Matthew Brett
> Subject: Re: [matplotlib-devel] Segmentation fault from fresh OSX snow
> leopard build
> To: matplotlib-devel
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?
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
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
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 happ
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.
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
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
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
generalize_mac_deployment.diff
Description: Binary data
On Mon, Nov 30, 2009 at 12:14 PM, Matthew Brett 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
---
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
12 matches
Mail list logo
