-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request]: Switch to using Delve DAP support? #186
Comments
Server is still way too immature to switch to this. For the record the following works with the example in support/test/go/hello_world: {
"adapters": {
"dlv-dap": {
"variables": {
"port": "${unusedLocalPort}"
},
"command": [
"$HOME/go/bin/dlv",
"dap",
"--listen",
"127.0.0.1:${port}"
],
"port": "${port}"
},
"run-dap": {
"adapter": "dlv-dap",
"default": true,
"configuration": {
"request": "launch",
"env": { "GO111MODULE": "off" },
"mode": "debug", // debug|test...
"program": "${workspaceRoot}/hello-world.go",
// "args": [],
// "buildFlags": ...
// "stackTraceDepth": ...,
// "showGlobalVariables": true,
}
}
} Reverse engineering is the only way to determine th launch arguments: https://github.com/go-delve/delve/blob/master/service/dap/server.go#L434 |
FWIW I'm having good success thus far with
I'll be sure to report any issues I do come across. |
As the closest thing I know to a go expert, I shall trust your judgement! if it works well then I’m keen to deprecate the typescript vscode plugin none sense and switch to it. |
emm, sorry, I get the error when use dlv-dap
threr is my .vimspector.json {
"adapters": {
"dlv-dap": {
"variables": {
"port": "${unusedLocalPort}"
},
"command": [
"$HOME/go/bin/dlv",
"dap",
"--listen",
"127.0.0.1:${port}"
],
"port": "${port}"
}
},
"configurations": {
"run": {
"adapter": "vscode-go",
"configuration": {
"request": "launch",
"mode": "debug",
"program": "${file}",
"dlvToolPath": "/bin/dlv",
"trace": true,
"env": { "GO111MODULE": "off" }
}
},
"run-dap": {
"adapter": "dlv-dap",
"configuration": {
"request": "launch",
"mode": "debug",
"program": "${file}",
"dlvToolPath": "/bin/dlv",
"trace": true,
"env": { "GO111MODULE": "off" }
}
},
"run-exec": {
// NOTE: To use this you _must_ disable optimistaion:
// go build -o hello_world -gcflags="all=-N -l"
"adapter": "vscode-go",
"configuration": {
"request": "launch",
"mode": "exec",
"program": "${file}.exe",
"dlvToolPath": "/bin/dlv",
"trace": true,
"env": { "GO111MODULE": "off" }
}
}
}
} |
Delve DAP doesn't support remote debugging at present so we can't switch to it. |
@puremourning Great timing since we are still working on polishing remote debugging features. Can you please clarify what you meant by 'remote' debugging for vimspector users? If users are willing to run Launching/attaching to a target on a host remote from the debug adapter is not supported and won't be supported. |
oh really. In that case it’s fine IMO. Users have to do that sort of thing for other adapters anyway and vimspector can even run it for you. I was really just parroting what I just read on the vscode-dap docs. So I guess we can switch to it in the same way we switched from vscode-python to debugpy ie deprecate vscode-go support and remove after 1 year. Anything else I should need to know ? Any other caveats or custom DAP stuff? |
Thanks @puremourning AFAIK, I don't see anything else - maybe update the documentation. :-) One tricky part we found today is: dlv dap is usable only with recent versions of Delve. (1.6.1+) and Delve officially supports 3 latest Go versions. So, if users want to debug a program with an old Go version, users will need to either 1) fall back to the legacy adapter, or 2) start Delve with Another tricky part in vscode-go integration was to handle stdout/stderr from the debugged target. The current dlv dap implementation does not send the debugee's stdout/stderr as OutputEvents. They are sent directly to stdout/stderr of the |
I'd like to give vimspector + dlv dap a try. |
@leoluz you mean like this ? #186 (comment) |
@puremourning Ok. I'll give that a try. I just wanted to follow the latest guide you have regarding that and that comment is from March so I wasn't sure. tks |
@puremourning The documentation for launch/attach args is in https://pkg.go.dev/github.com/go-delve/delve@master/service/dap#pkg-types Is there anything that you want us to clarify or fix before using |
@hyangah does dlv dap not send runInTerminal request for the debugee? If so, how is stdin handled? |
@puremourning
|
so in order to debug processes that use standard input, vimspector would have to do seomthing like start dlv dap in a terminal with a tty, then communicate with it over a socket ? does it support that ? I don't know tbh if this is any different/regressive vs vscode-go. The real reason I haven't done anything about this is that I don't use go often enough for it to affect me. There are a couple of things we would have to do:
So like, it's a bunch of fiddly work that isn't a high priority for me personally. I'm happy to accept community contributions on this of course, but not breaking existing users is a must and avoiding supporting 2 ways to do go is a strong desirable, because I don't have the bandwidth to constantly ask "which adapter are you using" when someone inevitably says "go debugging no works" in Gitter or on GitHub issues/discussions. |
go-delve/delve#1515
It looks like they merged DAP support in Delve directly. This might be better than relying on the (mostly unnecessary) vscode-go bloat which is likely only tested with vscode.
Switching to debugpy was a great choice and much better than vscode-python.
The text was updated successfully, but these errors were encountered: