Support for attaching a command interpreter to a pty slave about debug-adapter-protocol

[lanza]

Right, but it's a backdoor. The spec itself says this prompt is for evaluating expressions in the context of the current stack frame. It's not a prompt for debugger commands. The packet sent is the same packet as the one sent for hover evaluations.

I don't think it's a contentious statement to say that the Debug Console's backdoored command prompt implementations are a sign of a problem. Here are all the ways the features I am requesting are hacked into the implementations:

• vscode-cpptools - Prefix the command with -exec e.g. -exec target list
• vscode-lldb - The specs is actually ignored and evaluate actually evaluated the lldb command. You must prefix your Debug Console command with ? in order to get the spec's evaluation requirements.
• lldb-vscode - Prefix the command with a backtick. 'target list.
• code-debug - Same as vscode-lldb, ignores the spec and provides the debugger command prompt instead.
• My own implementation - As @weinand mentioned above, createTerminals lldb-vscode, attaches command prompt and then listens via a socket to provide the actual lldb command prompt.

So we have five tools with four unique approaches to circumventing the shortcomings of the DAP. All of which technically violate the specification in order to do so.

[puremourning]

If I understood this correctly, this would allow the DAP client to present a true UI to the command-line-debugger. This is a really nice feature of graphical debuggers: yes the UI is nice, but power users know how to do things using the debugger CLI quickly.

As a power user, that's really attractive to me. And as the author of Vimspector, I'd look to somehow make this possible with Vim's built-in Terminal. Though if I'm honest, I don't know how to make that happen (yet).

OTOH I wonder how general it is. I mean for a given DAP server, how many things could I do in the lldb, gdb, a.n. other, CLI that would break the state and/or behaviour of the DAP wrapper (e.g. MIEngine). This is already a problem for some adapters that try this. Again, referring to vscode-cpptools, if you happen to set certain types of conditional breakpoint via the "REPL" interface, it breaks the debugging session.

I think I'd be in favour of this protocol addition if there were a number of server authors (and perhaps client authors) that would implement it consistently and robustly.

[walter-erquinigo]

I want this feature!

I work for Oculus and we do a lot of non-web native development: games, operating systems, frameworks, hardware controllers, etc. Besides, many of our developers are trying to move to VSCode, which is a very cool IDE.

In terms of debugging, something quite relevant is accessing the broad range of commands that LLDB offers, which are beyond what the VSCode debugger UI supports through the DAP protocol:

