You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
VSCode launch.json field observatoryUri should match DevTools name. #1642
Should be decided by a PM and needs corresponding fixes for Flutter Tool, VSCode and DevTools (if it changes from vm-uri).
When creating a configuration to attach to a running Flutter application the VM URI is called observatoryUri this will be confusing as DevTools is calling this vm-uri and Flutter tool will also be calling something else hopefully 'VM Uri'. We need to coordinate with Flutter too on a name.
DevTools CLI uses --vm-uri
Flutter tool calls it An Observatory debugger and profiler e.g.,
An Observatory debugger and profiler on AOSP on IA Emulator is available at: http://127.0.0.1:34637/OIt9yrpqmNE=/
Has there been any decision on this? Right now this URI in VS Code s the Observatory web app and not the VM service URI (we need to change the protocol and add /ws). If we renamed it to vmServiceUri then I think it would be better if we put the exactly VM Service URI there (ws://127.0.0.1:33933/aAqCdEkfG4A=/ws/). We can still support observatoryUri for compatibility, but I think it might get confusing to call the original link a "VM Service URI"?
Debug service listening on ws://127.0.0.1:56732/2Eg-vfZURVA=
I think we should refer to the URI as a 'debug service' url for text presented to users. For more technical areas (json files? source code? protocols?) I think that referring to it as the vmServiceUri / VM service URI (or similar) also makes sense.
While I'm updated references to Observatory, VS Code currently has a command Dart: Open Observatory that opens the web app (as scraped from stdout). Right now this is occasionally useful (though perhaps mostly only for me, often comparing its behaviour with things). Is it likely that web app will cease to exist anytime soon? Should I think about removing it?
In the next version of VS Code, things that referenced Observatory now generally say "VM Service" (there are a few that do not, for example the "Open Observatory" command remains, as that's still what it does).
For launch.json, observatoryUri will still work - but will give a warning that it's not supported (the fix is to change it to vmServiceUri).
Activity
terrylucas commentedon Feb 18, 2020
@jonahwilliams @csells
DanTup commentedon Feb 24, 2020
Has there been any decision on this? Right now this URI in VS Code s the Observatory web app and not the VM service URI (we need to change the protocol and add
/ws). If we renamed it tovmServiceUrithen I think it would be better if we put the exactly VM Service URI there (ws://127.0.0.1:33933/aAqCdEkfG4A=/ws/). We can still supportobservatoryUrifor compatibility, but I think it might get confusing to call the original link a "VM Service URI"?DanTup commentedon May 20, 2020
Ping! :-)
devoncarew commentedon May 20, 2020
For web apps, flutter tools prints to stdout:
I think we should refer to the URI as a
'debug service'url for text presented to users. For more technical areas (json files? source code? protocols?) I think that referring to it as thevmServiceUri/VM service URI(or similar) also makes sense.DanTup commentedon May 20, 2020
Thanks!
While I'm updated references to Observatory, VS Code currently has a command Dart: Open Observatory that opens the web app (as scraped from stdout). Right now this is occasionally useful (though perhaps mostly only for me, often comparing its behaviour with things). Is it likely that web app will cease to exist anytime soon? Should I think about removing it?
DanTup commentedon Jun 17, 2020
In the next version of VS Code, things that referenced Observatory now generally say "VM Service" (there are a few that do not, for example the "Open Observatory" command remains, as that's still what it does).
For launch.json,
observatoryUriwill still work - but will give a warning that it's not supported (the fix is to change it tovmServiceUri).