Stage rl/standard debug sockets #876
Conversation
|
I signed the CLA, check will hopefully succeed after review and changes |
| const regex = | ||
| /DEBUGGER: Debugger can attach via UNIX domain socket \((.*)\)/; | ||
| const sockPath = RegExp(regex).exec(initialMessage); | ||
| if (sockPath && sockPath.length === 2) { | ||
| resolve(new vscode.DebugAdapterNamedPipeServer(sockPath[1])); | ||
| } else { | ||
| reject(new Error("Debugger not found on UNIX socket")); | ||
| } |
There was a problem hiding this comment.
Yeah, this is not necessary if we keep our standard socket path for launch.
There was a problem hiding this comment.
See the previous one.
The point is that we maybe don't want to hardcode those sockets and want to let rdbg decide. We then extract them from debugger output. The implementation provided handles both ends, see your other comment.
src/debugger.ts
Outdated
| @@ -121,41 +120,45 @@ export class Debugger | |||
| this.subscriptions.forEach((subscription) => subscription.dispose()); | |||
| } | |||
|
|
|||
| private getSockets(): string[] { | |||
There was a problem hiding this comment.
When getting sockets, we should take users' launch.json configuration into account, especially the env. When users specifying things like RUBY_DEBUG_SOCK_DIR when starting the debuggee process, the rdbg --util=list-socks call needs to have the same value or it wouldn't find anything.
The vscode-rdbg extension takes the configuration into account so it supports the above use case.
(*The current implementation doesn't need this because it doesn't invoke the rdbg executable)
There was a problem hiding this comment.
Notice that this information has to be read from the Ruby object for the current workspace as we do here, which contains the activated environment.
|
There are some typechecking errors failing on CI. |
README.md
Outdated
| 1. Press `F5` OR click the green triangle next to the top dropdown. VS Code will then run the test file with debugger activated. | ||
| 1. When the breakpoint is triggered, the process will pause and VS Code will connect to the debugger and activate the debugger UI. | ||
| 1. Open the Debug Console view to use the debugger's REPL. | ||
| 2. Open the relevant test file. |
There was a problem hiding this comment.
(nit) Leaving them all at 1. in the source makes it easier to add or remove steps, without having to renumber the others.
There was a problem hiding this comment.
@vinistock I tested this branch against:
- A Rails app on Spin around server integration + debug code lens
ruby-lsp's debug code lens + server debug mode- IRB's debug code lens
And they all worked perfectly, with only ruby-lsp's debug mode needing to remove the socket path env.
I'll let you do the final review and merge.
@stage-rl Sorry for the long delay and thanks for the amazing work 🎉
|
I'm getting into rails with vscode, and was wondering if I was crazy because I couldn't figure out why debugging was so difficult. Thanks for this @stage-rl! |
After Shopify/vscode-ruby-lsp#876, we don't specify the debugger socket path on the extension side anymore. So if we keep the fixed path in the executable, it will cause the debugger to fail to connect.
Motivation
Closes #832
Simplify debugging rails app and running tests. Use standard debug sockets provided by rdbg as much as possible.
Implementation
Attach configuration - request sockets by running
bundle exec rdbg --util=list-socksRunning tests - extract socket info from rdbg output
Updated Readme.md to reflect this
Automated Tests
No tests added. If required, let me know
Manual Tests
Install
debuggem. Verify by runningbundle exec rdbg -vRun your app with rdbg - e.g.
bundle exec rdbg -O -n -c -- bin/rails server -p 3000You should be able to use vscode debugger attach configuration to connect to your running app