matplotlib-devel Mailing List for matplotlib

>>>>> "Ted" == Ted Drain <ted...@jp...> writes:

    Ted> I would vote for not having GUI messages being popped up from
    Ted> a script.  A quick poll of our users also indicates that they
    Ted> expect script errors to be like python and appear in the
    Ted> script.

Agreed -- what designed to ease the life of point and click windows
users has turned into a monster that is bogging us down.

    Ted> Could we set some type of option in the config file that
    Ted> would allow either behavior?

No, afraid not.  All that crappy error handling cruft is going in the
heap.  It's exceptions all the way through.

I've actually already banished every usage of error_msg from my local
tree.  I think verbose.report_error should go the same way -- all
opposed, say "Nay"!

Assuming that report_error should die too, the remaining question is
how to best handle deprecation or non fatal errors 
or something where we want to warn but fall back on a default
behavior.  My vote is

  import warnings
  warnings.warn('This function is deprecated')

JDH

I like the idea of keeping pylab simpler.  It's too bad there is no easy 
way to handle executable python code from Windows.  Of course, windows 
users could write a small wrapper that traps exceptions, prints them, and 
then waits for a keypress - but that might be too much to ask.  I think 
about it some more...

I would vote for not having GUI messages being popped up from a script.  A 
quick poll of our users also indicates that they expect script errors to be 
like python and appear in the script.

One thing to think about is that if you dump all errors into a GUI, you 
limit the ability to use matplotlib in some applications.  For example, 
we're considering writing a real-time plotting application that reads data 
from the network and keeps a screen updated of the current status (in this 
case, we want to plot real-time data read from spacecraft telemetry) for 
several teams to look at.  This application needs to be very robust and 
handle errors explicitly so that it remains running at all times.  It's 
generally going to be displayed on a monitor away from the computer for 
people to see.

Since this is an automated system, it could end up trying to executing some 
plot command that is invalid (the down link data sometimes becomes 
corrupted for example).  In this case, we want to catch the MPL exception 
and discard the last data packet or do some other type of data 
handling.  If the error pops up a dialog, then my program is basically done 
for because there is no user to click the OK button.

Could we set some type of option in the config file that would allow either 
behavior?

Ted

At 01:43 PM 2/14/2005, John Hunter wrote:
> >>>>> "Ted" == Ted Drain <ted...@jp...> writes:
>
>     Ted> OK - I think I've read most of those messages and had a few
>     Ted> comments/ideas.  Soapbox mode on: Please don't change the
>     Ted> system exception hook.  Matplotlib (MPL) is not an
>     Ted> application, it's a library.  Libraries should never change
>     Ted> global behavior - only applications.  By changing global
>     Ted> behavior you severely limit how and where your library can be
>     Ted> used by others.  Soapbox mode off.
>
>Point taken.  One might view the pylab interface as an application,
>but I won't quibble.
>
>     Ted> I wonder if it helps to think about errors from a different
>     Ted> stand point.  For example, I can think of two high level
>     Ted> views that might help.  Users interact with MPL either
>     Ted> through the Python command line (via typing or scripts) or
>     Ted> through GUI front ends.
>
>     Ted> 1) A python function is called which has an error (or
>     Ted> something it calls has an error, etc, etc).  In this case, if
>     Ted> the function throws an exception, python will propagate the
>     Ted> exception normally.  If you're typing something on the prompt
>     Ted> or running a script, the exception get's printed with a trace
>     Ted> back.  Very useful and very normal for Python.
>
>There is a wrinkle here.  On win32 (or another platform that binds
>python scripts to an executable), you might double click on a script
>
>   from pylab import *
>   semilogy([0,1,2,3])
>   show()
>
>In pre 0.72 mpl, this would throw an exception.  On windows, if you
>double clicked this script, a stdout window would launch and die
>before you could read the traceback -- very annoying.  That's the
>primary reason I tried to catch exceptions in the pylab interface and
>forward them on to the error_msg handler function.  But the current
>impl. is admittedly broken.  Do you have a suggestion for how to
>handle this case?
>
>We could do something like this: all GUIs define a function
>show_message.  This pops up a message dialog with a single OK button.
>pylab dies the following
>
>
>def plot(*args, **kwargs):
>     # allow callers to override the hold state by passing hold=True|False
>     b = ishold()
>     h = popd(kwargs, 'hold', None)
>     if h is not None:
>         hold(h)
>     try:
>         ret =  gca().plot(*args, **kwargs)
>     except:
>         msg = ...get the traceback as string ...
>         show_message(msg)
>         hold(b)
>         ...rethrow the same exception....
>     else:
>         try: draw_if_interactive()
>         except:
>             msg = ...get the traceback as string...
>             show_message(msg)
>             hold(b)
>             ...rethrow the same exception....
>
>         hold(b)
>         return ret
>
>Someone please remind me how to rethrow the last exception --
>Fernando?
>
>Or we could just ignore it and let win32 users who are double clicking
>scripts die the painful death they deserve.  It would certainly make
>for cleaner pylab code.
>
>     Ted> - Error trying to save the plot to the image file 'plot.png'.
>     Ted> - Error in the automatic plot layout algorithm.  - Error in
>     Ted> setting the size of the plot region.  The inputs size of
>     Ted> [-10, 200] is invalid.
>
>This gives you more diagnostic information in that you get helpful
>messages at each level, but the standard traceback gives you all the
>levels, no?
>
>JDH

