matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] debugging python code

[Todd M. <jm...@st...>]

On Tue, 2004-12-07 at 10:52 +0800, Steve Chaplin wrote:
> On Mon, 2004-12-06 at 15:34 -0500, Perry Greenfield wrote:
> > I really appreciate Andrew's diagnosing the original problem and  
> > particularly in recognizing it as possibility here. This is a nasty  
> > kind of bug to figure out.
> The original bug was reported to numarray developers via the SourceForge
> bug tracking system back in February, the glibc patch was also applied
> in February. From Numarray 1.0 onwards a 'Special Note' has been
> included in the file numarray/Doc/Install.txt referencing the problem.
> 
> I believe the SourceForge bug report was the one
> 870660  Numarray: CFLAGS build problem  
> yet for some reason I can't locate it anymore. 

Here's the "numarray bugs tracker" link for this report:

http://sourceforge.net/tracker/index.php?func=detail&aid=870660&group_id=1369&atid=450446

My guess is that you were looking in the "numpy bugs tracker" where the
bug was originally filed but which is supposed to be for Numeric:

http://sourceforge.net/tracker/?group_id=1369&atid=101369

Numarray bugs which are filed in the numpy bugs tracker are moved to the
numarray bugs tracker.  They're both on the same SF project,  but the
numarray tracker is more hidden.  I'm sorry this is confusing.

Regards,
Todd

Re: [matplotlib-devel] debugging python code

[Andrew S. <str...@as...>]

On Dec 6, 2004, at 6:52 PM, Steve Chaplin wrote:

> On Mon, 2004-12-06 at 15:34 -0500, Perry Greenfield wrote:
>> I really appreciate Andrew's diagnosing the original problem and
>> particularly in recognizing it as possibility here. This is a nasty
>> kind of bug to figure out.
> The original bug was reported to numarray developers

Probably by the too-modest Steve Chaplin, I suspect.  I forgot in my 
previous email that a significant component of my late-phase debugging 
consisted of emailing the numarray list, and getting an email from 
Steven Chaplin, who had independently diagnosed the problem. He had 
already gone much further than I -- he's the one who submitted the bug 
report and patch to the glibc itself:

> This is the glibc bug report
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=10

Jochen, that bug report contains a C program which replicates the bug.  
Perhaps you could send that test program to the Debian bug tracking 
system to spur patching?  (There is an additional comment on the glibc 
bugzilla page saying "The test program isn't really testing what it is 
supposed to (the SSE status is never touched) but the SSE control 
change is indeed wrong."  You may want to address this first if you're 
up for this kind of low-level fun.)

To summarize, we owe a big thanks to Steve Chaplin.  A heartfelt 
thanks, Steve!

Cheers!
Andrew

Re: [matplotlib-devel] debugging python code

[Steve C. <ste...@ya...>]

On Mon, 2004-12-06 at 15:34 -0500, Perry Greenfield wrote:
> I really appreciate Andrew's diagnosing the original problem and  
> particularly in recognizing it as possibility here. This is a nasty  
> kind of bug to figure out.
The original bug was reported to numarray developers via the SourceForge
bug tracking system back in February, the glibc patch was also applied
in February. From Numarray 1.0 onwards a 'Special Note' has been
included in the file numarray/Doc/Install.txt referencing the problem.

I believe the SourceForge bug report was the one
870660  Numarray: CFLAGS build problem  
yet for some reason I can't locate it anymore. Perhaps thats one of the
reasons that the problem keeps getting rediscovered.

This is the glibc bug report
http://sources.redhat.com/bugzilla/show_bug.cgi?id=10

Steve

Re: [matplotlib-devel] debugging python code

[Perry G. <pe...@st...>]

On Dec 5, 2004, at 9:10 PM, Andrew Straw wrote:

