14 comments
Comment actions Permalink

After that lengthy discussion about how you were going to handle the complexities of multiple debuggers, do you have a moment to comment on the compromises you made? And is it still a work in progress?

I see you decided not to tie breakpoints to a single debugger session. A breakpoint will break in every session.

0
Comment actions Permalink

It seemed to us that the application domain for the multiply debuggers
feature are mostly highly intelinked processes. People who have, for
example, separate server and client, prefer to open several projects, each
with single debugger. Contrary, when the server and client share the
functionality and have high interaction the multiply debuggers become
valuable.

Roughly speaking you prefer multiply debuggers when your processes are
likely to be one distributed application.

Hence we came to the idea that multiprocess debugging should be much simular
to multithreading debugging.
Consequently, the breakpoints are spreaded to all the processes.
May be it's worth sharing watches, threads and frame tabs between processes.
May be it will be also useful to implement one debug configuration for
several processes (in order to start / stop all the processes together).

Currently I'm refactoring the existing debugger, this will give us more
potentialities for changing the interface and implementing new features.

Everybody are welcome to share their ideas ;)


0
Comment actions Permalink

I would suggest incorporating the evaluation window into a debug session tab (as another sub-tab I guess), to clear up the issue of which eval window belongs to which debug session.

I would also consider the following tracker, concerning stop and stepping through several threads at once:
http://www.intellij.net/tracker/idea/viewSCR?publicId=13218
This would allow you to do pretty cool things, like carefully stepping through two threads individually to debug a deadlock situation. The old VA Java debugger was marvelous in this respect.

Also, while on the topic of debuggers, I would give another look to this one (just ignore the stuff referring to multiple debug sessions):
http://www.intellij.net/tracker/idea/viewSCR?publicId=11939

0
Comment actions Permalink

Actually, I just played with this "breaking in two threads" business, and it appears it about half implemented already. If I launch two threads and put a breakpoint in each of them, the debugger does appear to break at both points.

On the "Frame" tab, if I select each of the threads in the thread drop-down, I can see the context and call stack for both threads, but there is no indication in the thread drop-drop of which threads are currently suspended.

In the "Threads" tab, only the first thread which suspended is shown in the tree. Even if thread 2 is selected in the thread drop-down on the "Frame" tab, thread 1 is still the only thread shown in the "Threads" tab.

Also, back in the "Frame" tab, regardless of which thread is selected in the thread drop-down, the step buttons always just operate on the thread 1. Eg, select thread 2 and press the stop over button: thread 1 steps, thread 2 just resumes.

0
Comment actions Permalink

Actually, I just played with this "breaking in two threads" business, and

it appears it about half implemented already. If I launch two threads

and put a breakpoint in each of them, the debugger does appear to break at

both points.

Also, back in the "Frame" tab, regardless of which thread is selected in

the thread drop-down, the step buttons always just operate on the

thread 1. Eg, select thread 2 and press the stop over button: thread 1

steps, thread 2 just resumes.

It seems you turned on "Suspend all threads while stepping". In this case
the behavour is correct.

On the "Frame" tab, if I select each of the threads in the thread

drop-down, I can see the context and call stack for both threads, but there
is

no indication in the thread drop-drop of which threads are currently

suspended.

In the "Threads" tab, only the first thread which suspended is shown in

the tree. Even if thread 2 is selected in the thread drop-down on the
>"Frame" tab, thread 1 is still the only thread shown in the "Threads" tab.

Yes, I know about those problems. Personally, I would prefer only Threads
tab without drop-down box, so the information about threads will not be
duplicated. But in this case it will be rather hard to navigate through
local variables, you will always switch between Threads and Frame tabs. Now
I'm looking for the solution that will solve both problems.


0
Comment actions Permalink

Great work, getting multiple debugger support in. Am I alone in thinking it
would be a much cleaner UI if the Run and Debug tool windows were combined
into a single tool window?

http://www.intellij.net/tracker/idea/viewSCR?publicId=3766

I am always switching between debug sessions and the consoles of running
processes.

The advantages of this suggestion that I can think of are:

- it saves the time it takes to minimize one window and open the other
- it would take a maximum of one mouse click instead of a maximum of two
- it would eliminate lots of rather annoying window painting noise
- someone could write a cool tab-switching plugin like Timur's tabSwitch
plugin :)

I guess I could run everything in debug now, but thats gonna have side
effects...

Keep up the excellent work.

Colin



0
Comment actions Permalink

Yes, I know about those problems. Personally, I would prefer only Threads
tab without drop-down box, so the information about threads will not be
duplicated. But in this case it will be rather hard to navigate through
local variables, you will always switch between Threads and Frame tabs. Now
I'm looking for the solution that will solve both problems.


I think it would be nice to have 3-pane window which shows Threads > Frames > Local
Variables. Each of these panes should be minimizable (you know - the small arrows on the
split bar). The title of the toolwindow should display the current context (e.g. "[Thread
1] MainClass.main()).

The advantages are that you could see more information at once without clicking all these
dropdowns. Also IMO the switching between threads/frames would be more convenient.

It could be also nice to remember the stackframe when switching between threads although
I'm not that sure about this...

-- dimiter

0
Comment actions Permalink

> Great work, getting multiple debugger support in. Am I alone in thinking it
> would be a much cleaner UI if the Run and Debug tool windows were combined
> into a single tool window?

Very often I use the run and debug tabs docked to top and bottom, to watch the outputs of
two programs simultaneously. Sometimes I even use the Ant tab to watch a third program :)

So, although it sounds good, I would not like this (at least until the "undock tab"
feature is not implemented).

cheers,
dimiter


Colin Smith wrote:

Great work, getting multiple debugger support in. Am I alone in thinking it
would be a much cleaner UI if the Run and Debug tool windows were combined
into a single tool window?

http://www.intellij.net/tracker/idea/viewSCR?publicId=3766

I am always switching between debug sessions and the consoles of running
processes.

The advantages of this suggestion that I can think of are:

- it saves the time it takes to minimize one window and open the other
- it would take a maximum of one mouse click instead of a maximum of two
- it would eliminate lots of rather annoying window painting noise
- someone could write a cool tab-switching plugin like Timur's tabSwitch
plugin :)

I guess I could run everything in debug now, but thats gonna have side
effects...

Keep up the excellent work.

Colin



0
Comment actions Permalink

I agree, undocking tabs is the way to go. Then you would be able to see as
many consoles as you like, simultaneously.


0
Comment actions Permalink

Colin Smith wrote:

I agree, undocking tabs is the way to go. Then you would be able to see as
many consoles as you like, simultaneously.

I think it'd be very nice too.
We need to enter a feature request I'm too lazy to search for duplicates
now ...




0
Comment actions Permalink

Edoardo Comar wrote:

Colin Smith wrote:

>> I agree, undocking tabs is the way to go. Then you would be able to
>> see as
>> many consoles as you like, simultaneously.
>>
>>

I think it'd be very nice too.
We need to enter a feature request I'm too lazy to search for duplicates
now ...



well, done ...

http://www.intellij.net/tracker/idea/viewSCR?publicId=13301

0
Comment actions Permalink

Actually, I just played with this "breaking in two

threads" business, and
it appears it about half implemented already. If I
launch two threads

and put a breakpoint in each of them, the debugger

does appear to break at
both points.

Also, back in the "Frame" tab, regardless of which

thread is selected in
the thread drop-down, the step buttons always just
operate on the

thread 1. Eg, select thread 2 and press the stop

over button: thread 1
steps, thread 2 just resumes.

It seems you turned on "Suspend all threads while
stepping". In this case
the behavour is correct.


I should have mentioned: I didn't have "Suspend all threads" turned on. I checked, and all the other threads (besides the two I had suspended) were humming along nicely.

You're right though, the behaviour is the same as when all threads are suspend with each step. But I always thought this was unintuitive. When I tell a thread to step, I expect just that thread to run, while all the other threads stay suspended. Not sure why they did it this way, unless it's a limitation of the Sun debugger interface.

0
Comment actions Permalink

I think it would be nice to have 3-pane window which shows Threads >
Frames > Local Variables. Each of these panes should be minimizable (you
know - the small arrows on the split bar). The title of the toolwindow
should display the current context (e.g. "[Thread 1] MainClass.main()).


Agreed. I always use idea in full screen mode (and also use two
monitors) so I have lots of horizontal space. The current debug layout
wastes much of that space. I would much rather see the list of stacks
in-line instead of the in a dropdown. The up/down arrows helped
somewhat. But often you need to skip over thirdparty calls and clicking
with up/down you don't know how many times you have to click.

0
Comment actions Permalink

Alexei Nikitin wrote:

It seemed to us that the application domain for the multiply debuggers
feature are mostly highly intelinked processes. People who have, for
example, separate server and client, prefer to open several projects, each
with single debugger. Contrary, when the server and client share the
functionality and have high interaction the multiply debuggers become
valuable.

Roughly speaking you prefer multiply debuggers when your processes are
likely to be one distributed application.

Hence we came to the idea that multiprocess debugging should be much simular
to multithreading debugging.
Consequently, the breakpoints are spreaded to all the processes.
May be it's worth sharing watches, threads and frame tabs between processes.
May be it will be also useful to implement one debug configuration for
several processes (in order to start / stop all the processes together).

Currently I'm refactoring the existing debugger, this will give us more
potentialities for changing the interface and implementing new features.

Everybody are welcome to share their ideas ;)


I have been using multiple debuggers in a coupled client-server
environment for a couple of days and I must say I am very happy with it.

Well done - for me there's no turning back from 823 ;)

Edo

0

Please sign in to leave a comment.