Multiple debuggers

Hi All,

I would like to discuss one of the features a lot of people have been requesting us: multiple debugger instances per project.
Could you share your thoughts and suggestions of how the feature should work from the user's point of view?
Some problems to consider:

1. When you add a line breakpoint, to what process are you targeting it? Should the breakpoint be shared between the processes
currently debugged (the debugger tries to add breakpoint requests to all debuggees). Or if the breakpoint should be set up for only
one process, what's the best way to choose for which one?
2. When you perform such actions like stepping, expression evaluation etc, to what debuggee process are you expecting the actions to
be applied to?
3. When hovering with the mouse over a variable, a tooltip with the value is shown. Provided the class exists in several debuggees,
what value to show?

One of the important things that should be introduced, is a notion of "active debuggee" - the debuggee to which all the actions
described above will be applied (similar to a control currently posessing focus in a GUI form). Then the question arises: what are
the events that make the debuggee "active": explicit selection as "active" by the user or/and hitting the breakpoint in the target
process? More generally, how do you see the "focus changing policy" that won't confuse the user and make him/her "lost in the
debuggers"?

I see only one use-case when multiple debuggers would be useful - client/server applications. But personally I would choose another
approach for debugging: I would set up 2 projects (for client and server) and opened them simultaneously: each project could have
its own debugger and since the project are in different frames, my debugging contexts are well separated. I don't see any problems
in such configuration, but looks like some people have different opinion : please share your thoughts why the suggested approach
soes not suit you and why you find opening multiple debuggers in one project more convenient.
Perhaps you could describe other situations when multiple debuggers would be handy: the use-cases you describe could help us make
the feature really useful (and usable) for those requested it.


--

Best regards,
Eugene Zhuravlev
JetBrains, Inc, http://www.intellij.com
"Develop with pleasure!"


53 comments
Comment actions Permalink

1. When you add a line breakpoint, to what process
are you targeting it? Should the breakpoint be shared
between the processes currently debugged (the debugger >tries to add breakpoint requests to all debuggees). Or if >the breakpoint should be set up for only one process, >what's the best way to choose for which one?


Well, in my experience this is not a big issue, since I usually debug different parts of a distributed architecture, but they are not the same software. Should I debug two instances of the same app, I think that there could be many ways to do this: since I usually set breakpoints by clicking on the gutter, you could allow to click multiple times to set the instance. I.e.: I click one time, and I set the breakpoint for all instances, if I click again I restrict it to the first instance, then the second, and so on. It could then be possible to apply it to multiple instances at the same time by editing the breakpoint properties. Of course this involves a concept of "debugged instances" that should be visible in some way.

2. When you perform such actions like stepping,
expression evaluation etc, to what debuggee process
are you expecting the actions to
be applied to?


I think this could behave as when one has two threads which can incur in the same BP: if you don't want the second instance to block on it, you disarm it after touching it with the first. When I step from that breakpoint, all the actions should be applied to the instance currently debugged, but I should have, of course, the capability to move to the other instance, pause it, and apply the actions.

3. When hovering with the mouse over a variable, a
tooltip with the value is shown. Provided the class
exists in several debuggees,
what value to show?


An IDEA frame instance should only show values for a single debugged instance at a time: it should be possible to switch instances, or open different idea frames.

question arises: what are
the events that make the debuggee "active": explicit
selection as "active" by the user or/and hitting the
breakpoint in the target
process?


Both: a breakpoint should change the active debugged instance, but it should be possible to manually switch: the configuration should allow to tell if all the instances work in the same frame or if every instance has its frame.

More generally, how do you see the "focus
changing policy" that won't confuse the user and make
him/her "lost in the debuggers"?


Well an indicator such as "instance 1" with configurable labels should be enough.

I see only one use-case when multiple debuggers would
be useful - client/server applications. But


What about peer-based distributed applications? What about distributed architectures?? In our system we have an applet (client) that connects to a push server for receiving distributed feeds, which connects to a backend server but exchanges info with other push servers too.

soes not suit you and why you find opening multiple
debuggers in one project more convenient.


