matplotlib-devel Mailing List for matplotlib (Page 2)

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:


    Fernando> I realize that excepthook is a tempting tool to use, but
    Fernando> I hope you guys reconsider this.  I really think it
    Fernando> would cause many more headaches down the road than those
    Fernando> it initially appears to solve.

OK, good to know.  That was news to me.  Now why is it that ipython
and envisage get to mess around with it and we don't :-) ?

So what is the canonical way to funnel exceptions into GUI dialog
boxes?  Isn't this what sys.except_hook is for?

Actually, it would be fine if matplotlib overrode sys.except_hook and
ipython later came along and overrode that.  Basically, ipython would
be saying, "I know I've got a shell to display errors in, so we don't
need to GUI method".  I don't think matplotlib would have a problem
with that.  Ditto for envisage.  Basically, we would be providing a
default method to get the message to the GUI which could be overriden
by other applications that want to (ipython, envisage, what-have-you).

So I don't really see a danger here, but please educate me!

JDH

John Hunter schrieb:
>>>>>>"Steve" == Steve Chaplin <ste...@ya...> writes:
> 
> 
>     Steve> By subclassing Verbose you group all the functions that
>     Steve> display messages to the user together into one class.  I
>     Steve> may have misunderstood some of the discussion - I agree
>     Steve> with doing all error handling with exceptions, but when you
>     Steve> catch the exception in a GUI I'm assuming you still want to
>     Steve> popup a message to inform the user.  Are you describing
>     Steve> using exceptions and tracebacks without any error messages
>     Steve> for GUI backends? I don't think you can assume a GUI
>     Steve> backend user will see a traceback since the terminal window
>     Steve> may be obscured, iconified or even closed.
> 
> For the GUI error handling, I was assuming we would use the
> except_hook, and do away with error reporting in the verbose class.

I'd like to strongly plead that you stay away from sys.excepthook.

That is the 'last resort' tool to manipulate exceptions, and it's typically 
used by frameworks which need to completely control the python process.  For 
example, ipython puts its internal crash handler in sys.excepthook, so that if 
all else fails, the crash handler generates a very detailed crash report.  But 
all 'normal' exception handling is done by the internal user loop, with manual 
control.

I haven't had time to look in detail, but I even think that ipython pretty 
aggressively reclaims sys.excepthook if user code messes with it.  I wouldn't 
be surprised if other frameworks (like envisage) also used sys.excepthook 
themselves.  Matplotlib is 'only' a plotting library :), and it should IMHO 
play nicely with other code running along with it.  If it gets into a 
foodfight over who owns sys.excepthook, or if it crashes because 
sys.excepthook is not what it thinks it is, I expect serious interoperability 
problems to pop up down the road.

I realize that excepthook is a tempting tool to use, but I hope you guys 
reconsider this.  I really think it would cause many more headaches down the 
road than those it initially appears to solve.

Regards,

f

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> By subclassing Verbose you group all the functions that
    Steve> display messages to the user together into one class.  I
    Steve> may have misunderstood some of the discussion - I agree
    Steve> with doing all error handling with exceptions, but when you
    Steve> catch the exception in a GUI I'm assuming you still want to
    Steve> popup a message to inform the user.  Are you describing
    Steve> using exceptions and tracebacks without any error messages
    Steve> for GUI backends? I don't think you can assume a GUI
    Steve> backend user will see a traceback since the terminal window
    Steve> may be obscured, iconified or even closed.

For the GUI error handling, I was assuming we would use the
except_hook, and do away with error reporting in the verbose class.

For the regular verbose reporting, I'm not averse to plugging it into
a GUI dialog, but I'm not sure this is useful.  As I wrote before,
this will mainly be used in debug situations when we can probably
assume a user has access to a shell output.  They can always capture
it to a file using the regular rc mechanism of setting verbose.fileo.

If we did want to do it in a GUI, we would have to be fairly careful
about the implementation, so that the GUI cached sequential methods
and only displayed them if some time interval (eg 100ms) had lapsed
with no new messages.  This would be used to prevent the curse of 20
popups.  This could presumably be done in GTK with an idle handler and
a changed timestamp.

Alternatively, it could be done in the verbose base class itself,
implemented using threads, but I'm a little wary of the extra
complexity here.  

That said, I think that having the figure manager define a
popup_dialog method would be generally useful.  

    Steve> It does look like they are all non-fatal. I guess the fatal
    Steve> ones are the ones that matplotlib does not anticipate or
    Steve> catch, thinks like faulty installations, missing libraries
    Steve> etc. At the moment these would cause matplotlib to
    Steve> terminate but if we add a default exception handler we will
    Steve> start catching these also.  We could have a policy for
    Steve> matplotlib to catch all exceptions and always attempt to
    Steve> continue, and if it becomes unusable its up to the user to
    Steve> close the window. Also we could recognise some situations
    Steve> (if there are any) where we need to terminate, so we raise
    Steve> SystemExit and set the default exception handler to
    Steve> terminate on SystemExit and continue on all other cases.

