New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop supporting onDebug:type activation event #33803

Closed
isidorn opened this Issue Sep 4, 2017 · 7 comments

Comments

Projects
None yet
4 participants
@isidorn
Contributor

isidorn commented Sep 4, 2017

Stop support for onDebug:type

Currently the C++ extension seems to be the only extension getting activated by onDebug:type event. Since we added this event we have introduced alternative ways for extensions to be activated so there is possibly a better way to achieve what the C++ extension needs here.

@pieandcakes could you please clarify how you useonDebug:type in your extension. So we could potentially adivse to use a different solution

fyi @weinand

related #33258

@isidorn isidorn added debt debug labels Sep 4, 2017

@isidorn isidorn added this to the October 2017 milestone Sep 4, 2017

@isidorn isidorn self-assigned this Sep 4, 2017

@isidorn

This comment has been minimized.

Show comment
Hide comment
@isidorn

isidorn Sep 29, 2017

Contributor

@pieandcakes ping regarding this issue

Contributor

isidorn commented Sep 29, 2017

@pieandcakes ping regarding this issue

@roblourens

This comment has been minimized.

Show comment
Hide comment
@roblourens

roblourens Nov 9, 2017

Member

@ramya-rao-a and I noticed that the current state is actually not that great for the Go extension. It contributes a debugger and a language server, so activating is a heavy operation that ideally would only happen when Go files are detected. But now it happens when a debug session of any type is started.

Most debug extensions probably just contribute debuggers, so vscode-go may be an oddball. Any thoughts on how to mitigate this?

Microsoft/vscode-go#1324

Member

roblourens commented Nov 9, 2017

@ramya-rao-a and I noticed that the current state is actually not that great for the Go extension. It contributes a debugger and a language server, so activating is a heavy operation that ideally would only happen when Go files are detected. But now it happens when a debug session of any type is started.

Most debug extensions probably just contribute debuggers, so vscode-go may be an oddball. Any thoughts on how to mitigate this?

Microsoft/vscode-go#1324

@testforstephen

This comment has been minimized.

Show comment
Hide comment
@testforstephen

testforstephen Nov 9, 2017

@isidorn @weinand @aeschli
Got similar perf issue for java debugger. When user is debugging non-java project, also activate java language server and debugger extension.
See the issue Microsoft/vscode-java-debug#142

testforstephen commented Nov 9, 2017

@isidorn @weinand @aeschli
Got similar perf issue for java debugger. When user is debugging non-java project, also activate java language server and debugger extension.
See the issue Microsoft/vscode-java-debug#142

@weinand

This comment has been minimized.

Show comment
Hide comment
@weinand
Member

weinand commented Nov 9, 2017

@aeschli fyi

@isidorn

This comment has been minimized.

Show comment
Hide comment
@isidorn

isidorn Nov 9, 2017

Contributor

I understand the issue. Thanks for letting us know @roblourens @testforstephen
I do not see this as a critical issue, so I suggest to try to fix this in November. Options:

  • introduce new activation event "onDebugSession:type" which would fire everytime a session of that type is about to start. Basically would behave like the old event

Suggestions are also welcome. Once we come to the conclusion I can open a new issue for November to track this.

Contributor

isidorn commented Nov 9, 2017

I understand the issue. Thanks for letting us know @roblourens @testforstephen
I do not see this as a critical issue, so I suggest to try to fix this in November. Options:

  • introduce new activation event "onDebugSession:type" which would fire everytime a session of that type is about to start. Basically would behave like the old event

Suggestions are also welcome. Once we come to the conclusion I can open a new issue for November to track this.

@weinand

This comment has been minimized.

Show comment
Hide comment
@weinand

weinand Nov 9, 2017

Member

I've created #37918 to track this.

Member

weinand commented Nov 9, 2017

I've created #37918 to track this.

@weinand

This comment has been minimized.

Show comment
Hide comment
@weinand

weinand Nov 9, 2017

Member

@isidorn activating on a specific type only would miss the case of collecting all registered DebugConfigurationProviders for the "initialLaunchConfigs" functionality.

Member

weinand commented Nov 9, 2017

@isidorn activating on a specific type only would miss the case of collecting all registered DebugConfigurationProviders for the "initialLaunchConfigs" functionality.

@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 17, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.