• memory debugging
• disassembling
• register debugging
• scripting (yes, it's common to load a python script from LLDB that automates some workflow)
• symbol lookup
• module debugging
• etc.

What I mentioned here are some of daily tools native-code developers use when debugging and these are not just for power users. It can't be expected to have such features in the VSCode UI, but there should be access to them through a CLI at least.

I think supporting the PTY or creating a REPL protocol in the DebugConsole are reasonable implementations.

[pieandcakes]

For the C++ extension, we rolled a special REPL command where if the command was prefaced with -exec we would forward the command to the underlying debugger without additional parsing. I think with this proposed change, it would alleviate users from having to type -exec in front of every command sent through the REPL window.

[weinand]

Thanks for suggesting a new feature.

However, I do not fully understand what you are trying to achieve...
So here are some questions:

• "lldb-vscode" is a command tool like "lldb" that uses the VS Code debugger as its UI, correct?
  But then I got lost.. could you provide some screen recording that shows "lldb-vscode" in action?
• when you talk about "server" you mean "debug adapter" and with "client" you mean "VS Code", right?
• If my last assumption is correct, then VS Code needs to probe for a "supportsAttachingCommandInterpreter" capability returned by the debug adapter. This means that your new feature is not only a DAP extension but requires code in VS Code too. Shouldn't we then move the discussion to the VS Code repository? You are actually asking for a new VS Code feature (which might require a DAP extension eventually).

One additional comment:
in the proposed protocol you are talking about Unix paths and sys calls. Please be aware that DAP operates on a more abstract level since it is OS agnostic. A VS Code implementation does not want to deal with OS differences. If there are any, they need to be handled in the debug adapter.

[lanza]

in the proposed protocol you are talking about Unix paths and sys calls. Please be aware that DAP operates on a more abstract level since it is OS agnostic. A VS Code implementation does not want to deal with OS differences. If there are any, they need to be hanudled in the debug adapter.

Yup, our implementation (lldb-vscode) works on both. I just refer to posix API calls because I have them memorized and have to look up the full win32 ones. But we offer full support for both platforms. I'm not proposing a specific implementation, just using the linux syscalls to demonstrate the idea.

lldb-vscode is a C++ program that just loops over STDIN for DAP packets. e.g. in simplified pseudoish code

int main() {
    while (true) {
        llvm::json json = readJSON();
        dispatchJsonHandling();
    }
}

Nothing exciting there. But within the program there is a function that can run a repl loop. Again in psuedoish code:

void start_repl_loop(int file_descriptor) {
    while (true) {
        read_line();
        eval_line();
        print_result();
    }
}

Currently, that function is unused since lldb-vscode is launched like any other DAP implementation and has STDIN and STDOUT connected for DAP packets.

This request is for the DAP implementation to tell the host that it has a function like start_repl_loop that can provide command line functionality if offered a pty that will be attached to a terminal emulator. So in response to the initialize packet the DAP implementation would say supportsCommandInterpreter: true.

If the host tool (e.g. VSCode or emacs dap-mode or vim-vimspector or neovim) supports this functionality, it will ptyopen a new pty slave/master pair, send the slave filepath to the DAP implementation and attach the pty master to a terminal emulator. The DAP implementation will open the file and call start_repl_loop on it.

The ultimate result is that you have both the standard gdb/lldb/pdb/jdb/visual-studio debugger/etc command prompt AND the GUI integration for any implementation that supports this option.

"lldb-vscode" is a command tool like "lldb" that uses the VS Code debugger as its UI, correct?
But then I got lost.. could you provide some screen recording that shows "lldb-vscode" in action?

lldb-vscode is nothing special. It's a DAP implementation. The program in the package.json is lldb-vscode and it handles DAP packets the same as any other DAP implementation. It just has a function that can open a REPL that is currently unused since the DAP and VSCode do not offer this functionality.

If my last assumption is correct, then VS Code needs to probe for a "supportsAttachingCommandInterpreter" capability returned by the debug adapter. This means that your new feature is not only a DAP extension but requires code in VS Code too. Shouldn't we then move the discussion to the VS Code repository? You are actually asking for a new VS Code feature (which might require a DAP extension eventually).

Not quite. This is a DAP feature. VSCode would just implement it. If I choose to implement this in vim-vimspector and nobody ever touches it for VSCode it would still require both sides to agree on the DAP communication of this functionality.

[lanza]

As a power user, that's really attractive to me. And as the author of Vimspector, I'd look to somehow make this possible with Vim's built-in Terminal. Though if I'm honest, I don't know how to make that happen (yet).

Yea, this is something that will need to be implemented in every host. Luckily VSCode and neovim are very openly maintained. Some means to pass around ptys and mapped terminal buffers will be necessary.

The actual final implementation strategy could be very different. This was just something another lldb developer and I spoke about while considering implementing the command line interpreter for our lldb-vscode binary. The command line interpreter tools will need a fd that reports back true to isatty. Hence the suggestion to hand off a pty path for open.

OTOH I wonder how general it is. I mean for a given DAP server, how many things could I do in the lldb, gdb, a.n. other, CLI that would break the state and/or behaviour of the DAP wrapper (e.g. MIEngine). This is already a problem for some adapters that try this. Again, referring to vscode-cpptools, if you happen to set certain types of conditional breakpoint via the "REPL" interface, it breaks the debugging session.

I think I'd be in favour of this protocol addition if there were a number of server authors (and perhaps client authors) that would implement it consistently and robustly.

This is a weird bias towards young projects and the short-term. A properly done debugging interface could be a many decade solution that all debuggers could grow to stability against. It should be done right and not focused on today's bugs. Visual Studio, Xcode, Clion, Android Studio, IntelliJ, Eclipse etc all offer command line debugging integrated into their GUIs.

I'm not sure of the long term goals of the DAP authors. But if it's completion and feature parity then this functionality seems like a requirement.

[PavelSosin]

Again, I'm worry about protocol stack. Remote DAP protocol, shares with LSP certain protocol stack:
DAP / LSP on top of JSONrpc on top of WebSocket.. It makes them universally usable. WebSocket protocol is Linga Franka of Cloud computing. For example, Google supports node inspector protocol in the Cloud via certain universally available annotations of components responsible on requests routing.
If protocol stack can't be routed safely(!!!) through the Cloud routing and proxy components, i.e. can be used only for desktop IDE. Its implementation can't attract investments from major Cloud IDE providers. I prefer not to think that it will be used only in week-end projects instead to be used as industrial standard.

[PavelSosin]

I would like to remind that Microsoft VSCODE is Web based replacement for MS Visual Studio. This is not only open source project but also Microsoft product. Any VS code extension or extension of protocols used by VSCODE should conform with main scenario relevant for Microsoft, i.e. Azure cloud based development including DevOps, etc. As industrial standard candidate it should conform also with other Web IDEs: Eclipse/Che from RedHat, WebIDE from SAP. Please, think twice before you submit you proposals how it can be implemented in Cloud based IDE.

[weinand]

@PavelSosin this project is about the Debug Adapter Protocol. Please refrain from making questionable statements about unrelated topics.

[puremourning]

This is a weird bias towards young projects and the short-term.

That’s a reasonable criticism. As I said I love the concept of power we can expose, but I worry that the robustness could ultimately hinder UX. but if the community are behind it, then I have no fundamental objection, other than considering whether the protocol wants to support running the DA on another’s host, in a container, etc.

Having said that @weinand is correct to point out that UX in that sense is somewhat orthogonal tot he protocol definition. Though a protocol without real use cases isn’t strictly a solution to anything ;)