Sounds right to me....  So in summary, if all agree and we've covered
all the bases, Verbose.report_error and error_msg disappear and are
replaced by regular exceptions.  matplotlib code can raise a
SystemExit for the relatively rare fatal errors.  GUIs define
sys.excepthook = exception_handler following the lead of Steve's
implementation in backend_gtk (in CVS).

verbose.report is left untouched for now but may be hooked into a GUI
reporting functionality if we can resolve the issues of whether this
is desirable and how to handle caching of many independent sequential
messages.

JDH

On Sat, 2004-11-20 at 17:26 -0600, John Hunter wrote:
> As for report_error, subclassing Verbose, or using figure manager for
> this as Jochen has suggested, are both workable solutions, but what
> does it ultimately buy us?  I am inclined to the logically cleaner
> solution of doing all error handling with exceptions, using a hook
> like you've provided for GUIs.
By subclassing Verbose you group all the functions that display messages
to the user together into one class.
I may have misunderstood some of the discussion - I agree with doing all
error handling with exceptions, but when you catch the exception in a
GUI I'm assuming you still want to popup a message to inform the user.
Are you describing using exceptions and tracebacks without any error
messages for GUI backends? I don't think you can assume a GUI backend
user will see a traceback since the terminal window may be obscured,
iconified or even closed.

> I grepped for all the current uses of report error (included below) --
> on quick inspection none of these appear fatal for a GUI.  I think
> simply informing the user of the error may suffice.  Can you provide
> an example of where we may need to exit (and would it suffice for the
> raiser to simply raise a SystemExit for this case?)

It does look like they are all non-fatal. I guess the fatal ones are the
ones that matplotlib does not anticipate or catch, thinks like faulty
installations, missing libraries etc. At the moment these would cause
matplotlib to terminate but if we add a default exception handler we
will start catching these also.
We could have a policy for matplotlib to catch all exceptions and always
attempt to continue, and if it becomes unusable its up to the user to
close the window. Also we could recognise some situations (if there are
any) where we need to terminate, so we raise SystemExit and set the
default exception handler to terminate on SystemExit and continue on all
other cases.

Steve

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> I was thinking of something like:

    Steve> class VerboseGTK(Verbose): def report_error(self, s):
    Steve> dialog = gtk.MessageDialog( parent = None, type =
    Steve> gtk.MESSAGE_ERROR, buttons = gtk.BUTTONS_OK, message_format
    Steve> = msg) dialog.run() dialog.destroy()

    Steve> So that the matlab interface can call
    Steve> verbose.report_error() and for image backends it writes to
    Steve> stdout and for GUI backends it pops up a message dialog.

    Steve> You can hook a GTK dialog into unhandled Python exceptions
    Steve> with: import sys

    Steve> def exception_handler(type, value, tb): """Handle uncaught
    Steve> exceptions""" error_msg_gtk(value)

    Steve> sys.excepthook = exception_handler

    Steve> (I've added this to backend_gtk.py in cvs if you want to
    Steve> try it out)

As for report_error, subclassing Verbose, or using figure manager for
this as Jochen has suggested, are both workable solutions, but what
does it ultimately buy us?  I am inclined to the logically cleaner
solution of doing all error handling with exceptions, using a hook
like you've provided for GUIs.

The only lingering advantage I see for a report_error call w/o an
exception being raised is it presents a cleaner error message, which
is nice for newbies.  I have a python 3000-esque design philosophy for
matplotlib -- I want it to be accessible to newbies.  And a simple
message "function blah expects 1 or 2 arguments" is much more likely
to be read and parsed by a newbie, who in my experience will disregard
a traceback simply because it often appears unreadable, until you are
trained to read from the bottom up, which is counter intuitive to
some.

Are there other advantages to report_error that I'm missing, and if
not, does the readability issue justify circumventing the default
exception handling mechanism?  My inclination is that it doesn't.

    Steve> But you still need to decide how to handle the exceptions -
    Steve> with some you need to terminate the program, with others
    Steve> its safe to continue. It may mean you end up writing a
    Steve> complicated generic exception handler that tries to handle
    Steve> every possible exception. In that case handling exceptions
    Steve> individually, the usual way might be better, possibly using
    Steve> the sys.excepthook to handle the remaining uncaught
    Steve> exceptions, or using it when you want to terminate the
    Steve> program and want to popup a message saying "Fatal error..."

I grepped for all the current uses of report error (included below) --
on quick inspection none of these appear fatal for a GUI.  I think
simply informing the user of the error may suffice.  Can you provide
an example of where we may need to exit (and would it suffice for the
raiser to simply raise a SystemExit for this case?)

JDH

