The gen_protocol_ml*.js scripts die with assertion failures

[richardlford]

Using the latest protocol file referenced in the top-level dune file:

https://raw.githubusercontent.com/microsoft/debug-adapter-protocol/gh-pages/debugAdapterProtocol.json

The gen_protocol_ml*.js scripts die with assertion failures. I have partially debugged the failures and one source of the problem new

        "StartDebuggingRequestArguments": {
            "type": "object",
            "description": "Arguments for `startDebugging` request.",
            "properties": {
                "configuration": {
                    "type": "object",
                    "additionalProperties": true,
                    "description": "Arguments passed to the new debug session. The arguments must only contain properties understood by the `launch` or `attach` requests of the debug adapter and they must not contain any client-specific properties (e.g. `type`) or client-specific features (e.g. substitutable 'variables')."
                },
                "request": {
                    "type": "string",
                    "enum": [
                        "launch",
                        "attach"
                    ],
                    "description": "Indicates whether the new debug session should be started with a `launch` or `attach` request."
                }
            },
            "required": [
                "configuration",
                "request"
            ]
        },

which contains a

                    "additionalProperties": true,

The current code does not expect additionalProperties to have a boolean value, though that is allowed by the JSON Scheme spec.

There may be additional reasons for failures but that is the only cause I've identified so far.

The assertion failure is on line 190 of gen_protocol_ml.js or line 195 of gen_protocol_mli.js.

[richardlford]

@hackwaly, any plans to fix this? Also, do you plan to update earlybird for the latest OCaml?

[hackwaly]

No, I have not enough time to maintain earlybird anymore in the comming year(s?).

[hackwaly]

@hackwaly, any plans to fix this? Also, do you plan to update earlybird for the latest OCaml?

https://github.com/hackwaly/ocaml-dap/commit/fe2825a9ea31a3c7d27b394c9dd79695c756f9a0#r99353286

There's a wip commit. There's a tough thing to do. I have no time to continue.

[richardlford]

No, I have not enough time to maintain earlybird anymore in the comming year(s?).

@hackwaly, I'm sorry to hear that. I had heard that earlybird was accepted as an OCaml Software Foundation project. Are there any candidates to take over this work? Do you know of any funding available to work on it? I found it very nice and a great improvement over bare use of ocamldebug.

[richardlford]

@hackwaly, any plans to fix this? Also, do you plan to update earlybird for the latest OCaml?

fe2825a#r99353286

There's a wip commit. There's a tough thing to do. I have no time to continue.

@hackwaly, Thanks. I will look at it. Can you give a hint about the "tough thing to do"? Is there anyone that will be taking over the ocaml-dap work?

[hackwaly]

@hackwaly, any plans to fix this? Also, do you plan to update earlybird for the latest OCaml?

fe2825a#r99353286 There's a wip commit. There's a tough thing to do. I have no time to continue.

@hackwaly, Thanks. I will look at it. Can you give a hint about the "tough thing to do"? Is there anyone that will be taking over the ocaml-dap work?

You can see the comment in the linked page.

No, I have not enough time to maintain earlybird anymore in the comming year(s?).

@hackwaly, I'm sorry to hear that. I had heard that earlybird was accepted as an OCaml Software Foundation project. Are there any candidates to take over this work? Do you know of any funding available to work on it? I found it very nice and a great improvement over bare use of ocamldebug.

AFAIK. No one will take over this work at this time. But improving debugging experience is an important thing for OCaml Software Foundation. They may have some plan on that.