| Following my request for help on octave-help, Paul Kienzle gently sent
| me the enclosed patch to solve the described problem.
Thanks, I've included changes based on Paul's patch in the 2.1.x
sources. I changed the name of the user-level variable to
debug_on_error, and I also introduced debug_on_warning.
I also only did a small amount of testing (just to see that it would
compile and work at all) and checked in the changes to the CVS
| I've modified get_user_input() to distinguish between "quit" and
| "return" in keyboard(). Not required for error trapping to
| but certainly useful. get_user_input() should be rewritten so
| that it is not such a hack. keyboard() should contain the loop
| since input() doesn't need it. Restricting get_user_input() to
| doing just that, and letting keyboard() and input() evaluate or
| not as they wish is probably the best approach.
Yes, I agree that this could use some cleanup. Maybe after I get some
| pt-misc.cc, toplev.cc, toplev.h:
| The tricky bit: how to know what statement caused the error. I
| create a new global variable similar to the curr_function variable
| which defines the current statement. Then during
| tree_statement_list::eval(), I update it with each new statement.
| In 2.1.x series, tree_statement::eval() is probably the nicest
| place to put this, but tree_statement_list::eval() works, too
| [see file pt-stmt.cc]. I don't know if the unwind_protect_ptr()
| is necessary or useful here.
I put it in tree_statement_list::eval (there is only one in the 2.1.x
sources), but I'll try to have another look at it later to see if
tree_statement::eval is really better.
I'm not sure that the unwind_protect is really useful unless you
also add a call to unwind_protect::run so that the value is restored.
I'm also not sure if it is really needed anyway. Hmm.
| PS, It occurs to me that dbstep functionality would be easy to
| just define a "step_through_statements" flag like "stop_on_error", and
| in tree_statement::eval(), if this flag is set, then do the same debug
| call that you do for stop_on_error.
Right, that would be nice too. The somewhat more difficult part would
be adding the stuff necessary to support dbstop in a reasonably
| PPS, With curr_function and curr_command, warning() can print the
| and statement line/column which generated the warning. That would be
Yes. You get that now if you set debug_on_warning to true, but then
you also go in the debugger. I'll also try to take a look at cleaning
this up a bit so warning can print some file/line/column info.
BTW, your patch was reversed (please use diff -c OLD-file NEW-file).