Ted Drain     Jet Propulsion Laboratory   ted...@jp...    

John,
Looks like that ctor was added in 3.2 of qt.  Looking back through 3.0, I 
think you should be able to just change the line to look like this:

a = qt.QAction( text, qt.QIconSet( image ), text,
                 qt.QKeySequence('M'), self.window )

which is a ctor supported by even version 2.3 of qt.

We tend to keep up w/ the latest versions of Qt pretty regularly.  I may 
have to keep an old Qt/PyQt build around to test this stuff against...

Ted

At 02:08 PM 2/14/2005, John Hunter wrote:

>With the updated qtagg backend, which worked fine on my OSX box but I
>didn't test on my linux box, I get an error when trying to run a qtagg
>plot (the previous backend does work on this box, so I think my qt
>install is OK)
>
>The offending part is "argument 1" of
>
>             a = qt.QAction( qt.QIconSet( image ), text, qt.QKeySequence('M'),
>                             self.window )
>
>
>peds-pc311:~/python/projects/matplotlib> python examples/simple_plot.py 
>-dQtAgg --verbose-helpful
>matplotlib data path /usr/local/share/matplotlib
>loaded rc file /home/jdhunter/python/projects/matplotlib-cvs/.matplotlibrc
>matplotlib version 0.72
>verbose.level helpful
>interactive is False
>platform is linux2
>numerix Numeric 23.6
>font search path ['/usr/local/share/matplotlib']
>loaded ttfcache file /home/jdhunter/.ttffont.cache
>Could not load matplotlib icon: 'module' object has no attribute 
>'window_set_default_icon_from_file'
>backend QtAgg version 0.9
>Traceback (most recent call last):
>   File "examples/simple_plot.py", line 5, in ?
>     figure(1)
>   File "/usr/local/lib/python2.3/site-packages/matplotlib/pylab.py", line 
> 828, in figure
>     figManager = new_figure_manager(num, figsize, dpi, facecolor, 
> edgecolor, frameon)
>   File 
> "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_qtagg.py", 
> line 25, in new_figure_manager
>     return FigureManagerQT( canvas, num )
>   File 
> "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py" 
> , line 155, in __init__
>     self.toolbar = NavigationToolbar2QT( canvas, self.window )
>   File 
> "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py" 
> , line 191, in __init__
>     NavigationToolbar2.__init__( self, canvas )
>   File 
> "/usr/local/lib/python2.3/site-packages/matplotlib/backend_bases.py", 
> line 896, in __init__
>     self._init_toolbar()
>   File 
> "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py" 
> , line 206, in _init_toolbar
>     self.window )
>   File "/usr/local/lib/python2.3/site-packages/qt.py", line 67, in __init__
>     libqtc.sipCallCtor(216,self,args)
>TypeError: Argument 1 of QAction() has an invalid type
>
>
>peds-pc311:~/python/projects/matplotlib> python
>Python 2.3.3 (#2, Apr 13 2004, 17:41:29)
>[GCC 3.3.3] on linux2
>Type "help", "copyright", "credits" or "license" for more information.
> >>> import qt
> >>> qt.PYQT_VERSION
>199936
>
>
>Also, the original intent of the backend_version variable was to
>report version info for the underlying toolkit.  Eg
>
>   backend_version = qt.PYQT_VERSION
>
>the backend is assumed to have the same version as the mpl parent.
>
>JDH
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Ted Drain     Jet Propulsion Laboratory   ted...@jp...    

John Hunter wrote:

> Someone please remind me how to rethrow the last exception --
> Fernando?

try:
   foo
except E:
   print 'I caught E, now I will raise it'
   raise


Best,

f

With the updated qtagg backend, which worked fine on my OSX box but I
didn't test on my linux box, I get an error when trying to run a qtagg
plot (the previous backend does work on this box, so I think my qt
install is OK)

The offending part is "argument 1" of

            a = qt.QAction( qt.QIconSet( image ), text, qt.QKeySequence('M'),
                            self.window )


peds-pc311:~/python/projects/matplotlib> python examples/simple_plot.py -dQtAgg --verbose-helpful
matplotlib data path /usr/local/share/matplotlib
loaded rc file /home/jdhunter/python/projects/matplotlib-cvs/.matplotlibrc
matplotlib version 0.72
verbose.level helpful
interactive is False
platform is linux2
numerix Numeric 23.6
font search path ['/usr/local/share/matplotlib']
loaded ttfcache file /home/jdhunter/.ttffont.cache
Could not load matplotlib icon: 'module' object has no attribute 'window_set_default_icon_from_file'
backend QtAgg version 0.9
Traceback (most recent call last):
  File "examples/simple_plot.py", line 5, in ?
    figure(1)
  File "/usr/local/lib/python2.3/site-packages/matplotlib/pylab.py", line 828, in figure
    figManager = new_figure_manager(num, figsize, dpi, facecolor, edgecolor, frameon)
  File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_qtagg.py", line 25, in new_figure_manager
    return FigureManagerQT( canvas, num )
  File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py", line 155, in __init__
    self.toolbar = NavigationToolbar2QT( canvas, self.window )
  File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py", line 191, in __init__
    NavigationToolbar2.__init__( self, canvas )
  File "/usr/local/lib/python2.3/site-packages/matplotlib/backend_bases.py", line 896, in __init__
    self._init_toolbar()
  File "/usr/local/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py", line 206, in _init_toolbar
    self.window )
  File "/usr/local/lib/python2.3/site-packages/qt.py", line 67, in __init__
    libqtc.sipCallCtor(216,self,args)
