Re: Debugger bugfix

[David Bateman]

John Swensen wrote:
> Do you have some concrete examples of where these two cases from the 
> previous threads were failing, so I can start hunting this down?  I 
> keep telling myself I need to work on something that forces me to get 
> to understand how the code is parsed and stored, and maybe this is my 
> chance to bite the bullet.
I can no longer reproduce easily the first issue I had, with misreported 
locations of errors in if/for, etc blocks. Perhaps John check in a 
change that fixed it in the last few weeks.

As for the second one, I thought the issue was generic and any block 
would cause this issue. However it appears to only happen in methods of 
classes. So consider we have a class constructor @cls/cls.m with the 
contents

function b = cls (a)
 if (nargin < 1 || nargin > 2)
   print_usage ();
 else
   b.a = a;
   b.b = "cls";
   b = class (b, "cls");
 endif
end

Then here is an example with this  simple class

octave:2> a = cls(1)
octave:3> dbstop cls
ans =  2
octave:4> a = cls(1)
octave:5> dbstatus ()
octave:6>

This appears to happen in all methods of classes. However now consider

octave:6> dbstop("cls",5)
ans =  5
octave:7> a = cls(1)
cls: line 5, column 9
b.a = a
keyboard: stopped in /home/dbateman/octave/devel/classes/@cls/cls.m at 
line 5
debug>

So setting the breakpoint somewhere that isn't on a if/while/for, etc 
lock works fine.  Didn't look very far into this one.

Regards
David

--
David Bateman                                address@hidden
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)