>
> On Dec 5, 2004, at 9:04 AM, Jochen Voss wrote:
>
>> Hello everybody,
>>
>> On Wed, Dec 01, 2004 at 06:38:47PM -0800, Andrew Straw wrote:
>>> It sounds like you may have hit a nasty glibc bug that caused me much
>>> head scratching over the months.  Check this thread:
>>>
>>> http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/ 
>>> 2207861
>>>
>>> Bottom line:
>>>
>>> numarray does The Right Thing and attempts to set up floating point
>>> exception handling, but older versions of glibc (such as that in  
>>> Debian
>>> sarge) have a bug whereby the floating point error bits in the SSE  
>>> are
>>> not  properly cleared, leading to a SIGFPE terminating the program  
>>> the
>>> next time the SSE unit is used.
>> Yes, this was the problem.  I applied the patch from
>>
>
I really appreciate Andrew's diagnosing the original problem and  
particularly in recognizing it as possibility here. This is a nasty  
kind of bug to figure out.

>> By the way: I am still interested in my original question.  How would
>> I use a debugger etc. to find the problem myself in such a situation?
>
> If you find out, let me know!  Seriously, having a process killed by  
> the kernel

Us too!

Perry

Re: [matplotlib-devel] debugging python code

[Jochen V. <vo...@se...>]

Hello Andrew,

On Mon, Dec 06, 2004 at 06:42:03PM +0000, Jochen Voss wrote:
> I will try to add more information to the bug report log.
> Maybe this helps the patch being applied.
It turns out that I do not understand enough of this to
produce an illustrative example.  Do you have a minimal
C program which terminates with SIGFPE because of this bug
where it shouldn't?

All the best,
Jochen
--=20
http://seehuhn.de/

Re: [matplotlib-devel] debugging python code

[Jochen V. <vo...@se...>]

Hello Andrew,

On Sun, Dec 05, 2004 at 06:10:47PM -0800, Andrew Straw wrote:
> I have to admit that I'm a little disappointed in the speed of this=20
> bugfix going into the Debian sources.  I'd think that since I submitted=
=20
> a 2 line (1 of which was comments) patch over a month ago, which was=20
> copied directly from upstream, this would be about 2 minutes of work=20
> for someone...
Yes, this can be a pain.  I think the first thing to do
is to add more information to the bug report log.  I guess
the the Debian libc-maintainers are short of time and have
problems to easily see whether the bug is actually a bug and the
fix is actually a fix.

I will try to add more information to the bug report log.
Maybe this helps the patch being applied.

All the best,
Jochen
--=20
http://seehuhn.de/

Re: [matplotlib-devel] debugging python code

[Steve C. <ste...@ya...>]

> By the way: I am still interested in my original question.  How would
> I use a debugger etc. to find the problem myself in such a situation?

I should know the answer because I created the glibc patch that fixes
the problem, but it was back in February and I can't remember all the
details.
It started when I thought, why should I run my AthlonXP in '386 emulator
mode' when I can use 'gcc -march=athlon-xp' and actually benefit from
the extra instructions my processor supports. This worked fine until I
compiled numarray and it failed its own tests with a floating-point
exception. But if I used the default gcc settings it worked OK. I filed
a numarray bug report (which I can no longer locate, perhaps they get
deleted after a certain date), they looked at it and said it was
probably a gcc bug. I filed a gcc bug report, and they closed it saying
it was not a gcc bug.
Then I thought it might be a bug with the way kernel handles FP
exceptions and started looking through the kernel sources, but did not
make much progress. So I went back to the numarray source code and tried
no narrow down where the problem was occurring.

Now to answer your question:
Consider you are on a TV game show where you have to guess a number x in
the range 1 to y and are told 'higher', 'lower' or 'correct' after each
turn.  You can use a binary search and always guess the mid point of the
range - you are either correct or eliminate half of the possibilities
each turn, so in ceil log(y, 2) turns or less you locate the correct
number.

You can use a similar kind of binary search to locate bugs in software.
You know the bug occurs on some line x of the source code with y lines.
Use gdb and insert breakpoints in the code (I think I just inserted
printf() statements instead of using gdb) and see if the error occurs
before or after the breakpoint, move the breakpoint and try again. The
problem is that source code is rarely a linear list of statements in one
file that are executed in order, but a set of procedures/functions in
many files where the execution order can vary. You can start at the main
() function, split it in half and insert a breakpoint (or printf()) run
it and see in which half the error occurs, repeat the process working
your way down into other functions until you pinpoint the error.

