On Wed, Nov 25, 2015 at 6:29 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:

2015-11-25 17:16 GMT+01:00 Andrei Chis <chisvasileandrei@gmail.com>:
Hi,

In updating the debuggers from moose to the new API just one small issue came up:

- Process>>newDebugSessionNamed:startedAt: hardcodes��DebugSession. However we are using different debugging sessions.

The class side method #sessionClass of a debugger returns the debugging session's class. That could be used instead of DebugSession.

To provide fast fix we can rewrite process method with:

Process>>newDebugSessionNamed: aString startedAt: aContext

^Smalltalk tools debugger sessionClass named: aString on: self startedAt: aContext

Could you publish issue and slice?

We can postpone this for the moment.

I'll look a bit more at how this fits with the debuggers from moose as I'd like a more general solution where the debugger can be dynamically selected.��

��

In my fixes I try to put single point for debugging. I removed some old methods and clean places where they was used.
Session is actual debugger model. And I was think that it is better to always create debugger on it.
Now I think that maybe debug session should be internal object for debugger. But it's seems strange.

When I added the session I viewed it as a model for the debugger. SpecDebugger and GTStackDebugger are just two different user interfaces for the same model (DebugSession).

��

My main target is remote debugger. So I try to investigate all related stuff.

Cool target :)

��

What subclasses of DebugSession implement specifically? For what they needed?

For example,��GTBytecodeDebugger uses��GTBytecodeDebuggerSession which makes sure step instructions only go over one bytecode (so no usage of #stepToSendOrReturn which are needed in the normal debugger).

Apart from this other sessions store more information. For example��GTSUnitDebugSession stores the context with the failing assertion.

��

If we move to GTDebugger completely can we have only debug session class?

GTGenericStackDebugger, ��the equivalent of SpecDebugger, uses also DebugSession (it just adds a few extension methods).��

All other debuggers have sessions that just inherit from DebugSession and they can be loaded separately.

Cheers,

Andrei

��