-
Notifications
You must be signed in to change notification settings - Fork 28.7k
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
Initial built-in variables view #198468
Initial built-in variables view #198468
Conversation
d5d2456
to
18a0104
Compare
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.
Looks good, we may want to add the proposed api check later.
@@ -207,6 +208,14 @@ export class ExtHostNotebookKernels implements ExtHostNotebookKernelsShape { | |||
data.supportsInterrupt = Boolean(value); | |||
_update(); | |||
}, | |||
set variableProvider(value) { |
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 may want to validate proposed api usage.
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.
Nice!
if (token.isCancellationRequested) { | ||
return; | ||
} | ||
this._proxy.$receiveVariable(requestId, variable); |
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.
If you're just going to pull all the variables here, then it seems like you could just return the variables from this call directly rather than send them over one by one?
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.
This could stream them into the renderer process asynchronously.
Would there still a purpose to using an asyncIterable in the API if they just are gathered up at once in the EH anyway?
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 suppose it would make sense to send them all at once if I'm going to stick with the non-async tree type - I wasn't really settled on that yet.
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 figured that getting the next variable from the call wouldn't typically be slow, so if there are 10 variables they are going to basically appear all at once anyway, but that you could implement something like paging with this, eg you pull the first 10 variables out of here, display those, and pull more out later if needed. And also for the large array paging thing. This is fine for now of course.
readonly value: string; | ||
} | ||
|
||
export class NotebookVariablesTree extends WorkbenchObjectTree<INotebookVariableElement> { } |
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.
No reason to subclass it, I think
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.
oh yeah, made more sense for the Async one with three arguments.
I'll make some follow-up changes, just so I can make sure to get the bulk of this in |
for #166296
Base implementation of displaying variables from a
VariableProvider
on theNotebookController
. Only displays the root variables at this point, and doesn't listen to the update event (it just pulls for every execution end event)