Run normally without debug

[TheColorRed]

Is there a command that will run my file without opening the debug console and without opening the debug tab?

[weinand]

@TheColorRed no there is no run command, but I think it is a valid feature request.

@isidorn what do you think?

[isidorn]

@weinand I agree it is a valid feature request. Not sure how to best handle this, adding a 'silent' option in the launch.config?

[egamma]

Could this be covered by a new run action that consumes the information in the existing launch config but doesn't do any debugger attachment logic.

[isidorn]

By debugger attachment logic you mean open the debug console and open the debug viewlet?
Yes it could be covered by a new action. Would we just call it run, or debug: run. If we just call it run it would not be clear that it actually reads the launch.json for the program file and so on..

[weinand]

@egamma sure, but it has to go through the debug adapter (DA) because VS Code doesn't know anything about how to launch a program or that an 'debugger attachment logic' even exists. And the launch/attach config attributes are not part of the debug protocol but are contributed by a debug extension, so VS Code cannot know how to use them in order to 'run' a program.

It is probably a new built-in launch config attribute noDebug. This will trigger VS Code not to start a debug session and prevent the 'debugger attachment' logic in the DA. Some of the other attributes still make sense (e.g. args, runtimeArgs, cwd, externalConsole) but it the responsibity of the DA to decide what to do with them.

Another interesting question is whether VS Code tracks programs started this way. If there is no debug session, there will be no 'Terminate' button. This requires some new terminate UI if the program is run in the internal debug console.

[egamma]

@weinand makes sense, but from a user perspective I would not want to have to edit the launch config when I want to switch from running under the debugger and running without the debugger.

My thinking was that the Run actions passes the noDebug attribute to the DA.

[weinand]

@egamma yes, I was assuming that... Sorry for not making this clear.

[weinand]

@felixfbecker thanks for your great suggestions in #3209

(and sorry that I had to make your newer issue a duplicate of this older one...)

[felixfbecker]

@weinand my bad for not searching enough first ;)

[felixfbecker]

Gonna repost what I said:

In Visual Studio, you can press Ctrl+F5 to launch the application without a debugger attached, which i befinicial for performance reasons. For VS Code this would be very helpful, because you don't always want to actually debug a file or actually cannot because there is no debug adapter extension out there yet. Currently, you have to define a "launch" task, which cannot get a keyboard shortcut. Having "Launch without debugging" would be much more semantically correct.

• Introduce a new action in command palette "Launch without debuggin" with keyboard shortcut Ctrl+F5
• If the currently selected configuration has type set, send the debug adapter a launchRequest with the additional argument debug: false runRequest
• Make the debug setting type optional. If a configuration does not have a type, it can only be launched without debugging:
  • If runtimeExecutable is set, spawn the runtime executable (java, bash, ...) with the runtimeArguments, program and args.
    Otherwise spawn program with args directly (like a .exe or .bat)
  • program should be allowed to drop the file extension (java needs this for example)
  • Put stdout on the debug console and send input on the debug console to stdin
  • If externalConsole is true, run the script in an external console
  • Support preLaunchTask

Examples:

{
  "name": "Run currently open script",
  "runtimeExecutable": "bash",
  "program": "${file}"
}

{
  "name": "Launch",
  "runtimeExecutable": "java",
  "program": "${workspaceRoot}/MyClass",
  "preLaunchTask": "compile"
}

However, I also prefer the idea of having a runRequest instead of my initial idea with launchRequest with debug: false, because adapters that do not implement this simply error instead of behaving unexpectedly.

[weinand]

@felixfbecker one problem with the 'un-typed' approach is that there are no "well known" attributes such as runtimeArguments, program and args. All launch attributes are contributed by different schemas.

So probably we will go with the noDebug attribute approach first. We will add noDebug as a predefined attribute and the UI will pass it automatically if a "Run" action was used.

[felixfbecker]

@weinand I just think for "just running" there should be no debug adapter needed, so it should work even if such an extension doesn't exist (yet).

[weinand]

@felixfbecker for "just running" there are no launch config attributes that we can rely on. So we would have to introduce another task running subsystem with its own set of predefined attributes. But this is something that we want to avoid because a task running subsystem already exists in VS Code and it requires only a little bit of additional work to pimp it up to support the "just running" functionality.

[weinand]

