dbstop doesn't break with run script

[John W. Eaton]

On 25-May-2011, Jordi Gutiérrez Hermoso wrote:

| If you do
| 
|     dbstop foo 5
| 
| and a breakpoint is set and later type
| 
|     run foo.m
| 
| the breakpoint isn't hit. Is this a bug?

Here's what I think is happening:

When you set the breakpoint, Octave finds the function or script foo.
If it is not already in the symbol table, it parses it, then tags the
function's parse tree with the debug breakpoint.  Then if you type

  foo

to execute the script, Octave will find it in the symbol table and
execute the already parsed version of the script with the debugging
info, so you'll end up stopping at the breakpoint you set.

When you use the run function to execute the script, it ultimately
calls

        evalin ("caller", sprintf ("source (\"%s\");", script),
                "rethrow (lasterror ())");

to evaluate "./foo.m".  The source function does not look for
"./foo.m" in the symbol table, but instead unconditionally parses the
file and executes the resulting parse tree object, which does not have
the debugging info attached to it.

If you think it is a bug that should be fixed, then I think we need to
either change the source function to look for functions and scripts in
the symbol table first before parsing the file again, or have some
other way of executing functions that can look in the symbol table
first.  We would need to be able to find the function regardless of
how the name is specified to the run function.  I don't remember
precisely how functions and scripts are stored in the symbol table, so
I don't know whether the full path name is used as a key, or if it is
simple to search using that information.

BTW, it looks to me like the evalin above could simplified by using

  source (script, "caller");

now, but this will not solve the problem you are seeing.

jwe