'Error: %s'%msg
'Unable to allocate color %1.3f, %1.3f, %1.3f; using nearest neighbor' % rgb
'Error: %s'% msg
'Error: %s' % msg
'Could not load font file "%s"'%fname
'Error: %s'% msg
'Could not load filename for text "%s"'%fname
msg
'Could not find bitmap file "%s"; dying'%bmpFilename
'backend_gtk could not import mathtext (build with ft2font')
'Error: %s' % exc
'The GTK backend cannot draw text at a %i degree angle, try GtkAgg instead' % angle
'mathtext not supported: %s' % exc
"Could not renderer vertical text", s
"cairo.numpy module required for draw_image(")
'Mathtext not implemented yet'
'Unrecognized cap style.  Found %s' % cs
'Unrecognized join style.  Found %s' % js
"%s: %s" % (exc.filename, exc.strerror)
'Format "%s" is not supported.\nSupported formats: %s.' %
./__init__.py:    def report_error(self, s:
'Could not find .matplotlibrc; using defaults'
message
'Illegal line #%d\n\t%s\n\tin file "%s"' % (cnt, line, fname)
'%s is deprecated in .matplotlibrc - use %s instead.' % (key, alt)
'Bad key "%s" on line %d in %s' % (key, cnt, fname)
'Bad val "%s" on line #%d\n\t"%s"\n\tin file "%s"\n\t%s' % (val, cnt, line, fname, msg)
'unrecognized backend %s.\n' % arg +\
./backend_bases.py:    verbose.report_error('Error: %s'% msg
"ColormapJet deprecated, please use cm.jet instead"
"Grayscale deprecated, please use cm.gray instead"
'urlopen( failure\n' + url + '\n' + exc.strerror[1])
"Could not open font file %s"%fpath
"Could not open font file %s"%fpath
 msg % name
'Could not match %s, %s, %s.  Returning %s' % (name, style, variant, self.defaultFont)
'Unrecognized location %s. Falling back on upper right; valid locations are\n%s\t' %(loc, '\n\t'.join(self.codes.keys()))
'Unrecognized line style %s' %( linestyle, type(linestyle))
'Unrecognized marker style %s'%( marker, type(marker))
'unrecognized symbol "%s"' % sym
'unrecognized symbol "%s, %d"' % (sym, num)
'Coherence is calculated by averaging over NFFT length segments.  Your signal is too short for your choice of NFFT'
'Dimension error'
'Second argument not permitted for matrices'
__doc__
'Unrecognized location %s. Falling back on bottom; valid locations are\n%s\t' %(loc, '\n\t'.join(self.codes.keys()))
'AutoLocator illegal dataInterval range %s; returning NullLocator'%d
'Unrecognized location %s. Falling back on upper right; valid locations are\n%s\t' %(loc, '\n\t'.join(self.codes.keys()))


    Steve> Steve





    Steve> -------------------------------------------------------
    Steve> This SF.Net email is sponsored by: InterSystems CACHE FREE
    Steve> OODBMS DOWNLOAD - A multidimensional database that combines
    Steve> robust object and relational technologies, making it a
    Steve> perfect match for Java, C++,COM, XML, ODBC and
    Steve> JDBC. www.intersystems.com/match8
    Steve> _______________________________________________
    Steve> Matplotlib-devel mailing list
    Steve> Mat...@li...
    Steve> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hello,

On Sat, Nov 20, 2004 at 11:53:01AM +0800, Steve Chaplin wrote:
> I was thinking of something like:
>=20
> class VerboseGTK(Verbose):
>     def report_error(self, s):
>         dialog =3D gtk.MessageDialog(
>             parent         =3D None,
>             type           =3D gtk.MESSAGE_ERROR,
>             buttons        =3D gtk.BUTTONS_OK,
>             message_format =3D msg)
>         dialog.run()
>         dialog.destroy()
Alternatively we could make report_error a figure_manager method.
If could default to

class FigureManagerBase:
    def report_error(self, s):
	sys.stderr.write("error: %s\n"%s)

And FigureManagerGTK could overload it with the above code to generate
an error box.

Reasons why I would prefer this:

1) I do not like these global variables which are set on module import
  at all.  Using the VerboseGTK idea we would get another instance of this,
  namely something like "currentVerboseClass=3DVerboseBackend" or such.

  We already have something like this for figure managers, so no new instan=
ce
  of this would be created with my suggestion.

  Reporting errors would then work like this:

      manager =3D get_current_fig_manager()
      manager.canvas.report_error(message)

  which could be wrapped into a function.

2) The main functionality of the Verbose class seems to be,
  that the user can select how many messages he wants to see.
  Error messages (at least fatal ones) should be presented to
  the user in any case, so for me reporting errors does not
  look like an application of the Verbose class.

What do you think?

Jochen
--=20
http://seehuhn.de/

