platform-debug-dev

[platform-debug-dev] Debug Contribution

Darin_Wright@xxxxxxx (Darin Wright) — Mon, 23 Nov 2009 21:35:58 GMT

The map file has been updated for the following Bug changes:
+ Bug 200364. The 'variables view' will sometimes show 'null' values for 
variables that do have a value (FIXED)
+ Bug 290285. API for custom JDWP commands and model state refresh 
(ASSIGNED)
+ Bug 291267. [flex-hierarchy] Viewer does not preserve expansion state 
correctly when elements are inserted/removed due to IModelDelta.CONTENT 
(FIXED)
+ Bug 295585. Test failures in I20091118-1342 (FIXED)
+ Bug 295765. [flex-hierarchy] There are multiple update sequences 
reported during a single view refresh. (FIXED)

The following projects have changed:
org.eclipse.jdt.debug
org.eclipse.jdt.debug.tests
org.eclipse.debug.ui
org.eclipse.jdt.debug.ui
org.eclipse.debug.tests

Darin

RE: [platform-debug-dev] launch shortcut question

dalexiev@xxxxxxx (Alexiev, Dobrin) — Mon, 23 Nov 2009 15:56:33 GMT

Darin, 

My launch shortcut implements ILaunchShortcut2.

In my environment there are two launch shortcuts that can handle C projects. 

When the function ContextRunner.getParticipatingLaunchConfigurations() is invoked I see that it loops through both launch shortcuts.  
Mine shortcut's ILaunchShortcut2.getLaunchConfigurations(ISelection selection) returns empty array - a configuration does not exists but can be created. 
The other shortcuts' ILaunchShortcut2.getLaunchConfigurations(ISelection selection) returns null. 

Because of the other launch shortcut' ILaunchShortcut2.getLaunchConfigurations(ISelection selection) is returning null the variable useDefault is set to true. Once that variable is set to true it will get all launches from all launch shortcuts considered compatible with the project. 
Since my launch configuration doesn't have mapped resources the function LaunchConfigurationManager.getApplicableLaunchConfigurations( null, project) will return my launch configuration. 


Looking at the use case: 
Two launch shortcuts can handle the same project - one is saying "I don't have a launch configuration for this project but I can create one", the other is saying "default resource mapping should be used" ending up launching a launch configuration from the first launch shortcut that is not related to the project. 

I guess I was expecting a dialog to be popped up to ask the user to resolve which launch shortcut to be used - that is exactly the case if I don't have a launch configuration already created (or have one mapped to a different project). 

Is there a way I can achieve this? 

Thanks
Dobrin

