The CLI was not providing the ipv6 flag to DDS, resulting in a "Could
not start Observatory" error.
Change-Id: Idff0f525455f121b8f1e89bc4ad20a01cd1165ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/204860
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This reverts commit a527411e51.
Reason for revert: depends on package 'devtools_shared' that is not yet migrated.
Original change's description:
> [ package:dds ] Add null safety support
>
> Fixes https://github.com/dart-lang/sdk/issues/45756
>
> TEST=service + DDS tests
>
> Change-Id: I6dd14d7f9fdee479a830c3b053dc3b00aa635202
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/199800
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Devon Carew <devoncarew@google.com>
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: Icdaef3ac55d7ef302acd3f9c2538a41e52e4253a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/200180
Reviewed-by: David Morgan <davidmorgan@google.com>
Commit-Queue: David Morgan <davidmorgan@google.com>
This reverts commit ef0e4ea107.
Reason for revert: Flutter HHH and golem builds are red. Rolls to Flutter are failing.
TEST=N/A
Original change's description:
> [ VM / DDS / CLI ] Add DevTools support to the standalone VM
>
> Example output on stdout when DevTools is enabled:
>
> Observatory listening on http://127.0.0.1:8181/CzkZzZaONW4=/
> The Dart DevTools debugger and profiler is available at: http://127.0.0.1:8181/devtools/#/?uri=ws%3A%2F%2F127.0.0.1%3A8181%2FCzkZzZaONW4%3D%2Fws
> hello world!
>
> vm-service: isolate(1674461414267555) 'main' has no debugger attached and is paused at exit. Connect to Observatory at http://127.0.0.1:8181/CzkZzZaONW4=/ to debug.
>
> TEST=pkg/dartdev/test/commands/run_test.dart
>
> Change-Id: Icd1afda87ad4a46f228125d53094d10adf8056ec
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/188361
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I50e8dc4e592e13b44c2fb980b2029d5c5cc3ad2a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/198381
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Also updated non-migrated libraries to include @dart=2.10.
Change-Id: Idcf4e54f9aa37b9b016133144af594cc932418a0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/192122
Reviewed-by: Gary Roumanis <grouma@google.com>
The VM and dartdev were not forwarding --disable-service-auth-codes to
the DDS instance, resulting in auth codes always being enabled.
Change-Id: Ib23bfeb7c64a51fb1229f049a4b61cb1ce5018de
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/163261
Reviewed-by: Siva Annamalai <asiva@google.com>
This reverts commit 0ea18ffb36.
Reason for revert: Tree is on fire
Original change's description:
> [ Service / DDS ] Advertise DDS as the VM service, bump version to 4.0
>
> This change does the following:
> - The DDS URI will be reported by the VM as the VM service URI. If DDS
> disconnects, the VM service URI will be reported instead. This only
> impacts the standalone VM.
> - Updated the service protocol to 4.0 and removed the following
> deprecated functionality:
> - Client synchronization RPCs (these now live in DDS)
> - getWebSocketTarget (no longer needed as the VM service no longer
> tries to redirect web socket clients to DDS)
> - Regenerates package:vm_service based on the new spec, prepare for
> 5.0 release
>
> Change-Id: I8a2b401062342eb99b81ef10ef6926baa88f946e
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/160141
> Reviewed-by: Siva Annamalai <asiva@google.com>
TBR=bkonyi@google.com,rmacnak@google.com,asiva@google.com
Change-Id: I6a16e9fa7ceb18555d6424a169cfa811d3833419
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/160340
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This change does the following:
- The DDS URI will be reported by the VM as the VM service URI. If DDS
disconnects, the VM service URI will be reported instead. This only
impacts the standalone VM.
- Updated the service protocol to 4.0 and removed the following
deprecated functionality:
- Client synchronization RPCs (these now live in DDS)
- getWebSocketTarget (no longer needed as the VM service no longer
tries to redirect web socket clients to DDS)
- Regenerates package:vm_service based on the new spec, prepare for
5.0 release
Change-Id: I8a2b401062342eb99b81ef10ef6926baa88f946e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/160141
Reviewed-by: Siva Annamalai <asiva@google.com>
This reverts commit bc4cb123a8.
Reason for revert: breaks crossword simarm tests https://ci.chromium.org/p/dart/builders/ci.sandbox/vm-kernel-precomp-linux-debug-simarm_x64/2619
Original change's description:
> Reland "[ VM / DartDev ] Launch DartDev in an isolate within a single main Dart process"
>
> This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
>
> By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
>
> VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
> Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
> Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/42092)
>
> This reverts commit 3849b5061c.
>
> Change-Id: I4fd3ba33840771a9f284d733c4a25fac6cde64ca
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154706
> Reviewed-by: Siva Annamalai <asiva@google.com>
TBR=bkonyi@google.com,asiva@google.com
Change-Id: I649d94c668417f2edbfd7039fa5c876e10dc32fe
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154800
Reviewed-by: Alexander Aprelev <aam@google.com>
This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/42092)
This reverts commit 3849b5061c.
Change-Id: I4fd3ba33840771a9f284d733c4a25fac6cde64ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154706
Reviewed-by: Siva Annamalai <asiva@google.com>
This reverts commit ffe258d2d4.
Reason for revert: Failures on bots
Original change's description:
> [ VM / DartDev ] Launch DartDev in an isolate within a single main Dart process
>
> This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
>
> By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
>
> VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
> Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
> Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/41978)
>
> Change-Id: I1c6b1425831b691ad20284716aa80f817dbaf607
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152588
> Commit-Queue: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Siva Annamalai <asiva@google.com>
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
TBR=bkonyi@google.com,rmacnak@google.com,asiva@google.com
Change-Id: Idb1d24a4524bdc3ccfb199a82710f3c0d9db539a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/154702
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This CL changes how DartDev is run and how the run command handles executing a Dart program (will port additional commands in a separate CL). Rather than using DartDev to spawn a child process to run user code, the VM will instead launch a DartDev isolate after doing some VM options processing. DartDev will communicate information like exit codes and script/arg pairs with the VM via isolate ports. Once DartDev runs to completion and notifies the VM that a script should be run, the VM will move on to spawning another isolate with user code and continue executing in the same VM process.
By moving DartDev into an isolate within the same process that user code will eventually run in we're able to resolve the following issues that arose due to signal handling and IPC issues:
VM hangs when --enable-vm-service is supplied and there are compile time errors (https://github.com/dart-lang/sdk/issues/42630)
Dart daemon spinning in exit code handler / zombie Dart processes (https://github.com/dart-lang/sdk/issues/41978)
Signal handling in children of 'dartdev run' is problematic (https://github.com/dart-lang/sdk/issues/41978)
Change-Id: I1c6b1425831b691ad20284716aa80f817dbaf607
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/152588
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
