Artifact Build Windows (internal CI) build fails

T:\src\github\grpc>If "true" == "true" (powershell -File tools\internal_ci\helper_scripts\install_python_interpreters.ps1   || goto :error )
Downloading the Python installer: https://www.python.org/ftp/python/3.8.0/python-3.8.0.exe => C:\tools\python-3.8.0.exe
T:\src\github\grpc\tools\internal_ci\helper_scripts\install_python_interpreters.ps1 : Invalid Python installer: failed
checksum!
+ CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,install_python_interpreters.ps1

Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
[16:36:01] Transferring environment variable script to build VM
[16:36:02] Transferring kokoro_log_reader.py to build VM
[16:36:02] Transferring source code to build VM
[16:36:05] Executing build script on build VM
[ID: 6864414] Executing command via SSH:
export KOKORO_BUILD_NUMBER="22097"
export KOKORO_JOB_NAME="grpc/core/pull_request/windows/grpc_build_artifacts"
source /tmpfs/kokoro-env_vars.sh; cd /tmpfs/src/ ;  nohup bash -c "( rm -f /tmpfs/kokoro_build_exit_code ; cmd /c 'github\grpc\tools\internal_ci\windows\grpc_build_artifacts.bat'   ; echo ${PIPESTATUS[0]} > /tmpfs/kokoro_build_exit_code ) > /tmpfs/kokoro_build.log 2>&1" > /dev/null 2>&1 & echo $! > /tmpfs/kokoro_build.pid ; cmd /c 'C:/python27/python.exe T:/kokoro_log_reader.py T:/kokoro_build.log T:/kokoro_build_exit_code T:/kokoro_build.pid T:/kokoro_log_reader.pid --start_byte 0'
T:\src>choco uninstall yasm -y --limit-output
Uninstalling the following packages:
yasm
Chocolatey uninstalled 0/1 packages. 1 packages failed.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
Failures

yasm - yasm is not installed. Cannot uninstall a non-existent package.

If a package uninstall is failing and/or you've already uninstalled the
software outside of Chocolatey, you can attempt to run the command
with -n to skip running a chocolateyUninstall script, additionally
adding --skip-autouninstaller to skip an attempt to automatically
remove system-installed software. This will only remove the packaging
files and not things like software installed to Programs and Features.
If a package is failing because it is a dependency of another package
or packages, then you may first need to consider if it needs removed
as it is typically installed as a dependency for a reason. If you
decide that you still want to remove it, head into
$env:ChocolateyInstall\lib and find the package folder you want
removed. Then delete the folder for the package. This option should
only be used as a last resort.
T:\src>choco install nasm -y --limit-output
Installing the following packages:
nasm
By installing you accept licenses for the packages.
Progress: Downloading nasm 2.14.02... 15%
Progress: Downloading nasm 2.14.02... 49%
Progress: Downloading nasm 2.14.02... 82%
Progress: Downloading nasm 2.14.02... 100%
nasm v2.14.02 [Approved]
nasm package files install completed. Performing other installation steps.
Downloading nasm 64 bit
from 'https://www.nasm.us/pub/nasm/releasebuilds/2.14.02/win64/nasm-2.14.02-installer-x64.exe'
Progress: 7% - Saving 70.2 KB of 933.77 KB
Progress: 15% - Saving 148.32 KB of 933.77 KB
Progress: 24% - Saving 226.45 KB of 933.77 KB
Progress: 32% - Saving 304.57 KB of 933.77 KB
Progress: 40% - Saving 382.7 KB of 933.77 KB
Progress: 49% - Saving 460.82 KB of 933.77 KB
Progress: 57% - Saving 538.95 KB of 933.77 KB
Progress: 66% - Saving 617.07 KB of 933.77 KB
Progress: 74% - Saving 695.2 KB of 933.77 KB
Progress: 82% - Saving 773.32 KB of 933.77 KB
Progress: 91% - Saving 851.45 KB of 933.77 KB
Progress: 99% - Saving 929.57 KB of 933.77 KB
Progress: 100% - Completed download of T:\tmp\chocolatey\nasm\2.14.02\nasm-2.14.02-installer-x64.exe (933.77 KB).
Download of nasm-2.14.02-installer-x64.exe (933.77 KB) completed.
Hashes match.
Installing nasm...
nasm has been installed.
The install of nasm was successful.
Software installed as 'exe', install location is likely default.
Chocolatey installed 1/1 packages.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
T:\src>cd /d T:\src\github\grpc\tools\internal_ci\windows\......
T:\src\github\grpc>set PREPARE_BUILD_INSTALL_DEPS_PYTHON=true
T:\src\github\grpc>call tools/internal_ci/helper_scripts/prepare_build_windows.bat   || exit /b 1
T:\src\github\grpc>set PATH=C:\tools\msys64\usr\bin;C:\Python27;C:\Program Files\CMake\bin;C:\cygwin64\bin;C:\Program Files\Docker\Docker\Resources\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\libnvvp;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.1\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.1\libnvvp;C:\cygwin64\bin;C:\Program Files\Microsoft MPI\Bin;C:\Perl64\site\bin;C:\Perl64\bin;C:\tools\ruby25\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\ProgramData\GooGet;C:\Program Files\Google\Compute Engine\metadata_scripts;C:\Program Files (x86)\Google\Cloud SDK\google-cloud-sdk\bin;C:\Program Files\Google\Compute Engine\sysprep;C:\ProgramData\chocolatey\bin;C:\Program Files\nodejs;C:\Program Files\Java\jdk-9.0.1\bin;C:\Program Files\Java\jdk1.8.0_152\bin;C:\tools\php72;C:\Program Files (x86)\vim\vim80;C:\Android\android-sdk\tools;C:\Android\android-sdk\platform-tools;C:\Users\kbuilder.dnx\bin;C:\Program Files\Microsoft DNX\Dnvm;C:\Program Files\Microsoft SQL Server\130\Tools\Binn;C:\Program Files\Microsoft SQL Server\120\Tools\Binn;C:\Program Files\dotnet;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\Git\cmd;C:\python27;C:\Go\bin;C:\bazel;C:\Users\cyg_server\AppData\Local\Microsoft\WindowsApps
T:\src\github\grpc>if defined KOKORO_GITHUB_PULL_REQUEST_NUMBER if defined RUN_TESTS_FLAGS (set RUN_TESTS_FLAGS= --filter_pr_tests --base_branch origin/master )
T:\src\github\grpc>netsh interface ip set dns "Local Area Connection 8" static <IP_ADDRESS> primary
The filename, directory name, or volume label syntax is incorrect.
T:\src\github\grpc>netsh interface ip add dnsservers "Local Area Connection 8" <IP_ADDRESS> index=2
The filename, directory name, or volume label syntax is incorrect.
T:\src\github\grpc>netsh interface ip add dnsservers "Local Area Connection 8" <IP_ADDRESS> index=3
The filename, directory name, or volume label syntax is incorrect.
T:\src\github\grpc>python -m pip install google-api-python-client   || goto :error
Requirement already satisfied: google-api-python-client in c:\python27\lib\site-packages (1.6.4)
Requirement already satisfied: six<2dev,>=1.6.1 in c:\python27\lib\site-packages (from google-api-python-client) (1.11.0)
Requirement already satisfied: uritemplate<4dev,>=3.0.0 in c:\python27\lib\site-packages (from google-api-python-client) (3.0.0)
Requirement already satisfied: oauth2client<5.0.0dev,>=1.5.0 in c:\python27\lib\site-packages (from google-api-python-client) (4.1.2)
Requirement already satisfied: httplib2<1dev,>=0.9.2 in c:\python27\lib\site-packages (from google-api-python-client) (0.10.3)
Requirement already satisfied: rsa>=3.1.4 in c:\python27\lib\site-packages (from oauth2client<5.0.0dev,>=1.5.0->google-api-python-client) (3.4.2)
Requirement already satisfied: pyasn1-modules>=0.0.5 in c:\python27\lib\site-packages (from oauth2client<5.0.0dev,>=1.5.0->google-api-python-client) (0.2.1)
Requirement already satisfied: pyasn1>=0.1.7 in c:\python27\lib\site-packages (from oauth2client<5.0.0dev,>=1.5.0->google-api-python-client) (0.4.2)
You are using pip version 10.0.1, however version 20.3.3 is available.
You should consider upgrading via the 'python -m pip install --upgrade pip' command.
T:\src\github\grpc>powershell -File src\csharp\install_dotnet_sdk.ps1   || goto :error
Downloading install script: https://dot.net/v1/dotnet-install.ps1 => T:\tmp\dotnet-install.ps1
dotnet-install: Note that the intended use of this script is for Continuous Integration (CI) scenarios, where:
dotnet-install: - The SDK needs to be installed without user interaction and without admin rights.
dotnet-install: - The SDK installation doesn't need to persist across multiple CI runs.
dotnet-install: To set up a development environment or to run apps, use installers rather than this script. Visit https://dotnet.microsoft.com/download to get the installer.
dotnet-install: Downloading primary link https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.504/dotnet-sdk-2.1.504-win-x64.zip
dotnet-install: Extracting zip from https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.504/dotnet-sdk-2.1.504-win-x64.zip
dotnet-install: Adding to current process PATH: "C:\Users\kbuilder\AppData\Local\Microsoft\dotnet". Note: This change will not be visible if PowerShell was run as a child process.
dotnet-install: Note that the script does not resolve dependencies during installation.
dotnet-install: To check the list of dependencies, go to https://docs.microsoft.com/dotnet/core/install/windows#dependencies
dotnet-install: Installation finished
T:\src\github\grpc>set PATH=C:\Users\kbuilder\AppData\Local\Microsoft\dotnet;C:\tools\msys64\usr\bin;C:\Python27;C:\Program Files\CMake\bin;C:\cygwin64\bin;C:\Program Files\Docker\Docker\Resources\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\libnvvp;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.1\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.1\libnvvp;C:\cygwin64\bin;C:\Program Files\Microsoft MPI\Bin;C:\Perl64\site\bin;C:\Perl64\bin;C:\tools\ruby25\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\ProgramData\GooGet;C:\Program Files\Google\Compute Engine\metadata_scripts;C:\Program Files (x86)\Google\Cloud SDK\google-cloud-sdk\bin;C:\Program Files\Google\Compute Engine\sysprep;C:\ProgramData\chocolatey\bin;C:\Program Files\nodejs;C:\Program Files\Java\jdk-9.0.1\bin;C:\Program Files\Java\jdk1.8.0_152\bin;C:\tools\php72;C:\Program Files (x86)\vim\vim80;C:\Android\android-sdk\tools;C:\Android\android-sdk\platform-tools;C:\Users\kbuilder.dnx\bin;C:\Program Files\Microsoft DNX\Dnvm;C:\Program Files\Microsoft SQL Server\130\Tools\Binn;C:\Program Files\Microsoft SQL Server\120\Tools\Binn;C:\Program Files\dotnet;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\Git\cmd;C:\python27;C:\Go\bin;C:\bazel;C:\Users\cyg_server\AppData\Local\Microsoft\WindowsApps
T:\src\github\grpc>set NUGET_XMLDOC_MODE=skip
T:\src\github\grpc>set DOTNET_SKIP_FIRST_TIME_EXPERIENCE=true
T:\src\github\grpc>set DOTNET_CLI_TELEMETRY_OPTOUT=true
T:\src\github\grpc>If "true" == "true" (powershell -File tools\internal_ci\helper_scripts\install_python_interpreters.ps1   || goto :error )
Downloading the Python installer: https://www.python.org/ftp/python/3.8.0/python-3.8.0.exe => C:\tools\python-3.8.0.exe
T:\src\github\grpc\tools\internal_ci\helper_scripts\install_python_interpreters.ps1 : Invalid Python installer: failed
checksum!
+ CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,install_python_interpreters.ps1
T:\src\github\grpc>exit /b 1
[ID: 6864414] Build finished after 99 secs, exit value: 1
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
[16:37:44] Collecting build artifacts from build VM
Build script failed with exit code: 1

Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
[16:36:01] Transferring environment variable script to build VM
[16:36:02] Transferring kokoro_log_reader.py to build VM
[16:36:02] Transferring source code to build VM
[16:36:05] Executing build script on build VM
[ID: 6864414] Executing command via SSH:
export KOKORO_BUILD_NUMBER="22097"
export KOKORO_JOB_NAME="grpc/core/pull_request/windows/grpc_build_artifacts"
source /tmpfs/kokoro-env_vars.sh; cd /tmpfs/src/ ;  nohup bash -c "( rm -f /tmpfs/kokoro_build_exit_code ; cmd /c 'github\grpc\tools\internal_ci\windows\grpc_build_artifacts.bat'   ; echo ${PIPESTATUS[0]} > /tmpfs/kokoro_build_exit_code ) > /tmpfs/kokoro_build.log 2>&1" > /dev/null 2>&1 & echo $! > /tmpfs/kokoro_build.pid ; cmd /c 'C:/python27/python.exe T:/kokoro_log_reader.py T:/kokoro_build.log T:/kokoro_build_exit_code T:/kokoro_build.pid T:/kokoro_log_reader.pid --start_byte 0'
T:\src>choco uninstall yasm -y --limit-output
Uninstalling the following packages:
yasm
Chocolatey uninstalled 0/1 packages. 1 packages failed.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
Failures

