isolates refactor: this change introduces 'dart:isolate' as a library. This is a

isolates refactor: this change introduces 'dart:isolate' as a library. This is a
big global change, so let me explain in more detail. This refactoring CL does
the following:
- moves all the dart code for isolates in a common library (lib/isolate)

- changes frog to understand 'dart:isolate' imoprts by loading the code from the
  location above.

- changes the vm to undernstand 'dart:isolate' imports by creating a separate
  library that is part of the bootstrap. This follows the same code-structure
  that Todd suggested in his CL introducing the mirror library

- changes dartc to use the shared isolate library as the source of truth for
  type checking. I left around some of the internal js code in dartc so that the
  backend continues to work for apps that don't use isolates.

- changes all tests that use isolates to import the library explicitly (this is a large bulk of the files in this CL)

- changes test status for tests we can't fix in this repo (e.g. co19)

- splits the isolate library code to make it possible to preserve some tests
  without exposing internal types (e.g. tests about
  serialization/deserialization)

- changes the create_sdk script to copy the isolate library to the sdk

- includes the isolate library in dartdoc

I'll wait for at least one lgtm from each area (dartc, vm, frog, sdk)

There is one important pending thing this CL doesn't do:
- update test_runner.dart: This should be updated next time we upload the new
  binaries to tool/testing/bin
- dartium specific changes: Vijay, is there anything I need to do for dartium?

Committed: https://code.google.com/p/dart/source/detail?r=4647

[kasperl, 2012-02-20 12:34:38]

The frog changes LGTM. I think this will be easier to clean up and make nicer
once we have a common location (lib/isolate) for the code for all platforms.

[Bob Nystrom, 2012-02-21 18:41:58]

Dartdoc changes LGTM.

[eub, 2012-02-21 23:43:17]

Changes to lib/ and frog/lib/ LGTM.  I haven't looked at the VM changes.

(Lots of touched files still have a 2011 date on them; I can recommend elisp for
auto-updating but I don't know the vim equivalent.)

http://codereview.chromium.org/9422019/diff/3139/lib/isolate/isolate_runtime....
File lib/isolate/isolate_runtime.dart (left):

http://codereview.chromium.org/9422019/diff/3139/lib/isolate/isolate_runtime....
lib/isolate/isolate_runtime.dart:5: #library('dartcombatlib');
What the heck was this? :)

[Siggi Cherem (dart-lang), 2012-02-21 23:54:22]

http://codereview.chromium.org/9422019/diff/3139/lib/isolate/isolate_runtime....
File lib/isolate/isolate_runtime.dart (left):

http://codereview.chromium.org/9422019/diff/3139/lib/isolate/isolate_runtime....
lib/isolate/isolate_runtime.dart:5: #library('dartcombatlib');
On 2012/02/21 23:43:18, eub wrote:
> What the heck was this? :)

Most likely this was git trying to be smart, and failing gloriously. Since
'isolate_runtime' is a new added file, git looks if there is any file similar to
'isolate_runtime' (in case it was not a new file, but a file copy). Git detected
a lot of similiarity with 'client/samples/dartcombat/dartcombatlib.dart', so it
shows the diff here.

[siva, 2012-02-22 00:58:20]

DBC

https://chromiumcodereview.appspot.com/9422019/diff/3139/lib/isolate/isolate_...
File lib/isolate/isolate_api.dart (right):

https://chromiumcodereview.appspot.com/9422019/diff/3139/lib/isolate/isolate_...
lib/isolate/isolate_api.dart:217: void stop();
What is the semantics of this stop? Could you document it more. Is the caller
guaranteed that the isolate has been stopped when this returns or are in just
requesting the other isolate to stop? If it is the later than please rename  the
method.

It is generally a bad idea to allow an isolated to be 'stopped' from another
isolate (case in point - the method Thread.stop from another language was
deprecated quickly once people realized all the problems associated with it).

https://chromiumcodereview.appspot.com/9422019/diff/3139/lib/isolate/runtime/...
File lib/isolate/runtime/isolateimpl.dart (right):

https://chromiumcodereview.appspot.com/9422019/diff/3139/lib/isolate/runtime/...
lib/isolate/runtime/isolateimpl.dart:6: // Dart isolate's API and implementation
for the dartvm.
I would prefer if we did not move this VM specific implementation out of the
runtime directory into this new 'lib/runtime' directory.

