runtime/observatory/tests/service/debugger_location_test.dart hangs

The vm-kernel-win-debug-ia32 bot has been plagued by flaky infra failures in the last few days.
It seems to consistently happen on shard 6, and the test involved is runtime/observatory/tests/service/debugger_location_test.dart.
The recent string of flakiness seem to coincide with landing of 140480.
The bot logs show the test timing out:
{"name":"service/debugger_location_test","configuration":"dartk-win-debug-ia32","suite":"service","test_name":"debugger_location_test","time_ms":120137,"result":"Timeout","expected":"Pass","matches":false}
And the task logs show the whole task failing due to a pair of hanging processes:
Failed to delete C:\b\s\w\ir (16 files remaining).
  Maybe the test has a subprocess outliving it.
  Sleeping 2 seconds.
Failed to delete C:\b\s\w\ir (16 files remaining).
  Maybe the test has a subprocess outliving it.
  Sleeping 4 seconds.
Failed to delete C:\b\s\w\ir. The following files remain:
- \\?\C:\b\s\w\ir
- \\?\C:\b\s\w\ir\out
[...]
Enumerating processes:
- pid 1844; Handles: 97; Exe: C:\b\s\w\ir\out\DebugIA32\crashpad_handler.exe; Cmd: C:\b\s\w\ir\out\DebugIA32\crashpad_handler.exe --database=C:\b\s\w\ir\crashes --metrics-dir=C:\b\s\w\ir\crashes --initial-client-data=0x1cc,0x1d0,0x1d4,0x1c4,0x1d8,0x14acf7c,0x14acf8c,0x14acf9c
- pid 7012; Handles: 172; Exe: C:\b\s\w\ir\out\DebugIA32\dart.exe; Cmd: out\DebugIA32\dart.exe --write-service-info=file:///C:/b/s/w/itgbicvk/dart_service4641cc87-6e85-11ea-9603-d43d0c4f0314/service_info.json --profiler --ignore-unrecognized-flags --packages=C:\b\s\w\ir\.packages --enable-vm-service:0 C:\b\s\w\ir\runtime\observatory\tests\service\debugger_location_test.dart
Terminating 2 processes:
- 1844 killed
- 7012 killed
*** Swarming tried multiple times to delete the C:\b\s\w\ir directory and failed ***
*** Hard failing the task ***

+@bkonyi who was looking at this issue the other day.
+@athom for engprod context.

Discussing the issue with Slava, he mentioned we should verify that test.dart kills child processes when it detects a timeout.

runtime\observatory\tests\service\debugger_location_test test is hanging on vm-kernel-win-debug-ia32 consistently, turning bot purple.
Also saw a hanging runtime\observatory\tests\service\rewind_optimized_out_test on vm-kernel-win-release-ia32 bot.
Log:
Failed to delete C:\b\s\w\ir (16 files remaining).
  Maybe the test has a subprocess outliving it.
  Sleeping 2 seconds.
Failed to delete C:\b\s\w\ir (16 files remaining).
  Maybe the test has a subprocess outliving it.
  Sleeping 4 seconds.
Failed to delete C:\b\s\w\ir. The following files remain:
- \\?\C:\b\s\w\ir
- \\?\C:\b\s\w\ir\out
- \\?\C:\b\s\w\ir\out\DebugIA32
- \\?\C:\b\s\w\ir\out\DebugIA32\dbghelp.dll
- \\?\C:\b\s\w\ir\out\DebugSIMARM
- \\?\C:\b\s\w\ir\out\DebugSIMARM\dbghelp.dll
- \\?\C:\b\s\w\ir\out\ProductIA32
- \\?\C:\b\s\w\ir\out\ProductIA32\dbghelp.dll
- \\?\C:\b\s\w\ir\out\ProductSIMARM
- \\?\C:\b\s\w\ir\out\ProductSIMARM\dbghelp.dll
- \\?\C:\b\s\w\ir\out\ReleaseIA32
- \\?\C:\b\s\w\ir\out\ReleaseIA32\crashpad_handler.exe
- \\?\C:\b\s\w\ir\out\ReleaseIA32\dart.exe
- \\?\C:\b\s\w\ir\out\ReleaseIA32\dbghelp.dll
- \\?\C:\b\s\w\ir\out\ReleaseSIMARM
- \\?\C:\b\s\w\ir\out\ReleaseSIMARM\dbghelp.dll
Enumerating processes:
- pid 6192; Handles: 97; Exe: C:\b\s\w\ir\out\ReleaseIA32\crashpad_handler.exe; Cmd: C:\b\s\w\ir\out\ReleaseIA32\crashpad_handler.exe --database=C:\b\s\w\ir\crashes --metrics-dir=C:\b\s\w\ir\crashes --initial-client-data=0x1c8,0x1cc,0x1d0,0x1c4,0x1d4,0x5bbe18,0x5bbe28,0x5bbe38
- pid 9652; Handles: 168; Exe: C:\b\s\w\ir\out\ReleaseIA32\dart.exe; Cmd: out\ReleaseIA32\dart.exe --write-service-info=file:///C:/b/s/w/it6hykly/dart_service1aaeb074-704b-11ea-9603-c2ba776539ff/service_info.json --profiler --trace-rewind --prune-dead-locals --no-background-compilation --optimization-counter-threshold=10 --ignore-unrecognized-flags --packages=C:\b\s\w\ir\.packages --enable-vm-service:0 C:\b\s\w\ir\runtime\observatory\tests\service\rewind_optimized_out_test.dart
Terminating 2 processes:
- 6192 killed
- 9652 killed
*** Swarming tried multiple times to delete the C:\b\s\w\ir directory and failed ***
*** Hard failing the task ***

Swarming detected that your testing script ran an executable, which may have
started a child executable, and the main script returned early, leaving the
children executables playing around unguided.

You don't want to leave children processes outliving the task on the Swarming
bot, do you? The Swarming bot doesn't.

How to fix?
- For any process that starts children processes, make sure all children
  processes terminated properly before each parent process exits. This is
  especially important in very deep process trees.
  - This must be done properly both in normal successful task and in case of
    task failure. Cleanup is very important.
- The Swarming bot sends a SIGTERM in case of timeout.
  - You have 30.0 seconds to comply after the signal was sent to the process
    before the process is forcibly killed.
- To achieve not leaking children processes in case of signals on timeout, you
  MUST handle signals in each executable / python script and propagate them to
  children processes.
  - When your test script (python or binary) receives a signal like SIGTERM or
    CTRL_BREAK_EVENT on Windows), send it to all children processes and wait for
    them to terminate before quitting.

See
https://chromium.googlesource.com/infra/luci/luci-py.git/+/master/appengine/swarming/doc/Bot.md#Graceful-termination_aka-the-SIGTERM-and-SIGKILL-dance
for more information.

*** May the SIGKILL force be with you ***

https://dart-review.googlesource.com/c/sdk/+/141840 skips the tests on windows debug configurations.

service\rewind_optimized_out_test timed out on vm-kernel-win-release-ia32 once again, turning the bot purple:
Failed to delete C:\b\s\w\ir (16 files remaining).
  Maybe the test has a subprocess outliving it.
  Sleeping 2 seconds.
Failed to delete C:\b\s\w\ir (16 files remaining).
  Maybe the test has a subprocess outliving it.
  Sleeping 4 seconds.
Failed to delete C:\b\s\w\ir. The following files remain:
- \\?\C:\b\s\w\ir
- \\?\C:\b\s\w\ir\out
- \\?\C:\b\s\w\ir\out\DebugIA32
- \\?\C:\b\s\w\ir\out\DebugIA32\dbghelp.dll
- \\?\C:\b\s\w\ir\out\DebugSIMARM
- \\?\C:\b\s\w\ir\out\DebugSIMARM\dbghelp.dll
- \\?\C:\b\s\w\ir\out\ProductIA32
- \\?\C:\b\s\w\ir\out\ProductIA32\dbghelp.dll
- \\?\C:\b\s\w\ir\out\ProductSIMARM
- \\?\C:\b\s\w\ir\out\ProductSIMARM\dbghelp.dll
- \\?\C:\b\s\w\ir\out\ReleaseIA32
- \\?\C:\b\s\w\ir\out\ReleaseIA32\crashpad_handler.exe
- \\?\C:\b\s\w\ir\out\ReleaseIA32\dart.exe
- \\?\C:\b\s\w\ir\out\ReleaseIA32\dbghelp.dll
- \\?\C:\b\s\w\ir\out\ReleaseSIMARM
- \\?\C:\b\s\w\ir\out\ReleaseSIMARM\dbghelp.dll
Enumerating processes:
- pid 5500; Handles: 166; Exe: C:\b\s\w\ir\out\ReleaseIA32\dart.exe; Cmd: out\ReleaseIA32\dart.exe --write-service-info=file:///C:/b/s/w/ittukdyk/dart_servicea2460aeb-79c8-11ea-b4cb-86add17e8a3d/service_info.json --profiler --trace-rewind --prune-dead-locals --no-background-compilation --optimization-counter-threshold=10 --ignore-unrecognized-flags --packages=C:\b\s\w\ir\.packages --enable-vm-service:0 C:\b\s\w\ir\runtime\observatory\tests\service\rewind_optimized_out_test.dart
- pid 5528; Handles: 97; Exe: C:\b\s\w\ir\out\ReleaseIA32\crashpad_handler.exe; Cmd: C:\b\s\w\ir\out\ReleaseIA32\crashpad_handler.exe --database=C:\b\s\w\ir\crashes --metrics-dir=C:\b\s\w\ir\crashes --initial-client-data=0x1dc,0x1e0,0x1e4,0x1d4,0x1e8,0xf54500,0xf54510,0xf54520
Terminating 2 processes:
- 5500 killed
- 5528 killed
*** Swarming tried multiple times to delete the C:\b\s\w\ir directory and failed ***

Another similar infra failure on vm-kernel-win-release-ia32:
INFO: Enabling coredump archiving into C:\b\s\w\ir\crashes
INFO: Core dump archiving is activated
INFO: No unexpected crashes recorded
Failed to delete C:\b\s\w\ir (16 files remaining).
  Maybe the test has a subprocess outliving it.
  Sleeping 2 seconds.
Failed to delete C:\b\s\w\ir (16 files remaining).
  Maybe the test has a subprocess outliving it.
  Sleeping 4 seconds.
Failed to delete C:\b\s\w\ir. The following files remain:
- \\?\C:\b\s\w\ir
- \\?\C:\b\s\w\ir\out
- \\?\C:\b\s\w\ir\out\DebugIA32
- \\?\C:\b\s\w\ir\out\DebugIA32\dbghelp.dll
- \\?\C:\b\s\w\ir\out\DebugSIMARM
- \\?\C:\b\s\w\ir\out\DebugSIMARM\dbghelp.dll
- \\?\C:\b\s\w\ir\out\ProductIA32
- \\?\C:\b\s\w\ir\out\ProductIA32\dbghelp.dll
- \\?\C:\b\s\w\ir\out\ProductSIMARM
- \\?\C:\b\s\w\ir\out\ProductSIMARM\dbghelp.dll
- \\?\C:\b\s\w\ir\out\ReleaseIA32
- \\?\C:\b\s\w\ir\out\ReleaseIA32\crashpad_handler.exe
- \\?\C:\b\s\w\ir\out\ReleaseIA32\dart.exe
- \\?\C:\b\s\w\ir\out\ReleaseIA32\dbghelp.dll
- \\?\C:\b\s\w\ir\out\ReleaseSIMARM
- \\?\C:\b\s\w\ir\out\ReleaseSIMARM\dbghelp.dll
Enumerating processes:
- pid 3528; Handles: 175; Exe: C:\b\s\w\ir\out\ReleaseIA32\dart.exe; Cmd: out\ReleaseIA32\dart.exe --disable-dart-dev --pause-isolates-on-start --pause-isolates-on-exit --write-service-info=file:///C:/b/s/w/itfvsc51/dart_service59bcb3bd/service_info.json --profiler -DUSE_DDS=true --ignore-unrecognized-flags --packages=C:\b\s\w\ir\.packages --enable-vm-service:0 C:\b\s\w\ir\runtime\observatory\tests\service\dds_log_history_size_gigantic_test.dart
- pid 10844; Handles: 97; Exe: C:\b\s\w\ir\out\ReleaseIA32\crashpad_handler.exe; Cmd: C:\b\s\w\ir\out\ReleaseIA32\crashpad_handler.exe --database=C:\b\s\w\ir\crashes --metrics-dir=C:\b\s\w\ir\crashes --initial-client-data=0x1d4,0x1d8,0x1dc,0x1cc,0x1e0,0xfe46d0,0xfe46e0,0xfe46f0
Terminating 2 processes:
- 3528 killed
- 10844 killed
*** Swarming tried multiple times to delete the C:\b\s\w\ir directory and failed ***
*** Hard failing the task ***

