[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Debugger bugfix
From: |
David Bateman |
Subject: |
Re: Debugger bugfix |
Date: |
Sat, 29 Nov 2008 22:47:26 +0100 |
User-agent: |
Mozilla-Thunderbird 2.0.0.17 (X11/20081018) |
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)