I'm not actually sure what step over means vs. step in/out, in the context of parsing using the schema. Would step over mean to break at the next point where the stack is the same depth?

Need to at least sketch an approach to testing in and get it running in CI.

I get a functional hex view, but no highlighting or arrow.

I do see the .arrow.svg under the dapodil xdg data dir ~/.local/share/dapodil/.arrow.svg.

Scala & Extension in harmony

We use the built-in XML language currently, which allows the DFDL XSD to be debugged, but also applies to other XML, like an infoset file.

Adding a DFDL extension should give ability to express schemas more precisely and will also support editing and other needs.

If the data property in launch json is set to a directory prompt the user to pick a file and start browsing at that directory.

When the bytePos1b ("byte position 1's-based") is reported, it is interpreted incorrectly in the view: the view selects row n instead of byte n, where a row is 16 bytes in the current view.

After the hex view is closed it should be able to be opened without restarting the debug.

I frequently see error codes returned in the UI. If the backend fails to start for any reason is one example where you will see the return code from that process.

It would be good to wrap points such as these and provide descriptive strings for know errors, and provide as helpful wrapper as possible for others.

v0.0.2

1. Start debug session
2. When prompted for version enter a version that will need downloaded
3. Wait for plugin to download
4. The version prompt will appear again

The apache/daffodil project does not publish GitHub releases. It looks like some Apache projects do, some don't. Something to think about is how we can query releases elsewhere. Does Apache have an API?

I posted to dev asking about it.

We have been using the GitHub API to collect (representative) releases of
Daffodil during some prototype work. However when looking at the main
Daffodil repo I see there are no releases published there.

There are probably some other ways to work around this, but the simplest is
to ask if publishing releases to GitHub is something that can be done going
forward?

The extension correctly launches the DAPodil process, but if "debugServer": 4711 is missing then VS Code runs the markdown debugger that it built into the mock extension that the Daffodil extension is based on.

Using this config,

    {
      "type": "dfdl",
      "request": "launch",
      "name": "Daffodil: jpeg.dfdl.xsd/works.jpg",
      "program": "${workspaceFolder}/src/main/resources/jpeg.dfdl.xsd",
      "data": "${workspaceFolder}/src/main/resources/works.jpg",
      "stopOnEntry": true
    }

you can see the Daffodil debugger launched, listening on 4711, but then the mock markdown "debugger" starts:

I'm not sure what's needed to address this, but I imagine there are defaults that might be set in the extension. But it's also very important to remove the markdown mock debugger from the codebase.

Additionally, when in this state the DAPodil process can't be killed by closing the VS Code terminal, it requires an external kill -9. It correctly closes when the debug session actually connects to the forked backend.

We wont always want to kill the existing sever, such as when doing development work between DAPodil and the extension.

Can probably keep this simple and just say if a flag is set skip the version prompt, download, kill, etc.

We will need the 3.1.0 release published to the Daffodil page to complete the 0.1.0 release.

To share with the users mailing list, put on the Daffodil wiki, publish as a separate blog post, etc.

Demonstrate adding a new view which is a read-only text display.

We expose & relay the current data position for a given stack frame (bytePos1b), but we should collect other positions that can be related so the view can show highlighted regions, etc. Points of uncertainty? Delimiter info? We should ask the mailing list about these.

The legacy interactive debugger shows the region between the previous step's position and the current one, if I'm reading the code correctly.

Tag -> GH Release

Remove bits that we are not using or that no longer apply.

• unused files (eg. travis and appveyor)
• text references to markdown
• config references to markdown

I upgraded the extension from 0.0.6 to 0.0.7 and can't seem to launch a debug session. I get a popup that says:

Configured debug type 'dfdl' is not supported.

My launch config is:

{
      "type": "dfdl",
      "request": "launch",
      "name": "Daffodil: jpeg.dfdl.xsd/works.jpg",
      "program": "${workspaceFolder}/src/main/resources/jpeg.dfdl.xsd",
      "data": "${workspaceFolder}/src/main/resources/works.jpg",
      "stopOnEntry": true,
      "debugServer": 4711
},

"infosetOutput": {
  "type": "console" | "none" | "file"
  "path": <path to output for type file>
}

jw3/example-daffodil-debug#30

Add a view that accepts a diff event and displays the content.

Steps to reproduce

1. Install Daffodil extension v0.0.7
2. Create an empty workspace
3. Open "Run and Debug" pane on the leftbar
4. Click "Run and Debug" button
   

What happened

At this point I was prompted for the debugger version with the dropdown but not for a data file. The debugger started and the log confirmed with an error message that no data file was sent.

What I expected to happen

After picking the debugger version I would also pick a data file.

Steps to reproduce

1. Install Daffodil extension v0.0.7
2. Create an empty workspace
3. Open "Run and Debug" pane on the leftbar
4. Click the "create a launch.json file" link
   

What happened

The launch.json created from the "Run and Debug" pane does not contain all fields required by the extension.

It shows a validation warning about the generated launch config

What I expected to happen

That the launch.json would contain all required fields and be ready to launch. It is confusing to see the validation warning, even though it works if you ignore the warning and run.

Suggestions

