Debug session doesn't connect to launched backend

[arosien]

Fresh install of 0.0.14:

• Open jpeg.dfdl.xsd in VSCode, choose menu "Daffodil Debug: Debug File".
• Backend launches waiting for connection from extension. Nothing connects, backend exits after 10 seconds.

Will try to reproduce locally at the HEAD of the main branch.

[arosien]

Performing the same procedure locally and the extension pops up this error:

Activating extension 'jw3.daffodil-debug' failed: command 'extension.dfdl-debug.runEditorContents' already exists.

But I'm not sure this is what happens with 0.0.14, since the message seems like some extension interference condition.

[arosien]

"Manually" creating a launch configuration works as expected. Configuration used:

{
    "type": "dfdl",
    "request": "launch",
    "name": "dfdl",
    "program": "${command:AskForProgramName}",
    "stopOnEntry": true,
    "data": "${command:AskForDataName}",
    "infosetOutput": {
            "type": "console"
    },
    "debugServer": 4711
},

[jw3]

In the first instance did you have a launch.json present or not?

I cant recreate this, but not sure I have covered all the cases yet...

[jw3]

Did you get prompted to pick any files? When I launch (ctrl+p Debug: Start debugging) from the open xsd without a launch.json I get prompted for data file and then it proceeds to connect.

[arosien]

ctrl+p Debug: Start debugging)

This works for me. And now I can't reproduce what I'm seeing. GRRR.

[arosien]

Ok, now it consistently happens, and I have no idea why.

[arosien]

How can I debug this? Are there any logs?

When an xsd file is the currently open file, both "Debug: Start Debugging" and "Daffodil Debug: Debug File" immediately launch the backend, without asking for either a schema or data file.

[arosien]

Is there some kind of caching of the data file selection, @Shanedell or @jw3? I filed a bug #113 where if you cancel a dialog, the backend still launches, so if that caches a "bad" choice of data, that would explain this weird behavior.

[arosien]

What is this caching voodoo for? :D

// If prgramFile is not set do not prompt for dataFile
        const programFile = Buffer.from(
          await vscode.workspace.fs.readFile(
            vscode.Uri.parse(`${xdgAppPaths.data()}/.programFile`)
          )
        ).toString('utf8')

[jw3]

There was some caching of some sort @Shanedell would have to elaborate.

Could it be the cache should have been deleted due to some code updates? Did you try to delete that XDG dir?

[arosien]

I'm looking into this one...

[arosien]

This code executes:

      if (config.data.includes('${command:AskForDataName}')) {
        config.data = await vscode.commands.executeCommand(
          'extension.dfdl-debug.getDataName'
        )
      }

but sets config.data to ''.

No dialog appeared from the above code, however.

[arosien]

It is the caching thing being tripped:

➜  example-daffodil-vscode git:(master) ✗ ls -l /Users/arosien/Library/Application\ Support/dapodil/.programFile
-rw-r--r--  1 arosien  staff  0 Aug 27 11:44 /Users/arosien/Library/Application Support/dapodil/.programFile

Zero length file stops the debugging:

if (programFile === '') {
  stopDebugging()
  return ''
}

Now the question why that file exists and is zero-length.

[shanedell]

So I can update this the reason for the caching as it was the way so that if the user uses both ${command:AskForProgramName} and ${command:AskForDataName} that if they don't select a file for AskForProgramName that the debugger stops. However I did not catch that it breaks the Debug File and Run File so I am looking into how to make sure it is only happens on certain cases

[arosien]

@Shanedell i think i have the fix: getProgramName shouldn't save an empty program name in the cache. I'll post a PR.

[shanedell]

@arosien I think you may just need to remove these lines

// If prgramFile is not set do not prompt for dataFile
const programFile = Buffer.from(
  await vscode.workspace.fs.readFile(
     vscode.Uri.parse(`${xdgAppPaths.data()}/.programFile`)
    )
).toString('utf8')
if (programFile === '') {
  stopDebugging()
  return ''
}

Because the ${command:AskForProgramName} will stop the debugger if no file is selected so that check I put into getDataName is actually redundant I believe

[arosien]

Well, I need to think it through... :)

[shanedell]

@arosien Nevermind my previous comment it is needed as the stopDebugging on selecting a programFile does not actually cause a full stop

[arosien]

I think the real issue is that once the choice of program or data file is persisted, it doesn't get cleared. Now I'm not sure why it is persisted in the first place.

[shanedell]

@arosien So one thing I remember being a requirement was for the extension to not prompt for a dataFile if no programFile was selected, this was the purpose for the caching. So I we may want to put that back into that check (I can do it here in a sec) because as I was running yours it stills prompts me for a dataFile when I select nothing for a programFile. So I will just add some better checking into the caching to make sure the prior issues are resolved as well.

[arosien]

@arosien So one thing I remember being a requirement was for the extension to not prompt for a dataFile if no programFile was selected, this was the purpose for the caching. So I we may want to put that back into that check (I can do it here in a sec) because as I was running yours it stills prompts me for a dataFile when I select nothing for a programFile. So I will just add some better checking into the caching to make sure the prior issues are resolved as well.

That's very strange, I don't see how the code allows the data dialog to appear after an empty program is selected, but it does happen.

[arosien]

Ah, it's appears there's hooks in the debugger extension package.json that launch commands:

        "variables": {
          "AskForProgramName": "extension.dfdl-debug.getProgramName",
          "AskForDataName": "extension.dfdl-debug.getDataName"
        }

So perhaps our code shouldn't do this substitution "manually"?

[arosien]

Ah, it's appears there's hooks in the debugger extension package.json that launch commands:

        "variables": {
          "AskForProgramName": "extension.dfdl-debug.getProgramName",
          "AskForDataName": "extension.dfdl-debug.getDataName"
        }

So perhaps our code shouldn't do this substitution "manually"?

Oh, I'm guessing if this is used then the backend launches too soon while the dialogs are waiting to be filled in.

[shanedell]

Yeah them being inducted via package.json is why getDataName will still get execute so I am working on getting a good work around here.

[arosien]

Mutable data is evil.

[shanedell]

@arosien That fix you put in looks good going to merge it in here I just had to push up one commit for lint issues