Hope that makes sense. You could now reinstall the old glibc, forget
that you know that glibc is the problem and start again to locate the
bug, it will be useful practise for the next bug that comes along!

Steve

Re: [matplotlib-devel] debugging python code

[Andrew S. <str...@as...>]

On Dec 5, 2004, at 9:04 AM, Jochen Voss wrote:

> Hello everybody,
>
> On Wed, Dec 01, 2004 at 06:38:47PM -0800, Andrew Straw wrote:
>> It sounds like you may have hit a nasty glibc bug that caused me much
>> head scratching over the months.  Check this thread:
>>
>> http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/2207861
>>
>> Bottom line:
>>
>> numarray does The Right Thing and attempts to set up floating point
>> exception handling, but older versions of glibc (such as that in 
>> Debian
>> sarge) have a bug whereby the floating point error bits in the SSE are
>> not  properly cleared, leading to a SIGFPE terminating the program the
>> next time the SSE unit is used.
> Yes, this was the problem.  I applied the patch from
>
>     http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=279294
>
> and the problem disappeared.  Does this imply that on current
> Debian/unstable systems matplotlib can only be used with
> python-numeric and not with python-numarray?

You can remove atlas3-sse2 (and perhaps atlas3-sse), and it should run 
OK.  Sorry I didn't remember this earlier.

I have to admit that I'm a little disappointed in the speed of this 
bugfix going into the Debian sources.  I'd think that since I submitted 
a 2 line (1 of which was comments) patch over a month ago, which was 
copied directly from upstream, this would be about 2 minutes of work 
for someone...  Maybe I should have put it at a higher priority than 
"Normal".

> By the way: I am still interested in my original question.  How would
> I use a debugger etc. to find the problem myself in such a situation?

If you find out, let me know!  Seriously, having a process killed by 
the kernel because of a signal was difficult for me to debug. (Python 
is supposed to insulate you from this kind of low-level stuff and 
generally does a fantastic job.) I had no idea where the FPE signal was 
coming from or why. I first came across this in the context of a 
numarray/Intel IPP program.  Because  IPP is closed source, I didn't go 
very far initially, and just converted my program to Numeric. Then, I 
encountered the same thing purely within numarray and knew it was 
within my grasp.  By making a minimal program that exhibited the bug, I 
determined that the floating point error checking and setting code 
executed on import of numarray.ieeespecial would cause a floating point 
error (SIGFPE) in later matrix calls (e.g. 
numarray.linear_algebra.singular_value_decomposition).  I began to 
suspect the SSE unit because this code ran fine when I compiled 
numarray with its built-in lapack_lite.

Strangely, running python from within gdb did not terminate or indicate 
that a SIGFPE was raised.  This I'd like to understand a bit better...

Cheers!
Andrew

Re: [matplotlib-devel] debugging python code

[Jochen V. <vo...@se...>]

Hello everybody,

On Wed, Dec 01, 2004 at 06:38:47PM -0800, Andrew Straw wrote:
> It sounds like you may have hit a nasty glibc bug that caused me much=20
> head scratching over the months.  Check this thread:
>=20
> http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/2207861
>=20
> Bottom line:
>=20
> numarray does The Right Thing and attempts to set up floating point=20
> exception handling, but older versions of glibc (such as that in Debian=
=20
> sarge) have a bug whereby the floating point error bits in the SSE are=20
> not  properly cleared, leading to a SIGFPE terminating the program the=20
> next time the SSE unit is used.
Yes, this was the problem.  I applied the patch from

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D279294

and the problem disappeared.  Does this imply that on current
Debian/unstable systems matplotlib can only be used with
python-numeric and not with python-numarray?

By the way: I am still interested in my original question.  How would
I use a debugger etc. to find the problem myself in such a situation?

Many thanks,
Jochen
--=20
http://seehuhn.de/

Re: [matplotlib-devel] zoom in TkAgg buggy?

[Steve C. <ste...@ya...>]

On Sat, 2004-12-04 at 19:10 +0100, Norbert Nemec wrote:
> Hi there,
> 
> can anybody reproduce these bugs:
> 
> * when I first use the interactive zoom&move feature and then switch over to 
> the zoom-to-box mode, the mode is not completely switched, but stays in some 
> broken intermediate state: using the mouse, I can draw a box, but at the same 
> time, the plot is moved along with the mouse (like in interactive mode)
I can't reproduce this problem.

