@deivid-rodriguez I put together a way to set hit conditions via the CLI, per our discussion https://github.com/deivid-rodriguez/byebug/pull/747#issuecomment-708662824.

Doing it all in one command with a single regex and a single help string was getting messy, so I split ConditionCommand into subcommands.

Any ideas on how to better expose it?

ConditionCommand could be modified to support hit conditions. Possibly:

• cond[ition] [expr[ession]] <n>[ expr]
• cond[ition] hit[count] <n>[ <op> value]

Implemented as:

Closes #739.

This MR modifies brkpt_set_hit_condition in ext/byebug/breakpoint.c to allow clearing a breakpoint's hit condition by setting it to nil. The documentation on the function indicates this should be possible, but passing nil will raise an exception, and no code path in the function will set the condition to HIT_COND_NONE.

Replacing Document-class: Byebug with Document-module: Byebug in ext/byebug/byebug.c fixes yard doc. Without this, it appears that YARD clobbers everything except what's in the C files. At the time of writing, https://rubydoc.info/gems/byebug contains only the following:

• Byebug (module)
  • DebugThread < Thread
  • ThreadsTable < Object
• Context < Object
• Exception
• Kernel
• ThreadsTable < Object

This is missing almost all the Ruby classes. This change un-confuses YARD, resulting in documentation for the Ruby code.

Problem description

The documentation on Breakpoint#hit_condition= indicates that nil should be a valid value. However, the implementation doesn't actually handle nil.

https://github.com/deivid-rodriguez/byebug/blob/c27c0c74c67743d20d6ceae58fe242118545dc50/ext/byebug/breakpoint.c#L114-L142

Expected behavior

Calling bp.hit_condition=(nil) sets breakpoint->hit_condition = HIT_COND_NONE;

Actual behavior

TypeError (nil is not a symbol)

Steps to reproduce the problem

irb> require 'byebug/core'
irb> bp = Byebug::Breakpoint.add('file.rb', 1)
irb> bp.hit_condition = nil

• Adapter extension - VSCode Byebug Debugger (repo)
• Adapter - byebug-dap Gem (repo)
• SDK - ruby-dap Gem (repo)

Problem description

I want to be able to set a function breakpoint on Foo.method(:bar) separately from Foo.instance_method(:bar). I don't have any strong feelings about how/if this is handled by byebug's frontend/interface, because I am implementing my own interface. For that, I just need some way to create a breakpoint that is instance-only or class/module-only.

class Foo
  def bar
    # ...
  end

  def self.bar
    # ...
  end
end

Expected behavior

When I set a breakpoint on Foo#bar, byebug breaks on the instance method. When I set a breakpoint on Foo.bar, byebug breaks on class method.

Actual behavior

When I set a breakpoint, I cannot specify instance vs class, I can only specify the class name and method name. Because of this and because Byebug's method breakpoint handling is agnostic of instance vs class method, byebug breaks on both methods when I set a method breakpoint.

Steps to reproduce the problem

1. Include the above class and loop { Foo.new.bar; Foo.bar } in test.rb
2. Debug test.rb with byebug
3. Set a method breakpoint with Foo#bar or Foo.bar
4. Byebug breaks on both the instance and class method, regardless of how the breakpoint is created

In this case, a long-running process with worker process children is running. When VSCode attaches to the main process, the debug adapter informs the extension of the children (via a custom event), and VSCode attaches to the children, as child debug sessions. When VSCode disconnects from a given session, the process/debug adapter (intentionally) does not exit.

This appears to be a side-effect of the fact that VSCode leaves the Call Stack view empty if there is only a single debug session, which is single threaded. If I start a second thread in the child, the two threads appear in the Call Stack view. I still find this behavior confusing, but I guess it's not a bug. I might open a feature request: "VSCode should show something in the Call Stack view for a single, single-threaded debug session."

Fun fact - disconnecting from the parent session does not disconnect from the child session, but it does remove both sessions from the Call Stack view, unless the child is paused, and the toolbar remains up and associated with the child session: #108351

Issue Type: <b>Bug</b>

VS Code version: Code 1.49.3 (2af051012b66169dde0c4dfae3f5ef48f787ff69, 2020-10-02T17:54:06.165Z) OS version: Darwin x64 19.6.0

1. Attach to or launch a debugger that spawns a child process and attaches to the child as a nested debugger session
2. Detach from the parent session
3. The child session stays attached and the debugger toolbar stays active, but the child session disappears from the call stack pane.