Swarming detected that your testing script ran an executable, which may have
started a child executable, and the main script returned early, leaving the
children executables playing around unguided.

You don't want to leave children processes outliving the task on the Swarming
bot, do you? The Swarming bot doesn't.

How to fix?
- For any process that starts children processes, make sure all children
  processes terminated properly before each parent process exits. This is
  especially important in very deep process trees.
  - This must be done properly both in normal successful task and in case of
    task failure. Cleanup is very important.
- The Swarming bot sends a SIGTERM in case of timeout.
  - You have 30.0 seconds to comply after the signal was sent to the process
    before the process is forcibly killed.
- To achieve not leaking children processes in case of signals on timeout, you
  MUST handle signals in each executable / python script and propagate them to
  children processes.
  - When your test script (python or binary) receives a signal like SIGTERM or
    CTRL_BREAK_EVENT on Windows), send it to all children processes and wait for
    them to terminate before quitting.

See
https://chromium.googlesource.com/infra/luci/luci-py.git/+/master/appengine/swarming/doc/Bot.md#Graceful-termination_aka-the-SIGTERM-and-SIGKILL-dance
for more information.

*** May the SIGKILL force be with you ***

Full log.

Saw another one of this during gardening today
https://ci.chromium.org/p/dart/builders/ci.sandbox/vm-kernel-win-release-ia32/7384

Another purple bot: https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket.appspot.com/8871433581629769936/+/steps/vm_tests_shard_2/0/logs/task_stdout_stderr:_vm_tests_shard_2/0

vm-kernel-nnbd-win-release-ia32 turned purple again:
Failed to delete C:\b\s\w\ir. The following files remain:
- \\?\C:\b\s\w\ir
- \\?\C:\b\s\w\ir\out
- \\?\C:\b\s\w\ir\out\ReleaseIA32
- \\?\C:\b\s\w\ir\out\ReleaseIA32\crashpad_handler.exe
- \\?\C:\b\s\w\ir\out\ReleaseIA32\dart.exe
- \\?\C:\b\s\w\ir\out\ReleaseIA32\dbghelp.dll
Enumerating processes:
- pid 4824; Handles: 97; Exe: C:\b\s\w\ir\out\ReleaseIA32\crashpad_handler.exe; Cmd: C:\b\s\w\ir\out\ReleaseIA32\crashpad_handler.exe --database=C:\b\s\w\ir\crashes --metrics-dir=C:\b\s\w\ir\crashes --initial-client-data=0x1d0,0x1d4,0x1d8,0x1cc,0x1dc,0x16d0df8,0x16d0e08,0x16d0e14
- pid 5624; Handles: 134; Exe: C:\b\s\w\ir\out\ReleaseIA32\dart.exe; Cmd: C:\b\s\w\ir\out\ReleaseIA32\dart.exe  "--enable-experiment=non-nullable file:///C:/b/s/w/ir/tests/co19/src/LibTest/io/Stdin/readByteSync_A01_t01.dart" test
Terminating 2 processes:
- 4824 killed
- 5624 killed
*** Swarming tried multiple times to delete the C:\b\s\w\ir directory and failed ***
*** Hard failing the task ***

Full log: https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket.appspot.com/8865042100554160896/+/steps/vm_co19_nnbd_tests_in_strong_mode_shard_3/0/logs/task_stdout_stderr:_vm_co19_nnbd_tests_in_strong_mode_shard_3/0
Similar problem on vm-kernel-nnbd-win-debug-x64:
Failed to delete C:\b\s\w\ir. The following files remain:
- \\?\C:\b\s\w\ir
- \\?\C:\b\s\w\ir\out
- \\?\C:\b\s\w\ir\out\DebugX64
- \\?\C:\b\s\w\ir\out\DebugX64\crashpad_handler.exe
- \\?\C:\b\s\w\ir\out\DebugX64\dart-sdk
- \\?\C:\b\s\w\ir\out\DebugX64\dart-sdk\bin
- \\?\C:\b\s\w\ir\out\DebugX64\dart-sdk\bin\dart.exe
- \\?\C:\b\s\w\ir\out\DebugX64\dart.exe
- \\?\C:\b\s\w\ir\out\DebugX64\dbghelp.dll
Enumerating processes:
- pid 5352; Handles: 114; Exe: C:\b\s\w\ir\out\DebugX64\dart.exe; Cmd: C:\b\s\w\ir\out\DebugX64\dart.exe  "--enable-experiment=non-nullable file:///C:/b/s/w/ir/tests/co19/src/LibTest/io/Stdin/readByteSync_A01_t01.dart" test
- pid 7028; Handles: 78; Exe: C:\b\s\w\ir\out\DebugX64\crashpad_handler.exe; Cmd: C:\b\s\w\ir\out\DebugX64\crashpad_handler.exe --database=C:\b\s\w\ir\crashes --metrics-dir=C:\b\s\w\ir\crashes --initial-client-data=0x184,0x188,0x18c,0x180,0x190,0x1413c6a58,0x1413c6a68,0x1413c6a28
Terminating 2 processes:
- 5352 killed
- 7028 killed
*** Swarming tried multiple times to delete the C:\b\s\w\ir directory and failed ***
*** Hard failing the task ***

https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket.appspot.com/8865042100554160880/+/steps/vm_co19_nnbd_tests_in_weak_mode_with_asserts_shard_3/0/logs/task_stdout_stderr:_vm_co19_nnbd_tests_in_weak_mode_with_asserts_shard_3/0
Failed to delete C:\b\s\w\ir. The following files remain:
- \\?\C:\b\s\w\ir
- \\?\C:\b\s\w\ir\out
- \\?\C:\b\s\w\ir\out\DebugX64
- \\?\C:\b\s\w\ir\out\DebugX64\crashpad_handler.exe
- \\?\C:\b\s\w\ir\out\DebugX64\dart-sdk
- \\?\C:\b\s\w\ir\out\DebugX64\dart-sdk\bin
- \\?\C:\b\s\w\ir\out\DebugX64\dart-sdk\bin\dart.exe
- \\?\C:\b\s\w\ir\out\DebugX64\dart.exe
- \\?\C:\b\s\w\ir\out\DebugX64\dbghelp.dll
Enumerating processes:
- pid 5384; Handles: 114; Exe: C:\b\s\w\ir\out\DebugX64\dart.exe; Cmd: C:\b\s\w\ir\out\DebugX64\dart.exe  "--enable-experiment=non-nullable file:///C:/b/s/w/ir/tests/co19/src/LibTest/io/Stdin/readByteSync_A01_t02.dart" test
- pid 8900; Handles: 78; Exe: C:\b\s\w\ir\out\DebugX64\crashpad_handler.exe; Cmd: C:\b\s\w\ir\out\DebugX64\crashpad_handler.exe --database=C:\b\s\w\ir\crashes --metrics-dir=C:\b\s\w\ir\crashes --initial-client-data=0x184,0x188,0x18c,0x180,0x190,0x1413c6a58,0x1413c6a68,0x1413c6a28
Terminating 2 processes:
- 5384 killed
- 8900 killed
*** Swarming tried multiple times to delete the C:\b\s\w\ir directory and failed ***
*** Hard failing the task ***

https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket.appspot.com/8865042100554160880/+/steps/vm_co19_nnbd_tests_in_strong_mode_shard_4/0/logs/task_stdout_stderr:_vm_co19_nnbd_tests_in_strong_mode_shard_4/0
And on vm-kernel-nnbd-win-release-x64:
Failed to delete C:\b\s\w\ir. The following files remain:
- \\?\C:\b\s\w\ir
- \\?\C:\b\s\w\ir\out
- \\?\C:\b\s\w\ir\out\ReleaseX64
- \\?\C:\b\s\w\ir\out\ReleaseX64\crashpad_handler.exe
- \\?\C:\b\s\w\ir\out\ReleaseX64\dart-sdk
- \\?\C:\b\s\w\ir\out\ReleaseX64\dart-sdk\bin
- \\?\C:\b\s\w\ir\out\ReleaseX64\dart-sdk\bin\dart.exe
- \\?\C:\b\s\w\ir\out\ReleaseX64\dart.exe
- \\?\C:\b\s\w\ir\out\ReleaseX64\dbghelp.dll
Enumerating processes:
- pid 5928; Handles: 78; Exe: C:\b\s\w\ir\out\ReleaseX64\crashpad_handler.exe; Cmd: C:\b\s\w\ir\out\ReleaseX64\crashpad_handler.exe --database=C:\b\s\w\ir\crashes --metrics-dir=C:\b\s\w\ir\crashes --initial-client-data=0x180,0x184,0x188,0x17c,0x18c,0x7ff647b86620,0x7ff647b86630,0x7ff647b86640
- pid 6904; Handles: 113; Exe: C:\b\s\w\ir\out\ReleaseX64\dart.exe; Cmd: out\ReleaseX64\dart.exe
Terminating 2 processes:
- 5928 killed
- 6904 killed
*** Swarming tried multiple times to delete the C:\b\s\w\ir directory and failed ***
*** Hard failing the task ***

https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket.appspot.com/8865042100554160864/+/steps/vm_nnbd_tests_in_weak_mode_with_asserts_shard_4/0/logs/task_stdout_stderr:_vm_nnbd_tests_in_weak_mode_with_asserts_shard_4/0

Another similar failure on vm-kernel-win-release-x64:
Failed to delete C:\b\s\w\ir. The following files remain:
- \\?\C:\b\s\w\ir
- \\?\C:\b\s\w\ir\out
- \\?\C:\b\s\w\ir\out\ReleaseX64
- \\?\C:\b\s\w\ir\out\ReleaseX64\crashpad_handler.exe
- \\?\C:\b\s\w\ir\out\ReleaseX64\dart.exe
- \\?\C:\b\s\w\ir\out\ReleaseX64\dbghelp.dll
Enumerating processes:
- pid 1328; Handles: 113; Exe: C:\b\s\w\ir\out\ReleaseX64\dart.exe; Cmd: C:\b\s\w\ir\out\ReleaseX64\dart.exe stream_lib.dart "Hi, stdout" "Hi, stderr"
- pid 10328; Handles: 78; Exe: C:\b\s\w\ir\out\ReleaseX64\crashpad_handler.exe; Cmd: C:\b\s\w\ir\out\ReleaseX64\crashpad_handler.exe --database=C:\b\s\w\ir\crashes --metrics-dir=C:\b\s\w\ir\crashes --initial-client-data=0x180,0x184,0x188,0x17c,0x18c,0x7ff69fbc6620,0x7ff69fbc6630,0x7ff69fbc6640
Terminating 2 processes:
- 1328 killed
- 10328 killed
*** Swarming tried multiple times to delete the C:\b\s\w\ir directory and failed ***
*** Hard failing the task ***

