multi debug: productise 'composite' launch config

[weinand]

TBD

related issues:
#14335
#14481
#14486

[isidorn]

I think we should also consider putting 'composites' as an additional section as a sibling to 'configurations' in launch.json. Since doing it the current way we might hit some limitations because required fields for configuraitons are not required for composites and in essence they are different.

I do not plan to work on composites this week so we can also discuss on Monday once I am back in Zh :)

[weinand]

In a ZRH team discussion concerns were raised that 'composite' launch configs have too much overlap with 'tasks' or 'scripts' and that debug should not open the door for this. So we decided not to release our existing implementation but to wait for task support for this.

So this feature is blocked now.

/cc @kieferrm @egamma @dbaeumer

[dbaeumer]

I think task is not the right place to solve this either. I do have similar requests. To make this scripting approach work I think we need the following :

• a scripting interface to VS Code (I have these requests in tasks since people want to talk back to VS Code from their tasks)
• if we want to use the OS scripts engines we need to have executables to talk to VS Code
• we could also say scripting happens in JS. Then we would provide a node module which we automatically inject into the started node engine to allow a script to talk back to VS Code.

[joshgav]

I just set myself up to step debug through Node.js server-side code and browser-side JavaScript from the same VS Code session and smiled in wonderment as a single request hit breakpoints on both sides in succession. I'd like to begin attaching to multiple Node processes at once too so I can follow requests through multiple services. So I was sad to find this no longer works in v1.8, and to discover this issue.

Multi-target takes step debugging to what might be the new normal in our highly-componentized microservices world, where work often traverses process and system boundaries. It would be ideal to focus on the experience specifically for step debugging, independently of Tasks work. Please reconsider including this as a debugging-specific feature. Thanks!

/cc @auchenberg

[weinand]

Multi session debugging is in the product since last milestone (1.7) and it will stay in VS Code.

The only thing that has changed is the UI.

In the October release we had no real UI and the only way to launch multiple sessions was by using a ‘composite launch configuration’.
This was a simple hack that we introduced to surface multi session debugging and make it testable.

In the November milestone we’ve added real UI.
With this a user can launch a new session even if other debug sessions are still running.
As soon as a second session starts the UI changes and shows multiple sessions in the CALL STACK view and the debug action bar:

This multi session UI will ship in November (and it is already available in the Insiders release).

The 'composite' launch config is considered a secondary UI and it will be made available in the November release after some polish.

The following example shows the proposed syntax:

"compounds": [
    {
        "name": "Node+Browser",
        "configurations": [ "Server", "Browser" ]
    }
],
"configurations" [
    {
        "name": "Browser",
        "type": "chrome",
        //...
    },
    {
        "name": "Server",
        "type": "node",
        //...
    }
]

[joshgav]

Thanks for the clarification @weinand! And thanks for this great feature!

[auchenberg]

Great. I've hereby updated my blog post with the new launch config. https://medium.com/@auchenberg/introducing-simultaneous-nirvana-javascript-debugging-for-node-js-and-chrome-in-vs-code-d898a4011ab1#.bgkqbh54p

[isidorn]

@auchenberg great - thanks!

[weinand]

@auchenberg thanks for updating. Just be aware that the new syntax is only available in the Insiders release. The Stable November release will become available in about two weeks from now.

[auchenberg]

@weinand Good point!

[darkyen]

Say I have my server and client both compiling using webpack in watch mode. In this scenario I'll need two separate tasks (I am compiling typescript to run in a specialized environment with node2 as debugger and chrome for browser). If I do this right now it throws me the error

There is a task server running. Can not run pre launch task client.

Will this be handled gracefully in future?

:Edit:

Further info, I was using attach mode so far, however the problem persists in launch mode aswell. Interestingly though, the node2 does not kill the task it spawned however the chrome debugger does.

[weinand]

@dbaeumer could you please comment on @darkyen's comment #14842 (comment)?

[dbaeumer]

Currently the task framework can only execute one task at the time. Since the watching task takes the slot the prelaunch task can't be started. This is a known limitation. We are working on supporting more than one task to run in parallel.

[darkyen]

Thanks for your reply! I work around the problem to a certain extent by creating 3 npm tasks, 2 standalone and 1 merged. And then 4 launch configs [1 specifically for Server Client] basically two are in launch mode which start the process while 2 are in attach mode and then a final multi target debugger which uses the ones in attach mode that way I can run the tasks almost together. It works as a workaround :)

…

On Jan 9, 2017, at 3:14 PM, Dirk Bäumer ***@***.***> wrote: Currently the task framework can only execute one task at the time. Since the watching task takes the slot the prelaunch task can't be started. This is a known limitation. We are working on supporting more than one task to run in parallel. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14842 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_jo5T6aFLEGEMCdfwnSaHCtFaIXNRAks5rQgFngaJpZM4KnA6z>.

[weinand]

@darkyen great to hear that you were able to work around this limitation.

[DanTup]

@weinand Is there an example anywhere of being able to debug a debug adapter? I've been reading through all these issues, but they mostly seem to be launching multiple processes to debug at once, but since the debug adapter is started later when I hit F5 in my extension, I'm not sure how to get the debugger attached to it (and early enough to actually debug it).

[weinand]

@DanTup just run your debug adapter in server mode from VS Code (if it is a clone of mock-debug there should be a launch config "Server" for this). In another VS Code window add "debugServer": 4711" to you launch config. If you now launch this debug session, VS Code will connect to your debug adapter server. Since your debug adapter runs in server mode, you can easily set breakpoints and hit them without having to restart the debug adapter.

This is explained here: https://code.visualstudio.com/docs/extensions/example-debuggers#_development-setup-for-mock-debug

[DanTup]

@weinand cool; I'll try diffing against that one, I must be missing something (I don't seem to have an option to launch it). Will it still call the start session command and use the info from launch.json in the project loaded in the extension host so my debugger gets the correct config?

[weinand]

If you are using the npm module "vscode-debugadapter" then your debug adapter automatically gets a server mode option --server=4711. In this mode the adapter creates a server socket and uses socket based communication (instead of the stdin/stdout based-communication). In addition the server doesn't shut down between sessions.

Yes, the start session command is supported as well. You should not see a difference here.

[weinand]

BTW, mock-debug has a composite launch config: "Extension + Server". If you use this you can debug you debug extension and you debug adapter simultaneously.

[DanTup]

@weinand Finally got around to trying this, my launch.json for the debug adapter was really old (no server option), but I've updated it and everything works perfectly. Thanks!

[weinand]

@DanTup great to hear!

[hexa00]

I just tried this with vscode Version 1.13.0

And I have the following problem:

Breakpoints are working in my nodejs debug app and when I start a chrome debug session the chrome debug breakpoins work, but the nodejs breakpoints go away.

I get Breakpoints ignored because generated code not found.

Any ideas on what is going on ? is the sourceMap beeing overriden globally with the ones found in chrome ? or ?