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.
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.
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.
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.
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.
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?
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...
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...
> 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?
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...
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.
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.
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 ;)
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.
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 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
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.
it appears it about half implemented already. If I launch two threads
both points.
the thread drop-down, the step buttons always just operate on the
steps, thread 2 just resumes.
It seems you turned on "Suspend all threads while stepping". In this case
the behavour is correct.
drop-down, I can see the context and call stack for both threads, but there
is
suspended.
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.
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
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
> 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:
I agree, undocking tabs is the way to go. Then you would be able to see as
many consoles as you like, simultaneously.
Colin Smith wrote:
I think it'd be very nice too.
We need to enter a feature request I'm too lazy to search for duplicates
now ...
Edoardo Comar wrote:
>> I agree, undocking tabs is the way to go. Then you would be able to
>> see as
>> many consoles as you like, simultaneously.
>>
>>
well, done ...
http://www.intellij.net/tracker/idea/viewSCR?publicId=13301
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.
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.
Alexei Nikitin wrote:
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