Packaging the debugger as a VS Code extension

[arosien]

The biggest unknown I have after getting the barest Daffodil-DAP-VSCode pipeline flowing is how to package it into an extension. I'm currently running Daffodil as a separate process on a known port, and attaching VS Code to it in a fairly direct way.

The way it should work is different: you have the extension installed and are looking at a schema file, then you launch a parse of some data as a debugging session, and the extension fires up Daffodil in the background. (Or at least that's how I'm imagining it.) What do you think?

So we need some time to be spent to learn how extension packaging works. Need to decide on prioritizing this vs. other things.

[arosien]

I don't yet have any of prototype of the extension checked in, but I had followed the instructions at Debugger Extension, The Mock Debug Extension which uses the microsoft/vscode-mock-debug project.

The only change I've made to my local vscode-mock-debug is:

{
	// Use IntelliSense to learn about possible attributes.
	// Hover to view descriptions of existing attributes.
	// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
	"version": "0.2.0",
	"configurations": [
		{
			"type": "mock",
			"request": "launch",
			"name": "Debug test.md",
			"program": "${workspaceFolder}/test.md",
			"stopOnEntry": true,
			"trace": false,
+			"debugServer": 4711
		}
	]
}

To override the debugging session to talk to a locally running DAPodil that is listening on port 4711.

So to run the DAPodil debugger:

1. In the example-daffodil-debug repo, run ddb.debugger.dapodil.DAPodil.
2. In the vscode-mock-debug repo, open the "Run and Debug" sidebar, and launch the "Extension" configuration. This loads the extension in a new VS Code window.
3. Launch the debug session ("Debug test.md") from the new window.

[jw3]

The steps above got me up and running with DAPodil. Is incredible to see in action.

notes

• add the debugServer port line to the sampleWorkspace/launch.json file (which may be obvious to a vscode user)
• yarn install on ubuntu requires a little extra

[arosien]

FYI #15 tracks how our adapter receives the debug target from the extension.

[jw3]

Packaging experiments based on the mock plugin are going to be here https://github.com/jw3/example-daffodil-vscode

Same approach as this repo, initial experiments in there and then we will distill a clean first release for the Apache repo later.

[arosien]

@jw3, do you have any tasks or progress on the extension? No pressure, I just want to stay aware of anything you've done.

So far I've seen some Daffodil + DAPodil packaging, which I'm assuming is going to be used by the extension. I think #15 is probably the most critical on my end (passing schema and data file to DAPodil; it's currently hard-coded).

[jw3]

I wasn't looking at that this week, rather like you saw was heading down the road of getting extension and backend bundled, that was the packaging work.

re: #15, consider an approach like in 9844e3e, we can use program from the launch profile for both and split it. Manually editing the launch profile and using the joined string might be good enough until the vscode side is further down the line.

After copying the schema and data into the vscode workspace the launch profile program arg looks like

{
...
    "program": "${workspaceFolder}/jpeg.dfdl.xsd:${workspaceFolder}/works.jpg",
...
}

Otherwise, I wont be doing a dialog for entry any time soon, so if you want to impl that for #15 go ahead I wont mind. 😄

... After typing this up I thought why split a string, just add a data property to the launch profile and send two strings in the json. But after a quick look at that, vscode gives a "disallowed" warning because of the json schema check failing. Maybe it would still work, but since this post is all typed up and the commit is already pushed and working... Im not going to dig at it right now.

[arosien]

I'm surprised extra fields can't be sent along. I'll have to dig a little bit to see what other extensions do.

[arosien]

https://code.visualstudio.com/api/references/contribution-points#contributes.debuggers:

configurationAttributes is the schema for launch configuration arguments specific to this debugger. Please note that the JSON schema constructs $ref and definition are not supported.

So maybe additional required configuration attributes, like data?

[jw3]

Yep, that works.

Adding extra data property

              "data": {
                "type": "string",
                "description": "Absolute path to a data file.",
                "default": "${workspaceFolder}/${command:AskForProgramName}"
              },

then the launch profile

			"program": "${workspaceFolder}/jpeg.dfdl.xsd",
			"data": "${workspaceFolder}/works.jpg",

0a1ff4c

[jw3]

Pushed the changes to the launch profile over here https://github.com/jw3/example-daffodil-vscode/tree/dapodil/mock

[jw3]

Maybe rename program to schema though...

Eh, it requires a bit more modification, going to leave it as program for now, but make a note of that changing.

[arosien]

I'll update dapodil to expect program and data, thanks!