Skip to content
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

Debugging without an open folder #285

Closed
shashankt1989 opened this issue Nov 19, 2015 · 30 comments

Comments

Projects
None yet
8 participants
@shashankt1989
Copy link

commented Nov 19, 2015

Why is folder required to have debugging enabled?
Case in point - trying out single file ps scripts. Am I missing something?

@isidorn

This comment has been minimized.

Copy link
Contributor

commented Nov 20, 2015

I see that your scenario would not require the workspace, however our vscode frontend has to support multiple languages to debug and for most having a workspace is required. Also debugging requires a launch.json file, and when there is no workspace there needs to be a shared launch.json which is a bit cumbersome.

Due to the above this is by design.

@isidorn isidorn closed this Nov 20, 2015

@shashankt1989

This comment has been minimized.

Copy link
Author

commented Nov 20, 2015

So keep it as an open issue in case someone wants to code up a solution? Or is it something that we don't want to have at all because it would make the product worse?

@isidorn isidorn reopened this Nov 20, 2015

@isidorn

This comment has been minimized.

Copy link
Contributor

commented Nov 20, 2015

Let's keep it open for now then

@isidorn isidorn self-assigned this Nov 24, 2015

@isidorn isidorn added the debug label Nov 24, 2015

@egamma egamma modified the milestone: Backlog Dec 10, 2015

@isidorn isidorn removed their assignment Dec 22, 2015

@mateuszlewko

This comment has been minimized.

Copy link

commented Feb 21, 2016

Yes this would be a useful feature. Debuging just a single file. Please add this.

@davehope

This comment has been minimized.

Copy link

commented Nov 10, 2016

I'd like to explain a possible use case for this.

I use vscode to write PowerShell scripts, these are usually single-files. I'd like to be able to open a Powershell file, set some break points and debug the script like I can with the PowerShell ISE

@daviwil

This comment has been minimized.

Copy link
Member

commented Dec 6, 2016

I'm starting to see a real need for this in the PowerShell extension but I'll bet that it'd also be helpful for other languages with a more dynamic/interactive development workflow (Python, F#, etc). Here's a thought:

  1. The user opens VS Code and starts typing in a file then saves it with a .ps1 extension.
  2. The user sets a breakpoint and presses F5
  3. Because there isn't a folder currently open, VS Code assumes the user wants to launch the debug adapter for the extension that provides a debugger contribution for the current file type (in this case the PowerShell extension). It generates a launch.json in a temporary directory using the extension's default configuration and then launches the debug adapter with that.

It may be necessary to also have a different type of default, single-file configuration or maybe some way to generate one.

I realize there's some work required to enable this, but does this set of steps sound reasonable?

@isidorn

This comment has been minimized.

Copy link
Contributor

commented Dec 6, 2016

@daviwil we actually had this feature 1 year ago but removed it because it was causing issues and did not provide any key benefits. I understand that the powershell users would definetly benefit from this now.
@weinand and @kieferrm can decide how high is this on our priority list

@daviwil

This comment has been minimized.

Copy link
Member

commented Dec 6, 2016

Yeah, this is one of the core expectations of PowerShell users since it's a primary development workflow in the PowerShell ISE editor. I would love to work with you guys to find out a good way to enable this without disrupting the existing folder-based debugger configuration.

@TheKnightCoder

This comment has been minimized.

Copy link

commented Dec 7, 2016

I would also like this feature. Opening a single file with vs code feels kind of useless. Is it bad if vs code automatically opened the parent folder when someone opens a file with vs code.

@weinand weinand self-assigned this Dec 7, 2016

@isidorn isidorn self-assigned this Dec 23, 2016

@isidorn isidorn modified the milestones: January 2017, Backlog Dec 23, 2016

@isidorn

This comment has been minimized.

Copy link
Contributor

commented Dec 23, 2016

Ok let's do this, moving to January for exploration.
Was thinking a bit about this, imho we have two options:

1. Have a shared "launch.json" in a user folder which is used for all no-folder workspaces

  • same experience as setting up regular debugging, all improvment which we do for launch.json will also benefit no folder debugging
  • lets user customize to fine grained details for each no folder debug session
  • variable substition will not work nicely, since things like ${workspaceRoot} are not availalbe in no folder debugging - this can be very confusing to the user
  • might be overly complex in order to just run a simple file (e.g. powershell script)