On Fri, 2004-11-19 at 09:23 -0600, John Hunter wrote:
> I think you are right that the plethora of error reporting strategies
> is causing confusion, especially for me!  I like the idea of the GUI
> backends overriding placing a hook into the python exception handling
> process.  One possibility would be to do away with
> verbose.report_error and error_msg.  The GUIs hook into the exception
> message, and anywhere we want to report an error we raise a python
> exception.  And we continue to use verbose.report as before.
> 
> I just checked backend_ps and the only place is uses error_msg is
> 
>     error_msg_ps('Could not open %s for writing' % outfile)
> 
> which would be more naturally handled as an exception anyway.
> 
> Steve, could you look into hooking a GTK dialog into the python
> exception reporting mechanism to see if this is viable?  In summary,
> the thought is
> 
>   * use verbose only for non-error reporting
> 
>   * use exceptions for all error reporting
> 
>   * work some GUI magic to transparently get the errors forwarded to a
>     dialog box w/o using special functions
> 
> As for verbose.report, I'm not convinced it is a good idea to hook
> this into the GUI.  For one thing, some reporting occurs before the
> backend is determined.  For another, it would also require some
> caching of messages because if 30 messages generate 30 popups it will
> get annoying quick.  These things are manageable, but I think the main
> use for verbose.report is debugging a problem, in which case simply
> having the messages go to a stdout or a file may be the best place for
> them.
> 
> JDH
I was thinking of something like:

class VerboseGTK(Verbose):
    def report_error(self, s):
        dialog = gtk.MessageDialog(
            parent         = None,
            type           = gtk.MESSAGE_ERROR,
            buttons        = gtk.BUTTONS_OK,
            message_format = msg)
        dialog.run()
        dialog.destroy()

So that the matlab interface can call verbose.report_error() and for
image backends it writes to stdout and for GUI backends it pops up
a message dialog.

You can hook a GTK dialog into unhandled Python exceptions with:
import sys

def exception_handler(type, value, tb):
    """Handle uncaught exceptions"""
    error_msg_gtk(value)

sys.excepthook = exception_handler

(I've added this to backend_gtk.py in cvs if you want to try it out)

But you still need to decide how to handle the exceptions - with some
you need to terminate the program, with others its safe to continue. It
may mean you end up writing a complicated generic exception handler that
tries to handle every possible exception. In that case handling
exceptions individually, the usual way might be better, possibly using
the sys.excepthook to handle the remaining uncaught exceptions, or using
it when you want to terminate the program and want to popup a message
saying "Fatal error..."

Steve

>>>>> "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'

Hello,

On Fri, Nov 19, 2004 at 09:23:36AM -0600, John Hunter wrote:
> In summary, the thought is
>=20
>   * use verbose only for non-error reporting
>=20
>   * use exceptions for all error reporting
I agree with this.

>   * work some GUI magic to transparently get the errors forwarded to a
>     dialog box w/o using special functions
Here I have no opinion until I understand the special kind
of magic which is going to be used here.

> For another, it would also require some
> caching of messages because if 30 messages generate 30 popups it will
> get annoying quick.
Yes, we have to be careful here.

As nobody objected to this part of the plan, I changed the PostScript
backend in CVS as follows:

    diff -u -r1.13 backend_ps.py
    --- backend_ps.py       13 Nov 2004 11:41:54 -0000      1.13
    +++ backend_ps.py       19 Nov 2004 16:23:13 -0000
    @@ -529,10 +529,7 @@
		 basename, ext =3D os.path.splitext(outfile)
		 if not ext: outfile +=3D '.ps'
		 isEPSF =3D ext.lower().startswith('.ep')
    -            try:
    -                fh =3D file(outfile, 'w')
    -            except IOError:
    -                error_msg_ps('Could not open %s for writing' % outfile)
    +            fh =3D file(outfile, 'w')
		 needsClose =3D True
		 title =3D outfile

Slight problem: it might now be a little bit more difficult to include
the name of the file which could not be opened in the error message.
The IOError exception will probably only have "permission denied" associated
with it.

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

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
    Steve> At the moment we have error_msg(), the Verbose class and
    Steve> exceptions all working in the same area and a bit of
    Steve> confusion as to which one does what. I don't think we need
    Steve> all three.

    Steve> I suggest - using exceptions to handle errors that may
    Steve> terminate the program, and allowing the matlab interface,
    Steve> GUI backends and user scripts to catch these exceptions.  -
    Steve> using verbose for all reporting - merging error_msg() into
    Steve> the Verbose class (with the GUI backends possibly
    Steve> subclassing Verbose to provide a popup error dialog)

I think you are right that the plethora of error reporting strategies
is causing confusion, especially for me!  I like the idea of the GUI
backends overriding placing a hook into the python exception handling
process.  One possibility would be to do away with
verbose.report_error and error_msg.  The GUIs hook into the exception
message, and anywhere we want to report an error we raise a python
exception.  And we continue to use verbose.report as before.

I just checked backend_ps and the only place is uses error_msg is

    error_msg_ps('Could not open %s for writing' % outfile)

which would be more naturally handled as an exception anyway.

Steve, could you look into hooking a GTK dialog into the python
exception reporting mechanism to see if this is viable?  In summary,
the thought is

  * use verbose only for non-error reporting

  * use exceptions for all error reporting

  * work some GUI magic to transparently get the errors forwarded to a
    dialog box w/o using special functions

As for verbose.report, I'm not convinced it is a good idea to hook
this into the GUI.  For one thing, some reporting occurs before the
backend is determined.  For another, it would also require some
caching of messages because if 30 messages generate 30 popups it will
get annoying quick.  These things are manageable, but I think the main
use for verbose.report is debugging a problem, in which case simply
having the messages go to a stdout or a file may be the best place for
them.

JDH

On Thu, 2004-11-18 at 18:05 +0000, Jochen Voss wrote: 
> 4) some ideas:
> 
>   - The backends could return errors via python standard exceptions
>     without printing messages and such.  This leads to simple code,
>     feels quite Pythonic, makes the backends more independent of the
>     error reporting policy and at the moment seems to be the only sane
>     solution to me.
> 
>   - The backends should have a function which the matlab interface can
>     call to report errors to the user.  This should pop up a dialog
>     etc.  on GUI backends and just print the message to stderr for
>     non-GUI backends.  It should not terminate the program.
I agree with these ideas.