@isidorn I've added 'Run' support to node-debug by introducing a noDebug launch config attribute. So you can now 'run' a program by adding "noDebug": true to the launch config. VS Code will have a debug session while the program is running. This makes it possible to terminate the program. Trying to use 'Pause' or the REPL results in timeouts (which is bogus because there is no connection), but overall 'Run' works.

Now we need a few UI tweaks. My proposal is this:

• We introduce a 'Run' action that is basically the 'Debug: Start' but passes a "noDebug": true when calling the launchRequest (We have to decide whether to disable 'Run' when the debug adapter does not support this).
• The 'Pause' button needs to be disabled in this mode. The 'step' buttons are already correctly disabled because there never will be a stop event.
• The REPL should not be available.

What do you think? Is this feasible?

[isidorn]

@weinand great! Here's my first impression, I can provide more details once I have looked deeper into the code.

1. sounds good. Not sure how to disable this action since we will only know if the debug adapter supports it on the first debug - when we get the capabilites. So I propose a simple solution, it is always enabled, and if the debugger does not support run it just debugs
2. Makes sense
3. REPL is always available, no matter if you are in a session or not. I propose that we just do not open it if the user does a 'Run'

Thoughts?

[weinand]

@isidorn all three make sense for an initial version.
If we want to enable Run only for DAs that support this, we could add a flag to the debbugers extensionpoint. That info would be available without running the DA.
For the REPL I will improve the error message.

[isidorn]

Great, so I will start on it as proposed in the previous comment.
The problem with the flag to the debuggers is that a user can have a Mono debugger which supports run, a node which does not support run. And he has a node workspace. Should we enable the run action now? We would have to look iinside the launch.json for a chosen configuration and enable / disable the action based on the chosen configuration. Which might make sense, but can also be weird for the user.

Would we keep this action only as a global workbench action for starters, or we would surface it in the viewlet. For start, I propose to only have a global workbench action since it does not belong in the debug viewlet, since it is run, not debug.

[felixfbecker]

@weinand @isidorn I think the whole feature only really adds true benefit if

• It can be triggered by a shortcut like Ctrl+F5 instead of having to duplicate essentially the whole debug configuration and then selecting the noDebug config from the select box
• It allows to run scripts without a debug adapter (Java for example)

I actually even thought about creating a debug adapter that doesn't debug but simply runs whatever is thrown at it. I opened the feature request because I thought this should be a core feature rather. If you do not plan to do this, I would go at creating that adapter ;)

[weinand]

@felixfbecker it was never the idea to copy launch configs or to let the user add the 'noDebug' attribute. Just read my proposal from above: there will be a 'Run' action (which of course has a shortcut), that adds the 'noDebug' option into the args passed to launch behind the scene.

Running arbitrary programs (e.g. Java) is (or soon will be) possible with tasks. We are not going to copy this functionality in debug land.

Please feel free to to write an debug adapter that simply runs whatever is thrown at it. ;-)

[weinand]

@isidorn the 'Run' action operates only on the currently selected launch config (like "Debug"). If the adapter doesn't support 'Run', it will fall back to Debug. This is ok for the first version.

If we want to enable 'Run' only for DAs that support Run, we could either use a flag in the DA's package.json or a flag returned from the Initialize request. In the former case we could disable 'Run' early because we have the necessary information when a launch config is selected in the drop down. In the latter case 'Run' would be always enabled but it would aborted as soon as Initialize returns the flag.

[weinand]

@daviwil please file a separate issue for this. Sounds like an interesting use case that we should support in the future.

[daviwil]

Yep, I filed one a long time ago (#547) and it seems another has been filed since then (#1222)

[rkeithhill]

With the March release VS Code will support to 'run' a program

I'm a little confused. Are you referring to the release on "March" 7th or a future release which may or may not happen in March? Maybe it's time to rethink the milestone naming convention. ;-)

[weinand]

@rkeithhill In March we are working on the 'March' release which ideally ships at the end of March (but in practice slips a bit into the next month). So what was released on March 7 was the February release.
In general just use this query to find our release plans with all the details.

[rkeithhill]

@weinand Thanks for the link!

[obskyr]

So... is there still no way to run without a debug adapter? If I'm working on an obscure system (and I am), and my build task is an arbitrary command, shouldn't my run task be able to be one too? I don't want to have to write a debug adapter that does absolutely nothing just to be able to appease the type property in launch.json.

[rkeithhill]

@obskyr For now, you can use a task (tasks.json) to run something without debugging it. I've done this with some Electron development I've been doing. I also mark the task with isTestCommand and then configure a keyboard shortcut to run the workbench.action.tasks.test command.