yasm - yasm is not installed. Cannot uninstall a non-existent package.

If a package uninstall is failing and/or you've already uninstalled the
software outside of Chocolatey, you can attempt to run the command
with -n to skip running a chocolateyUninstall script, additionally
adding --skip-autouninstaller to skip an attempt to automatically
remove system-installed software. This will only remove the packaging
files and not things like software installed to Programs and Features.
If a package is failing because it is a dependency of another package
or packages, then you may first need to consider if it needs removed
as it is typically installed as a dependency for a reason. If you
decide that you still want to remove it, head into
$env:ChocolateyInstall\lib and find the package folder you want
removed. Then delete the folder for the package. This option should
only be used as a last resort.
T:\src>choco install nasm -y --limit-output
Installing the following packages:
nasm
By installing you accept licenses for the packages.
Progress: Downloading nasm 2.14.02... 15%
Progress: Downloading nasm 2.14.02... 49%
Progress: Downloading nasm 2.14.02... 82%
Progress: Downloading nasm 2.14.02... 100%
nasm v2.14.02 [Approved]
nasm package files install completed. Performing other installation steps.
Downloading nasm 64 bit
from 'https://www.nasm.us/pub/nasm/releasebuilds/2.14.02/win64/nasm-2.14.02-installer-x64.exe'
Progress: 7% - Saving 70.2 KB of 933.77 KB
Progress: 15% - Saving 148.32 KB of 933.77 KB
Progress: 24% - Saving 226.45 KB of 933.77 KB
Progress: 32% - Saving 304.57 KB of 933.77 KB
Progress: 40% - Saving 382.7 KB of 933.77 KB
Progress: 49% - Saving 460.82 KB of 933.77 KB
Progress: 57% - Saving 538.95 KB of 933.77 KB
Progress: 66% - Saving 617.07 KB of 933.77 KB
Progress: 74% - Saving 695.2 KB of 933.77 KB
Progress: 82% - Saving 773.32 KB of 933.77 KB
Progress: 91% - Saving 851.45 KB of 933.77 KB
Progress: 99% - Saving 929.57 KB of 933.77 KB
Progress: 100% - Completed download of T:\tmp\chocolatey\nasm\2.14.02\nasm-2.14.02-installer-x64.exe (933.77 KB).
Download of nasm-2.14.02-installer-x64.exe (933.77 KB) completed.
Hashes match.
Installing nasm...
nasm has been installed.
The install of nasm was successful.
Software installed as 'exe', install location is likely default.
Chocolatey installed 1/1 packages.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
T:\src>cd /d T:\src\github\grpc\tools\internal_ci\windows\......
T:\src\github\grpc>set PREPARE_BUILD_INSTALL_DEPS_PYTHON=true
T:\src\github\grpc>call tools/internal_ci/helper_scripts/prepare_build_windows.bat   || exit /b 1
T:\src\github\grpc>set PATH=C:\tools\msys64\usr\bin;C:\Python27;C:\Program Files\CMake\bin;C:\cygwin64\bin;C:\Program Files\Docker\Docker\Resources\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\libnvvp;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.1\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.1\libnvvp;C:\cygwin64\bin;C:\Program Files\Microsoft MPI\Bin;C:\Perl64\site\bin;C:\Perl64\bin;C:\tools\ruby25\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\ProgramData\GooGet;C:\Program Files\Google\Compute Engine\metadata_scripts;C:\Program Files (x86)\Google\Cloud SDK\google-cloud-sdk\bin;C:\Program Files\Google\Compute Engine\sysprep;C:\ProgramData\chocolatey\bin;C:\Program Files\nodejs;C:\Program Files\Java\jdk-9.0.1\bin;C:\Program Files\Java\jdk1.8.0_152\bin;C:\tools\php72;C:\Program Files (x86)\vim\vim80;C:\Android\android-sdk\tools;C:\Android\android-sdk\platform-tools;C:\Users\kbuilder.dnx\bin;C:\Program Files\Microsoft DNX\Dnvm;C:\Program Files\Microsoft SQL Server\130\Tools\Binn;C:\Program Files\Microsoft SQL Server\120\Tools\Binn;C:\Program Files\dotnet;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\Git\cmd;C:\python27;C:\Go\bin;C:\bazel;C:\Users\cyg_server\AppData\Local\Microsoft\WindowsApps
T:\src\github\grpc>if defined KOKORO_GITHUB_PULL_REQUEST_NUMBER if defined RUN_TESTS_FLAGS (set RUN_TESTS_FLAGS= --filter_pr_tests --base_branch origin/master )
T:\src\github\grpc>netsh interface ip set dns "Local Area Connection 8" static <IP_ADDRESS> primary
The filename, directory name, or volume label syntax is incorrect.
T:\src\github\grpc>netsh interface ip add dnsservers "Local Area Connection 8" <IP_ADDRESS> index=2
The filename, directory name, or volume label syntax is incorrect.
T:\src\github\grpc>netsh interface ip add dnsservers "Local Area Connection 8" <IP_ADDRESS> index=3
The filename, directory name, or volume label syntax is incorrect.
T:\src\github\grpc>python -m pip install google-api-python-client   || goto :error
Requirement already satisfied: google-api-python-client in c:\python27\lib\site-packages (1.6.4)
Requirement already satisfied: six<2dev,>=1.6.1 in c:\python27\lib\site-packages (from google-api-python-client) (1.11.0)
Requirement already satisfied: uritemplate<4dev,>=3.0.0 in c:\python27\lib\site-packages (from google-api-python-client) (3.0.0)
Requirement already satisfied: oauth2client<5.0.0dev,>=1.5.0 in c:\python27\lib\site-packages (from google-api-python-client) (4.1.2)
Requirement already satisfied: httplib2<1dev,>=0.9.2 in c:\python27\lib\site-packages (from google-api-python-client) (0.10.3)
Requirement already satisfied: rsa>=3.1.4 in c:\python27\lib\site-packages (from oauth2client<5.0.0dev,>=1.5.0->google-api-python-client) (3.4.2)
Requirement already satisfied: pyasn1-modules>=0.0.5 in c:\python27\lib\site-packages (from oauth2client<5.0.0dev,>=1.5.0->google-api-python-client) (0.2.1)
Requirement already satisfied: pyasn1>=0.1.7 in c:\python27\lib\site-packages (from oauth2client<5.0.0dev,>=1.5.0->google-api-python-client) (0.4.2)
You are using pip version 10.0.1, however version 20.3.3 is available.
You should consider upgrading via the 'python -m pip install --upgrade pip' command.
T:\src\github\grpc>powershell -File src\csharp\install_dotnet_sdk.ps1   || goto :error
Downloading install script: https://dot.net/v1/dotnet-install.ps1 => T:\tmp\dotnet-install.ps1
dotnet-install: Note that the intended use of this script is for Continuous Integration (CI) scenarios, where:
dotnet-install: - The SDK needs to be installed without user interaction and without admin rights.
dotnet-install: - The SDK installation doesn't need to persist across multiple CI runs.
dotnet-install: To set up a development environment or to run apps, use installers rather than this script. Visit https://dotnet.microsoft.com/download to get the installer.
dotnet-install: Downloading primary link https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.504/dotnet-sdk-2.1.504-win-x64.zip
dotnet-install: Extracting zip from https://dotnetcli.azureedge.net/dotnet/Sdk/2.1.504/dotnet-sdk-2.1.504-win-x64.zip
dotnet-install: Adding to current process PATH: "C:\Users\kbuilder\AppData\Local\Microsoft\dotnet". Note: This change will not be visible if PowerShell was run as a child process.
dotnet-install: Note that the script does not resolve dependencies during installation.
dotnet-install: To check the list of dependencies, go to https://docs.microsoft.com/dotnet/core/install/windows#dependencies
dotnet-install: Installation finished
T:\src\github\grpc>set PATH=C:\Users\kbuilder\AppData\Local\Microsoft\dotnet;C:\tools\msys64\usr\bin;C:\Python27;C:\Program Files\CMake\bin;C:\cygwin64\bin;C:\Program Files\Docker\Docker\Resources\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\libnvvp;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.1\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.1\libnvvp;C:\cygwin64\bin;C:\Program Files\Microsoft MPI\Bin;C:\Perl64\site\bin;C:\Perl64\bin;C:\tools\ruby25\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\ProgramData\GooGet;C:\Program Files\Google\Compute Engine\metadata_scripts;C:\Program Files (x86)\Google\Cloud SDK\google-cloud-sdk\bin;C:\Program Files\Google\Compute Engine\sysprep;C:\ProgramData\chocolatey\bin;C:\Program Files\nodejs;C:\Program Files\Java\jdk-9.0.1\bin;C:\Program Files\Java\jdk1.8.0_152\bin;C:\tools\php72;C:\Program Files (x86)\vim\vim80;C:\Android\android-sdk\tools;C:\Android\android-sdk\platform-tools;C:\Users\kbuilder.dnx\bin;C:\Program Files\Microsoft DNX\Dnvm;C:\Program Files\Microsoft SQL Server\130\Tools\Binn;C:\Program Files\Microsoft SQL Server\120\Tools\Binn;C:\Program Files\dotnet;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files\Git\cmd;C:\python27;C:\Go\bin;C:\bazel;C:\Users\cyg_server\AppData\Local\Microsoft\WindowsApps
T:\src\github\grpc>set NUGET_XMLDOC_MODE=skip
T:\src\github\grpc>set DOTNET_SKIP_FIRST_TIME_EXPERIENCE=true
T:\src\github\grpc>set DOTNET_CLI_TELEMETRY_OPTOUT=true
T:\src\github\grpc>If "true" == "true" (powershell -File tools\internal_ci\helper_scripts\install_python_interpreters.ps1   || goto :error )
Downloading the Python installer: https://www.python.org/ftp/python/3.8.0/python-3.8.0.exe => C:\tools\python-3.8.0.exe
T:\src\github\grpc\tools\internal_ci\helper_scripts\install_python_interpreters.ps1 : Invalid Python installer: failed
checksum!
+ CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,install_python_interpreters.ps1
T:\src\github\grpc>exit /b 1
[ID: 6864414] Build finished after 99 secs, exit value: 1
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
[16:37:44] Collecting build artifacts from build VM
Build script failed with exit code: 1