2. No "launch.json" - implicitly always send the path to the currently opened file to the adapter

A user who gets used to this scenario might be shocked that once he opens a workspace he needs to setup a complex launch.json. This option obviously has the pro of being simple to setup but opens the following questions:

How to choose the correct adapter for a particular file, e.g a hello.ps1 script?

Currently adapter are not contributing in any way the extensions of the files they are interested in except via the breakpoints contribution. Using that contribution for this use case feels a bit hacky. Also what would we do if there are two adapter that contribute the same extension, we can be pragmatic and just take the first

Do we always launch or give a user to choose between launch / attach?

We could do this choice via quick pick but it is painful that the user always has to choose launch every time he wants to simply run his script. Recently we were talking to a team that have a use case of always attaching, so we should also support this imho.

Two options of quick pick not annoying the user:

  • users first choice is remembered for the rest of the vscode session
  • introduce a setting "debug.noWorkspaceRequest" which could by deafault be launch, but could also have attach and pick. Where pick would always ask the user.

Does the adapter require some arguments in the "attach" case?

Can the adapter just always pick the default port or do we need to do the pick process action?

UI state in no folder workspace

All ui state is preserved until vscode is closed. Which means on vscode restart all breakpoints will be lost. IMHO this is fine for the no folder debug scenario as this is our general no folder experience. If you want persistent state open a folder.

@egamma egamma referenced this issue Jan 3, 2017

Closed

January Iteration Plan #17608

56 of 56 tasks complete
@weinand

This comment has been minimized.

Copy link
Member

commented Jan 9, 2017

I don't like option 1 because managing a shared launch.json somewhere on disk sounds complex and it has the problems already identified by @isidorn.

For option 2 I propose a solution that aligns nicely with the theme to open up debugger functionality for extensibility. The basic idea is to optionally route the "debug" or "run" requests to a debugger extension which can modify a launch config in any way needed. In the "Debugging without an open folder" context the extension would have to create a launch config on the fly because none exists in the no-folder mode.

Details:

  • for the debuggers contribution point we introduce a new optional sub-configuration point languages. Here those languages can be listed for which the debug extension could be considered the "default debugger". VS Code makes use of this information only in cases where a debugger must be found automatically for a given file type.

  • for the debuggers contribution point we introduce a sub-configuration point startSessionCommand that takes a command ID. If specified, VS Code will call this command for the "debug" or "run" actions targeted for this extension. If a launch configuration was selected, it is passed as an argument to the command (and the extension can massage the launch config as desired). If "debug" or "run" is executed without an existing launch config, an empty launch config is passed to the "startSessionCommand" and the extension is expected to "fill in" missing attributes based on the file currently open in the editor.

@isidorn isidorn added the on-testplan label Jan 11, 2017

@daviwil

This comment has been minimized.

Copy link
Member

commented Jan 11, 2017

This looks great! I'll give it a try today. Judging from the code changes, it looks like this will also call my startSessionCommand when there is an open folder/workspace, is that correct? If so, that is excellent. This will let me give a much more streamlined debugging experience for PowerShell users both in the no-folder and workspace folder cases.

@daviwil

This comment has been minimized.

Copy link
Member

commented Jan 11, 2017

Ahhh, finally just read Andre's design proposal above. I suppose this means the user will still be prompted to create a launch.json config on first launch in an open workspace. That seems ideal because it will allow the user to save debugger config parameters in their project's launch.json while still allowing the extension to augment their config before launching the debugger. This is really nice!

@isidorn

This comment has been minimized.

Copy link
Contributor

commented Jan 11, 2017

it looks like this will also call my startSessionCommand when there is an open folder/workspace, is that correct?

Yes.

I suppose this means the user will still be prompted to create a launch.json config on first launch in an open workspace

No.
He will be prompted to create a launch.json if he clicks on the configure button or if he is trying to launch a file for which none of the debuggers are interested in.
Get the latest insiders tomorrow try it out and let us know if something does not make sense ;)

@daviwil

This comment has been minimized.

Copy link
Member

commented Jan 11, 2017

That might be even better! I'll hold any further questions until I try it tomorrow :)