> 7) Conclusions:
> 
>   I suggest the following.
> 
>   - Change backend_template.py and all the other non-GUI backends to
> 
> 	def error_msg_ps(msg, *args):
> 	    """
> 	    Signal an error condition.
> 	    """
> 	    sys.stderr.write('Error: %s' % msg)
I'd prefer to merge error_msg into the Verbose class, or just delete it.

>   - Change all callers of error_msg to terminate the program after the
>     call when appropriate
Agree

>   - Remove the verbose.report_error function and replace it with Python
>     exceptions etc.
Agree

> What do you think?
At the moment we have error_msg(), the Verbose class and exceptions all
working in the same area and a bit of confusion as to which one does
what. I don't think we need all three. 

I suggest
- using exceptions to handle errors that may terminate the program, and
allowing the matlab interface, GUI backends and user scripts to catch
these exceptions.
- using verbose for all reporting
- merging error_msg() into the Verbose class (with the GUI backends
possibly subclassing Verbose to provide a popup error dialog)

Steve

John Hunter schrieb:

> try : save_ps(fname)
> except IOError, msg:
>    verbose.report_error('Backend PS failed to save %s'%fname)
>    raise IOError(msg)

Just 'raise' is enough, python by default will re-raise the original exception 
untouched.

I'll leave this discussion to you guys, I don't know the matplotlib code 
enough to contribute anything really useful.  My only point is that reusing 
SystemExit for other purposes, with additional information encoded in the 
message, is IMHO a bad idea.  There's a reason why exceptions make up a class 
hierarchy: this allows you to use classes for the flow control mechanisms, 
leaving the string messages simply as additional information mainly for the 
user.  Since these messages are potentially locale-sensitive, and can change 
over time (spelling, capitalization, etc), it's just not a good idea to base 
code behaviour on them.

Cheers,

f

Hello,

I tried to think a little bit more systematically about the way
error conditions and messages are passed around in matplotlib.

1) There see to be several kinds of object:

  - informational messages like the output of --verbose-debug-annoying
  - error messages which the matlab interface passes to the
    backends to have them displayed to the user
  - error conditions reported by the backends to the caller

2) Typical scenarios:

  a) A user tries to debug some installation problem by using
     the --verbose-debug-annoying option or similar.  This generates
     potentially a lot of messages which should shown to the user.
     Dumping them all to stdout or stderr seems fine here.

  b) A script calls the matlab interface functions with invalid arguments.
     The user should get an error message.  In a GUI backend this error
     message might pop up in a message window or similar.

  c) A backend encounters an error condition, e.g. if it cannot open
     the file, cannot load a font etc.  If a GUI backend is active
     the error message should be displayed by the GUI backend,
     otherwise it should be printed to stderr or similar.

Is this so far correct?

3) Required or almost required properties of the implementation:

  - the user should be able to customise how much information he
    sees, e.g. by using the --verbose-* options

  - The GUI backends should not be terminated if there is an error
    while saving a file etc.

4) some ideas:

  - The backends could return errors via python standard exceptions
    without printing messages and such.  This leads to simple code,
    feels quite Pythonic, makes the backends more independent of the
    error reporting policy and at the moment seems to be the only sane
    solution to me.

  - The backends should have a function which the matlab interface can
    call to report errors to the user.  This should pop up a dialog
    etc.  on GUI backends and just print the message to stderr for
    non-GUI backends.  It should not terminate the program.

    Rationale for not calling verbose.report_error in this function:
    the GUI backend reports the error on its own (dialog, status line,
    etc), so it does not need to use verbose.report_error
    additionally.  When the PostScript backend is called from the GUI
    backend, then the GUI backends error report function will be used,
    what PostScript does does not matter.  In all other cases
    displaying the error message to stderr seems the only useful thing
    to do (e.g. disabling it is not useful).