https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket.appspot.com/8864995426008441616/+/steps/vm_co19_tests_shard_3/0/logs/task_stdout_stderr:_vm_co19_tests_shard_3/0
It looks like all Windows bots are affected by this problem.

The recent hanging process https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket.appspot.com/8862167650803506432/+/steps/vm_tests_shard_5/0/logs/task_stdout_stderr:_vm_tests_shard_5/0
=== 1275 tests passed, 53 failed ===
***************** Killing dart *****************
Hanging process info:
  PID: 11208
  Command line: out\ReleaseX64\dart.exe --disable-dart-dev --pause-isolates-on-start --pause-isolates-on-exit --write-service-info=file:///C:/b/s/w/itet6u6n/dart_servicea248110b/service_info.json --profiler -DUSE_DDS=true --ignore-unrecognized-flags --packages=C:\b\s\w\ir\.packages --enable-vm-service:0 C:\b\s\w\ir\runtime\observatory_2\tests\service_2\next_through_await_for_test.dart
Killed pid: 11208
***************** Killing gen_snapshot *****************
  No gen_snapshot processes found.
***************** Killing dart_precompiled_runtime *****************
  No dart_precompiled_runtime processes found.
INFO: Enabling coredump archiving into C:\b\s\w\ir\crashes
INFO: Core dump archiving is activated
INFO: No unexpected crashes recorded
Failed to delete C:\b\s\w\ir (6 files remaining).
  Maybe the test has a subprocess outliving it.
  Sleeping 2 seconds.
Failed to delete C:\b\s\w\ir (6 files remaining).
  Maybe the test has a subprocess outliving it.
  Sleeping 4 seconds.
Failed to delete C:\b\s\w\ir. The following files remain:
- \\?\C:\b\s\w\ir
- \\?\C:\b\s\w\ir\out
- \\?\C:\b\s\w\ir\out\ReleaseX64
- \\?\C:\b\s\w\ir\out\ReleaseX64\crashpad_handler.exe
- \\?\C:\b\s\w\ir\out\ReleaseX64\dart.exe
- \\?\C:\b\s\w\ir\out\ReleaseX64\dbghelp.dll
Enumerating processes:
- pid 9464; Handles: 78; Exe: C:\b\s\w\ir\out\ReleaseX64\crashpad_handler.exe; Cmd: C:\b\s\w\ir\out\ReleaseX64\crashpad_handler.exe --database=C:\b\s\w\ir\crashes --metrics-dir=C:\b\s\w\ir\crashes --initial-client-data=0x180,0x184,0x188,0x17c,0x18c,0x7ff778985600,0x7ff778985610,0x7ff778985620
- pid 11208; Handles: 164; Exe: C:\b\s\w\ir\out\ReleaseX64\dart.exe; Cmd: out\ReleaseX64\dart.exe --disable-dart-dev --pause-isolates-on-start --pause-isolates-on-exit --write-service-info=file:///C:/b/s/w/itet6u6n/dart_servicea248110b/service_info.json --profiler -DUSE_DDS=true --ignore-unrecognized-flags --packages=C:\b\s\w\ir\.packages --enable-vm-service:0 C:\b\s\w\ir\runtime\observatory_2\tests\service_2\next_through_await_for_test.dart
Terminating 2 processes:
- 9464 killed
- failed to kill 11208, error [Error 5] Access is denied
Enumerating processes:
- pid 11208; Handles: 164; Exe: C:\b\s\w\ir\out\ReleaseX64\dart.exe; Cmd: out\ReleaseX64\dart.exe --disable-dart-dev --pause-isolates-on-start --pause-isolates-on-exit --write-service-info=file:///C:/b/s/w/itet6u6n/dart_servicea248110b/service_info.json --profiler -DUSE_DDS=true --ignore-unrecognized-flags --packages=C:\b\s\w\ir\.packages --enable-vm-service:0 C:\b\s\w\ir\runtime\observatory_2\tests\service_2\next_through_await_for_test.dart
Terminating 1 processes:
- failed to kill 11208, error [Error 5] Access is denied
Enumerating processes:
- pid 11208; Handles: 164; Exe: C:\b\s\w\ir\out\ReleaseX64\dart.exe; Cmd: out\ReleaseX64\dart.exe --disable-dart-dev --pause-isolates-on-start --pause-isolates-on-exit --write-service-info=file:///C:/b/s/w/itet6u6n/dart_servicea248110b/service_info.json --profiler -DUSE_DDS=true --ignore-unrecognized-flags --packages=C:\b\s\w\ir\.packages --enable-vm-service:0 C:\b\s\w\ir\runtime\observatory_2\tests\service_2\next_through_await_for_test.dart
Terminating 1 processes:
- failed to kill 11208, error [Error 5] Access is denied
Failed to terminate processes.
2144 2020-11-30 22:42:54.339 E: rmtree(u'C:\\b\\s\\w\\ir') failed: [Error 5] Access is denied: u'\\\\?\\C:\\b\\s\\w\\ir\\out\\ReleaseX64\\crashpad_handler.exe'
*** Swarming tried multiple times to delete the C:\b\s\w\ir directory and failed ***

Flaky->timeout again log
--- Command "vm" (took 04:00.000604s):
DART_CONFIGURATION=ReleaseXARM64 out/ReleaseXARM64/dart -DUSE_DDS=true -Dtest_runner.configuration=dartk-linux-release-arm64 --ignore-unrecognized-flags --packages=/b/s/w/ir/.packages /b/s/w/ir/runtime/observatory_2/tests/service_2/debugger_location_test.dart

exit code:
null

diagnostics:
Process list including children: [24019, 24781]
Trying to capture stack trace for pid 24019
Unable to capture stack traces: ProcessException: No such file or directory
  Command: eu-stack -p 24019
Trying to capture stack trace for pid 24781
Unable to capture stack traces: ProcessException: No such file or directory
  Command: eu-stack -p 24781

stdout:
00:00 +0: debugger_location_test.dart (DDS)

** Launching SERVICE_TEST_TESTEE=true out/ReleaseXARM64/dart --disable-dart-dev --write-service-info=file:///b/s/w/it_eipcf1r/dart_serviceTHXSEJ/service_info.json --profiler -DUSE_DDS=true -Dtest_runner.configuration=dartk-linux-release-arm64 --ignore-unrecognized-flags --packages=/b/s/w/ir/.packages --enable-vm-service:0 /b/s/w/ir/runtime/observatory_2/tests/service_2/debugger_location_test.dart

>testee>out> The Dart VM service is listening on http://<IP_ADDRESS>:40795/iVxpvoOEjZs=/

>testee>out>

** Signaled to run test queries on http://<IP_ADDRESS>:42957/P0vIZCQplyY=/ (DDS)

Loading VM...

Done loading VM

Running debugger_location_test.dart [1/11]

Paused with PauseBreakpoint

Running debugger_location_test.dart [2/11]

Running debugger_location_test.dart [3/11]

Running debugger_location_test.dart [4/11]

Running debugger_location_test.dart [5/11]

Running debugger_location_test.dart [6/11]

Running debugger_location_test.dart [7/11]

Running debugger_location_test.dart [8/11]

--- Re-run this test:
python3 tools/test.py -n dartk-linux-release-arm64 service_2/debugger_location_test/dds

Simarm flaky -> timeout https://dart-ci.appspot.com/log/vm-kernel-nnbd-linux-release-simarm64/dartk-strong-linux-release-simarm64/867/service/debugger_location_test/dds


Control Panel Switch - Control Panel doesnt show up again.

Hello, its me again.
When i hide the Smalltime control panel, i cant show it up again by clicking the button. I have to restart the world. Then the button reacts and the control panel appears again.
Tested in:

System: Das Schwarze Auge/The Dark Eye (5th Edition)
Foundry Version 0.7.10 and 0.8.6

Hmm. So DSA doesn't run under 0.8.6 yet, and I can't reproduce this behaviour under 0.7.10.

I run the unofficial releaser version... but i thougt this also happend to me in 0.7.9... i will try further tests an write the outcome here.

Can repo this issue, Clicking the button to show the panel after it's been hidden makes it not show up. Additionally the panel just doesn't show up for players at all.

@yoshisman8 What Foundry and game system versions?

Can't repro this, and haven't received any further info; closing for now.


#299 Set OS from SCC Results

Loading an SCC scan by itself does not set the OS or applied checklists. From the cdf:target-facts tag:
<cdf:fact name="urn:scap:fact:asset:identifier:os_name" type="string">Windows Server 2008 R2 Datacenter</cdf:fact>
<cdf:fact name="urn:scap:fact:asset:identifier:os_version" type="string">Windows Server 2008 R2 Datacenter</cdf:fact>
<cdf:fact name="urn:scap:fact:asset:identifier:processor" type="string">Intel(R) Core(TM) i7-4800MQ CPU @ 2.70GHz</cdf:fact>
<cdf:fact name="urn:scap:fact:asset:identifier:processor_architecture" type="string">Intel64 Family 6 Model 60 Stepping 3</cdf:fact>
Sagacity should set the OS and associated checklists based on the SCC contents. The next bug will be to apply the scanned checklist to the host.

Pretty sure this happens now.


fix(test): resolve TODO in integration test for log message validation

Description

all tests passed

...

solved a TODO from  apps/generator/test/integration.test.js  [  /*TODO:
Include log message test in the future to ensure that the log.debug for skipping overwrite is called
*/]

Related issue(s)

@Light13008 hey, you need to update your PR with latest master, there are some conflicts


Error when baking brand new razor template site

Just installed pretzel <IP_ADDRESS> from chocolatey and went to make a new razor site and got an error
C:\site>pretzel create -t=razor
starting pretzel...
create - configure a new site
Using razor Engine
Pretzel site template has been created

C:\site>pretzel bake
starting pretzel...
bake - transforming content into a website
Recommended engine for directory: 'razor'
Failed to render template, falling back to direct content
done - took 5808ms

C:\site>

Not sure which template it is actually failing on as most of the site seems to have been generated.

It looks like in SiteConextGenerator.cs there is this code:
html = Path.GetExtension(file).IsMarkdownFile()
    ? CommonMark.CommonMarkConverter.Convert(contentsWithoutHeader).Trim()
    : contentsWithoutHeader;

the html generated by CommonMark.CommonMarkConvert.Convert is not valid for a razor template.  It contains html entities like > that cause the razor engine to fail.

Thanks for the feedbak.
Normally this is fixed with the current master branch, can you try it?
You can find the latest binaries on AppVeyor.

Works when built from master branch (5df3cfaae513888edef4d205f5e1857731c92551).  You guys should either release a new version or at least update the docs to reflect that <IP_ADDRESS> isn't a good version.  I was already moving to the master branch because I found it fixed issue #199 which is a pretty big deal too if you ask me.

I plan to release the v0.3 soon but before I want to fix some recent feedback like yours.


[Bug]: db:migrate failed

What happened?
db error: ERROR: cannot alter type of a column used by a view or rule
DETAIL: rule _RETURN on view "ImageResourceHelper" depends on column "name"
   0: sql_migration_connector::validate_migrations
           with namespaces=None
             at migration-engine\connectors\sql-migration-connector\src\lib.rs:301
   1: migration_core::state::DevDiagnostic
             at migration-engine\core\src\state.rs:269

