@Lycan-Thrope
you bring me a new feature to try and work into the package
I’m sooorrrryyy :D
get up to speed on this DAP and
In short, it is essentially a “standard” for how an application should communicate with a debugger.
The communication itself takes place via JSON with a header section and is transmitted either via stdio or TCP.
Each side can send a request, which must be answered by the other side with a response, and in addition,
both sides can send events, which are simply pieces of information that do not require a response.
It looks like this
Content-Length: 139
{"seq":29,"type":"event","event":"stopped","body":{"allThreadsStopped":true,"hitBreakpointIds":[1],"reason":"breakpoint","threadId":13008}}
Content-Length: 46
{"command":"threads","type":"request","seq":9}
Content-Length: 180
{"seq":30,"type":"response","request_seq":9,"success":true,"command":"threads","body":{"threads":[{"id":10932,"name":"2: tid=10932 \"\""},{"id":13008,"name":"1: tid=13008 \"\""}]}}
Content-Length: 47
So, to make your dbase debugger dap-compatible, you need to wrap it in this layer and interpret it:
In the previous example, the client asks: Which threads are currently running?
And the dbase adapter would then have to convert this into dbase debugger commands and return the result wrapped in JSON.
Of course, not all debuggers can support every feature, which is where capabilities come into play.
Before the actual debugging begins, the client and the debug-adapter exchange information about what each is capable of,
and only the appropriate requests should be used thereafter.
along with all the IRL chores I have to get done this season
Those are exactly the things that keep holding me back.
I have no idea who came up with them, but… can’t we just fire that person?
I mean, obviously I’m not the only one this affects. :-D
