Implement the vm service protocol for the dart debugger

[jakemac53]

TODO: list all the required methods (maybe @vsmenon?)

[jakemac53]

• getVM
• getIsolate
• callServiceExtension
• getVersion
• getScripts
• getObject
• streamListen
• addBreakpoint
• removeBreakpoint
• callMethod
• getStack
• invoke
• resume
• setExceptionPauseMode
• pause

[DanTup]

Some things VS Code currently uses that I don't think are covered above:

• setLibraryDebuggable
• evaluate
• evaluteInFrame

[jakemac53]

Ya, evaluate is probably deserving of its own issue entirely. We have an extremely rudimentary version now that just evals the expression as JS within the correct library scope (which was enough to unblock the inspector).

True support like a debugger needs will be a lot more involved though.

[jakemac53]

Also - do you have any sense of how often you will be running evals? (for instance with a watch window this could get quite nasty I presume?)

[DanTup]

do you have any sense of how often you will be running evals?

Yeah, it (evaluateInFrame) is used by the watch window, the debug console (where the use can type expressions), and I think also when the user hovers over symbols in the editor (it just occurs to me that VS Code myst have some heuristics to device what expression under the mouse to send for evaluation, since I'm pretty sure we don't help it out here).

There was talk about potentially providing batch support for this, since it can be slow for Dart use too (in VS Code we have an option to execute all getters when you're examining an object, and currently that's an evaluate for each one). It's possible that some of VS Code's use of evaluate could be moved over to invoke (for ex. we use evaluate to just call toString() in some places for sure) so if there will likely be a perf difference between them, I'll move over what I can.

[DanTup]

Oh also, we use evaluateInFrame for conditional breakpoints and log points too. Both essentially just set breakpoints, then when they're hit we evaluate the expression/print and then immediately resume. This means conditional breakpoints/logpoints slow things down quite considerably (even before accounting for the evaluation). I think users tend to understand that though, and I don't think people use them that much.

[jakemac53]

I think for the watch window case at least caching should be able to save us to some degree - we can cache the compiled JS by expression/library, presumably the watch window is sending the exact same call repeatedly?

[DanTup]

As you step it will, yeah - I was thinking more about the having 15 watch variables, that it sends 15 requests (or if any are expanded objects or arrays, potentially more) sequentially.

[jakemac53]

Ah ya - maybe we can resolve that case with some sort of batching mechanism.

In general its going to be very difficult to provide a good experience I think though.

I do wonder if we want some sort of special compiler mode for this..? Knowing absolutely nothing about ddc it seems like you could maybe do a "dumb" compile that doesn't require info about dependencies and uses all dynamic calls. Maybe that is a terrible idea or totally impossible idk, cc @jmesserly @nshahan @Markzipan for input :).

[DanTup]

Yeah, we've talked about batching elsewhere (possibly with @bkonyi?), but I don't think anything has been started yet.

I don't know the details, but I think Flutter mobile has a compiler service that handles evaluate requests (I think the on-device VM can't evaluate them so it sends them back to Flutter tools over a VM service to compile?). I'm not sure it helps you at all, though I think @aam worked on it so he may be able to explain it better if it sounds relevant.

[bkonyi]

Yes, we have plans to support batching for certain operations like evaluate and invoke, but I'm not sure what those will look like yet. Should be something I can get to soon though.

[alan-knight]

For a lot of uses it's possible to fake a batch evaluate by doing a single evaluate that returns a batch of things. But real support would be nice.

We have some code for doing evaluation internally, but it needs to be adapted for a different build system, module system, etc., and will probably come after things like breakpoint support.

[jmesserly]

I do wonder if we want some sort of special compiler mode for this..? Knowing absolutely nothing about ddc it seems like you could maybe do a "dumb" compile that doesn't require info about dependencies and uses all dynamic calls.

yeah Alan and I have brainstormed this.

There's a few different approaches we could take:

Approach 1: compile the expression, defining all names as dynamic variables. For example:

// console/watch expression the user typed:
foo.bar.baz + qux

becomes:

// Note, we simply pass in all identifier-like names. If they weren't actually in the
// JS scope, we'll pass in an object with nSM that throws an appropriate error.
//
// We don't even need to parse the expression at all--false positives are fine.
evaluate(foo, bar, baz, qux) => foo.bar.baz + qux;

One problem with that is class names and library prefixes:

// Foo and Bar.baz are constructors, qux is a library prefix in scope:
Foo() + Bar.baz() + qux.f()

We could solve that by passing in wrapper objects, that understand how to call constructors (via nSM, or internal magic in DDC's dynamic dispatch) or lookup members in libraries. But that still doesn't work in all cases:

// Oops, now "Bar" needs to be a type available at compile time.
Foo<Bar>()

Another problem is mutation:

// attempt to set the "foo" variable/field/setter
foo = bar.baz

For that to work, we'll need to use getters/setters instead of parameters:

import 'special_repl_magic.dart' show scope;
// read/write against the current scope.
// may call getters/setters depending on what these names refer to
get foo => scope['foo'];
set foo(x) => scope['foo'] = x;
get bar => scope['bar'];
set bar(x) => scope['bar'] = x;
get baz => scope['baz'];
set baz(x) => scope['baz'] = x;

evaluate() => foo = bar.baz;

---

Approach 2: parse and evaluate the expression directly, rather than using the compiler.

Since we're using dynamic dispatch, we're already relying on most operations being interpreted at run time. If we do a real Dart parse of the expression, we could reliably perform lookups against the currently active scope. As a result, type arguments would work as expected. This would also make it much easier to declare and mutate local variables in the console (typically, this is accomplished by giving the console its own scope in the scope chain).

The benefit here is we can implement any features that users need; there's no upper limit. Responsiveness should be better too, in most cases.

With either approach, we'll be much worse if the user pastes a complex "for" loop that does local computation inside the REPL (without relying on already-compiled functions). The current approach, which uses the compiler and static types, would be superior for that use case. However, I believe that use case is very uncommon.

Another issue is type inference:

// list is statically dynamic, but actually a List<int>
list.map((x) => x + 42).toList()

With approach 1, that will produce a List<dynamic>. Approach 2 will give the same result, unless we implement some type inference in the interpreter (note: this isn't quite as bad as it sounds; DDC's runtime already has some type inference code ported from CFE. It's used to provide better error messages.)

Personally I think List<dynamic> is an acceptable result. An easy workaround is list.map((int x) => x + 42).toList()

---

As to which approach is better: I think option 2 is better in the long run, but option 1 is very appealing in the short term. The first approach is quite close to what we're doing now, but it lets watch expressions work regardless of context they're evaluated in.

So my recommendation is to implement Option 1, and consider option 2 down the road if needed.

Interested to hear everyone's thoughts on this. :)