TypeError: Argument 1 of QAction() has an invalid type


peds-pc311:~/python/projects/matplotlib> python
Python 2.3.3 (#2, Apr 13 2004, 17:41:29)
[GCC 3.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import qt
>>> qt.PYQT_VERSION
199936


Also, the original intent of the backend_version variable was to
report version info for the underlying toolkit.  Eg

  backend_version = qt.PYQT_VERSION

the backend is assumed to have the same version as the mpl parent.

JDH

>>>>> "Ted" == Ted Drain <ted...@jp...> writes:

    Ted> OK - I think I've read most of those messages and had a few
    Ted> comments/ideas.  Soapbox mode on: Please don't change the
    Ted> system exception hook.  Matplotlib (MPL) is not an
    Ted> application, it's a library.  Libraries should never change
    Ted> global behavior - only applications.  By changing global
    Ted> behavior you severely limit how and where your library can be
    Ted> used by others.  Soapbox mode off.

Point taken.  One might view the pylab interface as an application,
but I won't quibble.

    Ted> I wonder if it helps to think about errors from a different
    Ted> stand point.  For example, I can think of two high level
    Ted> views that might help.  Users interact with MPL either
    Ted> through the Python command line (via typing or scripts) or
    Ted> through GUI front ends.

    Ted> 1) A python function is called which has an error (or
    Ted> something it calls has an error, etc, etc).  In this case, if
    Ted> the function throws an exception, python will propagate the
    Ted> exception normally.  If you're typing something on the prompt
    Ted> or running a script, the exception get's printed with a trace
    Ted> back.  Very useful and very normal for Python.

There is a wrinkle here.  On win32 (or another platform that binds
python scripts to an executable), you might double click on a script

  from pylab import *
  semilogy([0,1,2,3])
  show()

In pre 0.72 mpl, this would throw an exception.  On windows, if you
double clicked this script, a stdout window would launch and die
before you could read the traceback -- very annoying.  That's the
primary reason I tried to catch exceptions in the pylab interface and
forward them on to the error_msg handler function.  But the current
impl. is admittedly broken.  Do you have a suggestion for how to
handle this case?

We could do something like this: all GUIs define a function
show_message.  This pops up a message dialog with a single OK button.
pylab dies the following


def plot(*args, **kwargs):
    # allow callers to override the hold state by passing hold=True|False
    b = ishold()
    h = popd(kwargs, 'hold', None)
    if h is not None:
        hold(h)
    try:
        ret =  gca().plot(*args, **kwargs)
    except:
        msg = ...get the traceback as string ...
        show_message(msg)
        hold(b)
        ...rethrow the same exception....   
    else:
        try: draw_if_interactive()
        except:
            msg = ...get the traceback as string...
            show_message(msg)
            hold(b)
            ...rethrow the same exception....   
        
        hold(b)
        return ret

Someone please remind me how to rethrow the last exception --
Fernando?

Or we could just ignore it and let win32 users who are double clicking
scripts die the painful death they deserve.  It would certainly make
for cleaner pylab code.

    Ted> - Error trying to save the plot to the image file 'plot.png'.
    Ted> - Error in the automatic plot layout algorithm.  - Error in
    Ted> setting the size of the plot region.  The inputs size of
    Ted> [-10, 200] is invalid.

This gives you more diagnostic information in that you get helpful
messages at each level, but the standard traceback gives you all the
levels, no?

JDH

>>>>> "Abraham" == Abraham Schneider <ab...@cn...> writes:

    Abraham> Wow, that makes life much easier! I'll get started on
    Abraham> re-porting the new style config library to use your
    Abraham> modified Traits2.

As I mentioned, I've been talking with the enthought folks about where
traits should live in matplotlib, and they suggested
matplotlib.enthought.traits, because

 * it's important to have traits live inside of an enthought directory
   because enthought.traits import statements are widely used in their
   UI code, and this will help us keep our code in sync with theirs.

 * because we have a stripped down version missing
   lots-o-functionality, it shouldn't go into site-packages/enthought
   because that will screw up folks who have a regular enthought
   install

So I added the core enthought traits tree (minus UI) to CVS -- once
the mirrors update (tick, tock, tick, tock), you can do

  from matplotlib.enthought.traits import HasTraits, etc.

Dave Morrill is working on a null UI (like backend_template), so that
we can develop UI functionality if we want to but it will only work on
some backends (currently WX).  The other backends can fall back on the
null UI.  Michel Sanner has expressed some interest in having his
group repair the currently defunct Tk traits backend.  Now if we can
just get Steve to do GTK, Gregory to do FLTK and Ted and friends to do
QT, we could have a very nice way to manipulate plot attributes and rc
configuration through the GUI.  But that is a story for another
day....

JDH

OK - I think I've read most of those messages and had a few comments/ideas.

Soapbox mode on:
Please don't change the system exception hook.  Matplotlib (MPL) is not an 
application, it's a library.  Libraries should never change global behavior 
- only applications.  By changing global behavior you severely limit how 
and where your library can be used by others.
Soapbox mode off.

I wonder if it helps to think about errors from a different stand 
point.  For example, I can think of two high level views that might 
help.  Users interact with MPL either through the Python command line (via 
typing or scripts) or through GUI front ends.

1) A python function is called which has an error (or something it calls 
has an error, etc, etc).  In this case, if the function throws an 
exception, python will propagate the exception normally.  If you're typing 
something on the prompt or running a script, the exception get's printed 
with a trace back.  Very useful and very normal for Python.

