Add support for WASM target

Before reporting an issue please first check the
troubleshooting guide. If
the issue you're encountering is not solved thereby please state the following in your bugreport:

Operating system
5.6.10-arch1-1 GNU/Linux
The way you installed OpenCV: package, official binary distribution, manual compilation, etc.
via "packer" manager
OpenCV version
4.3.0
Attach the full output of the following command from your project directory:RUST_BACKTRACE=full cargo build -vv

Version
rustc 1.43.0 (4fb7144ed 2020-04-20)
Target
wasm32-unknown-unknown
CLI
cargo +stable build --release --target=wasm32-unknown-unknown
   Compiling num-traits v0.2.11
   Compiling opencv v0.34.0
error: failed to run custom build command for `opencv v0.34.0`

Caused by:
  process didn't exit successfully: `/home/horky/Documents/WorkspaceRust/cvwasm/target/release/build/opencv-e2dc348207d786b2/build-script-build` (exit code: 1)
--- stderr
=== Environment configuration:
===   OPENCV_HEADER_DIR = None
===   OPENCV_PACKAGE_NAME = None
===   OPENCV_PKGCONFIG_NAME = None
===   OPENCV_LINK_LIBS = None
===   OPENCV_LINK_PATHS = None
===   OPENCV_INCLUDE_PATHS = None
===   PKG_CONFIG_PATH = None
===   VCPKG_ROOT = None
=== Setting up OpenCV library from pkg_config
Error: "Package opencv4 is not found, caused by: Cross compilation detected. Use PKG_CONFIG_ALLOW_CROSS=1 to override"

warning: build failed, waiting for other jobs to finish...
error: build failed

I didn't succeed to find a way of working OpenCV (rust+wasm) example on internet, is there a way to build it properly?
PS. Trivia I would like to rewrite my simple app from C++ intro rust

Not that I have tested it in any way, but did you try doing what it suggested?
Use PKG_CONFIG_ALLOW_CROSS=1 to override

Yes, I have but unsuccessfully. ( I also posted in the user group, in January)
log dump
   Compiling num v0.2.1
   Compiling opencv v0.34.0
error: failed to run custom build command for `opencv v0.34.0`

Caused by:
  process didn't exit successfully: `/home/horky/Documents/WorkspaceRust/cvwasm/target/release/build/opencv-e2dc348207d786b2/build-script-build` (exit code: 1)
--- stdout
cargo:rerun-if-env-changed=OPENCV_HEADER_DIR
cargo:rerun-if-env-changed=OPENCV_PACKAGE_NAME
cargo:rerun-if-env-changed=OPENCV_PKGCONFIG_NAME
cargo:rerun-if-env-changed=OPENCV_LINK_LIBS
cargo:rerun-if-env-changed=OPENCV_LINK_PATHS
cargo:rerun-if-env-changed=OPENCV_INCLUDE_PATHS
cargo:rerun-if-env-changed=PKG_CONFIG_PATH
cargo:rerun-if-env-changed=VCPKG_ROOT
cargo:rerun-if-changed=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/common.hpp
cargo:rerun-if-changed=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/dnn.hpp
cargo:rerun-if-changed=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/videoio.hpp
cargo:rerun-if-changed=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/core.hpp
cargo:rerun-if-changed=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/manual-dnn.cpp
cargo:rerun-if-changed=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/face.hpp
cargo:rerun-if-changed=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/manual-core.cpp
cargo:rerun-if-changed=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/aruco.hpp
cargo:rerun-if-changed=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/ocvrs_resolve_types.hpp
cargo:rerun-if-changed=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/manual-features2d.cpp
cargo:rerun-if-changed=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/hdf.hpp
cargo:rerun-if-changed=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/calib3d.hpp
cargo:rerun-if-changed=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/ccalib.hpp
cargo:rerun-if-changed=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/bioinspired.hpp
cargo:rerun-if-changed=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/sfm.hpp
cargo:rerun-if-changed=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/imgproc.hpp
TARGET = Some("wasm32-unknown-unknown")
OPT_LEVEL = Some("3")
HOST = Some("x86_64-unknown-linux-gnu")
CXX_wasm32-unknown-unknown = None
CXX_wasm32_unknown_unknown = None
TARGET_CXX = None
CXX = None
CXXFLAGS_wasm32-unknown-unknown = None
CXXFLAGS_wasm32_unknown_unknown = None
TARGET_CXXFLAGS = None
CXXFLAGS = None
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("false")
CXX_wasm32-unknown-unknown = None
CXX_wasm32_unknown_unknown = None
TARGET_CXX = None
CXX = None
CXXFLAGS_wasm32-unknown-unknown = None
CXXFLAGS_wasm32_unknown_unknown = None
TARGET_CXXFLAGS = None
CXXFLAGS = None
CRATE_CC_NO_DEFAULTS = None
CXX_wasm32-unknown-unknown = None
CXX_wasm32_unknown_unknown = None
TARGET_CXX = None
CXX = None
CXXFLAGS_wasm32-unknown-unknown = None
CXXFLAGS_wasm32_unknown_unknown = None
TARGET_CXXFLAGS = None
CXXFLAGS = None
CRATE_CC_NO_DEFAULTS = None
CXX_wasm32-unknown-unknown = None
CXX_wasm32_unknown_unknown = None
TARGET_CXX = None
CXX = None
CXXFLAGS_wasm32-unknown-unknown = None
CXXFLAGS_wasm32_unknown_unknown = None
TARGET_CXXFLAGS = None
CXXFLAGS = None
CRATE_CC_NO_DEFAULTS = None
CXX_wasm32-unknown-unknown = None
CXX_wasm32_unknown_unknown = None
TARGET_CXX = None
CXX = None
CXXFLAGS_wasm32-unknown-unknown = None
CXXFLAGS_wasm32_unknown_unknown = None
TARGET_CXXFLAGS = None
CXXFLAGS = None
CRATE_CC_NO_DEFAULTS = None
CXX_wasm32-unknown-unknown = None
CXX_wasm32_unknown_unknown = None
TARGET_CXX = None
CXX = None
CXXFLAGS_wasm32-unknown-unknown = None
CXXFLAGS_wasm32_unknown_unknown = None
TARGET_CXXFLAGS = None
CXXFLAGS = None
CRATE_CC_NO_DEFAULTS = None
running: "sccache" "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-unknown-unknown" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4" "-I" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out" "-I" "." "-Wall" "-Wextra" "-std=c++11" "-o" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/aruco.o" "-c" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/aruco.cpp"
running: "sccache" "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-unknown-unknown" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4" "-I" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out" "-I" "." "-Wall" "-Wextra" "-std=c++11" "-o" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/calib3d.o" "-c" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/calib3d.cpp"
running: "sccache" "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-unknown-unknown" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4" "-I" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out" "-I" "." "-Wall" "-Wextra" "-std=c++11" "-o" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/core.o" "-c" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/core.cpp"
running: "sccache" "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-unknown-unknown" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4" "-I" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out" "-I" "." "-Wall" "-Wextra" "-std=c++11" "-o" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/ccalib.o" "-c" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/ccalib.cpp"
running: "sccache" "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-unknown-unknown" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4" "-I" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out" "-I" "." "-Wall" "-Wextra" "-std=c++11" "-o" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/alphamat.o" "-c" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/alphamat.cpp"
running: "sccache" "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-unknown-unknown" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4" "-I" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out" "-I" "." "-Wall" "-Wextra" "-std=c++11" "-o" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/bgsegm.o" "-c" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/bgsegm.cpp"
running: "sccache" "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-unknown-unknown" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4" "-I" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out" "-I" "." "-Wall" "-Wextra" "-std=c++11" "-o" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/bioinspired.o" "-c" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/bioinspired.cpp"
running: "sccache" "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-unknown-unknown" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4" "-I" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out" "-I" "." "-Wall" "-Wextra" "-std=c++11" "-o" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/manual-core.o" "-c" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/manual-core.cpp"
cargo:warning=In file included from /home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/aruco.cpp:1:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/aruco.hpp:1:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/common.hpp:2:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4/opencv2/core.hpp:52:
cargo:warning=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4/opencv2/core/cvdef.h:171:10: fatal error: 'limits' file not found
cargo:warning=#include <limits>
cargo:warning=         ^~~~~~~~
cargo:warning=1 error generated.
exit code: 1
running: "sccache" "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-unknown-unknown" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4" "-I" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out" "-I" "." "-Wall" "-Wextra" "-std=c++11" "-o" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/cvv.o" "-c" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/cvv.cpp"
cargo:warning=In file included from /home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/alphamat.cpp:1:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/common.hpp:2:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4/opencv2/core.hpp:52:
cargo:warning=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4/opencv2/core/cvdef.h:171:10: fatal error: 'limits' file not found
cargo:warning=#include <limits>
cargo:warning=         ^~~~~~~~
cargo:warning=1 error generated.
exit code: 1
cargo:warning=In file included from /home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/calib3d.cpp:1:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/calib3d.hpp:1:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/common.hpp:2:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4/opencv2/core.hpp:52:
cargo:warning=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4/opencv2/core/cvdef.h:171:10: fatal error: 'limits' file not found
cargo:warning=#include <limits>
cargo:warning=         ^~~~~~~~
cargo:warning=1 error generated.
exit code: 1
cargo:warning=In file included from /home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/bgsegm.cpp:1:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/common.hpp:2:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4/opencv2/core.hpp:52:
cargo:warning=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4/opencv2/core/cvdef.h:171:10: fatal error: 'limits' file not found
cargo:warning=#include <limits>
cargo:warning=         ^~~~~~~~
cargo:warning=1 error generated.
exit code: 1
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/manual-core.cpp:1:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/core.hpp:1:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/common.hpp:2:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4/opencv2/core.hpp:52:
cargo:warning=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4/opencv2/core/cvdef.h:171:10: fatal error: 'limits' file not found
cargo:warning=#include <limits>
cargo:warning=         ^~~~~~~~
cargo:warning=1 error generated.
exit code: 1
cargo:warning=In file included from /home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/bioinspired.cpp:1:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/bioinspired.hpp:3:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/common.hpp:2:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4/opencv2/core.hpp:52:
cargo:warning=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4/opencv2/core/cvdef.h:171:10: fatal error: 'limits' file not found
cargo:warning=#include <limits>
cargo:warning=         ^~~~~~~~
cargo:warning=1 error generated.
exit code: 1
cargo:warning=In file included from /home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/ccalib.cpp:1:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/ccalib.hpp:1:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/common.hpp:2:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4/opencv2/core.hpp:52:
cargo:warning=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4/opencv2/core/cvdef.h:171:10: fatal error: 'limits' file not found
cargo:warning=#include <limits>
cargo:warning=         ^~~~~~~~
cargo:warning=1 error generated.
exit code: 1
cargo:warning=In file included from /home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/core.cpp:1:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/core.hpp:1:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/common.hpp:2:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4/opencv2/core.hpp:52:
cargo:warning=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4/opencv2/core/cvdef.h:171:10: fatal error: 'limits' file not found
cargo:warning=#include <limits>
cargo:warning=         ^~~~~~~~
cargo:warning=1 error generated.
exit code: 1
cargo:warning=In file included from /home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/cvv.cpp:1:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp/common.hpp:2:
cargo:warning=In file included from /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4/opencv2/core.hpp:52:
cargo:warning=/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4/opencv2/core/cvdef.h:171:10: fatal error: 'limits' file not found
cargo:warning=#include <limits>
cargo:warning=         ^~~~~~~~
cargo:warning=1 error generated.
exit code: 1

