mailRe: r2540 - in /branches/warning: errors.py generic_fns/pdb.py relax


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by Chris MacRaild on August 30, 2006 - 19:16:
On Thu, 2006-08-31 at 02:36 +1000, Edward d'Auvergne wrote:
The traceback results look identical to that of the error system.
Once the 'format()' function has been moved into the 'self' namespace
I'm happy for this branch to be merged back into the 1.2 line.

I'll make the required changes and do the merge tomorrow.

Actually I've just looked over all the modifications and just have one
more point.  The warning statements in the 'pdb.py' file are only
executed when the 'print_flag' is set.  I think the 'if print_flag:'
statements should be dropped and the warning printed to stderr in all
situations.  The print_flag variable is for increasing or decreasing
the quantity of data, results, etc printed out for the user to see.
The value is specifically set by the called user function and hence
the variable won't exist in all situations.  As with the RelaxError
system The new RelaxWarning system would be better separated from this
fine granularity output printing system.

Agreed. I only put these warnings under 'if print_flag:' because the
equivalent print statements were similarly gated. Clearly it makes less
sense with a proper warning system.


I'll look back into trimming the other side of the stack later on.
The idea I had was to trim both ends of the stack so that only things
after the line

File "test_m5.py", line 38, in ?

in your traceback are printed, i.e. from the script onwards.  This
would only occur when RelaxErrors or RelaxWarnings occur.  The
RelaxError system does not currently have this feature, but it is a
very ancient idea, so I might create a task for this.  Then I can't
forget about it again (which has occurred quite a number of times
already).  The change is very superficial though, but it may help
users by simplifying the debugging output for them.  I have previously
avoided the task as it is not basic and the benefits were almost
non-existant in the early stages of development.

This needs a bit of care. Although those parts of the traceback are
unimportant most of the time, there may be occasions when bugs surface
somewhere in these top levels of relax (eg. if new UIs are introduced).
Then we might want access to the top of the traceback. I guess what I'm
saying is if you do try to trim from the top of the stack, it should be
possible turn that behaviour off. The debug flag would be the obvious
switch.


Bye,

Edward





Related Messages


Powered by MHonArc, Updated Thu Aug 31 13:41:22 2006