-----Original Message-----
From: platform-debug-dev-bounces@xxxxxxxxxxx [mailto:platform-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Darin Wright
Sent: November 22, 2009 11:54 AM
To: Eclipse Platform Debug component developers list.
Subject: Re: [platform-debug-dev] launch shortcut question

> 
> Hello, 
> 
> For our debugger I am implementing a launch configuration type and a
> launch shortcut for that type. 
> 
> Some of the configurations of that type are created based on a 
> project and for these configurations I call 
> LaunchConfigurationWorkingCopy.setMappedResources().
> 
> But other configurations of the same type are based on different 
> selection (an external file from a different view) so there is no 
> project associated with these launch configuration instances. In 
> that case I don't call 
LaunchConfigurationWorkingCopy.setMappedResources().
> 
> Here is the problem: 
> When I select a project and click on the debug toolbar a previously 
> created configuration based on external file is launched 
> automatically.  Everything works fine if all my launch 
> configurations had mapped resource associated with them. 
> 
> I traced that this behaviour is due to 
> LaunchConfigurationManager.getApplicableLaunchConfigurations.
> When the function is trying to find launch configurations applicable
> to a specific resource it assumes that if a launch configuration 
> doesn't have mapped resources the launch configuration should be 
applicable. 
> 
> I was wandering if there is an API that should be called so the 
> launch configuration manager won't assume  configuration that 
> doesn't have mapped resource will be applicable for this resource?
> 
> Thanks 
> Dobrin_______________________________________________

You should be able to solve this by having your launch shortcut implement 
ILaunchShortcut2. This allows the shortcut to determine which existing 
configurations are applicable to a selection or active editor.

Darin

Re: [platform-debug-dev] launch shortcut question

Darin_Wright@xxxxxxx (Darin Wright) — Sun, 22 Nov 2009 16:53:55 GMT

> 
> Hello, 
> 
> For our debugger I am implementing a launch configuration type and a
> launch shortcut for that type. 
> 
> Some of the configurations of that type are created based on a 
> project and for these configurations I call 
> LaunchConfigurationWorkingCopy.setMappedResources().
> 
> But other configurations of the same type are based on different 
> selection (an external file from a different view) so there is no 
> project associated with these launch configuration instances. In 
> that case I donât call 
LaunchConfigurationWorkingCopy.setMappedResources().
> 
> Here is the problem: 
> When I select a project and click on the debug toolbar a previously 
> created configuration based on external file is launched 
> automatically.  Everything works fine if all my launch 
> configurations had mapped resource associated with them. 
> 
> I traced that this behaviour is due to 
> LaunchConfigurationManager.getApplicableLaunchConfigurations.
> When the function is trying to find launch configurations applicable
> to a specific resource it assumes that if a launch configuration 
> doesnât have mapped resources the launch configuration should be 
applicable. 
> 
> I was wandering if there is an API that should be called so the 
> launch configuration manager wonât assume  configuration that 
> doesnât have mapped resource will be applicable for this resource?
> 
> Thanks 
> Dobrin_______________________________________________

You should be able to solve this by having your launch shortcut implement 
ILaunchShortcut2. This allows the shortcut to determine which existing 
configurations are applicable to a selection or active editor.

Darin

[platform-debug-dev] launch shortcut question

dalexiev@xxxxxxx (Alexiev, Dobrin) — Fri, 20 Nov 2009 23:05:09 GMT

Hello,

For our debugger I am implementing a launch configuration type and a launch shortcut for that type.

Some of the configurations of that type are created based on a project and for these configurations I call LaunchConfigurationWorkingCopy.setMappedResources().

But other configurations of the same type are based on different selection (an external file from a different view) so there is no project associated with these launch configuration instances. In that case I don’t call LaunchConfigurationWorkingCopy.setMappedResources().

Here is the problem:

When I select a project and click on the debug toolbar a previously created configuration based on external file is launched automatically. Everything works fine if all my launch configurations had mapped resource associated with them.

I traced that this behaviour is due to LaunchConfigurationManager.getApplicableLaunchConfigurations.

When the function is trying to find launch configurations applicable to a specific resource it assumes that if a launch configuration doesn’t have mapped resources the launch configuration should be applicable.

I was wandering if there is an API that should be called so the launch configuration manager won’t assume configuration that doesn’t have mapped resource will be applicable for this resource?

Thanks

Dobrin

[platform-debug-dev] Breakpoint actions support

ken.ryall@xxxxxxx (ken.ryall) — Thu, 19 Nov 2009 22:36:13 GMT

Hi,

As we discussed on our last call I created a bugzilla and attached my first
pass at moving the breakpoint action support from CDT to the Debug Platform.
There is no support for the Java debugger yet and there are a few other
issues to clean up but the basics and APIs are there.

I'll be on vacation all next week but will respond to any feedback shortly
after I return.

Thanks - Ken

https://bugs.eclipse.org/bugs/show_bug.cgi?id=295658

[platform-debug-dev] BreakpointActionType extension point enablement

marc.khouzam@xxxxxxx (Marc Khouzam) — Tue, 17 Nov 2009 15:22:10 GMT

Hi,

This is a suggestion for Breakpoint Action, and since there is talk about moving this feature to Platform, I'm copying

patform-debug-dev.

The CDT currently provides an extension point BreakpointActionType to define actions to execute when a breakpoint is hit.

I would like to add an optional 'enablement' condition to control when that ActionType is applicable.

For example, for Tracepoints, a different set of actions is applicable. "Resume" does not apply for a Tracepoint, while a new

"Collect" would only apply to Tracepoints.

I would add the standard "enablement" support with:

I don't know how close this feature is to being part of Platform and if this was already discussed.

Should I go ahead and open a bug in CDT and make a patch for CDT?

Thanks

Marc

[platform-debug-dev] Debug contribution

Darin_Wright@xxxxxxx (Darin Wright) — Mon, 16 Nov 2009 21:05:52 GMT

The map file has been updated for the following Bug changes:
+ Bug 291267. [flex-hierarchy] Viewer does not preserve expansion state 
correctly when elements are inserted/removed due to IModelDelta.CONTENT 
(FIXED)
+ Bug 294553. toggleBreakpointsTargetFactories extension point does not 
respect ActionSet (FIXED)

The following projects have changed:
org.eclipse.debug.core
org.eclipse.debug.ui
org.eclipse.debug.tests

Re: [platform-debug-dev] Launch Templates

rat042@xxxxxxx (John Cortell) — Mon, 16 Nov 2009 17:00:26 GMT

Darin,

Yeah. It does see to me that this gets complicated. You would need to give users the ability to specify the applicability on a per attribute level in order to properly support pushing updates to the children of the template. You could do that via a table, but that would mean exposing attribute names to the user, and the typical users doesn't deal with attributes (and shouldn't have to, IMO, in order to properly make use of this new feature).

