Skip to content
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

Support "inspect()" method from "dart:developer" library #2137

Closed
shroudedcode opened this issue Nov 29, 2019 · 9 comments
Closed

Support "inspect()" method from "dart:developer" library #2137

shroudedcode opened this issue Nov 29, 2019 · 9 comments
Labels
in debugger Relates to the debug adapter or process of launching a debug session is enhancement
Milestone

Comments

@shroudedcode
Copy link

The dart:developer library has an inspect(Object object) method with the following description:

Send a reference to object to any attached debuggers.
Debuggers may open an inspector on the object. Returns the argument.

Dart Code currently doesn't do anything when inspect is called, so I was wondering if adding support for it has ever been considered. Here's how I would imagine this feature to work:

  • Dart Code detects that inspect was called.
  • The matching value inside of the "Variables" panel is resolved.
  • The "Variables" panel is expanded and the resolved value is highlighted.

Is this doable? If it is, I'd be happy to make a pull request. I might need a little heads up on where to start though.

@DanTup
Copy link
Member

DanTup commented Dec 2, 2019

I don't think there are any APIs in VS Code that would let us interact with the Variables pane in that way. Normally VS Code will call us whenever the code pauses and ask for the data that should be listed there, but it doesn't let us push to it, nor control things like expansion or focus.

We are already somewhat handling this event - it's how we navigate to widget code as you're clicking on items in the Flutter inspector (eg. in DevTools).

@devoncarew @jacob314 should we do more with this event here (eg. for non-widgets)? I can't tell from the IntelliJ handler whether it's doing anything more here.

@shroudedcode what's the use case you have in mind? Maybe there's another way we can achieve it (do logpoints help?).

@jacob314
Copy link

jacob314 commented Dec 2, 2019

We aren't doing anything more along those lines in IntelliJ today as far as I know.

@shroudedcode
Copy link
Author

What's the use case you have in mind?

I was looking for a way to quickly jump to a deeply nested object in the "Variables" panel and discovered the inspect() method while looking at the dart:developer docs. I thought it would be the perfect solution and was disappointed to find that it didn't work with Dart Code's debugger.

Maybe there's another way we can achieve it (do logpoints help?).

Yeah, calling inspect() is certainly not the only way to inspect the piece of data I was looking for. I only opened this issue because I felt like Dart Code should support inspect() because one might expect that it does after reading through the dart:developer docs. If VS Code doesn't have an API for focusing elements in the "Variables" panels, there's not really anything that can be done about this though.

@DanTup
Copy link
Member

DanTup commented Dec 3, 2019

I was looking for a way to quickly jump to a deeply nested object in the "Variables" panel

Even with the VS Code API, I'm not sure this would be feasible - there could be several (or zero) variables in the list that have references to your object many levels deep and I'm not sure how you could find them without traversing the tree (which would be very slow, and there may be side-effects if you execute all of the getters as your search).

I wonder if we could dump the object to the debug console, would that be useful? For example here, I'm at a breakpoint and I typed home into the debug console to have it evaluated. The response is an object you can expand/collapse to see it's fields:

Screenshot 2019-12-03 at 11 13 18 am

It might be possible that we could make inspect(home) behave the same way that typing home into there. If we did, we probably wouldn't want to do it for every item you click in the Widget Inspector though (which I think also fires the same event). @jacob314 @devoncarew what do you think? If we can differentiate widget inspector inspect events from those from user code, does this seem like a reasonable use of inspect()? (the docs are a bit vague so it's not clear if users should use it in this way - if not, we should probably make that clearer).

@DanTup DanTup modified the milestones: v3.8.0, On Deck Dec 3, 2019
@DanTup DanTup added the in debugger Relates to the debug adapter or process of launching a debug session label Dec 3, 2019
@shroudedcode
Copy link
Author

I wonder if we could dump the object to the debug console, would that be useful?

Absolutely! I even think that this would be a better solution and it perfectly fits the definition of open an inspector on the object in my opinion since it's more than just a static "string log". I also think the debug console should be opened automatically (and maybe scrolled to the bottom) to satisfy the open part of the definition and make it more obvious where the output is shown.

@ajain-bst
Copy link

Screenshot 2020-09-08 at 8 28 58 PM

Judt upgraded flutter. I sometimes get <evalError>:<collected> when I inspect something. Sometimes it does work, and I am able to expand the inspected object. Any idea what it means?

@DanTup
Copy link
Member

DanTup commented Sep 8, 2020

@ajain-bst I've responded over in #2780. Thanks!

@danielchan303
Copy link

It will be great if the vscode logpoints can have this feature, instead of outputting the string, can output the expandable object.

@DanTup
Copy link
Member

DanTup commented Jan 4, 2023

@danielchan303 please file a new issue about this. I think it would be a nice feature, although I'm not sure how well it would work without VS code having some way to choose whether a logpoint is intended as a message versus an expression whose result should be inspected. Perhaps if the data is a single expression with no prefix/suffix ({foo}) and the expression evaluates to something that is not a simple string/number/etc. then we could do this (and if you only wanted the string representation you could just add a prefix/suffix: foo: {foo}).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in debugger Relates to the debug adapter or process of launching a debug session is enhancement
Projects
None yet
Development

No branches or pull requests

5 participants