2) A GUI widget calls a function which has an error.  If the function 
throws an exception, the GUI should trap that exception and show a dialog 
or whatever is appropriate for that GUI.

So I guess I'm wondering what happens if we just throw standard Python 
exceptions for all errors?  From the Python interface you get normal Python 
behavior regardless of the front end (Tk,Qt,Gtk,Agg,etc).  If you executed 
some operation from the front end (like clicking the save file dialog in 
the toolbar), you get a GUI error message like any normal GUI.  Is this too 
simple of a view?


As an aside, we've found that using error stack classes work very well in 
exception error handling.  Most of our code throws an error stack class 
which holds an array of error messages.  This way you can trap errors and 
add an error message with context information at various levels.  Many 
times errors happen at the lowest levels and you don't really know why that 
function was called.

As a completely contrived example (and probably stupid), let's say you were 
saving a plot to an image and the plot had to resize/re-render to get to 
the right image format.  You might get an error back that looks like this:

- Error trying to save the plot to the image file 'plot.png'.
- Error in the automatic plot layout algorithm.
- Error in setting the size of the plot region.  The inputs size of [-10, 
200] is invalid.

I realize this example doesn't make a lot of sense but hopefully it gives 
you some idea what you can do.  In this case the lowest level function 
which sets the size of the region decided that the inputs were invalid.  If 
you just propagate that error to the user, they may not have any idea why 
that function was called in the first place.  So the higher level functions 
do a try...except loop where they add context messages to the error and 
then re-throw it.  This has really helped our users get useful error 
messages when something goes wrong at the lowest level.