--- stderr
=== Environment configuration:
===   OPENCV_HEADER_DIR = None
===   OPENCV_PACKAGE_NAME = None
===   OPENCV_PKGCONFIG_NAME = None
===   OPENCV_LINK_LIBS = None
===   OPENCV_LINK_PATHS = None
===   OPENCV_INCLUDE_PATHS = None
===   PKG_CONFIG_PATH = None
===   VCPKG_ROOT = None
=== Setting up OpenCV library from pkg_config
=== OpenCV library configuration: Library {
    pkg_name: "opencv4",
    include_paths: [
        "/usr/include/opencv4",
    ],
    version: "4.3.0",
    cargo_metadata: [
        "cargo:rustc-link-search=native=/usr/lib",
        "cargo:rustc-link-lib=opencv_gapi",
        "cargo:rustc-link-lib=opencv_stitching",
        "cargo:rustc-link-lib=opencv_alphamat",
        "cargo:rustc-link-lib=opencv_aruco",
        "cargo:rustc-link-lib=opencv_bgsegm",
        "cargo:rustc-link-lib=opencv_bioinspired",
        "cargo:rustc-link-lib=opencv_ccalib",
        "cargo:rustc-link-lib=opencv_cvv",
        "cargo:rustc-link-lib=opencv_dnn_objdetect",
        "cargo:rustc-link-lib=opencv_dnn_superres",
        "cargo:rustc-link-lib=opencv_dpm",
        "cargo:rustc-link-lib=opencv_highgui",
        "cargo:rustc-link-lib=opencv_face",
        "cargo:rustc-link-lib=opencv_freetype",
        "cargo:rustc-link-lib=opencv_fuzzy",
        "cargo:rustc-link-lib=opencv_hdf",
        "cargo:rustc-link-lib=opencv_hfs",
        "cargo:rustc-link-lib=opencv_img_hash",
        "cargo:rustc-link-lib=opencv_intensity_transform",
        "cargo:rustc-link-lib=opencv_line_descriptor",
        "cargo:rustc-link-lib=opencv_quality",
        "cargo:rustc-link-lib=opencv_rapid",
        "cargo:rustc-link-lib=opencv_reg",
        "cargo:rustc-link-lib=opencv_rgbd",
        "cargo:rustc-link-lib=opencv_saliency",
        "cargo:rustc-link-lib=opencv_stereo",
        "cargo:rustc-link-lib=opencv_structured_light",
        "cargo:rustc-link-lib=opencv_phase_unwrapping",
        "cargo:rustc-link-lib=opencv_superres",
        "cargo:rustc-link-lib=opencv_optflow",
        "cargo:rustc-link-lib=opencv_surface_matching",
        "cargo:rustc-link-lib=opencv_tracking",
        "cargo:rustc-link-lib=opencv_datasets",
        "cargo:rustc-link-lib=opencv_text",
        "cargo:rustc-link-lib=opencv_dnn",
        "cargo:rustc-link-lib=opencv_plot",
        "cargo:rustc-link-lib=opencv_videostab",
        "cargo:rustc-link-lib=opencv_videoio",
        "cargo:rustc-link-lib=opencv_viz",
        "cargo:rustc-link-lib=opencv_xfeatures2d",
        "cargo:rustc-link-lib=opencv_shape",
        "cargo:rustc-link-lib=opencv_ml",
        "cargo:rustc-link-lib=opencv_ximgproc",
        "cargo:rustc-link-lib=opencv_video",
        "cargo:rustc-link-lib=opencv_xobjdetect",
        "cargo:rustc-link-lib=opencv_objdetect",
        "cargo:rustc-link-lib=opencv_calib3d",
        "cargo:rustc-link-lib=opencv_imgcodecs",
        "cargo:rustc-link-lib=opencv_features2d",
        "cargo:rustc-link-lib=opencv_flann",
        "cargo:rustc-link-lib=opencv_xphoto",
        "cargo:rustc-link-lib=opencv_photo",
        "cargo:rustc-link-lib=opencv_imgproc",
        "cargo:rustc-link-lib=opencv_core",
    ],
}
=== Found OpenCV library version: 4.3.0 in headers located at: /home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4

error occurred: Command "sccache" "clang" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=wasm32-unknown-unknown" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/src_cpp" "-I" "/home/horky/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.34.0/headers/4" "-I" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out" "-I" "." "-Wall" "-Wextra" "-std=c++11" "-o" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/alphamat.o" "-c" "/home/horky/Documents/WorkspaceRust/cvwasm/target/wasm32-unknown-unknown/release/build/opencv-18a6d2821fe7f5f3/out/alphamat.cpp" with args "clang" did not execute successfully (status code exit code: 1).

I see. Well, the current build process is targeted at using OpenCV as a native shared library which is not supported in wasm environment obviously. I do have plans to explore this direction though and any help is greatly appreciated!

I have a simple example of how to build OpenCV into Emscripten target, but still not sure how to "glue" it properly with "rustc".
https://github.com/Horki/lanelines_wasm_emscripten/blob/master/BUILD.md

Hi @Horki @twistedfall I am also insterested in this topic. I have a bit of experience with Emscripten, and yes probably is required to link the OpenCV static libs compiled with Emscripten in the final stage of the project. I would try to dig into this, but i feel as an absolute beginner (almost) with Rust. 😢

Hi @Horki @twistedfall I am also insterested in this topic. I have a bit of experience with Emscripten, and yes probably is required to link the OpenCV static libs compiled with Emscripten in the final stage of the project. I would try to dig into this, but i feel as an absolute beginner (almost) with Rust. 😢

Hi, well, this task is up for grabs if you feel like it. I've done a preliminary investigation and it's not an easy deal. You would need to have some javascript glue to link wasm from opencv crate with wasm from OpenCV lib. Then there is also question of mapping the data structs between them. It's a good investigative task, but not something you would do in a week.

Hi, well, this task is up for grabs if you feel like it. I've done a preliminary investigation and it's not an easy deal. You would need to have some javascript glue to link wasm from opencv crate with wasm from OpenCV lib. Then there is also question of mapping the data structs between them. It's a good investigative task, but not something you would do in a week.

@twistedfall does problem solved? I tried to build my app with wasm-pack and have similar errors

Nope, no real work has been done in that direction yet as far as I know.

This might be helpful for someone - I tried to build the same project on Ubuntu instead of Arch - and the build succeeded

Hi, well, this task is up for grabs if you feel like it. I've done a preliminary investigation and it's not an easy deal. You would need to have some javascript glue to link wasm from opencv crate with wasm from OpenCV lib. Then there is also question of mapping the data structs between them. It's a good investigative task, but not something you would do in a week.

Hi @twistedfall back on this. Have you a reference example for this? Not with opencv-rust but another project that used the approach you explained. Thank you.

