Data editor: add profile source target selection

[Ontiomacer]

Closes #1563

Description

This PR adds support for profiling different data targets in the Data Editor, allowing users to choose between profiling:

• the current in-memory (unapplied) editor buffer, or
• the on-disk data.

This resolves cases where profiling previously ignored unapplied edits and aligns the profiler behavior with user expectations.

Wiki

• I have determined that no documentation updates are needed for these changes

Review Instructions

1. Open the Data Editor
2. Navigate to the Data Metrics / Profiler panel
3. Select a profiling target (Editor or Disk)
4. Modify data in the editor without applying changes
5. Run profiling and verify the selected target is respected

Confirmation Testing

• Manually tested profiling with unapplied editor changes
• Verified on-disk profiling continues to behave as before

Regression Testing

• Existing profiling functionality verified with no UI regressions observed

[stricklandrbls]

Firstly, could you update the PR description w/ documentation updates, if any. This is required and runs against a CI job to verify. Take a look at some other PRs and the PR template for how it is formatted w/ markdown.

Secondly, the TS/Svelte formatting needs to be resolved. There is a script in the package.json that does this.

I will test out the functionality for this PR when I get a chance sometime today.

[Ontiomacer]

Thanks for the feedback.

I’ve updated the PR description to explicitly cover documentation requirements per the template.

I’m also running the project’s formatting script and will amend the commit if it introduces any changes. I did not attempt to resolve unrelated pre-existing Svelte check warnings outside the scope of this PR.

Let me know if you’d like me to address any specific formatting issues beyond that.

[Ontiomacer]

Hey @stricklandrbls,
just checking back in on this PR.

You’d mentioned earlier that you were also working around this area and that we could tackle it together, so I wanted to see if you’ve had a chance to try out the changes on your end. From my side, the target selection behaves as expected, but I’d really value your take on whether the approach and wiring look correct or if anything should be adjusted.

Also, if there are other issues in the daffodil-vscode repo where help would be useful right now, feel free to point me in that direction — happy to pick up more work.

Thanks, and no rush at all. Just wanted to make sure I’m aligned and well updated

[Ontiomacer]

Also lastly @stricklandrbls i hope the changes you requested me to do are aligned properly in my pr description or is there something left ??

[rthomas320]

Thanks for the feedback.
I’ve updated the PR description to explicitly cover documentation requirements per the template.
I’m also running the project’s formatting script and will amend the commit if it introduces any changes. I did not attempt to resolve unrelated pre-existing Svelte check warnings outside the scope of this PR.
Let me know if you’d like me to address any specific formatting issues beyond that.

The Svelte Formatting check is still failing in CI.

The CI log file for that check shows:

[lrbarber]

You're adding a feature that requires a user to make a selection (where they previously did not), but state that no documentation needs to be updated?
The wiki section on Data Profiler almost certainly needs a new screen shot of this step with a short blurb about what the differences are between the two options.

[JeremyYao]

@Ontiomacer, would you like me to assist you with passing the lint tests?

[Ontiomacer]

Hey collaborators @rthomas320 @lrbarber @JeremyYao I am working on this and I'll update this pr soon

[Ontiomacer]

Hey @JeremyYao
I tracked the failing CI formatting job down to svelte-check, not Prettier.

Locally:

yarn prettier src -c → passes

yarn prettier . -c → passes

yarn svelte-check → fails
The failure is:
node_modules/svelte/elements.d.ts
Error: Cannot find name 'ContentVisibilityAutoStateChangeEvent'
This error originates inside node_modules/svelte, not from any project file or changes in this PR.

This looks like a dependency/toolchain mismatch between svelte, svelte-check, and the TS DOM lib used by CI. Happy to help fix it, but it seems orthogonal to the feature changes here. Please advise how you’d like me to proceed.

[Ontiomacer]

@lrbarber
I’m happy to update the Data Profiler documentation, though I’m not fully familiar yet with the preferred structure and level of detail for the wiki. I’ll review the existing Data Profiler section and add a concise blurb plus a screenshot describing Editor vs Disk profiling.

If there’s a specific wiki page or format you’d like me to follow, please let me know — otherwise I’ll mirror the existing style and keep the update minimal and focused.
As if now @lrbarber i have left it unchecked

[Ontiomacer]

@JeremyYao
your help would be much appreciated. I’m working through the CI formatting issue and the documentation update, and any guidance you can share would be great.

[shanedell]

@Ontiomacer All you should need to do is run the below command locally:

yarn lint:fix

This should auto format any files that are causing lint issues. After that you should just need to commit the updated files.

[Ontiomacer]

I force-pushed to clean up the branch history and retrigger CI.
Could a @shanedell please approve the workflows so CI can run on the updated commits?
also all the lint:fix commands are executed

[JeremyYao]

I force-pushed to clean up the branch history and retrigger CI. Could a @shanedell please approve the workflows so CI can run on the updated commits? also all the lint:fix commands are executed

Approved workflows to run

[Ontiomacer]

Ok @JeremyYao i see the sqash commit error and a documentation error to ci I will fix the squash commit error shortly what should I do for documentation error?

[JeremyYao]

Ok @JeremyYao i see the sqash commit error and a documentation error to ci I will fix the squash commit error shortly what should I do for documentation error?

The documentation error checks to see if the checkbox for determining if documentation for the PR should be added. Given that this is an enhancement (addition to the extension), I suggest re-adding the I have determined that documentation updates are needed for these changes checkbox back in and editing https://github.com/apache/daffodil-vscode/wiki/Apache-Daffodil%E2%84%A2-Extension-for-Visual-Studio-Code:-v1.6.0-%E2%80%90-In-Development to describe the new functionality the PR adds. Once https://github.com/apache/daffodil-vscode/wiki/Apache-Daffodil%E2%84%A2-Extension-for-Visual-Studio-Code:-v1.6.0-%E2%80%90-In-Development is edited to contain the information, you can check the checkbox for I have determined that documentation updates are needed for these changes.

[stricklandrbls]

@Ontiomacer - I apologize for the radio silence recently, I have been tied up in a ton of other things plus the holidays.

I'm going to checkout this branch and look at the functionality. If I see any issues I'll bring them up. If not then once the CI errors are fixed I will approve.

[stricklandrbls]

I would remove the ... tail of the message. The status message indicates as if the profiler is currently loading something.

[stricklandrbls]

Given that this variable instance type is used in multiple places it should be extracted to a concrete type definition:

type ProfileTarget = 'editor' | 'disk'

Then change the appropriate variable's types:

  let lastProfileTarget: ProfileTarget | undefined = undefined
  let lastRequestedTarget: ProfileTarget = 'editor'

[stricklandrbls]

Create a data object above this postMessage call and deconstruct it into the data property:

  type ProfileMsg = {
    startOffset: number,
    length: number,
    target: ProfileTarget
  }

...

const profileTargetData: ProfileMsg = {
 startOffset,
 length,
 target: profileTarget === 'disk' ? 'disk' : 'editor'
}

vscode.postMessage({
...
   data: {...profileTarget}
}

I'm also unsure as to why the target would be set to undefined if the target was 'editor' since there's only 2 requestable types.

[stricklandrbls]

Calling the createSession API function is emitting the following error from Omega Edit server:

rejected promise not handled within 1 second: createSession error: 13 INTERNAL: Failed to create session: ALREADY_EXISTS

I don't currently have a resolution off the top of my head so you may have to read up on the exposed API functions to work around this.