Happening after a fresh clone of main branch and following the steps described in the readme.
Step 5 is where it fails. Ive never worked with this db framework so no idea whats going wrong here.
Is there a faulty config/file on my side or something with repo?
Steps to reproduce the problem
Follow the readme steps till step 5.
What should have happened?
Succesful migration.
What platforms do you use to access the site?
No response
What browsers do you use to access the site?
No response
Additional information, context and logs
No response

There were some bad migrations in the main branch, but we pushed new changes recently which fixes the issue. Please pull latest from main and try again.


hostapp-update-hooks: Don't fail if efivars fs already mounted

This prevents the following error and hup abort when sysfs is bind-mounted in the hostapp-update container:
mount: /sys/firmware/efi/efivars: efivarfs already mounted or mount point busy.
Changelog-entry: hostapp-update-hooks: Don't fail if efivars fs already mounted
Addresses one failure in https://github.com/balena-os/meta-balena/pull/3194

Investigating test failures in https://github.com/balena-os/balena-intel/pull/676

Self-certifying based on genericx86-64-exit pass in https://github.com/balena-os/meta-balena/pull/3194
jenkins-leviathan-v2-template-24000-client-1  | [2023-08-10T11:07:31.161Z][worker-hup] Test suite has exited with: PASS

Once this PR is merged, meta-balena 3194 should no longer fail for the generic-amd64 either.

@balena-ci I self-certify!


chore: bdd-spring-1572418009 to 0.0.1

chore: Promote bdd-spring-1572418009 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


IncludedService should be immutable

Composer uses async patterns, thus all relevant classes should be immutable to be thread safe

Closed by #19


Don't merge! Regression pull request perf test for no metavalidation

Docs Build status updates of commit 0f3fdb6:
:clock10: Pending: waiting for processors (17 builds ahead of you)
:warning: Docs Build is busy, currently there are 17 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit 0f3fdb6:
:clock10: Full build: the average full build time is 10 min(s) 21 sec(s), this is based on the last 22 build(s) for this repository.

Docs Build status updates of commit 0f3fdb6:
:warning: Validation status: warnings

File
Status
Preview URL
Details
Dependent Files

developer/TestingPullRequest.md
:warning:Warning
View
Details

developer/TestingPullRequest.md

[Warning] Metadata with following name(s) are not allowed to be set in Yaml header, or as file level metadata in docfx.json, or as global metadata in docfx.json: content_type. They are generated by Docs platform, so the values set in these 3 places will be ignored. Please remove them from all 3 places to resolve the warning.
[Warning] the value invalid_type is undefined for metadata content_type
Line 7: [Warning] Invalid file link:(~/../nonexisted1.md).
Line 8: [Warning] Invalid file link:(~/../nonexisted2.md).
Line 9: [Warning] Invalid file link:(~/../nonexisted3.md).

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit f396ba7:
:clock10: Pending: waiting for processors (21 builds ahead of you)
:warning: Docs Build is busy, currently there are 21 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit f396ba7:
:warning: Validation status: warnings

File
Status
Preview URL
Details
Dependent Files

developer/TestingPullRequest.md
:warning:Warning
View
Details

.openpublishing.publish.config.json
:white_check_mark:Succeeded

developer/TestingPullRequest.md

[Warning] Metadata with following name(s) are not allowed to be set in Yaml header, or as file level metadata in docfx.json, or as global metadata in docfx.json: content_type. They are generated by Docs platform, so the values set in these 3 places will be ignored. Please remove them from all 3 places to resolve the warning.
[Warning] the value invalid_type is undefined for metadata content_type
Line 7: [Warning] Invalid file link:(~/../nonexisted1.md).
Line 8: [Warning] Invalid file link:(~/../nonexisted2.md).
Line 9: [Warning] Invalid file link:(~/../nonexisted3.md).

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Cut report last message to specified length

Details

Cut last message of a report to specific length, because we only use last message as alternate text on RHN and LHN.
Fixed Issues

$ https://github.com/Expensify/App/issues/6699
Tests

Send large text message
Open developer tools and search for alternateText showed in LHN and RHN on that room.
Alternate text should contains trimmed last message and doesn't contain full length of last message
Repeat steps above for sending IOU reques, receive new message and receive new IOU message.

QA Steps

Send large text message
Open developer tools and search for alternateText showed in LHN and RHN on that room.
Alternate text should contains trimmed last message and doesn't contain full length of last message
Repeat steps above for sending IOU reques, receive new message and receive new IOU message.

Tested On

[x] Web
[ ] Mobile Web
[ ] Desktop
[ ] iOS
[ ] Android

Screenshots

Web

Mobile Web

Desktop

iOS

Android

🚀 Deployed to staging by @Julesssss in version: 1.1.30-4 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by @chiragsalian in version: 1.1.31-1 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


[Bug] 部署llama2-13B int4量化报错，提示权重文件不存在

Checklist

[X] 1. I have searched related issues but cannot get the expected help.
[X] 2. The bug has not been fixed in the latest version.

Describe the bug
使用从HuggingFace下载的Llama2-13B在部署服务时，在int4量化之前可以正常部署服务，量化后无法使用service_docker_up.sh部署trition server，提示找不到权重文件，例如找不到layers.24.feed_forward.w1.0.qweight，但量化后权重只有layers.24.feed_forward.w2.0.qweight。
使用 python3 -m lmdeploy.turbomind.chat ./workspace 可以正常推理量化模型
使用的docker image：openmmlab/lmdeploy:latest
docker image内lmdeploy版本是0.0.2
量化模型使用的lmdeploy版本是0.0.5
Reproduction

calibrate量化权重
python3 -m lmdeploy.lite.apis.calibrate
--model /mnt/disk3/Llama-2-13b-chat-hf
--calib_dataset 'c4'
--calib_samples 128
--calib_seqlen 2048
--work_dir /mnt/disk3/llama-13b-int4

int4量化
python3 -m lmdeploy.lite.apis.auto_awq
--model /mnt/disk3/Llama-2-13b-chat-hf
--w_bits 4
--w_group_size 128
--work_dir /mnt/disk3/llama-13b-int4 \

deploy部署
python3 -m lmdeploy.serve.turbomind.deploy
--model-name llama2
--model-path /mnt/disk3/llama2-13b-int4
--model-format awq
--group-size 128

拉起docker
bash ./workspace/service_docker_up.sh