[PavelSosin]

For my company and me the decision whether to develop Cloud IDE for development of cloud applications is already behind us. Many hundreds of developers use WebIDE every day and they use it because it is Cloud IDE. The same is true for RedHat Eclipse/Che. They use multilingual IDE today. They need multilingual debugger tomorrow.

[puremourning]

If I'm understanding @PavelSosin correctly, the concern is that by including in the protocol such a concept as a file descriptor, or pseudo terminal, then that bakes in an assumption that the client and server share some common hardware or software or filesystem. I think that's a reasonable concern (though not one that particularly bothers me), but it begs a wider question about the expected use case for the protocol: is there an inherent assumption that the client/server run on the same machine? There is in LSP (you pass the parent PID, IIRC, and there are some filesystem assumptions), and I also think there are for practical reasons in DAP (e.g. runInTerminal and suchlike). So perhaps that's a wider question.

Assuming that is the question/concern, I suspect it could have been expressed better. If it's not, then I'm struggling to see the relevance of most of what was said.

[lanza]

Having said that @weinand is correct to point out that UX in that sense is somewhat orthogonal tot he protocol definition. Though a protocol without real use cases isn’t strictly a solution to anything ;)

Yea, the implementation into VSCode's GUI is an entirely different feature suggestion I'll have to do over there. But the feature will require the DAP to support it in the first place. Their implementation will be muddied a little bit as there already is a Debug Console. Maybe they can move that to a Variable Evaluation pane and repurpose the Debug Console being that what I'm proposing is more properly a "Debug Console."

[PavelSosin]

Lets see things as they are in modern software development. 99% of investments are attracted by 3 areas: Mobile applications, cloud applications and IoT. I can hardly imagine as adoption of some feature which can't solve some issue in these areas can be submitted into backlog of our company. Developer working with cloud development environment provided by Google, SAP or RedHat (Eclipse~tm owner) own no hardware, neither client nor server. He/She is not involved directly in hardware maintenance. His client is browser and his server is VM. Naturally, in IoT area reined by ARM situation is different. Developer either posses or lease on cloud some device on which application will run. In the case when application is written in Java or C++ (mostly) nothing else regular high level language debugger is necessary. In the case when application is written in Assembly or C++ some hardware details can be visible in the context of device's CPU architecture (registers) and memory model.
Microsoft provides cloud tool for application image (snapshot) debugging - Azure Snapshot debugger. Google provides cloud tool for application image (snapshot) debugging - GCP Stack Driver. Cloud infrastructure(!) is adopted to run these tools including protocol support.
VSCode is Nicrosoft product but Microsoft is great Cloud company today.
The last areas where low level programming is applicable are compiler and driver development.
If DAP protocol feature can't solve problems in these areas or can't run in given development environment it will never be offered to developers.
In any scenario developer can access source file located on his computer or in remote workspace.