I don't know if that makes any sense or would help with error reporting in 
MPL so feel free to ignore it completely.  It was just something that has 
helped us a lot in using exceptions to provide useful messages to people.

Ted


At 11:16 AM 2/14/2005, John Hunter wrote:
> >>>>> "Ted" == Ted Drain <ted...@jp...> writes:
>
>     Ted> Also, I'm a little confused about the backends use of the
>     Ted> 'error_msg' function.  Many of the backends import this
>     Ted> function from backend_bases but then change that names
>     Ted> definition to a local copy (see backend_gtk,
>     Ted> backend_template, backend_wx).  This seems wrong or at least
>     Ted> more confusing that it needs to be.  I don't think a script
>     Ted> should explicitly import something with one name and then
>     Ted> change the name to point to a local variable.
>
>We're a little confused too :-)
>
>The error_msg function was initially designed to provide a way to get
>error messages up to the GUI, otherwise they might disappear into
>stderr, stdout.  However, the framework has caused nothing but grief
>and confusion and needs to die.  It has lived this long simply because
>noone has found the time to kill it.  The system exit in the default
>error message function was meant to be used by image backends with the
>reasoning that if you get an error on an image backend, there is no
>point in trying to continue.  But now I see the unintended
>consequences of this decision when we mix image and gui backends, as
>in qt agg.
>
>There have been prolonged discussions on the topic before.  See for
>example the "propagation of errors thread at CVS
>
>http://sourceforge.net/mailarchive/forum.php?forum_id=36187&max_rows=100&style=threaded&viewmonth=200411
>
>
>where we almost reach a consensus and then promptly repress the
>subject for a few more months.  Last time we left off, I think I
>suggested that we should kill error message and use exception hooks to
>get the exceptions into the GUI.  Steve tried to implement something
>like this for GTK -- I can't remember what the final result was.
>
>
>
>I think a good place to start would be to remove all instances of
>error_msg* from the mpl front end and backend code, and then see where
>we are.  Any major problems with that?
>
>JDH