Error traceback
类似这种提示
[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.23.feed_forward.w2.0.scales cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.23.feed_forward.w2.0.zeros cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.24.attention.w_qkv.0.scales cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.24.attention.w_qkv.0.zeros cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.24.attention.wo.0.scales cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.24.attention.wo.0.zeros cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.24.feed_forward.w1.0.qweight cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.24.feed_forward.w1.0.scales cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.24.feed_forward.w1.0.zeros cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.24.feed_forward.w3.0.qweight cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.24.feed_forward.w3.0.scales cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.24.feed_forward.w3.0.zeros cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.24.feed_forward.w2.0.scales cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.24.feed_forward.w2.0.zeros cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.25.attention.w_qkv.0.scales cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.25.attention.w_qkv.0.zeros cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.25.attention.wo.0.scales cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.25.attention.wo.0.zeros cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.25.feed_forward.w1.0.qweight cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.25.feed_forward.w1.0.scales cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.25.feed_forward.w1.0.zeros cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.25.feed_forward.w3.0.qweight cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.25.feed_forward.w3.0.scales cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.25.feed_forward.w3.0.zeros cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.25.feed_forward.w2.0.scales cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.25.feed_forward.w2.0.zeros cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.26.attention.w_qkv.0.scales cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.26.attention.w_qkv.0.zeros cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.26.attention.wo.0.scales cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.26.attention.wo.0.zeros cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.26.feed_forward.w1.0.qweight cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.26.feed_forward.w1.0.scales cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.26.feed_forward.w1.0.zeros cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.26.feed_forward.w3.0.qweight cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.26.feed_forward.w3.0.scales cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.26.feed_forward.w3.0.zeros cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.26.feed_forward.w2.0.scales cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.26.feed_forward.w2.0.zeros cannot be opened, loading model fails!

[TM][WARNING] file /workspace/models/model_repository/turbomind/1/weights/layers.27.attention.w_qkv.0.scales cannot be opened, loading model fails!

感觉docker image不是最新的。还请重新 docker pull openmmlab/lmdeploy:latest

重新拉取镜像后可以正常使用了，image里面lmdeploy version是最新的0.0.5


Fix C++ distribtest

Looks like C++ distribtest has been broken for a while.
Fixing it by explicitly dividing distrib tests into two categories - tests that require cloning the entire repo with submodules (currently only C++) and tests that only need to copy the test/distrib directory (all other langs).
See https://github.com/grpc/grpc/issues/10788

No significant performance differences

Additional though; would this be really messy to add to mac and windows since we wouldn't be able to use docker? It might be nice to ensure that the examples build and run in more environments

@ncteisen   yes,  adding more distribtests (like mac and windows) is generally a good idea (and we do have windows and mac distribtests for some other languages like C# or node.js), but we need to think carefully what to add - tests need to have sufficient added value to make things worth it - someone needs to watch the results, maintain them and our computation resources are also a bit limited right now.
In the ideal world, we would run  artifact - build packages - distribtest  flow on each PR to prevent package breakages in our release branches (we always have to fix something, this time c-ares is causing issues) but currently it takes too long to run them and there are other complications - I have some WIP toward making this possible.
Once distribtest that I really want to introduce is a "cmake" distrib tests - where a cmake based example project depends on gRPC and we verify that works well.

That makes sense.
Also, w.r.t. this PR, the Basic Tests Linux still haven't run. Could that be caused by this change? I looked at some more recent PRs and that tests has run for them

test this please

No significant performance differences

Known failures:
https://github.com/grpc/grpc/pull/10877
https://github.com/grpc/grpc/issues/10807
https://github.com/grpc/grpc/issues/10878
Portability Linux: TODO

Artifact build: https://grpc-testing.appspot.com/view/Artifacts/job/gRPC_build_artifacts/3307/

Distribtests results here: https://grpc-testing.appspot.com/view/Artifacts/job/gRPC_distribtest/3222/


Update workflows and dependencies

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (a472857) to head (d93c4b8).

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #444   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           94        94
  Lines         2439      2439
  Branches       211       211
=========================================
  Hits          2439      2439

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


[BUG]:  Problem type with loadStripe

What happened?
When you use Elements with a stripePromise, you have a error type.
In the documentation, we will have to use it this way:
` const stripePromise = loadStripe('pk_test_oKhSR5nslBRnBZpjO6KuzZeX');

export default function App() {
  const options = {
    // passing the client secret obtained from the server
    clientSecret: '{{CLIENT_SECRET}}',
  };

  return (
    <Elements stripe={stripePromise} options={options}>
      <CheckoutForm />
    </Elements>
  );
};`

But a type error appear:
error TS2322: Type 'Promise<Stripe | null>' is not assignable to type 'Stripe | PromiseLike<Stripe | null> | null'.   Type 'Promise<Stripe | null>' is not assignable to type 'PromiseLike<Stripe | null>'.      Types of property 'then' are incompatible.       Type '<TResult1 = Stripe | null, TResult2 = never>(onfulfilled?: ((value: Stripe | null) => TResult1 | PromiseLike<TResult1>) | null | undefined, onrejected?: ((reason: any) => TResult2 | PromiseLike<...>) | ... 1 more ... | undefined) => Promise<...>' is not assignable to type '<TResult1 = Stripe | null, TResult2 = never>(onfulfilled?: ((value: Stripe | null) => TResult1 | PromiseLike<TResult1>) | null | undefined, onrejected?: ((reason: any) => TResult2 | PromiseLike<...>) | ... 1 more ... | undefined) => PromiseLike<...>'.          Types of parameters 'onfulfilled' and 'onfulfilled' are incompatible.            Types of parameters 'value' and 'value' are incompatible.
Currently we are using stripe-js 2.4.0, at this time everything was good. And we updated to 3.0.6, the error appeared at that time
Environment
No response
Reproduction
No response

Experiencing the same issue, but with EmbeddedCheckoutProvider and not Elements:

@stripe/stripe-js 3.0.10
@stripe/react-stripe-js 2.6.2
typescript 5.4.2

Running the same setup in another project but with @stripe/stripe-js  2.2.0, no issues there.

Not the same as #566, but similar. But anyways this is fixed for me in 3.1.0.

Here to report the same, resolved with 3.1.0, thanks 👍🏼


Expand commit file list height issue

Description
When showing the list of files of commits, the option to expand/collapse the file list is not visually working properly.
When expanding the list, the area showing the list is too small in height.
It should cover the entire height of the page, but it only shows one or two lines with a vertical scrollbar.
This makes showing the list useless as you do not have a clear overview of the files. You need to use the scrollbar which is terrible.
Screenshots

Gitea Version
1.19.0+3-g782c376c8 built with GNU Make 4.1, go1.20.2 : bindata, sqlite, sqlite_unlock_notify
Can you reproduce the bug on the Gitea demo site?
No
Operating System
Server=Linux ARM64, client=Windows 10
Browser Version
Firefox & Chrome

Here a screenshot when using the scrollbar. It clearly shows that the file list area is just a few lines in height.

It has been fixed on latest nightly build.
Download the binary from https://dl.gitea.com/gitea/1.19/

Yes, using latest build:
1.19.0+37-g8b3dd7de5 built with GNU Make 4.1, go1.20.2 : bindata, sqlite, sqlite_unlock_notify
The issue is indeed solved, see screenshot below:


Fixed missing translations of config options (Fixes #2193)

Fixes also #2245

Ok. Travis failed. Fix this, then merge.

Travis fixed.


Test-AdfCode Assumes Factory has Global Parameters

Released in 0.74 - Test-AdfCode began failing as it was validating the Factory and config files.
In our usage, we do not use global parameters so our json does not contain the properties or global parameters node.
To Reproduce
Factory json looks like example
{ 	"name": "yournamehere", 	"location": "centralus", 	}
Test-AdfCode -RootFolder .\

Expected behaviour
I expect Test-AdfCode to be able to handle this case
Screenshots

Version of PowerShell module of:

azure.datafactory.tools 0.74

We got around this issue for now by adding empty properties and globalparameters nodes in the json

Faced the same issue. Tried to add empty properties and globalParameters but still got error because it seemed also requiring deployment/config-{env}.csv (or json) file while in my case I don't use such config file.
So I just go the previous version (0.70.0-preview) until this problem resolved.

I did not hit that - but an empty config file will also blow up as well.
I'm going to spin up a branch - I've read through the code and all looks easy enough to account for.

Released in ver.0.75
https://www.powershellgallery.com/packages/azure.datafactory.tools/0.75.0


The process manager window style is not valid

Type: Bug
When I open the process manager through the help menu, I find that the window is not a VS Code custom style. Is this an unsolved problem? Or are there limitations in the application of custom window styles?
VS Code version: Code 1.76.0 (92da9481c0904c6adfe372c12da3b7748d74bdcb, 2023-03-01T10:25:16.105Z)
OS version: Linux x64 5.18.17-amd64-desktop-community-hwe
Modes:
Sandboxed: No

System Info

Item
Value

CPUs
11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz (8 x 2400)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: disabled_softwarevideo_encode: disabled_softwarevulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off

Load (avg)
2, 2, 2

Memory (System)
23.29GB (8.15GB free)

Process Argv
--unity-launch --crash-reporter-id e31d5c4b-dbe6-44a7-8a42-42f22285ca34

Screen Reader
no

VM
0%

DESKTOP_SESSION
deepin

XDG_CURRENT_DESKTOP
Deepin

XDG_SESSION_DESKTOP
deepin

XDG_SESSION_TYPE
x11

Extensions (23)

Extension
Author (truncated)
Version

vscode-eslint
dba
2.4.0

gitlens
eam
13.3.2

vsc-material-theme-icons
equ
2.6.1

prettier-vscode
esb
9.10.4

go
gol
0.38.0

Ionide-fsharp
Ion
7.5.1

vscode-language-pack-zh-hans
MS-
1.76.2023030809

csharp
ms-
1.25.4

dotnet-interactive-vscode
ms-
1.0.4152020

vscode-dotnet-pack
ms-
1.0.12

jupyter
ms-
2023.2.1000592019

jupyter-keymap
ms-
1.1.0

jupyter-renderers
ms-
1.0.15

vscode-jupyter-cell-tags
ms-
0.1.6

vscode-jupyter-slideshow
ms-
0.1.5

remote-ssh
ms-
0.98.0

remote-ssh-edit
ms-
0.84.0

vscode-remote-extensionpack
ms-
0.24.0

remote-explorer
ms-
0.2.0

remote-server
ms-
1.0.0

vetur
oct
0.37.3

volar
Vue
1.2.0

vscode-typescript-vue-plugin
Vue
1.2.0

A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593cf:30376535
pythonvs932:30410667
cppdebug:30492333
vsclangdc:30486549
c4g48928:30535728
dsvsc012cf:30540253
pynewvextcfv2:30681851
azure-dev_surveyone:30548225
vscccc:30610679
pyindex848:30662994
nodejswelcome1cf:30587006
282f8724:30602487
pyind779:30671433
f6dab269:30613381
pythonsymbol12:30671437
showlangstatbar:30672706
vsccsb:30677849

No, what I mean is that all Windows should have a consistent window look when set to custom draw Windows, because it turns out that some Windows don't

2023年3月14日 20:16，Daniel Imms @.***> 写道：
Do you mean the window style as in how it has a native window, not a custom drawn one like the code editor?
https://user-images.githubusercontent.com/2193314/224998248-11c2f96f-77d1-48db-9b1e-60372c6589e9.png
If so, this is by design and it's not worth doing the custom window for the process manager or similar windows like the issue reporter imo.
—
Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode/issues/176605#issuecomment-1467999674, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKQI5JH2MZJCE7ILN55J7U3W4BOSHANCNFSM6AAAAAAVUWRQQU.
You are receiving this because you authored the thread.

You said no, but it sounds like that is what you're talking about? In an ideal world we would do this, but it's not worth the engineering effort to get our custom style working in these auxiliary windows.

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.
If you wonder what we are up to, please see our roadmap and issue reporting guidelines.
Thanks for your understanding, and happy coding!


Not Working on OP7Pro

Kirisakura Kernel (custom) on OB4. When I tap the QS tile nothing happens, and it's stuck on 90hz.
Don't think the kernel is breaking it, but idk I might just test with stock

Hi, I would need some further details about the issue you have.
1.- Have you grant the WRITE_SECURE_SETTINGS permission?
2.- Do any toast notification appear?
3.- Paste the output running this command via adb adb shell settings list global | grep oneplus

Thanks, worked after I granted write secure settings permission through adb as it never prompted me


Hannahjump uprating2020

Updating amounts for parental leave for tax year beginning 2020

When merging this (when it's ready post-fact-check), please squash the commits manually or hit "squash and merge" button on GitHub and re-word the title. Thanks!


Non occurencies support

What is the status of non-occuriences support in sequences and patterns?

That can be implemented as below
from arrivals_stream#window.time(2 minutes)
select *
insert expired events into overdue_deliveries_stream;

from every arrivalEvent = arrivals_stream ->
deliveryEvent = deliveries_stream[arrivalEvent.trackingId == trackingId]
    or overdue_delivery = overdue_deliveries_stream[arrivalEvent.trackingId == trackingId]
select arrivalEvent.trackingId as trackingId, arrivalEvent.customerName as customerName, arrivalEvent.telephoneNo as telephoneNo, deliveryEvent.trackingId as deliveryId
insert into filter_stream;

from filter_stream [ isNull(deliveryId)]
select trackingId, customerName, telephoneNo
insert into alert_stream;

For more info refer:
https://docs.wso2.com/display/CEP400/Sample+0111+-+Detecting+non-occurrences+with+Patterns


How is the threshold formula derived？

Hello, I would like to know what is the principle of setting the threshold formula? What does that mean in mathematical physics? How did you get it?I'm very much looking forward to hearing from you！

This code provides an emulation of the Surface Simplification Using Quadric Error Metrics described by Garland and Heckbert. The Approximating Error With Quadrics section describes the cost function. With this implementation iterations continue until the number of remaining triangles reaches the target_count. The present implementation is very fast because it only re-computes the error metrics occasionally, so it is very fast though the solution may not be quite the theoretical optimal.

Thank you for your answer. I would also like to know the specific meaning of the threshold formula. How is it obtained?double threshold = 0.000000001 * Math.Pow(iteration + 3, simplificationOptions.Agressiveness);`

I assume this threshold was chosen pragmatically, and it has stood the test of time. This parameter is just a tradeoff for speed and quality. The idea is that with a low (slow but precise) aggressiveness many iterations will be done that only create tiny changes in the original mesh, while are higher levels more dramatic errors are tolerated to allow the algorithm to quickly reach the desired level of simplification.


Create Blog "The multicore software triad"

See https://web.archive.org/web/20081227235517/http://www.cilk.com/multicore-blog/bid/4983/The-Multicore-Software-Triad

Summary of blog: The CilkArts team interviewed scores of software companies about their needs and these three items stood out:
-Development time
-Software reliability
-Application performance
90% of respondents said 2 out of 3 was not enough. Have to have all 3!
Then a description of how OpenCilk provides all 3.


Create Blazor WebAssembly Standalone app with Aspire, build fails with error: There was no runtime pack for Microsoft.AspNetCore.App available for the specified RuntimeIdentifier 'browser-wasm'

INSTALL STEPS

Clean machine: Win11 x64 23h2 ENU
Install VS 17.9 P1 from build main-34219.241
Install 8.0 RC 2 build 8.0.100-rtm.23519.30
Apply NuGet Feeds
Install Aspire workload

REPRO STEPS

In VS, new Blazor WebAssembly Standalone App > BlazorWasmApp1
Ctrl+F5, works fine
Right-click project > Add Aspire Orchestrator Support
Build solution

ACTUAL
Build fails

EXPECTED
Build to succeed.

Aspire dont work with Blazor Webassembly for me i got the error: "There was no runtime pack for Microsoft.AspNetCore.App available for the specified RuntimeIdentifier 'browser-wasm'"

I'm on Preview 3 and am still seeing this error with WASM?

here is minimal repo:
BlazorApp1.zip


Develop debugging envoy using vscode Container

windows 10
wsl2
vscode
branch:master
error:
Skipping proto_format.sh due to no API change
$TEST_TMPDIR defined: output root default is '/build/envoy-compdb' and max_idle_secs default is '15'.
Starting local Bazel server and connecting to it...
WARNING: /workspaces/envoy/test/proto/BUILD:30:23: in genrule rule //test/proto:bookstore_proto_descriptor: target '//test/proto:bookstore_proto_descriptor' depends on deprecated target '@com_google_protobuf//:well_known_protos': Prefer :well_known_type_protos instead.
INFO: Repository org_golang_google_protobuf instantiated at:
/workspaces/envoy/WORKSPACE:25:25: in
/workspaces/envoy/bazel/dependency_imports.bzl:92:18: in envoy_dependency_imports
Repository rule go_repository defined at:
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_gazelle/internal/go_repository.bzl:313:32: in
ERROR: An error occurred during the fetch of repository 'org_golang_google_protobuf':
Traceback (most recent call last):
File "/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_gazelle/internal/go_repository.bzl", line 247, column 17, in _go_repository_impl
fail("failed to fetch %s: %s" % (ctx.name, result.stderr))
Error in fail: failed to fetch org_golang_google_protobuf: fetch_repo<EMAIL_ADDRESS>Get<EMAIL_ADDRESS>dial tcp <IP_ADDRESS>:443: i/o timeout
ERROR: /workspaces/envoy/WORKSPACE:25:25: fetching go_repository rule //external:org_golang_google_protobuf: Traceback (most recent call last):
File "/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_gazelle/internal/go_repository.bzl", line 247, column 17, in _go_repository_impl
fail("failed to fetch %s: %s" % (ctx.name, result.stderr))
Error in fail: failed to fetch org_golang_google_protobuf: fetch_repo<EMAIL_ADDRESS>Get<EMAIL_ADDRESS>dial tcp <IP_ADDRESS>:443: i/o timeout
INFO: Repository kafka_server_binary instantiated at:
/workspaces/envoy/WORKSPACE:13:19: in
/workspaces/envoy/bazel/repositories.bzl:242:16: in envoy_dependencies
/workspaces/envoy/bazel/repositories.bzl:1236:26: in _kafka_deps
/workspaces/envoy/bazel/repositories.bzl:30:23: in external_http_archive
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/envoy_api/bazel/envoy_http_archive.bzl:16:17: in envoy_http_archive
Repository rule http_archive defined at:
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_tools/tools/build_defs/repo/http.bzl:372:31: in
INFO: Repository org_boost instantiated at:
/workspaces/envoy/WORKSPACE:13:19: in
/workspaces/envoy/bazel/repositories.bzl:210:15: in envoy_dependencies
/workspaces/envoy/bazel/repositories.bzl:474:26: in _org_boost
/workspaces/envoy/bazel/repositories.bzl:30:23: in external_http_archive
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/envoy_api/bazel/envoy_http_archive.bzl:16:17: in envoy_http_archive
Repository rule http_archive defined at:
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_tools/tools/build_defs/repo/http.bzl:372:31: in
INFO: Repository com_github_curl instantiated at:
/workspaces/envoy/WORKSPACE:13:19: in
/workspaces/envoy/bazel/repositories.bzl:197:21: in envoy_dependencies
/workspaces/envoy/bazel/repositories.bzl:854:26: in _com_github_curl
/workspaces/envoy/bazel/repositories.bzl:30:23: in external_http_archive
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/envoy_api/bazel/envoy_http_archive.bzl:16:17: in envoy_http_archive
Repository rule http_archive defined at:
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_tools/tools/build_defs/repo/http.bzl:372:31: in
INFO: Repository skywalking_data_collect_protocol instantiated at:
/workspaces/envoy/WORKSPACE:13:19: in
/workspaces/envoy/bazel/repositories.bzl:187:31: in envoy_dependencies
/workspaces/envoy/bazel/repositories.bzl:589:26: in _com_github_skyapm_cpp2sky
/workspaces/envoy/bazel/repositories.bzl:30:23: in external_http_archive
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/envoy_api/bazel/envoy_http_archive.bzl:16:17: in envoy_http_archive
Repository rule http_archive defined at:
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_tools/tools/build_defs/repo/http.bzl:372:31: in
INFO: Repository com_github_unicode_org_icu instantiated at:
/workspaces/envoy/WORKSPACE:13:19: in
/workspaces/envoy/bazel/repositories.bzl:179:32: in envoy_dependencies
/workspaces/envoy/bazel/repositories.bzl:386:26: in _com_github_unicode_org_icu
/workspaces/envoy/bazel/repositories.bzl:30:23: in external_http_archive
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/envoy_api/bazel/envoy_http_archive.bzl:16:17: in envoy_http_archive
Repository rule http_archive defined at:
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_tools/tools/build_defs/repo/http.bzl:372:31: in
ERROR: /workspaces/envoy/contrib/golang/filters/http/source/go/pkg/api/BUILD:5:11: //contrib/golang/filters/http/source/go/pkg/api:api depends on @org_golang_google_protobuf//types/known/anypb:anypb in repository @org_golang_google_protobuf which failed to fetch. no such package '@org_golang_google_protobuf//types/known/anypb': failed to fetch org_golang_google_protobuf: fetch_repo<EMAIL_ADDRESS>Get<EMAIL_ADDRESS>dial tcp <IP_ADDRESS>:443: i/o timeout
ERROR: Analysis of target '//contrib/golang/filters/http/source/go/pkg/api:api' failed; build aborted: Analysis failed
INFO: Elapsed time: 57.442s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (1261 packages loaded, 29655 targets configured)
currently loading: @proxy_wasm_cpp_sdk// ... (19 packages)
Fetching repository @com_github_cncf_xds_go; starting 41s
Fetching repository @com_github_lyft_protoc_gen_star; starting 39s
Fetching https://archive.apache.org/dist/kafka/3.3.1/kafka_2.13-3.3.1.tgz; 9.8 MiB (10,280,960B) 37s
Fetching https://boostorg.jfrog.io/artifactory/main/release/1.78.0/source/boost_1_78_0.tar.gz; 10.9 MiB (11,443,551B) 32s
Traceback (most recent call last):
File "/workspaces/envoy/tools/gen_compilation_database.py", line 127, in
fix_compilation_database(args, generate_compilation_database(args))
File "/workspaces/envoy/tools/gen_compilation_database.py", line 24, in generate_compilation_database
subprocess.check_call([args.bazel, "build"] + bazel_options + [
File "/usr/lib/python3.10/subprocess.py", line 369, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['bazel', 'build', '--config=compdb', '--remote_download_outputs=all', '--aspects=@bazel_compdb//:aspects.bzl%compilation_database_aspect', '--output_groups=compdb_files,header_files', '//source/...', '//test/...', '//contrib/...']' returned non-zero exit status 1.
2

windows 10
wsl2
vscode
branch:master
error:
Skipping proto_format.sh due to no API change
$TEST_TMPDIR defined: output root default is '/build/envoy-compdb' and max_idle_secs default is '15'.
Starting local Bazel server and connecting to it...
WARNING: /workspaces/envoy/test/proto/BUILD:30:23: in genrule rule //test/proto:bookstore_proto_descriptor: target '//test/proto:bookstore_proto_descriptor' depends on deprecated target '@com_google_protobuf//:well_known_protos': Prefer :well_known_type_protos instead.
Analyzing: 3997 targets (1112 packages loaded, 29259 targets configured)
Analyzing: 3997 targets (1112 packages loaded, 29259 targets configured)
INFO: Repository com_github_cncf_xds_go instantiated at:
/workspaces/envoy/WORKSPACE:25:25: in
/workspaces/envoy/bazel/dependency_imports.bzl:99:18: in envoy_dependency_imports
Repository rule go_repository defined at:
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_gazelle/internal/go_repository.bzl:313:32: in
ERROR: An error occurred during the fetch of repository 'com_github_cncf_xds_go':
Traceback (most recent call last):
File "/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_gazelle/internal/go_repository.bzl", line 247, column 17, in _go_repository_impl
fail("failed to fetch %s: %s" % (ctx.name, result.stderr))
Error in fail: failed to fetch com_github_cncf_xds_go: fetch_repo<EMAIL_ADDRESS>Get<EMAIL_ADDRESS>dial tcp <IP_ADDRESS>:443: i/o timeout
ERROR: /workspaces/envoy/WORKSPACE:25:25: fetching go_repository rule //external:com_github_cncf_xds_go: Traceback (most recent call last):
File "/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_gazelle/internal/go_repository.bzl", line 247, column 17, in _go_repository_impl
fail("failed to fetch %s: %s" % (ctx.name, result.stderr))
Error in fail: failed to fetch com_github_cncf_xds_go: fetch_repo<EMAIL_ADDRESS>Get<EMAIL_ADDRESS>dial tcp <IP_ADDRESS>:443: i/o timeout
INFO: Repository org_boost instantiated at:
/workspaces/envoy/WORKSPACE:13:19: in
/workspaces/envoy/bazel/repositories.bzl:210:15: in envoy_dependencies
/workspaces/envoy/bazel/repositories.bzl:474:26: in _org_boost
/workspaces/envoy/bazel/repositories.bzl:30:23: in external_http_archive
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/envoy_api/bazel/envoy_http_archive.bzl:16:17: in envoy_http_archive
Repository rule http_archive defined at:
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_tools/tools/build_defs/repo/http.bzl:372:31: in
INFO: Repository kafka_server_binary instantiated at:
/workspaces/envoy/WORKSPACE:13:19: in
/workspaces/envoy/bazel/repositories.bzl:242:16: in envoy_dependencies
/workspaces/envoy/bazel/repositories.bzl:1236:26: in _kafka_deps
/workspaces/envoy/bazel/repositories.bzl:30:23: in external_http_archive
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/envoy_api/bazel/envoy_http_archive.bzl:16:17: in envoy_http_archive
Repository rule http_archive defined at:
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_tools/tools/build_defs/repo/http.bzl:372:31: in
INFO: Repository com_github_curl instantiated at:
/workspaces/envoy/WORKSPACE:13:19: in
/workspaces/envoy/bazel/repositories.bzl:197:21: in envoy_dependencies
/workspaces/envoy/bazel/repositories.bzl:854:26: in _com_github_curl
/workspaces/envoy/bazel/repositories.bzl:30:23: in external_http_archive
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/envoy_api/bazel/envoy_http_archive.bzl:16:17: in envoy_http_archive
Repository rule http_archive defined at:
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_tools/tools/build_defs/repo/http.bzl:372:31: in
INFO: Repository skywalking_data_collect_protocol instantiated at:
/workspaces/envoy/WORKSPACE:13:19: in
/workspaces/envoy/bazel/repositories.bzl:187:31: in envoy_dependencies
/workspaces/envoy/bazel/repositories.bzl:589:26: in _com_github_skyapm_cpp2sky
/workspaces/envoy/bazel/repositories.bzl:30:23: in external_http_archive
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/envoy_api/bazel/envoy_http_archive.bzl:16:17: in envoy_http_archive
Repository rule http_archive defined at:
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_tools/tools/build_defs/repo/http.bzl:372:31: in
INFO: Repository com_github_unicode_org_icu instantiated at:
/workspaces/envoy/WORKSPACE:13:19: in
/workspaces/envoy/bazel/repositories.bzl:179:32: in envoy_dependencies
/workspaces/envoy/bazel/repositories.bzl:386:26: in _com_github_unicode_org_icu
/workspaces/envoy/bazel/repositories.bzl:30:23: in external_http_archive
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/envoy_api/bazel/envoy_http_archive.bzl:16:17: in envoy_http_archive
Repository rule http_archive defined at:
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_tools/tools/build_defs/repo/http.bzl:372:31: in
ERROR: /workspaces/envoy/contrib/golang/filters/http/source/go/BUILD:5:10: //contrib/golang/filters/http/source/go:libgolang.so depends on @com_github_cncf_xds_go//udpa/type/v1:type in repository @com_github_cncf_xds_go which failed to fetch. no such package '@com_github_cncf_xds_go//udpa/type/v1': failed to fetch com_github_cncf_xds_go: fetch_repo<EMAIL_ADDRESS>Get<EMAIL_ADDRESS>dial tcp <IP_ADDRESS>:443: i/o timeout
ERROR: Analysis of target '//contrib/golang/filters/http/source/go:libgolang.so' failed; build aborted: Analysis failed
INFO: Elapsed time: 56.310s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (1112 packages loaded, 29259 targets configured)
currently loading: @com_github_google_quiche// ... (8 packages)
Fetching repository @org_golang_google_protobuf; starting 41s
Fetching repository @com_github_lyft_protoc_gen_star; starting 40s
Fetching https://archive.apache.org/dist/kafka/3.3.1/kafka_2.13-3.3.1.tgz; 10.1 MiB (10,592,256B) 37s
Fetching https://boostorg.jfrog.io/artifactory/main/release/1.78.0/source/boost_1_78_0.tar.gz; 15.7 MiB (16,491,873B) 35s
Traceback (most recent call last):

Skipping proto_format.sh due to no API change
$TEST_TMPDIR defined: output root default is '/build/envoy-compdb' and max_idle_secs default is '15'.
Starting local Bazel server and connecting to it...
WARNING: /workspaces/envoy/test/proto/BUILD:30:23: in genrule rule //test/proto:bookstore_proto_descriptor: target '//test/proto:bookstore_proto_descriptor' depends on deprecated target '@com_google_protobuf//:well_known_protos': Prefer :well_known_type_protos instead.
INFO: Repository com_github_lyft_protoc_gen_star instantiated at:
/workspaces/envoy/WORKSPACE:25:25: in
/workspaces/envoy/bazel/dependency_imports.bzl:117:18: in envoy_dependency_imports
Repository rule go_repository defined at:
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_gazelle/internal/go_repository.bzl:313:32: in
ERROR: An error occurred during the fetch of repository 'com_github_lyft_protoc_gen_star':
Traceback (most recent call last):
File "/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_gazelle/internal/go_repository.bzl", line 247, column 17, in _go_repository_impl
fail("failed to fetch %s: %s" % (ctx.name, result.stderr))
Error in fail: failed to fetch com_github_lyft_protoc_gen_star: fetch_repo<EMAIL_ADDRESS>Get<EMAIL_ADDRESS>dial tcp <IP_ADDRESS>:443: i/o timeout
ERROR: /workspaces/envoy/WORKSPACE:25:25: fetching go_repository rule //external:com_github_lyft_protoc_gen_star: Traceback (most recent call last):
File "/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_gazelle/internal/go_repository.bzl", line 247, column 17, in _go_repository_impl
fail("failed to fetch %s: %s" % (ctx.name, result.stderr))
Error in fail: failed to fetch com_github_lyft_protoc_gen_star: fetch_repo<EMAIL_ADDRESS>Get<EMAIL_ADDRESS>dial tcp <IP_ADDRESS>:443: i/o timeout
INFO: Repository com_github_unicode_org_icu instantiated at:
/workspaces/envoy/WORKSPACE:13:19: in
/workspaces/envoy/bazel/repositories.bzl:179:32: in envoy_dependencies
/workspaces/envoy/bazel/repositories.bzl:386:26: in _com_github_unicode_org_icu
/workspaces/envoy/bazel/repositories.bzl:30:23: in external_http_archive
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/envoy_api/bazel/envoy_http_archive.bzl:16:17: in envoy_http_archive
Repository rule http_archive defined at:
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_tools/tools/build_defs/repo/http.bzl:372:31: in
INFO: Repository kafka_server_binary instantiated at:
/workspaces/envoy/WORKSPACE:13:19: in
/workspaces/envoy/bazel/repositories.bzl:242:16: in envoy_dependencies
/workspaces/envoy/bazel/repositories.bzl:1236:26: in _kafka_deps
/workspaces/envoy/bazel/repositories.bzl:30:23: in external_http_archive
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/envoy_api/bazel/envoy_http_archive.bzl:16:17: in envoy_http_archive
Repository rule http_archive defined at:
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_tools/tools/build_defs/repo/http.bzl:372:31: in
INFO: Repository com_github_nlohmann_json instantiated at:
/workspaces/envoy/WORKSPACE:13:19: in
/workspaces/envoy/bazel/repositories.bzl:191:30: in envoy_dependencies
/workspaces/envoy/bazel/repositories.bzl:604:26: in _com_github_nlohmann_json
/workspaces/envoy/bazel/repositories.bzl:30:23: in external_http_archive
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/envoy_api/bazel/envoy_http_archive.bzl:16:17: in envoy_http_archive
Repository rule http_archive defined at:
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_tools/tools/build_defs/repo/http.bzl:372:31: in
INFO: Repository org_boost instantiated at:
/workspaces/envoy/WORKSPACE:13:19: in
/workspaces/envoy/bazel/repositories.bzl:210:15: in envoy_dependencies
/workspaces/envoy/bazel/repositories.bzl:474:26: in _org_boost
/workspaces/envoy/bazel/repositories.bzl:30:23: in external_http_archive
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/envoy_api/bazel/envoy_http_archive.bzl:16:17: in envoy_http_archive
Repository rule http_archive defined at:
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_tools/tools/build_defs/repo/http.bzl:372:31: in
INFO: Repository com_github_curl instantiated at:
/workspaces/envoy/WORKSPACE:13:19: in
/workspaces/envoy/bazel/repositories.bzl:197:21: in envoy_dependencies
/workspaces/envoy/bazel/repositories.bzl:854:26: in _com_github_curl
/workspaces/envoy/bazel/repositories.bzl:30:23: in external_http_archive
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/envoy_api/bazel/envoy_http_archive.bzl:16:17: in envoy_http_archive
Repository rule http_archive defined at:
/build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/bazel_tools/tools/build_defs/repo/http.bzl:372:31: in
ERROR: /build/envoy-compdb/_bazel_vscode/2d35de14639eaad1ac7060a4dd7e3351/external/com_envoyproxy_protoc_gen_validate/BUILD:18:11: @com_envoyproxy_protoc_gen_validate//:protoc-gen-validate_lib depends on @com_github_lyft_protoc_gen_star//lang/go:go in repository @com_github_lyft_protoc_gen_star which failed to fetch. no such package '@com_github_lyft_protoc_gen_star//lang/go': failed to fetch com_github_lyft_protoc_gen_star: fetch_repo<EMAIL_ADDRESS>Get<EMAIL_ADDRESS>dial tcp <IP_ADDRESS>:443: i/o timeout
ERROR: Analysis of target '//contrib/postgres_proxy/filters/network/test:postgres_integration_proto_cc_proto_validate' failed; build aborted:
INFO: Elapsed time: 48.911s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (1229 packages loaded, 28967 targets configured)
currently loading: @com_github_google_tcmalloc//tcmalloc ... (8 packages)
Fetching repository @org_golang_google_protobuf; starting 34s
Fetching repository @com_github_cncf_xds_go; starting 34s
Fetching https://archive.apache.org/dist/kafka/3.3.1/kafka_2.13-3.3.1.tgz; 7.6 MiB (7,987,200B) 30s
Fetching https://boostorg.jfrog.io/artifactory/main/release/1.78.0/source/boost_1_78_0.tar.gz; 4.1 MiB (4,255,073B) 29s
Fetching https://github.com/nlohmann/json/archive/v3.11.2.tar.gz; 6.7 MiB (7,077,674B) 26s
Fetching https://github.com/curl/curl/releases/download/curl-7_87_0/curl-7.87.0.tar.gz; 1.1 MiB (1,199,767B) 21s
Traceback (most recent call last):
File "/workspaces/envoy/tools/gen_compilation_database.py", line 127, in
fix_compilation_database(args, generate_compilation_database(args))
File "/workspaces/envoy/tools/gen_compilation_database.py", line 24, in generate_compilation_database
subprocess.check_call([args.bazel, "build"] + bazel_options + [
File "/usr/lib/python3.10/subprocess.py", line 369, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['bazel', 'build', '--config=compdb', '--remote_download_outputs=all', '--aspects=@bazel_compdb//:aspects.bzl%compilation_database_aspect', '--output_groups=compdb_files,header_files', '//source/...', '//test/...', '//contrib/...']' returned non-zero exit s

Seems there are some troubles for your dev environment to access go-releated deps.


Fix Makefile and don't overwrite config file if already present

You can't really notice it with the Github diff but there was a trailing whitespace causing that mentioned issue in the comment (about pkg-config)
During installation, if the config file is already there we should not overwrite it with default values again

Nice, good spot & good idea! Thanks for this, merged.


ghdlsynth build breaks

ghdlsynth uses the following to compile its interface module:
yosys-config --exec --cxx -c --cxxflags -o $@ $<

A recent change to yosys breaks the inclusion of rtlil.h... at line 380 it tries to include "constids.inc" which appears only in the kernel directory, and is not in the include path.  A quick hack to put the yosys/kernel directory in the path manually results in a working ghdl module.
I had a quick look at the changesets and it's not immediately obvious which change causes this, or if the build break is caused by an incomplete build or install issue, but it is in the last 2 days.  I have been tracking both ghdlsynth and yosys development, and this is a new bug.
Cheers, and thanks to all the Yosys developers.  In conjunction with the GHDL developer's work, very much progress has been made in just the last few weeks.

Sorry, I believe this is my doing for #1767! Please try #1858.

@donnie-j Can you confirm if this fixes your issue please?

Not OP, but 2d0b4033 still doesn't work - the error doesn't occur during compilation of yosys, but when ghdl-yosys-plugin includes the yosys headers:
In file included from /usr/share/yosys/include/kernel/yosys.h:277,
                 from src/ghdl.cc:19:
/usr/share/yosys/include/kernel/rtlil.h:380:10: fatal error: constids.inc: No such file or directory
  380 | #include "constids.inc"
      |          ^~~~~~~~~~~~~~

I think the occurences in both rtlil.cc and yosys.cc are fine, only rtlil.h needs to be changed.

It'll also need an $(eval $(call add_include_file,kernel/constids.inc)) in the Makefile to copy the file over during installation.

Thanks @Xiretza! Seems like I got the wrong end of the stick entirely. I still think there's value in #1858 as I believe convention is to include <subdir>/<file> regardless.

Yup, now seems to be fixed.  Thanks all.


12 page anchor navigation

Please always provide the GitHub issue(s) your PR is for, as well as test URLs where your change can be observed (before and after):
Fix #12

Test URLs:

Before: https://main--choice--hlxsites.hlx.page/en-us/explore/
After: https://12-page-anchor-navigation--choice--hlxsites.hlx.page/en-us/explore/

Wrapping behaviour seems different.
Original

Yours:

Just like Francisco solution I like better your implementation, maybe we can ask the customer to agree to it

@cuzuco2 @chicharr since this a PoC and we have no customer contact, i think we can take the liberty and choose the more beautiful wrapping. WDYT?


Maya: Extract look is not AYON compatible

Describe the bug
Extract look is looking for data.sourceHashes.<key> on version documents in mongo, using distinct (get all versions which contain the file hash). This data structure and query type does not have equivalent in AYON -> We don't have option to have attribute which is dictionary/object + we're not able to "distinct" all version which have a key in the dictionary. Function which does that: https://github.com/ynput/OpenPype/blob/develop/openpype/hosts/maya/plugins/publish/extract_look.py#L33
Additional context
I'm not familiar what are the hashes used for. Are sourceHashes used now -> do we need them? If we do, could they be handled in a different way?
[cuID:OP-5375]

I'm not familiar what are the hashes used for. Are sourceHashes used now -> do we need them? If we do, could they be handled in a different way?

They are used for detecting if a certain texture had been published before so that e.g. a hardlink could be made if the texture hasn't changed since published. It's a feature disabled on Windows however.


Update src/quo.core.js

Imposible auto-merge :(
Manual Mode ON :) >> https://github.com/soyjavi/QuoJS/commits/master


Services, Load Balancing, and Networking

This section is causing some confusion for me. Does it mean that only on a Linux host network does Kubernetes require that pods communicate with pods in other nodes without NAT? Can the first portion here be amended to just state it only applied to Linux if that is the case? I don't understand the distinction between the first point in the first section and the point in the second section.
Help me understand and I'll push a PR to clarify it for others as well.
Kubernetes imposes the following fundamental requirements on any networking implementation (barring any intentional network segmentation policies):

- pods on a node can communicate with all pods on all nodes without NAT
- agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that node

Note: For those platforms that support Pods running in the host network (e.g. Linux):
- pods in the host network of a node can communicate with all pods on all nodes without NAT

/kind support

@churnikorn, GitHub is not the right place for support requests.
For help, you could try Server Fault.
You can also post your question on the Kubernetes Slack or the Discuss Kubernetes forum.


Recovery point (Latest - lowest RPO) is not discussed

[Enter feedback here]

In Test Failover, Select a recovery point to use for the failover:

I see 4 recovery points in the Azure Portal only 3 are discussed here

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: cc1e6c87-727d-56d3-1157-963bb69fe6f3
Version Independent ID: 1843c357-4032-5d6b-418a-ba5eafa6a4da
Content: Run a disaster recovery drill for Azure VMs to a secondary Azure region with the Azure Site Recovery service
Content Source: articles/site-recovery/azure-to-azure-tutorial-dr-drill.md
Service: site-recovery
GitHub Login: @rayne-wiselman
Microsoft Alias: raynew

@kumarallamraju Thanks for the feedback! I have assigned the issue to the doc author for updating the document accordingly.

@rayne-wiselman Can you please look into this and update the document as applicable.

Added a note to the documentation. Should appear later today
#please-close


Fixes threaded shuffle writer test mocks for spark 3.3.0+ [databricks]

Signed-off-by: Alessandro Bellina<EMAIL_ADDRESS>This PR https://github.com/NVIDIA/spark-rapids/pull/6052, broke one of our nightly jobs for Spark 3.3.0+. This was due to the test not mocking a new method added in Spark 3.3.0.
This adds the mock and defines a subclass of IndexShuffleBlockResolver that defines the method for versions before 3.3.0.

build

failed pyspark.sql.utils.AnalysisException: java.lang.RuntimeException: The root scratch dir: /tmp/hive on HDFS should be writable. Current permissions are: rwxr-xr-x
seems some orc cases introduced side effect from other PRs

build

build


Update intro.md

updated links in intro.md

This change doesn't appear to work. What's the intention here?

This change doesn't appear to work. What's the intention here?

Sorry. I tried following one of the links and it did not work, and I saw the links included a num prefix. The files in the repository did not include this in their name so I changed the link to reflect this. However, this change did not create working links.
Is there a page associated with these files other than the repository page, like a GitHub pages site?
If not, I have updates the links again to point to the .md documents in the repository, and I actually tested them this time. Sorry about that.

Is there a page associated with these files other than the repository page, like a GitHub pages site?

Yep, check out the guide

I see. So the links are correct when used on the site. They’re relative links instead of absolute links, so they don’t work when you click on them while in the git repository.

Yes, unfortunately. I may add a README.md in the guide/ directory that points readers to the docs.


Add invSqrt

This is the original Quake III Arena implementation of Fast InvSqrt() from id Tech 3, ported to Java using Float.floatToIntBits() and Double.doubleToLongBits(). May need to add a disclaimer that any observable performance difference over 1/Math.sqrt(x) is entirely system-dependent

I just want to point out why this was closed: the method is sound and should work for the -0.5 power with good precision, but according to benchmarks I ran a while ago (partly in https://github.com/tommyettinger/assorted-benchmarks/blob/master/src/main/java/net/adoptopenjdk/bumblebench/examples/MathSqrtFloatBench.java ), this inverse approximation isn't as fast as 1f/(float)Math.sqrt(x) because sqrt is an intrinsic candidate on most JDKs. For cube root, an approximation like this is much faster than Math.cbrt(x), so the format is still useful, just not the specific case of the 0.5 or -0.5 power.

So my old benchmark didn't test GraalVM (it wasn't usable on Windows for a while early on), and it turns out this code is significantly faster on Graal (> 40% higher throughput) while only being a tiny bit slower elsewhere (less than 5% slower on HotSpot, though since it's an approximation, it is less accurate). It looks like Graal doesn't have the same intrinsic optimizations that HotSpot has for Math.sqrt(), or they aren't as fast. I can't reopen this PR because of some Git reason ("main branch was force-pushed or recreated"), so I may recreate it with a notice about being a good choice if you distribute with or typically target GraalVM. There was one change I needed to make anyway; Float's int/float conversions are good on Desktop and Android, but are extremely slow by default on GWT. We use BitConversion here, which should inline to be the same as Float.intBitsToFloat() and related methods on desktop, while using an alternate (non-approximate) algorithm on GWT-only that is optimized for what it can do.


Can the CHANGELOG be updated for 1.32.0?

I read it every time!

:+1: - my fault, done and dusted :point_up_2:   a191908b053ae582661fd74b2e8dc3e1d9b4a030


[special] add cupyx.scipy.special.softmax

Adds cupyx.scipy.special.softmax.
Benchmarks

size
dtype
SciPy
CuPy

1000
int8
0.106 ms
0.104 ms

1000
int32
0.062 ms
0.104 ms

1000
float32
0.046 ms
0.106 ms

1000
float64
0.058 ms
0.105 ms

100000
int8
5.711 ms
0.111 ms

100000
int32
1.761 ms
0.139 ms

100000
float32
0.378 ms
0.115 ms

100000
float64
1.620 ms
0.138 ms

1000000
int8
56.208 ms
0.225 ms

1000000
int32
17.004 ms
0.774 ms

1000000
float32
2.805 ms
0.270 ms

1000000
float64
17.225 ms
0.925 ms

Script (Click Please)

import cupy
import cupyx
import cupyx.scipy.stats

import scipy

from cupy import testing
from cupyx.profiler import benchmark

import scipy.stats

n_warmup = 1
n_repeat = 10
dtype_set = ('int8', 'int32', 'float32', 'float64')
n_set = (1000, 100000, 1000000)

def get_time(pref):
    cpu_time = pref.cpu_times.mean()
    gpu_time = pref.gpu_times.mean()
    return max(cpu_time, gpu_time) * 1000  # ms

def time(a):
    cp_a = cupy.array(a)
    ref = scipy.special.softmax(a)
    ret = cupyx.scipy.special.softmax(cp_a)
    times = []
    perf = benchmark(scipy.special.softmax, (a,),
                     n_warmup=n_warmup, n_repeat=n_repeat)
    times.append(get_time(perf))
    perf = benchmark(cupyx.scipy.special.softmax, (cp_a,),
                     n_warmup=n_warmup, n_repeat=n_repeat)
    times.append(get_time(perf))
    return times

print('size | dtype | SciPy | CuPy')
print('-----|-------|-------|-----')
for n in n_set:
    for dtype in dtype_set:
        a = scipy.random.randint(0, 2, size=n).astype(dtype)
        times = time(a)
        print('{} | {} | {:.3f} ms | {:.3f} ms'.format(n, dtype, times[0], times[1]))

/test mini

Would you leave a comment that you tried using CuPy fusion, which was not well performant? The content of gitter talk is okay.

Thanks for your work!

Hi, @takagi!
Thanks for reviewing and for the tricks!

Would you leave a comment that you tried using CuPy fusion, which was not well performant? The content of gitter talk and measured result are okay.

Sure, since this PR is merged. I'll send a different PR adding a comment.

Sent a PR: #6944! Thanks

Would you leave a comment that you tried using CuPy fusion, which was not well performant? The content of gitter talk and measured result are okay.

Note: here, we used three kernel switches for the implementation, we tried using cupy.fusion, but the performance degraded. Because CuPy fusion does not generate competitive codes for all cases. The fusion technique we iterated:
def make_expander(shape, axis):
    axis = internal._normalize_axis_indices(axis, len(shape))
    expander = []
    for i, s in enumerate(x.shape):
        if i in axis:
            expander.append(None)
        else:
            expander.append(slice(None))
    return tuple(expander)

@_util.memoize(for_each_device=True)
def _softmax_fuse(shape, axis):
    expander = make_expander(shape, axis)
    @_core.fusion.fuse()
    def softmax_fuse(x):
        x_max = cupy.amax(x, axis=axis)
        exp_x_shifted = cupy.exp(x - x_max[expander])
        return exp_x_shifted / cupy.sum(exp_x_shifted, axis=axis)[expander]
    return softmax_fuse

def softmax(x, axis=None):
    fused_softmax = _softmax_fuse(shape=x.shape, axis=axis)
    return fused_softmax(x)

TODO: Add the shape method in cupy.fusion so we can fuse the make_expander function, too, which might increment the performance.

Thanks @khushi-411 !


Colorbars within figures

Description
Unable to produce colorbars within different subplots. Matplotlib is able to produce a better colorbar.
Steps to reproduce in Matplotlib
import matplotlib.pyplot as plt
import numpy as np

# Fixing random state for reproducibility
np.random.seed(19680801)

fig, axs = plt.subplots(3, 3, constrained_layout=True)
for ax in axs.flat:
    pcm = ax.pcolormesh(np.random.random((20, 20)))

fig.colorbar(pcm, ax=axs[0, :2], shrink=0.6, location='bottom')
fig.colorbar(pcm, ax=[axs[0, 2]], location='bottom')
fig.colorbar(pcm, ax=axs[1:, :], location='right', shrink=0.6)
fig.colorbar(pcm, ax=[axs[2, 1]], location='left')
plt.show()

Steps to reproduce in Proplot
import proplot as plt

fig, axs = plt.subplots(ncols=3, nrows=3)
for ax in axs:
    pcm = ax.pcolormesh(np.random.random((20, 20)))

fig.colorbar(pcm, ax=axs[0, :2], shrink=0.6, location='bottom')
fig.colorbar(pcm, ax=[axs[0, 2]], location='bottom')
fig.colorbar(pcm, ax=axs[1:, :], location='right', shrink=0.6)
fig.colorbar(pcm, ax=[axs[2, 1]], location='left')

Matplotlib behavior: [What you expected to happen]

Proplot behavior: [What actually happened]

Proplot version
3.4.3 Matplotlib
0.9.5 Proplot

I encountered the same issue. I feel the Matplotlib way to locate colorbar is easier to manage (or readable) than the cols and rows setup in Proplot.

This error occurs because proplot's fig.colorbar does not support multiple axes arguments.
@meng630 I agree. I would like to eventually support colorbars or legends along contiguous axes with both 1) matplotlib's fig.colorbar(ax=axs[:2]) syntax and 2) a proplot-only axs[:2].colorbar() syntax (using a SubplotGrid.colorbar method). I've run into cases where I need spanning labels across inner subplots in my own work, and had to use work-arounds in those cases. Hope to tackle this sometime this summer.
Turns out I already started a thread on this topic (#329), so further comments/discussion can go there.


Add jupyter notebook example

Coverage increased (+10.8%) to 72.8% when pulling abe1f5709de4b526c25677381d9a2a5a2182673e on zhaonan/jupyter into 90d9eb4f3356a3bd92b02379c8a461fb46d512ed on master.

Coverage increased (+10.8%) to 72.8% when pulling abe1f5709de4b526c25677381d9a2a5a2182673e on zhaonan/jupyter into 90d9eb4f3356a3bd92b02379c8a461fb46d512ed on master.