> * when I zoom in *very* close, (probably near the limit of floating point 
> resolution), I suddenly see huge garbage polygons in the plot. Probably there 
> should be some check limiting the zoom to the range of floating point values?
I do get this one. It looks like an Agg backend bug because it happens
for me on TkAgg and GTKAgg, but not GTK or GTKCairo.

Steve

[matplotlib-devel] zoom in TkAgg buggy?

[Norbert N. <No...@ne...>]

Hi there,

can anybody reproduce these bugs:

* when I first use the interactive zoom&move feature and then switch over to 
the zoom-to-box mode, the mode is not completely switched, but stays in some 
broken intermediate state: using the mouse, I can draw a box, but at the same 
time, the plot is moved along with the mouse (like in interactive mode)

* when I zoom in *very* close, (probably near the limit of floating point 
resolution), I suddenly see huge garbage polygons in the plot. Probably there 
should be some check limiting the zoom to the range of floating point values?

Greetings,
Nobbi 

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <No...@Ne...>

[matplotlib-devel] Qt backend

[Jody W. <jos...@ma...>]

Any pointers on either finding a Qt backend or writing one?

Thanks,

Jody Winston

Re: [matplotlib-devel] debugging python code

[Andrew S. <str...@as...>]

Jochen Voss wrote:

>I get the following output:
>
>    voss@plonk [~/src/mpl/test] ./test.py --numarray   
>    fisch
>    Floating point exception
>
>Thank you very much,
>Jochen
>  
>

It sounds like you may have hit a nasty glibc bug that caused me much 
head scratching over the months.  Check this thread:

http://aspn.activestate.com/ASPN/Mail/Message/numpy-discussion/2207861

Bottom line:

numarray does The Right Thing and attempts to set up floating point 
exception handling, but older versions of glibc (such as that in Debian 
sarge) have a bug whereby the floating point error bits in the SSE are 
not  properly cleared, leading to a SIGFPE terminating the program the 
next time the SSE unit is used.

One solution:

Rebuild glibc with the appropriate patch.

Re: [matplotlib-devel] debugging python code

[John H. <jdh...@ac...>]

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:


    Jochen> I get the following output:

    Jochen>     voss@plonk [~/src/mpl/test] ./test.py --numarray fisch
    Jochen> Floating point exception

I suggest you rm -rf site-packages/matplotlib and
site-packages/numarray and your matplotlib build directory.  
Then do a clean install of both packages, matplotlib cvs and numarray
1.1.1 or cvs.  Then try again, being mindful of which backend you are
running under with -dSomeBackend and perhaps increasing the verbose
level.

JDH

Re: [matplotlib-devel] debugging python code

[Jochen V. <vo...@se...>]

Hello Perry,

On Wed, Dec 01, 2004 at 01:28:57PM -0500, Perry Greenfield wrote:
> why not "x =3D sin(t)"? That should work. No need to use map or math.sin
true, this work as such but the crash is still there.

> Does it plot interactively? Do you get any error message or does it
> just crash out of python?
No, it does not plot interactively either.
If I run the script

    from matplotlib.matlab import *
    t=3Darange(0,10,0.1)
    x=3Dsin(t)
    plot(t,x)
    print "fisch"
    show()

I get the following output:

    voss@plonk [~/src/mpl/test] ./test.py --numarray  =20
    fisch
    Floating point exception

Thank you very much,
Jochen
--=20
http://seehuhn.de/

[matplotlib-devel] debugging python code

[Jochen V. <vo...@se...>]

Hello,

I tried to use matplotlib with numarray instead of numeric for the
first time, but it seems that it fails for me even for the simplest
examples.  For example the script

    from matplotlib.matlab import *
    from math import sin

    t=3Darange(0,10,0.1)
    x=3Dmap(lambda tt:sin(tt), t)
    plot(t,x)

    savefig("out.ps")

fails during the savefig call with a floating point exception.
Unfortunately there is no backtrace printed, so I have no idea where
exactly the problem lies.