Well, I used NetBeans, before, and this is just more practical from a usability point of view (not talking about the great amount of system resources that are spared): this said, it is clear that multi-debugging is a less-lot compelling feature if compared with hot-fix or some usability enhancements which are very important (e.g.: the thread combo list is completely unusable for systems with large numbers of threads: it should allow sorting, filtering, ...).

0
Comment actions Permalink

With different startup/config/use parameters, every
app can benefit from
multiple debugging sessions, and compare what happens
in each session.



Is this something that is worthy of its own feature? The ability to compare specific datapoints from multiple runs.

Perhaps something like a log of breakpoint evaluations that could be executed multiple times in differing configurations and compared?

I'm thinking of something like a Watch log, where you set of a set of conditional watches that get logged, and then multiple runs can be compared.

Mike

0
Comment actions Permalink

Copied these comments to an existing tracker which mentions breakpoint grouping: http://www.intellij.net/tracker/idea/viewSCR?publicId=11939

0
Comment actions Permalink

P.S. Generally it seems not a very good idea to
force to create different projects, espesially
artificial ones. In fact, the tendency is the
opposite. I tend to include more and more (even not
directly related) stuff into my workspace (read
project). Since the code gets more and more reused
it's a good way to keep old projects up-to-date
(i.e. all refactorings would automatically apply to
old projects as well). Surprisengly, I found myself
doing this more and more over time. This is, by the
way, a completely new level of development. You don't
deal with just today's needs and trends, you can have
all your history, inventions, implemented ideas
(let's say for the past 10 years), experimental stuff
and even somebodyelse's open source code right at
your fingertips. Combined with global refactoring and
code analysing tools it yields a great power. May be
you should think about making it another great
selling point for IDEA.



I agree with what was said. Specifically, I find myself doing exactly the same thing. I have much more in my project then just my project's code for exactly the same reason. I have it all available at my fingertips whenever I want it. The cost is just memory, which is cheap.

Mike

0
Comment actions Permalink

Just to sum up the discussion and throw in my two cents:

- people need multiple debuggers to test multiple entry points of the same project (e.g. it client vs. server or just slightly different apps that share almost all code)
- allow for multiple debug tabs
- active tab is "active debug process"
- breakpoints apply to all processes
- breakpoint state reflects state of breakpoint in "active debug process"
- value tooltips apply to "active debug process"
- also all actions like stepping, expression evaluation and so on apply to "active debug process"
- when a process hits a breakpoint and its tab is not active it should flash or show some other visual indicator

I think it's actually very easy to use. There's not much of a problem with having multiple debug tabs.

Stephen

0
Comment actions Permalink

"Barry Kaplan" <bkaplan@abwg.com> wrote in message news:b9et10$1km$1@is.intellij.net...

enacted. Of course, with that approach, you had to be careful not to
change the project settings, else last closed will blow away other
instances.


...which just brings up another long known issue (file synchronization):
http://www.intellij.net/tracker/idea/viewSCR?publicId=10624

Surely this aspect (synchronization) needs more development. The
current solution (sync on frame activation) is just no-go for high volume
projects. It's either too frequent and annoying (especially while debugging,
when I change frames frequently) or does not sync at all (after run or if file
got modified by another agent). To the best of my knowledge there is no
way to sync config files at all.
Having opened multiple frames (with multiple projects) will immediately
provoke synchronization problems. I can't really imagine that you would
not be able to change settings via any of the frames. It would just lower
usability standards to the level allowed for computer practice assignment
work for third grade students.
Thre are multiple solutions available. Sure JetBrains will choose the most
appropriate one, eventually.....

--Oleg



0
Comment actions Permalink

Just to sum up the discussion and throw in my two
cents:

- people need multiple debuggers to test multiple
entry points of the same project (e.g. it client vs.
server or just slightly different apps that share
almost all code)


Agreed. Along with this, it seems that the concept of using multiple debugging sessions to view differences and breakpoint grouping have merit by themselves.

- allow for multiple debug tabs