Instead of using the unset data property to prompt for the file we allow the property to be either a file path or a flag like prompt-for-file? Or perhaps more idiomatic would be to add another VS Code command that can be set by default that works like ${workspaceFolder}/${command:AskForProgramName}.

This would provide a more explicit default profile and also would would help custom profiles created by users to be more understandable.

Function that will roll together a schema and data sample into a TDML file.

This will be useful when submitting questions or bugs to the community.

Typing in a version each time is tiring.

1. Start debugging without a version specified in the launch.json
2. When prompted to select a version, click somewhere outside of the dropdown
3. Observe that the backend continue to launch

The same behavior can be observed if pressing Esc instead of clicking outside the box.

I would expect that if I click somewhere other than in the drop down that the operation would not progress further.

Is there a pattern in VS Code to create a launch configuration for a file. Eg. right click on a schema, select debug, and if a launch config doesn't exist for that schema one is created from a template for the launch?

It doesn't appear that breakpoints are setting on a schema.

Steps to recreate issue

1. Start debugging
2. Step, observe the hex view opening
3. Close the hex view
4. Step, hex view reopens

Expected behavior

If user closes the hex view it should stay closed until they explicitly reopen it.

What "view" means here is still undefined in 0.1.0. Keeping in mind the scope here and that we want to deliver an MVP, this could be limited to a simple text view or it could be the more full featured hex viewer.

This post is interesting #7 (comment)

Keeping downloads in the project dir is not ideal, but was nice for a quick turn on this. For a 0.1 we need to investigate a portable solution to this problem.

In Rust there is https://github.com/dirs-dev/dirs-rs which says

The library provides the location of these directories by leveraging the mechanisms defined by

• the XDG base directory and the XDG user directory specifications on Linux and Redox
• the Known Folder API on Windows
• the Standard Directories guidelines on macOS

The extension should support sending Daffodil CLI commands directly to the backend for evaluation.

This provides a bridge functionality for things we will not yet support by may be needed by schema developers.

When I install the extension (version 0.0.6), I don't yet know how to start a debug session. I guessed that I need to make a launch configuration, so I added

    {
      "type": "dfdl",
      "request": "launch",
      "name": "Ask for file name",
      "program": "${workspaceFolder}/src/main/resources/jpeg.dfdl.xsd",
      "data": "${workspaceFolder}/src/main/resources/works.jpg",
      "stopOnEntry": true
    }

When I run this from VS Code, I choose (backend) version 0.0.6, an error flashes in the Terminal, but then the Terminal exits before I can read what happened. I can't find the error message in any of the Output buffers, so I'm a bit stuck.

There's some launch problem, but then the (fake) markdown debugger starts from the default code in the mock extension. Oh noes!

I installed v0.4 of the extension locally, and used the provided launch.json:

...
{
  "type": "dfdl",
  "request": "launch",
  "name": "Debug JPEG",
  "program": "${workspaceFolder}/jpeg.dfdl.xsd",
  "data": "${workspaceFolder}/works.jpg",
  "stopOnEntry": true,
  "trace": false,
  "debugServer": 4711
}

At the Daffodil version prompt I enter 3.1.0 but then I get a popup error dialog that says

Unexpected HTTP response: 404

I can't find any other output. Any ideas?

Can we provide a drop down list of available versions, or some other way to avoid the free text input?

Spawned from #16

v0.0.2

1. Start debug
2. Enter a version that needs downloaded
3. Wait for download
4. Enter same version (see #9)
5. Run debug ... end debug
6. Start new debug
7. Enter a new version that will need downloaded
8. Get error

> Executing task: ./daffodil-debugger-0.0.3/bin/da-podil <

/bin/bash: ./daffodil-debugger-0.0.3/bin/da-podil: No such file or directory
The terminal process "/bin/bash '-c', './daffodil-debugger-0.0.3/bin/da-podil'" failed to launch (exit code: 127).

Press any key to close the terminal.

When prompted to select a data file or schema it is not clear what you are selecting.

A title on the file picker dialog would do a lot by just saying

• "Select a DFDL schema file to debug"
• "Select an input data file to debug"

or something similar.

Doesnt seem to attempt the download.

> Executing task: ./daffodil-debugger-0.0.4/bin/da-podil <

/bin/bash: ./daffodil-debugger-0.0.4/bin/da-podil: No such file or directory
The terminal process "/bin/bash '-c', './daffodil-debugger-0.0.4/bin/da-podil'" failed to launch (exit code: 127).

Press any key to close the terminal.

Ability to obtain dump of current infoset at any point during the parse.

Don't prefixed user specified version with a "v", user should enter the exact version string.

Currently get a 404 when an invalid version is entered.

Determine the correct way to include a user defined snippets file into the extension. This file can include useful syntactic shortcuts that reduce tedious boilerplate entry while also reducing the chance of syntactic errors across many common patterns.

https://code.visualstudio.com/docs/editor/userdefinedsnippets

I would expect the hex view to be cleaned up after closing the debug session. It is not cleaned up and even returns after workspace restart.

Steps to reproduce

1. start a debug, hex view displayed
2. close ide
3. open ide
4. hex view is displayed

• GIF how-to images
• clean up things that dont apply

Start working through the issues associated to publishing.

Won't associate anything to official daffodil for now.

Automate publishing in #25