Debugging without an open folder #285

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

Projects

None yet

8 participants

@shashankt1989

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

@isidorn isidorn was assigned by weinand Nov 19, 2015
@isidorn
Contributor
isidorn commented Nov 20, 2015 edited

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

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
Contributor
isidorn commented Nov 20, 2015

Let's keep it open for now then

@isidorn isidorn was unassigned by egamma Nov 23, 2015
@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

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

@davehope

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
Member
daviwil commented Dec 6, 2016 edited

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
Contributor
isidorn commented Dec 6, 2016 edited

@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
Member
daviwil 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

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 milestone: January 2017, Backlog Dec 23, 2016
@isidorn
Contributor
isidorn commented Dec 23, 2016 edited

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.

@weinand
Member
weinand commented Jan 9, 2017 edited

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 a commit that closed this issue Jan 11, 2017
@isidorn isidorn debug: no folder debugging
fixes #285
929a29e
@isidorn isidorn closed this in 929a29e Jan 11, 2017
@isidorn
Contributor
isidorn commented Jan 11, 2017

We have an initial version of this working in the vscode insider builds. Since this is still work in progress the exact semantics might change.

@daviwil @rkeithhill you might want to try updating your powershell debug extension in order to support this. As explained above in greater detail your adapter needs to:

  • contribute "languages" - example
  • contribute a "startSessionCommand" - example
  • implement your start session command which will handle the no workspace case. Example
@isidorn isidorn referenced this issue Jan 11, 2017
Closed

Test: debug with no launch.json #18397

3 of 3 tasks complete
@isidorn isidorn added the on-testplan label Jan 11, 2017
@daviwil
Member
daviwil 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
Member
daviwil 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
Contributor
isidorn 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
Member
daviwil commented Jan 11, 2017

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

@daviwil
Member
daviwil 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.

@davidanthoff davidanthoff referenced this issue in JuliaEditorSupport/julia-vscode Jan 11, 2017
Open

Run a whole file #101

@daviwil
Member
daviwil commented Jan 13, 2017 edited

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
Member
daviwil 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
Member
daviwil 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
Member
weinand commented Jan 13, 2017

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

@isidorn
Contributor
isidorn 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 isidorn added a commit that referenced this issue Jan 13, 2017
@isidorn isidorn do not use map for pending requests fb838d2
@isidorn
Contributor
isidorn 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
Member
weinand 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
Member
daviwil 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
Contributor
isidorn 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
Member
daviwil commented Jan 13, 2017

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

@daviwil
Member
daviwil commented Jan 13, 2017 edited

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

@isidorn
Contributor
isidorn commented Jan 13, 2017

Awesome - we'll go back to using a map

@jchadwick jchadwick added a commit to jchadwick/vscode that referenced this issue Jan 14, 2017
@isidorn @jchadwick isidorn + jchadwick do not use map for pending requests a9f3f32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment