observatory docs

77 views
Skip to first unread message

Devon Carew

unread,
Jul 7, 2015, 10:03:50 AM7/7/15
to observato...@dartlang.org
I looked over the service protocol docs - is it only documenting the public part of the API? About how much of the API is public and how much private, and what parts of the private API do you see stabilizing in the near future?

I think I remember that the observatory gave access to the stdout / stderr streams for applications being debugged but I don't see that in the service protocol doc - I assume that's part of the private APIs currently?


--
Devon Carew
Software Engineer
Google, Inc.

John Mccutchan

unread,
Jul 7, 2015, 10:09:33 AM7/7/15
to Devon Carew, observato...@dartlang.org
On Tue, Jul 7, 2015 at 7:03 AM 'Devon Carew' via Dart VM Observatory Discuss <observato...@dartlang.org> wrote:
I looked over the service protocol docs - is it only documenting the public part of the API?

Yes. The private API is not documented.
 
About how much of the API is public and how much private, and what parts of the private API do you see stabilizing in the near future?


Most of the API is private. We haven't decided what will become public next or when. It will likely be driven by feedback from users of the service protocol. What features do you need?

I think I remember that the observatory gave access to the stdout / stderr streams for applications being debugged but I don't see that in the service protocol doc - I assume that's part of the private APIs currently?


This is not implemented today. Todd is working on this, I'm not sure when he expects to have this complete or whether or not the RPCs will be public.

John

Todd Turnidge

unread,
Jul 7, 2015, 4:31:53 PM7/7/15
to John Mccutchan, Devon Carew, observato...@dartlang.org
As John says, I'm about to start working on stdout/stderr right now.  We have the api support for getting a named stream and I need to figure out how to do the plumbing.

We pushed a lot of very useful apis into the private api before coming out with the draft spec.  If you need to use bits of the private api, let us know and we will work to polish them and make them public.

Todd

--
You received this message because you are subscribed to the Google Groups "Dart VM Observatory Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to observatory-dis...@dartlang.org.

Devon Carew

unread,
Jul 7, 2015, 4:43:20 PM7/7/15
to Todd Turnidge, John Mccutchan, observato...@dartlang.org
Most of the API is private. We haven't decided what will become public next or when. It will likely be driven by feedback from users of the service protocol. What features do you need?

I could see the stdout/stderr streams being useful, esp. for situations where you did not launch the process being debugged.

As John says, I'm about to start working on stdout/stderr right now.  We have the api support for getting a named stream and I need to figure out how to do the plumbing.

We pushed a lot of very useful apis into the private api before coming out with the draft spec.  If you need to use bits of the private api, let us know and we will work to polish them and make them public.

What's the best way to get a sense of the APIs that are currently private? Is there another doc or file in the repo to look at?

It'd be great to have visibility into the private-but-available APIs in that service.md doc. There'd be fewer places to look for API docs (and people using that file for code gen would be able to try the private APIs out easily). Of course, documenting the private APIs may mean people have higher expectations of them being available going forward.


Todd

On Tue, Jul 7, 2015 at 7:09 AM, 'John Mccutchan' via Dart VM Observatory Discuss <observato...@dartlang.org> wrote:


On Tue, Jul 7, 2015 at 7:03 AM 'Devon Carew' via Dart VM Observatory Discuss <observato...@dartlang.org> wrote:
I looked over the service protocol docs - is it only documenting the public part of the API?

Yes. The private API is not documented.
 
About how much of the API is public and how much private, and what parts of the private API do you see stabilizing in the near future?


Most of the API is private. We haven't decided what will become public next or when. It will likely be driven by feedback from users of the service protocol. What features do you need?

I think I remember that the observatory gave access to the stdout / stderr streams for applications being debugged but I don't see that in the service protocol doc - I assume that's part of the private APIs currently?


This is not implemented today. Todd is working on this, I'm not sure when he expects to have this complete or whether or not the RPCs will be public.

John

--
You received this message because you are subscribed to the Google Groups "Dart VM Observatory Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to observatory-dis...@dartlang.org.

John Mccutchan

unread,
Jul 7, 2015, 4:52:20 PM7/7/15
to Devon Carew, Todd Turnidge, observato...@dartlang.org
Hi,

I do not want us to include private RPCs in the service.md doc. The audience is limited and it is a big burden on the three of us to keep it documented. The good news is, these private RPCs are documented in code. See runtime/vm/service.cc:2754 (service_methods_). Each RPC's name and parameters are documented in a fairly obvious way. For example the "_getCpuProfile" method:

static const char* tags_enum_names[] = {
  "None",
  "UserVM",
  "UserOnly",
  "VMUser",
  "VMOnly",
  NULL,
};

static Profile::TagOrder tags_enum_values[] = {
  Profile::kNoTags,
  Profile::kUserVM,
  Profile::kUser,
  Profile::kVMUser,
  Profile::kVM,
  Profile::kNoTags,  // Default value.
};

static const MethodParameter* get_cpu_profile_params[] = {
  ISOLATE_PARAMETER,
  new EnumParameter("tags", true, tags_enum_names),
  NULL,
};

John
Reply all
Reply to author
Forward
0 new messages