Re: [Changeset] make symbol_table:; find_function also find class specific functions

[John W. Eaton]

On  7-Oct-2008, David Bateman wrote:

| John W. Eaton wrote:
| > OK.  The breakpoints seem to be failing because they are set on switch
| > statements or other locations that are not handled properly by the
| > debug code.  I tried a few quick things to fix it but wasn't
| > successful.  I don't understand the breakpoint/debug code very well
| > and don't have more time at the moment to debug it.  But you can see
| > that the breakpoints can work in methods and constructors if you do
| >
| >   dbstop @gf/subsasgn 5
| >
| > for example.
| >   
| Would this be the same issue that is causing errors in if/while/for 
| blocks to be reported as occurring after the end statement for the 
| block? It seems likely.

I'm not sure that it is exactly the same issue, though it could be
related.

I think the parser does not store line number information for all
tokens.  That could probably be improved.  Perhaps someone will take
the time to work on it?  I do not have time to do it now.

To fix the breakpoint problem, I think we need to decide precisely
where we should be attaching breakpoint tags, and how we should be
searching for them when a breakpoint is crossed.

The interface for setting breakpoints is line based, but the
interpreter works on statements and expressions.

Given code like

  1  if (c1)
  2    stmt1;
  3    if (c2) stmt1; stmt2; endif
  4  endif

and breakpoints set on line 2 and line 3, what should we do?  In the
case of line 2, it seems the breakpoint should be attached to the
statement STMT1.  But in the case of 3, should the breakpoint be
attached to the IF statement or the expressions (they are also on line
3).  If we set the breakpoint on the IF statement, then presumably the
debugger will stop before the condition C2 is executed.  Should there
be a way to step through the evaluation of the IF statement so that we
can stop just prior to each statement if C2 is true?

In any case, the debugger definitely needs more work, but as you have
said in the past and I agree, we should probably put that off until
after we convert the evaluator to be based on a visitor pattern.

jwe