Just checked the checksum value in our script and python.org. The checksum is the same. This issue might be a one-time network issue that the downloaded Python installer is corrupted.

Just checked the checksum value in our script and python.org. The checksum is the same. This issue might be a one-time network issue that the downloaded Python installer is corrupted.

You are right, this is not reproducible! thanks for checking

You are right, this is not reproducible! thanks for checking


Implement stacking for XYPlot

Resolving the task since it the code was already merged to master in #37


[SPARK-34225][CORE] Don't encode further when a URI form string is passed to addFile or addJar

What changes were proposed in this pull request?

This PR fixes an issue that addFile and addJar further encode even though a URI form string is passed.
For example, the following operation will throw exception even though the file exists.
sc.addFile("file:/foo/test%20file.txt")

Another case is --files and --jars option when we submit an application.
bin/spark-shell --files "/foo/test file.txt"

The path above is transformed to URI form here and passed to addFile so the same issue happens.
Why are the changes needed?

This is a bug.
Does this PR introduce any user-facing change?

No.
How was this patch tested?

New test.

Yeah, I agree with this change.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135689/

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40271/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40276/

Test build #135694 has started for PR 31718 at commit 17a2168.

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40271/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40271/

Test build #135694 has finished for PR 31718 at commit 17a2168.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135694/

Hm, are we sure? I'd expect that a user does not pass an encoded string. If it contains a % for example then it's really a % that needs encoding (or else, the input is incorrect).