@weinand

This comment has been minimized.

Copy link
Member

commented Jan 11, 2017

@daviwil

This comment has been minimized.

Copy link
Member

commented Jan 11, 2017

This is helpful, thanks! And thanks so much for getting this feature implemented, it's going to have a huge impact for the PowerShell extension.

@daviwil

This comment has been minimized.

Copy link
Member

commented Jan 13, 2017

Just tried this out, it's fantastic! It works exactly like I hoped it would both with and without a folder loaded.

One problem though: after I execute the vscode.startDebug command, the debugger client starts up and sends the initialize request to my debug adapter but somehow my initialize response is never received even though I can see from my debug adapter's logs that I've sent it.

This even happens when I take my startSessionCommand registration back out and let VS Code handle starting the debug adapter. When I try my debug adapter with VS Code Stable everything works correctly. Could something in the debug adapter client's protocol have changed recently to cause messages to not be received?

@daviwil

This comment has been minimized.

Copy link
Member

commented Jan 13, 2017

I should mention that to debug the issue I've set breakpoints in vs/workbench/parts/debug/electron-browser/rawDebugSession.ts in the initialize() and readCapabilities() methods. In the latest Insider build I can see initialize() get called but I never see readCapabilities() receive the response object until I wait a while and then stop the debugger. At that point it receives null.

@daviwil

This comment has been minimized.

Copy link
Member

commented Jan 13, 2017

Just thought to check this with the latest official release of the PowerShell extension, version 0.8.0 which came out in mid-December. When starting the debug adapter it hangs on startup in the same way that I described above. Something definitely must have changed in how the debug adapter client communicates with debug adapters, but I'm not quite sure how.

If you want to give this a try, install the PowerShell extension and open the following folder (adjust the path appropriately for OS X if needed):

c:\Users\<your username>\.vscode\extensions\ms-vscode.PowerShell-0.8.0\examples\

Open the DebugTest.ps1 file in that folder and hit F5, you'll see that the debug adapter never fully starts up (no orange status bar).

@weinand

This comment has been minimized.

Copy link
Member

commented Jan 13, 2017

@isidorn David's problem sounds like a regression to me. Can you look into this?

@isidorn

This comment has been minimized.

Copy link
Contributor

commented Jan 13, 2017

Just verified that VScode is sending exactly the same requests as before.
What we introduced recently is a handshake node module between vscode and adapters but this should not effect powershell as your adapter is not sending the 'handshake' request.

I am currently git bisecting to see what commit caused the issue
In order to spot issues like this in the future sooner it would be cool if you guys self hosted on vscode insiders :)

isidorn added a commit that referenced this issue Jan 13, 2017

@isidorn

This comment has been minimized.

Copy link
Contributor

commented Jan 13, 2017

Here's the commit that breaks it - praise git bisect 🙏
140f1ec

Here's the commit that fixes the issue fb838d2

@weinand

This comment has been minimized.

Copy link
Member

commented Jan 13, 2017

@isidorn but your commit does not explain what went wrong with the Map code. I'm using the identical Map code in node-debug and have no issues...

@daviwil

This comment has been minimized.

Copy link
Member

commented Jan 13, 2017

Sorry about that, I'll use Insiders from now on. I had been using it in the past but somehow switched back over to stable.

Just pulled down the latest code after your change, that fixed it! Everything works perfectly now. Thanks a lot Isidor!

@isidorn

This comment has been minimized.

Copy link
Contributor

commented Jan 13, 2017

After closer inspection with @weinand we figured out that the exact issue is that powershell is sending back strings instead of numbers for response.request_seq, so instead of 1 we are getting "1".
@daviwil can you look into fixing this issue on your side so we go back to our proper usage of es5 maps on our side.

@daviwil

This comment has been minimized.

Copy link
Member

commented Jan 13, 2017

Hah! Wow, wouldn't have expected that. Yep, I'll make the change.

@daviwil

This comment has been minimized.

Copy link
Member

commented Jan 13, 2017

I can confirm that changing request_seq to int in my message serializer fixed the issue in the Insider's build.

@isidorn

This comment has been minimized.

Copy link
Contributor

commented Jan 13, 2017

Awesome - we'll go back to using a map

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.