Ted Drain     Jet Propulsion Laboratory   ted...@jp...    

matplotlib-0.72 is up at the sourceforge site.  Note that there have
been some signficant changes at the extension code level.  If you get
crashes or segfaults on import or usage, try deleting the "build"
subsirectory and site-packages/matplotlib before reinstalling to
insure a clean install.


  - heavy optimizations in line marker drawing eg plot(x,y,'+') or any
    other line marker.  Here are some numbers, where N is the number
    of symbols
    

                       0.71     0.72    speedup
           -----------------------------------
        N =   1000 |  0.24s  |  0.13s |  1.85x
        N =   5000 |  0.68s  |  0.19s |  3.57x
        N =  10000 |  1.17s  |  0.28s |  4.19x
        N =  50000 |  5.30s  |  0.60s |  8.89x
        N = 100000 | 10.02s  |  0.70s | 14.31x
        N = 500000 | 48.81s  |  2.32s | 21.03x


 - lots of work making log plots "just work".  You can toggle log y
   axes with the 'l' command -- nonpositive data are simply ignored
   and no longer raise exceptions.  log plots should be a lot faster
   and more robust

 - fixed a contour bug for unequal sized arrays and made the syntax
   matlab compatible -- see http://matplotlib.sf.net/API_CHANGES

 - alpha version of QTAgg backend -- note the licensing issue of QT is
   murky since QT is dual licensed.  If you are shipping a commercial
   product with matplotlib you may want to remove the qt backend to be
   on the safe side.

 - matshow for displaying arrays with proper aspect ratio -- see
   http://matplotlib.sf.net/matplotlib.pylab.html#-mathshow

 - new examples/interactive.py which shows you how to use matplotlib
   in a custom gtk shell

 - shared axes for two scale and ganged plots -- you can set sharex on
   and axis and multiple subpolots will pan and zoom together.  See
   http://matplotlib.sf.net/examples/shared_axis_demo.py - Thanks Baptiste!

 - Default key presses over axes: 'g' toggles grid, 'l' toggles logy

 - little features: calls to subplot with overlap other subplots now
   delete the overlapped subplot, load and save work with file and
   handles gzipped files transaparently, small PS optimizations, gtk
   figure resizing more flexible

 - little bug fixes: contour datalim and unequal sized array bugs,
   mx2num, added missing mathtext symbols, fonts in mathtext
   super/subscripts, contour works with interactive changes in cmaps,
   clim

Special thanks to Fernando Perez for many CVS bug reports, feature
suggestions and contributions.

http://matplotlib.sf.net

JDH

>>>>> "Ted" == Ted Drain <ted...@jp...> writes:

    Ted> Also, I'm a little confused about the backends use of the
    Ted> 'error_msg' function.  Many of the backends import this
    Ted> function from backend_bases but then change that names
    Ted> definition to a local copy (see backend_gtk,
    Ted> backend_template, backend_wx).  This seems wrong or at least
    Ted> more confusing that it needs to be.  I don't think a script
    Ted> should explicitly import something with one name and then
    Ted> change the name to point to a local variable.

We're a little confused too :-)

The error_msg function was initially designed to provide a way to get
error messages up to the GUI, otherwise they might disappear into
stderr, stdout.  However, the framework has caused nothing but grief
and confusion and needs to die.  It has lived this long simply because
noone has found the time to kill it.  The system exit in the default
error message function was meant to be used by image backends with the
reasoning that if you get an error on an image backend, there is no
point in trying to continue.  But now I see the unintended
consequences of this decision when we mix image and gui backends, as
in qt agg.

There have been prolonged discussions on the topic before.  See for
example the "propagation of errors thread at CVS

http://sourceforge.net/mailarchive/forum.php?forum_id=36187&max_rows=100&style=threaded&viewmonth=200411


where we almost reach a consensus and then promptly repress the
subject for a few more months.  Last time we left off, I think I
suggested that we should kill error message and use exception hooks to
get the exceptions into the GUI.  Steve tried to implement something
like this for GTK -- I can't remember what the final result was.