Questions: Is there any easy way to get more information about where
the failure happens?  Is this specific problem known?

All the best,
Jochen
--=20
http://seehuhn.de/

Re: [matplotlib-devel] Several patches: kwargs cleanup, legend-kwargs, legend-fontsize

[Norbert N. <Nor...@gm...>]

Hi there,

seems like we are synchronizing rather badly in our work and our messages to 
the list. :-)

> Before we reapply your patch to raise on bad kwargs, I think it's
> worth getting some input if we want to raise on nonexistent keys...

Ok, there's a point. I did not even think that there would be any controversy, 
but what you point out should certainly be considered.

Basically, this is a question about the philosophy of properties in general: 
Should properties be settable just per-object, or should settings be 
propagated to the children. I believe the current state is not fully 
consistent in that respect.

What you are proposing is an interesting idea, but if it is adopted, it should 
be done in general and not only in certain places. And in that case, it might 
become rather complex. Properties would have to be uniquely identifiable by 
name only. (I.e. all linewidths have to be called just "linewidth", so an 
object that contains different lines that should be configurable 
independently have to be split in separate sub-objects) The passing of 
properties should happen everywhere in the library - otherwise it will be 
more confusing than helpful.

Currently, it seems to me that there is a rather weak distinction between 
properties and just plain kwargs. This should probably be sorted out before 
adopting a policy of passing all kwargs on to the children.

And as for silently ignoring unknown arguments: I still do not really like 
that idea. It smells like a source of hard to find bugs.

Ciao,
Nobbi

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <No...@Ne...>

[matplotlib-devel] Polar plot an smithchart

[<jor...@bo...>]

Hello,

I'm a happy user of matplotlib. I have both a usage question and a more=20
developer oriented question. First the usage question. I have some=20
trouble using the polarplot. I routinely need to plot complex valued=20
data on a polar grid. But it seems the polar plot requires an extra step=20
where I have to compute the magnitude and phase of my data. Is there an=20
easy way around this?

I would like to develop and contribute a smithchart plot routine but I'm=20
not sure what the best way would be to integrate it into=20
matplotlib.matlab. I understand I would need to create a subclass of=20
Axes for the grid but how is this then integrated into the matlab.axes=20
command? A plotsmithchart command should definately understand complex=20
valued data.
A smithchart grid contains a lot of arcs, looking at how the grid is=20
implemented in PolarAxes it seems there are no circle or arc primitives.=20
Is this correct?

for a brief introduction to the smith chart see:
http://en.wikipedia.org/wiki/Smith_chart

Best regards,
J=F6rgen Stenarson

[matplotlib-devel] Patch: cleaning up the pop-mess

[Norbert N. <Nor...@gm...>]

Hi there,

after the mess I created by submitting those patches using dict.pop (which is 
not available in Python 2.2) here is a patch that hopefully solves the 
problems:

As I found out, cbook.py already contained a routine popd which is supposed to 
be a replacement for dict.pop, which is missing in Python2.2. This new patch 
now reverts to my original kwargs-cleanup-patch but replaces pop by popd

The code runs through examples/backend_driver.py (except for some unrelated 
issue in the PS backend which I do not have the time to debug right now)

B.t.w: In axes.py, line 1461, the CVS version contains a typo "gry" instead of 
"get" which is also fixed by this patch.

Ciao,
Nobbi


-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <No...@Ne...>

Re: [matplotlib-devel] propagation of error messages in matplotlib

[Steve C. <ste...@ya...>]

On Wed, 2004-11-24 at 09:34 -0600, John Hunter wrote:
> For one thing, cxx strangely doesn't define an IOError.  I don't know
> if this is simply an oversight.  Perhaps I'll file a bug on the sf
> site....
The Python C API uses 
PyErr_SetFromErrnoWithFilename(PyObject *type, char *filename)
to raise IOError exceptions, perhaps cxx has an equivalent function.

Steve

Re: [matplotlib-devel] Several patches: kwargs cleanup, legend-kwargs, legend-fontsize

[John H. <jdh...@ac...>]

