cocoyaxi[libcurl] build failure

Host Environment

OS: Windows 10
Compiler: VC++ 2022

To Reproduce
Steps to reproduce the behavior:
./vcpkg install co[libcurl]:x64-windows
package: co[core,libcurl]:x64-windows -> 2.0.2#1
vcpkg-tool version: 2021-11-24-48b94a6946b8a70abd21529218927fd478d02b6c
Failure logs
PS D:\repo\vcpkg-master> .\vcpkg install co[libcurl]:x64-windows
Computing installation plan...
The following packages will be built and installed:
    co[core,libcurl]:x64-windows -> 2.0.2#1
Detecting compiler hash for triplet x64-windows...
Restored 0 packages from C:\Users\PROJECT\AppData\Local\vcpkg\archives in 151.9 us. Use --debug to see more details.
Starting package 1/1: co:x64-windows
Building package co[core,libcurl]:x64-windows...
-- Downloading https://github.com/idealvin/co/archive/25915760f5cbcde1c5af625dd4d19a632ae43f12.tar.gz -> idealvin-co-25915760f5cbcde1c5af625dd4d19a632ae43f12.tar.gz...
[DEBUG] Feature flag 'binarycaching' unset
[DEBUG] Feature flag 'manifests' = off
[DEBUG] Feature flag 'compilertracking' unset
[DEBUG] Feature flag 'registries' unset
[DEBUG] Feature flag 'versions' unset
[DEBUG] Downloading https://github.com/idealvin/co/archive/25915760f5cbcde1c5af625dd4d19a632ae43f12.tar.gz
Error: Failed to download from mirror set:
File does not have the expected hash:
             url : [ https://github.com/idealvin/co/archive/25915760f5cbcde1c5af625dd4d19a632ae43f12.tar.gz ]
       File path : [ D:\Repo\vcpkg-master\downloads\idealvin-co-25915760f5cbcde1c5af625dd4d19a632ae43f12.tar.gz.22440.part ]
   Expected hash : [ 892d70923409306ab548cf4568f15ffd13949047a5a7810c68d60c1afd184eafd2076f62eb6249ae64b38c409255cb873fa28740ceab37b908b70174ddf6d077 ]
     Actual hash : [ ad0d914e05371816862ef404fd8910106da90aa774c14e3e30cdf9c248a08a0ef00a40e2fdf54ac8f7b87886a50470b8415c0cca34f0a489989ca117973b3a61 ]

[DEBUG] D:\a\_work\1\s\src\vcpkg\base\downloads.cpp(656)
[DEBUG] Time in subprocesses: 0 us
[DEBUG] Time in parsing JSON: 1 us
[DEBUG] Time in JSON reader: 0 us
[DEBUG] Time in filesystem: 863 us
[DEBUG] Time in loading ports: 0 us
[DEBUG] Exiting after 6.618 s (6610960 us)

CMake Error at scripts/cmake/vcpkg_download_distfile.cmake:84 (message):

      Failed to download file with error: 1
      If you use a proxy, please check your proxy setting. Possible causes are:

      1. You are actually using an HTTP proxy, but setting HTTPS_PROXY variable
         to `https://address:port`. This is not correct, because `https://` prefix
         claims the proxy is an HTTPS proxy, while your proxy (v2ray, shadowsocksr
         , etc..) is an HTTP proxy. Try setting `http://address:port` to both
         HTTP_PROXY and HTTPS_PROXY instead.

      2. You are using Fiddler. Currently a bug (https://github.com/microsoft/vcpkg/issues/17752)
         will set HTTPS_PROXY to `https://fiddler_address:port` which lead to problem 1 above.
         Workaround is open Windows 10 Settings App, and search for Proxy Configuration page,
         Change `http=address:port;https=address:port` to `address`, and fill the port number.

      3. You proxy's remote server is out of service.

      In future vcpkg releases, if you are using Windows, you no longer need to set
      HTTP(S)_PROXY environment variables. Vcpkg will simply apply Windows IE Proxy
      Settings set by your proxy software. See (https://github.com/microsoft/vcpkg-tool/pull/49)
      and (https://github.com/microsoft/vcpkg-tool/pull/77)

      Otherwise, please submit an issue at https://github.com/Microsoft/vcpkg/issues

Call Stack (most recent call first):
  scripts/cmake/vcpkg_download_distfile.cmake:309 (z_vcpkg_download_distfile_show_proxy_and_fail)
  scripts/cmake/vcpkg_from_github.cmake:175 (vcpkg_download_distfile)
  ports/co/portfile.cmake:5 (vcpkg_from_github)
  scripts/ports.cmake:142 (include)

Error: Building package co:x64-windows failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `git pull` and `.\vcpkg update`.
Then check for known issues at:
  https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+co
You can submit a new issue at:
  https://github.com/microsoft/vcpkg/issues/new?template=report-package-build-failure.md&title=[co]+Build+error
including:
  package: co[core,libcurl]:x64-windows -> 2.0.2#1
    vcpkg-tool version: 2021-11-24-48b94a6946b8a70abd21529218927fd478d02b6c
    vcpkg-scripts version: unknown

Additionally, attach any relevant sections from the log files above.

Tried with the latest vcpkg after pulling from git, but without success.
PS D:\NewRepo\vcpkg-master> .\vcpkg install cocoyaxi[libcurl]:x64-windows-static
Computing installation plan...
A suitable version of cmake was not found (required v3.22.2). Downloading portable cmake v3.22.2...
Downloading cmake...
  https://github.com/Kitware/CMake/releases/download/v3.22.2/cmake-3.22.2-windows-i386.zip -> D:\NewRepo\vcpkg-master\downloads\cmake-3.22.2-windows-i386.zip
Extracting cmake...
The following packages will be built and installed:
    cocoyaxi[core,libcurl]:x64-windows-static -> 2.0.3#2
  * curl[core,non-http,openssl,schannel,ssl,sspi]:x64-windows-static -> 7.84.0
  * openssl[core]:x64-windows-static -> 3.0.5
  * vcpkg-cmake[core]:x64-windows -> 2022-07-02
  * vcpkg-cmake-config[core]:x64-windows -> 2022-02-06#1
  * vcpkg-cmake-get-vars[core]:x64-windows -> 2022-05-10#1
  * zlib[core]:x64-windows-static -> 1.2.12#1
Additional packages (*) will be modified to complete this operation.
Detecting compiler hash for triplet x64-windows...
A suitable version of git was not found (required v2.7.4). Downloading portable git v2.7.4...
Downloading git...
  https://github.com/git-for-windows/git/releases/download/v2.35.1.windows.2/PortableGit-<IP_ADDRESS>-32-bit.7z.exe -> D:\NewRepo\vcpkg-master\downloads\PortableGit-<IP_ADDRESS>-32-bit.7z.exe
Extracting git...
A suitable version of powershell-core was not found (required v7.2.5). Downloading portable powershell-core v7.2.5...
Downloading powershell-core...
  https://github.com/PowerShell/PowerShell/releases/download/v7.2.5/PowerShell-7.2.5-win-x86.zip -> D:\NewRepo\vcpkg-master\downloads\PowerShell-7.2.5-win-x86.zip
Extracting powershell-core...
Detecting compiler hash for triplet x64-windows-static...
Restored 0 package(s) from C:\Users\PROJECT\AppData\Local\vcpkg\archives in 1.168 ms. Use --debug to see more details.
Installing 1/7 vcpkg-cmake:x64-windows...
Building vcpkg-cmake[core]:x64-windows...
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/vcpkg_cmake_configure.cmake
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/vcpkg_cmake_build.cmake
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/vcpkg_cmake_install.cmake
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/vcpkg-port-config.cmake
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/copyright
-- Performing post-build validation
-- Performing post-build validation done
A suitable version of 7zip was not found (required v21.7.0). Downloading portable 7zip v21.7.0...
Downloading 7zip...
  https://www.7-zip.org/a/7z2107-extra.7z -> D:\NewRepo\vcpkg-master\downloads\7z2107-extra.7z
Extracting 7zip...
Stored binary cache: "C:\Users\PROJECT\AppData\Local\vcpkg\archives\6b\6be5626089172c019cf1104c82ca92ad9cda9594a9e8686154a4b108620a7071.zip"
Elapsed time to handle vcpkg-cmake:x64-windows: 4.367 s
Installing 2/7 vcpkg-cmake-config:x64-windows...
Building vcpkg-cmake-config[core]:x64-windows...
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake-config_x64-windows/share/vcpkg-cmake-config/vcpkg_cmake_config_fixup.cmake
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake-config_x64-windows/share/vcpkg-cmake-config/vcpkg-port-config.cmake
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake-config_x64-windows/share/vcpkg-cmake-config/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: "C:\Users\PROJECT\AppData\Local\vcpkg\archives\66\66f1db94eea6ee7da0ec458fca7cb71b8ce5f2e33196797bfcdb3192fc158698.zip"
Elapsed time to handle vcpkg-cmake-config:x64-windows: 91.15 ms
Installing 3/7 vcpkg-cmake-get-vars:x64-windows...
Building vcpkg-cmake-get-vars[core]:x64-windows...
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake-get-vars_x64-windows/share/vcpkg-cmake-get-vars/vcpkg_cmake_get_vars.cmake
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake-get-vars_x64-windows/share/vcpkg-cmake-get-vars/cmake_get_vars
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake-get-vars_x64-windows/share/vcpkg-cmake-get-vars/cmake_get_vars/CMakeLists.txt
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake-get-vars_x64-windows/share/vcpkg-cmake-get-vars/vcpkg-port-config.cmake
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake-get-vars_x64-windows/share/vcpkg-cmake-get-vars/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: "C:\Users\PROJECT\AppData\Local\vcpkg\archives\a4\a43322c160e3e137155e619a84e79bef50943a5244353f6fb8f19fff5c5bcc08.zip"
Elapsed time to handle vcpkg-cmake-get-vars:x64-windows: 101.6 ms
Installing 4/7 openssl:x64-windows-static...
Building openssl[core]:x64-windows-static...
-- Downloading https://github.com/openssl/openssl/archive/openssl-3.0.5.tar.gz -> openssl-openssl-openssl-3.0.5.tar.gz...
-- Extracting source D:/NewRepo/vcpkg-master/downloads/openssl-openssl-openssl-3.0.5.tar.gz
-- Applying patch D:/NewRepo/vcpkg-master/ports/openssl/windows/flags.patch
-- Using source at D:/NewRepo/vcpkg-master/buildtrees/openssl/src/nssl-3.0.5-df50913d32.clean
-- Downloading https://strawberryperl.com/download/<IP_ADDRESS>/strawberry-perl-<IP_ADDRESS>-32bit.zip -> strawberry-perl-<IP_ADDRESS>-32bit.zip...
-- Downloading https://www.nasm.us/pub/nasm/releasebuilds/2.15.05/win32/nasm-2.15.05-win32.zip;https://fossies.org/windows/misc/nasm-2.15.05-win32.zip -> nasm-2.15.05-win32.zip...
-- Downloading https://download.qt.io/official_releases/jom/jom_1_1_3.zip;https://mirrors.ocf.berkeley.edu/qt/official_releases/jom/jom_1_1_3.zip -> jom_1_1_3.zip...
-- Found external ninja('1.10.2').
-- Getting CMake variables for x64-windows-static
-- Copying openssl release source files...
-- Copying openssl release source files... done
-- Configure x64-windows-static-rel
-- Configure x64-windows-static-rel done
-- Build x64-windows-static-rel
-- Build x64-windows-static-rel done
-- Copying openssl debug source files...
-- Copying openssl debug source files... done
-- Configure x64-windows-static-dbg
-- Configure x64-windows-static-dbg done
-- Build x64-windows-static-dbg
-- Build x64-windows-static-dbg done
-- Installing: D:/NewRepo/vcpkg-master/packages/openssl_x64-windows-static/share/openssl/copyright
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/openssl_x64-windows-static/lib/pkgconfig/libcrypto.pc
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/openssl_x64-windows-static/lib/pkgconfig/libssl.pc
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/openssl_x64-windows-static/lib/pkgconfig/openssl.pc
-- Downloading https://repo.msys2.org/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst;https://www2.futureware.at/~nickoe/msys2-mirror/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst;https://mirror.yandex.ru/mirrors/msys2/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst;https://mirrors.tuna.tsinghua.edu.cn/msys2/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst;https://mirrors.ustc.edu.cn/msys2/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst;https://mirror.bit.edu.cn/msys2/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst;https://mirror.selfnet.de/msys2/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst;https://mirrors.sjtug.sjtu.edu.cn/msys2/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst -> msys-mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst...
-- Downloading https://repo.msys2.org/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst;https://www2.futureware.at/~nickoe/msys2-mirror/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst;https://mirror.yandex.ru/mirrors/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst;https://mirrors.tuna.tsinghua.edu.cn/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst;https://mirrors.ustc.edu.cn/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst;https://mirror.bit.edu.cn/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst;https://mirror.selfnet.de/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst;https://mirrors.sjtug.sjtu.edu.cn/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst -> msys-mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst...
-- Using msys root at D:/NewRepo/vcpkg-master/downloads/tools/msys2/9a1ec3f33446b195
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/openssl_x64-windows-static/debug/lib/pkgconfig/libcrypto.pc
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/openssl_x64-windows-static/debug/lib/pkgconfig/libssl.pc
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/openssl_x64-windows-static/debug/lib/pkgconfig/openssl.pc
-- Installing: D:/NewRepo/vcpkg-master/packages/openssl_x64-windows-static/share/openssl/usage
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: "C:\Users\PROJECT\AppData\Local\vcpkg\archives\5c\5c7b2c382184f86b61a7c29f2abeea3688783c21436d141ba06671c6d30988f9.zip"
Elapsed time to handle openssl:x64-windows-static: 5.213 min
Installing 5/7 zlib:x64-windows-static...
Building zlib[core]:x64-windows-static...
-- Downloading https://github.com/madler/zlib/archive/v1.2.12.tar.gz -> madler-zlib-v1.2.12.tar.gz...
-- Extracting source D:/NewRepo/vcpkg-master/downloads/madler-zlib-v1.2.12.tar.gz
-- Applying patch cmake_dont_build_more_than_needed.patch
-- Applying patch 0001-Prevent-invalid-inclusions-when-HAVE_-is-set-to-0.patch
-- Applying patch debug-postfix-mingw.patch
-- Applying patch 0002-android-build-mingw.patch
-- Using source at D:/NewRepo/vcpkg-master/buildtrees/zlib/src/v1.2.12-f2d39b538c.clean
-- Found external ninja('1.10.2').
-- Configuring x64-windows-static
-- Building x64-windows-static-dbg
-- Building x64-windows-static-rel
-- Installing: D:/NewRepo/vcpkg-master/packages/zlib_x64-windows-static/share/zlib/vcpkg-cmake-wrapper.cmake
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/zlib_x64-windows-static/lib/pkgconfig/zlib.pc
-- Using cached msys-mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst.
-- Using cached msys-mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst.
-- Using msys root at D:/NewRepo/vcpkg-master/downloads/tools/msys2/9a1ec3f33446b195
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/zlib_x64-windows-static/debug/lib/pkgconfig/zlib.pc
-- Installing: D:/NewRepo/vcpkg-master/packages/zlib_x64-windows-static/share/zlib/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: "C:\Users\PROJECT\AppData\Local\vcpkg\archives\1a\1a6eef2bc562a2052c9fd124ba4214e956d629bcee68a1caf6161789673b07dd.zip"
Elapsed time to handle zlib:x64-windows-static: 9.012 s
Installing 6/7 curl:x64-windows-static...
Building curl[core,non-http,openssl,schannel,ssl,sspi]:x64-windows-static...
-- Downloading https://github.com/curl/curl/archive/curl-7_84_0.tar.gz -> curl-curl-curl-7_84_0.tar.gz...
-- Extracting source D:/NewRepo/vcpkg-master/downloads/curl-curl-curl-7_84_0.tar.gz
-- Applying patch 0002_fix_uwp.patch
-- Applying patch 0005_remove_imp_suffix.patch
-- Applying patch 0012-fix-dependency-idn2.patch
-- Applying patch 0020-fix-pc-file.patch
-- Applying patch 0021-normaliz.patch
-- Applying patch 0022-deduplicate-libs.patch
-- Applying patch mbedtls-ws2_32.patch
-- Applying patch export-components.patch
-- Using source at D:/NewRepo/vcpkg-master/buildtrees/curl/src/url-7_84_0-fad13a6c94.clean
-- Found external ninja('1.10.2').
-- Configuring x64-windows-static
-- Building x64-windows-static-dbg
-- Building x64-windows-static-rel
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/curl_x64-windows-static/lib/pkgconfig/libcurl.pc
-- Using cached msys-mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst.
-- Using cached msys-mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst.
-- Using msys root at D:/NewRepo/vcpkg-master/downloads/tools/msys2/9a1ec3f33446b195
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/curl_x64-windows-static/debug/lib/pkgconfig/libcurl.pc
-- Installing: D:/NewRepo/vcpkg-master/packages/curl_x64-windows-static/share/curl/vcpkg-cmake-wrapper.cmake
-- Installing: D:/NewRepo/vcpkg-master/packages/curl_x64-windows-static/share/curl/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: "C:\Users\PROJECT\AppData\Local\vcpkg\archives\c3\c32cf8759a2e611bb6ed090273c8787e9bbd0b4d3d25e9b055162eac8a8b241b.zip"
Elapsed time to handle curl:x64-windows-static: 1.563 min
Installing 7/7 cocoyaxi:x64-windows-static...
Building cocoyaxi[core,libcurl]:x64-windows-static...
-- Downloading https://github.com/idealvin/cocoyaxi/archive/3fd22601de4d7a06548ca4d24ac36b4f82cde8c5.tar.gz -> idealvin-cocoyaxi-3fd22601de4d7a06548ca4d24ac36b4f82cde8c5.tar.gz...
[DEBUG] To include the environment variables in debug output, pass --debug-env
[DEBUG] Feature flag 'binarycaching' unset
[DEBUG] Feature flag 'manifests' = off
[DEBUG] Feature flag 'compilertracking' unset
[DEBUG] Feature flag 'registries' unset
[DEBUG] Feature flag 'versions' unset
[DEBUG] Downloading https://github.com/idealvin/cocoyaxi/archive/3fd22601de4d7a06548ca4d24ac36b4f82cde8c5.tar.gz
Error: Failed to download from mirror set:
File does not have the expected hash:
             url : [ https://github.com/idealvin/cocoyaxi/archive/3fd22601de4d7a06548ca4d24ac36b4f82cde8c5.tar.gz ]
       File path : [ D:\NewRepo\vcpkg-master\downloads\idealvin-cocoyaxi-3fd22601de4d7a06548ca4d24ac36b4f82cde8c5.tar.gz.40464.part ]
   Expected hash : [ 15a7fbd934b44ffd981067c18a66bf07423d8ded102d0c15b79c2f451192f17541b9c1a3d4eb913d9f8c7a55e051e4e1968e16a1113fa81038b3ad9534c57874 ]
     Actual hash : [ 2b261458e81cc7488bc4d12335b623a750071082b949ffa638e09ca2263ebfab7f8dd83dcb7c6b0085046fda26b5a52992f8907afb39f8f9e74601479c2fb9a7 ]

[DEBUG] D:\a\_work\1\s\src\vcpkg\base\downloads.cpp(766):
[DEBUG] Time in subprocesses: 0 us
[DEBUG] Time in parsing JSON: 3 us
[DEBUG] Time in JSON reader: 0 us
[DEBUG] Time in filesystem: 3513 us
[DEBUG] Time in loading ports: 0 us
[DEBUG] Exiting after 1.978 s (1967448 us)

CMake Error at scripts/cmake/vcpkg_download_distfile.cmake:24 (message):

      Failed to download file with error: 1
      If you use a proxy, please check your proxy setting. Possible causes are:

      1. You are actually using an HTTP proxy, but setting HTTPS_PROXY variable
         to `https://address:port`. This is not correct, because `https://` prefix
         claims the proxy is an HTTPS proxy, while your proxy (v2ray, shadowsocksr
         , etc..) is an HTTP proxy. Try setting `http://address:port` to both
         HTTP_PROXY and HTTPS_PROXY instead.

      2. You are using Fiddler. Currently a bug (https://github.com/microsoft/vcpkg/issues/17752)
         will set HTTPS_PROXY to `https://fiddler_address:port` which lead to problem 1 above.
         Workaround is open Windows 10 Settings App, and search for Proxy Configuration page,
         Change `http=address:port;https=address:port` to `address`, and fill the port number.

      3. Your proxy's remote server is out of service.

      In future vcpkg releases, if you are using Windows, you no longer need to set
      HTTP(S)_PROXY environment variables. Vcpkg will simply apply Windows IE Proxy
      Settings set by your proxy software. See (https://github.com/microsoft/vcpkg-tool/pull/49)
      and (https://github.com/microsoft/vcpkg-tool/pull/77)

      Otherwise, please submit an issue at https://github.com/Microsoft/vcpkg/issues

Call Stack (most recent call first):
  scripts/cmake/vcpkg_download_distfile.cmake:249 (z_vcpkg_download_distfile_show_proxy_and_fail)
  scripts/cmake/vcpkg_from_github.cmake:106 (vcpkg_download_distfile)
  ports/cocoyaxi/portfile.cmake:1 (vcpkg_from_github)
  scripts/ports.cmake:147 (include)

error: building cocoyaxi:x64-windows-static failed with: BUILD_FAILED
Please ensure you're using the latest port files with `git pull` and `vcpkg update`.
Then check for known issues at:
    https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+cocoyaxi
You can submit a new issue at:
    https://github.com/microsoft/vcpkg/issues/new?template=report-package-build-failure.md&title=[cocoyaxi]+Build+error
Include '[cocoyaxi] Build error' in your bug report title, the following version information in your bug description, and attach any relevant failure logs from above.
    vcpkg-tool version: 2022-07-21-a0e87e227afb536c62188c11ad029954f28fdb22
    vcpkg-scripts version: unknown

You can also use the prefilled template from D:\NewRepo\vcpkg-master\installed\vcpkg\issue_body.md.

Tried after pulling from git again , still without success. Here the log:

PS D:\NewRepo\vcpkg-master> .\vcpkg install cocoyaxi[libcurl]:x64-windows-static
Computing installation plan...
A suitable version of cmake was not found (required v3.24.0). Downloading portable cmake v3.24.0...
Downloading cmake...
https://github.com/Kitware/CMake/releases/download/v3.24.0/cmake-3.24.0-windows-i386.zip -> D:\NewRepo\vcpkg-master\downloads\cmake-3.24.0-windows-i386.zip
Extracting cmake...
The following packages will be built and installed:
cocoyaxi[core,libcurl]:x64-windows-static -> 2.0.3#2

curl[core,non-http,openssl,schannel,ssl,sspi]:x64-windows-static -> 7.84.0#1
openssl[core]:x64-windows-static -> 3.0.5#3
vcpkg-cmake[core]:x64-windows -> 2022-07-18
vcpkg-cmake-config[core]:x64-windows -> 2022-02-06#1
vcpkg-cmake-get-vars[core]:x64-windows -> 2022-05-10#1
zlib[core]:x64-windows-static -> 1.2.12#1
Additional packages (*) will be modified to complete this operation.
Detecting compiler hash for triplet x64-windows...
A suitable version of git was not found (required v2.7.4). Downloading portable git v2.7.4...
Downloading git...
https://github.com/git-for-windows/git/releases/download/v2.35.1.windows.2/PortableGit-<IP_ADDRESS>-32-bit.7z.exe -> D:\NewRepo\vcpkg-master\downloads\PortableGit-<IP_ADDRESS>-32-bit.7z.exe
Extracting git...
A suitable version of powershell-core was not found (required v7.2.5). Downloading portable powershell-core v7.2.5...
Downloading powershell-core...
https://github.com/PowerShell/PowerShell/releases/download/v7.2.5/PowerShell-7.2.5-win-x86.zip -> D:\NewRepo\vcpkg-master\downloads\PowerShell-7.2.5-win-x86.zip
Extracting powershell-core...
Detecting compiler hash for triplet x64-windows-static...
Restored 0 package(s) from C:\Users\PROJECT\AppData\Local\vcpkg\archives in 898.9 us. Use --debug to see more details.
Installing 1/7 vcpkg-cmake:x64-windows...
Building vcpkg-cmake[core]:x64-windows...
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/vcpkg_cmake_configure.cmake
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/vcpkg_cmake_build.cmake
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/vcpkg_cmake_install.cmake
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/vcpkg-port-config.cmake
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake_x64-windows/share/vcpkg-cmake/copyright
-- Performing post-build validation
-- Performing post-build validation done
A suitable version of 7zip was not found (required v21.7.0). Downloading portable 7zip v21.7.0...
Downloading 7zip...
https://www.7-zip.org/a/7z2107-extra.7z -> D:\NewRepo\vcpkg-master\downloads\7z2107-extra.7z
Extracting 7zip...
Stored binary cache: "C:\Users\PROJECT\AppData\Local\vcpkg\archives\dd\dd483f88e42e6a2787c509dd60599afb95dee62ccd92b3e66f5aa777a90eecde.zip"
Elapsed time to handle vcpkg-cmake:x64-windows: 6.07 s
Installing 2/7 vcpkg-cmake-config:x64-windows...
Building vcpkg-cmake-config[core]:x64-windows...
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake-config_x64-windows/share/vcpkg-cmake-config/vcpkg_cmake_config_fixup.cmake
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake-config_x64-windows/share/vcpkg-cmake-config/vcpkg-port-config.cmake
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake-config_x64-windows/share/vcpkg-cmake-config/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: "C:\Users\PROJECT\AppData\Local\vcpkg\archives\ff\ffdb70b10b36a5efa1b812133eb37c569b5a7a06a842e21890789c61187d67ad.zip"
Elapsed time to handle vcpkg-cmake-config:x64-windows: 89.01 ms
Installing 3/7 vcpkg-cmake-get-vars:x64-windows...
Building vcpkg-cmake-get-vars[core]:x64-windows...
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake-get-vars_x64-windows/share/vcpkg-cmake-get-vars/vcpkg_cmake_get_vars.cmake
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake-get-vars_x64-windows/share/vcpkg-cmake-get-vars/cmake_get_vars
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake-get-vars_x64-windows/share/vcpkg-cmake-get-vars/cmake_get_vars/CMakeLists.txt
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake-get-vars_x64-windows/share/vcpkg-cmake-get-vars/vcpkg-port-config.cmake
-- Installing: D:/NewRepo/vcpkg-master/packages/vcpkg-cmake-get-vars_x64-windows/share/vcpkg-cmake-get-vars/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: "C:\Users\PROJECT\AppData\Local\vcpkg\archives\52\5234c8d400c9503db8ecdfa168f8367d1489a7dca31c4f2195cbd7feb624e347.zip"
Elapsed time to handle vcpkg-cmake-get-vars:x64-windows: 104.6 ms
Installing 4/7 openssl:x64-windows-static...
Building openssl[core]:x64-windows-static...
-- Downloading https://github.com/openssl/openssl/archive/openssl-3.0.5.tar.gz -> openssl-openssl-openssl-3.0.5.tar.gz...
-- Extracting source D:/NewRepo/vcpkg-master/downloads/openssl-openssl-openssl-3.0.5.tar.gz
-- Applying patch D:/NewRepo/vcpkg-master/ports/openssl/windows/flags.patch
-- Using source at D:/NewRepo/vcpkg-master/buildtrees/openssl/src/nssl-3.0.5-df50913d32.clean
-- Downloading https://strawberryperl.com/download/<IP_ADDRESS>/strawberry-perl-<IP_ADDRESS>-32bit.zip -> strawberry-perl-<IP_ADDRESS>-32bit.zip...
-- Downloading https://www.nasm.us/pub/nasm/releasebuilds/2.15.05/win32/nasm-2.15.05-win32.zip;https://fossies.org/windows/misc/nasm-2.15.05-win32.zip -> nasm-2.15.05-win32.zip...
-- Downloading https://download.qt.io/official_releases/jom/jom_1_1_3.zip;https://mirrors.ocf.berkeley.edu/qt/official_releases/jom/jom_1_1_3.zip -> jom_1_1_3.zip...
-- Found external ninja('1.10.2').
-- Getting CMake variables for x64-windows-static
-- Copying openssl release source files...
-- Copying openssl release source files... done
-- Configure x64-windows-static-rel
-- Configure x64-windows-static-rel done
-- Build x64-windows-static-rel
-- Build x64-windows-static-rel done
-- Copying openssl debug source files...
-- Copying openssl debug source files... done
-- Configure x64-windows-static-dbg
-- Configure x64-windows-static-dbg done
-- Build x64-windows-static-dbg
-- Build x64-windows-static-dbg done
-- Installing: D:/NewRepo/vcpkg-master/packages/openssl_x64-windows-static/share/openssl/copyright
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/openssl_x64-windows-static/lib/pkgconfig/libcrypto.pc
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/openssl_x64-windows-static/lib/pkgconfig/libssl.pc
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/openssl_x64-windows-static/lib/pkgconfig/openssl.pc
-- Downloading https://repo.msys2.org/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst;https://www2.futureware.at/~nickoe/msys2-mirror/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst;https://mirror.yandex.ru/mirrors/msys2/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst;https://mirrors.tuna.tsinghua.edu.cn/msys2/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst;https://mirrors.ustc.edu.cn/msys2/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst;https://mirror.bit.edu.cn/msys2/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst;https://mirror.selfnet.de/msys2/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst;https://mirrors.sjtug.sjtu.edu.cn/msys2/mingw/i686/mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst -> msys-mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst...
-- Downloading https://repo.msys2.org/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst;https://www2.futureware.at/~nickoe/msys2-mirror/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst;https://mirror.yandex.ru/mirrors/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst;https://mirrors.tuna.tsinghua.edu.cn/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst;https://mirrors.ustc.edu.cn/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst;https://mirror.bit.edu.cn/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst;https://mirror.selfnet.de/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst;https://mirrors.sjtug.sjtu.edu.cn/msys2/mingw/i686/mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst -> msys-mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst...
-- Using msys root at D:/NewRepo/vcpkg-master/downloads/tools/msys2/9a1ec3f33446b195
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/openssl_x64-windows-static/debug/lib/pkgconfig/libcrypto.pc
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/openssl_x64-windows-static/debug/lib/pkgconfig/libssl.pc
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/openssl_x64-windows-static/debug/lib/pkgconfig/openssl.pc
-- Installing: D:/NewRepo/vcpkg-master/packages/openssl_x64-windows-static/share/openssl/usage
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: "C:\Users\PROJECT\AppData\Local\vcpkg\archives\40\406ed99b5081c7cbbd0755633da55cd2f47596593d50d3a54ac2a0995f161af6.zip"
Elapsed time to handle openssl:x64-windows-static: 14.95 min
Installing 5/7 zlib:x64-windows-static...
Building zlib[core]:x64-windows-static...
-- Downloading https://github.com/madler/zlib/archive/v1.2.12.tar.gz -> madler-zlib-v1.2.12.tar.gz...
-- Extracting source D:/NewRepo/vcpkg-master/downloads/madler-zlib-v1.2.12.tar.gz
-- Applying patch cmake_dont_build_more_than_needed.patch
-- Applying patch 0001-Prevent-invalid-inclusions-when-HAVE_-is-set-to-0.patch
-- Applying patch debug-postfix-mingw.patch
-- Applying patch 0002-android-build-mingw.patch
-- Using source at D:/NewRepo/vcpkg-master/buildtrees/zlib/src/v1.2.12-f2d39b538c.clean
-- Found external ninja('1.10.2').
-- Configuring x64-windows-static
-- Building x64-windows-static-dbg
-- Building x64-windows-static-rel
-- Installing: D:/NewRepo/vcpkg-master/packages/zlib_x64-windows-static/share/zlib/vcpkg-cmake-wrapper.cmake
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/zlib_x64-windows-static/lib/pkgconfig/zlib.pc
-- Using cached msys-mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst.
-- Using cached msys-mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst.
-- Using msys root at D:/NewRepo/vcpkg-master/downloads/tools/msys2/9a1ec3f33446b195
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/zlib_x64-windows-static/debug/lib/pkgconfig/zlib.pc
-- Installing: D:/NewRepo/vcpkg-master/packages/zlib_x64-windows-static/share/zlib/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: "C:\Users\PROJECT\AppData\Local\vcpkg\archives\3b\3bdd4cdb573e8019b94f17fd002c9704ebc578eda942b04e43bba3626d174274.zip"
Elapsed time to handle zlib:x64-windows-static: 7.602 s
Installing 6/7 curl:x64-windows-static...
Building curl[core,non-http,openssl,schannel,ssl,sspi]:x64-windows-static...
-- Downloading https://github.com/curl/curl/archive/curl-7_84_0.tar.gz -> curl-curl-curl-7_84_0.tar.gz...
-- Extracting source D:/NewRepo/vcpkg-master/downloads/curl-curl-curl-7_84_0.tar.gz
-- Applying patch 0002_fix_uwp.patch
-- Applying patch 0005_remove_imp_suffix.patch
-- Applying patch 0012-fix-dependency-idn2.patch
-- Applying patch 0020-fix-pc-file.patch
-- Applying patch 0021-normaliz.patch
-- Applying patch 0022-deduplicate-libs.patch
-- Applying patch mbedtls-ws2_32.patch
-- Applying patch export-components.patch
-- Using source at D:/NewRepo/vcpkg-master/buildtrees/curl/src/url-7_84_0-fad13a6c94.clean
-- Found external ninja('1.10.2').
-- Configuring x64-windows-static
-- Building x64-windows-static-dbg
-- Building x64-windows-static-rel
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/curl_x64-windows-static/lib/pkgconfig/libcurl.pc
-- Using cached msys-mingw-w64-i686-pkg-config-0.29.2-3-any.pkg.tar.zst.
-- Using cached msys-mingw-w64-i686-libwinpthread-git-<IP_ADDRESS>73.5be8fcd83-1-any.pkg.tar.zst.
-- Using msys root at D:/NewRepo/vcpkg-master/downloads/tools/msys2/9a1ec3f33446b195
-- Fixing pkgconfig file: D:/NewRepo/vcpkg-master/packages/curl_x64-windows-static/debug/lib/pkgconfig/libcurl.pc
-- Installing: D:/NewRepo/vcpkg-master/packages/curl_x64-windows-static/share/curl/vcpkg-cmake-wrapper.cmake
-- Installing: D:/NewRepo/vcpkg-master/packages/curl_x64-windows-static/share/curl/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: "C:\Users\PROJECT\AppData\Local\vcpkg\archives\93\933a2e8b98ef27d57829fe0e5128a55ae50b17cae2a51ed43166b51579c88a13.zip"
Elapsed time to handle curl:x64-windows-static: 1.388 min
Installing 7/7 cocoyaxi:x64-windows-static...
Building cocoyaxi[core,libcurl]:x64-windows-static...
-- Downloading https://github.com/idealvin/cocoyaxi/archive/3fd22601de4d7a06548ca4d24ac36b4f82cde8c5.tar.gz -> idealvin-cocoyaxi-3fd22601de4d7a06548ca4d24ac36b4f82cde8c5.tar.gz...
[DEBUG] To include the environment variables in debug output, pass --debug-env
[DEBUG] Feature flag 'binarycaching' unset
[DEBUG] Feature flag 'manifests' = off
[DEBUG] Feature flag 'compilertracking' unset
[DEBUG] Feature flag 'registries' unset
[DEBUG] Feature flag 'versions' unset
[DEBUG] Downloading https://github.com/idealvin/cocoyaxi/archive/3fd22601de4d7a06548ca4d24ac36b4f82cde8c5.tar.gz
Error: Failed to download from mirror set:
File does not have the expected hash:
url : [ https://github.com/idealvin/cocoyaxi/archive/3fd22601de4d7a06548ca4d24ac36b4f82cde8c5.tar.gz ]
File path : [ D:\NewRepo\vcpkg-master\downloads\idealvin-cocoyaxi-3fd22601de4d7a06548ca4d24ac36b4f82cde8c5.tar.gz.49492.part ]
Expected hash : [ 15a7fbd934b44ffd981067c18a66bf07423d8ded102d0c15b79c2f451192f17541b9c1a3d4eb913d9f8c7a55e051e4e1968e16a1113fa81038b3ad9534c57874 ]
Actual hash : [ 2b261458e81cc7488bc4d12335b623a750071082b949ffa638e09ca2263ebfab7f8dd83dcb7c6b0085046fda26b5a52992f8907afb39f8f9e74601479c2fb9a7 ]

[DEBUG] D:\a_work\1\s\src\vcpkg\base\downloads.cpp(766):
[DEBUG] Time in subprocesses: 0 us
[DEBUG] Time in parsing JSON: 3 us
[DEBUG] Time in JSON reader: 0 us
[DEBUG] Time in filesystem: 970 us
[DEBUG] Time in loading ports: 0 us
[DEBUG] Exiting after 1.81 s (1801921 us)
CMake Error at scripts/cmake/vcpkg_download_distfile.cmake:32 (message):
  Failed to download file with error: 1
  If you use a proxy, please check your proxy setting. Possible causes are:

  1. You are actually using an HTTP proxy, but setting HTTPS_PROXY variable
     to `https://address:port`. This is not correct, because `https://` prefix
     claims the proxy is an HTTPS proxy, while your proxy (v2ray, shadowsocksr
     , etc..) is an HTTP proxy. Try setting `http://address:port` to both
     HTTP_PROXY and HTTPS_PROXY instead.

  2. You are using Fiddler. Currently a bug (https://github.com/microsoft/vcpkg/issues/17752)
     will set HTTPS_PROXY to `https://fiddler_address:port` which lead to problem 1 above.
     Workaround is open Windows 10 Settings App, and search for Proxy Configuration page,
     Change `http=address:port;https=address:port` to `address`, and fill the port number.

  3. Your proxy's remote server is out of service.

  In future vcpkg releases, if you are using Windows, you no longer need to set
  HTTP(S)_PROXY environment variables. Vcpkg will simply apply Windows IE Proxy
  Settings set by your proxy software. See (https://github.com/microsoft/vcpkg-tool/pull/49)
  and (https://github.com/microsoft/vcpkg-tool/pull/77)

  Otherwise, please submit an issue at https://github.com/Microsoft/vcpkg/issues

Call Stack (most recent call first):
scripts/cmake/vcpkg_download_distfile.cmake:273 (z_vcpkg_download_distfile_show_proxy_and_fail)
scripts/cmake/vcpkg_from_github.cmake:106 (vcpkg_download_distfile)
ports/cocoyaxi/portfile.cmake:1 (vcpkg_from_github)
scripts/ports.cmake:147 (include)
error: building cocoyaxi:x64-windows-static failed with: BUILD_FAILED
Please ensure you're using the latest port files with git pull and vcpkg update.
Then check for known issues at:
https://github.com/microsoft/vcpkg/issues?q=is%3Aissue+is%3Aopen+in%3Atitle+cocoyaxi
You can submit a new issue at:
https://github.com/microsoft/vcpkg/issues/new?template=report-package-build-failure.md&title=[cocoyaxi]+Build+error
Include '[cocoyaxi] Build error' in your bug report title, the following version information in your bug description, and attach any relevant failure logs from above.
vcpkg-tool version: 2022-07-21-a0e87e227afb536c62188c11ad029954f28fdb22
vcpkg-scripts version: unknown
You can also use the prefilled template from D:\NewRepo\vcpkg-master\installed\vcpkg\issue_body.md.


LXD: Modifes errorResponse.Render function to JSON encode a api.ResponseRaw struct

Rather than using Jmap.
This brings it inline with OperationResponse.Render(), ForwardedOperationResponse.Render() and syncResponse.Render() functions.
This confused me for a while as I couldn't understand why api.ResponseRaw.Error wasn't referenced anywhere in the code, yet was being used in api.Response.Error to display the error message in lxdParseResponse.
Includes https://github.com/lxc/lxd/pull/9280

@stgraber one question I had was whether it would be acceptable to add omit_empty to api.ResponseRaw struct so that no all possible fields are returned for all types of responses (as it is today)?

@stgraber I also don't understand why the api.Response* structs have both Code (for error responses) and StatusCode (for sync responses) fields, when they also have a Type field indicating the type of the response?
Do you have any insight into how this came about?
We probably can't change it now, but I wonder if we can deprecate one field whilst still populating it, and start populating the other for all response types.

@tomponline I suspect what happened is that all the different response types were treated as completely separate struct initially and only got merged together into one struct when I wrote the new Go client package a few years back.
I can't think of a good reason why we'd have wanted separate fields in a shared struct when we already have the type as differentiator. And if we did, I'd probably have wanted a ErrorCode for symmetry.
Before we merge them into one we need to make sure that Code in the case of an error is always set to one of the values from shared/api/status_code.go as those while similar in ranges, differ from HTTP codes as may be used for errors.


Revert "1.3.1 sdk upgrade"

Reverts ton-blockchain/verifier#204

Help
On Wed, 25 Dec, 2024, 10:24 am Frenky9871, @.***> wrote:

@.**** approved this pull request.
—
Reply to this email directly, view it on GitHub
https://github.com/ton-blockchain/verifier/pull/335#pullrequestreview-2522326754,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BKDPQKBNAYZEPTQIWJXLPAL2HI3ALAVCNFSM6AAAAABS3NAQMCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDKMRSGMZDMNZVGQ
.
You are receiving this because you commented.Message ID:
@.***>


fix(i18n): frontend zh_TW

frontend add zh_TW support
Fill #28169 missing changes.

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

Project coverage is 60.48%. Comparing base (76d897e) to head (6d3cf8b).

Additional details and impacted files
@@           Coverage Diff           @@
##           master   #28255   +/-   ##
=======================================
  Coverage   60.48%   60.48%
=======================================
  Files        1931     1931
  Lines       76236    76236
  Branches     8568     8568
=======================================
  Hits        46114    46114
  Misses      28017    28017
  Partials     2105     2105

Flag
Coverage Δ

javascript
57.71% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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


TOMEE-2919 : Fix for ConcurrentModificationException error deploying …

Fix for ConcurrentModificationException error while deploying ear in TomEE Plus 7.1.2 or above
https://issues.apache.org/jira/browse/TOMEE-2919
https://issues.apache.org/jira/browse/OPENEJB-2145

Thank you so much, Geeth!

Thank you Sir!
Any idea when the next minor version (7.1.5, I think) will be put out?
On Thu, Apr 21, 2022 at 5:28 PM David Blevins @.***>
wrote:

Thank you so much, Geeth!
—
Reply to this email directly, view it on GitHub
https://github.com/apache/tomee/pull/868#issuecomment-1105822934, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAHTLI2Q3ZBHUG7KFJUZZ3TVGHJBRANCNFSM5UARUA3Q
.
You are receiving this because you authored the thread.Message ID:
@.***>

That I do not know.  The last 7.1.x was 2020 and everyone has largely been focused on maintaining 8.x and getting 9.x ready for a final release.
My advice would be to send a note to the<EMAIL_ADDRESS>list (email<EMAIL_ADDRESS>first or your mail will be rejected).  Ask real nicely for a 7.1.x and volunteer to help review the binaries when they go up for a vote.  Mention you contributed a patch and if you really want to motivate people, say you're interested in contributing more :)


BC break: HierarchicalComponent methods signature

to improve the method the signature should be update so that the only parameter type accepted is the string.

This issue was resolve when the URI Components where decoupled from the main league URI library in the league uri components package


The reference image and key image are exactly the same

In the article (QDTrack), the difference between the key image and the reference image is indicated by the image below.

However, when debugging the training code, I saw that the reference image metadata and key image metadata returned by the data loader are exactly the same.

Do I need to change a parameter before starting training or is this an error in the code? I would be glad if you inform me.

Hi @Hcayirli， we use images from detection set and tracking set for joint tracking. It is possible to use the same image as reference for training, especially for those images in the detection set.

Thanks for your quick response.
So how can we change this? Is there a parameter I can change in the code?

Here.

I am getting the following NotImplementedError.

How can I implement it to load a different image?


[WIP]Further Improvements in Color Picker User Experience

This PR completely removes any changes whenever either 'panels' are clicked outside the Stream Popover.
Moreover, Now the user can see how the stream swatch(Octathorpe) will look like in 'real-time' (The swatch color is updated as soon as the user clicks any color box) and choose the color accordingly.
Thanks a lot, @priyank-p for your help.

@timabbott you mentioned that you would like to see the 'Confirm' button totally gone here. With this commit, I believe we won't be needing it anymore since the user can basically click on the color box, choose accordingly, and simply click the chevron to hide the popover. I would love to know your opinions on this. Cheers :)

Can you post a screencast showing how this is meant to work?

I tested this locally and it seems to work fine

One thing here I am not understanding is if I change clickoutFiresChange boolean values for both sidebar_popover_colorpicker_options and sidebar_popover_colorpicker_options_full it's not making any difference (but according to docs it should)
Also, since we are live changing and saving the color the Confirm button now doesn't make any sense here, we can completely remove it to save space @timabbott what do you think?

Also, since we are live changing and saving the color the Confirm button now doesn't make any sense here, we can completely remove it to save space @timabbott what do you think?

I am working on it unless @timabbott has any objections?

Yes, I think given the other changes here, we can remove the "Confirm" button.

@PawBud can you clean up the commit message and PR title, and also mark this as closing the issue it resolves?

Sure @timabbott, but you see I stumbled upon a bug Which is preventing the octothorpe with the id stream_sidebar_swatch_{id} which is pointed by the cursor.
.
@priyank-p  noticed that the ID  #stream_sidebar_privacy_swatch_ + id. is being shared by 2 components hence causing the chaos.
Moreover the showButton: false is not working. It is responsible to hide both the cancel and the Confirm/Choose button as written here.

@PawBud can you clean up the commit message and PR title, and also mark this as closing the issue it resolves?
I think we should keep the [WIP] tag until the aforementioned bugs are solved. I see that Further Improvements in Color Picker User Experience is a bit abstract so I will change it to something much more precise.
As for the commit message, I will simply write it as `resolved #{issue_id}'.

One thing here I am not understanding is if I change clickoutFiresChange boolean values for both sidebar_popover_colorpicker_options and sidebar_popover_colorpicker_options_full it's not making any difference (but according to docs it should).

I am not sure about this @SiddharthVarshney, Something similar is happening to showButtons. Spectrum's docs are not very clear, to be honest!

We merged a change that just did the clickoutFiresChange change; I don't really understand the motivation for the rest here?

@timabbott, so this PR “further improves” the User Experience for the color picker by basically  exchanging the “change” event with the “move” event. This means that as soon as the user clicks on the color; It will instantly change the color thus removing the need for the “Confirm” Button.
The problem here is that since we won’t be needing the Confirm Buttom anymore, we can remove it using showButton: false. It’s probably a bug and I am looking into it.


embassy-stm32 on STM32F1: SPI1 malfunction with "alternate" pins - how to disable JTAG TRACESWO/NJRST?

Hello,
I'm currently debugging a particularly nasty and not too well documented issue with SPI on STM32F1 MCUs and embassy-stm32.
The basic problem is, I have a board design where I use the "alternate" PB3, PB4 and PB5 pins for the SPI1 peripherial with the STM32F103 chip instead of the "primary" pins PA5, PA6, PA7.

Under any circumstances, there just was no output on MOSI, MISO or SCK pins whatsoever.
I could not get them working on Rust and started fiddling around with the oscilloscope and the "official" STM32 HAL in C and with STM32CubeMX.
The problem seems that there are the SYS_JTD_TRACESWO and SYS_NJTRST pin confugurations for PB3 and PB4 that are unused most of the time in practice, but seem to be enabled somehow by default and messing with SPI1 configuration.
After initial failure to get SPI1 with the official C HAL as well, I found out ( with "inofficial" documentation ) that you actually either have to
disable SWD debugging entirely with __HAL_AFIO_REMAP_SWJ_DISABLE()
or
"disable JTAG, but enable SWD?!" with __HAL_AFIO_REMAP_SWJ_NOJTAG()
( --> https://codedocs.xyz/polfeliu/cantata/group__GPIOEx__AFIO__AF__REMAPPING.html is not very helpful...)
When I use either function in C before SPI1 configuration, SPI1 with alternate pin mapping works flawlessly ( and with the second option, I can still use SWD ).
These functions actually modify the "JTAG/SWD alternate function remapping" bits in the AFIO register.
See page 176 here: https://www.st.com/resource/en/reference_manual/cd00171190-stm32f101xx-stm32f102xx-stm32f103xx-stm32f105xx-and-stm32f107xx-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf
Is there actually a method to disable these JTAG pins with embassy/embassy-stm32 on STM32F1, so SPI1 is usable with the "alternate" pins?

Ok.
I fixed this by manually configuring the AFIO register and SPI1 remap register.
`    let p = embassy_stm32::init( ... );
unsafe {
    embassy_stm32::pac::AFIO.mapr().modify(|w| {

        w.set_swj_cfg(0b0000_0010);
        w.set_spi1_remap(true);

    });

}

let spi = Spi::new( ...);`

Ay chance this be integrated into the embassy SPI configuration for STM32F1 code?

STM32F1 AFIO is not supported yet unfortunately. The F1's GPIO remapping works differently to all the other families, this is why it has seen less attention.
The first step would be to add the F1 pin remap info to https://github.com/embassy-rs/stm32-data, then once we have that embassy-stm32 could autogenerate the right traits etc for it to work automatically like in the other families.
If this is something you want to tackle, I can walk you through it.

Are there any examples for pin remapping in stm32-data on other STM32 MCU families?

no :( "remaps" don't exist in other families. In the other families, you can pick any combination of pins.
For example, on all families except F1 pin mapping works like this:

RX can be any of [PA5, PB4, PE11]
TX can be any of [PA6, PB5, PE12]

and on F1 it works like this

RX=PA5, TX=PA6 (not remapped)
RX=PB4, TX=PB5 (remapped)

but you can't mix and match: you can't set RX=PA5, TX=PB5.
There's currently no way to represent the F1 style in the stm32-data json files. We'd have to invent a way to represent it, then scrape the data in that format, then make embassy-stm32 able to read it and generate code from that.

That's unfortunate.
Maybe write something to the FAQs with the "hacky" but working workaround from above...?

Same issue with an stm32l151cb-a


Crash

Issue description:
The game crashed, when I tried to clear out my inventory.
What happens:
I've filled my inventory with stuff from my chicken farm, when I tried to put it into my RS system, the game crashed. Not sure if it was while I put it in, or when I tried to open the grid (crafting grid, not trying to craft anything).
What you expected to happen:
To clean up my inventory.
Steps to reproduce:
See "What happens".
Version (Make sure you are on the latest version before reporting):

Minecraft: 1.10.2
Forge: <IP_ADDRESS>4
Refined Storage: 1.2.22
Sky Factory 3: 3.0.7
InventoryTweaks: 1.61-58

Does this issue occur on a server? [yes/no]
No.
If a (crash)log is relevant for this issue, link it here:
https://gist.github.com/soerenkk/35dd922e012fcf6d60174c8e7f973f94

I don't think this crash still happens on 1.11+.


How to use it for auto generation of models?

Can I use this for generating robospice-retrofit network call request and response models? If so How?

no - not at this point... perhaps you can create a custom template for swagger-codegen that does this? You can export a Swagger definition for your API from SoapUI/Ready! API.


Change stubbing in the run time

Hey,
I am using standalone jar file and I want to change the mapped file contents as per the PUT request from the client.
Is there any option to do that on the fly ?

As per the readme please direct questions to the mailing list.


Provide example of CPU-limited sandboxing of lucet programs

I'm interested in using Lucet for a project, but I have security concerns with running user-provided code (of course). I think it would be very useful if you could provide a description of the sandboxing method you use for Terrarium, or even provide some example code that shows how you're sandboxing the user code so it can't consume the whole CPU.

Hi Bouke,
Unfortunately, this is not possible yet, at least not in a simple and safe way, but this is something being worked on.
In Terrarium, there is only a global timeout, enforced on the whole container.

We also think it is important to support CPU-limited sandboxing :) @tyler is working on #150 and we've got some napkin-sketch design ideas about how to instrument the generated code to enforce more granular timeouts. At the moment we're a bit stretched for resources and may not be able to solve this within the next few months, but if this is something you'd like to work on with us, we'd love to collaborate!

I see, good to hear it's on your radar! I have some vague ideas about projects I would like to use lucet for, but not really the time to contribute major features, sorry :smile:
Semi-related question: do you think lucet will be able to provide enough protection and limiting to be able to safely run user-provided programs next to each other in the same process, outside of another sandbox? Or will some kind of cgroups/seccomp sandbox around lucet always be required?

Lucet should be able to protect against some classes of attacks from using user-provided programs in that scenario, if the embedding correctly separates the two programs and does not permit them access to some shared resource through imported function. This is one of the goals of lucet-wasi, for instance - if each module is given their own subdirectory to read/write into the filesystem, they shouldn't be able to interfere with each other.
There's a pretty comprehensive rundown of what Lucet does and does not protect against here: https://github.com/fastly/lucet/blob/master/SECURITY.md but if you have any questions we are happy to answer them.

user-provided programs next to each other in the same process

shouldn't be able to interfere with each other

I assumed that even with speculative execution protection (eventually) implemented in cranelift that the general consensus was that isolating untrusted code within the same process was very challenging: https://v8.dev/blog/spectre#site-isolation
I am also working on a project with Lucet and have assumed that it's best to have a separate process for each user. It would be interesting to hear if in Fastly's efforts with Lucet it is planned to run multiple user's code in a single process, or if the best bet at this point is to split them up.


Api For Custom Search

Where i can find api for custom search in google.com/cse?

Assuming you either run composer install or download a release the methods for the Google Custom Search API will be in vendor/google/apiclient-services/src/Google/Service/Customsearch.php. But you shouldn't have to worry about that if you are including the autoloader file: include_once __DIR__ . '/../vendor/autoload.php';

Thank you very much

We have installed via composer and are using autoload but get this error:
PHP Fatal error:  Uncaught Error: Class 'Google_Service_Customsearch' not found in


This effectively is a NOOP change, continuing the process of generating release assets based on the Go 1.20 series.

NOTE: We intentionally roll back one patch release in order to verify that dependabot issues PRs (return images to the current patch release) associated with the oldstable image.


Added SaaS in DSPM

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

Before: https://main--prisma-cloud-docs--hlxsites.hlx.page/
After: https://--prisma-cloud-docs--hlxsites.hlx.page/
Worker: https://prisma-cloud-docs-production.adobeaem.workers.dev/?branch=

Topic updated for https://redlock.atlassian.net/browse/PCDTUS-110


Prep200

@Phil-Friderici only given it a cursory look - but looks good to me

moving on to https://github.com/Ericsson/puppet-module-cgroups/pull/10 to get it into upstream


Corrected types of page_info return

page_info has start_cursor and end_cursor which are currently marked in the docs as boolean type, but they're actually strings.

I was confused by the current documentation, as it was requesting me to pass the previously received end_cursor into the next fetch but it was declared as a boolean. I checked in the debugger and it's just mislabeled in the docs, so this PR fixes the docs.
Test Plan
This is a change to documentation only.

@blargity sorry i messed up the rebase. Can you rebase real quick and i will land it?

@chirag04, I wasn't able to undo the other changes except by manually going through the file, and creating a new PR from a freshly synced fork made more sense to me, so I've opened #16830. I'll close this one.


the divide mistake of  positive and negative samples

❓ Questions and Help
Please note that this issue tracker is not a help form and this issue will be closed.
We have a set of listed resources available on the website. Our primary means of support is our discussion forum:

Discussion Forum
When dividing positive and negative samples, the gt_boxes index that anchor matches to is 0 will be mistaken as negative samples
for matched_idxs_per_image in matched_idxs:

positive = torch.nonzero(matched_idxs_per_image >= 1).squeeze(1)

negative = torch.nonzero(matched_idxs_per_image == 0).squeeze(1)

Hi,
Thanks for raising this question, it's a good question indeed.
The input to BalancedPositiveNegativeSampler is not actually the indices of the GT, but the labels themselves (with 0 being the background label), see https://github.com/pytorch/vision/blob/5b61a5c8f89348b14a63deb95d5ee7aea9507051/torchvision/models/detection/roi_heads.py#L585-L586
As such, the code properly takes into account the GT values irrespective of its index.
I believe I've answered your question, and as such I'm closing this issue but let us know if you have further questions


Cann't open Clipy main menu

I set a new shortcut for history and hide the app both in dock and on menu. Now I want to change the column size of history but Clipy main menu just disappeard. I reinstalled it and nothing worked.
Or where can I find the configuration path I can delete all the config files and maybe the main menu would come back again.

Same here. Found this: https://github.com/Clipy/Clipy/issues/382, but author closed it without solutions.

After several times install and remove by home brew, it somehow appears again and I don’t know why actually, so I switched the icon on and never touch that switch again

After several content clear and reinstall, it did not work, but I guess at some point, I restarted my Mac, and Clipy reset itself, started to show the icon, as well as a "Preference" item in the main menu.

what worked for me:
13 22:30:18 Ψ brew cask rm clipy
==> Uninstalling Cask clipy
==> Quitting application 'com.clipy-app.Clipy'...
Application 'com.clipy-app.Clipy' quit successfully.
==> Backing App 'Clipy.app' up to '/usr/local/Caskroom/clipy/1.2.1/Clipy.app'.
==> Removing App '/Applications/Clipy.app'.
==> Purging files for version 1.2.1 of Cask clipy
13 22:30:25 Ψ rm -rf /usr/local/Caskroom/clipy
13 22:30:43 Ψ brew cask install clipy

Tried removing without removing the backup and I assume homebrew was just recovering from it.

I've tried brew cleanup and nothing changed so maybe cleanup command does not cleanup the "backup"
------------------ 原始邮件 ------------------
发件人: "Illia<EMAIL_ADDRESS>发送时间: 2020年1月14日(星期二) 中午11:37
收件人<EMAIL_ADDRESS>抄送<EMAIL_ADDRESS><EMAIL_ADDRESS>主题: Re: [Clipy/Clipy] Cann't open Clipy main menu (#386)
what worked for me:
13 22:30:18 Ψ brew cask rm clipy ==> Uninstalling Cask clipy ==> Quitting application 'com.clipy-app.Clipy'... Application 'com.clipy-app.Clipy' quit successfully. ==> Backing App 'Clipy.app' up to '/usr/local/Caskroom/clipy/1.2.1/Clipy.app'. ==> Removing App '/Applications/Clipy.app'. ==> Purging files for version 1.2.1 of Cask clipy 13 22:30:25 Ψ rm -rf /usr/local/Caskroom/clipy 13 22:30:43 Ψ brew cask install clipy
Tried removing without removing the backup and I assume homebrew was just recovering from it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

@lovelock "backup" as of:

==> Backing App 'Clipy.app' up to '/usr/local/Caskroom/clipy/1.2.1/Clipy.app'.

Yeah I noticed that, thanks
------------------ 原始邮件 ------------------
发件人: "Illia<EMAIL_ADDRESS>发送时间: 2020年1月14日(星期二) 中午11:53
收件人<EMAIL_ADDRESS>抄送<EMAIL_ADDRESS><EMAIL_ADDRESS>主题: Re: [Clipy/Clipy] Cann't open Clipy main menu (#386)
@lovelock "backup" as of:
==> Backing App 'Clipy.app' up to '/usr/local/Caskroom/clipy/1.2.1/Clipy.app'.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

For anyone else running into this where you didn't install via homebrew:
I was able to get the default preferences restored by deleting the file ~/Library/Preferences/com.clipy-app.Clipy.plist

For anyone else running into this where you didn't install via homebrew:
I was able to get the default preferences restored by deleting the file ~/Library/Preferences/com.clipy-app.Clipy.plist

@lsirivong  this isn't even working for me -_-
Anyone know what else I have to nuke to get clipy back? I've lost my snippets hotkey and the ability to get to Preferences -_-

@lovelock Sorry for the late reply.
You can return to the initial settings by resetting the settings as in #226 #412 and then restarting.


any plans for react-native?

any working example for react-native

We don't have plans to release a react-native SDK at this time.
There is an open-source react-native package here: https://github.com/CatalystCode/react-native-azurenotificationhub, which I've used to build a simple test app. It works well and is simple to integrate.


Added TS definition draft

This is just a draft I made using dts-gen and some manual work. I needed it for my project because I prefer to enable the noImplicitAny option in my projects. I hope you'll publish it as @types/humanize-duration so I can add it as a project dependency instead of manually including it in my project.

I'm not sure but I suspect you need to submit this to the DefinitelyTyped repo. There's a contribution guide on how to do this here: http://definitelytyped.org/guides/contributing.html
I can try to help out with this, but it really depends on how much spare time I have :P
I'm not too familiar with testing the type declarations, but I'm currently reading up on it.
Here's a simple test example for the moment-timezone library declaration file: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/79f2e4fa0e657342e5361f4a0fab1044fa2168c8/moment-timezone/moment-timezone-tests.ts

I'm more than comfortable letting you own the semi-official Humanize
Duration Typescript declaration. Is that something you would be able to
take on at some point?

@EvanHahn Sure. I'll try to add the necessary tests as soon as I can, along with all the stuff required by the DefinitelyTyped repo.

Given that this will go to DefinitelyTyped, I'm going to close this.

Added TypeScript type definitions to DefinitelyTyped under @types/humanize-duration.


AfterMapping is not being called after ProjectToType

Hello,
i'm stuck with the AfterMapping fuction right now.
The given Action will be called when i use the Adapt method,
but not after ProjectToType Extension method.
Is that a bug or works as designed?
TypeAdapterConfig<Person, PersonDto>.NewConfig()
.AfterMapping((src, dest) => dest.Name += "xxx");
// AfterMapping Action will be called.
IList allPersons =
context.Person
.Adapt<List>(Mapper.Config);
// AfterMapping Action will not be called.
IList allPersons =
context.Person
.ProjectToType(Mapper.Config)
.ToList();
Regards
Sergey

Sorry AfterMapping cannot use with ProjectToType. When using queryable, expression must be single expression in order to convert to sql statement.
You can check method that support queryable here https://github.com/MapsterMapper/Mapster/wiki.


Impossible to delete state

https://github.com/keboola/storage-api-php-client/blob/master/src/Keboola/StorageApi/Components.php#L60
if state is empty, it will not be set at all.

note: empty state is empty array and null ?

Fixed by https://github.com/keboola/storage-api-php-client/pull/135


Create next version of .dsg with metadata on point interpretation

[ ] Increment .dsg version number
[ ] Add 'timestamp_position' as an attribute of TimeEnumeration. Choices are 'period_beginning', 'period_midpoint', 'period_ending'. Old Datafiles should default this to 'period_ending'.
[ ] Add 'point_interpretation' as data of FuelEnumeration and as an attribute of SingleFuelEndUseEnumeration. Choices are 'instantaneous', 'average', 'integrated'. Old Datafiles should default to 'integrated'.

Out-of-date given new dsgrid data format (which does include this feature).


Ability use different consume and produce types for the key and value

I don't think it's possible to use ParallelStreamProcessor with Consumer and Producer that do not share the same KeyType and ValueType.
Can this be considered in the future ?

Hi,
i see that you remove the blocker label.
Do you think the 1.0 version won't break after the implementation of the fix ?

i see that you remove the blocker label.

Whoops - mistake :) Still plan on changing this. Will be resuming work on PC this week :)

Closing Issue


the room directories should be saved if they were successfully reached

Steps to reproduce
-> go to the room directories activity
-> taps on (+) to add a new rooms directory (valid one)
-> the activity is closed
-> open the room directories activity again
the entered rooms directory was not saved

closed in favour of https://github.com/vector-im/riot-meta/issues/87


conflicting requirements on jmespath between botocore and boto3

While installing boto3 via pip on a fresh centos7 box today, I noticed the following incompatible requirements:
$ sudo pip install -U botocore
Collecting jmespath==0.7.1 (from botocore)
  Using cached jmespath-0.7.1-py2.py3-none-any.whl

$ sudo pip install -U boto3
Collecting jmespath<1.0.0,>=0.6.2 (from boto3)
  Using cached jmespath-0.8.0-py2.py3-none-any.whl

Installing boto3 alone will install jmespath-0.8.0 which is incompatible with botocore. But botocore and boto3 seem to work fine with jmespath-0.7.1.

Thanks for reporting. This was reported in https://github.com/boto/botocore/issues/656. We fixed this yesterday with these PRs https://github.com/boto/botocore/pull/658 and https://github.com/boto/boto3/pull/272. Will be available in the next release of botocore and boto3. Closing issue.


Aszlam/memory updates

Description
Please include a summary of the change and link to an issue this PR fixes. Please also include relevant context. List any downstream components that might be affected by this change.
Fixes # (issue)
Type of change
Please check the options that are relevant.

[x] Bug fix (non-breaking change that fixes an issue)
[ ] Proposes a change (non-breaking change that isn't necessarily a bug)
[x] New feature (non-breaking change that adds a new functionality)
[ ] Breaking change (fix or feature that would break some existing functionality downstream)
[ ] This is a unit test
[ ] Documentation only change

Type of requested review

[x] I want a thorough review of the implementation.
[ ] I want a high level review.
[ ] I want a deep design review.

Before and After
This PR fixes a longstanding bug where updates to certain memories did not change the updated_time in the main Memories table.  Also some memory types (in particular Triples) were not tracked by the main Memories table-  as of this PR they all should be.  Finally, to support these changes, a db_write() method wrapping ._db_write() is implemented, and several raw SQL deletes are removed from code.
Testing
A basic memory test is added in base agent
Checklist:

[ ] I have performed manual end-to-end testing of the feature in my environment.
[x] I have added Docstrings and comments to the code.
[x] I have made changes to existing documentation where needed.
[x] I have added tests that show that the PR is functional.
[x] New and existing unit tests pass locally with my changes.
[x] I have added relevant collaborators to review the PR before merge.

For low_level_memory_test.py(and more files to come). This should be set up as unittest and added to CI.
In order to do so, we should add __init__.py under test/ and have a test.sh file

For low_level_memory_test.py(and more files to come). This should be set up as unittest and added to CI.
In order to do so, we should add __init__.py under test/ and have a test.sh file

A bit unrelated: since we are replacing _db_write with db_write, we should do the same for all _* functions which are being used as public fn.

A bit unrelated: since we are replacing _db_write with db_write, we should do the same for all _* functions which are being used as public fn.

I'll setup base_agent test in another PR.

I'll setup base_agent test in another PR.


Update ui-components to 1.2.0

Ah, sorry, bad script for master :D just a sec..

(Replaced by https://github.com/ManageIQ/manageiq-ui-service/pull/1494)


Let rustfmt take care of wrapping comments

It turns out rustfmt can ensure a consistent comment length by applying automatic wrapping. Let's enable the functionality to get some more consistency into the code base and ensure that pull requests adhere to a basic standard in the process.

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 77.63%. Comparing base (b7f9388) to head (966ad78).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main       #5   +/-   ##
=======================================
  Coverage   77.63%   77.63%
=======================================
  Files           3        3
  Lines         228      228
=======================================
  Hits          177      177
  Misses         51       51

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


refactor: support IE11 in the examples

Please check if the PR fulfills these requirements

[ ] It's the right issue type on the title
[ ] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
[ ] The commit message follows our guidelines
[ ] Tests for the changes have been added (for bug fixes/features)
[ ] Docs have been added/updated (for bug fixes/features)
[ ] It does not introduce a breaking change or has a description of the breaking change

Description

Use a minified IE11 bundle file in the examples.
Use different CDN for the chance library to support IE11.

Thank you for your contribution to TOAST UI product. 🎉 😘 ✨

기왕 바꾸는김에 moment CDN도 CloudFlare 것으로 바꿀게요


chore(C): add radix sort

PR Checklist:

[x] My submission is formatted according to the guidelines in the contributing guide
[x] My addition is on refer on the language README.md file
[x] My addition does not have a spelling problem
[x] My submission has a proper and user-friendly description of the algorithm
[x] My submission has the time complexity of the algorithm
[x] My submission has sample input-output of the program (NOT FOR PYTHON)

What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[x] New algorithm
[ ] Optimization in previous algorithms
[ ] Code style update
[ ] Refactor
[ ] Documentation
[ ] Other, please describe:

Briefly describe the changes in this PR

Add radix sort algorithm in C language
The online resource
Other information:

Nice, now all that is left is to updating the C Readme.md file and the PR should be good to go.

Nice, now all that is left is to updating the C Readme.md file and the PR should be good to go.

Updated.
@Arsenic-ATG


Debugging test regression after 0.10.7

Describe the bug
Between 0.10.7..0.12.0 process.chdir() was removed, which causes vitest start problem if you're use vscode workspace folder != folder there vites.config.ts present. (vitest failed with exitcode 1)
Reproduction

Output
--

Version
0.12.4
Validations

[X] Check that you are using the latest version of the extension
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

Can you not assume when the bug is, but rather describe the issue itself. process.chdir is removed because child_process is initiated with correct cwd now and has nothing to do with debugger.

Debugger config wasn't using project CWD: https://github.com/vitest-dev/vscode/commit/3bfe794850cf4c9f7e3d571f00d5f4d052cb55ca

@sheremet-va thanks for fast fix


Add IoPathSaver and unify the mode for Saver

Fixes #91
Stack from ghstack:

#105 Add IoPathSaver and unify the mode for Saver
#104 Refactor IoPath FileLister and FileLoader

Differential Revision: D32317606

@ejguan has imported this pull request.  If you are a Facebook employee, you can view this diff on Phabricator.

This is also BC-breaking change. But, no need to let domains to change their code because Saver is not used by them directly. The on_disk_cache is the main consumer of Saver and it would explicitly add mode to Saver

@ejguan has imported this pull request.  If you are a Facebook employee, you can view this diff on Phabricator.

@ejguan has imported this pull request.  If you are a Facebook employee, you can view this diff on Phabricator.


Create the Category screen

Point to include:

there is only list of articles

Notes:

the article list component will be the same as in the home screen

:tada: This issue has been resolved in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


option to install/remove

Hello,great work
Is it possible to add to the script option/s to install/remove Quake 2 port / Goonies 20th anniversary etc.?
i know they are pre-installed, just in case to remove them and install them again after.
Thanks

original RetroPie ports can be removed/installed using the RetroPie-Setup (some may not work after reinstalled, needs some test). Easy alternative is to remove the whole ports folder from ~/RetroPie/roms if you dont want the Ports section showing on EmulationStation. For the time being, you can also move/remove specific files somewhere else and move them back when you want.


Add varN for ErrorPropagator

Added varN(ep::ErrorPropagator, gradient::Function, lvl = _reliable_level(ep)) function to the ErrorPropagator interface, in analogy to the existing function varN(ep::ErrorPropagator, i::Integer, lvl::Integer = _reliable_level(ep)).
Similar function pairs exist already for var(), mean(), and std_error().
Comes in handy if the error propagation is unstable / badly converged and the variance turns out negative, breaking straightforward access to std_error()=sqrt(varN()) for real numbers.

Thanks!


bugfixadd prefix for endpoint with s3 client

Proposed changes
add prefix for endpoint with s3 client.

run buildall

run p0

run cloudp0

run cloud_p0


Add a license

Can you add a license to this project? https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-license-to-a-repository
Thank you!

Done!


fix typos and casing in KNOWNISSUES.md

Fix typos and casing.
"on Linux PowerShell" change to "in PowerShell on Linux".
Apply "one-sentence-per-line" rule.

Oh that's what you meant. I thought you were trying to point out a "Linujx" typo.


Change the way Certificate of freesale can be legalised

BIS have informed us that these certificates are no longer signed but must bear the “Signature Valid” text along with a “Tick” on the certificate.
Rules have changed for this document only, so I had to create a new "group" for it. Not sure it's the least confusing way of making this change.

This has now been fact-checked and is ready for review.

LGTM :+1:


day 2 error

Hello,
I am trying to figure out what went wrong with my code for the day 2 challenge. I am pretty sure the result is correct.
Which for challenge one is 2017. 07.08 and 505 days for challenge 2.
Challenge :

We kicked off our 100 Days of Code project on March 30th, 2017. Calculate what date we finished the full 100 days!
PyBites was founded on the 19th of December 2016. We're attending our first PyCon together on May 8th, 2018. Can you calculate how many days from PyBites' inception to our first PyCon meet up?

My code :
from datetime import date, timedelta
start_100days = date(2017, 3, 30)
pybites_founded = date(2016, 12, 19)
pycon_date = date(2018, 5, 8)
def get_hundred_days_end_date():
"""Return a string of yyyy-mm-dd"""
end_date=timedelta(days=100)
finish_day = start_100days + end_date
print(str(finish_day))

def get_days_between_pb_start_first_joint_pycon():
"""Return the int number of days"""
in_between_days = pycon_date - pybites_founded
print(str(in_between_days))
get_hundred_days_end_date()
get_days_between_pb_start_first_joint_pycon()
error return :
============================= test session starts ==============================
platform linux -- Python 3.8.13, pytest-5.4.2, py-1.8.1, pluggy-0.13.1
rootdir: /tmp
plugins: asyncio-0.12.0
2017-07-08
505 days, 0:00:00
collected 2 items
../../tmp/test_calc_dts.py 2017-07-08
F505 days, 0:00:00
F
=================================== FAILURES ===================================
________________________ test_get_hundred_days_end_date ________________________
def test_get_hundred_days_end_date():

  assert get_hundred_days_end_date() == '2017-07-08'

E       AssertionError: assert None == '2017-07-08'
E        +  where None = get_hundred_days_end_date()
/tmp/test_calc_dts.py:6: AssertionError
_______________________ test_get_days_till_pycon_meetup ________________________
def test_get_days_till_pycon_meetup():

  assert get_days_between_pb_start_first_joint_pycon() == 505

E       assert None == 505
E        +  where None = get_days_between_pb_start_first_joint_pycon()
/tmp/test_calc_dts.py:10: AssertionError
=========================== short test summary info ============================
FAILED ../../tmp/test_calc_dts.py::test_get_hundred_days_end_date - Assertion...
FAILED ../../tmp/test_calc_dts.py::test_get_days_till_pycon_meetup - assert N...
============================== 2 failed in 0.07s ===============================

您好，您的邮件我已经收到，会尽快阅读并回复！
                                                                               zzWu

Hey @onethirtyseven I quickly checked and this is not an exercise bug, it's a failing submission.
where None = get_hundred_days_end_date() means you are not returning anything from the function.
Change your prints to returns and that fixes that issue.
There is another problem to fix (you're close!), it has to do with the return type of get_days_between_pb_start_first_joint_pycon() - you have str, but as per the test it needs to be int(hint: you can calldayson atimedelta` object ...)
HTH
Bob


Something might be broken

Hey looks like something might have broken in a new push ... getting two errors that I wasnt getting before.

---> Something was wrong trying to sign the app. Press Enter to continue
---> ERROR: Can't find file {dirpath}...Main.smali

Hi @securisec,
Could you try to use my master branch of my fork ?
My repo doesn't the last PR #4.
I am trying to fix your problem in another branch.


Consider moving away from jest-playwright-preset in favor of Playwright's builtin runner

Playwright is a library that allows interacting with a webpage through a headless browser. Jest is a test runner. jest-playwright-preset is a library that makes it possible to use the Jest test runner and interact with the browser using Playwright.
The jest-playwright-preset docs now suggest using Playwright's builtin test runner (https://www.npmjs.com/package/jest-playwright-preset), which presumably was recently built.
As part of https://github.com/civiform/civiform/issues/3302, we ran into issues where Jest 29 was updated, but jest-playwright-preset wasn't compatible with it immediately. It's unclear whether this will be resolved at some point. Either way, carrying this forward will always be a source of potential time sink. Given the warning on the jest-playwright-preset, it might make sense to try and use Playwright's native library instead.
I'll fill out a pointers as to what this migration might look like in future comments.

One thing I don't fully understand yet is what exactly jest-playwright-preset does. Reading our code - we write regular jest tests, using describe/it/expect/etc. We create new instances of browser manually using chromium.launch() using playwright API directly.  For example we are not using their helper functions like these: https://github.com/playwright-community/jest-playwright#reset-helper-functions
So I'm curious what will happen if we just remove jest-playwright-preset. What will break, if anything?

One thing I don't fully understand yet is what exactly jest-playwright-preset does. Reading our code - we write regular jest tests, using describe/it/expect/etc. We create new instances of browser manually using chromium.launch() using playwright API directly. For example we are not using their helper functions like these: https://github.com/playwright-community/jest-playwright#reset-helper-functions
So I'm curious what will happen if we just remove jest-playwright-preset. What will break, if anything?

Agreed. I removed jest-playwright-preset, rebuilt the browser env, and address.test.ts still continued to pass. That said, I have no idea if there's something subtle about the underlying library that we were relying on or depending on. Here's the custom runner that's used when the preset is enabled: https://github.com/playwright-community/jest-playwright/blob/main/src/PlaywrightRunner.ts.
I don't feel confident to say if anything will break or what the behavior change will be :/.

One thing I don't fully understand yet is what exactly jest-playwright-preset does. Reading our code - we write regular jest tests, using describe/it/expect/etc. We create new instances of browser manually using chromium.launch() using playwright API directly. For example we are not using their helper functions like these: https://github.com/playwright-community/jest-playwright#reset-helper-functions
So I'm curious what will happen if we just remove jest-playwright-preset. What will break, if anything?

Agreed. I removed jest-playwright-preset, rebuilt the browser env, and address.test.ts still continued to pass. That said, I have no idea if there's something subtle about the underlying library that we were relying on or depending on. Here's the custom runner that's used when the preset is enabled: https://github.com/playwright-community/jest-playwright/blob/main/src/PlaywrightRunner.ts.
I don't feel confident to say if anything will break or what the behavior change will be :/.

I did an experiment for the jest-monorepo upgrade: https://github.com/civiform/civiform/pull/3518.
In this PR, we:

Remove jest-playwright-preset entirely
Update the Jest monorepo with the same changes as #3302. There's still a warning about image snapshot being incompatible. That said, the tests currently pass, so we don't necessarily have to wait.

Given this, it might make sense to remove our dependency on jest-playwright-preset. Thanks to @nbeloglazov for pushing on this. I'm going to do a bit more scanning of the jest-playwright-preset codebase (code) to see if there's anything subtle I can see that we might be losing out on.

Things provided by the preset:

Hooks for setting up a development server and tearing it down as part of tests. We spawn our dev server using bin/run-browser-test-env presumably due to it running in a distinct container - I don't think this is useful (code).
Supporting a distinct config for how browsers are launched (docs). We in fact have a jest-playwright-config.js file (code) which specifies some options. That said, since we don't use any of the playwright context hooks (code), this is effectively ignored. I think this file can be removed to reduce confusion. It's entirely an unnecessary browser process is started as part of Playwright's setup (code). However, our call to chromium.launch would bypass all of this infrastructure.
The preset supports reading a list of browsers / devices from the configuration and generating distinct test targets for each combination (code). We only test in Chromium and don't make use of this feature
Overriding the test timeout from the Playwright default (code). We already do this as part of invoking the Jest process (code).
Looks like the jest-playwright-preset ends up including the ts-jest preset to add TypeScript support (code). We can replace our preset entry with this.

I'll update my PR to 1) remove jest-playwright-config.js since it's unused and 2) Update our preset to ts-jest.
If that all passes cleanly, I'll send the PR out for review without the Jest monorepo update. Once that's submitted, we can resync the RenovateBot PR and proceed.

Test run was successful: https://github.com/civiform/civiform/actions/runs/3137537237/jobs/5095817477.
I'll send out a PR with those changes sans the Jest monorepo update.

I can see needing to have 2 variations of screenshots, one for desktop and one for mobile. In which case jest-playwright-preset might have simplified things a little. But we might come up with our own enhancements to support that use case. Other than that I don't think we'd use their features.


[release-1.12] mcs test: backoff more aggresively

This is an automated cherry-pick of #35852

@howardjohn this will need your consent

@istio-testing: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

integ-pilot-multicluster-tests_istio_release-1.12
356f7db46d7f37705585c065feb220f1cbe21e7f
link
unknown
/test integ-pilot-multicluster-tests_istio_release-1.12

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest


Create LICENSE

Hi, Wenqi.
I have tried to reproduce your results with the implementation provided by you hosted on Dropbox. However, it executes too slow even using GPU and performs worse than the results claimed in the paper. So may you share the whole process to reproduce your experiments? Like how do you split the training and test set and hyper-parameters used? And BTW, where should I download datasets mentioned in your paper?

Why don't you publish the data processing code？

I think you should review your code, it is too slow, and your code have a very serious memory leak problem.

I think you should review your code, it is too slow, and your code have a very serious memory leak problem.

Based on my communication with the author through emails,

He said that his code is based on GraphSage-PyTorch and very straightforward, although time-consuming.
He also mentioned that there will be one simple version of GraphRec which is less time-consuming and flexible. And he will release it if possible.

The above points are all from the author himself, just for reference.

I think you should review your code, it is too slow, and your code have a very serious memory leak problem.

Based on my communication with the author through emails,

He said that his code is based on GraphSage-PyTorch and very straightforward, although time-consuming.
He also mentioned that there will be one simple version of GraphRec which is less time-consuming and flexible. And he will release it if possible.

The above points are all from the author himself, just for reference.

I think you should review your code, it is too slow, and your code have a very serious memory leak problem.

Based on my communication with the author through emails,

He said that his code is based on GraphSage-PyTorch and very straightforward, although time-consuming.
He also mentioned that there will be one simple version of GraphRec which is less time-consuming and flexible. And he will release it if possible.

The above points are all from the author himself, just for reference.

I also see another pytorch implement and I run that pyrotch version and got much worse results compared with the claimed results in the paper. So I wonder what about your results? Can you share with me your results?

@golsutsg I also see another pytorch implement and I run that pyrotch version and got much worse results compared with the claimed results in the paper. So I wonder what about your results? Can you share with me your results?

What exactly does the data represent?

I think you should review your code, it is too slow, and your code have a very serious memory leak problem.

Based on my communication with the author through emails,

He said that his code is based on GraphSage-PyTorch and very straightforward, although time-consuming.
He also mentioned that there will be one simple version of GraphRec which is less time-consuming and flexible. And he will release it if possible.

The above points are all from the author himself, just for reference.

Hello, have you reached the code of the paper?
Now I have been unable to reach the result of the paper, which is 0.04 less

@golsutsg Can you share the data processing code?Thank you!

I think you should review your code, it is too slow, and your code have a very serious memory leak problem.

Based on my communication with the author through emails,

He said that his code is based on GraphSage-PyTorch and very straightforward, although time-consuming.
He also mentioned that there will be one simple version of GraphRec which is less time-consuming and flexible. And he will release it if possible.

The above points are all from the author himself, just for reference.

Hello, have you reached the code of the paper?
Now I have been unable to reach the result of the paper, which is 0.04 less

Can you share the data processing code?Thank you!

I think you should review your code, it is too slow, and your code have a very serious memory leak problem.

Based on my communication with the author through emails,

He said that his code is based on GraphSage-PyTorch and very straightforward, although time-consuming.
He also mentioned that there will be one simple version of GraphRec which is less time-consuming and flexible. And he will release it if possible.

The above points are all from the author himself, just for reference.

Hello, have you reached the code of the paper?
Now I have been unable to reach the result of the paper, which is 0.04 less

Can you share the data processing code?Thank you!

This work is sick, you don't need to follow it.

I think you should review your code, it is too slow, and your code have a very serious memory leak problem.

Based on my communication with the author through emails,

He said that his code is based on GraphSage-PyTorch and very straightforward, although time-consuming.
He also mentioned that there will be one simple version of GraphRec which is less time-consuming and flexible. And he will release it if possible.

The above points are all from the author himself, just for reference.

Hello, have you reached the code of the paper?
Now I have been unable to reach the result of the paper, which is 0.04 less

Would you kindly share your data processing code? I used the modified version of data processing code published in the other pull request but it will cause key error when I run the GraphRec with the social relation part.


Does v4.0 work?

I ran version 3.x.x for a while, since launch and since upgrading to version 4, that data coming in is all over the place. Any  suggestions please?

v4 is a development version that is still being worked on.

Thanks for the reply.  When I tried to go to version 3.x.x.  I just got version 4 again.   What did I miss?  Thanks again.

There have been some adjustments with which version can be found on which branch and the current group of users have a slightly different yaml code, so that updating is based on the default branch in this repository (which is now  the dev branch).

Ah.. I missed that.  I think I understand.  Thank you for your prompt replies and for a great project.

I tried downloading the yaml from the main branch and the 3.1.1 branch and install and no matter what I do, I end up on version 4.0.0

Change the package url to: github://klaasnicolaas/home-assistant-glow/home_assistant_glow.yaml@main

oh, doh! Thanks

And there are more things that I actually want to release in the main branch from developtment, but I run into quite a few problems getting the CI/CD properly done with the release drafter and the way updates work in ESPHome. Any help for that is welcome.

Still no joy. https://www.youtube.com/watch?v=6rp4n62YjxA

And there are more things that I actually want to release in the main branch from developtment, but I run into quite a few problems getting the CI/CD properly done with the release drafter and the way updates work in ESPHome. Any help for that is welcome.

I will have a poke around, I have very little knowledge of GitHub Actions and EPSHome but see if I can help.

Hmm, I guess there is no fix for it then... I will keep on poking, will post here if I find a solution.

I've also installed version 4.0 and can't get i to work. Shows way too big numbers, even when the pulse setting is right. Is there a way to install previous version (manually)? Or some other help is welcome..

You can only downgrade using the yaml file from the main branch

I have tried this so many times.. never works any more :-( So confused.

Wouldn't really know, would have expected that adding @main would ensure that only the main branch is looked at 🤔 Could also just be a bug from ESPHome 🤷🏻♂

I'm just trying again with a brand new ESP32 device, I have uninstalled EP32Home and reinstalled it.

Will also grab an ESP32 and do some testing

https://youtu.be/6rp4n62YjxA?t=80
Here I chose "Plug in to this computer" and after flashing I am running version 3.1.0

There have been some adjustments with which version can be found on which branch and the current group of users have a slightly different yaml code, so that updating is based on the default branch in this repository (which is now the dev branch).

Seems like having dev as the default branch leads to that if one downloads the yaml file manually from github (for initial install), one ends up downloading the 4.0.0 version. Is that on purpose?
I'm not quite sure I understood your comment above, but I'm guessing that has to do with how updating from ESPhome is supposed to work.

It's the friction between how ESPHome handles updates when using dashboard_import, setting up a good git flow in this project for stables versions, doing development at the same time and making releases.
At some point, this branch split was chosen because otherwise people would already get breaking changes (such as a default pin switch), while this was something for v4.0 and not for the existing v3.x.

OK, I'm going to spend some time understanding  more about how ESPHome works with my own test project and see if I can get this figured out... no idea how long it will take

Thx @klaasnicolaas .
Just to ensure I got this right and also chose the correct GPIO pin (may help others wondering):
-For those who want to use a stable version now, choose 'main' -> use 3.1.0 -> use pulse_pin: GPIO12
-For those looking to test, choose 'dev' -> use 4.0.0 -> use pulse_pin: GPIO13
Did I get that right?