Not really, I don’t think something like this has ever been done to be honest.

Alternatively it may be possible to build OpenCV as static wasm and link it directly to the Rust wasm binary. As far as I know this will imply going around the standard OpenCV wasm build procedure and writing your own build script.

Alternatively it may be possible to build OpenCV as static wasm and link it directly to the Rust wasm binary. As far as I know this will imply going around the standard OpenCV wasm build procedure and writing your own build script.

i did already for wasm-ar project by @EdwardLu2018 see this build script https://github.com/webarkit/opencv-em it build the opencv static libs with WASM emscripten. But how can i link the static libs in Rust?

That's a good start, I didn't realize it existed! It might be way simpler to go this way. For now I'm not sure how do you statically link another wasm library. There are some hits on google like https://users.rust-lang.org/t/how-to-static-link-c-lib-to-wasm/36558 so it seems to be doable.

That article is a good example i think, I will try a similar approach. Thank you @twistedfall !

I would prefer to keep it open as a todo item if you don’t mind

Would be nice to have wasm target added

Is there any work being done for this? It seems to compile fine but the linker fails

Not at the moment unfortunately. Linking is the main problem indeed.

I was able to successfully build this repo. It was for the wasm32-unknown-emscripten target rather than wasm32-unknown-unknown.
Following the build instructions for opencv for wasm with the --wasm flag (i.e. emcmake python3 platforms/js/build_js.py build_js --build_wasm).  So you just need to run make install from the build folder, and point opencv-rust to the install location. Unfortunately the install prefix is hard coded in platforms/js/build_js.py.
# check the install dir for the list of libs built
export OPENCV_LINK_LIBS=opencv_calib3d,opencv_core,opencv_dnn,opencv_features2d,opencv_flann,opencv_imgproc,opencv_objdetect,opencv_photo,opencv_video
export OPENCV_LINK_PATHS=/path/to/install/lib/
export OPENCV_INCLUDE_PATHS=/path/to/install/include/opencv4/
export OPENCV_LINKAGE=static

cargo build --target=wasm32-unknown-emscripten

You can also set these values in .cargo/config.toml.

That's great news! I will try to reproduce it, thank you for sharing!

Hello, @mattangus ,Thanks for sharing your method. I tried using it, but I see the following get the warnings:
 note: wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'algorithm.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'alloc.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'arithm.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'arithm.dispatch.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'array.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'async.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'batch_distance.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'bindings_utils.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'buffer_area.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'channels.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'check.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'command_line_parser.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'conjugate_gradient.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'convert.dispatch.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'convert_c.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'convert_scale.dispatch.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'copy.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'count_non_zero.dispatch.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'cuda_gpu_mat.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'cuda_gpu_mat_nd.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'cuda_host_mem.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'cuda_info.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'cuda_stream.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'datastructs.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'directx.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'downhill_simplex.cpp.o' is neither Wasm object file nor LLVM bitcode
          ...

and then the linking fails with
 emcc: error: '/Users/tushar/Aftershoot/emsdk/upstream/bin/wasm-ld -o /Users/tushar/Meditations/Exps/temp/target/wasm32-unknown-emscripten/release/deps/temp.wasm /Users/tushar/Meditations/Exps/temp/target/wasm32-unknown-emscripten/release/deps/temp.temp.7907a7cd61e9fa75-cgu.0.rcgu.o /Users/tushar/Meditations/Exps/temp/target/wasm32-unknown-emscripten/release/deps/temp.9qr5wamp2zed2w4tk6teolorc.rcgu.o -L/Users/tushar/Meditations/Exps/temp/target/wasm32-unknown-emscripten/release/deps -L/Users/tushar/Meditations/Exps/temp/target/release/deps -L/Users/tushar/Meditations/Exps/temp/target/wasm32-unknown-emscripten/release/build/opencv-33eb669076e3c94c/out -L/Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib -L/Users/tushar/Aftershoot/backend/lib/macos/arm64/libjpeg/lib -L/Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib /Users/tushar/Meditations/Exps/temp/target/wasm32-unknown-emscripten/release/deps/libopencv-b31e8443eece564d.rlib /Users/tushar/Meditations/Exps/temp/target/wasm32-unknown-emscripten/release/deps/liblibc-8648be1f97d4a9d9.rlib /Users/tushar/Meditations/Exps/temp/target/wasm32-unknown-emscripten/release/deps/libnum_traits-669bc3b55d805a23.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libstd-078a2440946b4ad9.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libpanic_unwind-38df63a19dbda819.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/librustc_demangle-613f369fbf1858bc.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libstd_detect-66829d196d7e3f32.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libhashbrown-31c79f03125d17f2.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/librustc_std_workspace_alloc-95a3ab51dbc79ccc.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libminiz_oxide-bc3bd3e2b31ed919.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libadler-b7250bbf9f70ffb3.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libunwind-5e22616f1b445a53.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libcfg_if-5601884a4b7e82c7.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/liblibc-bbff3e626f351ebb.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/liballoc-0830855ff540bd35.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/librustc_std_workspace_core-392cd8b7d678e020.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libcore-0ee71266a6bac8a1.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libcompiler_builtins-5cee2ca66d5fec8d.rlib /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_imgcodecs.a /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_imgproc.a -littnotify /Users/tushar/Aftershoot/backend/lib/macos/arm64/libjpeg/lib/libturbojpeg.a /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/liblibtiff.a /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libtegra_hal.a /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libzlib.a -lc -L/Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib -L/Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/self-contained -L/Users/tushar/Aftershoot/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten -lGL-getprocaddr -lal -lhtml5 -lstubs -lnoexit -lc -ldlmalloc -lcompiler_rt -lc++ -lc++abi -lsockets -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-cxx-exceptions -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr /var/folders/qr/w92rrf2x5pn_ny17y7kljt300000gn/T/tmpz6u0sdy4libemscripten_js_symbols.so --strip-debug --export=ocvrs_create_byte_string --export=ocvrs_create_string --export=_emscripten_stack_alloc --export=__get_temp_ret --export=__set_temp_ret --export=__cxa_is_pointer_type --export=__cxa_can_catch --export=__cxa_increment_exception_refcount --export=__cxa_decrement_exception_refcount --export=setThrew --export=__cxa_free_exception --export=__wasm_call_ctors --export=emscripten_stack_get_current --export=_emscripten_stack_restore --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-if-defined=__start_em_lib_deps --export-if-defined=__stop_em_lib_deps --export-if-defined=__start_em_js --export-if-defined=__stop_em_js --export-if-defined=main --export-if-defined=__main_argc_argv --export-table -z stack-size=65536 --no-growable-memory --initial-heap=16777216 --no-entry --table-base=1 --global-base=1024' failed (returned 1)

I used the following command to run the script
emcmake python3 platforms/js/build_js.py out/build --build_wasm --cmake_option="-DOPENCV_EXTRA_MODULES_PATH=/Users/tushar/Aftershoot/opencv_contrib/modules"

I also checked what these object files are:
algorithm.cpp.o:                   WebAssembly (wasm) binary module version 0x1 (MVP)
alloc.cpp.o:                       WebAssembly (wasm) binary module version 0x1 (MVP)
arithm.cpp.o:                      WebAssembly (wasm) binary module version 0x1 (MVP)
arithm.dispatch.cpp.o:             WebAssembly (wasm) binary module version 0x1 (MVP)
array.cpp.o:                       WebAssembly (wasm) binary module version 0x1 (MVP)
async.cpp.o:                       WebAssembly (wasm) binary module version 0x1 (MVP)
batch_distance.cpp.o:              WebAssembly (wasm) binary module version 0x1 (MVP)
bindings_utils.cpp.o:              WebAssembly (wasm) binary module version 0x1 (MVP)
buffer_area.cpp.o:                 WebAssembly (wasm) binary module version 0x1 (MVP)
channels.cpp.o:                    WebAssembly (wasm) binary module version 0x1 (MVP)
check.cpp.o:                       WebAssembly (wasm) binary module version 0x1 (MVP)

These seem to be wasm modules.. But then why the linker is complaining..
Any help will be appreciated.

@CeNiEi That seems to work for me. Check the build logs (cargo build -vv --target=wasm32-unknown-emscripten). There should be something like this:
[opencv 0.92.2] === Detected probe priority boost based on environment vars: pkg_config: false, cmake: false, vcpkg: false
[opencv 0.92.2] === Probing the OpenCV library in the following order: environment, pkg_config, cmake, vcpkg_cmake, vcpkg
[opencv 0.92.2] === Configuring OpenCV library from the environment:
[opencv 0.92.2] ===   include_paths: /path/to/installed/include
[opencv 0.92.2] ===   link_paths: /path/to/installed/lib
[opencv 0.92.2] ===   link_libs: opencv_calib3d,opencv_core,opencv_dnn,opencv_features2d,opencv_flann,opencv_imgproc,opencv_objdetect,opencv_photo,opencv_video