>>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes:

    Norbert> Ouch, sorry, I do not even have 2.2 installed. Guess with
    Norbert> that information, the whole patch becomes bogus.

    Norbert> On the other hand: simpy reverting pop to get leaves you
    Norbert> with the old problem: you have to drop the check for
    Norbert> emptyness of kwargs since legal arguments are not removed
    Norbert> after use. If, on the other hand, you remove this check,
    Norbert> erraneous (p.e. misspelled) arguments are just silently
    Norbert> ignored.

    Norbert> Maybe, a wrapper would solve the problem? How would one
    Norbert> code a replacement for pop that works on 2.2 as well?
    Norbert> Probably easiest by using get and del within a
    Norbert> try..except block? The wrapper could then have a clear
    Norbert> note how to replace it once 2.3 becomes mandatory
    Norbert> sometimes in the future.

I added a method popd to matplotlib.cbook.  It should work just like
d.pop(key) but you call popd(d, key).  Like pop, it accepts a default
value.

Before we reapply your patch to raise on bad kwargs, I think it's
worth getting some input if we want to raise on nonexistent keys.  In
some cases, it might be desirable to be able to do, for example

  legend(handles, labels, linewidth=2, fontsize=12)

From an implementation standpoint, it's easiest to implement something
like this using anonymous **kwargs, and iterate over all the handles
and text objects calling set_someprop(val) if set_someprop exists for
some object.

Ie, rather than making all the keyword args explicit and therefore
having to add explicitly add all the setters for line, text and patch
to the kwargs of Legend, which would become a maintenance problem
(duplication of properties throughout the code), one possible design
is to just put a blanket kwargs at the end and define an Artist update
method to look like (freestyle coding here...)

def update(self, **kwargs):
    for key, val in kwargs.items():
        func = getattr(self, 'set_'+key, None)
        if func is None or not callable(func): continue
        func(val)
        

Then we could do in the legend class

   for o in lines+texts+patches: o.update(kwargs)

The downside of course is that this fails silently if the user
provides a bad kwarg.  The upside is it is a very easy, clean
implementation that scales with the addition of new setters to the
underlying objects.


JDH

Re: [matplotlib-devel] propagation of error messages in matplotlib