Uh. I'm not sure that this is either worth the effort, or even the desired behavior. I think multible debug tabs will be most useful for debugging the same code in multiple processes. This is probabaly pretty rare. For debugging different code in multiple processes (i.e. client/server) I think multiple workspaces is the superior solution.

- active tab is "active debug process"
- breakpoints apply to all processes


Again. Generally, I think this is NOT the correct behavior. As an option, it is fine, but Presumably the reason you have multiple processes, is because there are different run-time conditions between the two pieces of code. By requiring break points to propagate to all processes, it becomes difficult to debug common code used in 2 different processes without having both processes break.

- breakpoint state reflects state of breakpoint in
"active debug process"
- value tooltips apply to "active debug process"


This is where the hassle factor comes in with the tabs. I can conceive of the hours of frustration I am likely to have when I realize that I am evalating expressions for code I am debugging in the WRONG debug tab.

- also all actions like stepping, expression
evaluation and so on apply to "active debug process"
- when a process hits a breakpoint and its tab is not
active it should flash or show some other visual
indicator

I think it's actually very easy to use. There's not
much of a problem with having multiple debug tabs.


Couldn't disagree more.

Stephen


0
Comment actions Permalink

Are the views read-only or they allow modifications
to their contents?


Modification is important.

And it looks like the views duplicate the
functionality of the editor - is there any difference
between them?


There is a significant difference. Consider the following workflow.

I am debugging a multi-process application with multiple clients, a central clearinghouse service, with back-end dispatching applications (possibly multiple applications).

I want to have up to 5 processes being debugged at once so I can trace the route from one of the clients, through the central clearinghouse, to the back-end service.

In each case the following is true:

1) Have a different set of breakpoints / watches that I am interested in for the code. It is possible that I might have common code stretched between the processes, but I think it would be rare that I would simultaneously debug common code accross multiple processes. Automatic propagation of breakpoint settings across debugged processes would be more a hassle then help.

2) Have a different set of editors. One of my outstanding issues with IDEA is the display of and placement of editor tabs. For me the editor history and tab placement is very important in resuming the "development flow" after handling some kind of interruption. (one of these days I'll try to characterize my disappointment in a problem). If I have to share my editor tabs with a series of processes that I am debugging, then I am likely to be unsatisfied because my undo history, editor tab history, editor tab placement, etc are globaly changing for each process I debug. I want to be able to set up the back-end server editors (and tab placement, tab history, breakpoints, bookmarks, etc) without disrupting my client editors (tab placement, tab history, breakpoints, bookmarks, etc).

The more I think about it, the more I am convinced that the multiple debugger tabs has sub-optimal operability.

Mike



0
Comment actions Permalink

"Barry Kaplan" <bkaplan@abwg.com> wrote in message
news:b9et10$1km$1@is.intellij.net...

enacted. Of course, with that approach, you had to

be careful not to

change the project settings, else last closed will

blow away other

instances.


...which just brings up another long known issue
(file synchronization):
http://www.intellij.net/tracker/idea/viewSCR?publicId=
0624


I have never experienced this problem before, and I do a lot of external file modifications to things like XML files. I am usually very happy with automatic synchronization.

Surely this aspect (synchronization) needs more
development. The
current solution (sync on frame activation) is just
no-go for high volume
projects. It's either too frequent and annoying
(especially while debugging,



Presumably if it is another "view" of IDEA making changes to the files, then we would not have to depend on File-System synchronization for communicating that to other instances.

It would be much more efficient to set up some kind of event dispatching system to the other views to ask them to refresh.

Besides...Given the differences in behavior and performance of file synchronization (and the fact that it can be turned off), it isn't appropraite to use that mechanism in this scenario.

Mike

0
Comment actions Permalink

Michael,
Could you please give me an example what kind of a problem do you trying to
debug in the setting you described. I am not trying to be offensive here, it
is genuine curiosity. I do a lot of client server development and in
probably 95% cases end up debugging either client or server and probably in
5% cases both but I never was in the situation I tried to debug more than 2
processes simultaneously, even our server is actually a distributed
application. The problem here I think is that you can't debug anything until
you achieve 100% reproducibility of your problem but if you reach this
reproducibility you are pretty much localized the problem and don't need to
debug across multiple processes.
Another serious problem with IDEA debugger is that it slows down
dramatically (at least 10 times in my experience) in the presence of the
conditional breakpoints. But this is probably theme for another thread.

Alex Oscherov.

"Michael Kirby" <kirby@ess.mc.xerox.com> wrote in message
news:28252539.1052566925456.JavaMail.javamailuser@localhost...

Are the views read-only or they allow modifications
to their contents?

>

Modification is important.

>

And it looks like the views duplicate the
functionality of the editor - is there any difference
between them?

>

There is a significant difference. Consider the following workflow.

>

I am debugging a multi-process application with multiple clients, a

central clearinghouse service, with back-end dispatching applications
(possibly multiple applications).
>

I want to have up to 5 processes being debugged at once so I can trace the

route from one of the clients, through the central clearinghouse, to the
back-end service.
>

In each case the following is true:

>

1) Have a different set of breakpoints / watches that I am interested in

for the code. It is possible that I might have common code stretched
between the processes, but I think it would be rare that I would
simultaneously debug common code accross multiple processes. Automatic
propagation of breakpoint settings across debugged processes would be more a
hassle then help.
>

2) Have a different set of editors. One of my outstanding issues with

