matplotlib-devel Mailing List for matplotlib

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