Because of the enormous compilation time on my personal laptop, I decide to compile the .c code on a remote, much more powerful server. So I clone the project repository on the server and compile the target with a makefile, as I would do on my computer.
I send the .elf file back to my laptop and when I try to run debugging on Vscode, a main.cdasm file opens instead of the file I expected to see. The code works as expected, it's just the display on Vscode that is wrong.
Result expected :Debugging result when compiling on my laptop.
Result obtained :
Debugging result screen when compiling remotely
I guess there is a configuration on Vscode to change the location of the debugging entry point. Or maybe, there is a compiler option to change the default location of the .elf and start debugging in the right location.
A part of my json configuration :
"type": "cortex-debug",
"request": "launch",
"name": "LE00 | RAM", //name of the configuration
"cwd": "${workspaceRoot}",
"executable": "${input:elfFile}",
"servertype": "jlink",
"device": "ATSAML10E16A", //name of the device (need to be referenced by JLINK)
"interface": "swd",
"serverArgs": [
"-vd", //Verify after downloading
],
Can someone help me to configure the debugging console when the .elf (and thus the compilation) is done remotely?
In advance, thank you
Related
I have a VS Code project based on a CMakeLists.txt file, and using the CMakeTools extension I can successfully build the target executable.
However, I need to run the executable in a different directory to the build directory. I cannot find a setting to either:
The built executable is placed in a different directory to the build directory and then run from there
The build executable is run from a different working directory
How can I achieve my goal?
You can change the output directory for the executable using the RUNTIME_OUTPUT_DIRECTORY property. When debugging, the executable is run in that directory. For example:
set_target_properties(my_target
PROPERTIES
RUNTIME_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}/bin"
)
If you only want to change the current working directory (cwd), you can create your custom .vscode/launch.json. The content may depend on your OS and compiler:
{
"version": "0.2.0",
"configurations": [
{
"name": "Run CMake Target",
"type": "cppvsdbg", // use cppdbg on linux
"request": "launch",
"program": "${command:cmake.launchTargetPath}",
"cwd": "${workspaceFolder}/bin"
}
]
}
I'm trying to disable certain pylint warnings from VS Code, but nothing I do seems to work. I have put the same settings in all 3 of the possible places (User, Remote, Workspace), but the command line shown in the pylint output window doesn't reflect it. I've tried restarting, disable/enabling the extension. I am using Remote Explorer from my Window VSCode to a Linux server. I've got almost everything else working, including remote debug. I'm running python from a Virtual Environment. But I can't surpress pylint errors/warnings. Here is the setting I am trying:
"python.linting.pylintArgs": [
"--disable=C0103,C0303"
],
and this is what the pylint window shows:
/home/mlakata/e2e_ve/bin/python -m pylint --reports=n --output-format=json --from-stdin /home/mlakata/file1/file1.py
CWD Linter: /home/mlakata
file:///home/mlakata/File1/File1.py :
[
{
"type": "convention",
"module": "File1",
"obj": "",
"line": 19,
"column": 47,
"endLine": null,
"endColumn": null,
"path": "File1/File1.py",
"symbol": "trailing-whitespace",
"message": "Trailing whitespace",
"message-id": "C0303"
},
... several hundred more warnings ...
Pylint behaves rather unintuitively about where it takes its config from.
Two things are key to keep in mind:
IDEs often run pylint from a sub-directory (namely, from the directory directly containing the python file to be linted).
If pylint is being run from a sub-directory, this often changes which config file is being used, because pylint uses a weird order of priority (as stated here).
As a result, I would say there are three main gotchas:
Gotcha 1: pyproject.toml or setup.cfg don't get respected at all when running pylint from a sub-directory.
Gotcha 2: On the other hand, a pylintrc or .pylintrc in an upper directory will get respected, if the current working directory is a python package.
Gotcha 3: Some long-forgotten pylintrc or .pylintrc file lying around in your user's home or configuration directories might be running the show without your knowing.
To solve any issue similar to yours, it can be very helpful to run pylint with the --verbose flag, because then it tells you where it takes its config from.
I'm struggling with setting up environment for old tech project with PHP5.
My OS is Windows and I have installed so far VSCode plugins: PHP Debug, PHP Intelephense, PHPUnit, PHPUnit Test Explorer.
I downloaded phpunit-5.7.27.phar and configured VSCode according to documentation.
Settings.json
{
"php.validate.executablePath": "C:/wamp64/bin/php/php5.6.40/php.exe",
"phpunit.phpunit": "C:/wamp64/bin/php/php5.6.40/phpunit-5.7.27.phar",
"phpunit.php": "C:/wamp64/bin/php/php5.6.40/php.exe",
"intelephense.environment.phpVersion": "5.6.40",
"intelephense.environment.includePaths": [
"C:/wamp64/bin/php/php5.6.40/phpunit-5.7.27.phar",
"C:/wamp64/bin/php/php5.6.40/php.exe",
"C:/wamp64/bin/php/php5.6.40/"
]
}
Launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "Listen for XDebug",
"type": "php",
"request": "launch",
"port": 9000,
"xdebugSettings": {
"max_children": 256,
"max_data": 500,
"max_depth": 3
}
},
]
}
What works for me fine is breakpointing on running app with xdebug and running unittests with Cmd+Shift+P.
What I need help with are as follows:
Code editor shows error for PHP unit classes and methods (even though unittests are executing fine as is). Do I need to add to path something besides phar file? Is VSCode non-compatible with phar files? The same happens for PHPUnit\Framework\TestCase.
I can't figure out how to configure Test Explorer plugin to show nicely tests tree. Does it require some configuration in Launch.json? Launching tests with Cmd+Shift+P displays results only in terminal.
PHP Intelephense requires installed PHPUnit with composer in workspace.
composer require --dev phpunit/phpunit
PHPUnit Test Explorer has by default Phpunit: Files setting set to {test,tests}/**/*Test.php, so changing it to proper glob should allow plugin to detect all tests.
I try to set up a launch.json for a vagrant-plugin on windows. My current version look like this:
{
"version": "0.2.0",
"configurations": [
{
"name": "Launch Vagrant",
"type": "Ruby",
"request": "launch",
"cwd": "${workspaceRoot}",
"program": "${workspaceRoot}/bin/vagrant",
"args": ["up"],
"env": {
"VAGRANT_CWD": "${workspaceRoot}/development"
}
}
]
}
When starting the plugin now, vagrant misses the external dependencies. So I get the error:
The executable 'curl' Vagrant is trying to run was not
found in the %PATH% variable. This is an error. Please verify
this software is installed and on the path.
Adding the needed dependencies to my path sound like trouble (cp.exe, dir.exe, ...).
I tried:
"env": {
"PATH": "/HashiCorp/Vagrant/embedded/bin;${PATH}",
"VAGRANT_CWD": "${workspaceRoot}/development"
}
But then i get Debugger terminal error: Process failed: spawn rdebug-ide.bat ENOENT.
Is there a way the expend the PATH environment Variable in the launch.json?
For the question of:
Is there a way the expend the PATH environment Variable in the
launch.json?
From the documentation:
You can also reference environment variables through ${env.Name} (e.g.
${env.PATH}). Be sure to match the environment variable name's casing,
for example env.Path on Windows.
At: http://code.visualstudio.com/docs/editor/tasks#_variable-substitution
For example I often use this for Ruby apps in my launch.json in Visual Studio Code:
...
"pathToBundler": "${env.HOME}/.rvm/gems/ruby-2.3.0/wrappers/bundle",
...
#sschoof If you are trying to run VS Code from the windows host machine I'd suggest reading this post.
I've current just started configuring a development workspace for use with nodejs, VS Code, and Azure using my Mac OSX host. My solution is working but I have not a done a windows implementation so I currently cannot offer more experienced advice.
Since Visual Studio Code was created using Electron, I'm guessing that launch.json might be configured to properly launch an app using Electron. But I've not figured out how to do it yet.
Also since Electron is based on io.js, itself based on Node.js, I'm thinking maybe... it can be done, but haven't found the magic yet.
Tried something along these lines... snippet from launch.json:
"configurations": [
{
// Name of configuration; appears in the launch configuration drop down menu.
"name": "Launch Electron",
// Type of configuration. Possible values: "node", "mono".
"type": "node",
// Workspace relative or absolute path to the program.
"program": "Y:\\dev\\electron\\electron.exe",
// Automatically stop program after launch.
"stopOnEntry": false,
// Command line arguments passed to the program.
"args": ["CrawlSpace_Electron\\"],
// Workspace relative or absolute path to the working directory of the program being debugged. Default is the current workspace.
"cwd": ".",
// Workspace relative or absolute path to the runtime executable to be used. Default is the runtime executable on the PATH.
"runtimeExecutable": null,
// Environment variables passed to the program.
"env": { }
},
It does start Electron, but fails (window vanishes too fast to see exactly why).
Any thoughts?
If you specify electron.exe as the runtimeExecutable (as previously suggested) you can pass the main.js file as the program and it will work. Electron allows you to specify the directory OR the main.js file since that is pretty much what the package.json points to. Using the configuration below in my launch.json file, pressing F5 both launched Electron with my app and connected the debugger to the main process (eventually)...
{
"name": "Launch Electron",
"type": "node",
"program": "${workspaceRoot}/app/main.js", // ensure this is path to main.js file
"stopOnEntry": false,
"args": [],
"cwd": "${workspaceRoot}",
// as you have noted, this is also important:
"runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron.cmd"
},
My main.js file is in the app folder I normally would pass to Electron.
Yes, it could. Not only could VSCode launch Electron, it could also debug it.
Using node you can debug Electron's Main process, but with Debugger for Chrome you can also debug Electron's Renderer process. I wrote a blog post on this topic: http://code.matsu.io/1.
The current highest upvoted answer is a bit outdated.
You should use electron instead of electron-prebuilt. See http://electron.atom.io/blog/2016/08/16/npm-install-electron
You should use node_modules/.bin/electron to launch electron
On Windows it's electron.cmd, not electron.exe.
Here are two pre-configured projects: https://github.com/octref/vscode-electron-debug.
One configured to run electron/electron-quick-start
One modified from electron/electron-quick-start to use ES6 & Babel & Webpack.
Here is the launch.json for the first project. To run the target "Debug Renderer Process", you need to install Debugger for Chrome. But "Debug Main Process" works fine on vanilla VSCode.
{
"version": "0.2.0",
"configurations": [
{
"name": "Debug Main Process",
"type": "node",
"request": "launch",
"cwd": "${workspaceRoot}",
"runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron",
// Use the following for Windows
// "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron.cmd",
"program": "${workspaceRoot}/main.js"
},
{
"name": "Debug Renderer Process",
"type": "chrome",
"request": "launch",
"runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron",
// Use the following for Windows
// "runtimeExecutable": "${workspaceRoot}/node_modules/.bin/electron.cmd",
"runtimeArgs": [
"${workspaceRoot}/main.js",
"--remote-debugging-port=9222"
],
"webRoot": "${workspaceRoot}"
}
]
}
In theory the following should work:
Specify the electron.exe as the "runtimeExecutable" (since it replaces the node runtime). The electron program ("CrawlSpace_Electron\") becomes the "program". VSCode automatically passes a "--debug-brk" or "--debug" to electron.exe.
In practice VSCode does not yet support this setup because the preview version of VSCode tries to verify that the "program" attribute is a file that exists on disk. But for electron the "program" must be a directory.
I have created a bug on our side and will make sure it’s fixed with the next release.
I know this is just 1 link but it's the answer everyone needs...
https://code.visualstudio.com/docs/editor/debugging#_launchjson-attributes
Here are the attributes documented for launch.json. Unsure if the list is currently complete, but it should at least help...
On OSX the path to electron is
"runtimeExecutable": "${workspaceRoot}/node_modules/electron-prebuilt/dist/Electron.app/Contents/MacOS/Electron",