I am using vscode-byebug and byebug-dap. I've attached my test ruby file and launch configurations. For attaching, I am running bundle exec byebug-dap -f --wait --unix debug.socket main.rb.

• example.zip

<details> <summary>System Info</summary>

</details><details><summary>Extensions (33)</summary>

</details> <!-- generated by issue reporter -->

@weinand My use case is https://gitlab.com/firelizzard/vscode-byebug, specifically ByebugAdapterDescriptorFactory. ExecutableDebugAdapter is perfect for my purposes:

• I have a debug adapter (written in Ruby, for Ruby programs) that fully supports DAP, and thus the extension doesn't need to implement anything except startup.
• The DA supports stdin/stdout communications, which is ideal because I don't need to pollute user systems with unnecessary sockets.
• ExecutableDebugAdapter handles all of this, except failures.

The last point is especially problematic, because I don't have access to ExecutableDebugAdapter (and I'm not likely to get it: #108138) - all I can do is return a DebugAdapterExecutable.

If everything goes well, I return a DebugAdapterExecutable that launches byebug-dap --wait --stdio <program> <args> (or bundle exec byebug-dap <...>), and everything works perfectly. However, DebugAdapterExecutable does nothing to capture stderr. If the program argument is invalid, the debugger tracker will see ENOENT and a path, which is useful. But if bundle exists but it can't find byebug-dap, all I get is "exited with code 127", and zero information.

Beyond that, sometimes my extension has bugs (e.g. passing the wrong options) or the DA has bugs, and I want to show that error output somewhere. But DebugAdapterExecutable doesn't capture it at all.

I suppose a workable middleground would DebugAdapterStdio/StdioDebugAdapter, but I'd rather leave the child process handling to ExecutableDebugAdapter.

I believe there's a typo in AbstractDebugAdapter:

https://github.com/microsoft/vscode/blob/6bebcbb58d95e59ffde0e372888c5eea3995bf82/src/vs/workbench/contrib/debug/common/abstractDebugAdapter.ts#L43-L48

I'm pretty sure that should be if (this.messageCallback), not if (this.eventCallback)

This does not work for me.

I have a debug adapter that can work via stdin/stdout or via a unix socket:

class MyFactory implements DebugAdapterDescriptorFactory {
    async createDebugAdapterDescriptor(session: DebugSession) {
        if (session.configuration.request == 'attach') {
            return new DebugAdapterNamedPipeServer(session.configuration.socket);
        }

        const program = '...'
        const args = ['...', '--listen-on-unix-socket', '/tmp/byebug.socket']
        const dbg = spawn(program, args, {
            cwd: config.cwd,
            env: config.env,
            stdio: 'pipe',
        });

        let ready: (r: Boolean) => void;
        const setup = new Promise((ready) => {
            dbg.stdout.on('data', /* ... */);
            dbg.stderr.on('data', /* ... */);
            dbg.on('exit', /* ... */);
            dbg.on('error', /* ... */);
        });

        if (!await setup)
            return null;

        return new DebugAdapterNamedPipeServer('/tmp/byebug.socket');
    }
}

However, if I instruct my adapter to listen on stdin/stdout and use ProtocolServer:

        const args = ['...', '--listen-on-unix-stdio']
        // ...

        const adapter = new ProtocolServer();
        adapter.start(dbg.stdout, dbg.stdin);
        return new DebugAdapterInlineImplementation(adapter);

Then it does not work. The debug session hangs, with only the restart and stop buttons enabled and the progress indicator cycling endlessly. I put a breakpoint on the return statement, and it does return.

The existence of DebugAdapterExecutable in index.d.ts implies that extensions should be able to use it. I think it is reasonable to expect to act on output from the executable spawned by returning a DebugAdapterExecutable, so I created an MR to enable that. The MR template indicated that every MR is required to have a corresponding issue, so I created one.

This PR fixes #108145:

• Adds onOutput: Event<string> to AbstractDebugAdapter (and thus to all debug adapter classes)
• Adds onOutput?(output: string): void to DebugAdapterTracker and MultiTracker
• Adds $acceptDAOutput(handle: number, output: string): void to MainThreadDebugServiceShape and MainThreadDebugService
• Modifies ExecutableDebugAdapter.startSession to forward the child process' stderr to onOutput
• Modifies ExtHostDebugServiceBase.$startDASession to forward the debug adapter's onOutput to tracker.onOutput and to debugServiceProxy.$acceptDAOutput

