update to support newer vscode debugadapter functions

[GitMensch]

Both the debug adapter protocol (DAP) and the vscode counterpart had different "updates" since this was created.
Things like inline values, set and query memory directly and possibly a lot more are on the table.

The question is: Are there plans to maintain this extension for the future and add those here? If yes it may help to do some planning and creating issues for every feature "missing", so people both know about the state (including "accepts PR", if this is the case) and about the possible changes of those.

[jonahgraham]

We are happy to accept PRs. Please feel free to create issues for features/PRs that you need. Please note that the DAP implementation itself is https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter - that creates the package that is consumed by numerous vendors to create their VS Code/ Theia plug-in.

As you may have noticed this project has a new home as of a few days ago (Eclipse CDT Cloud) and with that is a new purpose and existence. We are delighted to have you join in that effort.

One of the key items that is coming soon is #40 which will help the publishing process and getting it into CDT Cloud Blueprint (see eclipse-cdt-cloud/cdt-cloud-blueprint#9)

[GitMensch]

For now I won't join much other than some testing, when published via open-vsx on vscodium.

Did I understand it correctly that most issues that are currently created here should be tracked in the other repo? Or would issues be created in both places and the dap one be the blocker for adding it here?

[jonahgraham]

Testing is great! Thank you.

As for where to create issues, don't worry too much about which one you create it in. The separation between these two projects is an implementation detail that users shouldn't have to know about.

But here are details of it helps. If it is extension code it belongs here (ie code that runs in the vs code extension process). If it is adapter code it belongs in CDT-gdb-adapter (ie code runs in the debug adapter process). And you are correct, some items require both, so bugs/PRs in both required.

[jonahgraham]

There is no concrete activity to do on this issue. As and when specific items need to be done issues can be created for them.

[GitMensch]

Just to recheck without any testing: are inline values supported now?

[jonahgraham]

Just to recheck without any testing: are inline values supported now?

The short answer is yes, at least basic ones. I think with a language model installed too then it can place the variables better? Not really sure. With debug.inlineValues set to on (instead of default of auto) I can see nice inline values like this:

If there is more to do, please create an issue and we can look into it further.