On Jul 8, 2010, at 2:51 PM, Michael Droettboom wrote:
> On 07/08/2010 02:38 PM, John Hunter wrote:
>> On Thu, Jul 8, 2010 at 1:25 PM, Tony S Yu wrote:
>>
>>> On Jul 8, 2010, at 12:27 PM, Michael Droettboom wrote:
>>>
>>> Can you get a gdb backtrace?
>>>
>>> Mike
>>>
>>> Ignore my last emai
On 07/08/2010 02:38 PM, John Hunter wrote:
> On Thu, Jul 8, 2010 at 1:25 PM, Tony S Yu wrote:
>
>> On Jul 8, 2010, at 12:27 PM, Michael Droettboom wrote:
>>
>> Can you get a gdb backtrace?
>>
>> Mike
>>
>> Ignore my last email. The crash occurs here:
>> #---
>> Continuing.
>> Reading symbols f
On Thu, Jul 8, 2010 at 1:25 PM, Tony S Yu wrote:
>
> On Jul 8, 2010, at 12:27 PM, Michael Droettboom wrote:
>
> Can you get a gdb backtrace?
>
> Mike
>
> Ignore my last email. The crash occurs here:
> #---
> Continuing.
> Reading symbols for shared libraries . done
> Reading symbols for shared lib
On Jul 8, 2010, at 12:27 PM, Michael Droettboom wrote:
> Can you get a gdb backtrace?
>
> Mike
Ignore my last email. The crash occurs here:
#---
Continuing.
Reading symbols for shared libraries . done
Reading symbols for shared libraries + done
2010-07-08 14:15:20.218 Python[60899:d13] *** __N
On Jul 8, 2010, at 12:27 PM, Michael Droettboom wrote:
> Can you get a gdb backtrace?
>
> Mike
>
This is as far as I can get with gdb:
#-
$ gdb python
GNU gdb 6.3.50-20050815 (Apple version gdb-1461.2) (Fri Mar 5 04:43:10 UTC
2010)
Copyright 2004 Free Software Foundation, Inc.
GDB
On Jul 8, 2010, at 12:16 PM, John Hunter wrote:
> On Thu, Jul 8, 2010 at 11:13 AM, Tony S Yu wrote:
>> The recent "nasty import behavior" thread motivated me to post an issue I've
>> been having with matplotlib and chaco. (I've posted to the Chaco list
>> previously, without much luck.)
>>
>>
I am not a usetex user, but in testing mpl on a linux box I got a new
error for dvipng. I hadn't seen this on this box before (it used to
work there) but I am not suspecting an mpl bug at this point, rather a
bug on the system. I don't really know, but others have reported
similar dvipng bugs unr
Can you get a gdb backtrace?
Mike
On 07/08/2010 12:13 PM, Tony S Yu wrote:
> The recent "nasty import behavior" thread motivated me to post an issue I've
> been having with matplotlib and chaco. (I've posted to the Chaco list
> previously, without much luck.)
>
> If I import matplotlib and chac
On Thu, Jul 8, 2010 at 11:13 AM, Tony S Yu wrote:
> The recent "nasty import behavior" thread motivated me to post an issue I've
> been having with matplotlib and chaco. (I've posted to the Chaco list
> previously, without much luck.)
>
> If I import matplotlib and chaco at the same time, I get
The recent "nasty import behavior" thread motivated me to post an issue I've
been having with matplotlib and chaco. (I've posted to the Chaco list
previously, without much luck.)
If I import matplotlib and chaco at the same time, I get a segmentation fault
in the _path.so plugin. Below is a si
On Thu, Jul 8, 2010 at 9:53 AM, Neal Becker wrote:
> Use case is I have a module that does digital design. If run as main, it
> has a little test that does a plot. The plot is supposed to use a gui and
> display.
>
> But if not run as main, there is no plot, and maybe no display.
>
> I had:
>
>
We've had users run into the same problem (and have a similar reaction). At
least on our end, there was a key assumption that users were making about how a
plotting system worked. They expected to be able to do something like this:
... plot stuff here
if outputFile:
P.savefig( "plot.png" )
It's not that simple. In order to get text metrics and start laying out
a plot for some backends (notably Gtk and Wx), the GUI framework needs
to be imported. Sure, we could import them on demand once the user
actually starts doing stuff, but that would require sprinkling the code
with "impor
Use case is I have a module that does digital design. If run as main, it
has a little test that does a plot. The plot is supposed to use a gui and
display.
But if not run as main, there is no plot, and maybe no display.
I had:
if __name__ == "__main__":
from matplotlib.pyplot import *
bu
On Thu, Jul 8, 2010 at 9:16 AM, Neal Becker wrote:
> Thanks for the info, but I still think this is rude behavior for a python
> module, and believe it would be a good thing to fix it.
Generally we try and make it easy for the user to express their
intention rather than guess what they are trying
Thanks for the info, but I still think this is rude behavior for a python
module, and believe it would be a good thing to fix it.
Michael Droettboom wrote:
> You need to set your backend to a non-GUI one (such as Agg) if you want
> to run without a display. This FAQ answer may be helpful:
>
>
You need to set your backend to a non-GUI one (such as Agg) if you want
to run without a display. This FAQ answer may be helpful:
http://matplotlib.sourceforge.net/faq/howto_faq.html#matplotlib-in-a-web-application-server
Mike
On 07/08/2010 08:26 AM, Neal Becker wrote:
A python module of mi
A python module of mine could draw a plot, and so imports from matplotlib.
Actually, plotting is part of the module test that is in
if __name__==__main__
But this kills my job trying to run non-interactively.
This is IMO rather nasty behavior. matplotlib should not try to open the
display ju
Hey Mike,
> Instead, it would make more sense to make use of the clipping
> algorithm already in matplotlib (and implemented in fast C++) that will
> actually splice the line segments at the boundary. I've attached a patch
> for this.
Good call. Our main clipping issue that still needs to be res
19 matches
Mail list logo
