Im using a virtual environment for my python project and I'd like to configure commands to automatize debugging.
So far, I've changed the python.pythonPath in launch.json and my intention is to update all dependencies before building with a custom task, which structure follows like
{
"version": "2.0.0",
"tasks": [{
"label": "echotest",
"command": "python ...", // Could be any other shell command
"args": ["test"],
"type": "shell"
}]
}
So, my question is if there is any way of using the pythonPath variable defined in launch.json inside the command key
My question is answered here in case it helps anyone. My final tasks.json is
{
"version": "2.0.0",
"tasks": [{
"label": "update dependencies",
"command": "${workspaceFolder}\\${config:python.pythonPath} -m pip -r ${workspaceFolder}\\requirements.txt",
"args": [],
"type": "shell"
}]
}
Care with blank spaces in folder names since scaping them with \"doesn't work at all
Related
I am a complete beginner with C and to VSCode. I am trying to configure the task and launch jsons but have no idea where to begin. I have tried googling the answers but I keep getting the same errors. I want to be able to step through the code line by line so I can see what it is doing.
I haven't changed the tasks.json from the original that VSCode sets. The launch.json I have changed by putting in the debugger path and the path of the executable. I have included the task.json, launch.json and the error that keeps popping up. Any help is appreciated.
tasks.json
"tasks": [
{
"type": "cppbuild",
"label": "C/C++: gcc build active file",
"command": "/usr/bin/gcc",
"args": [
"-fdiagnostics-color=always",
"-g",
"${file}",
"-o",
"${fileDirname}/${fileBasenameNoExtension}"
],
"options": {
"cwd": "${fileDirname}"
},
"problemMatcher": [
"$gcc"
],
"group": {
"kind": "build",
"isDefault": true
},
"detail": "Task generated by Debugger."
}
],
"version": "2.0.0"
}
launch.json
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/scheduler.c",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceRoot}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"miDebuggerPath": "/usr/bin/gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
},
{
"description": "Set Disassembly Flavor to Intel",
"text": "-gdb-set disassembly-flavor intel",
"ignoreFailures": true
}
]
}
]
}
I've recently had the same issues. Here is the procedure that I follow, that seem to work:
Download and install msys2 (1)
Download MSYS2 from https://www.msys2.org/
Install folder is typically C:\msys64
Go to C:\msys64 and open mingw64.ini
Change ‘#MSYS2_PATH_TYPE=inherit’ to ‘MSYS2_PATH_TYPE=inherit’ i.e. enable PATH variable.
Add PATH environment variables (2)
Type “environment” in Windows search field, and select “Edit environment variables …”
Add path to gcc.exe and g++.exe:
— Add: “C:\msys64\mingw64\bin” to PATH variable.
Add path to VS Code to PATH variable as well:
— This is usually the folder:
C:\Users\<username>\AppData\Local\Programs\Microsoft VS Code\
Run “msys2 mingw64” and test access to compilers and debugger (3)
In Windows Search field, type “msys2” and select “msys2 mingw64” and run the following:
To install gcc, the Gnu C compiler: pacman -S mingw-w64-ucrt-x86_64-gcc
To install gdb, the Gnu GDB debugger:
pacman -S --needed base-devel mingw-w64-x86_64-toolchain
To test that you can run compilers and debugger, run:
gcc --version
g++ --version
gdb --version
Start development in VSC (4)
Open “msys mingw64” terminal and run:
cd <common projects folder>
mkdir <projname>
cd <projname>
Above changes current directory to a projects folder. I use C:\Users<username>\src\projects, i.e. this is my but you may want to use something else.
In the folder you can make a subfolder per C coding project you want to run. This is what “mkdir ” does.
You will need a little Unix Bash shell command skills here, here is an ultrashort summary:
cd – change directory to
mkdir – makes a new directory called
in the current folder.
cd .. – change directory one up.
_ cd ~ – changes directory to your home folder, I have C:\Users<username> where is my … username.
pwd – shows current directory.
Now, if you did above you are currently in the specific projects folder (you can verify this with pwd), and you should start VSC from there by typing:
code .
And accept Workspace trust.
Create a C source file (5)
Open folder view, click on + icon, and select ‘new file’, type “hello.c”, go into the file and add the contents:
include
int main() {
printf("Hello World\n");
return 0;
}
Configure VSC for building – tasks.json (6)
Press “ctrl+shift+B” to build target (or menu: -> Terminal -> Run Build Task… or press green play icon)
Select “C/C++: gcc.exe build and debug active file”
Now it tries to build, using an autogenerated tasks.json file, located in project-folder, in subfolder .vscode:
.vscode/tasks.json
An example of a tasks.json file is shown below:
"tasks": [
{
"type": "cppbuild",
"label": "C/C++: gcc.exe build active file",
"command": "C:\apps\msys64\mingw64\bin\gcc.exe",
"args": [
"-fdiagnostics-color=always",
"-Wall",
"-g",
"${file}",
"-o",
"${fileDirname}\${fileBasenameNoExtension}.exe"
],
"options": {
"cwd": "${fileDirname}"
},
"problemMatcher": [
"$gcc"
],
"group": {
"kind": "build",
"isDefault": true
},
"detail": "Task generated by Debugger."
}
],
"version": "2.0.0"
}
The important section is:
"command": "C:\msys64\mingw64\bin\gcc.exe",
"args": [
"-fdiagnostics-color=always",
"-Wall",
"-g",
"${workspaceFolder}/*.c", OR TODO "${file}"
"-o",
"${fileDirname}\${fileBasenameNoExtension}.exe"
],
“command” is the Gnu C compiler, gcc.exe and the full path to it.
“args” are arguments for the compiler:
-Wall means warn about everyting.
-g means compiler must prepare for debugging.
“${file}” is current file.
-o is output file which is specified in the next line with .exe extension.
Sometimes we have to build multi-file projects and it will break the default build-functionality in tasks.json in VSC. In some cases this can be solved by changing:
${file},
to
"${workspaceFolder}/*.c",
Configure VSC for Debugging – launch.json (7)
Go to source file hello.c, and set a break point,
Click left to the line numbers to set red circle.
Select play/bug icon
Select “Debug C/C++ File”
Choose “C/C++ gcc build and debug active file” from list of automatically detected compilers.
This will autogenerate a file, launch.json in the projects folder, in subfolder .vscode:
.vscode/launch.json
An example of a launch.json file is shown below:
{
"configurations": [
{
"name": "C/C++: gcc.exe build and debug active file",
"type": "cppdbg",
"request": "launch",
"program": "${fileDirname}\${fileBasenameNoExtension}.exe",
"args": [],
"stopAtEntry": false,
"cwd": "${fileDirname}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"miDebuggerPath": "C:\\msys64\\mingw64\\bin\\gdb.exe",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
},
]
}
],
"preLaunchTask": "C/C++: gcc.exe build active file"
}
The most important parts are:
"program": "${fileDirname}\${fileBasenameNoExtension}.exe",
and
"miDebuggerPath": "C:\\msys64\\mingw64\\bin\\gdb.exe",
The “program” is the program generated when building the project. I.e. the output from running the task as specified in Tasks.json.
The miDebuggerPath is the path to gdb, the GNU gdb debugger.
If these does not match with your Tasks.json settings and your installation chances are slim to make it work.
Test it by pressing the Play/Bug icon button and notice if there are errors. If not you should be able to step through the code and watch variables etc.
Configure VSC for intellisense (8)
Install extension: “C/C++ extension for VS Code” by Microsoft.
Now this extension will assist when you type code. By example you can type for to get the basics of a for-loop. Similar for if, while etc. Cool!
Save work when creating new projects (9)
Instead of having to create the tasks.json and launch.json files for each project, I copy them to a templates folder, say:
C:\Users\username\src\templates\.vscode\
Copy the newly created tasks.json and launch.json files to the .vscode subfolder.
Now, say you want to create a new project, e.g. hello2, and you create a folder for it:
C:\Users\<username>\src\projects\hello2\
Go to the templates folder by
cd C:\Users<username>\src\templates
and copy the .json files to the new project by:
cp -Rp .vscode/ ../hello2/
And now the new project has the .json files.
Optional (10)
Later you may want to update msys2. To do this, open “msys2 mingw64” and type
pacman -Suy
Done (11)
Finally done … Not the easiest thing to get going, but I still think it is worth it.
I want to set up VScode (OS: Windows 10) to create and then compile programs written in Fortran 90/95. I can do this by typing in the terminal : gfortran -o Example_exe Example.f90 and then ./Example_exe. I don't want to have to write these lines every time, so I tried to set up my tasks.json file to automate a build routine using gfortran as compiler.
I found this tutorial : https://titanwolf.org/Network/Articles/Article?AID=360e0bde-0507-4de4-960c-2eae8fa8c782#gsc.tab=0 but the tasks.json file given is unclear.
Can I have a tasks.json file setup to automate my build routine please ?
I have installed the following extensions : Modern Fortran, Fortran IntelliSense, Code Runner, Fortran Breakpoint Support
Yes you can. Assuming that you want to execute in debug mode, you should create a tasks.json and a launcher.json and place them in .vscode/ at the root of your workspace.
Assuming the following file structure and a debugging mode with GDB for the execution:
root/
.vscode/
code/
Example_exe
This is what your tasks.json should look like:
{
"version": "2.0.0",
"tasks": [
{
"label": "compile",
"type": "shell",
"command": "gfortran -o Example_exe Example.f90 -g",
"options": {
"cwd": "code/"
}
}
]
}
And then, the launch.json, which will identify tasks.json as a "preLaunchTask".
{
"version": "0.2.0",
"configurations":[
{
"name": "Run my example",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}\\code\\example_exe.exe",
"args": ["],
"stopAtEntry": false,
"cwd": "${workspaceFolder}\\code",
"miDebuggerPath": "gdb.exe",
"preLaunchTask": "compile",
}
]
}
Launch the debugger by pressing F5 (or in the Run menu).
If you don't want to run in debug mode, have a look at this issue.
Sources:
How to build and run C++ code in Visual Studio Code?
awesome tutorial (for ubuntu, working for me with VSCode-gfortran-Win10)
https://www.youtube.com/watch?v=Rj-kYb9nZ3g&ab_channel=LukasLamm.
I'm new to using VSCode and also I'm learning Prolog so I want to know how to run it from the editor.
I'm on windows and I already activated the enviroment variable LINEDIT=gui=no so when I call C:\GNU-Prolog\bin\gprolog.exe it runs on the shell.
to open a file you have to run in the prolog terminal:
changedirectory(DirectoryPathName). to go to the file's directory and
[file] to open it.
I don't know how to translate that into the VSC settings so I can use it to run Prolog.
Any help is appreciated!
Something like defining a task in your tasks.json file. For version 1.5.0 of VSC:
{
"version": "1.5.0",
"tasks": [{
"label": "my echo test",
"command": "echo", // Could be any other cmd
"args": ["test"],
"type": "shell"
}]
}
I would like to know if there is a way to define a default Build Task for VSCode depending on file extension.
When working in some folder of Python code, I define the following Build Task:
{
"version": "0.1.0",
"command": "python",
"isShellCommand": true,
"showOutput": "always",
"args": ["${file}"]
}
Then if next time I go to another Python folder, I have to redefine it again.
Is it possible to configure VSCode in such a way that if it detects the current file as a Python script, then it will automatically define the above Build Task?
Thank you in advance for your help!
Update for latest vscode
The following will create a default "build" script, so you can use the keyboard shortcut to build your project. (Below for a javascript project, but shows general outline for other languages/projects.)
(1) Assuming you have a script named "build.js" at the root of your project.
(2) Create a file named "tasks.json" in root of project (workspace) with the following contents:
// tasks.json
{
"version": "2.0.0",
"tasks": [
{
"type": "npm",
"script": "mybuildscript", // use same name as in package.json
"group": {
"kind": "build",
"isDefault": true
}
}
]
}
(3) In your package.json, add "scripts" as:
// package.json
{
"name": "my",
"version": "1.0.0",
"description": "",
"scripts": {
"mybuildscript": "node ./build.js"
},
"dependencies": {
"myfs": "^1.0.22"
}
}
I created a rudimentary vscode extension that does all this for you:
https://marketplace.visualstudio.com/items?itemName=gieson.make-build-task
The extension isn't perfect (doesn't cover all the possible ways a project/workspace can be configured), but it's a good starting point.
Here's the repo:
https://github.com/bobtherobot/make-build-task
This is possible, but it requires writing an extension (unless somebody has already written one with a tasks provider for Python). Since 1.14.0, there's a new API which allows extensions to dynamically provide tasks. Check out the Task Provider Example.
Alternatiely, the Code Runner extension probably does the trick in this case as well. It doesn't use the Tasks system though.
I have started a few unmodified projects using dotnet new -t web. I have tried to restore using VS Code v 1.8.1 and dotnet restore. From the tutorials I have followed on dot.net and mva.microsoft.com there shouldn't be any difference in the projects at that point. I think that's right and I have not modified the project in question. When I run the same fresh project in the same browser using dotnet run then open a browser the left side of the image is the result as expected. When I try to run using F5 or pressing the run button on VS Code then the right side of the image is the result. All the practice I have had watching Elmo with my daughter has helped me come to the conclusion that one of these things is not like the other.
The proximate cause is that VS Code runs the site without a valid reference to necessary resources like the Bootstrap CSS file. Incorrectly, VS Code references Bootstrap at http://localhost:5000/lib/bootstrap/dist/css/bootstrap.css, while running the project with dotnet run is more fruitful and uses the following external URL: https://ajax.aspnetcdn.com/ajax/bootstrap/3.3.6/css/bootstrap.min.css. Is this a bug that will be fixed eventually and is there some documentation that would help fix this?
From the looks of the .vscode folder and the comment so far, the tasks.json file seems to be a key difference. Here is the file content:
{
"version": "0.1.0",
"command": "dotnet",
"isShellCommand": true,
"args": [],
"tasks": [
{
"taskName": "build",
"args": [
"${workspaceRoot}\\project.json"
],
"isBuildCommand": true,
"problemMatcher": "$msCompile"
}
]
}
Here is the launch.json file:
{
"version": "0.2.0",
"configurations": [
{
"name": ".NET Core Launch (web)",
"type": "coreclr",
"request": "launch",
"preLaunchTask": "build",
"program": "${workspaceRoot}\\bin\\Debug\\netcoreapp1.0\\Avalon.dll",
"args": [],
"cwd": "${workspaceRoot}",
"stopAtEntry": false,
"internalConsoleOptions": "openOnSessionStart",
"launchBrowser": {
"enabled": true,
"args": "${auto-detect-url}",
"windows": {
"command": "cmd.exe",
"args": "/C start ${auto-detect-url}"
},
"osx": {
"command": "open"
},
"linux": {
"command": "xdg-open"
}
},
"env": {
"ASPNETCORE_ENVIRONMENT": "Development"
},
"sourceFileMap": {
"/Views": "${workspaceRoot}/Views"
}
},
{
"name": ".NET Core Attach",
"type": "coreclr",
"request": "attach",
"processId": "${command.pickProcess}"
}
]
I did have the same issue.
The workaround is as follows:
Either run:
bower install
For this you need to install nodejs and git
Install Node.js from https://nodejs.org/
Install git from https://git-scm.com/
npm install -g bower
bower install
Or open _Layout.cshtml, and change line 9 to:
<link rel="stylesheet" href="https://ajax.aspnetcdn.com/ajax/bootstrap/3.3.6/css/bootstrap.css" />
Please have a look at the deeper explanation to this problem explained here:
https://github.com/dotnet/cli/issues/4076
Regards,
Thomas