[puremourning]

@PavelSosin even if your baseless statements about what "99% of investments" are used for are accurate, they are irrelevant to the discussion.

The last areas where low level programming is applicable are compiler and driver development.

This is simply untrue and shows a level of ignorance that I find deeply saddening.

[weinand]

@lanza there is no need to communicate to a DA via stdin/stdout. Using a socket instead is possible and part of VS Code's extension API. The Java debugger and other debug extensions use this approach.

When starting a debug session your extension code could launch the DA of lldb-vscode in the integrated terminal and pass a port number for the DAP communication. VS Code would then connect to this port.
Stdin and stdout would be available for the user to interact with your command interpreter.
VS Code's debug console would be still available as a REPL.

Why do you need a protocol addition for this?

[PavelSosin]

This is good idea how to extend Debugger UI functionality but how it is related to Protocol? Remote terminal needs RDP. DAP is based on WebSocket. do you mean tunneling RDP via WebSocket?
Remote terminal is already supported by some Cloud IDE out-of-the-box. Simply connect to Eclipse/Che trial and use it. This is generic native cloud infrastructure feature.

[PavelSosin]

Developer installs Visual Studio code from the site Visual Studio Code as a product. Visual Studio Code responsible on the product feature completeness and consistency regardless how much product license costs. Please, explain what is additional value the feature gives to users other then yourself. Please respect other developers. Please explain why it can't be achieved in already existing way. This is normal design process!
LSP is adopted widely by several development environments because it serves ultimately required from any IDE - code assistance. This feature was introduced many years ago by Visual Studio and Eclipse. LSP is backbone protocol of different IDE. Its implementation is feasible on top of various Web and Cloud infrastructures. The purpose of DAP is exactly the same as LSP - to be a backbone protocol! Locally installed Visual studio or Eclipse don't need LSP.
If yu need command line debugger on Windows you can run Linux subsystem (WSL) on Windows 10 nice feature. For remote command line debugging try OpenSSHClient feature of Windows 10
P.S. "Personal" WebIDE doesn't support LSP. Eclipse/Che can be installed on personal computer only on top of Docker infrastructure at least! Minikube or Minishift are desired.

[weinand]

@lanza please find another relevant question three comments above. Sorry that it drowned again...

[puremourning]

@weinand Regarding this:

When starting a debug session your extension code could launch the DA of lldb-vscode in the integrated terminal and pass a port number for the DAP communication. VS Code would then connect to this port.

The issue I have with this is this part:

your extension code

The problem is that this extension code won't exist for all-but-one of the actual clients. By integrating into the protocol, this allows all clients to benefit from this feature without having to write debug adapter-specific code, which I for example (as one person in my evenings and weekends) can't do for something like vimspector.

I think the use case is general (a REPL interface to the debugger), and has been implemented (badly) by some DAs using the evaluate request already. Perhaps we can argue about the implementation (pty slave or not, etc.), but can we agree on the generality of the use case?

Arguably useful contribution part ends here.

---

@PavelSosin You have to realise that there is a real use case for convenience of integrated debugging and power-user command interface, surely? Your own personal experience of cloud IDEs, and their use cases, is potentially useful input but not the only input and certainly not the only use case. It confounds me that you don't see that.

Moreover, this remains an optional feature. If your objection is that you can't implement it in your cloud-based whatever, then don't. I suspect that you can't implement the processId argument of the initialise request of LSP either, right?