I think a good place to start would be to remove all instances of
error_msg* from the mpl front end and backend code, and then see where
we are.  Any major problems with that?

JDH

John,
I have someone fixing the last items (status bar and error handling) from 
the Qt backend and I had a few questions.  You said:

>   * If you try to save to an unsupported output type (eg pdf) the
>     entire window closes -- a bit extreme

This seems to happen on the TkAgg backend as well.  The culprit seems to be 
this code (backend_tkagg.py):

         try:
             self.canvas.print_figure(fname)
         except IOError, msg:
             err = '\n'.join(map(str, msg))
             msg = 'Failed to save %s: Error msg was\n\n%s' % (
                 fname, err)
             error_msg_tkpaint(msg)

The exception (at least for trying to save a pdf file) is not an IOError so 
the message get's propagated up and you exit the event loop (which is what 
causes the window to disappear).

I think the problem is that backend_agg.py is calling error_msg() that it 
COPYS from backend_bases.py.  The default action from backend_bases.py is 
to print a message and call sys.exit() which is what is generating this 
message.  I assume that somewhere you're trapping the exit call to send an 
exception?

On the surface (i.e. w/o knowing the design decisions that were made), this 
seems like a bad idea.  It seems like exceptions should be used and that 
sys.exit() should exit the program.  Changing the behavior of a standard 
call like sys.exit() (if that's what is really happening) seems like a bad 
idea since it changes global behavior.

Also, I'm a little confused about the backends use of the 'error_msg' 
function.   Many of the backends import this function from backend_bases 
but then change that names definition to a local copy (see backend_gtk, 
backend_template, backend_wx).  This seems wrong or at least more confusing 
that it needs to be.  I don't think a script should explicitly import 
something with one name and then change the name to point to a local variable.

Is the idea that the backends should overload the error_msg function that 
all the code uses?  If that's the case it would be a simple change to do 
something like this:

import backend_bases
backend_bases.error_msg = error_msg_tkpaint

Ted
Ted Drain     Jet Propulsion Laboratory   ted...@jp...    

The following script generates an errant line in backend_ps

    from pylab import *

    x=arange(10)

    a=plot(x,x**2,'bo')
    b=plot(x,90-x**2,'rs')

    fl=figlegend((a,b),('curve 1','curve 2'),'lower center')
    fl.draw_frame(False)

    savefig('figlegend_bug')

but not in agg.  It only happens when the legend frame is off.

This is sf bug
https://sourceforge.net/tracker/?func=detail&atid=560720&aid=1122041&group_id=80706

JDH

John Hunter wrote:

> http://jdh.uchicago.edu/share/Traits2_UM.pdf
> 
> but there appears to be an OSX font problem with it...

It's more of a "non-Adobe Reader font problem," I think. It looks fine 
in Adobe Reader.

However, I just re-exported it to PDF using NeoOffice/J (the 
Java/Aqua/Mac version of OpenOffice). It seems to load fine in 
Preview.app, Adobe Reader, and Schubert|it's PDF plugin. Dunno about 
other platforms.

http://starship.python.net/crew/kernr/Traits2_UM_mac.pdf

-- 
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

>>>>> "Abraham" == Abraham Schneider <ab...@cn...> writes:

    Abraham> Wow, that makes life much easier! I'll get started on
    Abraham> re-porting the new style config library to use your
    Abraham> modified Traits2.

OK, great, just be aware that the directory organization will likely
change a bit over the next couple of weeks as I try to synchronize my
quick port with the enthought core tree.  But this change will be
localized to the one or two lines where the import occurs.

Eric Jones suggests we use continue to place traits under an enthought
basedir so it will be easier to keep our tree synched with theirs.  So
it will probably either matplotlib.enthought.traits or simply
enthought.traits depending on how things shake out.  He is also
interested in maintaining python2.2 compatibility so that bodes well
for us being able to work from their un/lightly-modified code base.

JDH