I was working in one VS Code window which had the mapping package in OtherProject. Given that I didn't understand what was going on there, I decided to create another directory in another window and create some toy/test code to experiment with. The relative file structure is.
- GoPractice
- osTest.go
- assignments.go
- OtherProject
- src
- main
- mapping.go
To continue with probing and trying to understand in OtherProject, I tried to use dlv debug. I couldn't build because I kept getting an error so I decided to start small with files in my GoPractice directory and searched for tutorials and landed on Digital Ocean's. I created a launch.json file but when I launched the debugger, I got this error that refers to mapping that isn't related to the directory I have.
found packages main (assignments.go) and osTest (osTest.go) in C:\Users\User\Documents\GoPractice
strconv.go:6:2: cannot find package "mapping" in any of:
C:\Program Files\Go\src\mapping (from $GOROOT)
C:\Users\User\go\src\mapping (from $GOPATH) (exit status 1)
Running go env in the window of:
OtherProject I get:
set GOPATH=C:/Users/User/OtherProject
...
set GOROOT=C:\Program Files\Go
I don't understand why the file paths for GOPATH and GOROOT alternate between UNIX and Windows paths from the same command, go env.
GoPractice I get:
set GOPATH=C:\Users\User\go
...
set GOROOT=C:\Program Files\Go
So mapping isn't coming from GOPATH even though I modified it in the original window. And here lies my confusion, it seems that there is a link to the original window's bash session but I can't tell what it is as my initial hunch of the environment variable is wrong based on go env output.
Here's my launch.json:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "DebugServer",
"type": "go",
"request": "launch",
"mode": "debug",
"program": "${workspaceRoot}",
"dlvFlags": ["--check-go-version=false"]
}
]
}
I am running on Go 1.19.1 and I needed to suppress the warning for dlv
Related
My Setup is the following:
I use a quite big python repository and code with VS Code with the following setup:
Version: 1.66.0 (user setup)
Commit: e18005f0f1b33c29e81d732535d8c0e47cafb0b5
Date: 2022-03-30T05:50:14.623Z
Electron: 17.2.0
Chromium: 98.0.4758.109
Node.js: 16.13.0
V8: 9.8.177.11-electron.0
OS: Windows_NT x64 10.0.19041
Since yesterday the debugger doesn't start anymore. When I start it with the buttons or with F5, the debug toolbar shows up for a second and then it vanishes again. The normal run works perfectly, as well as when I run my file from a terminal.
I didn't really change something that I can remember, only that VS Code did an automatic update on Monday evening.
There is no Terminal output that I can show, since it is not opening a Debugging Console.
I used the debugger always directly from the file that I needed to debug and didn't specify any launch.json files.
What I already tried, is as mentioned using not the Debugger, but the Run command and started the files from a terminal outside of VS Code. Then my code runs as intended. But since I need the debugger for my work, this is not a good solution.
I also went back a few commits to the last step where I know it was working, but this didn't change it at all.
I tried to debug a simple "hello World" python script but there I have the same problem.
I used the automatic add configuration from VS Code and it added the following launch.json file to the .vscode folder in the repo. Together with this file it added a configuration called "Python: Aktuelle Datei" (german for current file). This also didn't help when I'm trying to launch it with this configuration.
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Python: Aktuelle Datei",
"type": "python",
"request": "launch",
"program": "${file}",
"console": "integratedTerminal",
"justMyCode": true
}
]
}
Is there anyone who encountered a similar issue?
I have my main.go in a subfolder cmd/admin/main.go but when I'm debugging and there are errors in a file, it gives me the relative path from the main.go folder instead of the workspace folder. So for example I will have the error ..\..\path\to\file.go:238:3: undefined: test which won't work if I try to Ctrl+click it.
If I launch the command from the root go run cmd/admin/main.go that works as intended returning path\to\file.go:238:3: undefined: test.
My launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "Launch",
"type": "go",
"request": "launch",
"mode": "auto",
"cwd": "${workspaceFolder}",
"program": "${workspaceFolder}/cmd/admin",
"env": {},
"args": []
}
]
}
Go version 1.16.6
VSC version 1.58.2
OS Windows10
Go File > Add Folder to Workspace
Then select the folders containing main.go
You can also do it in the command line:
code cmd/admin -a
Now make sure your current launch.json has been deleted to start fresh, your workspace should look like this:
Notice that there is a 'package main' and 'func main()' this is required for Go to know the entry point.
Now press Run and Debug with a breakpoint:
That's it, it should now work on any folders you add to your workspace. If you want more specific debug options, add them to your workspace and they'll apply in the context of the file you run from. Click the 'create a launch.json file.:
Select workspace:
Select Go: Launch package
You now have a launch config that will apply to the directory you run it from:
Make sure to save your workspace to keep it:
Notes
Be sure to delete your current launch.json files if they already exist anywhere.
Make sure all of your source code is located in GOPATH/src, you can find out where GOPATH is by putting this into a command line:
go env GOPATH
The file doesn't need to be named main.go, but you MUST have a package named main, and a func named main for Go to know the entry point, for each executable, for example influxdb's two cli's: https://github.com/influxdata/influxdb/tree/master/cmd
More info
VS Code workspace debugging:
https://code.visualstudio.com/docs/editor/multi-root-workspaces#_debugging
GOPATH: https://golang.org/doc/gopath_code
Try and make sure:
you have no GOxxx environment variable set (no GO_BASE_PATH, no GOROOT), except for GOPATH set to %USERPROFILE%\go, and %GOPATH%\bin in your %PATH%
you are using Go installed in the default C:\Program Files\Go\ folder
you have set up your project using Go modules, with a go mod init myproject
you have defined a multi-root workspace for your project root folder, compose of only one root: your project. Save that workspace (it will create a <name>.code-workspace JSON file).
See then if the issue persists (and no cwd should be needed in your launch.json)
I have a launch.json like below:
"version": "0.2.0",
"configurations": [
{
"name": "Launch",
"type": "go",
"request": "launch",
"mode": "auto",
"program": "${fileDirname}",
"env": {},
"args": ["server"]
}
]
}
When I launch it using the debug view on VScode it works fine but I need to change the program attribute to relative path of the respective file from my workspace location, strange behaviour is observed, other components in the same package start throwing undefined func error. Probably something goes wrong with current working dir or go module setup.
In order to investigate further, I need to know the command that is generated from this launch.json file. It should be something like go run ...
I have checked the output and debug console, both of them shows nothing about the launch command.
If you know how to see launch command, please help.
You can find the generated command in Visual Studio Code's debug output. When you have started a debug session, open the Debug Console by clicking on the Debug Console icon in the View Bar or by pressing Ctrl + Shift + Y. The debug output will include the generated command line.
I want to use VSCode with WSL for development.
I have problems debugging my Go applications and I don't know why. I dont see the things in the call stack, no variables and also the buttons to jumping from breakpoint to breakpoint are greyed out. My DEBUG Console log is clean, no erros (see details below) I try to follow these articles to set up my environment:
https://github.com/Microsoft/vscode-go/wiki/GOPATH-in-the-VS-Code-Go-extension
https://github.com/Microsoft/vscode-go/wiki/Debugging-Go-code-using-VS-Code
So what I do in detail:
First I tell VSCode to set my GOPATH dynamacly from the current Workspace and also seperate the GooTools Installation from my GOPATH via go.toolsGopath. My settings.json looks like this:
{
"go.inferGopath": true,
"go.toolsGopath": "/mnt/c/Users/cloudnaut/gospace/gotools",
}
So my GoTools are installed to /mnt/c/Users/cloudnaut/gospace/gotools. I have installed also the dlv debugger. Also My working directory for go is instead /mnt/c/Users/cloudnaut/gospace/go
It haves the common go project structure:
.
├── bin
├── pkg
└── src
└── github.com
└── cloudnaut
└── project1
└── main.go
Everything seems fine. Go:Install/Update Tools are installed in my separate path. And my GOPATH structure also works. I use GO:Current GOPATH it shows my the correct GOPATH i want and go install also creates the go binary from my main.go in /bin. Perfect ...
Now I want to start to debbuging. I just use a simple launch.json file directly point to my main.go
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Launch",
"showLog": true,
"type": "go",
"request": "launch",
"mode": "auto",
"program": "/mnt/c/Users/cloudnaut/gospace/go/src/github.com/cloudnaut/project1/main.go",
"env": {},
"args": []
}
]
}
So and when I start now the debugging (breakpoints are set and shown under BREAKPOINTS) he creates in the folder a __debug_bin. But in my vscode debuger interface, I see no variables and stacktrace. The Problem is, I see also now errors or something. My Debug Console with the showLog: true option is nearly clean. It only contains the following lines:
API server listening at: 127.0.0.1:34477
2019-12-19T13:55:52+01:00 info layer=debugger launching process with args: [/mnt/c/Users/cloudnaut/gospace/go/src/github.com/cloudnaut/project1/__debug_bin]
Nothing else. The "step over/step info/Step out" buttons from the debugger are greyed out. I only can press pause, restart and stop.
See:
Picture VS Code Debugger Problem
I bring the solution for my own question:
The problem is that the Go dlv debugger dont works with WSL 1 because of some unsupported system calls. It only works with WSL 2, wich is included only in the Microsoft insider build.
See:
https://github.com/microsoft/vscode-go/issues/2505
I'm using the protractor-cucumber-framework to create a testbed environment for our QA team. I've searched around and been able to find zero help in implementing VS Code's debugging capability for use in this code. Has anyone does this? I'd really like to step away from console.log() statements.
1) Upgrade your Nodejs to 8 and later
2) Create a folder .vscode under your project base directory
3) Create a file launch.json under .vscode
4) Copy below content into launch.json
{
// Use IntelliSense to learn about possible Node.js debug attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [{
"type": "node",
"request": "launch",
"name": "gie",
"program": "${workspaceFolder}/node_modules/protractor/built/cli.js",
"cwd": "${workspaceFolder}",
"args": [
"config/gie.config.js",
"--browser=chrome"
]
}]
}
The ${workspaceFolder} represent your project base directory
The first value in args is your protractor config file, you can use relative path to ${workspaceFolder}
The second and next value in args is command options as you type in command line to run test.
My Environment: VSCode 1.8.1, Nodejs v8.9.0, Protractor 5.2.0,