[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[platform-debug-dev] Re: Launch configuration support not using dialog
|
I agree with the first two paragraphs. Thanks.
It would be nice to get the added support/changes for free. This is a good
suggestion - I will store a "key" attribute that the delegate can use to
pick up the rest of the parameters from the daemon, which will allow me to
use the #launch method.
From the configuration design doc you posted in November, you stated that a
launch that does not have a configuration cannot be added to the launch
history. Is there any other way to stop a launch from being added to the
launch history? Most of our non-dialog launches cannot be relaunched
through the UI.... We'd like to keep all launches as similar as possible,
so it would be nice to be able to use the launch configurations, without
adding the launch to the history.
Thanks.
Kristen
platform-debug-dev-request@e
clipse.org To: platform-debug-dev@xxxxxxxxxxx
Sent by: cc:
platform-debug-dev-admin@ecl Subject: platform-debug-dev digest, Vol 1 #69 - 2 msgs
ipse.org
04/01/2002 12:05 PM
Please respond to
platform-debug-dev
2. Re: Launch configuration support not using dialog
(Darin_Wright@xxxxxxx)
--__--__--
Message: 2
To: platform-debug-dev@xxxxxxxxxxx
Subject: Re: [platform-debug-dev] Launch configuration support not using
dialog
From: Darin_Wright@xxxxxxx
Date: Mon, 1 Apr 2002 10:33:47 -0600
Reply-To: platform-debug-dev@xxxxxxxxxxx
This is a multipart message in MIME format.
--=_alternative 005B0E9886256B8E_=
Content-Type: text/plain; charset="us-ascii"
Access to the launch delegate has been provided on
ILaunchConfigurationType (as there is only one delegate per launch config
type).
When a launch fails, a delegate should generally not de-register the
launch. Sometimes, useful information can be obtained by leaving the
launch registered - for example, some console I/O may provide details of
the failed launch. If the launch fails before a debug target or process is
created (i.e. a failed, empty launch), the debug framework could remove
the launch. In this case, the delegate should be throwing an exception
describing why the launch failed. This exception/status will be shown by
the debug UI in an error dialog.
Question: Would it be possible for you to use the #launch method by
passing the extra launch parameters as launch configuration attribtues?
Although you could by-pass the framework's launch mechanism, it means that
you do not inherit the common behavior, and you will be broken if/when
more common behavior is added/changed.
Darin
desarmo@xxxxxxxxxx
Sent by: platform-debug-dev-admin@xxxxxxxxxxx
03/28/2002 05:21 PM
Please respond to platform-debug-dev
To: platform-debug-dev@xxxxxxxxxxx
cc:
Subject: [platform-debug-dev] Launch configuration support
not using dialog
I am working on our launch configurations and I really like the design for
launching through the dialog. However, I have run into difficulty with
our
non-dialog scenario when an engine (or kicker) calls our daemon and
specifies the launch configuration (or launch configuration type) that
should be used for the launch. I cannot use
ILaunchConfiguration.launch(String, IProgressMonitor) because I have to
pass additional parameters to the delegate. Therefore, I need the
LaunchConfiguration.getDelegate() method to be public so that I know where
to delegate the launch request.
In response to the launch lifecycle changes proposed yesterday, I believe
this is OK provided that I can complete steps 1-4 myself (for the case
above) up to the point that the launch configuration takes over, i.e., I
won't be calling launch()... I also still need to be able to create and
register a launch without going through a launch configuration.
<steps copied from Darin's proposal>
(1) An empty launch object will be created by a launch configuration when
its launch method is called (since there is only one shared implementation
of ILaunchConfiguration, all clients inherit this behavoir for free). The
launch is empty in the sense that it does not contain any debug targets or
system processes at this point.
(2) The launch object will be seeded to point to the associated launch
configuration being launched
(3) The launch object will be registered with the debug plug-in
(4) The launch object will be passed to the configuration's associated
delegate to perform the actual launch.
(5) The delegate will launch/create processes and debug targets and ADD
them to the provided (already existing) launch object
If the launch fails after step 3, what is the expected error reporting
process? Would the delegate de-register the launch or terminate it or just
set the target to null?
Thanks.
Kristen Desarmo
IBM Distributed Debugger
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev
--=_alternative 005B0E9886256B8E_=
Content-Type: text/html; charset="us-ascii"
<br><font size=2 face="sans-serif">Access to the launch delegate has been
provided on ILaunchConfigurationType (as there is only one delegate per
launch config type).</font>
<br>
<br><font size=2 face="sans-serif">When a launch fails, a delegate should
generally not de-register the launch. Sometimes, useful information can be
obtained by leaving the launch registered - for example, some console I/O
may provide details of the failed launch. If the launch fails before a
debug target or process is created (i.e. a failed, empty launch), the debug
framework could remove the launch. In this case, the delegate should be
throwing an exception describing why the launch failed. This
exception/status will be shown by the debug UI in an error dialog.</font>
<br>
<br><font size=2 face="sans-serif">Question: Would it be possible for you
to use the #launch method by passing the extra launch parameters as launch
configuration attribtues? Although you could by-pass the framework's launch
mechanism, it means that you do not inherit the common behavior, and you
will be broken if/when more common behavior is added/changed.</font>
<br>
<br><font size=2 face="sans-serif">Darin</font>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>desarmo@xxxxxxxxxx</b></font>
<br><font size=1 face="sans-serif">Sent by:
platform-debug-dev-admin@xxxxxxxxxxx</font>
<p><font size=1 face="sans-serif">03/28/2002 05:21 PM</font>
<br><font size=1 face="sans-serif">Please respond to
platform-debug-dev</font>
<br>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To:
platform-debug-dev@xxxxxxxxxxx</font>
<br><font size=1 face="sans-serif"> cc:
</font>
<br><font size=1 face="sans-serif"> Subject:
[platform-debug-dev] Launch configuration
support not using dialog</font></table>
<br>
<br><font size=2 face="Courier New">I am working on our launch
configurations and I really like the design for<br>
launching through the dialog. However, I have run into difficulty
with our<br>
non-dialog scenario when an engine (or kicker) calls our daemon and<br>
specifies the launch configuration (or launch configuration type) that<br>
should be used for the launch. I cannot use<br>
ILaunchConfiguration.launch(String, IProgressMonitor) because I have to<br>
pass additional parameters to the delegate. Therefore, I need
the<br>
LaunchConfiguration.getDelegate() method to be public so that I know
where<br>
to delegate the launch request.<br>
<br>
In response to the launch lifecycle changes proposed yesterday, I
believe<br>
this is OK provided that I can complete steps 1-4 myself (for the case<br>
above) up to the point that the launch configuration takes over, i.e.,
I<br>
won't be calling launch()... I also still need to be able to create
and<br>
register a launch without going through a launch configuration.<br>
<br>
<steps copied from Darin's proposal><br>
(1) An empty launch object will be created by a launch configuration
when<br>
its launch method is called (since there is only one shared
implementation<br>
of ILaunchConfiguration, all clients inherit this behavoir for free).
The<br>
launch is empty in the sense that it does not contain any debug targets
or<br>
system processes at this point.<br>
(2) The launch object will be seeded to point to the associated launch<br>
configuration being launched<br>
(3) The launch object will be registered with the debug plug-in<br>
(4) The launch object will be passed to the configuration's associated<br>
delegate to perform the actual launch.<br>
(5) The delegate will launch/create processes and debug targets and ADD<br>
them to the provided (already existing) launch object<br>
<br>
If the launch fails after step 3, what is the expected error reporting<br>
process? Would the delegate de-register the launch or terminate it or
just<br>
set the target to null?<br>
<br>
Thanks.<br>
<br>
Kristen Desarmo<br>
IBM Distributed Debugger<br>
<br>
_______________________________________________<br>
platform-debug-dev mailing list<br>
platform-debug-dev@xxxxxxxxxxx<br>
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev<br>
</font>
<br>
<br>
--=_alternative 005B0E9886256B8E_=--
--__--__--
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev
End of platform-debug-dev Digest