IDEA is the display of and placement of editor tabs. For me the editor
history and tab placement is very important in resuming the "development
flow" after handling some kind of interruption. (one of these days I'll try
to characterize my disappointment in a problem). If I have to share my
editor tabs with a series of processes that I am debugging, then I am likely
to be unsatisfied because my undo history, editor tab history, editor tab
placement, etc are globaly changing for each process I debug. I want to be
able to set up the back-end server editors (and tab placement, tab history,
breakpoints, bookmarks, etc) without disrupting my client editors (tab
placement, tab history, breakpoints, bookmarks, etc).
>

The more I think about it, the more I am convinced that the multiple

debugger tabs has sub-optimal operability.
>

Mike

>
>
>
>


0
Comment actions Permalink

Michael,
Could you please give me an example what kind of a
problem do you trying to
debug in the setting you described. I am not trying
to be offensive here, it
is genuine curiosity. I do a lot of client server
development and in
probably 95% cases end up debugging either client or
server and probably in
5% cases both but I never was in the situation I
tried to debug more than 2
processes simultaneously, even our server is actually
a distributed
application. The problem here I think is that you
can't debug anything until
you achieve 100% reproducibility of your problem but
if you reach this
reproducibility you are pretty much localized the
problem and don't need to
debug across multiple processes.


Of course this is all speculative, because I can't run 2 debuggers now, I must use print statements on one of the processes.

In our project we have our main application, a simulator, and a remote client. I don't usually debug more then 2 at a time (basically focusing on a published interfacec).

My goal is to verify that a specific sequence of calls is taking place and that the contents of those calls ( and anticipated affect on state) occurs.

So I will set up breakpoints in the application side of the house on both the main app, and simulator.

As the application runs, the breakpoints stop it at each transaction accross the wire, allowing me to verify the correctness of the transaction.

Since setup is a pain, and once I go past the point where I have the problem, I have to restart, it is useful to have breakpoints in two processes. Otherwise, It would be a three step process.

1) Identify the process where the problem is occuring
2) Identify the call that is failing.
3) Identify the problem (either client or server).

Most likely there would be a variety of restarts between steps. I am trying to minimize restarts.

Another serious problem with IDEA debugger is
is that it slows down
dramatically (at least 10 times in my experience) in
the presence of the
conditional breakpoints. But this is probably theme
for another thread.



Hopefully this is fixed in upcomming releases of the JDK. I know that faster debugging is a key feature for upcomming JDK releases.

Mike

0
Comment actions Permalink

