I've issued a pull request [1] with quicktype-generated Debug Adapter Protocol pmod containing domain objects, along with serializing/deserializing subroutines. It leaves a lot to be desired, but it's something we can move the work on for now.
One of the problems with this specification is the fact that it's delivered as a JSON Schema. AFAIK Schema's purpose is to validate JSONs - not to represent a JSON structure. For example, this specification is attempting to represent inheritance relation with an `allOf` keyword, while Schema reference explicitly states that `allOf` is not meant to represent such relation. I've also encountered some problems with an absurd amount of generated enums, so I had to hack QuickType's Pike renderer a little. More details in the commit's doc/worklog.md.

Notice that the problem is within how QuickType handles this schema, and it's not related specifically to Pike's renderer.

I'm really concerned about poor serialization and deserialization performance of the generated implementation. We'll see in practice how big a problem it is.
One way would be to gradually refactor the generated implementation manually, and taking into account that it's almost 7k lines long, it might take some time.

[1] https://github.com/pikelang/Pike/pull/22

śr., 2 sty 2019 o 23:25 Mateusz Krawczuk <krawczukmat@gmail.com> napisał(a):

Ah! Right, sorry, my bad, actually the specification is a JSON schema and can be found here: https://github.com/Microsoft/debug-adapter-protocol/blob/gh-pages/debugAdapterProtocol.json

śr., 2 sty 2019, 20:23: H. William Welliver III <william@welliver.org> napisał(a):
I started looking at the JSON-RPC code before the holidays, I will put what I have in a repository somewhere... it's not a lot of code, as the spec is pretty simple. Note that this won't be helpful for DAP, as it doesn't use JSON-RPC (though LSP does).

I think (but am not 100% sure), that the definitive specifications for DAP is expressed via a JSON schema... my guess is that a TypeScript converter would probably be a good bit of work, unless the changes required would be very minimal, though I haven't really thought too much about it. TypeScript is certainly what Microsoft uses for a lot of their tooling, but I'm not sure if that code is considered the original specification or just a reference implementation.

I will try to dig out the Java parser code. I did spend a day or two looking at it, but there were two problems: 1) there is some dependency on Eclipse editor classes and b) an older version of the parser and lexer libraries is fairly old. I tried to tackle both of the problems at once and it ended up being a bit of a mess.

There's a LR parser module in Pike, but I haven't looked at whether it could be used with a version of the pike language syntax to generate the kinds of data we need.

January 2, 2019 12:04 PM, "Mateusz Krawczuk" <krawczukmat@gmail.com> wrote:

I've started a separate thread for QuickType support in Pike. But now I'm thinking perhaps it would be even better to have some kind of TypeScript -> Pike class transformer, since both DAP and LSP JSON-RPC message specifications are in TypeScript. Does anyone know any tools that might be able to do it?

Bill, can you please share the Pike language parser plugin for Eclipse, along with the JSON-RPC implementation you mentioned? Might turn out handy.