You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
VS Code version: N/A (using the debug adapter with vimspector
Extension version (available under the Extensions sidebar): 2018.12.1
OS and version: macOS Mojave (10.14.1)
Python version (& distribution if applicable, e.g. Anaconda): macOS system python
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): pyenv virtualenv
Relevant/affected Python packages and their versions: any
Expected behaviour
The debug adapter should adhere to the Debug Adapter Protocol. In particular:
It should not send multiple responses for the initialize request.
It should include the variablesReference field in all Varables messages.
Stack frame sources must have a name.
Evaluations must have a string result
The previous version worked fine with vimspector.
Actual behaviour
The debug adapter returns multiple responses to the initialise request. Conforming debug adapter protocol clients choke on this. I suppose the specification doesn't state explicitly that this is a breach, but it seems reasonable to only reply once to a single request.
The variablesReference key is not always included in evaluate and variables responses. The specification lists it as mandatory.
The name key is not always supplied in the Source type returned from the server. The protocol states "Every source returned from the debug adapter has a name"
The 'result' entry in evaluate requests is returned as 'null'. There is no provision in the specification for it to be null
I realise this is unusual (most users will be using VSCode), and I can work around all of these issues in vimspector, but the key power of DAP is client independence.
Relying on VSCode de facto behaviours makes it difficult to build and maintain independent clients.
The text was updated successfully, but these errors were encountered:
Thanks for the info, but ptvsd by itself doesn't implement the Debug Adapter Protocol and our debug adapter in the extension isn't designed to be run externally. If you want to submit a PR to us or Microsoft/ptvsd then we would be happy to review it.
Environment data
Expected behaviour
The debug adapter should adhere to the Debug Adapter Protocol. In particular:
variablesReference
field in allVarables
messages.name
.The previous version worked fine with vimspector.
Actual behaviour
variablesReference
key is not always included inevaluate
andvariables
responses. The specification lists it as mandatory.name
key is not always supplied in theSource
type returned from the server. The protocol states "Every source returned from the debug adapter has a name"null
Logs
Duplicate response
Missing 'variablesReference' in 'evaluate' response
In reality the problem here is that
request_id
in this context, does exist,but that's not a protocol violation.
Missing 'variablesReference' in 'variables' response
See the 2nd entry in
variables
. This item is not expandable, so should havevariablesReference
set to0
, not omitted.null result in 'evaluate' response
Missing 'name' in 'Source' under 'StackFrame'
I realise this is unusual (most users will be using VSCode), and I can work around all of these issues in vimspector, but the key power of DAP is client independence.
Relying on VSCode de facto behaviours makes it difficult to build and maintain independent clients.
The text was updated successfully, but these errors were encountered: