-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement source lookup in Item Properties view #276
Implement source lookup in Item Properties view #276
Conversation
cell in ITEM PROPERTIES view. (Not moving to the associated line number yet, however).
@GregSavin thanks for the contribution. I missed this PR. I'll review it this week. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed that the source code is not formatted in the properties view. I notice that the CSS definition is not available in the vscode-trace-extension
that the theia-trace-extension
is using and defining .
Just add the following line to file vscode-trace-explorer-properties-widget.tsx
import 'traceviewer-react-components/style/trace-explorer.css'
@@ -68,7 +68,7 @@ class TraceExplorerProperties extends React.Component<{}, PropertiesViewState> { | |||
`${e.currentTarget.getAttribute('data-id')}` | |||
); | |||
console.log('filename: ' + fileLocation + ':' + line); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if we need to keep the console log.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I added the import for the CSS, and removed the console.log().
@@ -209,4 +210,9 @@ export class VsCodeMessageManager extends Messages.MessageManager { | |||
const data = JSON.stringify(payload); | |||
vscode.postMessage({ command: VSCODE_MESSAGES.CONTEXT_MENU_ITEM_CLICKED, data: data }); | |||
} | |||
|
|||
sourceLookup(path: string, line: number): void { | |||
const data = { path: path, line: line }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I troubleshooting a use case with the Trace Compass server and I noticed that the events table data provider for certain trace types will return a list of source in the form [file1:line1, file2:line2]. Even if it's only one file it will provide it with the brackets. I think when we did this prototype, there was only never the brackets. Anyways, I think for now it's ok to not support the list. I'll need to think about more how to support that better.
Is your format always file:line
or is it also [file:line]`, i.e. with brackets?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Our format is using file:line only (at least currently).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We support [file:line,file:line,...]
in tc for
1- SIMD
2- Heterogeonous snapshot events
3- Recycled trace points (bad practice)
4- Callstacks
5- User defined behaviour.
I would argue that file:line
is fine, until there's a demand for more. When that comes, @GregSavin I hope we can solve the issue together (i.e we don't want to break your work)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I think I've addressed the immediately actionable review comments. The fact that callstacks can carry source annotations (in a list form) is new to me. Going forward, I'll try to learn more about that specific case (how the data flow works for that), but for now, our only usage of "Source" attribute is as an aspect of our ITmfEvent subclass, and it's only file:line.
...e-extension/src/trace-explorer/properties/trace-explorer-properties-view-webview-provider.ts
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this, please address Bernd's comments first and consider this +1 the second review, I locally tested with codium
@@ -209,4 +210,9 @@ export class VsCodeMessageManager extends Messages.MessageManager { | |||
const data = JSON.stringify(payload); | |||
vscode.postMessage({ command: VSCODE_MESSAGES.CONTEXT_MENU_ITEM_CLICKED, data: data }); | |||
} | |||
|
|||
sourceLookup(path: string, line: number): void { | |||
const data = { path: path, line: line }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We support [file:line,file:line,...]
in tc for
1- SIMD
2- Heterogeonous snapshot events
3- Recycled trace points (bad practice)
4- Callstacks
5- User defined behaviour.
I would argue that file:line
is fine, until there's a demand for more. When that comes, @GregSavin I hope we can solve the issue together (i.e we don't want to break your work)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks good to me. Thanks. I'll squash the commits when merging it.
The intention of this patch is to achieve the following runtime behavior:
If a loaded trace has a "Source" column, and if the value of that column is of the form file:line, then highlighting the event in question, and clicking on the "Source" value that shows up in Item Properties shall open the corresponding file in a VSCode editor, and position the cursor on the corresponding line number, if said file exists.