I see the merits of a cloned workspace, and if this is a workable solution, then great. I'm just worried about the memory and speed impact. If it takes too long to open the second workspace (or the third or fourth workspace), or if each workspace increases memory consumption by 50meg, then I'd definitely prefer the limitations of multiple debug tabs. I also have an aversion to multiple windows. Myself and many of my colleagues prefer an IDE which organizes everything within a single frame, as we've already got too many email programs, browsers, console windows, and development utilities cluttering up our task bar. That's why we all rejected Netbeans early on.

Also, the general concensus on this thread seems to be that implementing multiple workspace windows in an efficient manner would be easier than implementing the multiple debug tabs. Is this realistic? It would seem just the opposite to me. This one is up to the Intellij guys to decide of course...

As to the issue of mixing up which VM your expressions are eval'ed in, that can be easily clarified by making the expression eval window part of the debug tab. That would only leave the popup windows as something which might be difficult to associate with a particular debug session. This is something I personally wouldn't cry to much over since I don't use this feature much (I usually use watches and the thread context window). And I still don't really believe that associating the popups with the "active" debug session will be that confusing. I suspect a developer will be concentrating on a particular session most of the time, and so will know which session the popup is related to.

Finally, if multiple debug tabs is so confusing, so difficult to implement, and such an impediment to developer productivity, then why has it been part of JBuilder for so long? And why has this JBuilder feature garnered so little antipathy from JBuilder's users over the years? This is not a Herculean task, nor is it a task which has never been accomplished before.

0
Comment actions Permalink


"Michael Kirby" <kirby@ess.mc.xerox.com> wrote in message news:17658151.1052567214168.JavaMail.javamailuser@localhost...
>

I have never experienced this problem before, and I do a lot of external file modifications to things like XML files.

I am usually very happy with automatic synchronization.

What automatic synchronization are you talking about? To the best of my knowledge there isn't one.
There is synchronization on frame activation/deactivation but it's hardly automatic. If you know something
I don't know then please share your experience. How do you manage to see up-to-date content of your
externally modified XML files without changing frames or hitting synchronize button or reopening them?
This problem is a constant pain in the neck for me.

Presumably if it is another "view" of IDEA making changes to the files, then we would not have to depend on

File-System synchronization for communicating that to other instances.
>

It would be much more efficient to set up some kind of event dispatching system to the other views to ask them to

refresh.
>

Besides...Given the differences in behavior and performance of file synchronization (and the fact that it can be

turned off), it isn't appropraite to use that mechanism in this scenario.

I agree absolutely! I guess I just could not stand the chance not to mention this problem once again...
It seems like a good idea also if IDEA could listen to some simple well-defined UDP broadcast with open
message format. Than it would be easy to generate/propagate such messages within LAN. This
would probably be a good semi-atomatic solution for systems/drives which do not support notifications
natively (i.e. Linux, network drives etc)

And, of course, it would be a crazy idea to duplicate everything while opening another project frame.
No doubt, simultaneously debugged processes will have a lot of common files, so all synchronizations
must occur on per JVM basis, not per project frame.

--Oleg


0
Comment actions Permalink

Michael,
In the case similar to yours I create two different IDEA projects one for
client and one for server (it is not a big deal in my case to create
additional project with the same codebase) and start simultaniously two
instances of IDEA and run debugger in each of them. Works almost like a
charm for me.

Alex Oscherov
"Michael Kirby" <kirby@ess.mc.xerox.com> wrote in message
news:1206501.1052740551230.JavaMail.javamailuser@localhost...

Michael,
Could you please give me an example what kind of a
problem do you trying to
debug in the setting you described. I am not trying
to be offensive here, it
is genuine curiosity. I do a lot of client server
development and in
probably 95% cases end up debugging either client or
server and probably in
5% cases both but I never was in the situation I
tried to debug more than 2
processes simultaneously, even our server is actually
a distributed
application. The problem here I think is that you
can't debug anything until
you achieve 100% reproducibility of your problem but
if you reach this
reproducibility you are pretty much localized the
problem and don't need to
debug across multiple processes.

>

Of course this is all speculative, because I can't run 2 debuggers now, I

must use print statements on one of the processes.
>

In our project we have our main application, a simulator, and a remote

client. I don't usually debug more then 2 at a time (basically focusing on
a published interfacec).
>

My goal is to verify that a specific sequence of calls is taking place and

that the contents of those calls ( and anticipated affect on state) occurs.
>

So I will set up breakpoints in the application side of the house on both

the main app, and simulator.
>

As the application runs, the breakpoints stop it at each transaction

accross the wire, allowing me to verify the correctness of the transaction.
>

Since setup is a pain, and once I go past the point where I have the

problem, I have to restart, it is useful to have breakpoints in two
processes. Otherwise, It would be a three step process.
>

1) Identify the process where the problem is occuring
2) Identify the call that is failing.
3) Identify the problem (either client or server).

>

Most likely there would be a variety of restarts between steps. I am

trying to minimize restarts.
>

Another serious problem with IDEA debugger is
is that it slows down
dramatically (at least 10 times in my experience) in
the presence of the
conditional breakpoints. But this is probably theme
for another thread.

>
>

Hopefully this is fixed in upcomming releases of the JDK. I know that

faster debugging is a key feature for upcomming JDK releases.
>

Mike

>
>


0
Comment actions Permalink


"Michael Kirby" <kirby@ess.mc.xerox.com> wrote in
message
news:17658151.1052567214168.JavaMail.javamailuser@loca
host...
>

I have never experienced this problem before, and I

do a lot of external file modifications to things
like XML files.
I am usually very happy with automatic
synchronization.

What automatic synchronization are you talking about?
To the best of my knowledge there isn't one.
There is synchronization on frame
activation/deactivation but it's hardly automatic. If
you know something
I don't know then please share your experience. How
do you manage to see up-to-date content of your
externally modified XML files without changing frames
or hitting synchronize button or reopening them?
This problem is a constant pain in the neck for me.


Perhaps I misspoke. I use XML Spy in a windows environment. alt-tab to XML Spy...Change the XML File....Alt-tab back to IDEA...Files are nice and updates. Very fast too.

But If I didn't do the frame activation, then there would be a problem...You are correct.

And, of course, it would be a crazy idea to duplicate
everything while opening another project frame.
No doubt, simultaneously debugged processes will have
a lot of common files, so all synchronizations
must occur on per JVM basis, not per project frame.



Agreed...

Mike

0
Comment actions Permalink


"Michael Kirby" <kirby@ess.mc.xerox.com> wrote in message news:18258927.1052771292433.JavaMail.javamailuser@localhost...
>

Perhaps I misspoke. I use XML Spy in a windows environment. alt-tab to XML Spy...Change the XML File....Alt-tab back

to IDEA...Files are nice and updates. Very fast too.

Very fast? Just curious, what kind of hardware do you use and what is the size of the project?
Eventually I've disabled even frame activation based sync because every frame flip-flop
during debugging spawns a totally unnecessary and useless sync which takes up to a half
a minute (plus another half for GC from time to time) on my home W2K 500MHz 512Mb RAM,
which makes debugging unbearable annoying (JetBrainers, I hope you're reading this :().

--Oleg


0
Comment actions Permalink

Very fast? Just curious, what kind of hardware do you
use and what is the size of the project?
Eventually I've disabled even frame activation based
sync because every frame flip-flop
during debugging spawns a totally unnecessary and
useless sync which takes up to a half
a minute (plus another half for GC from time to time)
on my home W2K 500MHz 512Mb RAM,
which makes debugging unbearable annoying
(JetBrainers, I hope you're reading this :().


I have an Athalon XP1700 with 1 GB of ram. It's a Soyo Dragon+ motherboard based machine I put together myself. It seems to outperform Dell PC's we have here with clockspeeds in excess of 2 GH.

I use Clearcase snapshot views which stores all my project files on the local hard-drive. So there is no network access. I have also tuned the crap out of the machine to get network delays and the like to a minimum -- Those of you using clearcase should consider turning off netbios)

It's running W2k SP2. Our project is about 2000 classes running on JDK 1.4.1_02.

I would have to say that the hardware you are running on is probabaly too small. We have a number of Dell Precision 220's that we purchased a while back. These have PIII 700mhz processors. But they have pretty fast IO, and a decent motherboard. They were pig-dog slow (why are pig-dog's slow??) until we upgraded them to 1GB of memory.

