Remove dart:_vmservice and dart:vmservice_io from platform.dill.

Remove dart:_vmservice and dart:vmservice_io from platform.dill.

A mirrors test which now passes has been removed from the blacklist.

R=asiva@google.com

Committed: https://github.com/dart-lang/sdk/commit/a879f91420b4b1838950fe9482a02ed9b32f429d

[sivachandra, 2017-06-09 21:48:42]

sivachandra@google.com changed reviewers:
+ asiva@google.com

[sivachandra, 2017-06-09 21:48:43]

As discussed offline, this is the first step of the goal towards loading the
service isolate from kernel. I will follow up with a CL to add a script which
generates vmservice_io.dill.

[siva, 2017-06-09 22:54:50]

https://codereview.chromium.org/2931193002/diff/1/tools/patch_sdk.dart
File tools/patch_sdk.dart (right):

https://codereview.chromium.org/2931193002/diff/1/tools/patch_sdk.dart#newcod...
tools/patch_sdk.dart:204: locations["_vmservice"] = "vmservice/vmservice.dart";
Do we still need to copy the vmservice_io.dart, loader.dart and server.dart etc.
to the patched_sdk folder and add their locations to the map?

[sivachandra, 2017-06-12 20:39:43]

https://codereview.chromium.org/2931193002/diff/1/tools/patch_sdk.dart
File tools/patch_sdk.dart (right):

https://codereview.chromium.org/2931193002/diff/1/tools/patch_sdk.dart#newcod...
tools/patch_sdk.dart:204: locations["_vmservice"] = "vmservice/vmservice.dart";
On 2017/06/09 22:54:50, siva wrote:
> Do we still need to copy the vmservice_io.dart, loader.dart and server.dart
etc.
> to the patched_sdk folder and add their locations to the map?

I think what you are saying is that, if the vmservice related scripts are not
going to be part of platform.dill anymore, then we do not need to copy them over
to the patched_sdk; One could potentially compile them directly from the source
tree. Is this correct?

My understanding is that, since we are compiling a "dart:*" library, the only
way currently is to trick the fasta compiler into thinking that
dart:vmservice_io is part of "platform". So, to do this trick, we copy the
vmservice_io related files over to patched_sdk. That way, the compiler can
resolve dart:vmservice_io when it sees it in patched_sdk.

[siva, 2017-06-13 02:15:43]

LGTM but can we file an issue  to track this issue of having to trick the front
end into thinking that vmservice_io belongs in platform and hence needs to be
copied into the patched_sdk. This may not work if the front end team resolves
issue #29835 and compiles using platform.dill which will not have vmservice_io
in it.

[sivachandra, 2017-06-13 16:14:04]

On 2017/06/13 02:15:43, siva wrote:
> LGTM but can we file an issue  to track this issue of having to trick the
front
> end into thinking that vmservice_io belongs in platform and hence needs to be
> copied into the patched_sdk. This may not work if the front end team resolves
> issue #29835 and compiles using platform.dill which will not have vmservice_io
> in it.

We already have https://github.com/dart-lang/sdk/issues/29818. I am not sure I
understand the exact problem you are hinting at, but we could add to this issue
I suppose?

[sivachandra, 2017-06-13 20:35:48]

Description was changed from

==========
Remove dart:_vmservice and dart:vmservice_io from platform.dill.
==========

to

==========
Remove dart:_vmservice and dart:vmservice_io from platform.dill.

A mirrors test which now passes has been removed from the blacklist.
==========

[sivachandra, 2017-06-13 20:49:43]

Description was changed from

==========
Remove dart:_vmservice and dart:vmservice_io from platform.dill.

A mirrors test which now passes has been removed from the blacklist.
==========

to

==========
Remove dart:_vmservice and dart:vmservice_io from platform.dill.

A mirrors test which now passes has been removed from the blacklist.

R=asiva@google.com

Committed:
https://github.com/dart-lang/sdk/commit/a879f91420b4b1838950fe9482a02ed9b32f429d
==========

[sivachandra, 2017-06-13 20:49:44]

Committed patchset #2 (id:20001) manually as
a879f91420b4b1838950fe9482a02ed9b32f429d (presubmit successful).

[Siggi Cherem (dart-lang), 2017-06-13 23:58:04]

sigmund@google.com changed reviewers:
+ sigmund@google.com

[Siggi Cherem (dart-lang), 2017-06-13 23:58:05]

lgtm

[Siggi Cherem (dart-lang), 2017-06-14 00:12:39]

https://codereview.chromium.org/2931193002/diff/1/tools/patch_sdk.dart
File tools/patch_sdk.dart (right):

https://codereview.chromium.org/2931193002/diff/1/tools/patch_sdk.dart#newcod...
tools/patch_sdk.dart:204: locations["_vmservice"] = "vmservice/vmservice.dart";
On 2017/06/12 20:39:43, sivachandra wrote:
> On 2017/06/09 22:54:50, siva wrote:
> > Do we still need to copy the vmservice_io.dart, loader.dart and server.dart
> etc.
> > to the patched_sdk folder and add their locations to the map?
> 
> I think what you are saying is that, if the vmservice related scripts are not
> going to be part of platform.dill anymore, then we do not need to copy them
over
> to the patched_sdk; One could potentially compile them directly from the
source
> tree. Is this correct?
> 
> My understanding is that, since we are compiling a "dart:*" library, the only
> way currently is to trick the fasta compiler into thinking that
> dart:vmservice_io is part of "platform". So, to do this trick, we copy the
> vmservice_io related files over to patched_sdk. That way, the compiler can
> resolve dart:vmservice_io when it sees it in patched_sdk.

It is actually possible to avoid the copying if we set here the location of
vmservice.dart in the source tree instead. This wasn't possible a couple weeks
ago, but now the input to the compiler is a .json file describining where to
find the sources. That .json file is created using this `locations` map here.
Note that to make it work this needs to be a relative path from the the json
file, which is emitted in the patched_sdk folder (e.g.
out/ReleaseX64/patched_sdk/libraries.json) and there may be small differences
depending on the architecture (win/mac/linux).

Just to be clear. We still need to copy the SDK libraries that contain
patch-files until we add patching support in fasta.

Question: do you need to continue using `dart:*` URIs for these libraries? Or
can they be a regular script or a script with a native extension? If you must
use dart:*, then we can skip the copying, if however it is possible to make them
a script, I'd rather move in that direction.