Hello, @mattangus ,Thanks for sharing your method. I tried using it, but I see the following get the warnings:
 note: wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'algorithm.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'alloc.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'arithm.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'arithm.dispatch.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'array.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'async.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'batch_distance.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'bindings_utils.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'buffer_area.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'channels.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'check.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'command_line_parser.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'conjugate_gradient.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'convert.dispatch.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'convert_c.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'convert_scale.dispatch.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'copy.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'count_non_zero.dispatch.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'cuda_gpu_mat.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'cuda_gpu_mat_nd.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'cuda_host_mem.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'cuda_info.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'cuda_stream.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'datastructs.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'directx.cpp.o' is neither Wasm object file nor LLVM bitcode
          wasm-ld: warning: /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a: archive member 'downhill_simplex.cpp.o' is neither Wasm object file nor LLVM bitcode
          ...

and then the linking fails with
 emcc: error: '/Users/tushar/Aftershoot/emsdk/upstream/bin/wasm-ld -o /Users/tushar/Meditations/Exps/temp/target/wasm32-unknown-emscripten/release/deps/temp.wasm /Users/tushar/Meditations/Exps/temp/target/wasm32-unknown-emscripten/release/deps/temp.temp.7907a7cd61e9fa75-cgu.0.rcgu.o /Users/tushar/Meditations/Exps/temp/target/wasm32-unknown-emscripten/release/deps/temp.9qr5wamp2zed2w4tk6teolorc.rcgu.o -L/Users/tushar/Meditations/Exps/temp/target/wasm32-unknown-emscripten/release/deps -L/Users/tushar/Meditations/Exps/temp/target/release/deps -L/Users/tushar/Meditations/Exps/temp/target/wasm32-unknown-emscripten/release/build/opencv-33eb669076e3c94c/out -L/Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib -L/Users/tushar/Aftershoot/backend/lib/macos/arm64/libjpeg/lib -L/Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib /Users/tushar/Meditations/Exps/temp/target/wasm32-unknown-emscripten/release/deps/libopencv-b31e8443eece564d.rlib /Users/tushar/Meditations/Exps/temp/target/wasm32-unknown-emscripten/release/deps/liblibc-8648be1f97d4a9d9.rlib /Users/tushar/Meditations/Exps/temp/target/wasm32-unknown-emscripten/release/deps/libnum_traits-669bc3b55d805a23.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libstd-078a2440946b4ad9.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libpanic_unwind-38df63a19dbda819.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/librustc_demangle-613f369fbf1858bc.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libstd_detect-66829d196d7e3f32.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libhashbrown-31c79f03125d17f2.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/librustc_std_workspace_alloc-95a3ab51dbc79ccc.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libminiz_oxide-bc3bd3e2b31ed919.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libadler-b7250bbf9f70ffb3.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libunwind-5e22616f1b445a53.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libcfg_if-5601884a4b7e82c7.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/liblibc-bbff3e626f351ebb.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/liballoc-0830855ff540bd35.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/librustc_std_workspace_core-392cd8b7d678e020.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libcore-0ee71266a6bac8a1.rlib /Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/libcompiler_builtins-5cee2ca66d5fec8d.rlib /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_core.a /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_imgcodecs.a /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libopencv_imgproc.a -littnotify /Users/tushar/Aftershoot/backend/lib/macos/arm64/libjpeg/lib/libturbojpeg.a /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/liblibtiff.a /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libtegra_hal.a /Users/tushar/Aftershoot/backend/lib/macos/arm64/opencv/lib/libzlib.a -lc -L/Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib -L/Users/tushar/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/wasm32-unknown-emscripten/lib/self-contained -L/Users/tushar/Aftershoot/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten -lGL-getprocaddr -lal -lhtml5 -lstubs -lnoexit -lc -ldlmalloc -lcompiler_rt -lc++ -lc++abi -lsockets -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-cxx-exceptions -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr /var/folders/qr/w92rrf2x5pn_ny17y7kljt300000gn/T/tmpz6u0sdy4libemscripten_js_symbols.so --strip-debug --export=ocvrs_create_byte_string --export=ocvrs_create_string --export=_emscripten_stack_alloc --export=__get_temp_ret --export=__set_temp_ret --export=__cxa_is_pointer_type --export=__cxa_can_catch --export=__cxa_increment_exception_refcount --export=__cxa_decrement_exception_refcount --export=setThrew --export=__cxa_free_exception --export=__wasm_call_ctors --export=emscripten_stack_get_current --export=_emscripten_stack_restore --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-if-defined=__start_em_lib_deps --export-if-defined=__stop_em_lib_deps --export-if-defined=__start_em_js --export-if-defined=__stop_em_js --export-if-defined=main --export-if-defined=__main_argc_argv --export-table -z stack-size=65536 --no-growable-memory --initial-heap=16777216 --no-entry --table-base=1 --global-base=1024' failed (returned 1)

I used the following command to run the script
emcmake python3 platforms/js/build_js.py out/build --build_wasm --cmake_option="-DOPENCV_EXTRA_MODULES_PATH=/Users/tushar/Aftershoot/opencv_contrib/modules"

I also checked what these object files are:
algorithm.cpp.o:                   WebAssembly (wasm) binary module version 0x1 (MVP)
alloc.cpp.o:                       WebAssembly (wasm) binary module version 0x1 (MVP)
arithm.cpp.o:                      WebAssembly (wasm) binary module version 0x1 (MVP)
arithm.dispatch.cpp.o:             WebAssembly (wasm) binary module version 0x1 (MVP)
array.cpp.o:                       WebAssembly (wasm) binary module version 0x1 (MVP)
async.cpp.o:                       WebAssembly (wasm) binary module version 0x1 (MVP)
batch_distance.cpp.o:              WebAssembly (wasm) binary module version 0x1 (MVP)
bindings_utils.cpp.o:              WebAssembly (wasm) binary module version 0x1 (MVP)
buffer_area.cpp.o:                 WebAssembly (wasm) binary module version 0x1 (MVP)
channels.cpp.o:                    WebAssembly (wasm) binary module version 0x1 (MVP)
check.cpp.o:                       WebAssembly (wasm) binary module version 0x1 (MVP)

These seem to be wasm modules.. But then why the linker is complaining..
Any help will be appreciated.

@CeNiEi Probably you should avoid to build opencv with extra modules as you can see from @mattangus instructions there are only a set of limited opencv libs

@mattangus @kalwalt
But the issue is that I want to use the opencv_contrib modules. And the original opencv_js script does in fact support building with contrib modules


No SSL certificate

http://kusama.polkassembly.io/ does not have a SSL certificate.

An SSL certificate has been installed.


block_execution settings used from reporter instead of user operating defect dojo

Each user has a setting in their profile named block_execution. By default this is False and most expensive actions triggered by the user are handle in the background by celery (i.e. dedupe, push to jira, apply rules, ...).
When saving a finding, the current user is not nown in the finding.save() method. As a workaround the block_execution setting from the reporter is used. This can lead to confusing situations where actions are sometimes async and sometimes synchronous. This can lead to users missing errors in the jira integration, missing alerts, etc.
Possible solutions:
A) pass on the request or request.user object everywhere in the (kw)args.
B) start layering like a (Java Enterprise) boss with all kinds of DAO objects
C) use a middleware like django-crum: https://pythonhosted.org/django-crum/

option C is implemented in #2889


Upgrade to 2.3.0

New features:

A new and unified GMX interface for CHARMM/AMBER format input files
Support reflecting boundaries in PMF calculations
Initial unit tests

New dependency:

parmed

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Support for table index

If there exists index on table - research and explore possibility that they can be used for scan.
Interesting would be to look into BRIN indexes that can be used as way to pre filter pages based on query filters.

Is there still something actionable here for the 0.1.0 release?

Closing this in favor of #243 (I didn't realise this issue was still open when I created that one). This issue was resolved, but we'll now revert its implementation for #183


chore: Logs the duration of migrations execution

SUMMARY
Depending on the amount of data an organization has, the migration scripts can take a long time to run. This PR adds the duration of the complete migration process to help administrators to estimate downtime for upgrades/downgrades. Duration is only logged in case all migrations successfully complete.
TESTING INSTRUCTIONS
CI should be sufficient.
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

[optional] a context decorator could be nice and simple for this:

That would be nice. We can think about this when creating the helper functions for the migrations as part of [SIP-142] Improving Database Migration Management


Fix aftman.toml file being removed

It seems like installation is failing since this commit https://github.com/ok-nick/setup-aftman/commit/3a79d6c063a62d55640f7dbfd9f3af5a5286a54c because rm aftman* also removes the aftman.toml file that contains the tool definitions. This PR makes the pattern more specific and removes exact filenames aftman.exe on Windows and aftman on macOS/Linux instead.

Finally, thank you. I was wondering why it wasn't working. I guess it's because the toml file was being deleted. I'll check this out when I get back to my computer, thanks.