5) the verbose.report mechanism:

  At the moment I am not sure how this fits in here.  Maybe it should
  only be used for non-error messages?

  What is configurable here?  The user can choose the amount of
  messages he wants to see.  Anything else?

6) Analysis of the three scenarios above:

  a) --verbose-* output:

     Here the flow of control is straightforward.  At random places
     there are calls to verbose.report.  These are either discarded
     or printed to stdout.  This is currently done by the Verbose class.

  b) invalid arguments

     Again, this is simple: the matlab interface calls error_msg,
     the GUI backend does something useful with the message.

  c) backend error conditions

     This seems to be the most complex scenario.  I think this should
     work as follows: the backend raises the standard Python exception,
     e.g IOError.  If the GUI backend calls the PostScript backend,
     it should catch any exception from the PostScript backend call,
     and tell the user about it.

     If the user in a script calls e.g. "savefig('/fig1.eps')" and has
     no write permission for the root directory, then he will get the
     Python exception and can do with it whatever he likes.

7) Conclusions:

  I suggest the following.

  - Change backend_template.py and all the other non-GUI backends to

	def error_msg_ps(msg, *args):
	    """
	    Signal an error condition.
	    """
	    sys.stderr.write('Error: %s' % msg)

    Maybe even make this function a class method of the
    FigureManagerBase class?  (the "error_msg =3D error_msg_..."
    assignments seem hackish.)

  - Change all callers of error_msg to terminate the program after the
    call when appropriate

  - Remove the verbose.report_error function and replace it with Python
    exceptions etc.

What do you think?

Jochen
--=20
http://seehuhn.de/

>>>>> "Jochen" == Jochen Voss <vo...@se...> writes:
    Jochen> Sorry, I am still not clear about this function.  What is
    Jochen> its purpose?  When will it be called?

Good question.  In simple cases the matlab interface calls this
function if illegal arguments are passed, eg if you call axis with the
wrong signature

    if len(v) != 4:
        error_msg('v must contain [xmin xmax ymin ymax]')
        return 

This just displays the error and returns, non-fatal.  In other
functions, it does forwards the traceback message on to the error_msg
function and then re-raises.  This is done to prevent the gui from
swallowing the traceback.

But there is no coherent policy in the matlab interface in how error
handling is done.  Eg, in savefig, which calls print_figure

    for key in ('dpi', 'facecolor', 'edgecolor'):
        if not kwargs.has_key(key):
            kwargs[key] = rcParams['savefig.%s'%key]

    manager = get_current_fig_manager()
    manager.canvas.print_figure(*args, **kwargs)

There is no try/except handling of print_figure.  

The leads to the question: which exceptions should the matlab
interface handle when calling the backend?  Do we do the extra work of
defining the exception policy of backend functions and just catch
these.  Or do we catch all exceptions, forward the exception message
to error_msg, and then re-raise the identical exception.  The latter
sounds reasonably coherent.

Or do we start over with a new design?  Wandering into murky waters
here, is it possible for the GUIs simply to add an exception hook to
hook the tracebacks into a GUI dialog box, and simply do away with
error_msg all-together?  I'm starting to like the sound of that.

JDH

Hello John,

On Thu, Nov 18, 2004 at 10:24:57AM -0600, John Hunter wrote:
> I suggest we rework the image backends to not define an error message
> function at all, but simply to import and reuse the one from
> backend_bases.  This will make it easier to change the policy in a
> single place.  Secondly, an image backend should never call this
> function, it should be reserved for the matlab interface simply to
> insure a consistent interface between the various backends.
Sorry, I am still not clear about this function.  What is its purpose?
When will it be called?

> Thirdly, the image backends should verbose.report/report_error where
> appropriate, and raise when indicated.  GUI backends can catch these
> exceptions and handle them how they want.
This sounds fine for me.

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

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:


    Steve> I tried this calling the SVG backend directly and by
    Steve> switching to the SVG backend from the GTK backend and it
    Steve> works OK.

This gets back to our previous unresolved discussion on error handling
in the image backends.  I think the way it is done now is a historical
accident.  In the olden days, pre matplotlib-0.50, there was no
ability to switch backends, or to use an image backend within a GUI
(eg gtkcairo, gtkagg).  So the image backends were free-standing and
their error handling didn't have much impact outside their own scope.
Now they clearly do.

The second design problem was that I preferred simple error messages
rather than exceptions with tracebacks.  This grew out of my
experience with users of my GUIs who basically will not read a
traceback - they appear to have blinders on.  However, they will read
a simple message like

  Could not save file blah, blah, blah.

But as we are seeing, this approach (simple message, SystemExit)
doesn't scale well and isn't appropriate when GUIs are calling image
backends.  