[isidorn]

More about the tasks framework can be found here https://code.visualstudio.com/docs/editor/tasks

[justin-romano]

Still seems very opinionated towards grunt type tasks

…

On May 29, 2017 10:47 PM, "Isidor Nikolic" ***@***.***> wrote: More about the tasks framework can be found here https://code.visualstudio.com/docs/editor/tasks — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2780 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABoM2hG6zmjCZ0VX70SQWHdDW5GA8YeNks5r-qJagaJpZM4HVLo4> .

[weinand]

@justin-romano why do you think that tasks are opinionated towards grunt?

The doc says: "... can be a task runner like gulp or grunt or any command line tool like a compiler or linter" and grunt always shows up together with gulp and jake.

[justin-romano]

Just the way it has the tasks list. Not all tools use parameters the same way.

…

On May 30, 2017 10:14 AM, "Andre Weinand" ***@***.***> wrote: @justin-romano <https://github.com/justin-romano> why do you think that tasks are opinionated towards grunt? The doc says: "... can be a task runner like gulp or grunt or any command line tool like a compiler or linter" and grunt always shows up together with gulp and jake. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2780 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABoM2kQkqN9uvRVCKa8fE4IGABc3_tCvks5r-0NegaJpZM4HVLo4> .

[weinand]

@dbaeumer I do not understand @justin-romano's concern. But may be you can chime in...

[dbaeumer]

@justin-romano can you make an example. And please note that 1.13 will ship with a new task runner that executes the task in the terminal plus a Task API to allow extensions to easier customize and contribute tasks.

[justin-romano]

Several things.

1. would be nice to have tasks and subtasks assignable to and keyboard shortcut of your choice.
   maybe like "shortcut":"Ctrl+k, Ctrl+p"
2. The below task is me trying to get a sync task working so that when i build it syncs the code to a remote embedded machine (like a raspberry pi)
   because the task name is actually passed as the first parameter with no way to.
   see "taskName": "-pw" actually an arbitrary parameter in the case password.

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "name": "SYNC",
    "version": "0.1.0",
    "command": "c:\\windows\\sysnative\\pscp.exe",
    "isShellCommand": false,
    "echoCommand": true,
    "tasks": [
        {
            "taskName": "-pw",
            "args": [
                "a_password_for_sftp",
                "root@192.168.20.51:/root/src/WiringOP-Zero/examples/${fileBasenameNoExtension}",
                "${fileDirname}\\${fileBasenameNoExtension}"
            ],
            "isBuildCommand": false,
            "problemMatcher": "$tsc"
        }
    ],
    "showOutput": "always"
}

But it may have changed since i last looked.

[dbaeumer]

Two things:

• in the output runner (version 0.1.0) you can use suppressTaskName to avoid passing the task name as an arg.
• you can assign keyboard short cuts. See https://code.visualstudio.com/docs/editor/tasks#_binding-keyboard-shortcuts-to-tasks

[HorstBaerbel]

Could you add the information to the VSCode C++ docs and maybe post a complete tasks.json / launch.json example here? I've read a couple of issues now and can't quite make launching work...
I use make to build my projects. I put

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch",
            "runtimeExecutable": "MYEXECUTABLE",
            "program": "${workspaceRoot}/MYOUTPUT.FILE",
            "preLaunchTask": "Make"
            }
    ]
}

into launch.json. My tasks.json looks like this:

{
    "version": "2.0.0",
    "tasks": [
        {
            "taskName": "Make",
            "type": "shell",
            "command": "make",
            "args": [""],
            "group": "build",
            "presentation": {
                "reveal": "always",
                "panel": "dedicated"
            },
            "problemMatcher": {
                "owner": "cpp",
                "fileLocation": ["relative", "${workspaceRoot}"],
                "pattern": {
                    "regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
                    "file": 1,
                    "line": 2,
                    "column": 3,
                    "severity": 4,
                    "message": 5
                }
            }
        }
    ]
}

The binary file is built sucessfully via CTRL+SHIFT+B, but when launching via CTRL+F5 I get the message "No executable targets are available". I guess vscode does not know what output file make generates...

[dbaeumer]

@HorstBaerbel can you start the discussion here please: https://github.com/Microsoft/vscode-cpptools

It is the repository for the cpp tools and I know that they even have a problem matcher contribution now. So no need to inline one in the tasks.json.

[HorstBaerbel]

Thanks. Will do.