Add pthread_main_np to FreeBSD-like and _lwp_self to NetBSD

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @gnzlbg (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

cc @asomers
@bors r=asomers

:pushpin: Commit 36a92d5278fa1b908632ea3bcaafec7b2ef0a102 has been approved by asomers

:hourglass: Testing commit 36a92d5278fa1b908632ea3bcaafec7b2ef0a102 with merge ff63cb517872d95bdba9960d4d200d024c1805a0...

:sunny: Test successful - checks-cirrus-freebsd-10, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, status-azure
Approved by: asomers
Pushing ff63cb517872d95bdba9960d4d200d024c1805a0 to master...

Not that there's anything wrong with this PR, but why did you tell bors that I approved it?

 I wanted to delegate approving this PR to you. but instead of delegate=X I wrote r=X and apparently r=X is valid syntax that approves a PR in the name of somebody else =/ Sorry.


Added single-loop examples to 08a and 08b (EnKF)

I've added examples to both of the EnKF scripts, 08a and 08b, showing how to implement the EnKF assimilation in a single loop, which is how one would typically do it in practice. This may make it easier to translate the educational example to practical applications.
The branch to be pulled is already up-to-date with the current master branch. Only changes to the markdown, code, and new outputs are included; the notebook metadata are unchanged. All code has been tested.

In the example 11,  "Wofost72_PP_notebook_11.conf"  is needed, but this file is not included in this project. Could you please add this file, or direct a path to download?  Thanks for your project,  and it is useful.

Is this a notebook or a model configuration (.conf) file?
Allard

Op 08-01-2024 04:33 CET schreef ZhiyiLiao @.***>:
In the example 11, "Wofost72_PP_notebook_11.conf" is needed, but this file is not included in this project. Could you please add this file, or direct a path to download? Thanks for your project, and it is useful.
—
Reply to this email directly, view it on GitHub https://github.com/ajwdewit/pcse_notebooks/pull/19#issuecomment-1880340339, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJYCNT7KF2RQWF444XMUMDYNNSINAVCNFSM6AAAAAA76DEWVKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBQGM2DAMZTHE.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

芷依已收到您发送的邮件，谢谢！

Hi! It seems that compute_analysed_states may be using the definition of H in the block related to the Kalman Gain H = np.identity(len(obs)), since it is not an argument of the function. I don't know if this is by design, but I wanted to let you know. Thank you for the script!

芷依已收到您发送的邮件，谢谢！

Hi, I don't know if this was by design, but some of the functions for use in the loop (script 8a) are using the definitions of the previous steps (e.g. H). Thank you for the script!


chore(ingest): cleanup unused hash methods

Checklist

[ ] The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
[ ] Links to related issues (if applicable)
[ ] Tests for the changes have been added/updated (if applicable)
[ ] Docs related to the changes have been added/updated (if applicable). If a new feature has been added a Usage Guide has been added for the same.
[ ] For any breaking change/potential downtime/deprecation/big changes an entry has been made in Updating DataHub

Looks like we have a bigger issue here, which is that our usage of lru_cache on source methods (as opposed to on functions) will prevent sources from ever being garbage collected
Going to close this for now, but definitely something to fix up in the future


Created a welcomebot  for this pi-builder project

Created a config,yml file, a welcome bolt for this project
Thanks for opening a pull request! In this repository, opening a PR will initiate the generation of a new Raspberry Pi image, and create an image file you can download and use in your Raspberry Pi.
The changes you add to the pull request, such as adding software to install, will be run on the generated image.
For an example, see the software installed and configured in this pull request: https://github.com/publiclab/image-builder-rpi/pull/15/files
Recipe
Use this space to describe what your "recipe" is intended to install and configure on a Raspberry Pi:

Download instructions
Generating the image will take a few minutes. Once the image is prepared, and if it succeeded, you'll see a green checkmark at the bottom of the pull request. To download the image:

click the green checkmark; you'll go to a page at a URL like https://gitlab.com/publiclab/image-builder-rpi/pipelines/########/builds
On this page, click the Jobs tab, next to Pipeline
Click the green Passed button
Click Download in the right-hand sidebar
Unzip the artifacts.zip file, and also the hypriotos-rpi-camera_web.img.zip within it
Use a program like https://etcher.io/ to flash it to an SD card

You'll also be able to read the output of the image generation in this window.
We hope to create a bot to report back the completed image URL in each pull request. If you can help create such a bot, please contact us at:
https://github.com/publiclab/image-builder-rpi/issues/16
Thanks!

@jywarren Kindly review my PR

Thank you @cesswairimu, I have removed the unwanted line. Please review

Thank you @cesswairimu for your patience with me. I have made the necessary adjustment. Kindly review

Hi @cesswairimu I'm yet to get your review. Kindly review

@cesswairimu please review again, I have made the correction. Thanks for your patience


Updates

Add OSM_Way_Id to the gps logging.
Add Chrysler 300 support
Add Toyota Prius 2021 Support
Split Corolla and Corolla Hybrid for TSS2 and fix up condition that would cause a crash
Add OSM Credit
Add More FPs i.e. Kona, Genesis

fixed eco and sport button for tss2 cars if you dont have button use op_edit.py
fixed double breaking.


Automatic Comment on Issue Close

The feature I'm proposing involves automatically commenting on an issue when it is closed within the project repository. This comment will serve as a closing message, expressing gratitude to the contributor for their input, informing them of the issue's resolution status, and providing any necessary next steps or additional information.

The feature I'm proposing involves automatically commenting on an issue when it is closed within the project repository. This comment will serve as a closing message, expressing gratitude to the contributor for their input, informing them of the issue's resolution status, and providing any necessary next steps or additional information.

These are not important. And we already have.

Our main focus on providing Insightful Content


restart pod after patch configmap

fix #165

Just noticed this PR. @aditighag was already working on this in #151 which just got merged.


Make extract-api part of the build and update api.md files

Fixes #5641

@XiaoningLiu, @jiacfan We will be merging this PR as it mainly adds the api extractor step to the build process and resolves merge conflicts resulting from #5632 and #5567
Do leave a comment if you see anything unexpected here


Keyboard remap func requirement.

Dear developer. I'm currently using 0.31.2
The keyboard remap work perfect for my external third-party Bluetooth keyboard to achieve mac-os like function key layout. But when remapping, the system touch keyboard remap at same time which troublesome for copy and paste. If the remap function could take charge only for keyboard except system touch keyboard would be ideal.
And for shortcut  remap, i found that when remap one specific key combination (eg Alt-D) for one app, it could not be further remapped for others. I mean, it would be grateful if more detailed logic like 'better touch tool' could be introduced.
Thank you.

No way for us to do per-keyboard at this moment in time.  It was something we wanted to do but without some super low level work, we won't be able to.
https://github.com/microsoft/PowerToys/issues/1460 is the tracking issue.


Fix names.

Fix class name.
Fix variable name.

That's because the documentation code wasn't working properly.

Thank you for your contribution.
Could you send PR to main repository? This is a read only subtree.
https://github.com/ventoviro/windwalker
https://github.com/ventoviro/windwalker/tree/master/src/Crypt
Thank you.

Fixed in https://github.com/ventoviro/windwalker/issues/259


[feat:] Add params to the plugin config yaml

It would be great if we could pass parameters to the underline yaml file of a  plugin to make it more flexible.
i.e.: in a plugin I have:
plugin.yaml
myfile.yaml
the plugin is:
plugin-name: mycustomplugin
namespace: "mynamespace"
yaml:
  - url: "myfile.yaml"
    type: "file"
    param: "var1=val1 var2=val2"ù

the myfile.yaml has something like:
apiVersion: apps/v1
kind: Deployment
...
  template:
    metadata:
      labels:
        app: jupyter-srv
    spec:
      containers:
      - name: {{var1}}
         value: {val1}
       image: {{ val1 }}

/ena

this is managed by inline plugins now


Make fasta_windows sensitive to soft-masking

Might be useful. Suggested by @claudia-c-weber

Fixed - accidentally used #6 instead of #4 in the commit message.


[Sema] Setter has incorrect mutating-ness inside class-constrained protocol extension

If we have a class-constrained protocol extension, where the protocol does not impose a class requirement, then the setter is incorrectly inferred to be mutating by default.
Resolves SR-11298.

cc @slavapestov

Technically source-breaking, but I kinda hope no one is depending on this.
protocol SR_11298_P {
  init()
}

class SR_11298_C: SR_11298_P {
  var property: String = ""
  required init() {}
}

extension SR_11298_P where Self: SR_11298_C {
  var wrappingProperty: String {
    get { return property }
    set { self = .init() }
  }
}

let origInstance = SR_11298_C()
var instance = origInstance
instance.wrappingProperty = ""
print(instance === origInstance)

Can someone kick off the tests? Thanks!

@swift-ci Please test

@swift-ci Please test source compatibility

Build failed
Swift Test Linux Platform
Git Sha - 759e4a3e264622f1a094eb34df5b09b0c302c129

Build failed
Swift Test OS X Platform
Git Sha - 759e4a3e264622f1a094eb34df5b09b0c302c129

Thanks! All tests have passed!

Thanks, @theblixguy!

Should we make a note of this in the changelog? Note that this change can also break code where the setter delegates to another mutating requirement or extension member, such as:
protocol P {
  var property: String { get set }
}

extension P where Self : AnyObject {
  var wrappingProperty: String {
    get { property }
    set { property = newValue }
  }
}

Ah, hm. That might be a more serious concern, especially since people are already confused about why protocol methods can be mutating for classes.

Reverting for now.

@theblixguy Can you create a PR that adds a test case for the current behavior, including @hamishknight's example? I'm not sure it's tested anywhere in our suite and we want to make sure any change is intentional.

Sure. I’ve also created a forum thread to discuss this.


Replace codecov.io dependency

The codecov.io dependency (https://github.com/cainus/codecov.io) is being deprecated, and is using outdated dependencies. They suggest using codecov-node(https://github.com/codecov/codecov-node) as a replacement.
Currently, tap has an insecure dependency a few levels deep because of codecov.io using an ancient version of request which uses and even older version of hawk. See this thread for details: https://github.com/cainus/codecov.io/issues/29
They decided to deprecate codecov.io instead of fixing the actual issue.

You can also just update the version of codecov.io as a temporary fix as it looks like they updated their dependency. Either way, they still plan on deprecating the package.

+1

I can't switch over at least until https://github.com/codecov/codecov-node/pull/14 is completed and landed.

Went a different way on this, removing codecov in tap 6.0.


Is it possible to update it to support 5.x ?

Elastic provides reindexing feature in the latest elasticsearch.
So, I have no plan to support elasticsearch 5 at the moment.


Roll engine cc3009cb4ea9..19ac3e1ac251 (4 commits)

https://github.com/flutter/engine/compare/cc3009cb4ea9...19ac3e1ac251
git log cc3009cb4ea9..19ac3e1ac251 --no-merges --oneline
19ac3e1ac Roll src/third_party/skia 358558a4cecc..11f4994b84e1 (2 commits) (flutter/engine#6312)
7648d21b0 Dart SDK roll for 2018-09-21 (flutter/engine#6311)
5b8e8c328 Make FlutterStandardCodec handle writing NSData (flutter/engine#6207)
02901b78c Decouple PlatformViewsController from FlutterView. (flutter/engine#6303)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.

@rmistry @liyuqian : New roll has been created by https://autoroll.skia.org/r/flutter-engine-flutter-autoroll

Trybots failed. These were the failed builds: https://cirrus-ci.com/task/6323155186483200

Commit queue failed; closing this roll.


Automated Package Upgrade

:tada: This PR is included in version 2.2.148 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


how to update existing index with jdbc

Hi, jprante
very useful for you plugin jdbc, i use it import content to es directly.
below is my import scripts.
echo '{
"type" : "jdbc",
"jdbc": {
"url":"jdbc:mysql://localhost:3306/gz",
"statefile" : "statefile.json",
"user":"root",
"password":"mariadb",
"sql": [ {
"statement" :"select * from vc2c where es_update_time > ?",
"parameter" : [ "$metrics.lastexecutionstart" ]
}],
"index" : "source_test",
"type" : "source_test",
"metrics" : {
"logger" : {
"plain" : "false",
"json" : "true"
},
"enabled" : "true"
},
"elasticsearch" : {
"cluster" : "Test-cluster",
"host" : "<IP_ADDRESS>",
"port" : 9300
}
}
}' | java
-cp "${lib}/*"
-Dlog4j.configurationFile=${bin}/log4j2.xml
org.xbib.tools.Runner
org.xbib.tools.JDBCImporter

how to use schedule to define running it.
when db have been update like some status, or some content, how to update the existing index in elasticsearch. i can automatic get new increment data in es, but that's not what i want, too many duplicate index there. is there a good way to update it? thanks.

You can see  https://github.com/jprante/elasticsearch-jdbc#time-scheduled-execution to find out how to schedule
When you select data from db, you must define a unique field as _id, then the same record in db would be the some record in elasticsearch , otherwise elasticsearch just insert a new record. When I index Wordpress data, i do it in this way ,select id as _id, post_title, post_content from wp_posts

@dengshilong ok got it , thanks.

Don't use scheduled settings and crontab together. Just one of them.

Did you realize of implementing incremental index?

@chsnake now it working well, for incremental index. i use crontab to running it.


Remove CPieceObj::m_rctExtent

This PR is intended to replace PR #90 as described in https://github.com/CyberBoardPBEM/cbwindows/pull/90#issuecomment-1287619725

Looks good. Do you want me to merge to master?

Yes, please.


Create 'cardinal feature' annotation to drive which polyhierarchies to assert

We need a new annotation "cardinal feature" that would drive which of the possible multihierarchies to assert.
For instance, for Marfan, the primary parent would be 'genetic syndromic disease' and its cardinal features would be aortic, skeletal, and ocular.

Additional comments:

There should be a computational check that corroborates that these cardinal features are linked to the annotations (and that the community agrees to it). (@mellybelly)
This should be a conservative process.
There was also a suggestion to do this only (at least initially) with multi-systemic disorders for which there are publications in support -and wide acceptance of- said cardinal feature(s).
Cardinal features should be supported with HPO terms.
Please note that an opposing proposal was also made: that cardinal features should not be baked into the ontology; rather, classification should be done by organ and let the features be a matter of phenotypes, handled by HPO (or other sources as appropriate).


Segfault when using cargo test with glfw

Code:
extern crate glfw;
#[test]
fn test() {
    unsafe{glfw::ffi::glfwInit() };
    unsafe{glfw::ffi::glfwTerminate()};
}

Output of cargo test
   Compiling raytracer v0.1.0 (file:///home/normal/raytracer)
    Finished dev [unoptimized + debuginfo] target(s) in 0.44 secs
     Running target/debug/deps/raytracer-9ee32f3ce5c79175

running 1 test
test test ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured

error: process didn't exit successfully: `/home/normal/raytracer/target/debug/deps/raytracer-9ee32f3ce5c79175` (signal: 11, SIGSEGV: invalid memory reference)

To learn more, run the command again with --verbose.

Backtrace (via gdb on coredump, for some reason it works when running directly in gdb)
#0  0x00007f949a3f2150 in ?? ()
#1  0x00007f94a070b429 in __nptl_deallocate_tsd.part.4 () from /usr/lib/libpthread.so.0
#2  0x00007f94a070c498 in start_thread () from /usr/lib/libpthread.so.0
#3  0x00007f94a023654f in clone () from /usr/lib/libc.so.6

Glfw-rs issue that I probably didn't need to open here.
Tested on stable and nightly. Code works properly when run as a main function in a binary instead of as a test.

GlfwInit and glfwTerminate must only be called from the main thread. A crate's tests are not run in the main thread.

Damn, that's unfortunate.

@gmorenz - I asked this question on stack overflow and got a very helpful answer. Hope it helps you as well: http://stackoverflow.com/a/43458688/2521691

@jasongrlicky Thanks!


Throw Exceptions for all n+1 queries in our tests

Description
We recently added the ability to throw an exception in our tests if hibernate detects an n+1 query. Currently a number of tests are set to log the exception as an error. We should fix all of these queries so that our tests run without generating any n+1 queries and will fail if they detect them
Proposed solution

[ ] Fix the 174 Facility n+1 queries. PesonServiceTest is a good example
[ ] Fix the 150 TestEvent n+1 queries.DatahubUploaderServiceTest is a good example
[x] Fix the 92 PatientLink n+1 queries.TextMessageStatusService is a good example (#2445 )
[ ] Fix the 70 Organization n+1 queries.OrganizationServiceTest is a good example
[ ] Fix the 40 PhoneNumber n+1 queries.TestOrderService is a good example

Each of these can be tested by removing TestPropertySource(properties = "hibernate.query.interceptor.error-level=ERROR") in the example test file
Calls to TestPropertySource should be removed when there are no more n+1 queries in the file. can be check by querying files in backend/build/test-results/test for HibernateQueryInterceptor errors
Additional context

I am not sure that the n+1 query detection is working correctly in the API tests

related to https://github.com/CDCgov/prime-simplereport/issues/2184

@zdeveloper rewrite


Adding new topic for PKS with NSX-T Upgrade

WIP -- not ready for review/merge, thanks

@mjgutermuth @animatedmax Content is ready for review and merging. Content is applicable to both the 1.1 and master (1.2) branches. Thanks.


Exception Filters returns an empty body in asp.net-core 1.1

I have a very simple controller with  an ExceptionFilterAttribute that throws an exception
   [TypeFilter(typeof(MyControllerExceptionFilterAttribute))]
    public class HomeController : Controller
    {
        public IActionResult Index()
        {
            throw new Exception("Hello Exception");
            return View();
        }
   }
}

this is the ExceptionFilterAttribute
   [AttributeUsage(AttributeTargets.Method | AttributeTargets.Class, AllowMultiple = false)]
    public class MyControllerExceptionFilterAttribute : ExceptionFilterAttribute
    {
        protected readonly IHostingEnvironment _hostingEnvironment;
        protected readonly IModelMetadataProvider _modelMetadataProvider;

        public MyControllerExceptionFilterAttribute(IHostingEnvironment hostingEnvironment, IModelMetadataProvider modelMetadataProvider)
        {
            _hostingEnvironment = hostingEnvironment;
            _modelMetadataProvider = modelMetadataProvider;
        }

        public override void OnException(ExceptionContext context)
        {
            if (context.ExceptionHandled) return;
            var result = new ViewResult { ViewName = "ApplicationError" };
            context.ExceptionHandled = true; // mark exception as handled
            context.HttpContext.Response.Clear();
            context.Result = result;
        }
    }

this works fine in asp.net core 1.0, while in asp.net core 1.1 the result is not rendered anymore and the returned http response is like this:
HTTP/1.1 200 OK
Server: Kestrel
X-SourceFiles: =?UTF-8?B?QzpcUHJvamVjdHNcaW50ZXJhaC52aXN1YWxzdHVkaW8uY29tXEludmVudGFyaW9cTWFpblxTb3VyY2VcRnJvbnRvZmZpY2Vcc3JjXEZyb250b2ZmaWNl?=
X-Powered-By: ASP.NET
Date: Wed, 30 Nov 2016 14:49:53 GMT
Content-Length: 0

You can reproduce very easily in this way

create a new ASP.NET Core Web Application (.NET Framework). by default asp.net core 1.0 is installed. then add the controller the ExceptionFilterAttribute above and a very simple ApplicationError view: the view is rendered
update to asp.net core 1.1 then excecute: the view is not rendered and the returned page is blank
comment the  row   'context.ExceptionHandled = true;'  in ExceptionFilterAttribute: at this point the view is rendered as in step 1.

my conclusion is that 'context.ExceptionHandled = true' is not working as expected
I've made this small project to demostrate the behavior https://www.dropbox.com/s/dl1xa7d2nzy48o8/WebApplication3.zip?dl=0

Not sure this is a bug. It appears just a change in the default state of context.ExceptionHandled. That value is not intended to inform the developer on the exception state, but on the contrary for the developer to inform the framework it handeld the exception, so the exception must stop propagation..
In a few words you dont need to check context.ExceptionHandled since if another component handles the exception yor handler will not be invoked at all.
What changed in the new version is that this value is pre-set to true, since it is more common developer handles exception. In case developer decide it is not able to recover exception he may set context.ExceptionHandled to  false.

Hi @frankabbruzzese, thank you for your explanation.
I removed the check on ExceptionHandled, but I am still a bit confused about when to set it true or false:
the official sample set ExceptionHandled = true, then returns a view as result.
In my case it's working differently:

if i set ExceptionHandled = true: a 200 status is returned (as in the sample), but the body of the response is empty
if i set ExceptionHandled = false (or if I don't set it at all):  200 status is returned and the body of the response contains the rendered view

You should set ExceptionHandled = true when you handle exception and false whenyou want exception coninue being thrown up. This should always work also if  ExceptionHandled  default changed.
Otherwise there is a bug somewhere. Have you tried removing:
context.HttpContext.Response.Clear();
?

Here my ExceptionFilterAttribute now
        public override void OnException(ExceptionContext context)         {             var result = new ViewResult { ViewName = "ApplicationError" };             context.ExceptionHandled = true; // mark exception as handled             context.Result = result;         }
setting context.ExceptionHandled = false; or commenting the row, the view is shown
setting context.ExceptionHandled = true, a blank page is shown (response body empty)
The view is a single row

Errore Applicativo

the project is an  empty ASP.NET Core Web Application (.NET Framework)
No other code is present on my side

I downloaded your project and played with it. Basically context.ExceptionHandled = true,always cause a blank page while  context.ExceptionHandled = false, correcly displays the custom error page, that makes absolutely no sense.
You are right there is a bug!

@frankabbruzzese I thought the point of ExceptionHandled was to signal the framework that "I got it, it's ok". So it returning 200 OK should be expected no?

@juunas11 ,
ExceptionHandled = true, says "ok I handled the exception, no need to propagate it further", so in the case of @robertovanoli 2oo ok is expected since he have not explicitely set an error header. What is not expected is the blank page!!! Why the the View passsed in ViewResult is not rendered???
It is strange also what happens when setting ExceptionHandled = false. In this case if no ViewResult is set you get an error header which is correct. However, if you set a ViewResult you still get a 200 ok, but this time View is rendered!
Thus it appears that `ExceptionHandled should alway be set to false, and the response depends if you set or not the ViewResult.
Maybe ExceptionHandled = true must be used only when ExceptionFilter write directly in the response stream?? This would explain everything. However, this behavior is different from what is written in the documentation...So some correction is needed anywau :)

@frankabbruzzese Ohh, I misread it. The blank page is certainly weird since a view result was set. I'll have a look at this if I have a moment.

@robertovanoli I got the error page to show just by commenting out context.HttpContext.Response.Clear();. The other thing is that as @frankabbruzzese mentioned the default for ExceptionHandled is now true, so you must set it to false if you don't want to handle the exception.
    public override void OnException(ExceptionContext context)
    {
        if (_hostingEnvironment.IsDevelopment())
        {
            context.ExceptionHandled = false;
            return;
        }
        var result = new ViewResult { ViewName = "ApplicationError" };
        context.Result = result;
    }

This works for me.

@juunas11 ,
No actually. context.ExceptionHandled is not true as defaul, but it is false. I supposed it was true to explain the behavior,..but before downloading the project and debugging it.
Your code works simply bacause you dont set context.ExceptionHandled = true. Try setting explicitaly it to true, and you will see error page is not shown anymore.

@frankabbruzzese You are right! I took a little dive into ControllerActionInvoker's state machine.
This line in particular seems to be the reason the behaviour is the way it is: https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc.Core/Internal/ControllerActionInvoker.cs#L675
if (exceptionContext.Result != null && !exceptionContext.ExceptionHandled)
{
    goto case State.ExceptionShortCircuit;
}

So the short-circuiting is only done if a result is set, and ExceptionHandled is false. The short-circuit state is the one that executes the result. Seems to be this commit that added this part. @rynowak was this intended behaviour? After more testing I can confirm the OP's code worked as expected on 1.0.0, but not on 1.1.0.

@juunas11,
Either bug or change in intended meaning of  ExceptionHandled = true from "exception handled" to "exception handled completely" by writing response in the response stream.

This seems like it should be an or.
So, to confirm this is working as expected when you set both .Result and .ExceptionHandled

When you set a result, and leave ExceptionHandled false, the result gets executed. But if you set a result, and set ExceptionHandled to true, the result does not get executed.

@rynowak ,
Not convinced must be an or. In any case it appears that !exceptionContext.ExceptionHandled should be substituted with exceptionContext.ExceptionHandled. IE the main error appears to be the negation.
About the or. It depends if one allows the exception be handled by writing directly in the Response stream instead of returning a result. I dont know if this scenario is properly handled anyway, since
State.ExceptionShortCircuit perform an InvokeAsymc of the Result in any case.
Another strange stuff is:
Since with ExceptionHandled = true at moment the if fails, so according to the state machine the exception should be rethrown...instead a 200 ok is returned with a blank page!

@frankabbruzzese
Francesco,  for now I bypassed rendering a HTML response by myself .  As you can see setting ExceptionHandled = true works fine.  Obviously it's only a temporary workaround...
regards
'public override void OnException(ExceptionContext context)
{
context.ExceptionHandled = true; // mark exception as handled
context.HttpContext.Response.Clear();
context.HttpContext.Response.StatusCode = 400;
context.HttpContext.Response.ContentType = new MediaTypeHeaderValue("text/html").ToString();
var home = string.Format("{0}://{1}", context.HttpContext.Request.Scheme,context.HttpContext.Request.Host);
var htmlString ="SI E' VERIFICATO UN ERRORE INATTESO";
context.HttpContext.Response.WriteAsync(htmlString, Encoding.UTF8);
}
`

@dougbu @rynowak - any ideas on this?

We need to double check the behavior of short circuiting exception filters wrt compatibility with MVC5. This should be a patch candidate if we have a bug here

Have confirmed IActionFilters in MVC 5.2.3 and ASP.NET Core 1.1.0 behave the same. However, IExceptionFitlers behave differently w.r.t. setting Result but leaving ExceptionHandled==false. Should remove this special case around setting Result.
1.1.0 behaviour is also a regression compared to ASP.NET Core 1.0.x.
Long story about a consistent behaviour for ASP.NET Core:

Users can short-circuit most IFilterMetadata implementations by setting Result. But, only on the way in e.g. OnActionExecuting() can short-circuit but OnActionExecuted() cannot.
To short-circuit IExceptionFilter implementations (which are only called on the way out), users must set ExceptionHandled==true.
Setting ExceptionHandled==true in all IFilterMetadata implementations also ensures an Exception thrown in an action is not rethrown. An overridden Result is used in that case.
In a small, intentional deviation from MVC 5.2.3, setting Exception==null is handled identically to setting ExceptionHandled==true.

Fix should be a one-line change in ControllerActionInvoker line 675.

Resetting labels other than Bug and patch-proposed. @Eilon / @danroth27

This patch bug is approved. Please use the normal code review process w/ a PR and make sure the fix is in the correct branch, then close the bug and mark it as done.

@dougbu - I could use your help to fact check the following table:
I'm defining short circuit to mean that subsequent exception filters do not run, and no exception is thrown.

MVC 5.2.3
MVC Core 1.0.0
MVC Core 1.1.0
MVC Core 1.1.2 (proposed)

set Result
exception thrown
short circuit && result executed
short circuit && result executed
???

set ExceptionHandled
short circuit
short circuit
short circruit
???

set Exception = null
exception thrown
short circuit
short circuit
???

set Result && Exception Handled
short circuit && result executed
short circuit && result executed
short circuit
???

I'm going to move forward with a PR to make the behavior like the table above since that resolves the breaking change we accidentally made in 1.1.0. If there are any other changes we want to make here let's discuss that separately.

@rynowak I edited your table above with one tweak. But, I agree we should focus on the one thing customers have complained about. That's the unintended Core 1.0.0 to 1.1.0 change you're reverting in the 1.1.2 column.
BTW this could simply be a typo in one line of code. @frankabbruzzese mentioned the oddball at line 675 in ControllerActionInvoker above. None of the other ExceptionContext checks look like that one. The rest check exceptionContext.Exception == null and not exceptionContext.Result != null. (Well, there's another line with the same condition but that's just for logging.)

BTW this could simply be a typo in one line of code.

That's part of the fix.

https://github.com/aspnet/Mvc/pull/5777#issuecomment-279446439
This has been fixed in dev and in rel/1.1.2

@rynowak Glad this bug was squashed.
However, since 1.1.2 hasn't been released yet, what is the recommended workaround right now?
i.e. Within an exception filter, to perform a redirect / set the Result / etc.?

@grokky1 my workaround was: http://stackoverflow.com/questions/40892538/exception-filters-returning-an-empty-body-in-asp-net-core-1-1

I came here from the docs they say at the moment:

In ASP.NET 1.1, the response is not sent if you set ExceptionHandled to true and write a response. In that scenario, ASP.NET Core 1.0 does send the response, and ASP.NET Core 1.1.2 will return to the 1.0 behavior.

Should this work again?
        public void OnException(ExceptionContext context)
        {
            if (context.Exception is ApiError)
            {
                context.Result = (context.Exception as ApiError).GetResult();
                context.Exception = null;
                context.ExceptionHandled = true;
            }

I keep getting empty result back

I think I was confused by csproj, I changed:
<RuntimeFrameworkVersion>1.1.1</RuntimeFrameworkVersion>
to
<RuntimeFrameworkVersion>1.1.2</RuntimeFrameworkVersion>
Instead, of course one must update this line:
<PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="1.1.1" />
to
<PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="1.1.2" />


Updating from 2.0.1 (22.9.1 upstream) to 2.0.2 (22.10.1 upstream) fails

Updating gives this error message:
Reply: Command failed: docker-compose -f /usr/src/app/dnp_repo/teku.dnp.dappnode.eth/docker-compose.yml up --detach <&- Container DAppNodePackage-validator.teku.dnp.dappnode.eth Starting Container DAppNodePackage-beacon-chain.teku.dnp.dappnode.eth Starting Container DAppNodePackage-beacon-chain.teku.dnp.dappnode.eth Started Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: exec: "entrypoint.sh": executable file not found in $PATH: unknown

Please go to discord for technical support, but this issue has already been resolved so I'm going to close this.  Sorry for the inconvenience.


AttributeError: module 'webcolors' has no attribute 'CSS3_HEX_TO_NAMES'

Hello,
I'm trying to run Tikzplotlib in Jupyter with Python 3.11 and I get the following error:
...
File ~/anaconda3/lib/python3.11/site-packages/tikzplotlib/_save.py:213, in get_tikz_code(figure, filepath, ...)
    [210] _print_pgfplot_libs_message(data)
    [212] # gather the file content
--> [213] data, content = _recurse(data, figure)
    [215] # Check if there is still an open groupplot environment. This occurs if not
    [216] # all of the group plot slots are used.
...
---> [32] for h, name in webcolors.CSS3_HEX_TO_NAMES.items():
     [33]     r = int(h[1:3], 16)
     [34]     g = int(h[3:5], 16)

AttributeError: module 'webcolors' has no attribute 'CSS3_HEX_TO_NAMES'

I realized that this could be a compatibility problem with the webcolors package. I downgraded it from version 24.6 (latest available as of now) to 1.5, where the function CSS3_HEX_TO_NAMES seems to exist, but still no success. Is there a workaround for this?
Also, it would be great to know what are the latest versions of the dependencies of Tikzplotlib for which it works properly (matplotlib, numpy, Pillow, webcolors), given that the development is stalled for the time being. Where can I look at that? I hope Tikzplotlib comes back to life, it's an amazing and useful tool!

The mapping is an internal API nowadays, starting at version 24.6.0: https://github.com/ubernostrum/webcolors/commit/68ba427417b6065684a162f1484c45886a401a85 Thus using pip install "webcolors<24.6.0" should work.
Version 1.5 works for me as well. Please ensure that you are not mixing up the version installed in your Conda environment with the one installed outside of it.

Thanks for the insight, makes total sense. How terrible is this for tikzplotlib? Will anyone installing it –starting two weeks ago– have problems with it (assuming the latest versions of all dependencies)?
Regarding the mixing up of environments, that might be my case, thanks for pointing it out.

There are known limitations with matplotlib already (see the other issues and PRs), requiring version < 3.6.0. For Pillow and numpy, I am not aware of any reports. And yes, this will affect users with recent webcolors installations as well.

Ok, I see, problems with Matplotlib, as in Tikzplotlib. Thanks!

I solved changing the code def _get_closest_colour_name(rgb): as following:
`def _get_closest_colour_name(rgb):
match = None
mindiff = 1.0e15
for name in webcolors.names("css3"):
    intrgb = webcolors.name_to_rgb(name)

    diff = (rgb[0] - intrgb.red) ** 2 + (rgb[1] - intrgb.green) ** 2 + (rgb[2] - intrgb.blue) ** 2
    if diff < mindiff:
        match = name
        mindiff = diff

    if mindiff == 0:
        break

return match, mindiff`


Update setup.py

ref https://stackoverflow.com/questions/14399534/reference-requirements-txt-for-the-install-requires-kwarg-in-setuptools-setup-py#comment63662558_16624700

I added this
    install_requires=[
        'django-formtools>=2.0',
        'django-model-utils>=3.0',
    ],

to setup.py and removed this lines from requirements.txt, and it worked, but like,
the install took 100x as long as it normally does, and was hanging most of that time


[Bug] Cannot install "AVP-Textures" for "Astronomers Visual Pack"

Background

Operating System: Win10 Pro
CKAN Version: 1.27.2
KSP Version: <IP_ADDRESS>88

Have you made any manual changes to your GameData folder (i.e., not via CKAN)?
Yes, but not with this mod.
Problem

AstronomersVisualPack 2:v4.04 depends on AVP-Textures, which is not compatible with the currently installed version of KSP

AVP-2kTextures v1.11 depends on AstronomersVisualPack, which is not compatible with the currently installed version of KSP
AVP-4kTextures v1.11 depends on AstronomersVisualPack, which is not compatible with the currently installed version of KSP
AVP-8kTextures v1.11 depends on AstronomersVisualPack, which is not compatible with the currently installed version of KSP

My guess is that they are going into some kind of cyclical dependency, which is why CKAN can't properly handle their "Max KSP version".

No, it's the EVE dependency. Check the relationships tab.

I apologize for forgetting to clarify: I allowed CKAN to install modifications starting from KSP v1.8 and up to 1.9.1

When I try that, it installs without any problems and the relationships look fine.

@Artemonim, what other mods do you have installed? Maybe one of them has a conflict with AVP (notably JNSQ has this).

It turned out that first you had to put the EVE Stock Config on deletion, apply it, and only then try to install AVP. I tried to do it together and here it is.
Desktop 2020.06.15 - <IP_ADDRESS>.zip
Check whether "Environmental Visual Enhancements-HR" is written correctly in the CKAN and in "AstronomersVisualPack" conflicts section.

Yup, they're correct. Glad you got it working!


[plugin] API Billing

first version with just a Stripe connection.

:+1:

How do your customers typically integrate Gelato with billing?  I see that you support dev on boarding which is great to get people on and start playing with the API however our data providers charge us for accessing data and so for the customer to use real data they would need to purchase a credit package and be assigned an API key.  I am looking at Chargify as a possible billing solution, do you have anyone else integrating Gelato with Chargify or have any other reference cases I can use?

Billing plugin for Kong people asking for that in Gelato support

Any news regarding an open-source billing plugin for Kong?

Just wanted to say that we researched using Kong for our API, but lack of payment integration is a show-stopper for us :/

Agreed... Even if this can be considered as a portal feature and not really a gateway one, this is definitely something missing in Kong.

We need this feature.

How are Kong users dealing with the issue currently?

For simple pricing cases, it's enough to set rate limits and analyze logs against specific usage patterns. It's possible to feed Kong's logs into ElasticSearch (for example) and do periodic processing to determine usage and trigger actions. Alternatively, it's possible to derive metrics from logs into some time-series DB too and trigger actions to produce invoices out of it.
Let's discuss what would be most common pricing schemes because billing is always about usage->$ formula.

thanks a lot for your hints! @dobrych

@dobrych the API we are currently working on will have different payment plans. As you already mentioned we are planning to restrict a user of a plan to a specfic ACL (most basic use case: n requests for x $). When the user signs up (probably going to use gelato) he/she will have to either pay a monthly one-time fee or subscribe to the plan. I was wondering which service/plugin Kong users would suggest to achieve this payment step?