If your IO is reasonably fast, then I would recommend adding another 512mb. You will be amazed at the difference. Even if you program completely fits in RAM today, having at least 256 mb of free RAM allows windows to use gobs of memory as filesystem cache. That makes compilation run very quickly.

Mike

0
Comment actions Permalink

Michael Kirby wrote:

If your IO is reasonably fast, then I would recommend adding another 512mb. You will be amazed at the difference. Even if you program completely fits in RAM today, having at least 256 mb of free RAM allows windows to use gobs of memory as filesystem cache. That makes compilation run very quickly.


Sound advice. 1GB of RAM made a world of difference for me as well.

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://java.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: 416-643-4846 | Fax: 416-594-1919

0
Comment actions Permalink

Moi aussi.

Gordon Tyler wrote:

Michael Kirby wrote:

>> If your IO is reasonably fast, then I would recommend adding another
>> 512mb. You will be amazed at the difference. Even if you program
>> completely fits in RAM today, having at least 256 mb of free RAM
>> allows windows to use gobs of memory as filesystem cache. That
>> makes compilation run very quickly.
>

Sound advice. 1GB of RAM made a world of difference for me as well.

>

Ciao,
Gordon



0
Comment actions Permalink

Also, the general concensus on this thread seems to be that implementing

multiple workspace windows in an efficient manner would be easier than
implementing the multiple debug tabs. Is this realistic? It would seem
just the opposite to me. This one is up to the Intellij guys to decide of
course...


I also think multiple workspaces will be more work than more debugger tabs.

IMHO, multiple workspaces, with the possibility of having different modules,
debugging sessions, running sessions, etc open, each of these with their
associated source/resource files/tabs/panels opened would be a greater
improvement than another debugger tab


But I have to confess that I'm a little (a lot :) prejudiced: I don't fell
a need for multiple debugging and would like to to have multiple workspaces
:)

Carlos


0
Comment actions Permalink

On Wed, 14 May 2003 02:08:57 +0100, Carlos Costa e Silva wrote:

But I have to confess that I'm a little (a lot :) prejudiced: I don't
fell a need for multiple debugging and would like to to have multiple
workspaces
:)


Does multiple workspaces equate to multiple instances? I found the other
day when I had two projects open, when one was rebuilding, I could alt-tab
to the other, but it was locked up whilst the first was building :(

--
...turn to the light - don't be frightened by the shadows it creates,
...turn to the light - turning away could be a terrible mistake
...dream theater - the great debate


0
Comment actions Permalink

What actually was the reason for limiting Idea to only once instance?


Merely internal technical problems. They would share lot of information in
and folders and simultenous access to it could corrupt it. So we actually allow multiple IDEA instances but you should specify different config and system folders. -- Valentin Kipiatkov JetBrains, Inc http://www.intellij.com "Develop with pleasure!" "Mark Derricutt" ]]> wrote in message
news:pan.2003.05.09.06.00.40.264526@satinism.org...

On Thu, 08 May 2003 19:33:18 -0500, Barry Kaplan wrote:

>

I must say, that before idea prevented the launching of multiple
instances, that indirectly supported multiple debug sessions. It was

only

late in Aroura eap that the limitation of only one idea process was
enacted. Of course, with that approach, you had to be careful not to
change the project settings, else last closed will blow away other
instances.

>

What actually was the reason for limiting Idea to only once instance?
Licensing issues ( I had thought of this, with exported X sessions on
*nix ), but one could still limit multi instances, but only to say the
same display/monitor. Mmm.

>
>

--
...turn to the light - don't be frightened by the shadows it creates,
...turn to the light - turning away could be a terrible mistake
...dream theater - the great debate

>


0
Comment actions Permalink

This feature is not only required for client-server applications but any distributed application.

0

Please sign in to leave a comment.