interface InitializeParams {
	/**
	 * The process Id of the parent process that started
	 * the server. Is null if the process has not been started by another process.
	 * If the parent process is not alive then the server should exit (see exit notification) its process.
	 */
	processId: number | null;

---

FWIW, my personal opinion, which remains as irrelevant as yours, is that the worst possible IDE is one in a web browser. This is made completely unusable by being in "the cloud" as you put it. In my company this would be laughed at. Again, irrelevant to the discussion.

As a professional software engineer working with real mission critical systems, a good integrated debugger is especially useful to productivity. It is also very useful to have power user features as well, allowing a broad range of possible use cases across a broad range of programming and testing environments. I doubt there are a lot of game programmers using cloud-based IDEs.

[PavelSosin]

P.S. I found 2 SSH consoles in my Windows 10: from OpenSSH client feature and Linux SSH client from WSL. It is impossible to run OS Shell command from browser but it is possible to run OS Shell comand from nodejs server. It looks like it can be only VSCode back-end extension which has UI expression only if VScode server URL is localhost. For normal Cloud IDE your proposal is unusable. Every Cloud applications developer knows how to "SSH" container running the application by name:
cf ssh - Cloud Foundry
gccloud compute ssh - kubernetes,
etc.
Fortunately container name is known upon deployment application for debugging. Unfortunately every Cloud infra SDK uses its own CLI.

[PavelSosin]

You can try "Secure Shell Application" extension directly from your Chrome.
Do you still need the protocol feature? Maybe you can start using what you already have today?

[PavelSosin]

@lanza Nathan I doubt there are a lot of game programmers using cloud-based IDEs. ?
Indeed? The purpose of all existing Cloud based IDE is development of consumer and business applications using high level languages. Did you hear already about next big thing from Google Stadia? I strongly believe that Google will offer best of the bread development tools and situation will change soon. Be prepared! They search Game developers for Stadia with candles. You have chance! Chrome is superb rendering engine which uses native graphics and hardware acceleration. Try chrome://gpu on your browser.

[weinand]

@puremourning Debug Adapters were never designed as end-user visible tools. They are an implementation detail that "adapts" a generic debugger UI with a specific real debuggers via an abstract wire protocol.

Debug Adapters don't have an end user command interpreter because typically the "real debugger" has that and I see no need to duplicate that.

You said:

By integrating into the protocol, this allows all clients to benefit from this feature without having to write debug adapter-specific code, which I for example (as one person in my evenings and weekends) can't do for something like vimspector.

Since no DA has a command interpreter, it would be necessary for individual debug extensions to add one to the DA before they could profit from the generic functionality introduced with this feature.

But if the DA has to be changed anyway, then why not change the extension in the way I've described above? And if we see widespread adoption of this approach then we can add this feature to the Debug Adapter Protocol.

But I'm hesitant to add a new feature to the DAP that is not heavily requested.

[PavelSosin]

There are already 2 different approaches when LSP and DAP server processes should be started under discussion. The 1st approach iw starting by demand like in WebIDE starts LSP. the cost is high latency due to workspace, synchronization and compile/build by demand. Server start-up time is significant too. It harms performance. The second approach is Eclipse/Che Workspace.NEXT approach. The server runs as side-car of Workspace provisioning service and accesses workspace locally to spin-off application binary. LSP / DAP servers type is derived from project type. The server start-up time is a part of Workspace open time. The cost is permanent consumption of resources by servers, even when they are idle. This is latency - resources mitigation problem.
In both cases no button on UI is needed - Open Workspace, Open project and Start debugging are triggering event candidates.
Every server has own URL and port and can be used for full stack application development in desired combination.

[PavelSosin]

What is file descriptor? According the protocol definition file is represented by ruri. File uri is universal file descriptor. It can start from file://, http://,https://, etc. The base url of file url is workspace base URL even it is file:///c//myworkspace/ The Web UI client knows this fact very well. The developer also knows it
Workspace provisioning service has simple REST api. You can set tiny http or https nodejs static server and use it as remote workspace provisioning server. The concept is that LSP and DA servers are separated from Workspace provisioning

[weinand]

@PavelSosin could you please move your monologue to a new issue as it is unrelated to the topic at hand. Thanks.

[puremourning]

@weinand

Debug Adapters don't have an end user command interpreter because typically the "real debugger" has that and I see no need to duplicate that.

I would agree except that:

• the "real debugger" backs the DA, and this is just exposing that to the end user (by allowing it in the protocol
• the best (reference?) c/c++/etc. debug adapter (Microsoft's vscode-cpptools) already exposes this "real debugger" in the "Console" by allowing you to snd arbitrary commands -exec <command>

So there's clearly a real use case for it (it's already in use).

They are an implementation detail that "adapts" a generic debugger UI with a specific real debuggers via an abstract wire protocol.

I understand that entirely.

then why not change the extension in the way I've described above?

For the reason I mentioned above: this requires that client code is written to handle this per-debug-adapter which makes it no longer and abstract protocol, or that the "UI" is no longer generic.

But I'm hesitant to add a new feature to the DAP that is not heavily requested

Couldn't agree more. OTOH I'm strongly opposed to DA authors adapting to only work with VScode because the protocol limits the features they can expose that their users require. It's certainly a balance. As I said earlier:

I think I'd be in favour of this protocol addition if there were a number of server authors (and perhaps client authors) that would implement it consistently and robustly.

[weinand]

@puremourning the best way to spark interest in such a feature is by implementing and then marketing it. Where is the screen recording that shows this killer feature for "lldb-vscode"?

It took me a long time to grasp what this feature is all about (and I'm not really sure that I've understood it... @lanza need to confirm this first)

You complained:

"client code needs to be written to handle this per-debug-adapter"

Client code has to be written in any case because 99.99% of all DAs don't have command interpreters. So they need to be written first. The DAP protocol addition does not help with that.

The DAP protocol addition (and a client implementation of it) only helps to launch a DA in the integrated terminal and make the debugger UI to connect to it. These few lines of code are not a big deal. And everyone who wrote these lines will gain a lot of experience how the DAP addition will have to look like.

That's the approach how we typically extend DAP: first we implement the new feature as an extension and then we try to understand the limitations of that approach and how a DAP addition could fix this.

Adding a DAP protocol addition first and then hoping that someone is using it, has never worked.

BTW, before discussing details like this DAP addition, I would have expected to find feature requests filed against the clients (e.g. VS Code) that actually ask from an end users perspective, e.g. "support a CLI for debuggers". But I cannot remember that I have seen such a request...

[puremourning]

Client code has to be written in any case because 99.99% of all DAs don't have command interpreters. So they need to be written first. The DAP protocol addition does not help with that.

Apologies, perhaps I wasn't clear. When I say client code, I meant debug adapter client, i.e. vscode, vimspector, something else. I've no association with lldb whatsoever. I write vimspector, which is a debugger UI using DAP to communicate with debug adapters. I guess what I would say my position is:

• I think command line/repl interface to the actual underlying debugger is a good feature to have for a lot of debugging systems
• I would like that to be available in vimspector for any DA that makes it possible

If the protocol were to say: These messages are how you implement this feature is a completely debug-adapter and language-agnostic way, then as a debug adapter client author, I can write the code once (to the spec) and work with any debug adapter that implements it. If adapters are forced to go around the protocol by writing an "extension" (which I understood to mean a vscode-only piece of javascript), then only those clients (vscode) for which this "extension" has been written can benefit. THat's all I was saying about whether or not it warrants being in the protocol.

You complained.

I wasn't complaining :) Just contributing to the discussion. Apologies if you got that impression !

As the author of a client implementation it matters to me how much work is required to support each debug adapter. I would like to write to the specification and for any debug adapter to just work. I was under the impression that was a goal of having the protocol.

That's the approach how we typically extend DAP: first we implement the new feature as an extension and then we try to understand the limitations of that approach and how a DAP addition could fix this.

Understood. If that's the plan then I'm all for it.

Just so we're clear, where you say "extension", do you mean an extension to the protocol, or an extension to vscode via some javascript or other ?

Adding a DAP protocol addition first and then hoping that someone is using it, has never worked.

Again, I agree. The reason I'm contributing to the debate is that if, say vscode-lldb implemented such a feature, and it were part of the protocol, I would implement support for it in vimspector, as I see the value of it. Following this repo is the only way for me to know about upcoming changes to the protocol that I need to implement.

[weinand]

@puremourning you said:

I think command line/repl interface to the actual underlying debugger is a good feature to have for a lot of debugging systems

I agree with the "repl interface to the actual underlying debugger" but the "command line interface to the debugger" sounds a bit strange because the purpose of DAP is to connect a (graphical) debugger UI with a non-graphical debugger backend.

Using DAP to connect one debugger CLI with another debugger CLI was at least not the "design center" of DAP. So before we extend the DAP for this, we should make sure, that there is enough value and interest in that feature.

VS Code's builtin node.js debugger supports REPL and Intellisense in VS Code's debug console, but no one has ever asked to interact with the debugger via a CLI. In the VIM community that might be different, but the main target for DAP are tools with graphical UIs.

---

When I said "extension" I was referring to "VS Code" extensions or Eclipse plugins.
However, "protocol extension" makes sense too, because it is always possible to introduce private DAP protocol messages in an ad-hoc way if an (VS Code) extension needs to talk to its DA outside of the protocol.

[PavelSosin]

@lanza
Please read Visual studio code statement about debugging from Visual Studio Code debugging. The idea of terminal debugging is rejected. Stadia uses Visual Studio C# and Unity as development tools. Development indeed, local, but high-level languages are used. DevOps!!! is cloud-based, as expected

[lanza]

My backdoor implemented lldb-vscode

Xcode's implementation

Visual Studio's immediate Window Note that it also has the command window which does more

windbg's command prompt (the prompt that says 0:000>)

Clion/Android Studio's command prompt

@lanza there is no need to communicate to a DA via stdin/stdout. Using a socket instead is possible and part of VS Code's extension API. The Java debugger and other debug extensions use this approach.

When starting a debug session your extension code could launch the DA of lldb-vscode in the integrated terminal and pass a port number for the DAP communication. VS Code would then connect to this port.
Stdin and stdout would be available for the user to interact with your command interpreter.
VS Code's debug console would be still available as a REPL.

Why do you need a protocol addition for this?

These are the features I'm trying to match. In the first picture, I did what you suggested. I launched lldb-vscode via createTerminal and attached the command interpreter and then listened via a socket.

The problem with this is that it's, as @puremourning stated above, an adapter-to-host specific hack. The DAP doesn't support this and I'm shoe horning the feature in to make it work. If I want this feature in vimspector I have to shoe horn it there, too. If I want it in Visual Studio's debug adapter host I would require a third makeshift hack. This is the point of the protocol. To remove these implementation burdens. Every adapter should implement it once and every host should implement it once and it should work.

VS Code's builtin node.js debugger supports REPL and Intellisense in VS Code's debug console, but no one has ever asked to interact with the debugger via a CLI. In the VIM community that might be different, but the main target for DAP are tools with graphical UIs.

I think you're confusing the demographic. This isn't a vim vs VSCode thing. This is a JavaScript vs native thing. Developers that write native code expect this functionality. ALL Apple platform developers have lldb's command prompt trivially available as shown in the Xcode image above. All of Microsoft C++ developers have multiple options for command prompt + GUI debugging via WinDbg and Visual Studio. If you do native development in Android then Google's Android Studio offers lldb's command interpreter. And if you step into the GNU world then you have a thousand more examples of native code IDEs with command interpreters, the simplest of which could be the cgdb tool.

I'm shocked by the statement "no one has ever asked to interact with the debugger via a CLI." This is a flagpole feature request for the developer tooling I'm working on for Facebook/Oculus. lldb's feature set is such a drastic superset of the DAPs that it would be near impossible to adequately suit all our user's needs without the command interpreter.

[lanza]

So I don't use the https://github.com/Microsoft/vscode-cpptools plugin. But I just installed it to try it out. They ALSO backdoor the command interpreter via passing -exec thecommand in the Debug Console in order to execute lldb commands. I'm going to guess that they would also be in support of a properly implemented command interpreter.

[weinand]

@lanza thanks for providing that detailed CLI overview.

So let's get some stakeholders from the C# and C++ debuggers to the table:
@andrewcrawley @gregg-miskelly @pieandcakes what's your take on this feature request?

[walter-erquinigo]

Also, supporting completion seems like a must to me. Many commands can be long, not easily memorizable, and have typos when written. A full-fledged REPL with history and completion would boost productivity.

[gregg-miskelly]

From the VS IDE perspective: VS doesn't have a 'Debug Command' window. So there wouldn't be a good way to consume this in VS. VS does have a command window all up which isn't debugging specific. But the way to plug into that is very VS specific, and doesn't have a reasonable way to bridge.

For the C#/C++ DA perspective: To add onto what @pieandcakes mentioned, I think in most cases '-exec <command>' works pretty well -- it can be nice to not have to switch back and forth between two windows. But there are some cases where you want to type a bunch of commands where it would be nice for something more modal. Of course we could implement this in the DA itself by supported some sort of '-CommandMode enter'. But a separate window might be more discoverable. The other case that works a bit better is if the underlying debugger prompts the user when a command is executed. Today the C++ DA doesn't handle this well.

[walter-erquinigo]

@gregg-miskelly , I don't think that -exec provides a good developer experience. If you enter the LLDB REPL and type help, you'll find tens of commands, each of them having some additional tens of commands. Without proper completion and history, using the CLI through a mechanism like -exec might make some users avoid most of the time this functionality.

[gregg-miskelly]

@a20012251 the protocol already supports completion in the debug console. See CompletionsRequest.

[gregg-miskelly]

I should also add: I believe VS Code already supports history in their implementation of the debug console.

[gregg-miskelly]

I think that depends on if we have a prominent DA client that wants to offer a separate REPL window (or a different mode in their 'debug console').

If yes - we should extend the protocol.
If no - maybe all that is required is clarifying the documentation for the current evaluate response to indicate that really the DA is allowed to interpret the text however they like.

[weinand]

A "debugger command console" (my term for this feature) is not on the VS Code roadmap.
This could be changed. But for this we would need some interest showing up as VS Code feature requests and issues.

[PavelSosin]

By its definition DAP is purely Web protocol because it is based on purely Web communication stack: JSONRpc -> WebSocket. The security requirements for Internet protocols are very rigorous today. Any risk of backdoors must be avoided. Recent Windows 10 and Chrome 72 upgrades caused me big troubles and some servers which I started to use 2 years ago suddenly stopped to work. For example, Chrome upgrades HTTP to HTTPS and WS to WSS by default. WS is a part of DAP stack.
DAP Adapter is headless component unlike VSCode extension. Adapter can't attach external OS process or UI. Your feature request has to be opened on Mocrosoft/vscode github project. The final decision is up to Microsoft VSCode UX specialist.

[PavelSosin]

@lanza Implementation hint: If DA Server runs as container it automatically inherits SSH client from underlying Unix container even, if it uses DotNet run-time. To enable TTY at containerized server side some special docker images shall be used which provide TTY server: TTY Server Docker container . It is not a problem and zero codding is needed. But it is a kind of restriction. There is also Putty client container exists which offers Web GUI. If both containers have the same domain CORS issue is eliminated too.

[yannickowow]

Right, but it's a backdoor. The spec itself says this prompt is for evaluating expressions in the context of the current stack frame. It's not a prompt for debugger commands. The packet sent is the same packet as the one sent for hover evaluations.

Sorry if I dig this from too far, but is considering LLDB (or in my case, GDB) a REPL is a non-sense?
Since, for example, GDB MI (and probably LLDB-MI ?) supports --thread and --frame reference based on currently selected stack frame, and GDB-MI supports "complete" command, I did suggest it can be used as a prompt for commands.
But, in my case, this implementation also break support for "Evaluate" when using from editor context-menu. In my case, it would be perfect if uses another context than REPL (such as watch?)

[lanza]

Right, but it's a backdoor. The spec itself says this prompt is for evaluating expressions in the context of the current stack frame. It's not a prompt for debugger commands. The packet sent is the same packet as the one sent for hover evaluations.

Sorry if I dig this from too far, but is considering LLDB (or in my case, GDB) a REPL is a non-sense?
Since, for example, GDB MI (and probably LLDB-MI ?) supports --thread and --frame reference based on currently selected stack frame, and GDB-MI supports "complete" command, I did suggest it can be used as a prompt for commands.
But, in my case, this implementation also break support for "Evaluate" when using from editor context-menu. In my case, it would be perfect if uses another context than REPL (such as watch?)

I'm sorry but I don't understand what you're asking.

[yannickowow]

I was just asking if using directly debug commands in this Debug Console is really "out of spec" or not. Since GDB has a way to complete commands, you can fulfill "CompletionsRequest" with GDB one's. In the same way, GDB "REPL" is not really something relevant (in my opinion...)

Also, you said:
The packet sent is the same packet as the one sent for hover evaluations.
It is not really true, since you have a flag repl or hover depending on your current context.

Correct me if you don't see this thing like me, but, to me, changing the "Evaluate In Debug Console" context (using watch, a new one or ask the debuggee to add a prefix when executing this action (example: print)) in Editor's context menu and use "Debug Console" as debugger command console can be "sufficient".