Debug Protocol vs Language Server Protocol

It is safe to say that the language server protocol (LSP) is the future of developer tools.  When it comes to the equivalent for debug, the debug protocol is ‘LSP for debuggers’. It is a useful tagline but here are three key differences to be aware of:

  1. State – the big mindshift with LSP is that servers are stateless. The clients store all the state e.g. the files themselves and settings (what language, classpath, etc). Any state kept on the serverside (e.g. the index) is usually purely for performance reasons. What this means is that, for instance, servers can be restarted and carry on seamlessly without having to know anything of what happened in the system beforehand. On the other hand, the debug protocol is not stateless, servers need to know all sorts of state and sequences of what has happened, so the design space is different for this protocol.
  2. JSON RPC 2.0 Spec (and cancellable requests) – The LSP defines JSON-RPC messages for requests, responses and notifications. The debug protocol was created before JSON RPC 2.0 spec was finalized, debug protocol uses a similar structure, but it is not cross compatible. For example, the JSON field name for the method to call is command in debug protocol and method in JSON RPC 2.0. The type of message (event, request, or response) is explicit in DSP in the type field, but is implicit in JSON RPC 2.0 (based on presence of the combination of method, id, result and error fields). However using a library like org.eclipse.lsp4j.jsonrpc can hide such differences and provide equivalent higher level abstractions (like Java interfaces) and leave the library to handle the differences. The LSP has a nice feature, cancellable requests, that is an extension to JSON RPC2.0 that is also not available in the debug protocol: https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md#-cancellation-support
  3. Ubiquity – although the LSP was defined originally for use in VS Code do you know that the 2 flagship languages for VS Code are not based on LSP? Typescript and javascript language tooling is not done using LSP. On the other hand the debug protocol does underpin all the debugger implementations in VS Code, including the flagship node debuggers for V8 and Chrome.

All that being said, it’s worth repeating the common benefits of both protocols which are:

  • good separation of client/server
  • building the tooling once and reusing it across IDEs and editors i.e. vs code, eclipse, atom, etc
  • better unit/isolated testing
  • write in language most suited to the job
  • more effective way for tool developers to keep pace with underlying tools

The language server protocol will revolutionize how you code

lsps

The next generation Spring Boot tooling has been completely refactored to be based on the language server protocol (LSP). The tooling covers things like code assist for the Spring Boot property file, support for Cloud Foundry manifest files as well as Spring Boot support for Java files with typical features such as validation, content-assist and quick-fixes.

Beyond IDEs

Continue reading “The language server protocol will revolutionize how you code”

The Future of Developer Tools for IoT, ThingMonk 2017

ThingMonk is an annual London conference that brings together the people building and shaping the Internet of Things. This year I spoke at the conference on ‘The Future of Developer Tools for IoT’. This talk looks at emerging and future trends in the developer tools space. Check out the slides and feedback from the audience, as well as reference links at the end. Plus thanks to Marcel Bruch & Codetrails for input on AI tools. Be sure to share your thoughts on how you see developer tools shaping up to scale for building the Internet of Things.

Continue reading “The Future of Developer Tools for IoT, ThingMonk 2017”

Be a 10X Developer! Write Parameterized Tests

Following on from Yannick’s previous post about the necessity of thorough testing we wanted to look at the subject from an alternative angle. Within the confines of Junit’s Parameterized Test it is possible to test multiple classes simultaneously – thus saving  time and effort – but as with every labour-saving device, the devil is in the detail at the front end of the task – how to create a test we can rely on that will also reduce our ongoing test maintenance burden? Kichwa Coders’ intern Pierre Sachot grapples with this problem in his latest blog detailing how he set about creating a Parameterized Test within the Eclipse January Project. Find out how he got on and let us know what you think in the comments below.

Context:

I was back on the January Eclipse project, more specifically on JUnit Tests. We needed to test two functions of the Maths.java: arctan2() function and abs() in order to calculate the absolute value of a Dataset. I worked more on the second function, and as those two functions were really similar we decided to create a Parameterized Test class to include the first function too. This is a test that could be applied to both series of code, with only variable changing. It can therefore be used to test a function with a lot of values to find the one which is failing, or in our case, on several class types.

Tests before using Parameterized Tests:

Continue reading “Be a 10X Developer! Write Parameterized Tests”

GDB’s MI is not a Debug Protocol

While looking to the future of debugger tooling, it is still important to consider the prior art and the solutions that have stood the test of time. For embedded development, gdb is high on that list, so it is worth considering if gdb’s interface could be the basis of a debug protocol.

If you’ve used gdb to debug C/C++ code then you are probably aware of MI, the machine interface layer used to communicate between the debugger backend and the IDE front end. MI is not only used by gdb but also adopted by lldb (the defacto debugger for Swift) and more recently by clrdbg (.NET Core). MI defines a rich set of functionality from standard debug run control and breakpoints up to advanced features for multi-process debug, reverse debugging and dynamic printf. With MI being pretty pervasive and supporting such rich functionality, it is tempting to think it might make the basis of a good debug protocol.  However in practice it lacks some of the qualities of a good protocol:

1. A Specification

We once had the opportunity to work on a project where the brief was to integrate into Eclipse IDE/CDT a custom debugger that ‘implemented the MI spec’. We can tell you we learnt the hard way that MI has plenty of useful documentation but no spec to speak of. This matters when you get into the nitty gritty of implementation details for example: what syntax should be used to notify when a bad condition has been created on a breakpoint?

The documentation does not necessarily reflect what the code does, some command or command variants have inconsistencies with the source code or don’t reflect platform dependent issues. For example, the -exec-step-instruction in practice takes an argument (e.g -exec-step-instruction 1)  even though this is not documented.

The main message here is documentation, even good documentation as in the case of gdb, is not the same as a protocol specification, so one can’t blindly implement to the docs (and if you think it’s just a case of looking at the code… well, which version?- see #4 below).

2. Clean Interfaces with no Idiosyncrasies

This piece of code from Visual Studio’s MIEngine demonstrates how rife MI is with idiosyncrasies. The code launches a debugger which will use MI to communicate i.e. to gdb, lldb or clrdbg. There are special cases for each tool that an IDE just shouldn’t need to know about:

  • Different ways of specifying a working directory depending on the tool
  • Environment variables are set differently: before launch for gdb/lldb after for clrdbg
  • Details of which Operating System the debugger is being run on

miengine

And this is even before you launch MI. In Eclipse CDT just after launching MI, the IDE has to know about and issue commands about all sorts of things e.g. ‘set print sevenbit-strings on’ c’mon, really, seriously?  Tom sums it up nicely:

It is an oddity that currently an MI consumer must check gdb’s host charset in order to know how to decode its output.

Once you get into actual debugging there’s a fair amount of ‘need-to-know’ for special cases & exceptions. A protocol needs to steer-clear of implementation details, but in the case of MI these have all too often leaked in.

3. Fit for Purpose

As MI was not specifically designed to be a protocol,  not suprisingly there are a few behaviour specific things that make it not fit to be a protocol. For example:

  • If your program prints to stdout, then that can corrupt the output stream of MI, breaking the instructions.
  • In some cases GDB responds twice from a single command. In such cases, for example Eclipse CDT has a special MIAsyncErrorProcessor class just to manage such cases.

4. Versioning

A good protocol has defined versions that clients and subscribers can adapt to.  With each new version of GDB,  MI has subtle differences that make client implementation long-winded and difficult to maintain. For example, in Eclipse CDT’s gdb debugger implementation (DSF) separate classes are created to manage differences in MI in different versions of gdb.  There are 5 different breakpoint classes, 7 different run control classes, etc And this is just gdb versions, let alone lldb or clrdb – imagine trying to implement wide-scale support for all those in a new IDE!

debug_versions

Conclusion

While feature-rich and ubiquitous, gdb’s MI is a reasonable syntax, but not a good debug protocol.  A good protocol needs much more than that – clean interfaces, fit for purpose, a spec & versioning – if it is really going to make common debugger implementations easier.