From octave-maintainers-request at bevo dot che dot wisc dot edu  Fri Jul 28 04:41:58 2000
Subject: Patch for 2.0.16: call 'keyboard' automagically on error.
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: Joao Cardoso <jcardoso at inescporto dot pt>
Cc: octave-maintainers at bevo dot che dot wisc dot edu, pkienzle@kienzle.powernet.co.uk
Date: Fri, 28 Jul 2000 04:42:19 -0500 (CDT)

On 28-Jul-2000, Joao Cardoso <jcardoso at inescporto dot pt> wrote:

| 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
archive.

| input.cc:
|         I've modified get_user_input() to distinguish between "quit" and
|         "return" in keyboard().  Not required for error trapping to
| work,
|         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
sleep.  :-(

| 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
| implement:
| 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
efficient manner.

| PPS, With curr_function and curr_command, warning() can print the
| function
| and statement line/column which generated the warning.  That would be
| nice!

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).

Thanks!

jwe