I suggest we rework the image backends to not define an error message
function at all, but simply to import and reuse the one from
backend_bases.  This will make it easier to change the policy in a
single place.  Secondly, an image backend should never call this
function, it should be reserved for the matlab interface simply to
insure a consistent interface between the various backends.  Thirdly,
the image backends should verbose.report/report_error where
appropriate, and raise when indicated.  GUI backends can catch these
exceptions and handle them how they want.

In the case at hand, it might be sensible for backend ps to catch an
IO Error, report to verbose report_error, and then rethrow the error
with the message.  Something like

try : save_ps(fname)
except IOError, msg:
   verbose.report_error('Backend PS failed to save %s'%fname)
   raise IOError(msg)


Thoughts?

JDH

Hello Steve,

On Thu, Nov 18, 2004 at 11:38:10PM +0800, Steve Chaplin wrote:
> At the moment the PS backend does
>   try:
>       fh =3D file(outfile, 'w')
>   except IOError:
>       error_msg_ps('Could not open %s for writing' % outfile)
>=20
> which translates into
>   try:
>       fh =3D file(outfile, 'w')
>   except IOError:
>       verbose.report_error('Error: Could not open %s for writing' %
> outfile)
>       sys.exit()
>=20
> The backend does not do any cleanup after the exception, so I think it
> could be changed to just
>       fh =3D file(outfile, 'w')
As I understood John, the plan is to report error messages via the
verbose.report_error function.  Where would this be called with
the modified code (especially when there is no GUI backend active)?

> allowing the exception terminate the program with the error message
> appearing at the end of the traceback.
This looks really ugly to me.  But maybe it is the script author's
responsibility to catch this if he cares about this.

> Then the GUI backends can then do
>     from backend_svg import FigureCanvasSVG as FigureCanvas
>     try:
>         fc =3D self.switch_backends(FigureCanvas)
>         fc.print_figure(filename, dpi, facecolor, edgecolor,
> orientation)
>     except IOError, exc:
>         error_msg("%s: %s" % (exc.filename, exc.strerror), parent=3Dself)
What about other exceptions thrown by the backend?

I see that passing the original exception to the caller is cleaner
and I would be happy to change the PostScript backend to do this.
The only question for me is: how and when is the "report_error" function
to be used?

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

On Wed, 2004-11-17 at 10:54 -0700, Fernando Perez wrote:
> Jochen Voss schrieb:
> > Hello Steve,
> > 
> > On Wed, Nov 17, 2004 at 11:00:32PM +0800, Steve Chaplin wrote:
> > 
> >>I don't think failure to save a file should be a fatal error.
> >>Perhaps PS/SVG print_figure() could raise an exception for the GUI
> >>backend to catch so it can popup an error message and continue.
> > 
> > Even now you can probably (not tried) catch the SystemExit
> > exception and prevent the program from aborting.
> > Do you think raising SystemExit like
> > 
> >     raise SystemExit("error while writing file: permission denied")
> > 
> > would be good enough.  The GUI frontend could catch SystemExit,
> > check whether the associated value is a string, and then display
> > this string in an error message box.
> > 
> > What do you think?
> 
> Bad design.  Doing exception analysis based on string matching for the message 
> is very brittle.  A single change in capitalization of the message can break 
> things down the road.
> 
> It's _far_ better to either:
> 
> 1. have the ps/svg backends do whatever cleanup they want, and then reraise 
> the original exception unchanged
> 
> 2. or simply make a matplotlib.SaveError exception which can be explicitly 
> caught based on class matching, which is the preferred python way of doing this.
> 
> Best,
> 
> f
At the moment the PS backend does
  try:
      fh = file(outfile, 'w')
  except IOError:
      error_msg_ps('Could not open %s for writing' % outfile)

which translates into
  try:
      fh = file(outfile, 'w')
  except IOError:
      verbose.report_error('Error: Could not open %s for writing' %
outfile)
      sys.exit()

The backend does not do any cleanup after the exception, so I think it
could be changed to just
      fh = file(outfile, 'w')
allowing the exception terminate the program with the error message
appearing at the end of the traceback.

Then the GUI backends can then do
    from backend_svg import FigureCanvasSVG as FigureCanvas
    try:
        fc = self.switch_backends(FigureCanvas)
        fc.print_figure(filename, dpi, facecolor, edgecolor,
orientation)
    except IOError, exc:
        error_msg("%s: %s" % (exc.filename, exc.strerror), parent=self)

I tried this calling the SVG backend directly and by switching to the
SVG backend from the GTK backend and it works OK.

Steve

Hello,

On Wed, Nov 17, 2004 at 10:54:49AM -0700, Fernando Perez wrote:
> Bad design.  Doing exception analysis based on string matching for the=20
> message is very brittle.  A single change in capitalization of the messag=
e=20
> can break things down the road.
Sorry, maybe I was not clear enough.
What I tried to suggest was:

1) GUI backends should catch the SystemExit exception from the PS backend,
  thus being able to continue running even if the backend aborts with an
  error.