This can be tested by adding onOutput(s: string): void to a debug adapter tracker that tracks a debug adapter that uses DebugAdapterExecutable/ExecutableDebugAdapter to spawn a process that outputs on stderr.

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ --> <!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ --> <!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

When I return a DebugAdapterExecutable from DebugAdapterDescriptorFactory.createDebugAdapterDescriptor, the debug adapter that VSCode creates (ExecutableDebugAdapter) spawns a child process, but does not expose stderr of that process in any way.

VSCode should provide a way for extensions to act on stderr of the process spawned by ExecutableDebugAdapter.

This is somewhat related to #98976.

@connor4312 Nothing in that project fills the role of ExecutableDebugAdapter, so I would still have to reimplement most of its functionality. ExecutableDebugAdapter does exactly what I want, which is why I am asking for it to be exposed.

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ --> <!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ --> <!-- Please search existing issues to avoid creating duplicates. -->

I request that the classes in the following files are exposed to extensions, or distributed as a separate NPM package:

• src/vs/workbench/contrib/debug/common/abstractDebugAdapter.ts
  • AbstractDebugAdapter
• src/vs/workbench/contrib/debug/node/debugAdapter.ts
  • StreamDebugAdapter
  • NetworkDebugAdapter
  • SocketDebugAdapter
  • NamedPipeDebugAdapter
  • ExecutableDebugAdapter

As an extension developer, when implementing a DebugAdapterDescriptorFactory, I have access to a number of descriptors I can return: DebugAdapterExecutable, DebugAdapterServer, and DebugAdapterNamedPipeServer. However, I do not have access to the actual debug adapter implementation that is instantiated, unless I write and instantiate my own adapter and return a DebugAdapterInlineImplementation. Thus, if I want to provide any variation on the base executable, server, or named pipe server debug adapter implementations, I am forced to reimplement the entire adapter.

This is very inconvenient, as I am working on a debugger extension for a Ruby debug adapter that has first-class support for DAP. The existing ExecutableDebugAdapter does 99% of what I need; all it's missing is a way to handle STDERR:

class MyDebugAdapter extends ExecutableDebugAdapter {
    async startSession(): Promise<void> {
        await super.startSession()

        this.serverProcess.stderr!.on('data', data => /* do something useful */);
    }
}

@bpasero @SneakyFish5 I prefer the way Quit Control does it. If you quit, it asks "Do you really want to quit?". If you close a window, it asks "Do you really want to close this window?" Though system modal dialogs (as in this PR) may be better than VSCode-style prompts, because they're more in-your-face, which seems appropriate for this feature.

Note that this could still be compatible with the keybinding suggestion in #14710: Meta-Q once brings up the confirmation, Meta-Q a second time confirms. So Meta-Q, Enter and Meta-Q, Meta-Q would both quit/exit.

I think the second option that Quit Control shows should be omitted. It seems like it's saying, "Did you mean to Quit? If you actually meant to close, use Meta-W or Meta-Shift-W." I doubt that is a frequent point of confusion. When I accidentally quit, it's because I was aiming for Alt+Q (rewrap) but hit Meta+Q. When I accidentally close, it's because I was spamming Meta+W to close tabs and went too far.

@wingrunr21 This is still an issue. Please fix it. It's a really simple change:

diff --git a/packages/vscode-ruby-debugger/src/main.ts b/packages/vscode-ruby-debugger/src/main.ts
index bd3ec94..e859e13 100644
--- a/packages/vscode-ruby-debugger/src/main.ts
+++ b/packages/vscode-ruby-debugger/src/main.ts
@@ -508,7 +508,11 @@ class RubyDebugSession extends DebugSession {
 
     protected disconnectRequest(response: DebugProtocol.DisconnectResponse, args: DebugProtocol.DisconnectArguments) {
         if (this.rubyProcess.state !== SocketClientState.closed) {
-            this.rubyProcess.Run('quit');
+            if (this.debugMode === Mode.launch) {
+                this.rubyProcess.Run('quit');
+            } else {
+                this.rubyProcess.Run('detach');
+            }
         }
         this.sendResponse(response);
     }

I would much rather "Do you really want to quit?" behavior over making Cmd/Ctrl+Q chorded as in https://github.com/microsoft/vscode/issues/14710#issuecomment-488114446.

Users asking for features is how VSCode improves, and maybe if enough people ask for this feature, it will actually happen. But complaining is pointless.

Really struggling to see why.

Because it's not a priority for them. As a team, they have decided to prioritize other things. You can disagree with their decisions, but all of this "OMG whhhhhy" whining is obnoxious and pointless.