On 22 Jun 2018, at 02:54, Ben Coman <btc@openinworld.com> wrote:

>> On 15 Jun 2018, at 01:07, Ben Coman <btc@openinworld.com> wrote:
>> 
>> Not sure if this is intended behaviour...
>> 
>> in a brand new build 71053, open a browser GTGenericStackDebuggerTest >> testBasic
>> 
>> right-click and choose "Debug"
>> 
>> the debugger opens about on the third statement. 
>> Clicking <Restart> doesn't improve things, 
>> and then clicking <Into> shows the stack on MetaLink>>uninstall.
>> 
>> cheers -ben
> 

> On 15 Jun 2018, at 12:18, Marcus Denker <marcus.denker@inria.fr> wrote:
> 
> Thanks, I made a note and will look (I hope next week)
> 

On 21 June 2018 at 22:24, Marcus Denker <marcus.denker@inria.fr> wrote:

Hello,

The reason seems to be that the mechanism uses a ���once��� breakpoint which is for now implemented by
removing the breakpoint at runtime. This leads to the debugger getting text/bytecode offset wrong
as we install a different method.

runTest: testSelector of: testClass

        | breakpoint |
        breakpoint := Breakpoint new
                node: (testClass lookupSelector: testSelector) ast;
                once;
                install.
        [super runTest: testSelector of: testClass] ensure: [ breakpoint remove ]

Thanks for the update.
 

I am thinking of implementing the once breakpoints using a condition instead (so that the byte code is unchanged).
The other nice effect is that one can more easily re-enable those breakpoints (like haltOnce).

That sounds like a good idea.  Will that change the semantics at all?

IIRC, prior to metalinks the Halt-once was a global reset only, and post metalinks it was reset by a method save.

So will the condition-state be global or per method?  

And then mild curiousity about the implementation - how would that state be stored?