Currently all VM specific stuff is localized under 'runtime' and we have
followed a pattern that any code outside of that will use the dart API to access
the VM.

With your new organization we would have code outside the 'runtime' directory
that accesses the VM internals directly.

https://chromiumcodereview.appspot.com/9422019/diff/3139/lib/isolate/runtime/...
File lib/isolate/runtime/ports.dart (right):

https://chromiumcodereview.appspot.com/9422019/diff/3139/lib/isolate/runtime/...
lib/isolate/runtime/ports.dart:4: 
Ditto comment about moving this out of 'runtime'

Another question, should ReceivePort, SendPort etc. be part of the Isolate
library or should they be considered corelib features. (the io library uses
ReceivePort and I noticed you had to import 'dart:isolate' in io.dart).

https://chromiumcodereview.appspot.com/9422019/diff/3139/runtime/bin/builtin.cc
File runtime/bin/builtin.cc (right):

https://chromiumcodereview.appspot.com/9422019/diff/3139/runtime/bin/builtin....
runtime/bin/builtin.cc:30:
DART_CHECK_VALID(Dart_LibraryImportLibrary(isolate_lib, builtin_lib));
These 4 lines seem to be repeated a number of times, maybe we need a static
method:

static void ImportBuiltinLibIntoLib(const char* libname) {
  Dart_Handle url = Dart_NewString(libname);
  Dart_Handle lib = Dart_LookupLibrary(url);
  DART_CHECK_VALID(lib);
  DART_CHECK_VALID(Dart_LibraryImportLibrary(lib, builtin_lib));
}

replace current code as:
ImportBuiltinLibIntoLib(DartUtils::kCoreLibURL);
ImportBuiltinLibIntoLib(DartUtils::kCoreImplLibURL);
ImportBuiltinLibIntoLib(DartUtils::kIsolateLibURL);

https://chromiumcodereview.appspot.com/9422019/diff/3139/runtime/bin/builtin....
runtime/bin/builtin.cc:66: SetupAdditionalImports(library);
Are we sure that all these additional libraries will be already loaded when this
built in library is being loaded?

https://chromiumcodereview.appspot.com/9422019/diff/3139/runtime/lib/isolate_...
File runtime/lib/isolate_sources.gypi (right):

https://chromiumcodereview.appspot.com/9422019/diff/3139/runtime/lib/isolate_...
runtime/lib/isolate_sources.gypi:10:
'../../lib/isolate/runtime/isolateimpl.dart',
ditto comment about runtime directory outside of 'runtime'??

https://chromiumcodereview.appspot.com/9422019/diff/3139/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://chromiumcodereview.appspot.com/9422019/diff/3139/runtime/vm/object.cc...
runtime/vm/object.cc:667: ASSERT(!isolate_lib.IsNull());
I noticed that these changes are similar to the ones that Todd is doing for
'dart::mirrors'. There are some review comments in that CL. I am assuming you
will reconcile with Todd's changes once he submits them.

[scheglov, 2012-02-22 13:59:12]

dartc changes LGTM

[zundel, 2012-02-22 16:10:47]

dartc changes LGTM2

[dgrove, 2012-02-22 16:21:10]

sdk changes lgtm

[mmendez, 2012-02-22 16:32:07]

On 2012/02/22 16:21:10, dgrove wrote:
> sdk changes lgtm

dartc lgtm3

[Siggi Cherem (dart-lang), 2012-02-22 19:18:49]

https://chromiumcodereview.appspot.com/9422019/diff/3139/lib/isolate/isolate_...
File lib/isolate/isolate_api.dart (right):

https://chromiumcodereview.appspot.com/9422019/diff/3139/lib/isolate/isolate_...
lib/isolate/isolate_api.dart:217: void stop();
On 2012/02/22 00:58:20, asiva wrote:
> What is the semantics of this stop? Could you document it more. Is the caller
> guaranteed that the isolate has been stopped when this returns or are in just
> requesting the other isolate to stop? If it is the later than please rename 
the
> method.
> 
> It is generally a bad idea to allow an isolated to be 'stopped' from another
> isolate (case in point - the method Thread.stop from another language was
> deprecated quickly once people realized all the problems associated with it).

This is something that we were planning to remove, so I just went ahead and
delete it. The code was here because I was only doing refactoring (this code
came from another location)

https://chromiumcodereview.appspot.com/9422019/diff/3139/lib/isolate/runtime/...
File lib/isolate/runtime/isolateimpl.dart (right):