Seems to me these complications come to light only in the 'update' aspect of the feature. While I think it's a nice capability, I think template are still useful and worthwhile without them. Removing the 'update' aspect also simplifies the existing proposal. You would not need to preserve a parent/child between a template and its offspring.

John

At 01:36 PM 11/12/2009, Darin Wright wrote:

While working on the user interface for launch templates, I stumbled
across the problem described below. I've updated the WIKI (
http://wiki.eclipse.org/Debug/Plan/3.6/Launch_Templates#Design_Decisions)
with this description. Any input would be appreciated. Basically, we need
to decide if it is worthwhile moving ahead with the template
implementation with this limitation.

Launch configurations are relatively simple attribute/value data
structures. However, a launch configuration can use the absence of an
attribute to indicate important data. For example, when the JRE attribute
is not present for Java Application launch configurations, it indicates
that the project (or workspace) default JRE should be used (depending on
whether the configuration is associated with a project). This imposes a
limitation on template implementation: simply copying attributes from a
template to a configuration does not work for template application - as
this does not cause unspecified attributes to be removed.

For example, when a configuration specifies a specific JRE and a template
specifies a default JRE (null), copying attributes will result in the
specific JRE setting to remain in the configuration. For this reason it is
important to persist "null" and "removed" values in configuration
templates. This adds to the complexity of templates - as templates will
often be incomplete. For example, a template would not often contain a
main type name to launch - that whould usually be specified by individual
configurations. So, if the template contained a null or empty main type
name, we would not want this to cause the main type name in configurations
to be wiped out.

For these reasons, it is important that templates contain only the
relevant (sub)set of attributes that they define, and that null/removed
values are also persisted in the template. This also imposes restrictions
in the user interface implementation. If all launch tabs are present for a
template, all attributes will be present in that template - and
effectively override all settings its children configurations. To solve
this problem, a subset of tabs could be allowed for templates - and the
user should decide which tabs are going to be present in their template.
It also means that the effectiveness of templates depends on the existing
set of attributes grouped on each tab, as each tab will be applied in its
entirety to its children configurations. (The platform has no way of
associating attributes with launch tab controls, so this is the finest
granularity it can offer with existing APIs).

Darin
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev

Re: [platform-debug-dev] Launch Templates

pawel.piech@xxxxxxx (Pawel Piech) — Thu, 12 Nov 2009 20:41:07 GMT

Pawel Piech wrote:

One common request we get from our users is that they would like to be able to edit the launch configurations in a plain editor.

P.S. Technically this is possible now, but some of the attribute values are just too opaque.

This gives me an idea for a low-tech (and a somewhat crude) solution to this problem: what if we gave the user an option to see and edit the LC templates in its raw form (as property name/value pairs). Then the user could selectively look at the attributes and zero-out the ones that should not be in the template. Cheers Pawel