[John H. <jdh...@ac...>]

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
    Steve> For an IOError the exception attribute 'filename' is set to
    Steve> the filename. With your example above
    Steve> self.renderer._renderer.write_png(str (filename)) is Agg
    Steve> C++ extension code The line fp = fopen(file_name, "wb");
    Steve> could be changed to something like if ((fp =
    Steve> fopen(file_name, "wb")) == NULL) throw Py::IOError("could
    Steve> not open file", filename);

    Steve> Does this look right John?

Right in principle, but not in practice.

For one thing, cxx strangely doesn't define an IOError.  I don't know
if this is simply an oversight.  Perhaps I'll file a bug on the sf
site....

The larger problem is that the exception constructor doesn't accept
multiple args and concatenate them.  It would be nice if it did.

I added a Printf class to mplutils to ease the burden of making printf
style strings in C++ to make better exceptions, and updated the
exceptions in the image, agg and ft2font extensions.  The standard
usage is

    if ((fp = fopen(file_name, "wb")) == NULL) 
      throw Py::RuntimeError( Printf("Could not open file %s", file_name).str() );

JDH

Re: [matplotlib-devel] propagation of error messages in matplotlib

[Steve C. <ste...@ya...>]

On Wed, 2004-11-24 at 12:06 +0000, Jochen Voss wrote:
> Hello,
> 
> On Fri, Nov 19, 2004 at 10:33:43AM -0600, John Hunter wrote:
> > >>>>> "Jochen" == Jochen Voss <vo...@se...> writes:
> >     Jochen> Slight problem: it might now be a little bit more
> >     Jochen> difficult to include the name of the file which could not
> >     Jochen> be opened in the error message.  The IOError exception
> >     Jochen> will probably only have "permission denied" associated
> >     Jochen> with it.
> > 
> > Looks OK, at least on linux
> > 
> > 
> > >>> file('/sbin/ldconfig', 'w')
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in ?
> > IOError: [Errno 13] Permission denied: '/sbin/ldconfig'
> 
> But sometimes it doesn't give the file name:
> 
>     >>> from matplotlib.matlab import *
>     >>> plot([1,2,3],[2,3,1])
>     [<matplotlib.lines.Line2D instance at 0x41ef774c>]
>     >>> savefig("/forbidden.png")
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in ?
>       File ".../matlab.py", line 1009, in savefig
>         manager.canvas.print_figure(*args, **kwargs)
>       File ".../backends/backend_gtkagg.py", line 69, in print_figure
>         agg.print_figure(filename, dpi, facecolor, edgecolor, orientation)
>       File ".../backends/backend_agg.py", line 379, in print_figure
>         self.renderer._renderer.write_png(str(filename))
>     RuntimeError: could not open file
> 
> I did not investigate what happens here, but if there is an easy way to
> get the file name into the exception we should probably use it.
> 
> All the best,
> Jochen
For an IOError the exception attribute 'filename' is set to the
filename. With your example above self.renderer._renderer.write_png(str
(filename)) is Agg C++ extension code
The line
 fp = fopen(file_name, "wb");
could be changed to something like
 if ((fp = fopen(file_name, "wb")) == NULL)
     throw Py::IOError("could not open file", filename);

Does this look right John?

Steve

Re: [matplotlib-devel] propagation of error messages in matplotlib

[Steve C. <ste...@ya...>]

On Tue, 2004-11-23 at 16:38 -0600, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
>     Steve> I've updated backend_gtk.py in cvs to use a default
>     Steve> exception handler, and noticed a few things in the process:
>     Steve> - sys.excepthook does not catch SystemExit, which is what
>     Steve> we wanted anyway.
> 
> For some reason with matplotlib CVS using backend GTK on linux, I no
> longer recover the linux shell when I close the figure by clicking on
> the 'x' in the figure window
> 
>   > python somefile.py
> 
> I have to use CTRL-C.
> 
This situation happens when the main window is destroyed but
gtk.main_quit() is not called - the gtk.main loop is still running.
I'm not seeing this problem at the moment.

In FigureManagerGTK the 'destroy' signal is connected to Gcf.destroy
(num), which should eventually call

class FigureManagerGTK
    def destroy(self, *args):
        self.window.destroy()
        if Gcf.get_num_fig_managers()==0 and not
matplotlib.is_interactive():
            gtk.main_quit()

I set DEBUG = True and ran a few examples and it showed
FigureManagerGTK.destroy() was being called as expected.
Perhaps Gcf.get_num_fig_managers() is sometimes not 0 when it should be
0 and gtk.main_quit() is not being called.

Steve

Re: [matplotlib-devel] propagation of error messages in matplotlib

[Jochen V. <vo...@se...>]

Hello,

On Fri, Nov 19, 2004 at 10:33:43AM -0600, John Hunter wrote:
> >>>>> "Jochen" =3D=3D Jochen Voss <vo...@se...> writes:
>     Jochen> Slight problem: it might now be a little bit more
>     Jochen> difficult to include the name of the file which could not
>     Jochen> be opened in the error message.  The IOError exception
>     Jochen> will probably only have "permission denied" associated
>     Jochen> with it.
>=20
> Looks OK, at least on linux
>=20
>=20
> >>> file('/sbin/ldconfig', 'w')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> IOError: [Errno 13] Permission denied: '/sbin/ldconfig'

But sometimes it doesn't give the file name:

    >>> from matplotlib.matlab import *
    >>> plot([1,2,3],[2,3,1])
    [<matplotlib.lines.Line2D instance at 0x41ef774c>]
    >>> savefig("/forbidden.png")
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
      File ".../matlab.py", line 1009, in savefig
        manager.canvas.print_figure(*args, **kwargs)
      File ".../backends/backend_gtkagg.py", line 69, in print_figure
        agg.print_figure(filename, dpi, facecolor, edgecolor, orientation)
      File ".../backends/backend_agg.py", line 379, in print_figure
        self.renderer._renderer.write_png(str(filename))
    RuntimeError: could not open file

I did not investigate what happens here, but if there is an easy way to
get the file name into the exception we should probably use it.

All the best,
Jochen
--=20
http://seehuhn.de/