7 ms·

Debug Adapter Protocol

71 points by mmastrac 7y ago

NikkiA 7y ago
And VSCode moves a step closer to being 'Emacs, now written in Javascript'
- 0xTJ 7y ago
  I use VS Code as my main IDE for both business and pleasure, but I have to mistrust just how developer-friendly Microsoft has been. VS Code is a great, extendable, developer-friendly tool. WSL has made it so that it's less of a shame that I'm stuck using Windows for now. Even CMD has been getting updates that makes it behave more like a POSIX shell.
  - heavenlyblue 7y ago
    Microsoft had always been developer-friendly. They just haven't been friendly much towards developers outside their ecosystem, as soon as they have monopolised the given ecosystem.
- oaiey 7y ago
  Without knowing too much about emacs (vi user.. just kidding), but I imagine the interface is either a proprietary C interface or a Unix Domain Socket with an Language Server behind it. Both do not scale up to the needs of today (Windows support, Remote Support, solving the n x m problem, ...).
- pdpi 7y ago
  Nothing of the sort. We can discuss how Emacs and VSCode compare to each other (and we can discuss the advantages and disadvantages of VSCode taking the electron approach until we're blue in the face), but VSCode is definitely not trying to compete with Emacs, rather aiming for a very different user base. However, this article isn't even about VS Code proper. It's about Debug Adapter Protocol. If DAP achieves the same adoption as LSP, this will be a huge move forward in developer tooling across all sorts of tech stacks and domains. In between LSP and DAP, just about any editor is capable of becoming a lightweight IDE for an enormous variety of languages, and this is a Good Thing for everybody.
- zellyn 7y ago
  As a long-time Emacs user, I think you're not totally wrong. The thing is, it's the idea of Emacs that's important; you could argue that Emacs itself is an antiquated and idiosyncratic implementation of that idea. I'm fine with parallel attempts at programmable editors; seems like a win.
breatheoften 7y ago
How does this relate to and interact with the chrome devtools protocol? The chrome devtools protocol is really quite amazing to me as it provides an extremely thorough and powerful way to “get visibility into and external control over” a “process” — or what I think could very well become the most meaningful abstraction of a process for most application development in near future. Obviously cdp only applies to the communication mechanisms relevant to control a browser — i guess what I’m musing about is wanting to Suss out - is there anything that will be lost (dx feature support, performance) if one attempts to implement ide features but using debug adapter protocol to adapt CDP? Is CDP one of the target integrations that debug adapter protocol will aim to support? I think CDP is ridiculously important and likely to become more so ...
xvilka 7y ago
Hopefully, not UTF-16 this time, like LSP. Everywhere[1] but in Windows UTF-8 is being used. And it should be. So many LSP implentations recode UTF-16 to UTF-8 and vice versa. [1] http://utf8everywhere.org/ http://utf8everywhere.org/
- wolfgke 7y ago
  > Everywhere[1] but in Windows UTF-8 is being used. Further popular counterexamples besides the NT kernel (cf. [2]): - Java - JavaScript - .NET - Qt - Joilet file system (for CD-ROMs) [1] http://utf8everywhere.org/ http://utf8everywhere.org/ [2] https://en.wikipedia.org/w/index.php?title=UTF-16&oldid=909417171#Usage https://en.wikipedia.org/w/index.php?title=UTF-16&oldid=9094...
  - new_realist 7y ago
    All decisions made 20 years ago. The future is UTF-8.
    - naikrovek 7y ago
      honestly the future is probably UTF-32. just make all code points 32-bits and use the 11 bits that Unicode says it will never use for flags so things like formatting can be encoded per character.
      - targonca 7y ago
        That's... a very bad idea. First of all, there's graphemes are inherently not one-to-one with code points, e.g. Á = A + `. There's simply no Unicode encoding that will let you safely index into an array without paying attention to the meaning of the underlying codepoints. (and no, using NFC won't solve this either, because there are combinations for which there's no composed equivalent) Secondly, general formatting info won't fit into 11 bits (italic, bold, underline, strikethrough - that's already 4 bits, and we haven't talked about color, font weights other than bold, etc.), so why bother baking in a limited, intentionally gimped version into your character encoding?
lpcvoid 7y ago
Good idea, but why JSON? And why HTTP content headers? I much prefer binary protocols, but I'm probably within a minority on that one.
- MrBuddyCasino 7y ago
  Yeah I can see this being a bottleneck for inspecting large arrays. Maybe they‘ll add more transports over time.
  - royjacobs 7y ago
    Indeed, there's no reason this can't be extended in the future (and indeed content negiotated through regular HTTP).
  - naikrovek 7y ago
    It uses JSON-RPC which isn't held to a specific transport that I'm aware of. Currently in VSCode if you use a language server for Go, it launches the language server and appears to simply pipe data in and out using STDIN and STDOUT. That should be pretty fast if there isn't a cmd.exe somewhere in the mix. There's a lot of talk about fast C++ JSON libraries and how they can parse 1GB of JSON per second, and that's a lot of data, for sure, if you only count the data that's wrapped up in JSON. 1GB of JSON data contains a lot of waste that is not even usable data, and that's before you consider the textual encoding of what may better be represented by binary data, which inflates the size of a JSON file even further than the JSON syntax itself does. A binary file that is read at 1GB per second would contain far, far more actual data, and binary files can be read and written much more quickly than 1GB/s. I'm really starting to lose patience with all the JSON and web technologies that are finding their way into non-web use cases. using binary formats and simple programs to handle them is really, truly, easier to rationalize about, easier to maintain, easier to write, and easier to replace when the time comes.
    - rmetzler 7y ago
      Sorry, this is for debugging. How much state are you planning to transfer in a debugging session?
Normal_gaussian 7y ago
I'm aware that MS has been implementing all kinds of layers of abstraction when building features for VSCode, but I'm not aware (through my own ignorance) of anything else using these abstracted layers - which makes it hard to work out whether this is fluff or cool. Has anyone used some of their abstractions elsewhere? How good are these protocols they are pumping out?
- naikrovek 7y ago
  They have to start somewhere, I guess. I believe I saw some non-VSCode editors in the list of implementations.
- est31 7y ago
  LSP at least is implemented by lots of languages as well as lots of editors. There are long tables on the website: https://langserver.org/ https://langserver.org/ Adoption wise, I'd say it's a success. As for how good the protocol is, I'd personally have preferred something binary instead of json.
  - Entalpi 7y ago
    Been using it in Emacs with both Rust (rls) and C/C++ (clangd). It is glorious. I hope more people rally behind both DAP and LSP.
    - lazyguy 7y ago
      Recently switched away from Anaconda to Pyls for Python editing on Spacemacs. Documentation can be found: http://develop.spacemacs.org/layers/+lang/python/README.html http://develop.spacemacs.org/layers/+lang/python/README.html Seems to work fine. Functionally it seems the same, maybe a bit faster. Haven't used it a whole lot. Really tempted to try out the Microsoft PLS just so that I can say that I am using Microsoft in Emacs. Which is pretty close to being technically correct. Brave new world. Nowadays if I was forced to give up my Linux desktop and choose between Windows and OS X for work... Windows 100% of the time. Because I can then use WSL and get Linux nicely integrated into the base OS. Especially since Macbook Pros are not that nice anymore.
brandmeyer 7y ago
How does this compare to The Other Leading Brand: the GDB Server protocol?
smg 7y ago
DAP is already improving the debugging experience in other editors. Check out DAP-mode for Emacs https://github.com/emacs-lsp/dap-mode https://github.com/emacs-lsp/dap-mode
chrsw 7y ago
For many years now the acronym "DAP" has been used as the name of the debug interface for ARM based SoCs. Embedded software development with Visual Studio Code is already a thing and will likely become more popular. This can be a little confusing.

71 points by mmastrac 7y ago

NikkiA 7y ago

And VSCode moves a step closer to being 'Emacs, now written in Javascript'

0xTJ 7y ago
I use VS Code as my main IDE for both business and pleasure, but I have to mistrust just how developer-friendly Microsoft has been. VS Code is a great, extendable, developer-friendly tool. WSL has made it so that it's less of a shame that I'm stuck using Windows for now. Even CMD has been getting updates that makes it behave more like a POSIX shell.
- heavenlyblue 7y ago
  Microsoft had always been developer-friendly. They just haven't been friendly much towards developers outside their ecosystem, as soon as they have monopolised the given ecosystem.
oaiey 7y ago
Without knowing too much about emacs (vi user.. just kidding), but I imagine the interface is either a proprietary C interface or a Unix Domain Socket with an Language Server behind it. Both do not scale up to the needs of today (Windows support, Remote Support, solving the n x m problem, ...).
pdpi 7y ago
Nothing of the sort. We can discuss how Emacs and VSCode compare to each other (and we can discuss the advantages and disadvantages of VSCode taking the electron approach until we're blue in the face), but VSCode is definitely not trying to compete with Emacs, rather aiming for a very different user base. However, this article isn't even about VS Code proper. It's about Debug Adapter Protocol. If DAP achieves the same adoption as LSP, this will be a huge move forward in developer tooling across all sorts of tech stacks and domains. In between LSP and DAP, just about any editor is capable of becoming a lightweight IDE for an enormous variety of languages, and this is a Good Thing for everybody.
zellyn 7y ago
As a long-time Emacs user, I think you're not totally wrong. The thing is, it's the idea of Emacs that's important; you could argue that Emacs itself is an antiquated and idiosyncratic implementation of that idea. I'm fine with parallel attempts at programmable editors; seems like a win.

breatheoften 7y ago

How does this relate to and interact with the chrome devtools protocol? The chrome devtools protocol is really quite amazing to me as it provides an extremely thorough and powerful way to “get visibility into and external control over” a “process” — or what I think could very well become the most meaningful abstraction of a process for most application development in near future. Obviously cdp only applies to the communication mechanisms relevant to control a browser — i guess what I’m musing about is wanting to Suss out - is there anything that will be lost (dx feature support, performance) if one attempts to implement ide features but using debug adapter protocol to adapt CDP? Is CDP one of the target integrations that debug adapter protocol will aim to support? I think CDP is ridiculously important and likely to become more so ...

xvilka 7y ago

Hopefully, not UTF-16 this time, like LSP. Everywhere[1] but in Windows UTF-8 is being used. And it should be. So many LSP implentations recode UTF-16 to UTF-8 and vice versa. [1] http://utf8everywhere.org/ http://utf8everywhere.org/

wolfgke 7y ago
> Everywhere[1] but in Windows UTF-8 is being used. Further popular counterexamples besides the NT kernel (cf. [2]): - Java - JavaScript - .NET - Qt - Joilet file system (for CD-ROMs) [1] http://utf8everywhere.org/ http://utf8everywhere.org/ [2] https://en.wikipedia.org/w/index.php?title=UTF-16&oldid=909417171#Usage https://en.wikipedia.org/w/index.php?title=UTF-16&oldid=9094...
- new_realist 7y ago
  All decisions made 20 years ago. The future is UTF-8.
  - naikrovek 7y ago
    honestly the future is probably UTF-32. just make all code points 32-bits and use the 11 bits that Unicode says it will never use for flags so things like formatting can be encoded per character.
    - targonca 7y ago
      That's... a very bad idea. First of all, there's graphemes are inherently not one-to-one with code points, e.g. Á = A + `. There's simply no Unicode encoding that will let you safely index into an array without paying attention to the meaning of the underlying codepoints. (and no, using NFC won't solve this either, because there are combinations for which there's no composed equivalent) Secondly, general formatting info won't fit into 11 bits (italic, bold, underline, strikethrough - that's already 4 bits, and we haven't talked about color, font weights other than bold, etc.), so why bother baking in a limited, intentionally gimped version into your character encoding?

lpcvoid 7y ago

Good idea, but why JSON? And why HTTP content headers? I much prefer binary protocols, but I'm probably within a minority on that one.

MrBuddyCasino 7y ago
Yeah I can see this being a bottleneck for inspecting large arrays. Maybe they‘ll add more transports over time.
- royjacobs 7y ago
  Indeed, there's no reason this can't be extended in the future (and indeed content negiotated through regular HTTP).
- naikrovek 7y ago
  It uses JSON-RPC which isn't held to a specific transport that I'm aware of. Currently in VSCode if you use a language server for Go, it launches the language server and appears to simply pipe data in and out using STDIN and STDOUT. That should be pretty fast if there isn't a cmd.exe somewhere in the mix. There's a lot of talk about fast C++ JSON libraries and how they can parse 1GB of JSON per second, and that's a lot of data, for sure, if you only count the data that's wrapped up in JSON. 1GB of JSON data contains a lot of waste that is not even usable data, and that's before you consider the textual encoding of what may better be represented by binary data, which inflates the size of a JSON file even further than the JSON syntax itself does. A binary file that is read at 1GB per second would contain far, far more actual data, and binary files can be read and written much more quickly than 1GB/s. I'm really starting to lose patience with all the JSON and web technologies that are finding their way into non-web use cases. using binary formats and simple programs to handle them is really, truly, easier to rationalize about, easier to maintain, easier to write, and easier to replace when the time comes.
  - rmetzler 7y ago
    Sorry, this is for debugging. How much state are you planning to transfer in a debugging session?

Normal_gaussian 7y ago

I'm aware that MS has been implementing all kinds of layers of abstraction when building features for VSCode, but I'm not aware (through my own ignorance) of anything else using these abstracted layers - which makes it hard to work out whether this is fluff or cool. Has anyone used some of their abstractions elsewhere? How good are these protocols they are pumping out?

naikrovek 7y ago
They have to start somewhere, I guess. I believe I saw some non-VSCode editors in the list of implementations.
est31 7y ago
LSP at least is implemented by lots of languages as well as lots of editors. There are long tables on the website: https://langserver.org/ https://langserver.org/ Adoption wise, I'd say it's a success. As for how good the protocol is, I'd personally have preferred something binary instead of json.
- Entalpi 7y ago
  Been using it in Emacs with both Rust (rls) and C/C++ (clangd). It is glorious. I hope more people rally behind both DAP and LSP.
  - lazyguy 7y ago
    Recently switched away from Anaconda to Pyls for Python editing on Spacemacs. Documentation can be found: http://develop.spacemacs.org/layers/+lang/python/README.html http://develop.spacemacs.org/layers/+lang/python/README.html Seems to work fine. Functionally it seems the same, maybe a bit faster. Haven't used it a whole lot. Really tempted to try out the Microsoft PLS just so that I can say that I am using Microsoft in Emacs. Which is pretty close to being technically correct. Brave new world. Nowadays if I was forced to give up my Linux desktop and choose between Windows and OS X for work... Windows 100% of the time. Because I can then use WSL and get Linux nicely integrated into the base OS. Especially since Macbook Pros are not that nice anymore.

brandmeyer 7y ago

How does this compare to The Other Leading Brand: the GDB Server protocol?

smg 7y ago

DAP is already improving the debugging experience in other editors. Check out DAP-mode for Emacs https://github.com/emacs-lsp/dap-mode https://github.com/emacs-lsp/dap-mode

chrsw 7y ago

For many years now the acronym "DAP" has been used as the name of the debug interface for ARM based SoCs. Embedded software development with Visual Studio Code is already a thing and will likely become more popular. This can be a little confusing.