Darin Wright wrote:
While working on the user interface for launch templates, I stumbled across the problem described below. I've updated the WIKI ( http://wiki.eclipse.org/Debug/Plan/3.6/Launch_Templates#Design_Decisions) with this description. Any input would be appreciated. Basically, we need to decide if it is worthwhile moving ahead with the template implementation with this limitation.

Launch configurations are relatively simple attribute/value data structures. However, a launch configuration can use the absence of an attribute to indicate important data. For example, when the JRE attribute is not present for Java Application launch configurations, it indicates that the project (or workspace) default JRE should be used (depending on whether the configuration is associated with a project). This imposes a limitation on template implementation: simply copying attributes from a template to a configuration does not work for template application - as this does not cause unspecified attributes to be removed. For example, when a configuration specifies a specific JRE and a template specifies a default JRE (null), copying attributes will result in the specific JRE setting to remain in the configuration. For this reason it is important to persist "null" and "removed" values in configuration templates. This adds to the complexity of templates - as templates will often be incomplete. For example, a template would not often contain a main type name to launch - that whould usually be specified by individual configurations. So, if the template contained a null or empty main type name, we would not want this to cause the main type name in configurations to be wiped out. For these reasons, it is important that templates contain only the relevant (sub)set of attributes that they define, and that null/removed values are also persisted in the template. This also imposes restrictions in the user interface implementation. If all launch tabs are present for a template, all attributes will be present in that template - and effectively override all settings its children configurations. To solve this problem, a subset of tabs could be allowed for templates - and the user should decide which tabs are going to be present in their template. It also means that the effectiveness of templates depends on the existing set of attributes grouped on each tab, as each tab will be applied in its entirety to its children configurations. (The platform has no way of associating attributes with launch tab controls, so this is the finest granularity it can offer with existing APIs).

Darin _______________________________________________ platform-debug-dev mailing list platform-debug-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev

Re: [platform-debug-dev] Launch Templates

pawel.piech@xxxxxxx (Pawel Piech) — Thu, 12 Nov 2009 20:37:33 GMT

One common request we get from our users is that they would like to be able to edit the launch configurations in a plain editor. This gives me an idea for a low-tech (and a somewhat crude) solution to this problem: what if we gave the user an option to see and edit the LC templates in its raw form (as property name/value pairs). Then the user could selectively look at the attributes and zero-out the ones that should not be in the template.

Cheers
Pawel

Darin Wright wrote:

While working on the user interface for launch templates, I stumbled across the problem described below. I've updated the WIKI ( http://wiki.eclipse.org/Debug/Plan/3.6/Launch_Templates#Design_Decisions) with this description. Any input would be appreciated. Basically, we need to decide if it is worthwhile moving ahead with the template implementation with this limitation.

Launch configurations are relatively simple attribute/value data structures. However, a launch configuration can use the absence of an attribute to indicate important data. For example, when the JRE attribute is not present for Java Application launch configurations, it indicates that the project (or workspace) default JRE should be used (depending on whether the configuration is associated with a project). This imposes a limitation on template implementation: simply copying attributes from a template to a configuration does not work for template application - as this does not cause unspecified attributes to be removed.

For example, when a configuration specifies a specific JRE and a template specifies a default JRE (null), copying attributes will result in the specific JRE setting to remain in the configuration. For this reason it is important to persist "null" and "removed" values in configuration templates. This adds to the complexity of templates - as templates will often be incomplete. For example, a template would not often contain a main type name to launch - that whould usually be specified by individual configurations. So, if the template contained a null or empty main type name, we would not want this to cause the main type name in configurations to be wiped out.

For these reasons, it is important that templates contain only the relevant (sub)set of attributes that they define, and that null/removed values are also persisted in the template. This also imposes restrictions in the user interface implementation. If all launch tabs are present for a template, all attributes will be present in that template - and effectively override all settings its children configurations. To solve this problem, a subset of tabs could be allowed for templates - and the user should decide which tabs are going to be present in their template. It also means that the effectiveness of templates depends on the existing set of attributes grouped on each tab, as each tab will be applied in its entirety to its children configurations. (The platform has no way of associating attributes with launch tab controls, so this is the finest granularity it can offer with existing APIs).

Darin _______________________________________________ platform-debug-dev mailing list platform-debug-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/platform-debug-dev