If a URI form string contains an encoded character, it should be really an encoded character, while a non-URI form string contains an encoded character, it should be leave it.
This solution can keep % as it is.
--files
$ bin/spark-shell --files /path/to/test%file.txt
scala> sc.listFiles
res0: Seq[String] = Vector(file:///tmp/test%25file.txt)

sc.addFile
scala> sc.addFile("/path/to/test%file.txt")
scala> sc.listFiles
res0: Seq[String] = Vector(file:///tmp/test%25file.txt)

How do you know if it's a "real" encoded character or just looks like one? If a path actually contains "%25" then this would fail now.

If an URI form string like file:/foo/bar%25.txt or http://foo/bar%25.txt, I think we can consider %25 as an encoded character. URI can't contain non-encoded %.
If a non-URI form path actually contains %25, I think it should be considered it's not encoded.

OK I agree if it's specified as a URI, rather than a path

Added new assertions for non-URI paths.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135805/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40387/

retest please.

retest this please.

Test build #135822 has started for PR 31718 at commit b42052c.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40404/

Test build #135822 has finished for PR 31718 at commit b42052c.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135822/

My only concern here is if there's any unexpected behaviour changes between new Path(path) and Utils.resolveURI because Hadoop's Path has not clearly defined behaviours in terms of local paths and URIs IIRC.
Still I agree that we're good as long as we can take canonical URIs and files in Spark, so should be fine to go ahead if we're sure on this.

Test build #135876 has started for PR 31718 at commit 9dc15b9.

@HyukjinKwon OK, to minimize the risk, let's take care only the case which a path is an absolute URI and which contains %.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40459/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40459/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40459/

Test build #135876 has finished for PR 31718 at commit 9dc15b9.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135876/

@sarutak does that mean you want to make further changes?

@srowen No. The latest change is what I made to minimize the compatibility risk.

Jenkins retest this please

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135982/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40566/

retest this please.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/135993/

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40577/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/40577/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40577/

retest this please.

Test build #136022 has started for PR 31718 at commit 9dc15b9.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/40606/

Test build #136022 has finished for PR 31718 at commit 9dc15b9.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/136022/

@HyukjinKwon @srowen Do you have any comment on the latest change?

Merged to master and branch-3.1. Thank you @srowen and @HyukjinKwon .


Update configuring-npm-for-use-with-github-packages.md

Why:

Closes [issue link]
What's being changed:

Check off the following:

[ ] I have reviewed my changes in staging. (look for the deploy-to-heroku link in your pull request, then click View deployment)
[ ] For content changes, I have reviewed the localization checklist
[ ] For content changes, I have reviewed the Content style guide for GitHub Docs.

X

Thanks for opening a PR! It doesn't look like we need an additional space there, so I'm going to close this out.
Take a look at the contributing.md to learn how to contribute in this repo. You can open a discussion if you have any questions or check out issues with the help wanted label. :sparkles:


Implement yieldsRight

I implemented this together with @fhinkel (thanks for the nice coding sessions!).
Fixes #689.

:+1:

Thanks!

Thanks for this, it's very useful!
I couldn't find this in the documentation however. I only found this when I was looking at the source code trying to figure out if there was a simple way of stubbing functions that take callbacks, and discovered that it was already implemented. Is it an officially supported API that I can use without fear of it disappearing?

Honestly, I think this has been left out by mistake. We can try to do it right once #991 ships, I hope.


Depth Buffer Format settings

Describe the bug
Depth Buffer Format is set to 16 bit in Setting-> XR Plugin Management -> Windows Mixed Reality.
Despite this, I get "Depth Buffer Sharing has 24-bit depth format selected. Consider using 16-bit for performance." notification on play.
Expected behavior
No notification on run.
 If so, could you please update to a later version of MRTK? I don't believe this was supported in MRTK 2.4.

Solved by updating MRTK.


async update(table, object, escapes) function in /gestalt-postgres/src/DB.js

proposed compliment to async insert(table, object) would execute UPDATE SET WHERE queries
// updates the db based on a table name, constraints, and column:value key pair in object
  async update(
    table: string,
    object: Object,
    conditions: Object,
  ): Promise<Object> {

    ...

    const result = await this.exec(
      `UPDATE ... SET ... WHERE ... RETURNING *;`,
    );

    ...

    return [altered row];
  }

example:
updating a "hosts_by_location_id" column for updating a User's default Location (Location=HOSTS=>User, User <-HOSTS- Location)

Love it 👍 - if you want to put together a pull, I'll merge it.  Otherwise, I'll add this in the next few days.

added this


fix(dynamic): enable form options with any generic type

Hi! PR #233 introduced dynamic options to be used in forms and initially I was unable to get the following example working:
	var workspaceId, folderId int
	form := huh.NewForm(
		huh.NewGroup(
			huh.NewSelect[int]().
				Title("Choose your workspace").
				Height(15).
				Options(options...). // initial options constructed from API call
				Value(&workspaceId),
			huh.NewSelect[int]().
				Value(&folderId).
				Title("Choose your folder").
				Height(5).
				OptionsFunc(func() (options []huh.Option[int]) {
					if workspaceId == 0 {
						return
					}
					// API call using workspace ID to fetch list of folder ids
					return
				}, &workspaceId),
			huh.NewConfirm().
				Title("Use selected?").
				Value(&proceed),
		),
	)

but I was able to get the examples included in the PR working. Digging further I was able to get my example working using huh.Option[string] and the issue ended up being this particular type switch not matching the generic type huh.Option[int]:
https://github.com/charmbracelet/huh/blob/ccca06d54254036ee839c17e21a38560efc523a8/group.go#L251-L261
I tried bumping the project to Go 1.20 and adding UpdateOptionsMsg[any] to the switch case, but that didn't work, so instead I made the isUpdateOptionsMsg interface and embedded it in UpdateOptionsMsg. I'm unsure if this is the best approach but it does seem to work and I couldn't find in my searching if there is a more intended way to solve this in Go.

Hey @ChrisRx, thanks so much for this PR. I've fixed this issue in #318. Let me know if this works for you!


Class based views class attributes persist between requests

Using a class based view (specifically a MethodView), if you were to save something like a list, dict, or set, as a class attribute, this would persist through different requests.

To reproduce the bug:
class MyView(MethodView):
    a_list = []
    a_dict = dict()
    a_set = set()

    def get(self):
        print(self.a_list, flush=True)
        self.a_list.append(len(self.a_list))
        print(self.a_dict, flush=True)
        self.a_dict[len(self.a_dict.keys())] = len(self.a_dict.keys())
        print(self.a_set, flush=True)
        self.a_set.add(len(self.a_set))
        return ""

If you hit this endpoint, the first time, the list, dict, and set is printed as empty. Then if you hit the same endpoint, the three vars now show the previous requests variables. Keep hitting the endpoint and the list, dict, and set will continue growing without ever refreshing.
Environment:

Python version: 3.8.10
Flask version: 1.1.2

I think the answer here is "don't do that". If you define mutable class level attributes, you should know how they behave.

@ThiefMaster ah I thought these classes are destroyed in memory and brought back up upon a new request. In that case, if I were to use a cached_property from werkzeug, then the data persists as well?

No, those are stored on the instance, and there's a new instance for each request.

Got it. Thank you!


[POC] replace zero-styled path with pigment

closes #10

[ ] I have followed (at least) the PR section of the contributing guide.

This does not work too.


nav-justified displays  incorrect in safari 9.1.2

link: http://www.w3schools.com/bootstrap/tryit.asp?filename=trybs_tabs_pills_justified&stacked=h

open the link with safari and chrome
resize the window size and make it < 768px and resize back ( > 768px)
chrome displays the tabs by one row but safari displays the tabs by 2 rows which is not expected.

Duplicate of #9774.
Known Safari bug, already mentioned in the docs: http://getbootstrap.com/components/#nav-justified
Thankfully, the bug is fixed in the current Safari Technology Preview version.
Sidenote: Protip: Avoid w3schools.


Check implementation in onRestore method to execute onTapShow only wh…

…en pref is not null

A check has been implemented in onRestore to call onTapShow only when the pref is different from null.
Motivación y Contexto

It occurs when we don't have the data a first time and we are coming from the error screen, when we fall into the onRestore method, onTapShow is called without all the necessary data to build the screen, and with the implemented verification method onTapShow will be called only and I have the "pref" filled in, which prevents the crash.
Descripción

Cómo probarlo

To simulate the error it is necessary to leave the device in airplane mode, and perform the first call "Custom initialize". After loading the error screen, exit from airplane mode and click "try again".
Screenshots

Before correction

After correction

Tipo de cambio (para el release manager)

[x] Breaking change (Fix o feature que cambia una funcionalidad existente o rompe firmas)

[ ] Mi cambio afecta a los integradores internos

A new PR was made with this fix.
https://github.com/mercadopago/px-android/pull/2519


Toast hidden under keyboard on android

On android Toast component is opening below the keyboard so it's invisible until the keyboard is closed.
I checked the source and the ToastContainer only checks if the keyboard is opened or not on ios.
What's the story of this if condition?
https://github.com/GeekyAnts/NativeBase/blob/9c470822dc4912c3780cf14426cd3b6a56ef01f4/src/basic/ToastContainer.js#L61

Hi @levani , can you provide the link to snack of minimal reproduction for the same? I don't see anything like you said regarding Toast hidden under keyboard.

Hi @levani , closing for now. Let us know if the issue still persists.


Support local execution for testing by default

It's nice to be able to test your Lambda function in a local, Lambda-like environment as you're developing.
However, currently there's a check for whether or not you're running in Lambda (https://github.com/alixaxel/chrome-aws-lambda/blob/master/source/index.js#L91), and you get the following error when you try to run locally:
Error: Chromium revision is not downloaded. Run "npm install" or "yarn install"

Just faking out the check for headless (doing export AWS_LAMBDA_FUNCTION_NAME=myLambdaFunc or process.env.AWS_LAMBDA_FUNCTION_NAME = 'myLambdaFunc') makes everything work nicely, assuming you're running on a Lambda-like host environment.
Thoughts on just removing the check for headless?

@cschmidt So the reason why this check is in place is due to the Chromium binary itself. Chromium is statically compiled on a 64bit Amazon Linux instance, to ensure compatibility with AWS Lambda.
If this check was removed, and under certain systems, it simply wouldn't start. So I can't get away with it.
There's two solutions for this:

use puppeteer on dev and puppeteer-core on production
fake the AWS_LAMBDA_FUNCTION_NAME environment variable like you're doing (might not work)

For the first option, you would install dependencies like this:
npm install puppeteer --save-dev
npm install puppeteer-core --save-prod

And then you can conditionally require the puppeteer package like this:
const chromium = require('chrome-aws-lambda');
const puppeteer = chromium.puppeteer;

exports.handler = async (event, context) => {
  let browser = await puppeteer.launch({
    args: chromium.args,
    executablePath: await chromium.executablePath,
    headless: chromium.headless,
  });

  // ...
};

The getter is simply a try catch block that falls back to puppeteer-core if puppeteer is not present:
https://github.com/alixaxel/chrome-aws-lambda/blob/eeeca36782738bdd25f6b4d8061d4937501e1f91/source/index.js#L165-L175
Just make sure that you skip devDependencies when deploying to production:
npm install --no-optional --no-shrinkwrap --production && npm dedupe --no-shrinkwrap

PS: Sorry for the delay in the reply.

Serverless is a popular tool for developing AWS functions, and I am using it in conjunction with chrome-aws-lambda. Serverless provides the means of launching a lambda locally using a command line syntax such as:
sls invoke local --function my-function

This also fails to launch puppeteer due to the fact that AWS_LAMBDA_FUNCTION_NAME is set during the invocation in order to simulate the actual environment in AWS.
I am using this approach to support running commands locally using Serverless.
const chromiumOrig = require('chrome-aws-lambda');
const chromium = class ServerlessChromium extends chromiumOrig {
    static get headless() {
        return (process.env.IS_LOCAL) || (process.env.AWS_LAMBDA_FUNCTION_NAME !== undefined);
    }
}

The environment variable IS_LOCAL is set to true when running locally in serverless.

@oravecz Are you saying that when you run sls invoke local both AWS_LAMBDA_FUNCTION_NAME and IS_LOCAL are set?

Yes. IS_LOCAL was added to serverless to programmatically detect invoke local scenarios.
https://github.com/serverless/serverless/issues/3639

@alixaxel Awesome, thanks for already having a solution for this baked in!
One note, if you're doing something like PDF generation you probably just want to set headless to true as chromium.headless with this technique will return false on your local machine.


Allow require macro to unwrap result type as well as optional

Description
It would be very nice to be able to use the require macro to get the success value from a result similar to how you can require than an optional return value is not nil.
Expected behavior
Something like this would be nice:
let inner_value = try #require(Class.resultReturningMethod())
Actual behavior
Have to write something like this:
let inner_value = try #require(try Class.resultReturningMethod().get())
Steps to reproduce
This is a feature request so reproduction isn't really relevant, since the feature doesn't exist yet.
swift-testing version/commit hash
0.11.0
Swift & OS version (output of swift --version && uname -a)
<unknown>:0: warning: using (deprecated) legacy driver, Swift installation does not contain swift-driver at: '/Library/Developer/CommandLineTools/usr/bin/swift-driver-new'
Apple Swift version 6.0 (swiftlang-<IP_ADDRESS>.6 clang-16<IP_ADDRESS>)
Target: x86_64-apple-darwin24.0.0
Darwin Camdens-Mac 24.0.0 Darwin Kernel Version 24.0.0: Thu Jun 20 20:36:19 PDT 2024; root:xnu-11<IP_ADDRESS>1.3~1/RELEASE_X86_64 x86_64

Thanks for filing, @CamJN! This feature isn't necessary because you can simply write:
let inner_value = try Class.resultReturningMethod().get()

If the Result is of case .failure(), its error will be thrown from the test function and will be reported as a test failure.

@grynspan I may be mistaken but I think your snippet has some different behaviour than I was trying to describe.
I believe that let inner_value = try Class.resultReturningMethod().get() will not fail if inner_value is not truthy, correct? That was an important part of what I was trying to do, I didn't mention it because it's just part of how try #require works.

I'm not sure what you mean by "not truthy" here. Do you mean you're specifically interested in Result<Bool, _>? Such a value can also be handled already:
let inner_value = try Class.resultReturningMethod().get()
try #require(inner_value)

I just mean that similar to how if you pass in an optional, it ensures that the value is non-nil and not false, if you pass in a result, it would be really nice if it ensured that the value was success and does not contain false.
I know it's possible to do so with extra checks, but it would be nicer if it was combined.

I just mean that similar to how if you pass in an optional, it ensures that the value is non-nil and not false, if you pass in a result, it would be really nice if it ensured that the value was success and does not contain false.

It doesn't do that, actually. If you pass a value of type Bool?, you'll actually get a warning about it being ambiguous. :)

Oh, oops. I was under the impression that it did both. Might be worth putting a note in the docs about that.


Moving the LibC - support new bindings

The idea is to have a Crystal equivalent of https://golang.org/pkg/syscall/#Statfs_t to retrieve block informations relative to a directory (thus the disk).
My use case is to have the disk usage of the partitions.

The struct involved is LibC::Statfs - what will be its place regarding to File::Info (which is based on LibC::Stat on UN*Xes)?

Why don't you just add the libc bindings in your shard? Your use cases requires zero changes to the stdlib.

Because it's better to have projects that shares reusable code instead of having duplications.

A dedicated repository for libc bindings is created.

What is it good for? If a shard uses a C binding (be it libc or anything else), I'd rather just declare the bindings in that shard instead of relying on another one.

Support for many targets.
Supporting a C binding to a library is easy. Supporting a C binding for a libc call... I wish you good luck.

We'll see how this space matures then maybe make some bindings official once there's something well-used.
Before then, perhaps we should move LibC to Crystal::LibC. Thoughts?

No. It would just be more confusing.

@ysbaddaden how so?

IMO Rust has done this quite right by creating a separate crate in its own repository, and integrating it in the main Rust repository with git submodules (even if I prefer git subtree).

@RX14 It's already bad enough that we have named definitions such as LibC, LibEvent or LibSSL that are purely virtual, because in the end a fun is a fun  wherever it's defined —there can only be one C symbol, and all definitions must match.
Introducing namespaced LibC definitions would push for even more confusion...
IMHO all external symbols should be defined under LibC and that's it (no LibSSL, LibLLVM, ...) —this is what my c2cr binding generator assumes.
@j8r good luck with the shard! It would be fantastic to have, but hard and long and damn error prone... (see my abandoned POSIX project for instance).

@j8r I still don't understand why you don't create a statsfs shard and be done with this discussion, and why not having that specific binding to the function in the standard library bothers you so much. Otherwise, send a PR with those specific C function bindings and a proper wrapper, and someone will surely accept it. The standard library uses C bindings for the standard library. Having more, undocumented, unstable functions so that other shards can use them is not very productive in my opinion. Plus generating those bindings is really complex, as @ysbaddaden points out.
Why do we need this issue open?

@asterite this isn't only about statfs, but about all other native functions provided by various systems.
They doesn't always have there place in the language itself, with wrappers, objects, interfaces etc. — some are really specific to the underlying system.
Creating a shard for this purpose fits well the role.

Totally agree @ysbaddaden . I was just looking at your project clang.cr, and will send you some PRs (LLVM6, split of c2cr).
There is a need for wider LibC support, and the on-the-fly solution can be good if done right - working on it.

@ysbaddaden but that still doesn't stop people treating the stdlib's LibC as if it's a somewhat stable surface, I think moving to Crystal::LibC would better discourage people outside the stdlib from using it.

@ysbaddaden following your work with c2cr, I've modified the libc project to autobind to generate bindings (including libc), with libclang


Improve the Timeline performance

The poor performance of the Timeline event is causing us to have to hide performance tracking tools behind flags: https://github.com/flutter/flutter/pull/100926
One issue is that thread_info calls from the Dart SDK are very slow on iOS ( https://github.com/dart-lang/sdk/issues/47850 ).
This issue is to track all the suggestions and attempts I've made to make things faster over the past few days, hopefully culminating in a change that speeds them up.

For the thread_info issue I've suggested changing the samplerate of the call and interpolating between them.  The measurements for that are here: https://github.com/dart-lang/sdk/issues/47850#issuecomment-1087889382
The results are promising but we are also gated on the performance of the json encoding.

One thing I discovered is that in profile builds the arguments we are sending to the Timeline event are always the same Map that are getting json encoded.  The contents are defined in timelineArgumentsIndicatingLandmarkEvent.  We should be able to find a way to not call json encoding on that constantly.

I found that just caching the results of jsonArguments with the build_bench.dart went from 786.7 µs per iteration to 829.0 µs per iteration
--- a/sdk/lib/developer/timeline.dart
+++ b/sdk/lib/developer/timeline.dart
@@ -361,12 +361,19 @@ class _SyncBlock {
   }
 }

+String _jsonCache = '{}';
+Map? _argumentsCache;
 String _argumentsAsJson(Map? arguments) {
+  if (arguments == _argumentsCache) {
+    return _jsonCache;
+  }
   if ((arguments == null) || (arguments.length == 0)) {
     // Fast path no arguments. Avoid calling jsonEncode.
     return '{}';
   }
-  return json.encode(arguments);
+  _jsonCache = json.encode(arguments);
+  _argumentsCache = arguments;
+  return _jsonCache;
 }

I tried special casing the json encoding for 1 value arguments to capture the case for most of flutter in profile builds, but it didn't make a difference:
--- a/sdk/lib/developer/timeline.dart
+++ b/sdk/lib/developer/timeline.dart
@@ -366,6 +366,14 @@ String _argumentsAsJson(Map? arguments) {
     // Fast path no arguments. Avoid calling jsonEncode.
     return '{}';
   }
+  if (arguments.length == 1) {
+    Object value = arguments.values.first!;
+    if (value is String) {
+      return '{"${arguments.keys.first}": "$value"}';
+    } else if (value is num) {
+      return '{"${arguments.keys.first}": $value}';
+    }
+  }
   return json.encode(arguments);
 }

I found an old comment about how using the {"mode": "basic"} arguments in timeline events caused a 15% regression in performance: https://github.com/flutter/flutter/pull/12058#issuecomment-329841532

https://dart-review.googlesource.com/c/sdk/+/240148/7/runtime/vm/os_macos.cc#111 landed which will have sped up Timeline events for iOS which was the greatest need.

I tested the following change in Dart's timeline.dart and it results in a 16.7% increase in performance in the build_bench.dart benchmark with debugProfileBuildsEnabled turned on.
-String _argumentsAsJson(Map? arguments) {
+String _argumentsAsJson(Map? arguments, {TimelineEventMode? mode}) {
   if ((arguments == null) || (arguments.length == 0)) {
     // Fast path no arguments. Avoid calling jsonEncode.
-    return '{}';
+    if (mode == null) {
+      return '{}';
+    } else {
+      switch(mode) {
+        case TimelineEventMode.basic:
+          return '{ "mode": "basic" }';
+      }
+    }
+  }
+  if (mode != null) {
+    // TODO(gaaclarke): Move mode from outside of the `arguments` parameter into
+    // its own parameter if every call is supposed to have it.
+    // This is modifying `arguments` instead of editing a copy.
+    switch(mode) {
+      case TimelineEventMode.basic:
+        arguments['mode'] = 'basic';
+        break;
+    }
   }
   return json.encode(arguments);
 }

The question I still have to figure out is if we actually even care about those parameters anymore.  The PR that brought them in says they are for "the new developer centric Timeline Dashboard page in Observatory."  That might not even be a requirement anymore. (https://github.com/flutter/flutter/pull/12058)

(Triage) @gaaclarke I assigned this to you since you seem to be actively working on this.


ingest/ledgerbackend: Parse captive core toml to implement better merging

PR Checklist
PR Structure

[ ] This PR has reasonably narrow scope (if not, break it down into smaller PRs).
[ ] This PR avoids mixing refactoring changes with feature changes (split into two PRs
otherwise).
[ ] This PR's title starts with name of package that is most changed in the PR, ex.
services/friendbot, or all or doc if the changes are broad or impact many
packages.

Thoroughness

[ ] This PR adds tests for the most critical parts of the new functionality or fixes.
[ ] I've updated any docs (developer docs, .md
files, etc... affected by this change). Take a look in the docs folder for a given service,
like this one.

Release planning

[ ] I've updated the relevant CHANGELOG (here for Horizon) if
needed with deprecations, added features, breaking changes, and DB schema changes.
[ ] I've decided if this PR requires a new major/minor version according to
semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.

What
This PR fixes https://github.com/stellar/go/issues/3486 and lays the groundwork for implementing https://github.com/stellar/go/issues/3442 .
This PR changes how we interpret captive core append file (configured via --captive-core-config-append-path). Previously, we automatically generated the stellar core toml file for the captive core subprocess in ingest/ledgerbackend/stellar_core_runner.go by presetting some defaults and then concatenating the generated configuration with the user supplied append file.
This strategy did not work out so well because sometimes horizon operators included configuration in the append file which was already configured in the presets generated by ingest/ledgerbackend/stellar_core_runner.go. An example of this type of error can be found in https://github.com/stellar/go/issues/3486 .
Now, in this PR, instead of generating the stellar core toml file via simple string concatenation we actually parse the user supplied append file and try to do more robust merging between the user supplied configuration and the captive core preset defaults. The merging code is implemented in the NewCaptiveCoreToml() function defined in ingest/ledgerbackend/toml.go .
The merging strategy is unfortunately complicated by the fact that captive core configuration can come from 3 places:

User supplied append file
horizon command line flag (e.g. --captive-core-peer-port, --captive-core-http-port, etc)
default values which we preset (e.g. DISABLE_XDR_FSYNC)

In theory the user supplied append file should only contain the quorum set but in practice we have never validated the append file to ensure that it configures a quorum set and nothing else. We could simplify the merging logic in this PR by choosing to validate the append file in this way. I decided not to take that approach because I think that it would be a breaking change for many horizon operators (including SDF) who have configuration in the append file which is not related to quorum sets. If you disagree with this design decision please let me know.
The merging algorithm generally works as follows:
If there is a configuration field which is set both in source (1) and source (2) we check that both sources provide equivalent values, otherwise we return an error.
The exception to this rule is the history archive configuration. We take the history archive configuration from source (1) and completely disregard what is provided in source (2) unless there is no history archive configuration in source (1). The reason for this is that it's difficult to compare the history archive values from source (1) and source (2).
If a configuration field is defined in source (1) but not source (2), we will use the field which is explicitly defined. The same logic applies if the field is defined in source (2) but not source (1).
Finally, if there is no configuration defined in either source (1) or source (2), we use the value from source (3).
In the next PR, my plan is to fully implement https://github.com/stellar/go/issues/3442 by introducing a new horizon command line flag --captive-core-config-file which deprecates --captive-core-config-append-path. The difference between --captive-core-config-file and --captive-core-config-append-path is that the validation is stricter.
--captive-core-config-file will not allow any unknown fields to be present in the toml file, which is achieved by the following snippet:
func (c *CaptiveCoreToml) validate(params CaptiveCoreTomlParams) error {
	if params.Strict {
		if unexpected := c.metadata.Undecoded(); len(unexpected) > 0 {
			var parts []string
			for _, key := range unexpected {
				parts = append(parts, key.String())
			}
			return fmt.Errorf("invalid keys in captive core configuration: %s", strings.Join(parts, ", "))
		}
	}

Furthermore, if --captive-core-config-file is provided then you will not be allowed to use any horizon command line flags to configure captive core. In other words, --captive-core-config-file deprecates source (2).
Along with defining  --captive-core-config-file, the next PR will also add documentation for the captive core configuration file in an captive-core_example.cfg file (similar to how stellar core does it https://github.com/stellar/stellar-core/blob/master/docs/stellar-core_example.cfg ). The example file will document the full range of configuration options available to captive core instances.
Unfortunately there will be some slight differences between the stellar core example cfg and the captive core example cfg because captive core has different defaults compared to stellar core. For example, captive core sets DISABLE_XDR_FSYNC to true by default whereas stellar core sets DISABLE_XDR_FSYNC to false by default. We should think carefully about each of the cases where captive core diverges from stellar core.
Known limitations
The golang toml library doesn't handle nested tables in a way which is consistent with stellar core. As a workaround I implemented some hacky code to flatten nested tables using string manipulation.

@stellar/horizon-committers this ready for a final review now, PTAL!

This PR fixes #3486 and lays the groundwork for implementing #3442 .
This PR changes how we interpret captive core append file (configured via --captive-core-config-append-path). Previously, we automatically generated the stellar core toml file for the captive core subprocess in ingest/ledgerbackend/stellar_core_runner.go by presetting some defaults and then concatenating the generated configuration with the user supplied append file.
This strategy did not work out so well because sometimes horizon operators included configuration in the append file which was already configured in the presets generated by ingest/ledgerbackend/stellar_core_runner.go. An example of this type of error can be found in #3486 .
Now, in this PR, instead of generating the stellar core toml file via simple string concatenation we actually parse the user supplied append file and try to do more robust merging between the user supplied configuration and the captive core preset defaults. The merging code is implemented in ingest/ledgerbackend/toml.go .
The merging strategy is unfortunately complicated by the fact that captive core configuration can come from 3 places:
User supplied append file
horizon command line flag (e.g. --captive-core-peer-port, --captive-core-http-port, etc)
default values which we preset (e.g. DISABLE_XDR_FSYNC)
In theory the user supplied append file should only contain the quorum set but in practice we have never validated the append file to ensure that it configures a quorum set and nothing else. We could simplify the merging logic in this PR by choosing to validate the append file in this way. I decided not to take that approach because I think that it would be a breaking change for many horizon operators (including SDF) who have configuration in the append file which is not related to quorum sets. If you disagree with this design decision please let me know.
The merging algorithm generally works as follows:
If there is a configuration field which is set both in source (1) and source (2) we check that both sources provide equivalent values, otherwise we return an error.
The exception to this rule is the history archive configuration. We take the history archive configuration from source (1) and completely disregard what is provided in source (2) unless there is no history archive configuration in source (1). The reason for this is that it's difficult to compare the history archive values from source (1) and source (2).
If a configuration field is defined in source (1) but not source (2), we will use the field which is explicitly defined. The same logic applies if the field is defined in source (2) but not source (1).
Finally, if there is no configuration defined in either source (1) or source (2), we use the value from source (3).
In the next PR, my plan is to fully implement #3442 by introducing a new horizon command line flag --captive-core-config-file which deprecates --captive-core-config-append-path. The difference between --captive-core-config-file and --captive-core-config-append-path is that the validation is stricter.
--captive-core-config-file will not allow any unknown fields to be present in the toml file.
Furthermore, if --captive-core-config-file is provided then you will not be allowed to use any horizon command line flags to configure captive core. In other words, --captive-core-config-file deprecates source (2).
Along with defining --captive-core-config-file, the next PR will also add documentation for the captive core configuration file in an captive-core_example.cfg file (similar to how stellar core does it https://github.com/stellar/stellar-core/blob/master/docs/stellar-core_example.cfg ). The example file will document the full range of configuration options available to captive core instances.
Unfortunately there will be some slight differences between the stellar core example cfg and the captive core example cfg because captive core has different defaults compared to stellar core. For example, captive core sets DISABLE_XDR_FSYNC to true by default whereas stellar core sets DISABLE_XDR_FSYNC to false by default. We should think carefully about each of the cases where captive core diverges from stellar core.


Kodi plugin inputstream-adaptive - cannot be found by Search

Describe the bug
Inputstream-adaptive cannot be found using Add-ons > Add-ons browser > Search
+ I believe it should be displayed below Add-ons > Add-ons browser > Install from repository > Kodi Addon Repository > VideoPlayer InputStream. Currently I can only find it under the Add-ons > Add-ons browser > My add-ons > VideoPlayer InputStream
To Reproduce
Steps to reproduce the behavior:

Install plugin by nixpkgs.config.kodi.enableInputStreamAdaptive = true;
Restart Kodi and try to find the string "Input" among add-ons.

Expected behavior
The add-on will be found
+ will be displayed under the community repository
Additional context
The same goes for the nixpkgs.config.kodi.enablePVRIPTVSimple = true;
log file:
..
2021-03-25 10:07:41.921 T:139863748228032  NOTICE: ADDON: inputstream.adaptive v2.3.12 installed
..
2021-03-25 10:07:41.922 T:139863748228032  NOTICE: ADDON: pvr.iptvsimple v3.5.7 installed
..

Notify maintainers
@sephalon
Metadata
 - system: `"x86_64-linux"`
 - host os: `Linux 5.4.96, NixOS, 20.09.3072.d4c29df154d (Nightingale)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.10`
 - channels(ln): `"home-manager"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

@nesnera I'm sorry but I'm not a home-manager user so I don't understand the what channel you are on from the output you provided. Are you installing kodi from the 20.09 stable branch, or from unstable? Which version of kodi are you running?
The kodi package and package set was recently rewritten for the release of kodi 19.x so on unstable you can do this now:
# install inputstream-adaptive plugin
environment.systemPackages = with pkgs; [
  (kodi.withPackages (p: with p; [ inputstream-adaptive ]))
];

Or maybe you just want the netflix plugin:
# install netflix plugin, as well as inputstream-adaptive which is a dependency
environment.systemPackages = with pkgs; [
  (kodi.withPackages (p: with p; [ netflix ]))
];

@nesnera please let me know if your issue hasn't been resolved.


[joss paper] remarks

Hi ! A few notes on the paper while i read it :

The example section is abit weird, as, for me (I am not an expert in your field), i did not understand at all what your software did optimize based on what data to obtain the proposed graph. Could you enlarge a bit the section to detail clearly what are 1) Inputs, 2) aims, goals, algorithms, etc.. 3) Outputs ?
While the zenodo archive and the repositories are all on MIT licence, the paper shows out CC By 4.0. This is not necessarily an issue but you might want to sync up (or not).

xref https://github.com/openjournals/joss-reviews/issues/6619

@lrnv Thanks for you comments!
We have updated the example section now, hope it is easier to understand now. We still try keeping it quite brief, as we were a bit concerned about the length (there tend to be a large number of details for all such case studies).
We discussed the license issue internally, and as we understand it the paper will be licensed under CC By 4.0, while the code is licensed under MIT, and that sounds reasonable to us, but feel free to elaborate if this is something that should be aligned.

The example is much easier to read now for me, thanks.
No reason to align the licenses, I just wanted you to consider the issue.
You are good to go now :)


Fix Profiler done() method typing

Hi there!
A quick fix for the Profiler.done method TypeScript typing. It wasn't allowing any parameter, but actually, it does.
Best regards,
François Voron

Great, thank you! This will be included in the next release.


Introduce crossbeam-circbuf

I'm proposing to introduce crossbeam-circbuf, which implements bounded/unbounded SPSC/SPMC queues based on circular buffer.  Bounded queues are implemented with fixed-sized circular buffer.  Unbounded queues are implemented with dynamically growable/shrinkable circular buffer.
Currently I'm not sure how performant this crate is.  A few benchmark will be helpful in evaluating the performance.  I'm thinking of re-purposing the benchmark used in crossbeam-channel.
The implementation is sub-optimal in that it has an unnecessary indirection when accessing the underlying buffer.  In order to remove the indireciton we need to support DST, which is not yet implemented in Crossbeam, though.
We discussed to introduce crossbeam-circbuf in another PR, and there we also discussed tentative crate organizations.  Speaking of organizations, I think crossbeam-deque and crossbeam-arrayqueue can also be incorporated in this crate for the following reasons:

All of them share the same buffer struct.

crossbeam-arrayqueue is actually bounded MPMC queue based on circular buffer.

crossbeam-deque is actually a slight variant of unbounded SPMC queue based on circular buffer.

It seems CI fails due to unrelated issue: https://travis-ci.org/crossbeam-rs/crossbeam/jobs/472150001#L455
bors retry

By extending the crossbeam-channel benchmarks, I get these results for crossbeam-circbuf:
bounded_mpmc              Rust crossbeam-circbuf   0.496 sec
bounded_mpsc              Rust crossbeam-circbuf   0.400 sec
bounded_seq               Rust crossbeam-circbuf   0.138 sec
bounded_spmc              Rust crossbeam-circbuf   0.233 sec
bounded_spsc              Rust crossbeam-circbuf   0.123 sec

And here is MPMC queue:
unbounded_mpmc            Rust queue        0.179 sec
unbounded_mpsc            Rust queue        0.185 sec
unbounded_seq             Rust queue        0.242 sec
unbounded_spmc            Rust queue        0.204 sec
unbounded_spsc            Rust queue        0.112 sec

By bumping the block size from 32 to 256 we get even better results:
unbounded_mpmc            Rust queue        0.166 sec
unbounded_mpsc            Rust queue        0.190 sec
unbounded_seq             Rust queue        0.223 sec
unbounded_spmc            Rust queue        0.162 sec
unbounded_spsc            Rust queue        0.101 sec

And this is crossbeam-deque:
unbounded_seq             Rust crossbeam-deque   0.185 sec
unbounded_spmc            Rust crossbeam-deque   0.286 sec
unbounded_spsc            Rust crossbeam-deque   0.196 sec

My takeaways are:

The bounded SPSC should be a very simple typical SPSC queue instead, not something based on Chase-Lev.

Unbounded SPSC might be faster with something like this, and wouldn't need to use crossbeam-epoch. We could try allocating nodes in blocks to squeeze out more performance from it.

The MPMC queue seems to be faster in the MPMC and MPSC cases.

The case where crossbeam-circuf excels is SPMC, which is unsurprising because that's pretty much the use case Chase-Lev was invented for. But even then the MPMC queue is competitive (maybe because it doesn't need crossbeam-epoch).

Currently, crossbeam-circbuf is a clear winner only in the "seq" (single thread) case, which is uninteresting for a concurrent queue anyway. :( I wonder if we could optimize things some more to find its niche.

I should also add that it's possible that these benchmarks are not measuring the right thing and might be unfair to crossbeam-deque. If you have a suggestion on how to do benchmarks differently, do say!

In my unscientific experiment, it seems the numbers will become much better if we could remove an indirect pointer access using #209.  It'll be roughly on par with #338 for the bounded spsc case.

@jeehoonkang
Do you have any numbers or perhaps benchmarks I could run to reproduce them?
In my first comment on this PR, I noted it takes 0.123 sec for the bounded SPSC variant of crossbeam-circbuf to finish the spsc benchmark. 5 million messages are sent so that means sending & receiving a single message takes 25 ns.
The new bounded SPSC queue spends 0.029 sec on that same benchmark, which is 6 ns per message. That's 4x faster than crossbeam-circbuf.
I honestly doubt the double indirection costs much, if anything (my guess is less than 1 ns per message). The new bounded SPSC channel uses double indirection too, so it definitely cannot cost more than 6 ns per message.
Even if we conservatively assume the cost of double indirection is the whole 6 ns per message, that would mean removing it brings the result for crossbeam-circbuf from 25 ns down to 19 ns, which is still 3x slower than the new queue.

@stjepang I'll soon provide benchmark numbers.  Sorry for delay.


feat: add ENS validation

This adds chain-adapters support for ENS address in address validation.

Rebase ✅

approved, but would be nice to have some tests to go with this

approved, but would be nice to have some tests to go with this

Yeah, since the whole module is fully untested I think it will make more sense to tackle all, or at least as many as possible for it, rather than adding just one! Created #313 for it

This looks good to me, only question I have is how are we verifying that an ens address actually resolves?
@gomesalexandre - thanks for creating the issue for additional tests!

This looks good to me, only question I have is how are we verifying that an ens address actually resolves? @gomesalexandre - thanks for creating the issue for additional tests!

We don't, with this implementation this is done by the client in https://github.com/shapeshift/web/pull/704.
An unresolvable address is still a valid address, from a spec point of view, but maybe it still makes sense for chain-adapters to handle such concerns

Thanks @gomesalexandre - going to merge this!


Supports 3D vertex shaders so that you can play 3D games with Javafx

Supports 3D vertex shaders so that you can play 3D games with Javafx

window can use opengles u can see https://github.com/husker-dev/jfx-win-es2

Update:
The library is compatible with custom JavaFX builds that enable the OpenGL support for Windows. Both 2D and 3D effects seem to work as expected.
I have also added an example of creating a custom ShaderMaterial to the wiki.


[Question/Feedback]: amba-Policy-Compute deployment fails with InvalidPolicyParameterUpdate

Check for previous/existing GitHub issues

[X] I have checked for previous/existing GitHub issues

Description
Using the "Deploy to Azure" button in the blog article https://techcommunity.microsoft.com/t5/azure-governance-and-management/enhancements-to-azure-monitor-baseline-alerts-for-azure-landing/ba-p/4231710.
Deployment of the Compute policy fails as seen in the attached screenshot. Here are the error details:
The existing policy parameter(s) 'networkInterfacesToInclude' were not found in the policy being updated. The parameter names can not be changed. (Code: InvalidPolicyParameterUpdate)
The existing policy parameter(s) 'disksToInclude' were not found in the policy being updated. The parameter names can not be changed. (Code: InvalidPolicyParameterUpdate)

Closed due to duplicate with Issue #328, sorry but when I searched for matching text when creating my issue, no issues appeared in my search. I'll repost if the mitigation steps in Issue #328 don't succeed.


Publish branch for #528

Depends on #528

@juwens please see the additional changes here.  This is what I was looking for.  Thanks for the step in the right direction.


Configurable asset glob

Per your recommendation on #3.  Hopefully this resembles what you had in mind!  If not, let me know, and I'll get it fixed.

Woaaahh I did not know that cattr_accessor actually used a class attribute. I thought its whole point was to avoid the dangers of class attributes. I wonder if I've ever actually used it anywhere!
Ok, sorry I said AssetPath but I realize now that AssetPath is used for the path to the bundled JS, not the path to the files to reload :S Kind of dumb of me to get those mixed up. Do you mind moving that config back to AssetChangeSet? Sorry I got confused :weary:

No worries, yeah I thought it looked like a funny place for it.  I'll move that over to AssetChangeSet.
Do you want to stick with cattr_accessor, or move to some other solution?

I think cattr_accessor is fine since nobody's extending that class, but I think the safest is:
  class << self
    attr_accessor :asset_glob
   end
   self.asset_glob = "#{your-glob}"

Ohhh, maybe this is what i was thinking of: http://apidock.com/rails/Class/class_attribute ¯_(ツ)_/¯

Ok, how does that look?  I switched to class_attribute which basically is doing what you mentioned above.  It's dependent on ActiveSupport, but since this whole gem is for Rails, I figure that's not a horrible thing.

:money_with_wings:  :confetti_ball:

Shipped as 0.4.0

Sweet, thanks!


chore: pin redocli version

cc @rolfyone

Hi @rolfyone @mpetrunic do you recall the reason for pinning the version and what the linter bug was? We're introducing the same linter to builder-specs, so it'd be useful to keep track of this so we know when to upgrade. Thanks!

Hi @rolfyone @mpetrunic do you recall the reason for pinning the version and what the linter bug was? We're introducing the same linter to builder-specs, so it'd be useful to keep track of this so we know when to upgrade. Thanks!

https://github.com/ethereum/beacon-APIs/actions/runs/3523507907/jobs/5907749543
This should work since type field was present in reference object

Ahh that one, I've been getting that error locally all the time.  Thank you for the quick response!


Video Rooms

Video rooms
Addresses: https://github.com/restarone/violet_rails/issues/1598
Initialize your room from the Admin panel,

share the link with participants to join!

guide: https://github.com/domchristie/webrtc-hotwire-rails
implemented till commit: Do not use static properties to support Safari
Todo's:

ability for participants to mute audio / stop video
fix flakiness in new participants connecting to already-joined peers (newly joined peers dont see existing participants until they refresh the page and join again)
fix flakiness in video elements not being removed when participants leave

Bug report.
Able to join same call on multuple tabs
CC: @donrestarone

Unhandled Promise Rejection: TypeError: JSON.stringify cannot serialize cyclic structures.
error since: https://github.com/restarone/violet_rails/pull/1600/commits/1ffbfa9a20f29c244ecd8bbe9e195667fc259611


The default behavior of the installer is not optimal (SRP)

The installer essentially has two behaviors: downloading a specific build based on its tag, and on the other hand, downloading and compiling the source code from the main or latest branch, the latter being its default behavior, as it is desirable for users to download the latest version unless they specify which version to install.
We know at any moment what the latest version is, we have several constants for the different environments that have it stored, so I believe that the latest (and therefore the default behavior) should act as an alias to that version that we know is the latest.
Especially emphasizing that the process that clones the repo is worse since, first it requires having dependencies installed like git, it surely downloads the entire project (including documentation, etc...) which is also slower.
Looking at it carefully and knowing that the installer is used to generate the builds for the releases, perhaps the real interesting thing would be to separate the script in such a way that the installer only stays with the second behavior and set up a new script for the builder that in fact wouldn't need to download the repository since it could do it with the local version (meaning we are currently not separating the responsibilities well in this script).

Thoughts? @khru @Chemaclass


Please add XAMP to system menu

Could you please add more info about what would you like to see in XAMPP?

Please, consider to add https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html to convenient launch xampp manager on various linux distros.

I believe this is a duplicate of #8.
@beltran-rubo is it all right if I work on this issue? I'm interested in maintaining this project and this seems like a good place to start. I'd also like to fix the menu item on MacOS, currently it just says manager-osx.

Adds an example; translations in Polish, German, and English for the beginning.
[Desktop Entry]
Type=Application
Version=1.0
Name=XAMPP Control Panel
Name[pl]=Panel Sterowania XAMPP
Name[de]=XAMPP Steuerungspanel
GenericName=XAMPP Control Panel
GenericName[pl]=Panel Sterowania XAMPP
GenericName[de]=XAMPP Steuerungspanel
Comment=Control Panel for XAMPP
Comment[pl]=Pulpit sterowania XAMPP
Comment[de]=Steuerungspanel für XAMPP
Exec=/opt/lampp/manager-linux-x64.run
Path=/opt/lampp
Icon=/opt/lampp/htdocs/favicon.ico
Terminal=false
Categories=Development;Application;
#MimeType=text/html;text/xml;application/php;
StartupNotify=true
Actions=NewWindow;
[Desktop Action NewWindow]
Name=Open New Window
Name[pl]=Otwórz Nowe Okno
Name[de]=Neues Fenster Öffnen
Exec=/opt/lampp/manager-linux-x64.run
Icon=/opt/lampp/htdocs/favicon.ico
X-KDE-SubstituteUID=true
X-KDE-Username=


Rename SnapPlanner to StraightLinePlanner?

I wonder if it might be more descriptive to rename it based on its new functionality. If you wanted to be super cool, you could rename it GeodesicPlanner :).

+1 for GeodesicPlanner!

I'm guessing 'GeodesicPlanner` is not happening @mkoval?

I'm fine with either GeodesicPlanner or SnapPlanner. I wasn't sure if it was worth making a potentially breaking change just for the cosmetic improvement.
If you feel strongly about it, I can make this change and update AdaPy and HerbPy accordingly.

I do like the name GeodesicPlanner but, unfortunately, there is no way to make this change without breaking backwards compatibility. We should keep it in mind next time we do make a breaking change.

Why not rename it to GeodesicPlanner, subclassed by a wrapper called SnapPlanner which prints a warning when it's instantiated?

:+1: to @cdellin's suggestion.  warnings.DeprecationWarning ahoy!

I'm fine with that if someone sends me a pull request. I don't feel strongly enough about the name to implement it myself. :)
@cdellin @psigen Any takers?


increase staged roll-out of 25 to 100%

@blizzz this will break a lot of things due nextcloud/server#34905

Mh, it is already effective for two weeks.


Add KanuCon's Config File

Overview
This pull request adds a new config file specifically for KanuCon's setup.
Details

The config is specifically aimed at Super Smash Bros, featuring PinMapping settings optimized for the game.
Integrated settings for the Tilt Addon have also been included in this config.

Testing
Tested the new config on my local setup to make sure everything is working as expected.
Additional Notes
Please review and let me know if any changes are required.

Hi @smashBrosKanu - At this time we do not host configs for closed source devices.  This would be best kept as a fork.  If you have plans to open source the device please let me know.

Hi @TheTrainGoes ,Thank you for the information. I'm currently considering whether to open-source the device. I'll keep it as a fork for now, and I'll reach out if I decide to go the open-source route.

Hi @smashBrosKanu - please do!


feat(app-collection): systematically add linked name and "Go to details" cells

Changes
Systematically adds a “name” cell to AppCollections. The name cell will always be linked as long as either a summary or detail route is provided.
Systematically adds a “Go to details” link to AppCollections that have a summary route. This is intended as the primary quick interaction to go from list to detail view when a summary view exists for that list view. This becomes relevant because the default row click interaction for list views with a summary view is to open the summary view (and no longer the detail view).
Relates to #1681.
Signed-off-by: Philipp Rudloff<EMAIL_ADDRESS>Notes & motivation
This PR provides AppCollection with access to both the detail and summary route (if applicable). This is intended to move the responsibility for some pretty important interactions from users of AppCollection into AppCollection itself:

Row-click interactions. They are now conditional depending on the type of AppCollection: a row-click can go to either a summary route (if provided) or a detail route.
Linked name cells. Each use of AppCollection should have a linked name cell (unless there is neither a detail or summary view associated with it).
"Go to details" cell. On uses of AppCollection that have a summary, we want to add a "Go to details" cell that makes the navigation to the detail view available in one click and obvious.

I think these items should be handled more systematically than they currently do. It’s easy to forget adding one of these things on the user side of AppCollection.
As an additional bonus, it allow us to move the three-dot "More" dropdown menu code into AppCollection (in #1680) to avoid repeating it in the list view code.

I’ll wait with this PR a little bit mainly so I know which direction https://github.com/kumahq/kuma-gui/pull/1675 will go in. I’ll likely pull the Shift-Click mechanism out of this. I still would like to add this, but it’s less relevant with the addition of the "Go to details" link.
I plan to integrate a couple of things into AppCollection because they benefit from being abstracted away and into it. This avoids duplicating all sorts of things (the actions dropdown, the "Go to details" link we’re adding, etc.).
That’s exactly what AppCollection should be for.

Honestly, it kinda feels like adding an additional link after the existing 'name' link would probably be fine here. This is what you would do if you were doing this normally. You would just add a new link into the slot.

This is very repetitive and not systematic. We really want this to be systematic so we have less chance of messing it up.

AppCollection is supposed to be as simple as a table as we can get.

Doesn’t mean it shouldn’t help us where it’s the best tool for the job.

I haven't taken a look at this since we've removed the shift-click thing but wanted to say:

This is very repetitive and not systematic. We really want this to be systematic so we have less chance of messing it up.

The biggest problem we had with our old DataOverview component was, over time people had just added more and more things to it in order to avoid being repetitive and trying to be systematic. The biggest problem with KTable is that over time people had just added more and more things to it in the same way.
Where we've ended up with both of those components is extremely overloaded, difficult to manage components that in some cases tried to abstract the entire application into one component (bit of an exaggeration but you know what I mean). I want to take care to try to avoid returning to that.
Now, these things maybe seem simple, but they are sometimes hard to get right, and its is often a fine balance, but sometimes its just easier and more obvious, and in the longer term more flexible, to just use a Detail link. Links are pretty hard to mess up, whereas the rapidly growing code inside AppCollection is.
As I said its a fine balance, and sometimes hard to get right, but we should try, and with that being said I'll take a look at this again, but as it stood previously my overarching thought was, "why aren't we just using a link?"

The biggest problem we had with our old DataOverview component was, over time people had just added more and more things to it in order to avoid being repetitive and trying to be systematic.

Yeah but the abstraction of some (!) of thisstuff was actually a good part of DataOverview that we dropped with AppCollection. We currently repeat the exact same dropdown code over about 10 list views. That’s just not great. The same applies to various additions like the "Go to details" cell or the linked name cell. We shouldn’t need to re-implement those every time.

Draft until we figured the UX a little more.

Closing this for the time being. If I pick this up again, it’ll likely happen via https://github.com/kumahq/kuma-gui/pull/1680.


libnvvpi1: add recipe

Add recipe for installing the Nvidia VPI library.
Signed-off-by: Ilies CHERGUI<EMAIL_ADDRESS>

Adding a recipe to build a program against the library that we can use for testing would be best
Not sure we need the container-runtime-csv support for this package
The devso-symlink packaging is probably not needed, either

Agree 100% that we need at least a sample to test the library
I was not sure tbh, I will remove it
I will remove the devso-symlink package

Thanks a lot for your feedback


'draw' fires twice on .update()

I think I've found 2 bugs in v0.7.2 (line chart updates):
'draw' event fires once if I do this:
myChart.update(myData);
Bug 1: 'draw' event fires twice if I do this:
myChart.update(myData, myOptions, true);
Bug 2: "Uncaught TypeError: Cannot read property 'chart' of undefined" on line 2443 in chartist.js if I choose to not extend the options:
myChart.update(myData, myOptions, false);   // or:
myChart.update(myData, myOptions);
Bug 2 probably related to bug 1..  because it only throws the error once, presumably on the second 'draw' attempt.

Thanks for the report! You're right there is a bug and unfortunately this is not a very well tested part of the library.
There are actually two problems. The first one is that on optionsProvider recreation there is an immediate optionsChanged event triggered that will trigger an other update (thats why you've seen two events)
Actually the problem boils down to this line https://github.com/gionkunz/chartist-js/blob/develop/src/scripts/base.js#L40
The second problem, which of I didn't even think when I've accepted this PR for additional options override in updates, is that if you specify not to extend to options, an empty object will be used as base for the options. Which is completely non-sense as there are many default configurations required so Chartist can do its work. I think I've fixed these issues and will write some unit tests for this too.

Also I've renamed extendObjects to override as I find extendObjects quite meaningless if I think about it now.

Very nice explanation and thanks for looking in to that.


Add class comments to classes in ODBC-FFI

Would it be possible to add class comments to these methods (for instance with a link to external spec/docu for specific types)?

Issue was migrated from https://github.com/rko281/Pharo-ODBC/issues/3

Fixed


Landing page

Added a login page
Added a post method to access auth_token and userkey
Added an api base url

Changes Unknown when pulling 5f30b35dd2552a7caee6cb72b2f961386ea00676 on Meowvw:LandingPage into ** on HearthStats:dev**.

Changes Unknown when pulling 15cf8363d4e52950ba0012a0f990be4422e33d91 on Meowvw:LandingPage into ** on HearthStats:dev**.

I've tried it but the application does not start properly. I see the new landing frame in the task bar but cannot get it to display as a window so it's unusable.
I checked quickly the files, the config is still using  a local IP instead of the hearthstats.net URL but it's not the cause of the issue.
Can you please test it a bit more with the real server ? Also it could be related to the initial configuration, check if it works when you remove the configuration in your windows registry.

that's what I got, not so sure what problem it is, but yes, I 'll recheck it

You can call on Skype (tyrcho) when you see me online, if I can help you reproducing my issue ... In the current state I cannot merge this.


Unity 2020.1.13f1 compability issue with mirror 47.0.1 (46+)

Cannot build application for Windows on empty project
Install Unity on version 2020.1.13f1 (UnityHub link:  unityhub://2020.1.13f1/5e24f28bfbc0)
*Modules I have installed Android support, WebGL, Windows Build Support (IL2CPP)
*Create new  empty 3d Project
*Import Mirror from github release package or from Asset store (version 47.0.1)
*Restart editor
File Build settings-> Player->Other Settings _> Scripting  Backend Mono, API .Net 2.0 or .Net 4x
*Add example Scene from Mirror/Examples/Pong/Scenes to Scenes in Build
*Select target platorm to PC Windows x86_64
*hit build button
Expected behavior
Creates build  package without errors
Build stacktrace  error logs:
https://pastie.io/ogyfdw.tex
Desktop :

OS: Windows 10
Build target: Windows
Unity version: 2020.1.13f1
Mirror branch: master

Additional context
-the same reproduction on newer version of Unity like 2020.3.18f1 doesn't make any problems.

I found that Mirror 45.2 is the latest version that compiles with 2020.1.13f1. All versions after 45.2+ are not compiling and have issues with Weaver.

Weird, maybe this is 2020.1 specific? I have Mirror 46 in 2020.3 and it has no problems

please try 2020.3 LTS and report back :)

please try 2020.3 LTS and report back :)
we can change the ifdef to 2020.3 OR NEWER

18 days ago I wrote:
Additional context
-the same reproduction on newer version of Unity like 2020.3.18f1 doesn't make any problems.
= 2020.3 LTS no problemo, but I would like to use 2020.1 :P

@DanielDurys changed ifdefs to 2020_3_OR_NEWER on master.
please try.


Custom Class incompatibility with R.Swift used in Unit Tests

Version used: 5.0.2
When I set Custom Class > Class in Storyboard I got error from compiler:

Use of undeclared type 'xxxViewController'

when I remove it as below:

I got broken outlet and action connections:

and I get SIGABR panic when running app and test case

Could you check if the Module is set correctly, it sounds like the Module is not set in interfacebuilder and therefore R.swift does not add the correct import statement at top of the generated file.
See also: https://github.com/mac-cain13/R.swift/blob/master/Documentation/QandA.md#how-to-fix-missing-imports-in-the-generated-file

I have there checked checkbox inherit from target.

When I uncheck "Inherit Module From Target" and write my main target "xxxMap" in Module field and leave valid class in field above I get:

error shows twice per ViewController (I have 2 views controller's on storyboard ATM)

docs need to be fixed
to make my project compile with R.Swift I needed to change my Build Phase script to:
"$PODS_ROOT/R.swift/rswift" generate "$SRCROOT/[MAIN TARGET]/R.generated.swift"

and Output Files to
"$SRCROOT/[MAIN TARGET]/R.generated.swift"

Swift 4.2
Xcode 10.1

Ah, sounds like you missed the upgrade instructions from R.swift 4 to 5: https://github.com/mac-cain13/R.swift/blob/master/Documentation/Migration.md#upgrading-to-50
Any suggestions how we could improve this documentation so it's harder to miss?

Well for me this is not upgrading. I just started to use v5.0.2 for the first time. So I did not searched for any upgrade path.


Problem creating a new Flutter app

Steps to Reproduce

I'm not able to create or run old Flutter apps on my Mac. I've tried reconfiguring in .bash_profile and other options. Please, help i have two apps which are almost ready for production that i need to complete. Thank you

Logs

flutter --verbose create first_app
[  +26 ms] executing: [/Users/kenny/flutter/] git rev-parse --abbrev-ref
--symbolic @{u}
[  +54 ms] Exit code 0 from: git rev-parse --abbrev-ref --symbolic @{u}
[        ] origin/stable
[        ] executing: [/Users/kenny/flutter/] git rev-parse --abbrev-ref HEAD
[   +9 ms] Exit code 0 from: git rev-parse --abbrev-ref HEAD
[        ] stable
[        ] executing: [/Users/kenny/flutter/] git ls-remote --get-url origin
[   +8 ms] Exit code 0 from: git ls-remote --get-url origin
[        ] https://github.com/flutter/flutter.git
[        ] executing: [/Users/kenny/flutter/] git log -n 1 --pretty=format:%H
[   +9 ms] Exit code 0 from: git log -n 1 --pretty=format:%H
[        ] 8661d8aecd626f7f57ccbcb735553edc05a2e713
[        ] executing: [/Users/kenny/flutter/] git log -n 1 --pretty=format:%ar
[  +10 ms] Exit code 0 from: git log -n 1 --pretty=format:%ar
[        ] 3 weeks ago
[   +1 ms] executing: [/Users/kenny/flutter/] git describe --match v*.*.*
--first-parent --long --tags
[  +10 ms] Exit code 0 from: git describe --match v*.*.* --first-parent --long
--tags
[   +3 ms] v1.2.1-0-g8661d8aec
[ +292 ms] Creating project first_app...
[  +49 ms]   first_app/ios/Runner.xcworkspace/contents.xcworkspacedata (created)
[   +3 ms]   first_app/ios/Runner/Info.plist (created)
[  +24 ms]
<EMAIL_ADDRESS>             (created)
[   +3 ms]
<EMAIL_ADDRESS>             (created)
[   +2 ms]   first_app/ios/Runner/Assets.xcassets/LaunchImage.imageset/README.md
(created)
[   +2 ms]
first_app/ios/Runner/Assets.xcassets/LaunchImage.imageset/Contents.json
             (created)
[   +2 ms]
first_app/ios/Runner/Assets.xcassets/LaunchImage.imageset/LaunchImage.png
             (created)
[   +2 ms]
<EMAIL_ADDRESS>             (created)
[   +2 ms]
<EMAIL_ADDRESS>             (created)
[   +2 ms]
<EMAIL_ADDRESS>             (created)
[   +3 ms]
<EMAIL_ADDRESS>             (created)
[   +2 ms]
first_app/ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-1024x1024@1x.
             png (created)
[   +2 ms]
first_app/ios/Runner/Assets.xcassets/AppIcon.appiconset/Icon-App-83.5x83.5@2x.
             png (created)
[   +2 ms]
<EMAIL_ADDRESS>             (created)
[   +3 ms]
first_app/ios/Runner/Assets.xcassets/AppIcon.appiconset/Contents.json
             (created)
[   +3 ms]
<EMAIL_ADDRESS>             (created)
[   +2 ms]
<EMAIL_ADDRESS>             (created)
[   +2 ms]
<EMAIL_ADDRESS>             (created)
[   +2 ms]
<EMAIL_ADDRESS>             (created)
[   +3 ms]
<EMAIL_ADDRESS>             (created)
[   +2 ms]
<EMAIL_ADDRESS>             (created)
[   +3 ms]
<EMAIL_ADDRESS>             (created)
[   +3 ms]
<EMAIL_ADDRESS>             (created)
[   +2 ms]   first_app/ios/Runner/Base.lproj/LaunchScreen.storyboard (created)
[   +2 ms]   first_app/ios/Runner/Base.lproj/Main.storyboard (created)
[   +2 ms]
first_app/ios/Runner.xcodeproj/project.xcworkspace/contents.xcworkspacedata
             (created)
[   +3 ms]
first_app/ios/Runner.xcodeproj/xcshareddata/xcschemes/Runner.xcscheme
             (created)
[   +2 ms]   first_app/ios/Flutter/Debug.xcconfig (created)
[   +2 ms]   first_app/ios/Flutter/Release.xcconfig (created)
[   +2 ms]   first_app/ios/Flutter/AppFrameworkInfo.plist (created)
[   +1 ms]   first_app/test/widget_test.dart (created)
[   +6 ms]   first_app/first_app.iml (created)
[   +2 ms]   first_app/.gitignore (created)
[   +2 ms]   first_app/.metadata (created)
[   +3 ms]   first_app/ios/Runner/AppDelegate.h (created)
[   +2 ms]   first_app/ios/Runner/main.m (created)
[   +2 ms]   first_app/ios/Runner/AppDelegate.m (created)
[   +2 ms]   first_app/ios/Runner.xcodeproj/project.pbxproj (created)
[  +20 ms]
first_app/ios/Runner.xcodeproj/xcshareddata/xcschemes/Runner.xcscheme (existing
- skipped)
[   +1 ms]   first_app/android/app/src/profile/AndroidManifest.xml (created)
[   +2 ms]   first_app/android/app/src/main/res/mipmap-mdpi/ic_launcher.png
(created)
[   +2 ms]   first_app/android/app/src/main/res/mipmap-hdpi/ic_launcher.png
(created)
[   +2 ms]   first_app/android/app/src/main/res/drawable/launch_background.xml
(created)
[   +2 ms]   first_app/android/app/src/main/res/mipmap-xxxhdpi/ic_launcher.png
(created)
[   +2 ms]   first_app/android/app/src/main/res/mipmap-xxhdpi/ic_launcher.png
(created)
[   +1 ms]   first_app/android/app/src/main/res/values/styles.xml (created)
[   +1 ms]   first_app/android/app/src/main/res/mipmap-xhdpi/ic_launcher.png
(created)
[   +2 ms]   first_app/android/app/src/main/AndroidManifest.xml (created)
[   +2 ms]   first_app/android/app/src/debug/AndroidManifest.xml (created)
[   +2 ms]   first_app/android/gradle/wrapper/gradle-wrapper.properties
(created)
[   +2 ms]   first_app/android/gradle.properties (created)
[   +1 ms]   first_app/android/settings.gradle (created)
[   +1 ms]   first_app/pubspec.yaml (created)
[   +3 ms]   first_app/README.md (created)
[   +2 ms]   first_app/lib/main.dart (created)
[   +4 ms]   first_app/android/app/build.gradle (created)
[   +2 ms]
first_app/android/app/src/main/java/com/example/first_app/MainActivity.java
             (created)
[   +1 ms]   first_app/android/build.gradle (created)
[   +1 ms]   first_app/android/first_app_android.iml (created)
[   +1 ms]   first_app/.idea/runConfigurations/main_dart.xml (created)
[   +2 ms]   first_app/.idea/libraries/Flutter_for_Android.xml (created)
[   +1 ms]   first_app/.idea/libraries/Dart_SDK.xml (created)
[   +1 ms]   first_app/.idea/libraries/KotlinJavaRuntime.xml (created)
[   +1 ms]   first_app/.idea/modules.xml (created)
[   +1 ms]   first_app/.idea/workspace.xml (created)
[ +127 ms] Running "flutter packages get" in first_app...
[   +4 ms] Using /Users/kenny/flutter/.pub-cache for the pub cache.
[   +2 ms] executing: [/Users/kenny/first_app/]
/Users/kenny/flutter/bin/cache/dart-sdk/bin/pub --verbosity=warning --verbose
get --no-precompile

What is the error that you are getting?

Had this fixed already. Thank you