>> 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?

��

As workaround, we can remove the ��once�� as we remove the breakpoint in the ensure:, it should be removed and
not stay around causing problems. (but it is there in case you would run the test again, that is why a once break is nicer).

cheers -ben��