https://chromiumcodereview.appspot.com/9422019/diff/3139/lib/isolate/runtime/...
lib/isolate/runtime/isolateimpl.dart:6: // Dart isolate's API and implementation
for the dartvm.
On 2012/02/22 00:58:20, asiva wrote:
> I would prefer if we did not move this VM specific implementation out of the
> runtime directory into this new 'lib/runtime' directory.
> 
> Currently all VM specific stuff is localized under 'runtime' and we have
> followed a pattern that any code outside of that will use the dart API to
access
> the VM.
> 
> With your new organization we would have code outside the 'runtime' directory
> that accesses the VM internals directly.

Done. I moved this back under runtime/lib/

https://chromiumcodereview.appspot.com/9422019/diff/3139/lib/isolate/runtime/...
File lib/isolate/runtime/ports.dart (right):

https://chromiumcodereview.appspot.com/9422019/diff/3139/lib/isolate/runtime/...
lib/isolate/runtime/ports.dart:4: 
On 2012/02/22 00:58:20, asiva wrote:
> Ditto comment about moving this out of 'runtime'

Done

> Another question, should ReceivePort, SendPort etc. be part of the Isolate
> library or should they be considered corelib features. (the io library uses
> ReceivePort and I noticed you had to import 'dart:isolate' in io.dart).

I think they should be considered part of the isolate library. I'd like to make
it easy to see that a library (e.g. io) is interacting with other isolates. If
ports are part of the isolate library, we can tell if there is any interaction
by looking at the imports.

This happens to be important for frog. To make sure we generate small code for
small programs (e.g. hello world), it is necessary to detect if a program
interacts with any other isolate. If it doesn't, there is a lot of
isolate-machinery that we don't need to include in the generated code. For
example, 'helloworld' can be compiled to be < 1K today, but if we include the
isolate machinery, it becomes 10K. Today, we use adhoc tricks to detect whether
or not the program is interacting with other isolates. With this change, the
detection will be cleaner and less brittle.

https://chromiumcodereview.appspot.com/9422019/diff/3139/runtime/bin/builtin.cc
File runtime/bin/builtin.cc (right):

https://chromiumcodereview.appspot.com/9422019/diff/3139/runtime/bin/builtin....
runtime/bin/builtin.cc:30:
DART_CHECK_VALID(Dart_LibraryImportLibrary(isolate_lib, builtin_lib));
On 2012/02/22 00:58:20, asiva wrote:
> These 4 lines seem to be repeated a number of times, maybe we need a static
> method:
> 
> static void ImportBuiltinLibIntoLib(const char* libname) {
>   Dart_Handle url = Dart_NewString(libname);
>   Dart_Handle lib = Dart_LookupLibrary(url);
>   DART_CHECK_VALID(lib);
>   DART_CHECK_VALID(Dart_LibraryImportLibrary(lib, builtin_lib));
> }
> 
> replace current code as:
> ImportBuiltinLibIntoLib(DartUtils::kCoreLibURL);
> ImportBuiltinLibIntoLib(DartUtils::kCoreImplLibURL);
> ImportBuiltinLibIntoLib(DartUtils::kIsolateLibURL);

Done.

https://chromiumcodereview.appspot.com/9422019/diff/3139/runtime/bin/builtin....
runtime/bin/builtin.cc:66: SetupAdditionalImports(library);
On 2012/02/22 00:58:20, asiva wrote:
> Are we sure that all these additional libraries will be already loaded when
this
> built in library is being loaded?

yes - we are currently loading/compiling them immediately after coreimpl.

https://chromiumcodereview.appspot.com/9422019/diff/3139/runtime/lib/isolate_...
File runtime/lib/isolate_sources.gypi (right):

https://chromiumcodereview.appspot.com/9422019/diff/3139/runtime/lib/isolate_...
runtime/lib/isolate_sources.gypi:10:
'../../lib/isolate/runtime/isolateimpl.dart',
On 2012/02/22 00:58:20, asiva wrote:
> ditto comment about runtime directory outside of 'runtime'??

Done.

https://chromiumcodereview.appspot.com/9422019/diff/3139/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://chromiumcodereview.appspot.com/9422019/diff/3139/runtime/vm/object.cc...
runtime/vm/object.cc:667: ASSERT(!isolate_lib.IsNull());
On 2012/02/22 00:58:20, asiva wrote:
> I noticed that these changes are similar to the ones that Todd is doing for
> 'dart::mirrors'. There are some review comments in that CL. I am assuming you
> will reconcile with Todd's changes once he submits them.