2) GUI backends should in case that they caught a SystemExit exception
  notify the user that saving the figure as PostScript failed.  If
  the exception is associated with an error message string, they could
  display this string to the user.

> 1. have the ps/svg backends do whatever cleanup they want, and then rerai=
se=20
> the original exception unchanged
>=20
> 2. or simply make a matplotlib.SaveError exception which can be explicitl=
y=20
> caught based on class matching, which is the preferred python way of doin=
g=20
> this.
Maybe.  But how is any information except "the backend failed with
error message ..." useful to the GUI?  Would it act differently on
an font-not-found condition then it would on a save-failed one?

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

Jochen Voss schrieb:
> Hello Steve,
> 
> On Wed, Nov 17, 2004 at 11:00:32PM +0800, Steve Chaplin wrote:
> 
>>I don't think failure to save a file should be a fatal error.
>>Perhaps PS/SVG print_figure() could raise an exception for the GUI
>>backend to catch so it can popup an error message and continue.
> 
> Even now you can probably (not tried) catch the SystemExit
> exception and prevent the program from aborting.
> Do you think raising SystemExit like
> 
>     raise SystemExit("error while writing file: permission denied")
> 
> would be good enough.  The GUI frontend could catch SystemExit,
> check whether the associated value is a string, and then display
> this string in an error message box.
> 
> What do you think?

Bad design.  Doing exception analysis based on string matching for the message 
is very brittle.  A single change in capitalization of the message can break 
things down the road.

It's _far_ better to either:

1. have the ps/svg backends do whatever cleanup they want, and then reraise 
the original exception unchanged

2. or simply make a matplotlib.SaveError exception which can be explicitly 
caught based on class matching, which is the preferred python way of doing this.

Best,

f

Hello Steve,

On Wed, Nov 17, 2004 at 11:00:32PM +0800, Steve Chaplin wrote:
> I don't think failure to save a file should be a fatal error.
> Perhaps PS/SVG print_figure() could raise an exception for the GUI
> backend to catch so it can popup an error message and continue.
Even now you can probably (not tried) catch the SystemExit
exception and prevent the program from aborting.
Do you think raising SystemExit like

    raise SystemExit("error while writing file: permission denied")

would be good enough.  The GUI frontend could catch SystemExit,
check whether the associated value is a string, and then display
this string in an error message box.

What do you think?

Jochen
--=20
http://seehuhn.de/

I've noticed a problem as follows:

You run a GUI backend (GTK, GTKAgg etc) and want to save a figure.
You select the toolbar save button and type in a .ps or .svg filename
and select save.
The GUI backend switches to the PS/SVG backend to save the file.
If there is a problem saving the file, for example you do not have write
permission to the directory, PS/SVG backends will kill your GUI
application with sys.exit()

I don't think failure to save a file should be a fatal error.
Perhaps PS/SVG print_figure() could raise an exception for the GUI
backend to catch so it can popup an error message and continue.

Steve

Hi there,

again a few patches, mostly independent but somewhat interconnected:

axes-kwargs:
	a general cleanup of the code in axes.py - in several places, kwargs was 
handled inconsistently, ignoring surplus arguments. I went through all uses 
of kwargs and made sure that every argument is either used or reported as 
error

legend-fontsize:
	a tiny hack to make Legend respect the FONTSIZE parameter correctly. (up to 
now, it was plainly ignored)

legend-kwargs:
	have Legend.__init__ respect a bunch of kwargs, overriding the global 
defaults. Also Axes.legend passes these arguments through correctly

Ciao,
Norbert

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

Hello Steve,

On Sat, Nov 13, 2004 at 06:38:57PM +0800, Steve Chaplin wrote:
> I used the PS-backend today and I think there's a problem with landscape
> plots. When I view the PS files with 'gv' it looks like the bounding box
> is landscape but the figure is drawn as portrait.
Thanks for catching this.  It can be fixed with the following
patch (already in CVS):

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- backend_ps.py.~1.12.~	2004-11-10 23:50:32.000000000 +0000
+++ backend_ps.py	2004-11-13 11:34:20.000000000 +0000
@@ -558,6 +558,7 @@
=20
         if isLandscape:
             xo, yo =3D 72*paperHeight - yo, xo
+            llx, lly, urx, ury =3D lly, llx, ury, urx
             rotation =3D 90
         else:
             rotation =3D 0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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

On Fri, 2004-11-12 at 20:22 -0800, matplotlib-devel-
re...@li... wrote:
> I checked in the patch yesterday evening.  The patch decreased the
> total size of the PostScript files generated by backend_driver.py from
> 37MB to 31MB.
> 
> All the best,
> Jochen
> --=20
> http://seehuhn.de/

Jochen,
I used the PS-backend today and I think there's a problem with landscape
plots. When I view the PS files with 'gv' it looks like the bounding box
is landscape but the figure is drawn as portrait.

Regards,
Steve