I'm happy to do so, but since Todd is on vacation, I might submit this before.
In that case, would you like me to do some of the changes here?

I saw your comment on changing InitAdditionalLibraries to return RawObject, but
I'm not sure how far does you want that change to go. Did you mean to change
also Bootstrap::Compile to return RawObject*, and here Object::Init too? (so we
do the error handler allocation only in dart.cc (InitializeIsolate)?

[siva, 2012-02-22 23:18:13]

https://chromiumcodereview.appspot.com/9422019/diff/3139/runtime/vm/object.cc
File runtime/vm/object.cc (right):

https://chromiumcodereview.appspot.com/9422019/diff/3139/runtime/vm/object.cc...
runtime/vm/object.cc:667: ASSERT(!isolate_lib.IsNull());
On 2012/02/22 19:18:50, sigmund wrote:
> On 2012/02/22 00:58:20, asiva wrote:
> > I noticed that these changes are similar to the ones that Todd is doing for
> > 'dart::mirrors'. There are some review comments in that CL. I am assuming
you
> > will reconcile with Todd's changes once he submits them.
> 
> I'm happy to do so, but since Todd is on vacation, I might submit this before.
> In that case, would you like me to do some of the changes here?

I think we should probably have Todd reconcile when he submits his changes.



> 
> I saw your comment on changing InitAdditionalLibraries to return RawObject,
but
> I'm not sure how far does you want that change to go. Did you mean to change
> also Bootstrap::Compile to return RawObject*, and here Object::Init too? (so
we
> do the error handler allocation only in dart.cc (InitializeIsolate)?

My comment was a generic one but I was referring to the code in
InitAdditionalLibraries which had to create an Error handle and re - assign etc.
Not sure if there is code like that in other spots too.

[Ivan Posva, 2012-02-25 00:14:38]

https://chromiumcodereview.appspot.com/9422019/diff/9008/lib/isolate/isolate_...
File lib/isolate/isolate_api.dart (right):

https://chromiumcodereview.appspot.com/9422019/diff/9008/lib/isolate/isolate_...
lib/isolate/isolate_api.dart:55: interface ReceivePort default
ReceivePortFactory {
The class ReceivePortFactory could be completely hidden without the library
inflation.

https://chromiumcodereview.appspot.com/9422019/diff/9008/lib/isolate/isolate_...
lib/isolate/isolate_api.dart:188: interface Isolate2 default _IsolateFactory {
Conflating restructuring (adding the dart:isolate library) makes this review
more involved than needed. In the future please avoid this complication. Thanks!

https://chromiumcodereview.appspot.com/9422019/diff/9008/lib/isolate/isolate_...
File lib/isolate/isolate_frog.dart (right):

https://chromiumcodereview.appspot.com/9422019/diff/9008/lib/isolate/isolate_...
lib/isolate/isolate_frog.dart:9: #import("frog/isolateimpl.dart");
Please avoid this library inflation here. This will allow you to hide much more
implementation detail. For example there is not need that the default class for
a ReceivePort is not hidden.

https://chromiumcodereview.appspot.com/9422019/diff/9008/lib/isolate/isolate_...
lib/isolate/isolate_frog.dart:10: #import("frog/ports.dart");
ditto

https://chromiumcodereview.appspot.com/9422019/diff/9008/runtime/bin/builtin.cc
File runtime/bin/builtin.cc (left):

https://chromiumcodereview.appspot.com/9422019/diff/9008/runtime/bin/builtin....
runtime/bin/builtin.cc:24: 
Two lines between C++ methods.

https://chromiumcodereview.appspot.com/9422019/diff/9008/runtime/bin/io.dart
File runtime/bin/io.dart (right):

https://chromiumcodereview.appspot.com/9422019/diff/9008/runtime/bin/io.dart#...
runtime/bin/io.dart:10: #import("dart:nativewrappers");
Should we list imports in alphabetical order like #includes in C++?

https://chromiumcodereview.appspot.com/9422019/diff/9008/runtime/vm/bootstrap.cc
File runtime/vm/bootstrap.cc (right):

https://chromiumcodereview.appspot.com/9422019/diff/9008/runtime/vm/bootstrap...
runtime/vm/bootstrap.cc:57: RawError* Bootstrap::InitAdditionalLibraries() {
As we are planning to completely revamp the way libraries are injected into the
VM, please remove this abstraction and just mirror the LoadScript above by
adding LoadIsolateScript.

https://chromiumcodereview.appspot.com/9422019/diff/9008/runtime/vm/bootstrap...
File runtime/vm/bootstrap_natives.cc (right):

https://chromiumcodereview.appspot.com/9422019/diff/9008/runtime/vm/bootstrap...
runtime/vm/bootstrap_natives.cc:57: library =
isolate->object_store()->core_library();
Why were these changes here needed?

[Siggi Cherem (dart-lang), 2012-02-25 02:10:38]

Thanks Ivan - PTAL

https://chromiumcodereview.appspot.com/9422019/diff/9008/lib/isolate/isolate_...
File lib/isolate/isolate_api.dart (right):

https://chromiumcodereview.appspot.com/9422019/diff/9008/lib/isolate/isolate_...
lib/isolate/isolate_api.dart:55: interface ReceivePort default
ReceivePortFactory {
On 2012/02/25 00:14:38, Ivan Posva wrote:
> The class ReceivePortFactory could be completely hidden without the library
> inflation.

Done.

https://chromiumcodereview.appspot.com/9422019/diff/9008/lib/isolate/isolate_...
lib/isolate/isolate_api.dart:188: interface Isolate2 default _IsolateFactory {
On 2012/02/25 00:14:38, Ivan Posva wrote:
> Conflating restructuring (adding the dart:isolate library) makes this review
> more involved than needed. In the future please avoid this complication.
Thanks!

Will do. I actually didn't wanted to do this refactoring with this CL, but one
our tests (SerializationTest) was using directly types that became hidden. This
refactoring (and adding the new impl libraries) was a good way to keep the test
without exposing anything in dart:isolate.

https://chromiumcodereview.appspot.com/9422019/diff/9008/lib/isolate/isolate_...
File lib/isolate/isolate_frog.dart (right):

https://chromiumcodereview.appspot.com/9422019/diff/9008/lib/isolate/isolate_...
lib/isolate/isolate_frog.dart:9: #import("frog/isolateimpl.dart");
On 2012/02/25 00:14:38, Ivan Posva wrote:
> Please avoid this library inflation here. This will allow you to hide much
more
> implementation detail. For example there is not need that the default class
for
> a ReceivePort is not hidden.

Done.

I removed the library indirection, but had to expose a couple functions to be
able to keep SerializationTest running (see bottom of messages.dart). Let me
know if you have any ideas for doing that in a cleaner way.

https://chromiumcodereview.appspot.com/9422019/diff/9008/lib/isolate/isolate_...
lib/isolate/isolate_frog.dart:10: #import("frog/ports.dart");
On 2012/02/25 00:14:38, Ivan Posva wrote:
> ditto

Done.

https://chromiumcodereview.appspot.com/9422019/diff/9008/runtime/bin/builtin.cc
File runtime/bin/builtin.cc (left):

https://chromiumcodereview.appspot.com/9422019/diff/9008/runtime/bin/builtin....
runtime/bin/builtin.cc:24: 
On 2012/02/25 00:14:38, Ivan Posva wrote:
> Two lines between C++ methods.

Done.

https://chromiumcodereview.appspot.com/9422019/diff/9008/runtime/bin/io.dart
File runtime/bin/io.dart (right):

https://chromiumcodereview.appspot.com/9422019/diff/9008/runtime/bin/io.dart#...
runtime/bin/io.dart:10: #import("dart:nativewrappers");
On 2012/02/25 00:14:38, Ivan Posva wrote:
> Should we list imports in alphabetical order like #includes in C++?

sounds good. Done.

https://chromiumcodereview.appspot.com/9422019/diff/9008/runtime/vm/bootstrap.cc
File runtime/vm/bootstrap.cc (right):

https://chromiumcodereview.appspot.com/9422019/diff/9008/runtime/vm/bootstrap...
runtime/vm/bootstrap.cc:57: RawError* Bootstrap::InitAdditionalLibraries() {
On 2012/02/25 00:14:38, Ivan Posva wrote:
> As we are planning to completely revamp the way libraries are injected into
the
> VM, please remove this abstraction and just mirror the LoadScript above by
> adding LoadIsolateScript.

Done.

https://chromiumcodereview.appspot.com/9422019/diff/9008/runtime/vm/bootstrap...
File runtime/vm/bootstrap_natives.cc (right):

https://chromiumcodereview.appspot.com/9422019/diff/9008/runtime/vm/bootstrap...
runtime/vm/bootstrap_natives.cc:57: library =
isolate->object_store()->core_library();
On 2012/02/25 00:14:38, Ivan Posva wrote:
> Why were these changes here needed?

Reverted. I was integrating the changes from Todd in this CL too (minimizing
future conflicts with his CL).

[Ivan Posva, 2012-02-27 22:16:03]

LGTM (for runtime and library layout).

-Ivan

https://chromiumcodereview.appspot.com/9422019/diff/21146/tests/isolate/isola...
File tests/isolate/isolate.status (right):

https://chromiumcodereview.appspot.com/9422019/diff/21146/tests/isolate/isola...
tests/isolate/isolate.status:11: SerializationTest: Skip  # tests frog-specific
serialization code
Not this CL: Can we add this test to the frog-specific tests in a similar manner
to the standalone tests?

https://chromiumcodereview.appspot.com/9422019/diff/21146/tests/isolate/isola...
tests/isolate/isolate.status:15: SerializationTest: Skip  # tests frog-specific
serialization code
... would fix this too.

https://chromiumcodereview.appspot.com/9422019/diff/21146/tests/isolate/isola...
tests/isolate/isolate.status:54: SerializationTest: Skip
Skip or Fail?

https://chromiumcodereview.appspot.com/9422019/diff/21146/tests/isolate/src/A...
File tests/isolate/src/APIv2_unresolvedPortsBrowserNegativeTest.dart (right):

https://chromiumcodereview.appspot.com/9422019/diff/21146/tests/isolate/src/A...
tests/isolate/src/APIv2_unresolvedPortsBrowserNegativeTest.dart:7:
#import('dart:isolate');
import order?

https://chromiumcodereview.appspot.com/9422019/diff/21146/tests/isolate/src/A...
File tests/isolate/src/APIv2_unresolvedPortsBrowserTest.dart (right):

https://chromiumcodereview.appspot.com/9422019/diff/21146/tests/isolate/src/A...
tests/isolate/src/APIv2_unresolvedPortsBrowserTest.dart:7:
#import('dart:isolate');
ditto

[Siggi Cherem (dart-lang), 2012-02-27 22:30:33]

Thanks Ivan!

Submitting shortly...

https://chromiumcodereview.appspot.com/9422019/diff/21146/tests/isolate/isola...
File tests/isolate/isolate.status (right):

https://chromiumcodereview.appspot.com/9422019/diff/21146/tests/isolate/isola...
tests/isolate/isolate.status:11: SerializationTest: Skip  # tests frog-specific
serialization code
On 2012/02/27 22:16:04, Ivan Posva wrote:
> Not this CL: Can we add this test to the frog-specific tests in a similar
manner
> to the standalone tests?

Sounds good. Will do.

https://chromiumcodereview.appspot.com/9422019/diff/21146/tests/isolate/isola...
tests/isolate/isolate.status:15: SerializationTest: Skip  # tests frog-specific
serialization code
On 2012/02/27 22:16:04, Ivan Posva wrote:
> ... would fix this too.

will do

https://chromiumcodereview.appspot.com/9422019/diff/21146/tests/isolate/isola...
tests/isolate/isolate.status:54: SerializationTest: Skip
On 2012/02/27 22:16:04, Ivan Posva wrote:
> Skip or Fail?

apparently Pass :) - seems this was fixed in frogsh sometime last week.

https://chromiumcodereview.appspot.com/9422019/diff/21146/tests/isolate/src/A...
File tests/isolate/src/APIv2_unresolvedPortsBrowserNegativeTest.dart (right):

https://chromiumcodereview.appspot.com/9422019/diff/21146/tests/isolate/src/A...
tests/isolate/src/APIv2_unresolvedPortsBrowserNegativeTest.dart:7:
#import('dart:isolate');
On 2012/02/27 22:16:04, Ivan Posva wrote:
> import order?

Done.

https://chromiumcodereview.appspot.com/9422019/diff/21146/tests/isolate/src/A...
File tests/isolate/src/APIv2_unresolvedPortsBrowserTest.dart (right):

https://chromiumcodereview.appspot.com/9422019/diff/21146/tests/isolate/src/A...
tests/isolate/src/APIv2_unresolvedPortsBrowserTest.dart:7:
#import('dart:isolate');
On 2012/02/27 22:16:04, Ivan Posva wrote:
> ditto

Done.