Error during build

Hi,
I cloned the github version on the main branch, and then executed the following command make all-full CC="8.0" TRAIN_NAME=train_cu102, but I got the following error:
DOCKER_BUILDKIT=1 docker build \
	--target build-install \
	--tag pytorch_source:build_install-ubuntu18.04-cuda10.2-cudnn8-py3.9 \
	--build-arg LINUX_DISTRO=ubuntu \
	--build-arg DISTRO_VERSION=18.04 \
	--build-arg CUDA_VERSION=10.2 \
	--build-arg CUDNN_VERSION=8 \
	--build-arg MAGMA_VERSION=102   \
	--build-arg PYTHON_VERSION=3.9 \
	--build-arg BUILDKIT_INLINE_CACHE=1 \
	- < Dockerfile
[+] Building 0.7s (21/21) FINISHED
 => [internal] load build definition from Dockerfile                                                0.0s
 => => transferring dockerfile: 12.61kB                                                             0.0s
 => [internal] load .dockerignore                                                                   0.0s
 => => transferring context: 2B                                                                     0.0s
 => resolve image config for docker.io/docker/dockerfile:1.3.0-labs                                 0.4s
 => CACHED docker-image://docker.io/docker/dockerfile:1.3.0-labs@sha256:03ca0e50aa4b6e76365fa9a560  0.0s
 => [internal] load build definition from Dockerfile                                                0.0s
 => [internal] load .dockerignore                                                                   0.0s
 => [internal] load metadata for docker.io/nvidia/cuda:10.2-cudnn8-devel-ubuntu18.04                0.0s
 => [build-base-ubuntu 1/3] FROM docker.io/nvidia/cuda:10.2-cudnn8-devel-ubuntu18.04                0.0s
 => CACHED [build-base-ubuntu 2/3] RUN rm -f /etc/apt/apt.conf.d/docker-clean;     echo 'Binary::a  0.0s
 => CACHED [build-base-ubuntu 3/3] RUN --mount=type=cache,id=apt-cache-build,target=/var/cache/apt  0.0s
 => CACHED [build-base 1/3] RUN /usr/sbin/update-ccache-symlinks                                    0.0s
 => CACHED [build-base 2/3] RUN mkdir /opt/ccache && ccache --set-config=cache_dir=/opt/ccache &&   0.0s
 => CACHED [build-base 3/3] RUN curl -fsSL -v -o ~/miniconda.sh -O  https://repo.anaconda.com/mini  0.0s
 => CACHED [build-install 1/6] RUN --mount=type=cache,id=conda-build,target=/opt/conda/pkgs     co  0.0s
 => CACHED [build-install 2/6] WORKDIR /opt                                                         0.0s
 => CACHED [build-install 3/6] RUN git clone --recursive --jobs 0 https://github.com/pytorch/pytor  0.0s
 => CACHED [build-install 4/6] RUN git clone --recursive --jobs 0 https://github.com/pytorch/visio  0.0s
 => CACHED [build-install 5/6] RUN git clone --recursive --jobs 0 https://github.com/pytorch/text.  0.0s
 => CACHED [build-install 6/6] RUN git clone --recursive --jobs 0 https://github.com/pytorch/audio  0.0s
 => exporting to image                                                                              0.0s
 => => exporting layers                                                                             0.0s
 => => writing image sha256:81330a777d1f8a68c315ec6f1859c16ea71076ebd84a5c0bbd88fa6a333949b5        0.0s
 => => naming to docker.io/library/pytorch_source:build_install-ubuntu18.04-cuda10.2-cudnn8-py3.9   0.0s
 => exporting cache                                                                                0.0s
 => => preparing build cache for export                                                             0.0s
DOCKER_BUILDKIT=1 docker build \
	--target train-builds \
	--cache-from=pytorch_source:build_install-ubuntu18.04-cuda10.2-cudnn8-py3.9 \
	--tag pytorch_source:build_torch-v1.9.1-ubuntu18.04-cuda10.2-cudnn8-py3.9 \
	--build-arg TORCH_CUDA_ARCH_LIST="8.0" \
	--build-arg PYTORCH_VERSION_TAG=v1.9.1 \
	--build-arg TORCHVISION_VERSION_TAG=v0.10.1 \
	--build-arg TORCHTEXT_VERSION_TAG=v0.10.1 \
	--build-arg TORCHAUDIO_VERSION_TAG=v0.9.1 \
	--build-arg LINUX_DISTRO=ubuntu \
	--build-arg DISTRO_VERSION=18.04 \
	--build-arg CUDA_VERSION=10.2 \
	--build-arg CUDNN_VERSION=8 \
	--build-arg MAGMA_VERSION=102   \
	--build-arg PYTHON_VERSION=3.9 \
	--build-arg BUILDKIT_INLINE_CACHE=1 \
	- < Dockerfile
[+] Building 29.1s (24/37)
 => [internal] load build definition from Dockerfile                                                0.0s
 => => transferring dockerfile: 12.61kB                                                             0.0s
 => [internal] load .dockerignore                                                                   0.0s
 => => transferring context: 2B                                                                     0.0s
 => resolve image config for docker.io/docker/dockerfile:1.3.0-labs                                 0.5s
 => CACHED docker-image://docker.io/docker/dockerfile:1.3.0-labs@sha256:03ca0e50aa4b6e76365fa9a560  0.0s
 => [internal] load build definition from Dockerfile                                                0.0s
 => [internal] load .dockerignore                                                                   0.0s
 => [internal] load metadata for docker.io/nvidia/cuda:10.2-cudnn8-devel-ubuntu18.04                0.0s
 => importing cache manifest from pytorch_source:build_install-ubuntu18.04-cuda10.2-cudnn8-py3.9    0.0s
 => [train-builds 1/5] FROM docker.io/nvidia/cuda:10.2-cudnn8-devel-ubuntu18.04                     0.0s
 => CACHED [build-base-ubuntu 2/3] RUN rm -f /etc/apt/apt.conf.d/docker-clean;     echo 'Binary::a  0.0s
 => CACHED [build-base-ubuntu 3/3] RUN --mount=type=cache,id=apt-cache-build,target=/var/cache/apt  0.0s
 => CACHED [build-base 1/3] RUN /usr/sbin/update-ccache-symlinks                                    0.0s
 => CACHED [build-base 2/3] RUN mkdir /opt/ccache && ccache --set-config=cache_dir=/opt/ccache &&   0.0s
 => CACHED [build-base 3/3] RUN curl -fsSL -v -o ~/miniconda.sh -O  https://repo.anaconda.com/mini  0.0s
 => CACHED [build-install 1/6] RUN --mount=type=cache,id=conda-build,target=/opt/conda/pkgs     co  0.0s
 => CACHED [build-install 2/6] WORKDIR /opt                                                         0.0s
 => CACHED [build-install 3/6] RUN git clone --recursive --jobs 0 https://github.com/pytorch/pytor  0.0s
 => CACHED [build-install 4/6] RUN git clone --recursive --jobs 0 https://github.com/pytorch/visio  0.0s
 => CACHED [build-install 5/6] RUN git clone --recursive --jobs 0 https://github.com/pytorch/text.  0.0s
 => CACHED [build-install 6/6] RUN git clone --recursive --jobs 0 https://github.com/pytorch/audio  0.0s
 => CACHED [train-builds 2/5] COPY --from=build-install /opt/conda /opt/conda                       0.0s
 => CACHED [build-torch 1/4] WORKDIR /opt/pytorch                                                   0.0s
 => CACHED [build-torch 2/4] RUN if [ -n v1.9.1 ]; then     git checkout v1.9.1 &&     git submodu  0.0s
 => ERROR [build-torch 3/4] RUN --mount=type=cache,target=/opt/ccache     USE_CUDA=1 USE_CUDNN=1   28.3s
------
 > [build-torch 3/4] RUN --mount=type=cache,target=/opt/ccache     USE_CUDA=1 USE_CUDNN=1     TORCH_NVCC_FLAGS=-Xfatbin -compress-all     TORCH_CUDA_ARCH_LIST=8.0     CMAKE_PREFIX_PATH="$(dirname $(which conda))/../"     python setup.py bdist_wheel -d /tmp/dist:
#24 0.500 Building wheel torch-1.9.0a0+gitdfbd030
#24 0.534 -- Building version 1.9.0a0+gitdfbd030
#24 0.549 cmake -GNinja -DBUILD_PYTHON=True -DBUILD_TEST=True -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/opt/pytorch/torch -DCMAKE_PREFIX_PATH=/opt/conda/bin/../ -DNUMPY_INCLUDE_DIR=/opt/conda/lib/python3.9/site-packages/numpy/core/include -DPYTHON_EXECUTABLE=/opt/conda/bin/python -DPYTHON_INCLUDE_DIR=/opt/conda/include/python3.9 -DPYTHON_LIBRARY=/opt/conda/lib/libpython3.9.a -DTORCH_BUILD_VERSION=1.9.0a0+gitdfbd030 -DUSE_CUDA=1 -DUSE_CUDNN=1 -DUSE_NUMPY=True /opt/pytorch
#24 0.647 -- The CXX compiler identification is GNU 7.5.0
#24 0.716 -- The C compiler identification is GNU 7.5.0
#24 0.729 -- Detecting CXX compiler ABI info
#24 0.810 -- Detecting CXX compiler ABI info - done
#24 0.825 -- Check for working CXX compiler: /usr/bin/c++ - skipped
#24 0.825 -- Detecting CXX compile features
#24 0.826 -- Detecting CXX compile features - done
#24 0.829 -- Detecting C compiler ABI info
#24 0.900 -- Detecting C compiler ABI info - done
#24 0.913 -- Check for working C compiler: /usr/bin/cc - skipped
#24 0.913 -- Detecting C compile features
#24 0.915 -- Detecting C compile features - done
#24 0.916 -- Not forcing any particular BLAS to be found
#24 0.926 -- Performing Test COMPILER_WORKS
#24 1.001 -- Performing Test COMPILER_WORKS - Success
#24 1.001 -- Performing Test SUPPORT_GLIBCXX_USE_C99
#24 1.211 -- Performing Test SUPPORT_GLIBCXX_USE_C99 - Success
#24 1.212 -- Performing Test CAFFE2_EXCEPTION_PTR_SUPPORTED
#24 1.409 -- Performing Test CAFFE2_EXCEPTION_PTR_SUPPORTED - Success
#24 1.410 -- std::exception_ptr is supported.
#24 1.410 -- Performing Test CAFFE2_NEED_TO_TURN_OFF_DEPRECATION_WARNING
#24 1.446 -- Performing Test CAFFE2_NEED_TO_TURN_OFF_DEPRECATION_WARNING - Failed
#24 1.446 -- Turning off deprecation warning due to glog.
#24 1.446 -- Performing Test CAFFE2_COMPILER_SUPPORTS_AVX2_EXTENSIONS
#24 1.696 -- Performing Test CAFFE2_COMPILER_SUPPORTS_AVX2_EXTENSIONS - Success
#24 1.696 -- Current compiler supports avx2 extension. Will build perfkernels.
#24 1.697 -- Performing Test CAFFE2_COMPILER_SUPPORTS_AVX512_EXTENSIONS
#24 1.904 -- Performing Test CAFFE2_COMPILER_SUPPORTS_AVX512_EXTENSIONS - Success
#24 1.904 -- Current compiler supports avx512f extension. Will build fbgemm.
#24 1.905 -- Performing Test COMPILER_SUPPORTS_HIDDEN_VISIBILITY
#24 1.988 -- Performing Test COMPILER_SUPPORTS_HIDDEN_VISIBILITY - Success
#24 1.990 -- Performing Test COMPILER_SUPPORTS_HIDDEN_INLINE_VISIBILITY
#24 2.068 -- Performing Test COMPILER_SUPPORTS_HIDDEN_INLINE_VISIBILITY - Success
#24 2.070 -- Performing Test COMPILER_SUPPORTS_RDYNAMIC
#24 2.152 -- Performing Test COMPILER_SUPPORTS_RDYNAMIC - Success
#24 2.170 -- Building using own protobuf under third_party per request.
#24 2.170 -- Use custom protobuf build.
#24 2.171 --
#24 2.171 -- <IP_ADDRESS>
#24 2.172 -- Looking for pthread.h
#24 2.248 -- Looking for pthread.h - found
#24 2.248 -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
#24 2.327 -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
#24 2.327 -- Check if compiler accepts -pthread
#24 2.402 -- Check if compiler accepts -pthread - yes
#24 2.404 -- Found Threads: TRUE
#24 2.405 -- Performing Test protobuf_HAVE_BUILTIN_ATOMICS
#24 2.512 -- Performing Test protobuf_HAVE_BUILTIN_ATOMICS - Success
#24 2.529 -- Caffe2 protobuf include directory: $<BUILD_INTERFACE:/opt/pytorch/third_party/protobuf/src>$<INSTALL_INTERFACE:include>
#24 2.530 -- Trying to find preferred BLAS backend of choice: MKL
#24 2.531 -- MKL_THREADING = OMP
#24 2.532 -- Looking for sys/types.h
#24 2.604 -- Looking for sys/types.h - found
#24 2.605 -- Looking for stdint.h
#24 2.672 -- Looking for stdint.h - found
#24 2.673 -- Looking for stddef.h
#24 2.743 -- Looking for stddef.h - found
#24 2.743 -- Check size of void*
#24 2.816 -- Check size of void* - done
#24 3.083 CMake Warning (dev) at /opt/conda/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
#24 3.083   The package name passed to `find_package_handle_standard_args` (OpenMP_C)
#24 3.083   does not match the name of the calling package (OpenMP).  This can lead to
#24 3.083   problems in calling code that expects `find_package` result variables
#24 3.083   (e.g., `_FOUND`) to follow a certain pattern.
#24 3.083 Call Stack (most recent call first):
#24 3.083   cmake/Modules/FindOpenMP.cmake:576 (find_package_handle_standard_args)
#24 3.083   cmake/Modules/FindMKL.cmake:213 (FIND_PACKAGE)
#24 3.083   cmake/Modules/FindMKL.cmake:307 (CHECK_ALL_LIBRARIES)
#24 3.083   cmake/Dependencies.cmake:144 (find_package)
#24 3.083   CMakeLists.txt:621 (include)
#24 3.083 This warning is for project developers.  Use -Wno-dev to suppress it.
#24 3.083
#24 3.167 CMake Warning (dev) at /opt/conda/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
#24 3.167   The package name passed to `find_package_handle_standard_args` (OpenMP_CXX)
#24 3.167   does not match the name of the calling package (OpenMP).  This can lead to
#24 3.167   problems in calling code that expects `find_package` result variables
#24 3.167   (e.g., `_FOUND`) to follow a certain pattern.
#24 3.167 Call Stack (most recent call first):
#24 3.167   cmake/Modules/FindOpenMP.cmake:576 (find_package_handle_standard_args)
#24 3.167   cmake/Modules/FindMKL.cmake:213 (FIND_PACKAGE)
#24 3.167   cmake/Modules/FindMKL.cmake:307 (CHECK_ALL_LIBRARIES)
#24 3.167   cmake/Dependencies.cmake:144 (find_package)
#24 3.167   CMakeLists.txt:621 (include)
#24 3.167 This warning is for project developers.  Use -Wno-dev to suppress it.
#24 3.167
#24 3.172 -- Looking for cblas_sgemm
#24 3.420 -- Looking for cblas_sgemm - found
#24 3.426 -- MKL libraries: /opt/conda/lib/libmkl_intel_lp64.so;/opt/conda/lib/libmkl_gnu_thread.so;/opt/conda/lib/libmkl_core.so;-fopenmp;/usr/lib/x86_64-linux-gnu/libpthread.so;/usr/lib/x86_64-linux-gnu/libm.so;/usr/lib/x86_64-linux-gnu/libdl.so
#24 3.426 -- MKL include directory: /opt/conda/include
#24 3.426 -- MKL OpenMP type: GNU
#24 3.426 -- MKL OpenMP library: -fopenmp
#24 3.449 -- The ASM compiler identification is GNU
#24 3.452 -- Found assembler: /usr/bin/cc
#24 3.467 -- Brace yourself, we are building NNPACK
#24 3.471 -- Performing Test NNPACK_ARCH_IS_X86_32
#24 3.506 -- Performing Test NNPACK_ARCH_IS_X86_32 - Failed
#24 3.529 -- Found PythonInterp: /opt/conda/bin/python (found version "3.9.7")
#24 3.529 -- NNPACK backend is x86-64
#24 3.553 CMake Deprecation Warning at third_party/googletest/CMakeLists.txt:1 (cmake_minimum_required):
#24 3.553   Compatibility with CMake < 2.8.12 will be removed from a future version of
#24 3.553   CMake.
#24 3.553
#24 3.553   Update the VERSION argument <min> value or use a ...<max> suffix to tell
#24 3.553   CMake that the project does not need compatibility with older versions.
#24 3.553
#24 3.553
#24 3.555 CMake Deprecation Warning at third_party/googletest/googlemock/CMakeLists.txt:42 (cmake_minimum_required):
#24 3.555   Compatibility with CMake < 2.8.12 will be removed from a future version of
#24 3.555   CMake.
#24 3.555
#24 3.555   Update the VERSION argument <min> value or use a ...<max> suffix to tell
#24 3.555   CMake that the project does not need compatibility with older versions.
#24 3.555
#24 3.555
#24 3.556 CMake Deprecation Warning at third_party/googletest/googletest/CMakeLists.txt:49 (cmake_minimum_required):
#24 3.556   Compatibility with CMake < 2.8.12 will be removed from a future version of
#24 3.556   CMake.
#24 3.556
#24 3.556   Update the VERSION argument <min> value or use a ...<max> suffix to tell
#24 3.556   CMake that the project does not need compatibility with older versions.
#24 3.556
#24 3.556
#24 3.586 -- Failed to find LLVM FileCheck
#24 3.592 -- Found Git: /usr/bin/git (found version "2.17.1")
#24 3.614 -- git Version: v1.4.0-505be96a
#24 3.614 -- Version: 1.4.0
#24 3.617 -- Performing Test HAVE_CXX_FLAG_STD_CXX11
#24 3.700 -- Performing Test HAVE_CXX_FLAG_STD_CXX11 - Success
#24 3.702 -- Performing Test HAVE_CXX_FLAG_WALL
#24 3.783 -- Performing Test HAVE_CXX_FLAG_WALL - Success
#24 3.785 -- Performing Test HAVE_CXX_FLAG_WEXTRA
#24 3.868 -- Performing Test HAVE_CXX_FLAG_WEXTRA - Success
#24 3.870 -- Performing Test HAVE_CXX_FLAG_WSHADOW
#24 3.952 -- Performing Test HAVE_CXX_FLAG_WSHADOW - Success
#24 3.954 -- Performing Test HAVE_CXX_FLAG_WERROR
#24 4.031 -- Performing Test HAVE_CXX_FLAG_WERROR - Success
#24 4.033 -- Performing Test HAVE_CXX_FLAG_PEDANTIC
#24 4.112 -- Performing Test HAVE_CXX_FLAG_PEDANTIC - Success
#24 4.114 -- Performing Test HAVE_CXX_FLAG_PEDANTIC_ERRORS
#24 4.197 -- Performing Test HAVE_CXX_FLAG_PEDANTIC_ERRORS - Success
#24 4.199 -- Performing Test HAVE_CXX_FLAG_WSHORTEN_64_TO_32
#24 4.240 -- Performing Test HAVE_CXX_FLAG_WSHORTEN_64_TO_32 - Failed
#24 4.240 -- Performing Test HAVE_CXX_FLAG_WFLOAT_EQUAL
#24 4.320 -- Performing Test HAVE_CXX_FLAG_WFLOAT_EQUAL - Success
#24 4.322 -- Performing Test HAVE_CXX_FLAG_FSTRICT_ALIASING
#24 4.402 -- Performing Test HAVE_CXX_FLAG_FSTRICT_ALIASING - Success
#24 4.404 -- Performing Test HAVE_CXX_FLAG_WNO_DEPRECATED_DECLARATIONS
#24 4.484 -- Performing Test HAVE_CXX_FLAG_WNO_DEPRECATED_DECLARATIONS - Success
#24 4.486 -- Performing Test HAVE_CXX_FLAG_WSTRICT_ALIASING
#24 4.566 -- Performing Test HAVE_CXX_FLAG_WSTRICT_ALIASING - Success
#24 4.568 -- Performing Test HAVE_CXX_FLAG_WD654
#24 4.598 -- Performing Test HAVE_CXX_FLAG_WD654 - Failed
#24 4.600 -- Performing Test HAVE_CXX_FLAG_WTHREAD_SAFETY
#24 4.634 -- Performing Test HAVE_CXX_FLAG_WTHREAD_SAFETY - Failed
#24 4.635 -- Performing Test HAVE_CXX_FLAG_COVERAGE
#24 4.720 -- Performing Test HAVE_CXX_FLAG_COVERAGE - Success
#24 4.720 -- Performing Test HAVE_STD_REGEX
#24 4.720 -- Performing Test HAVE_STD_REGEX
#24 6.312 -- Performing Test HAVE_STD_REGEX -- success
#24 6.312 -- Performing Test HAVE_GNU_POSIX_REGEX
#24 6.312 -- Performing Test HAVE_GNU_POSIX_REGEX
#24 6.350 -- Performing Test HAVE_GNU_POSIX_REGEX -- failed to compile
#24 6.350 -- Performing Test HAVE_POSIX_REGEX
#24 6.350 -- Performing Test HAVE_POSIX_REGEX
#24 6.543 -- Performing Test HAVE_POSIX_REGEX -- success
#24 6.543 -- Performing Test HAVE_STEADY_CLOCK
#24 6.543 -- Performing Test HAVE_STEADY_CLOCK
#24 6.681 -- Performing Test HAVE_STEADY_CLOCK -- success
#24 6.714 -- Performing Test COMPILER_SUPPORTS_AVX512
#24 6.798 -- Performing Test COMPILER_SUPPORTS_AVX512 - Success
#24 6.802 CMake Warning (dev) at /opt/conda/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
#24 6.802   The package name passed to `find_package_handle_standard_args` (OpenMP_C)
#24 6.802   does not match the name of the calling package (OpenMP).  This can lead to
#24 6.802   problems in calling code that expects `find_package` result variables
#24 6.802   (e.g., `_FOUND`) to follow a certain pattern.
#24 6.802 Call Stack (most recent call first):
#24 6.802   cmake/Modules/FindOpenMP.cmake:576 (find_package_handle_standard_args)
#24 6.802   third_party/fbgemm/CMakeLists.txt:60 (find_package)
#24 6.802 This warning is for project developers.  Use -Wno-dev to suppress it.
#24 6.802
#24 6.803 -- Found OpenMP_C: -fopenmp (found version "4.5")
#24 6.803 CMake Warning (dev) at /opt/conda/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
#24 6.803   The package name passed to `find_package_handle_standard_args` (OpenMP_CXX)
#24 6.803   does not match the name of the calling package (OpenMP).  This can lead to
#24 6.803   problems in calling code that expects `find_package` result variables
#24 6.803   (e.g., `_FOUND`) to follow a certain pattern.
#24 6.803 Call Stack (most recent call first):
#24 6.803   cmake/Modules/FindOpenMP.cmake:576 (find_package_handle_standard_args)
#24 6.803   third_party/fbgemm/CMakeLists.txt:60 (find_package)
#24 6.803 This warning is for project developers.  Use -Wno-dev to suppress it.
#24 6.803
#24 6.804 -- Found OpenMP_CXX: -fopenmp (found version "4.5")
#24 6.804 -- Found OpenMP: TRUE (found version "4.5")
#24 6.804 CMake Warning at third_party/fbgemm/CMakeLists.txt:62 (message):
#24 6.804   OpenMP found! OpenMP_C_INCLUDE_DIRS =
#24 6.804
#24 6.804
#24 6.916 CMake Warning at third_party/fbgemm/CMakeLists.txt:142 (message):
#24 6.916   ==========
#24 6.916
#24 6.916
#24 6.916 CMake Warning at third_party/fbgemm/CMakeLists.txt:143 (message):
#24 6.916   CMAKE_BUILD_TYPE = Release
#24 6.916
#24 6.916
#24 6.916 CMake Warning at third_party/fbgemm/CMakeLists.txt:144 (message):
#24 6.916   CMAKE_CXX_FLAGS_DEBUG is -g
#24 6.916
#24 6.916
#24 6.916 CMake Warning at third_party/fbgemm/CMakeLists.txt:145 (message):
#24 6.916   CMAKE_CXX_FLAGS_RELEASE is -O3 -DNDEBUG
#24 6.916
#24 6.916
#24 6.916 CMake Warning at third_party/fbgemm/CMakeLists.txt:146 (message):
#24 6.916   ==========
#24 6.916
#24 6.916
#24 6.923 -- Performing Test __CxxFlag__fno_threadsafe_statics
#24 7.006 -- Performing Test __CxxFlag__fno_threadsafe_statics - Success
#24 7.008 -- Performing Test __CxxFlag__fno_semantic_interposition
#24 7.087 -- Performing Test __CxxFlag__fno_semantic_interposition - Success
#24 7.088 -- Performing Test __CxxFlag__fmerge_all_constants
#24 7.172 -- Performing Test __CxxFlag__fmerge_all_constants - Success
#24 7.174 -- Performing Test __CxxFlag__fno_enforce_eh_specs
#24 7.254 -- Performing Test __CxxFlag__fno_enforce_eh_specs - Success
#24 7.258 ** AsmJit Summary **
#24 7.258    ASMJIT_DIR=/opt/pytorch/third_party/fbgemm/third_party/asmjit
#24 7.258    ASMJIT_TEST=FALSE
#24 7.258    ASMJIT_TARGET_TYPE=STATIC
#24 7.258    ASMJIT_DEPS=pthread;rt
#24 7.258    ASMJIT_LIBS=asmjit;pthread;rt
#24 7.258    ASMJIT_CFLAGS=-DASMJIT_STATIC
#24 7.258    ASMJIT_PRIVATE_CFLAGS=-Wall;-Wextra;-Wconversion;-fno-math-errno;-fno-threadsafe-statics;-fno-semantic-interposition;-DASMJIT_STATIC
#24 7.258    ASMJIT_PRIVATE_CFLAGS_DBG=
#24 7.258    ASMJIT_PRIVATE_CFLAGS_REL=-O2;-fmerge-all-constants;-fno-enforce-eh-specs
#24 7.267 CMake Warning at cmake/Dependencies.cmake:793 (message):
#24 7.267   Not compiling with NUMA.  Suppress this warning with -DUSE_NUMA=OFF
#24 7.267 Call Stack (most recent call first):
#24 7.267   CMakeLists.txt:621 (include)
#24 7.267
#24 7.267
#24 7.267 -- Could NOT find Numa (missing: Numa_INCLUDE_DIR Numa_LIBRARIES)
#24 7.268 -- Using third party subdirectory Eigen.
#24 7.291 -- Found PythonInterp: /opt/conda/bin/python (found suitable version "3.9.7", minimum required is "3.0")
#24 7.296 -- Found PythonLibs: /opt/conda/lib/libpython3.9.a (found suitable version "3.9.7", minimum required is "3.0")
#24 7.301 -- Could NOT find pybind11 (missing: pybind11_DIR)
#24 7.302 -- Could NOT find pybind11 (missing: pybind11_INCLUDE_DIR)
#24 7.302 -- Using third_party/pybind11.
#24 7.303 -- pybind11 include dirs: /opt/pytorch/cmake/../third_party/pybind11/include
#24 7.426 -- Could NOT find MPI_C (missing: MPI_C_LIB_NAMES MPI_C_HEADER_DIR MPI_C_WORKS)
#24 7.506 -- Could NOT find MPI_CXX (missing: MPI_CXX_LIB_NAMES MPI_CXX_HEADER_DIR MPI_CXX_WORKS)
#24 7.507 -- Could NOT find MPI (missing: MPI_C_FOUND MPI_CXX_FOUND)
#24 7.507     Reason given by package: MPI component 'Fortran' was requested, but language Fortran is not enabled.
#24 7.507
#24 7.507 CMake Warning at cmake/Dependencies.cmake:1050 (message):
#24 7.507   Not compiling with MPI.  Suppress this warning with -DUSE_MPI=OFF
#24 7.507 Call Stack (most recent call first):
#24 7.507   CMakeLists.txt:621 (include)
#24 7.507
#24 7.507
#24 7.509 CMake Warning (dev) at /opt/conda/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
#24 7.509   The package name passed to `find_package_handle_standard_args` (OpenMP_C)
#24 7.509   does not match the name of the calling package (OpenMP).  This can lead to
#24 7.509   problems in calling code that expects `find_package` result variables
#24 7.509   (e.g., `_FOUND`) to follow a certain pattern.
#24 7.509 Call Stack (most recent call first):
#24 7.509   cmake/Modules/FindOpenMP.cmake:576 (find_package_handle_standard_args)
#24 7.509   cmake/Dependencies.cmake:1105 (find_package)
#24 7.509   CMakeLists.txt:621 (include)
#24 7.509 This warning is for project developers.  Use -Wno-dev to suppress it.
#24 7.509
#24 7.509 CMake Warning (dev) at /opt/conda/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
#24 7.509   The package name passed to `find_package_handle_standard_args` (OpenMP_CXX)
#24 7.509   does not match the name of the calling package (OpenMP).  This can lead to
#24 7.509   problems in calling code that expects `find_package` result variables
#24 7.509   (e.g., `_FOUND`) to follow a certain pattern.
#24 7.509 Call Stack (most recent call first):
#24 7.509   cmake/Modules/FindOpenMP.cmake:576 (find_package_handle_standard_args)
#24 7.509   cmake/Dependencies.cmake:1105 (find_package)
#24 7.509   CMakeLists.txt:621 (include)
#24 7.509 This warning is for project developers.  Use -Wno-dev to suppress it.
#24 7.509
#24 7.510 -- Adding OpenMP CXX_FLAGS: -fopenmp
#24 7.510 -- Will link against OpenMP libraries: /usr/lib/gcc/x86_64-linux-gnu/7/libgomp.so;/usr/lib/x86_64-linux-gnu/libpthread.so
#24 7.523 -- Found CUDA: /usr/local/cuda (found version "10.2")
#24 7.525 -- Caffe2: CUDA detected: 10.2
#24 7.525 -- Caffe2: CUDA nvcc is: /usr/local/cuda/bin/nvcc
#24 7.525 -- Caffe2: CUDA toolkit directory: /usr/local/cuda
#24 7.628 -- Caffe2: Header version is: 10.2
#24 7.633 -- Found CUDNN: /usr/lib/x86_64-linux-gnu/libcudnn.so
#24 7.633 -- Found cuDNN: v8.2.0  (include: /usr/include, library: /usr/lib/x86_64-linux-gnu/libcudnn.so)
#24 7.677 -- /usr/local/cuda/lib64/libnvrtc.so shorthash is 08c4863f
#24 7.678 CMake Warning at cmake/public/utils.cmake:365 (message):
#24 7.678   In the future we will require one to explicitly pass TORCH_CUDA_ARCH_LIST
#24 7.678   to cmake instead of implicitly setting it as an env variable.  This will
#24 7.678   become a FATAL_ERROR in future version of pytorch.
#24 7.678 Call Stack (most recent call first):
#24 7.678   cmake/public/cuda.cmake:511 (torch_cuda_get_nvcc_gencode_flag)
#24 7.678   cmake/Dependencies.cmake:1155 (include)
#24 7.678   CMakeLists.txt:621 (include)
#24 7.678
#24 7.678
#24 7.679 -- Added CUDA NVCC flags for: -gencode;arch=compute_80,code=sm_80
#24 7.680 CMake Warning at cmake/public/utils.cmake:365 (message):
#24 7.680   In the future we will require one to explicitly pass TORCH_CUDA_ARCH_LIST
#24 7.680   to cmake instead of implicitly setting it as an env variable.  This will
#24 7.680   become a FATAL_ERROR in future version of pytorch.
#24 7.680 Call Stack (most recent call first):
#24 7.680   cmake/External/nccl.cmake:13 (torch_cuda_get_nvcc_gencode_flag)
#24 7.680   cmake/Dependencies.cmake:1288 (include)
#24 7.680   CMakeLists.txt:621 (include)
#24 7.680
#24 7.680
#24 7.698 CMake Warning at cmake/External/nccl.cmake:62 (message):
#24 7.698   Objcopy version is too old to support NCCL library slimming
#24 7.698 Call Stack (most recent call first):
#24 7.698   cmake/Dependencies.cmake:1288 (include)
#24 7.698   CMakeLists.txt:621 (include)
#24 7.698
#24 7.698
#24 7.700 -- Could NOT find CUB (missing: CUB_INCLUDE_DIR)
#24 7.703 CMake Warning (dev) at third_party/gloo/CMakeLists.txt:21 (option):
#24 7.703   Policy CMP0077 is not set: option() honors normal variables.  Run "cmake
#24 7.703   --help-policy CMP0077" for policy details.  Use the cmake_policy command to
#24 7.703   set the policy and suppress this warning.
#24 7.703
#24 7.703   For compatibility with older versions of CMake, option is clearing the
#24 7.703   normal variable 'BUILD_BENCHMARK'.
#24 7.703 This warning is for project developers.  Use -Wno-dev to suppress it.
#24 7.703
#24 7.703 -- Gloo build as SHARED library
#24 7.711 -- Found CUDA: /usr/local/cuda (found suitable version "10.2", minimum required is "7.0")
#24 7.712 -- CUDA detected: 10.2
#24 7.714 CMake Warning (dev) at /opt/conda/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
#24 7.714   The package name passed to `find_package_handle_standard_args` (NCCL) does
#24 7.714   not match the name of the calling package (nccl).  This can lead to
#24 7.714   problems in calling code that expects `find_package` result variables
#24 7.714   (e.g., `_FOUND`) to follow a certain pattern.
#24 7.714 Call Stack (most recent call first):
#24 7.714   third_party/gloo/cmake/Modules/Findnccl.cmake:45 (find_package_handle_standard_args)
#24 7.714   third_party/gloo/cmake/Dependencies.cmake:128 (find_package)
#24 7.714   third_party/gloo/CMakeLists.txt:109 (include)
#24 7.714 This warning is for project developers.  Use -Wno-dev to suppress it.
#24 7.714
#24 7.714 -- Found NCCL: /usr/include
#24 7.714 -- Determining NCCL version from the header file: /usr/include/nccl.h
#24 7.714 -- NCCL_MAJOR_VERSION: 2
#24 7.714 -- Found NCCL (include: /usr/include, library: /usr/lib/x86_64-linux-gnu/libnccl.so)
#24 7.733 -- Found CUDA: /usr/local/cuda (found version "10.2")
#24 7.779 -- Performing Test UV_LINT_W4
#24 7.806 -- Performing Test UV_LINT_W4 - Failed
#24 7.808 -- Performing Test UV_LINT_NO_UNUSED_PARAMETER_MSVC
#24 7.836 -- Performing Test UV_LINT_NO_UNUSED_PARAMETER_MSVC - Failed
#24 7.837 -- Performing Test UV_LINT_NO_CONDITIONAL_CONSTANT_MSVC
#24 7.866 -- Performing Test UV_LINT_NO_CONDITIONAL_CONSTANT_MSVC - Failed
#24 7.867 -- Performing Test UV_LINT_NO_NONSTANDARD_MSVC
#24 7.895 -- Performing Test UV_LINT_NO_NONSTANDARD_MSVC - Failed
#24 7.896 -- Performing Test UV_LINT_NO_NONSTANDARD_EMPTY_TU_MSVC
#24 7.923 -- Performing Test UV_LINT_NO_NONSTANDARD_EMPTY_TU_MSVC - Failed
#24 7.924 -- Performing Test UV_LINT_NO_NONSTANDARD_FILE_SCOPE_MSVC
#24 7.951 -- Performing Test UV_LINT_NO_NONSTANDARD_FILE_SCOPE_MSVC - Failed
#24 7.953 -- Performing Test UV_LINT_NO_NONSTANDARD_NONSTATIC_DLIMPORT_MSVC
#24 7.979 -- Performing Test UV_LINT_NO_NONSTANDARD_NONSTATIC_DLIMPORT_MSVC - Failed
#24 7.981 -- Performing Test UV_LINT_NO_HIDES_LOCAL
#24 8.006 -- Performing Test UV_LINT_NO_HIDES_LOCAL - Failed
#24 8.008 -- Performing Test UV_LINT_NO_HIDES_PARAM
#24 8.034 -- Performing Test UV_LINT_NO_HIDES_PARAM - Failed
#24 8.036 -- Performing Test UV_LINT_NO_HIDES_GLOBAL
#24 8.061 -- Performing Test UV_LINT_NO_HIDES_GLOBAL - Failed
#24 8.063 -- Performing Test UV_LINT_NO_CONDITIONAL_ASSIGNMENT_MSVC
#24 8.091 -- Performing Test UV_LINT_NO_CONDITIONAL_ASSIGNMENT_MSVC - Failed
#24 8.092 -- Performing Test UV_LINT_NO_UNSAFE_MSVC
#24 8.117 -- Performing Test UV_LINT_NO_UNSAFE_MSVC - Failed
#24 8.118 -- Performing Test UV_LINT_WALL
#24 8.190 -- Performing Test UV_LINT_WALL - Success
#24 8.192 -- Performing Test UV_LINT_NO_UNUSED_PARAMETER
#24 8.263 -- Performing Test UV_LINT_NO_UNUSED_PARAMETER - Success
#24 8.265 -- Performing Test UV_LINT_STRICT_PROTOTYPES
#24 8.340 -- Performing Test UV_LINT_STRICT_PROTOTYPES - Success
#24 8.341 -- Performing Test UV_LINT_EXTRA
#24 8.414 -- Performing Test UV_LINT_EXTRA - Success
#24 8.416 -- Performing Test UV_LINT_UTF8_MSVC
#24 8.440 -- Performing Test UV_LINT_UTF8_MSVC - Failed
#24 8.442 -- Performing Test UV_F_STRICT_ALIASING
#24 8.512 -- Performing Test UV_F_STRICT_ALIASING - Success
#24 8.514 -- summary of build options:
#24 8.514     Install prefix:  /opt/pytorch/torch
#24 8.514     Target system:   Linux
#24 8.514     Compiler:
#24 8.514       C compiler:    /usr/bin/cc
#24 8.514       CFLAGS:          -fopenmp
#24 8.514
#24 8.517 -- Found uv: 1.38.1 (found version "1.38.1")
#24 8.519 CMake Warning at cmake/Dependencies.cmake:1406 (message):
#24 8.519   Metal is only used in ios builds.
#24 8.519 Call Stack (most recent call first):
#24 8.519   CMakeLists.txt:621 (include)
#24 8.519
#24 8.519
#24 8.522 Generated: /opt/pytorch/build/third_party/onnx/onnx/onnx_onnx_torch-ml.proto
#24 8.522 Generated: /opt/pytorch/build/third_party/onnx/onnx/onnx-operators_onnx_torch-ml.proto
#24 8.523 Generated: /opt/pytorch/build/third_party/onnx/onnx/onnx-data_onnx_torch.proto
#24 8.626 --
#24 8.626 -- ******** Summary ********
#24 8.626 --   CMake version         : 3.19.6
#24 8.626 --   CMake command         : /opt/conda/bin/cmake
#24 8.626 --   System                : Linux
#24 8.626 --   C++ compiler          : /usr/bin/c++
#24 8.626 --   C++ compiler version  : 7.5.0
#24 8.626 --   CXX flags             :  -Wno-deprecated -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -fopenmp -Wnon-virtual-dtor
#24 8.626 --   Build type            : Release
#24 8.626 --   Compile definitions   : TH_BLAS_MKL;ONNX_ML=1;ONNXIFI_ENABLE_EXT=1
#24 8.626 --   CMAKE_PREFIX_PATH     : /opt/conda/bin/../;/usr/local/cuda
#24 8.626 --   CMAKE_INSTALL_PREFIX  : /opt/pytorch/torch
#24 8.626 --   CMAKE_MODULE_PATH     : /opt/pytorch/cmake/Modules;/opt/pytorch/cmake/public/../Modules_CUDA_fix
#24 8.626 --
#24 8.626 --   ONNX version          : 1.8.0
#24 8.626 --   ONNX NAMESPACE        : onnx_torch
#24 8.626 --   ONNX_BUILD_TESTS      : OFF
#24 8.626 --   ONNX_BUILD_BENCHMARKS : OFF
#24 8.626 --   ONNX_USE_LITE_PROTO   : OFF
#24 8.626 --   ONNXIFI_DUMMY_BACKEND : OFF
#24 8.626 --   ONNXIFI_ENABLE_EXT    : OFF
#24 8.626 --
#24 8.626 --   Protobuf compiler     :
#24 8.626 --   Protobuf includes     :
#24 8.626 --   Protobuf libraries    :
#24 8.626 --   BUILD_ONNX_PYTHON     : OFF
#24 8.627 --
#24 8.627 -- ******** Summary ********
#24 8.627 --   CMake version         : 3.19.6
#24 8.627 --   CMake command         : /opt/conda/bin/cmake
#24 8.627 --   System                : Linux
#24 8.627 --   C++ compiler          : /usr/bin/c++
#24 8.627 --   C++ compiler version  : 7.5.0
#24 8.627 --   CXX flags             :  -Wno-deprecated -fvisibility-inlines-hidden -DUSE_PTHREADPOOL -fopenmp -Wnon-virtual-dtor
#24 8.627 --   Build type            : Release
#24 8.627 --   Compile definitions   : TH_BLAS_MKL;ONNX_ML=1;ONNXIFI_ENABLE_EXT=1
#24 8.627 --   CMAKE_PREFIX_PATH     : /opt/conda/bin/../;/usr/local/cuda
#24 8.627 --   CMAKE_INSTALL_PREFIX  : /opt/pytorch/torch
#24 8.627 --   CMAKE_MODULE_PATH     : /opt/pytorch/cmake/Modules;/opt/pytorch/cmake/public/../Modules_CUDA_fix
#24 8.627 --
#24 8.627 --   ONNX version          : 1.4.1
#24 8.627 --   ONNX NAMESPACE        : onnx_torch
#24 8.627 --   ONNX_BUILD_TESTS      : OFF
#24 8.627 --   ONNX_BUILD_BENCHMARKS : OFF
#24 8.627 --   ONNX_USE_LITE_PROTO   : OFF
#24 8.627 --   ONNXIFI_DUMMY_BACKEND : OFF
#24 8.627 --
#24 8.627 --   Protobuf compiler     :
#24 8.627 --   Protobuf includes     :
#24 8.627 --   Protobuf libraries    :
#24 8.627 --   BUILD_ONNX_PYTHON     : OFF
#24 8.628 -- Found CUDA with FP16 support, compiling with torch.cuda.HalfTensor
#24 8.628 -- Adding -DNDEBUG to compile flags
#24 8.629 -- Checking prototype magma_get_sgeqrf_nb for MAGMA_V2
#24 8.755 -- Checking prototype magma_get_sgeqrf_nb for MAGMA_V2 - True
#24 8.755 -- Compiling with MAGMA support
#24 8.755 -- MAGMA INCLUDE DIRECTORIES: /opt/conda/include
#24 8.755 -- MAGMA LIBRARIES: /opt/conda/lib/libmagma.a
#24 8.755 -- MAGMA V2 check: 1
#24 8.792 -- Could not find hardware support for NEON on this machine.
#24 8.792 -- No OMAP3 processor on this machine.
#24 8.792 -- No OMAP4 processor on this machine.
#24 8.793 -- Looking for cpuid.h
#24 8.867 -- Looking for cpuid.h - found
#24 8.868 -- Performing Test HAVE_GCC_GET_CPUID
#24 8.948 -- Performing Test HAVE_GCC_GET_CPUID - Success
#24 8.948 -- Performing Test NO_GCC_EBX_FPIC_BUG
#24 9.022 -- Performing Test NO_GCC_EBX_FPIC_BUG - Success
#24 9.022 -- <FindVSX>
#24 9.025 -- Performing Test C_VSX_FOUND
#24 9.056 -- Performing Test C_VSX_FOUND - Failed
#24 9.056 -- Performing Test CXX_VSX_FOUND
#24 9.086 -- Performing Test CXX_VSX_FOUND - Failed
#24 9.086 -- </FindVSX>
#24 9.087 -- Performing Test C_HAS_AVX_1
#24 9.215 -- Performing Test C_HAS_AVX_1 - Failed
#24 9.215 -- Performing Test C_HAS_AVX_2
#24 9.380 -- Performing Test C_HAS_AVX_2 - Success
#24 9.381 -- Performing Test C_HAS_AVX2_1
#24 9.507 -- Performing Test C_HAS_AVX2_1 - Failed
#24 9.507 -- Performing Test C_HAS_AVX2_2
#24 9.665 -- Performing Test C_HAS_AVX2_2 - Success
#24 9.666 -- Performing Test CXX_HAS_AVX_1
#24 9.797 -- Performing Test CXX_HAS_AVX_1 - Failed
#24 9.797 -- Performing Test CXX_HAS_AVX_2
#24 9.960 -- Performing Test CXX_HAS_AVX_2 - Success
#24 9.961 -- Performing Test CXX_HAS_AVX2_1
#24 10.09 -- Performing Test CXX_HAS_AVX2_1 - Failed
#24 10.09 -- Performing Test CXX_HAS_AVX2_2
#24 10.25 -- Performing Test CXX_HAS_AVX2_2 - Success
#24 10.25 -- AVX compiler support found
#24 10.25 -- AVX2 compiler support found
#24 10.25 -- Performing Test BLAS_F2C_DOUBLE_WORKS
#24 10.50 -- Performing Test BLAS_F2C_DOUBLE_WORKS - Failed
#24 10.50 -- Performing Test BLAS_F2C_FLOAT_WORKS
#24 10.74 -- Performing Test BLAS_F2C_FLOAT_WORKS - Success
#24 10.74 -- Performing Test BLAS_USE_CBLAS_DOT
#24 11.03 -- Performing Test BLAS_USE_CBLAS_DOT - Success
#24 11.03 -- Found a library with BLAS API (mkl). Full path: (/opt/conda/lib/libmkl_intel_lp64.so;/opt/conda/lib/libmkl_gnu_thread.so;/opt/conda/lib/libmkl_core.so;-fopenmp;/usr/lib/x86_64-linux-gnu/libpthread.so;/usr/lib/x86_64-linux-gnu/libm.so;/usr/lib/x86_64-linux-gnu/libdl.so)
#24 11.03 -- Found a library with LAPACK API (mkl).
#24 11.03 disabling ROCM because NOT USE_ROCM is set
#24 11.03 -- MIOpen not found. Compiling without MIOpen support
#24 11.04 -- MKLDNN_CPU_RUNTIME = OMP
#24 11.04 CMake Deprecation Warning at third_party/ideep/mkl-dnn/CMakeLists.txt:17 (cmake_minimum_required):
#24 11.04   Compatibility with CMake < 2.8.12 will be removed from a future version of
#24 11.04   CMake.
#24 11.04
#24 11.04   Update the VERSION argument <min> value or use a ...<max> suffix to tell
#24 11.04   CMake that the project does not need compatibility with older versions.
#24 11.04
#24 11.04
#24 11.04 -- Intel MKL-DNN compat: set DNNL_ENABLE_CONCURRENT_EXEC to MKLDNN_ENABLE_CONCURRENT_EXEC with value `ON`
#24 11.04 -- Intel MKL-DNN compat: set DNNL_BUILD_EXAMPLES to MKLDNN_BUILD_EXAMPLES with value `FALSE`
#24 11.04 -- Intel MKL-DNN compat: set DNNL_BUILD_TESTS to MKLDNN_BUILD_TESTS with value `FALSE`
#24 11.04 -- Intel MKL-DNN compat: set DNNL_LIBRARY_TYPE to MKLDNN_LIBRARY_TYPE with value `STATIC`
#24 11.04 -- Intel MKL-DNN compat: set DNNL_ARCH_OPT_FLAGS to MKLDNN_ARCH_OPT_FLAGS with value `-msse4`
#24 11.04 -- Intel MKL-DNN compat: set DNNL_CPU_RUNTIME to MKLDNN_CPU_RUNTIME with value `OMP`
#24 11.05 CMake Warning (dev) at /opt/conda/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
#24 11.05   The package name passed to `find_package_handle_standard_args` (OpenMP_C)
#24 11.05   does not match the name of the calling package (OpenMP).  This can lead to
#24 11.05   problems in calling code that expects `find_package` result variables
#24 11.05   (e.g., `_FOUND`) to follow a certain pattern.
#24 11.05 Call Stack (most recent call first):
#24 11.05   cmake/Modules/FindOpenMP.cmake:576 (find_package_handle_standard_args)
#24 11.05   third_party/ideep/mkl-dnn/cmake/OpenMP.cmake:61 (find_package)
#24 11.05   third_party/ideep/mkl-dnn/CMakeLists.txt:119 (include)
#24 11.05 This warning is for project developers.  Use -Wno-dev to suppress it.
#24 11.05
#24 11.05 -- Found OpenMP_C: -fopenmp (found version "4.5")
#24 11.05 CMake Warning (dev) at /opt/conda/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
#24 11.05   The package name passed to `find_package_handle_standard_args` (OpenMP_CXX)
#24 11.05   does not match the name of the calling package (OpenMP).  This can lead to
#24 11.05   problems in calling code that expects `find_package` result variables
#24 11.05   (e.g., `_FOUND`) to follow a certain pattern.
#24 11.05 Call Stack (most recent call first):
#24 11.05   cmake/Modules/FindOpenMP.cmake:576 (find_package_handle_standard_args)
#24 11.05   third_party/ideep/mkl-dnn/cmake/OpenMP.cmake:61 (find_package)
#24 11.05   third_party/ideep/mkl-dnn/CMakeLists.txt:119 (include)
#24 11.05 This warning is for project developers.  Use -Wno-dev to suppress it.
#24 11.05
#24 11.05 -- Found OpenMP_CXX: -fopenmp (found version "4.5")
#24 11.07 -- Primitive cache is enabled
#24 11.09 -- Found MKL-DNN: TRUE
#24 11.09 -- Looking for clock_gettime in rt
#24 11.17 -- Looking for clock_gettime in rt - found
#24 11.17 -- Looking for mmap
#24 11.25 -- Looking for mmap - found
#24 11.25 -- Looking for shm_open
#24 11.33 -- Looking for shm_open - found
#24 11.33 -- Looking for shm_unlink
#24 11.41 -- Looking for shm_unlink - found
#24 11.41 -- Looking for malloc_usable_size
#24 11.48 -- Looking for malloc_usable_size - found
#24 11.48 -- Performing Test C_HAS_THREAD
#24 11.56 -- Performing Test C_HAS_THREAD - Success
#24 11.57 -- Version: 7.0.3
#24 11.57 -- Build type: Release
#24 11.57 -- CXX_STANDARD: 14
#24 11.57 -- Performing Test has_std_14_flag
#24 11.66 -- Performing Test has_std_14_flag - Success
#24 11.66 -- Performing Test has_std_1y_flag
#24 11.74 -- Performing Test has_std_1y_flag - Success
#24 11.74 -- Performing Test SUPPORTS_USER_DEFINED_LITERALS
#24 11.83 -- Performing Test SUPPORTS_USER_DEFINED_LITERALS - Success
#24 11.83 -- Performing Test FMT_HAS_VARIANT
#24 11.96 -- Performing Test FMT_HAS_VARIANT - Success
#24 11.96 -- Required features: cxx_variadic_templates
#24 11.96 -- Looking for strtod_l
#24 12.00 -- Looking for strtod_l - not found
#24 12.01 -- Using Kineto with CUPTI support
#24 12.01 -- Configuring Kineto dependency:
#24 12.01 --   KINETO_SOURCE_DIR = /opt/pytorch/third_party/kineto/libkineto
#24 12.01 --   KINETO_BUILD_TESTS = OFF
#24 12.01 --   KINETO_LIBRARY_TYPE = static
#24 12.01 --   CUDA_SOURCE_DIR = /usr/local/cuda
#24 12.01 --   CUDA_INCLUDE_DIRS = /usr/local/cuda/include
#24 12.01 --   CUPTI_INCLUDE_DIR = /usr/local/cuda/include
#24 12.01 --   CUDA_cupti_LIBRARY = /usr/local/cuda/lib64/libcupti_static.a
#24 12.01 -- Found CUPTI
#24 12.03 -- Found PythonInterp: /opt/conda/bin/python (found version "3.9.7")
#24 12.09 -- Kineto: FMT_SOURCE_DIR = /opt/pytorch/third_party/fmt
#24 12.09 -- Kineto: FMT_INCLUDE_DIR = /opt/pytorch/third_party/fmt/include
#24 12.09 INFO CUPTI_INCLUDE_DIR = /usr/local/cuda/include
#24 12.09 -- Configured Kineto
#24 12.09 -- GCC 7.5.0: Adding gcc and gcc_s libs to link line
#24 12.09 -- Performing Test HAS_WERROR_FORMAT
#24 12.18 -- Performing Test HAS_WERROR_FORMAT - Success
#24 12.18 -- Performing Test HAS_WERROR_CAST_FUNCTION_TYPE
#24 12.22 -- Performing Test HAS_WERROR_CAST_FUNCTION_TYPE - Failed
#24 12.23 -- Looking for backtrace
#24 12.30 -- Looking for backtrace - found
#24 12.30 -- backtrace facility detected in default set of libraries
#24 12.30 -- Found Backtrace: /usr/include
#24 12.30 -- don't use NUMA
#24 12.32 -- Performing Test COMPILER_SUPPORTS_NO_AVX256_SPLIT
#24 12.40 -- Performing Test COMPILER_SUPPORTS_NO_AVX256_SPLIT - Success
#24 13.54 -- Using ATen parallel backend: OMP
#24 13.61 CMake Deprecation Warning at third_party/sleef/CMakeLists.txt:91 (cmake_policy):
#24 13.61   The OLD behavior for policy CMP0066 will be removed from a future version
#24 13.61   of CMake.
#24 13.61
#24 13.61   The cmake-policies(7) manual explains that the OLD behaviors of all
#24 13.61   policies are deprecated and that a policy should be set to OLD only under
#24 13.61   specific short-term circumstances.  Projects should be ported to the NEW
#24 13.61   behavior and not rely on setting a policy to OLD.
#24 13.61
#24 13.61
#24 14.09 -- Found OpenSSL: /opt/conda/lib/libcrypto.so (found version "1.1.1l")
#24 14.10 -- Check size of long double
#24 14.18 -- Check size of long double - done
#24 14.19 -- Performing Test COMPILER_SUPPORTS_LONG_DOUBLE
#24 14.27 -- Performing Test COMPILER_SUPPORTS_LONG_DOUBLE - Success
#24 14.27 -- Performing Test COMPILER_SUPPORTS_FLOAT128
#24 14.34 -- Performing Test COMPILER_SUPPORTS_FLOAT128 - Success
#24 14.34 -- Performing Test COMPILER_SUPPORTS_SSE2
#24 14.53 -- Performing Test COMPILER_SUPPORTS_SSE2 - Success
#24 14.53 -- Performing Test COMPILER_SUPPORTS_SSE4
#24 14.71 -- Performing Test COMPILER_SUPPORTS_SSE4 - Success
#24 14.71 -- Performing Test COMPILER_SUPPORTS_AVX
#24 14.89 -- Performing Test COMPILER_SUPPORTS_AVX - Success
#24 14.89 -- Performing Test COMPILER_SUPPORTS_FMA4
#24 15.07 -- Performing Test COMPILER_SUPPORTS_FMA4 - Success
#24 15.07 -- Performing Test COMPILER_SUPPORTS_AVX2
#24 15.26 -- Performing Test COMPILER_SUPPORTS_AVX2 - Success
#24 15.26 -- Performing Test COMPILER_SUPPORTS_AVX512F
#24 15.44 -- Performing Test COMPILER_SUPPORTS_AVX512F - Success
#24 15.44 -- Performing Test COMPILER_SUPPORTS_OPENMP
#24 15.53 -- Performing Test COMPILER_SUPPORTS_OPENMP - Success
#24 15.53 -- Performing Test COMPILER_SUPPORTS_WEAK_ALIASES
#24 15.61 -- Performing Test COMPILER_SUPPORTS_WEAK_ALIASES - Success
#24 15.61 -- Performing Test COMPILER_SUPPORTS_BUILTIN_MATH
#24 15.69 -- Performing Test COMPILER_SUPPORTS_BUILTIN_MATH - Success
#24 15.69 -- Performing Test COMPILER_SUPPORTS_SYS_GETRANDOM
#24 15.77 -- Performing Test COMPILER_SUPPORTS_SYS_GETRANDOM - Success
#24 15.79 -- Configuring build for SLEEF-v3.6.0
#24 15.79 -- Using option `-Wall -Wno-unused -Wno-attributes -Wno-unused-result -Wno-psabi -ffp-contract=off -fno-math-errno -fno-trapping-math` to compile libsleef
#24 15.79 -- Building shared libs : OFF
#24 15.79    Target system: Linux-5.4.0-88-generic
#24 15.79    Target processor: x86_64
#24 15.79    Host system: Linux-5.4.0-88-generic
#24 15.79    Host processor: x86_64
#24 15.79    Detected C compiler: GNU @ /usr/bin/cc
#24 15.79    CMake: 3.19.6
#24 15.79    Make program: /opt/conda/bin/ninja
#24 15.79 -- Building static test bins: OFF
#24 15.79 -- MPFR : LIB_MPFR-NOTFOUND
#24 15.79 -- GMP : LIBGMP-NOTFOUND
#24 15.79 -- RT : /usr/lib/x86_64-linux-gnu/librt.so
#24 15.79 -- FFTW3 : LIBFFTW3-NOTFOUND
#24 15.79 -- OPENSSL : 1.1.1l
#24 15.79 -- SDE : SDE_COMMAND-NOTFOUND
#24 15.79 -- RUNNING_ON_TRAVIS :
#24 15.79 -- COMPILER_SUPPORTS_OPENMP : 1
#24 15.80 AT_INSTALL_INCLUDE_DIR include/ATen/core
#24 15.80 core header install: /opt/pytorch/build/aten/src/ATen/core/TensorBody.h
#24 15.84 -- Include NCCL operators
#24 15.84 -- Excluding FakeLowP operators
#24 15.85 -- Including IDEEP operators
#24 15.85 -- Excluding image processing operators due to no opencv
#24 15.85 -- Excluding video processing operators due to no opencv
#24 15.85 -- MPI operators skipped due to no MPI support
#24 15.85 -- Include Observer library
#24 17.11 -- breakpad library not found
#24 17.11 -- /usr/bin/c++ /opt/pytorch/torch/abi-check.cpp -o /opt/pytorch/build/abi-check
#24 17.33 -- Determined _GLIBCXX_USE_CXX11_ABI=1
#24 17.34 CMake Warning (dev) at torch/CMakeLists.txt:348:
#24 17.34   Syntax Warning in cmake code at column 107
#24 17.34
#24 17.34   Argument not separated from preceding token by whitespace.
#24 17.34 This warning is for project developers.  Use -Wno-dev to suppress it.
#24 17.34
#24 17.34 CMake Warning (dev) at torch/CMakeLists.txt:348:
#24 17.34   Syntax Warning in cmake code at column 115
#24 17.34
#24 17.34   Argument not separated from preceding token by whitespace.
#24 17.34 This warning is for project developers.  Use -Wno-dev to suppress it.
#24 17.34
#24 17.42 CMake Warning at cmake/public/utils.cmake:365 (message):
#24 17.42   In the future we will require one to explicitly pass TORCH_CUDA_ARCH_LIST
#24 17.42   to cmake instead of implicitly setting it as an env variable.  This will
#24 17.42   become a FATAL_ERROR in future version of pytorch.
#24 17.42 Call Stack (most recent call first):
#24 17.42   torch/CMakeLists.txt:315 (torch_cuda_get_nvcc_gencode_flag)
#24 17.42
#24 17.42
#24 17.42 CMake Warning (dev) at /opt/conda/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
#24 17.42   The package name passed to `find_package_handle_standard_args` (OpenMP_C)
#24 17.42   does not match the name of the calling package (OpenMP).  This can lead to
#24 17.42   problems in calling code that expects `find_package` result variables
#24 17.42   (e.g., `_FOUND`) to follow a certain pattern.
#24 17.42 Call Stack (most recent call first):
#24 17.42   cmake/Modules/FindOpenMP.cmake:576 (find_package_handle_standard_args)
#24 17.42   caffe2/CMakeLists.txt:1155 (find_package)
#24 17.42 This warning is for project developers.  Use -Wno-dev to suppress it.
#24 17.42
#24 17.42 CMake Warning (dev) at /opt/conda/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
#24 17.42   The package name passed to `find_package_handle_standard_args` (OpenMP_CXX)
#24 17.42   does not match the name of the calling package (OpenMP).  This can lead to
#24 17.42   problems in calling code that expects `find_package` result variables
#24 17.42   (e.g., `_FOUND`) to follow a certain pattern.
#24 17.42 Call Stack (most recent call first):
#24 17.42   cmake/Modules/FindOpenMP.cmake:576 (find_package_handle_standard_args)
#24 17.42   caffe2/CMakeLists.txt:1155 (find_package)
#24 17.42 This warning is for project developers.  Use -Wno-dev to suppress it.
#24 17.42
#24 17.42 -- pytorch is compiling with OpenMP.
#24 17.42 OpenMP CXX_FLAGS: -fopenmp.
#24 17.42 OpenMP libraries: /usr/lib/gcc/x86_64-linux-gnu/7/libgomp.so;/usr/lib/x86_64-linux-gnu/libpthread.so.
#24 17.42 -- Caffe2 is compiling with OpenMP.
#24 17.42 OpenMP CXX_FLAGS: -fopenmp.
#24 17.42 OpenMP libraries: /usr/lib/gcc/x86_64-linux-gnu/7/libgomp.so;/usr/lib/x86_64-linux-gnu/libpthread.so.
#24 17.53 -- Using lib/python3.9/site-packages as python relative installation path
#24 17.63 CMake Warning at CMakeLists.txt:941 (message):
#24 17.63   Generated cmake files are only fully tested if one builds with system glog,
#24 17.63   gflags, and protobuf.
Thank you in advance!

As for myself, I just kept repeating the command until the build finished. I know that this is not a great solution, but I haven't faced any problems yet. This issue has not occurred to me on my server yet and it appears to be an issue with PyTorch itself.
Sorry, but I don't think that I can help more with this.

Also, I have check the build results and have confirmed that ld points to /usr/bin/ld as mentioned in pytorch/pytorch#32694. Setting this to /opt/conda/compiler_compat/ld may work.

I've added the ROCM flag. Please try it out.

I've placed the conda directory on the end of the PATH variable for the build image and it worked on my laptop without any hiccups.
I do not know if this does solve the problem but I will close this issue for now. Please reopen it if it still occurs.


Little fixes

I agree, this looks better. Will merge Tomorrow after testing that gcc 4.8 on Ubuntu 14 handles the emplace_back template.


Version 2.0.0-alpha.21

Landed in https://github.com/metarhia/impress/commit/2b4aad9e08ca91bbe8cf8f588c7903bfc2cfdbc3


Alert

WIP. Not very sophisticated but I'm interested in figuring out how reakit works

[x] bootstrap styles not showing up

[ ] make them more bootstrappy
[ ] aside elements have position: absolute by default

[x] website needs entry

[ ] docs need work
[ ] usage instructions? positioning, assertiveness, removal, etc
[ ] status enums? error success info warn etc

[ ] open/visible prop on non-dialog elements
[ ] axe doesn't like role="alert"

implements https://github.com/reakit/reakit/issues/464

@diegohaz do you think this has legs? what's the baseline for a component that's worth including in the library?

@diegohaz can u look at it, please?


How to extension GREYMatchers?

I want to extension GREYMatchers for customize my own matcher
extension GREYMatchers {

	public func grey_btnEnable(enable: Bool) -> GREYMatcher! {
		let matches: MatchesBlock = { (element: AnyObject!) -> Bool in
			return (element as? UIButton)!.enabled == enable
		}

		let describe: DescribeToBlock = { (description: GREYDescription!) -> Void in
			description.appendText("test")
		}

		return GREYElementMatcherBlock(matchesBlock: matches, descriptionBlock: describe)
	}
}

But it not work, I cannot find the function when use
EarlGrey().selectElementWithMatcher(grey_accessibilityID("test")).assertWithMatcher(grey_btnEnable(false))
What's wrong with it?

Remember that grey_accessibilityID () etc. are c functions. You've created a swift method on GREYMatchers if I'm right. Instead, add it as a method in your file, akin to grey_firstElement here.

@jeff77731, were you able to solve your issue with this? Feel free to reopen the issue in case it is still present.


Do you have plans to release all the captions of InternVid?

As described in the paper, there are 234M clips in the InternVid dataset in all, but the size of the largest subset which is publicly available is only 18M.
Do you have plans to release all the captions? Or can you release a subset of densely annotated videos (e.g., 1M videos, but with caption of all clips, so we can study the ordering of clips in the same video)

I was going to ask the same question.
InternVid is a valuable dataset. But for now, only a small subset is released.
It will be greatly helpful if the full dataset can released. A huge high-quality text-video dataset is in high demand.
Do you have any further release plans?
Thx.

Our team is preparing it. However, due to our tight schedule, the precise release date for the full version is currently uncertain.

Apologies for the delayed response. You can access the complete version of InternVid here.


about pip install apex

I follow this tip:
Python 3.10.8 (main, Nov 24 2022, 14:13:03) [GCC 11.2.0]
Version: v1.9.3
Commit hash: 1c0a0c4c26f78c32095ebc7f8af82f5c04fca8c0
Launching Web UI with arguments: --port=6006 --xformers --theme=dark --enable-insecure-extension-access --ad-no-huggingface
[-] ADetailer initialized. version: 24.5.1, num models: 14
ControlNet preprocessor location: /root/autodl-tmp/stable-diffusion-webui/extensions/sd-webui-controlnet/annotator/downloads
2024-05-23 14:18:18,927 - ControlNet - INFO - ControlNet v1.1.449
Please 'pip install apex'

As a result, it was：

Is it possible that the "apex" I installed is not the "apex" in the prompt?

It seems that what needs to be installed is:
!git clone https://github.com/NVIDIA/apex.git
%cd /root/apex
!pip install -v --disable-pip-version-check --no-cache-dir --no-build-isolation --global-option="--cpp_ext" --global-option="--cuda_ext" ./

=====================
Here's not what I need：
if pip >= 23.1 (ref: https://pip.pypa.io/en/stable/news/#v23-1) which supports multiple --config-settings with the same key...
!pip install -v --disable-pip-version-check --no-cache-dir --no-build-isolation --config-settings "--build-option=--cpp_ext" --config-settings "--build-option=--cuda_ext" ./
Next, /root/apex can be deleted

If it is just under Windows environment, just type: python setup.py install under Apex directory.
But I think without this, both ComfyUI and WebUI of mine which run in separate environment can run PuLID without this Apex

If it is just under Windows environment, just type: python setup.py install under Apex directory cloned.
But I think both ComfyUI and WebUI of mine which run in separate environment can run PuLID without this Apex.


Suggest using mkdirp instead of "mkdir -p" for better cross-platform compatibility

When running npm run build on a Windows system, the build fails on the call to mkdir -p because it is not a cross-platform command.
You can resolve this by adding mkdirp (an npm package which is x-plat) and changing the call in the build script to mkdirp /public/icons.
(credit to @RyKilleen who walked me through this).

@SeanKilleen Thanks for opening this, totally forgot to add that! Fixed in ef7d3c1 🙂

Thanks!


Layer outputs not appearing in layer list on Windows

Now that I've finally gotten napari working fine on the LOCI Windows workstation, I have been able to reproduce this bug @JenuC and I noticed yesterday morning.
When we run an operation in napari-imagej (say, filter.gaussian(image, image, oobf, sigmas) and run it on example data, the image does not appear in the layer list. This is not something I have seen on Linux, and apparently not something that @ctrueden has noticed on macOS.
Further digging needed.

As an update, I think the fix is already within napari. By taking the following steps I was able to see napari-imagej outputs:

Locally cloning the napari repository
Navigating to that local repository and installing that napari into my napari-imagej conda environment:

conda activate napari-imagej
pip install -e .

I then asked @elevans to see if this fix worked on his machine, and he also saw success.
So, my plan to fix this issue is:

Wait until napari-imagej>0.4.16 is released (I think they want to jump to 0.5.0)
Pin that version as the minimum for napari-imagej.

That worked. The segmentation script runs now and napari gets a label-layer from "net.imglib2.roi.labeling.ImgLabeling". quick question before we close the issue, is there a  current list of imglib2-supported outputs that I can send to napari from the java-side? I tried "net.imglib2.img.Img" and that works 😄

@JenuC there is no formal list; if you think that this is something people would want to use, we should make an issue about it (but this should probably be a feature of PyImageJ more broadly).
Informally, check out _ptypes.py. There are two classes containing the mappings of Java and Python types. TypeMappings should give you an idea of the two-way conversions available between Python and Java. TypePlaceholders stores some Python constants that correspond to Java Enums.

So, my plan to fix this issue is:

Wait until napari>0.4.16 is released (I think they want to jump to 0.5.0)
Pin that version as the minimum for napari-imagej.

Looks like napari released 0.4.17 last month, I'll test this today.


EmitBehaviors and Empty tags and Empty strings

I have a 2-part question:

How would I configure to have <Name /> emitted instead of <Name></Name> ?

What configuration should I use to have the <Name> tag not even get emitted in the case that the Name property is an empty string?  I would actually like to configure this for all string properties (not just the Name).

I have tried all 4 variants of the EmitBehaviors (Always, NotDefault, Classic, Assigned), but I always get the following XML no matter what:
<?xml version="1.0" encoding="utf-8"?><TestData><Name></Name></TestData>

My POCO:
public class TestData
{
    public string Name { get; set; }
}

My test code:
var serializer = new ConfigurationContainer()
                  .EnableImplicitTyping(typeof(TestData))
                  .Emit(EmitBehaviors.NotDefault)
                  .Create();

serializer.Serialize(new TestData {Name = "" })

Alright, these are good questions.  To start, Emit is used for more of a global rule for emitting values.  This does not impact the format.  In order to do this would require an extension, which I put together for you here:
https://github.com/wojtpl2/ExtendedXmlSerializer/blob/9011d884a08066e09af7c90d1ef10559d2a780ea/test/ExtendedXmlSerializer.Tests/ReportedIssues/Issue246Tests.cs#L38-L114
That might seem like a lot of code, but most of it is the decoration of the IFormatWriter, which could be wrapped in a region.
As for your first question, this is possible as well, I've provided two ways of doing this, first as a specific configuration to the member/property, and then as a global configuration to string:
https://github.com/wojtpl2/ExtendedXmlSerializer/blob/9011d884a08066e09af7c90d1ef10559d2a780ea/test/ExtendedXmlSerializer.Tests/ReportedIssues/Issue246Tests.cs#L20-L35
However, please note that you are now changing the actual value being stored persisted to disk/stream.  That empty value is string.Value, but since there is no value there, it will default to default(string) which is null.  If that is OK with you, then it is ok with me. :)

Oh, I thought of another way to keep your <Name /> from being emitted while also retaining its value when it is string.Empty:
https://github.com/wojtpl2/ExtendedXmlSerializer/blob/41742952f9f7f514c45622fd7a323fe4672f9c7a/test/ExtendedXmlSerializer.Tests/ReportedIssues/Issue246Tests.cs#L38-L56

Thanks so much!  Good sample code, and super-helpful-and-FAST   ⚡   I understand what you're saying about null vs empty string - I'm just trying to keep my XML as concise as possible by sending only the elements/values needed by the other system.

Cool, happy to help!  👍


auto host rewrite for DNS clusters

Ability to automatically rewrite the host header if we are proxying to a DNS based cluster. This is a little complicated and will mean we need to:

Store the original hostname in the host description.
Once LB returns a host, rewrite host header if an option is set with this information.

@rshriram implementation notes:

Extend host description (https://github.com/lyft/envoy/blob/master/include/envoy/upstream/host_description.h) to contain a hostName() parameter which should return const std::string&. This is similar to the generic address we had previously but we got rid of to yield a strongly typed address type.
This parameter will return "" for non-DNS types.
For DNS types, we should return the original host name that we resolved to make the host in the first place. (Basically LogicalDns and StrictDns should populate this when creating hosts).
Add a new routing option called something like "auto_host_name_rewrite" which if set, will rewrite the host header based on the contents of hostName() on the selected upstream host.

This isn't a super complicated change so should be tractable in a few days.


Add GIF of usage

Would be cool for demo purposes if we had a 10 second GIF showing the usage of this tool.

Solved this in here. However, I think it is better if we wait till #85 gets merged so the GIF is up to date with the available list of templates.

Now that #85 got merged, this is being addressed in #104.


LilyGo_RGBPanel.h compile error

When I try to compile any of the examples using LilyGo_RGBPanel.h, I get compile errors stemming from line #24 #include <ExtensionIOXL9555.hpp>.  Where is "ExtensionIOXL9555.hpp"??

Do you use platformio or arduino?
Using Arduino IDE or platformio will automatically download dependencies, ExtensionIOXL9555 is located
ExtensionIOXL9555.hpp
I ran a compile check and found no problems
https://github.com/Xinyuan-LilyGO/LilyGo-T-RGB/actions/runs/8261965632
https://github.com/Xinyuan-LilyGO/LilyGo-T-RGB/actions/runs/8261963905

I'm using Arduino IDE. My errors:
In file included from /Users/chriscarpenter/Downloads/lilygo/LilyGo-T-RGB-main/examples/lv_factory/lv_factory.ino:10:
/Users/chriscarpenter/Documents/Arduino/libraries/LilyGo-T-RGB/src/LilyGo_RGBPanel.h:103:24: error: 'ExtensionGPIO' in 'class ExtensionIOXL9555' does not name a type
ExtensionIOXL9555::ExtensionGPIO cs = ExtensionIOXL9555::IO3;
^~~~~~~~~~~~~
/Users/chriscarpenter/Documents/Arduino/libraries/LilyGo-T-RGB/src/LilyGo_RGBPanel.h:104:24: error: 'ExtensionGPIO' in 'class ExtensionIOXL9555' does not name a type
ExtensionIOXL9555::ExtensionGPIO mosi = ExtensionIOXL9555::IO4;
^~~~~~~~~~~~~
/Users/chriscarpenter/Documents/Arduino/libraries/LilyGo-T-RGB/src/LilyGo_RGBPanel.h:105:24: error: 'ExtensionGPIO' in 'class ExtensionIOXL9555' does not name a type
ExtensionIOXL9555::ExtensionGPIO sclk = ExtensionIOXL9555::IO5;
^~~~~~~~~~~~~
/Users/chriscarpenter/Documents/Arduino/libraries/LilyGo-T-RGB/src/LilyGo_RGBPanel.h:106:24: error: 'ExtensionGPIO' in 'class ExtensionIOXL9555' does not name a type
ExtensionIOXL9555::ExtensionGPIO reset = ExtensionIOXL9555::IO6;
^~~~~~~~~~~~~
/Users/chriscarpenter/Documents/Arduino/libraries/LilyGo-T-RGB/src/LilyGo_RGBPanel.h:107:24: error: 'ExtensionGPIO' in 'class ExtensionIOXL9555' does not name a type
ExtensionIOXL9555::ExtensionGPIO power_enable = ExtensionIOXL9555::IO2;
^~~~~~~~~~~~~
/Users/chriscarpenter/Documents/Arduino/libraries/LilyGo-T-RGB/src/LilyGo_RGBPanel.h:108:24: error: 'ExtensionGPIO' in 'class ExtensionIOXL9555' does not name a type
ExtensionIOXL9555::ExtensionGPIO sdmmc_cs = ExtensionIOXL9555::IO7;
^~~~~~~~~~~~~
/Users/chriscarpenter/Documents/Arduino/libraries/LilyGo-T-RGB/src/LilyGo_RGBPanel.h:109:24: error: 'ExtensionGPIO' in 'class ExtensionIOXL9555' does not name a type
ExtensionIOXL9555::ExtensionGPIO tp_reset = ExtensionIOXL9555::IO1;
^~~~~~~~~~~~~
exit status 1
Compilation error: exit status 1

Which version of esp32 core are you using? 3.0?

Can you compare to see if the installation is complete?

Thats the thing.  When I'm in ArduinoIDO and I search the Library for LilyGo-T-RGB, I don't get anything.  I imported the zip file from github

To import files, you must manually download dependent libraries instead of simply importing LilyGo-T-RGB.
https://github.com/Xinyuan-LilyGO/LilyGo-T-RGB#5⃣-arduino-ide-manual-installation

You can't find it? ?

SensorLib in the library only gives me an option up to version 0.1.4

SensorLib in the library only gives me an option up to version 0.1.4

 No, I don't see it

oh ! I don’t know what the situation is there, you can run the command line according to action CI
https://github.com/Xinyuan-LilyGO/LilyGo-T-RGB/blob/f9249cc55c71f011fab2e5a20354702727f67546/.github/workflows/arduino_ci.yml#L53

I suspect that your ArduinoIDE failed to pull the library index library, resulting in the inability to index the latest library.

Wow, ok let me try that

Installed the latest version of Arduino IDE and reverted to lvgl 8.3.1 and it now compiles. Thanks!


Failed to Load DSO when ./unimrcpserver is started

Hi,
I am a total beginner and trying to establish UniMRCP server with the Vosk plugin.
I started the server in my local but having a linking issue below:
2022-07-27 10:16:08:539422 [INFO]   Load Plugin [Vosk-Recog-1] [/usr/local/unimrcp/plugin/voskrecog.so]
2022-07-27 10:16:08:548585 [WARN]   Failed to Load DSO: /usr/local/unimrcp/plugin/voskrecog.so: undefined symbol: vosk_recognizer_set_nlsml
I started the ./unimrcpclient, it is integrating with the server but I can not use the recognition engine. Rest works fine with demo plugins but when I try run recog it gets the error below:
2022-07-27 10:27:01:680069 [INFO]   Receive SIP Event [nua_r_invite] Status 406 Not Acceptable [SIP-Agent-1]
2022-07-27 10:27:01:680110 [INFO]   Receive SIP Event [nua_i_state] Status 406 Not Acceptable [SIP-Agent-1]
I tried to run ./bootstrap, ./configure, make, make install on unimrcp_vosk_plugin folder again and again nothing changed. My vosk_api is also installed on /home/username/vosk-api and I configured the file Makefile.am in plugins/vosk-recog as VOSK_HOME = /home/username/vosk-api
Could you explain what is wrong? Thanks.

Solved this issue:
I was using the libvosk.so I downloaded from somewhere.
I installed the vosk api with
pip3 install vosk
And used the libvosk.so at /usr/local/lib/python3.8/dist-packages/vosk-0.3.43-py3.8.egg/vosk/libvosk.so
And now everything is fine.

Solved this issue:
I was using the libvosk.so I downloaded from somewhere.
I installed the vosk api with
pip3 install vosk
And used the libvosk.so at /usr/local/lib/python3.8/dist-packages/vosk-0.3.43-py3.8.egg/vosk/libvosk.so
And now everything is fine.


strip_whitespace after coercion, but before constraint checks on custom data types

Initial Checks

[X] I have searched Google & GitHub for similar requests and couldn't find anything
[X] I have read and followed the docs and still think this feature is missing

Description
Note: See https://github.com/pydantic/pydantic/discussions/6469 for the full discussion.
In Pydantic V1, it was possible to do something as simple as this, which resulted in the following operations happening in this order:

Type checking/coercion
Whitespace stripping
Length constraint checks

from pydantic import StrictStr

class Username(StrictStr):
    min_length = 3
    max_length = 20
    strip_whitespace = True

However, in Pydantic V2 this case is particularly tricky because the min_length constraint gets applied after coercion but before the Python string is created, and hence before the AfterValidator. So there is really no way to insert custom logic between these two steps.
The closest one can get is by using something like this, but this is a lot of mental gymnastics for something that was trivial in V1.
from typing_extensions import Annotated
from pydantic import BaseModel, Field, BeforeValidator

Username = Annotated[str, BeforeValidator(lambda x: str.strip(str(x))), Field(min_length=3, max_length=20)]

@adriangb suggested the easiest thing to do would probably be to just add back str_strip_whitespace to Field or create some sort of ConStr() marker for annotated (Annotated[str, ConStr(strip_whitespace=True), Field(max_length=10, ...)] or something like that), and that is why I am creating this feature request.
Affected Components

[ ] Compatibility between releases
[X] Data validation/parsing
[ ] Data serialization - .model_dump() and .model_dump_json()
[ ] JSON Schema
[ ] Dataclasses
[ ] Model Config
[x] Field Types - adding or changing a particular data type
[ ] Function validation decorator
[ ] Generic Models
[ ] Other Model behaviour - model_construct(), pickling, private attributes, ORM mode
[ ] Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.

Selected Assignee: @lig

Not much simpler at the minute, but this as_bv() util allows you to use existing validatory types such as constr, rather than rolling your own unnecessarily, by wrapping the type in a BeforeValidator.
tp.Annotated[str, Field(min_length=3, max_length=10), as_bv(constr(strip_whitespace=True))]

I'm hoping the equivalent of as_bv() is done implicitly pydantic-side at some point as per https://github.com/pydantic/pydantic/issues/6506#issuecomment-1627174736
import typing as tp
from pydantic import BeforeValidator, TypeAdapter, constr, Field

def as_bv(t: type) -> BeforeValidator:
    """Converts a type into a BeforeValidator"""
    ta = TypeAdapter(t)
    return BeforeValidator(lambda v: ta.validate_python(v))

MyT = tp.Annotated[str, Field(min_length=3, max_length=10), as_bv(constr(strip_whitespace=True))]

res = TypeAdapter(MyT).validate_python("   123456789   ")

print(f"res: '{res}'")

res: '123456789'

There are fundamental problems with this approach that will not allow us to include it in Pydantic directly.
Practically speaking, we've worked very hard to make the entirety of validation happen within a single Rust call (with callbacks to Python when necessary, yes, but avoiding these as much as possible for performance reasons). Not only would inserting a call to a TypeAdapter be problematic performance-wise, but it's also going to wreak havoc with exceptions (the exception from that validation call will end up just being a repr(ValueError()) instead of being collected into the top level ValueError) and probably other things I'm not even thinking of that we won't figure out until it's too late. It's just fundamentally an approach that Pydantic is not designed for.
On a perhaps more philosophical note the metadata in Annotated is not intended to be types, and while there are no runtime errors by putting a type in there it does seem just wrong to do.
That is not to say you can't use this utility function if it works for you, I just don't think it's as simple, universal, and cheap of a win as it seems on the surface.

@lig why is this "not planned"? It's a step back from Pydantic V1.
@adriangb suggested the easiest thing to do would probably be to just add back str_strip_whitespace to Field or create some sort of ConStr() marker for annotated (Annotated[str, ConStr(strip_whitespace=True), Field(max_length=10, ...)] or something like that), and his last comment in this thread related more to the other issue than to this one, as he said.

@prryplatypus At the moment solving this is too complicated as it would require some serious work in pydantic-core and it looks tricky to implement without affecting overall Pydantic performance.
This is not a step back but a cost of significant performance improvement of Pydantic v2 comparing to Pydantic v1.
That said, PRs are always welcome. In this particular case it's important that the change wouldn't affect the performance.

#6951 maybe solves this


Add BareVersion

Rust 1.56.0 has introduced the rust-version field in Cargo.toml, which1:

must be a bare version number with two or three components;
it cannot include semver operators or pre-release identifiers.

semver::Version requires three components so it's Deserialize implementation cannot be used for bare versions.
While bare versions can be deserialized as semver::VersionReq by virtue of being a syntactic subset, it doesn't make much sense to deserialize strings that explicitly "cannot include semver operators" as a vector of comparison operators.
This commit therefore introduces a new BareVersion type to accurately represent the restrictions of the new rust-version Cargo.toml field.
Prior art includes the cargo-msrv crate which already defines its own BareVersion type.2 The type introduced by this commit differs in that it's a struct instead of an enum since that allows easier access to the major and minor components.

Fair enough. I agree that it's extremely specific to package.rust-version. I stumbled on this since cargo_metadata currently wrongly uses VersionReq as the type for rust-version which makes it really awkward to work with ... so yeah switching to Version with a custom serialize impl would of course pretty much solve the problem for cargo_metadata.
There's still the use case of parsing Cargo.toml directly and serializing it again without incurring unrelated changes such as 1.2 -> 1.2.0 ... however then you could probably just use String in the struct and parse this afterwards as needed.


Provide an optional means of enabling validation of data integrity during Restores (i.e. enable Restic to use checksums)

https://issues.redhat.com/browse/MIG-20

Note to self from Vince's mockups (https://docs.google.com/presentation/d/1hlP8wjzsO_9c9ri2rIz7o2kuIQvmKCNUhoQxTnUkHr0/edit#slide=id.g7f12813776_1_8):

Checkboxes [in the "Verify copy" column] are disabled unless Filesystem copy is selected for the Copy method.


generic_currency doesnt allow tokens without decimals

You can define a symbol like S(0, GOLD) but you can't query it:
➜  kesar-coin eosioc push action coin issue '{"to":"crowdsale", "quantity": "1000 GOLD"}' --permission coin@active
2117858ms thread-0   main.cpp:866                  operator()           ] Converting argument to binary...
2117914ms thread-0   main.cpp:941                  main                 ] Failed with error: Assert Exception (10)
dot_pos != string::npos: dot missing in asset from string

@kesar try using "1000. GOLD". IIRC The dot is mandatory when converting from string

Agreed, but closing in favor of #1616 .


FIX: replacing Prometheus-IDs in datasource.yml

fix: https://github.com/stereum-dev/ethereum-node/issues/370

I thought you would implement this in write-grafana-configuration.yml 😅 otherwise the JS Backend would need to do this @stefa2k what do you think?

that looks to me only for tests, so we'd still need it in the JS backend right? Maybe we can talk about it tomorrow?

As discussed today: Please use a network alias for prometheus docker container.


installation: Flask>=0.11

Removes dependency on Flask-CLI.

Signed-off-by: Jiri Kuncar<EMAIL_ADDRESS>

It works :)


'NaiveBayesModel' object has no attribute 'serializeToBundle'

Hi,
In this simple script that does not have a pipeline, I want to serialize the NaiveBayes model to the filesystem, and it gets the error: AttributeError: 'NaiveBayesModel' object has no attribute 'serializeToBundle' calling serializeToBundle.
Is serializeToBundle only defined for Pipeline?
`
from mleap import pyspark
from pyspark.ml.classification import NaiveBayes
from pyspark.sql import SparkSession
if name == "main":
spark = SparkSession
.builder
.appName("NaiveBayesExample")
.getOrCreate()
data = spark.read.format("libsvm").load("<data file path>")
train, test = data.randomSplit([0.6, 0.4], 1234)

nb = NaiveBayes(smoothing=1.0, modelType="multinomial")
model = nb.fit(train)
model.serializeToBundle("jar:file:/tmp/nb_example.zip", model.transform(data))

...
`
Colin Goldberg

I got a similar error when I used a pipeline. But adding '--packages ml.combust.mleap:mleap-spark_2.11:0.8.1' seems to have solved it - for both use cases (Naive Bayes on its own, and using Pipeline).


Add FileRegionStream which can be used to provide a stream of FileReg…

…ion backed by some resource.
Motivation:
To support difference use-cases (like for example HTTP/2) we need the ability to dynamicly create FileRegion instances from a FileChannel in specific sizes.
Modifications:

Add FileRegionStream and a DefaultFileRegionStream implementation which allows to create DefaultFileRegion instances using the same FileChannel instance.
Allow to create DefaultFileRegion instances from a FileRegion and allow the user to take responsibility to close the FileChannel. This can be useful for users to write the same FileChannel multiple times without the overhead of calling
open(...) all the times. This is important as open(...) may block and is also expensive.

Result:
Be able to create a stream of FileRegions.

This is an alternative way of implement what we need for HTTP/2 and so could close https://github.com/netty/netty/pull/6997.
@carl-mastrangelo @ejona86 @Scottmitch @Apache9  I think I would prefer to do something like this to minimise the scope of changes. I think this is good enough.

So we are going to expose this in the HTTP/2 API? Overall LGTM. This is only a POC so I'm not going to point out some corner cases as I think you will fix them in the next patch. :)

yep... I want to get the opinion of the others on this approach before spending more time on it.

@normanmaurer - the approach in PR https://github.com/netty/netty/pull/6997 seems consistent with the pre-existing approach of taking subsections of content vs consuming subsections of content, reference counting not being conditional, and wrapping from ByteBuf, ByteBuffer, etc... The approach in PR #6997 also seems more likely what I would expect the behavior to be if we could break APIs on FIleRegion itself. Other than the change-set being smaller what are the advantages of this PR vs https://github.com/netty/netty/pull/6997?

also related to https://github.com/netty/netty/issues/7260


Consistently use binstubs

Since it default to rails 4 and we have bin/ anyway, I suggest to use it everywhere.

@igas Can you rebase?

@prathamesh-sonpatki sure. Done =)

Cheers!


Is it possible to add a function like proc.expect?

Is it possible to have a function like that you can set:
p = proc()
# ...
p.expect = "grep <some string expected> {{outfile}}"

Sometime, even it returned 0 and output file generated, it could be still unexpected results.
By this, you can set the expectation, tell pyppl whether the job is finished as we expected.

Good catch, try to implement it in next version.


Enable stock control for all product types

The system already has support for stock control, however for some odd reason the configuration options for it were only found in the config template for the "custom" product type. I have no idea if this was an accident or yet another extremely odd decision from the old BoxBilling team, but I'm considering it to be another dumb bug.
(Also to make it clear, the stock control functionality is indeed in the core and not implemented in the custom product type. It works with all product types)
So, this PR moves it to the main product configuration template & also makes a few tweaks to that template to improve it.
Old

New

Seems like a pretty sensible change. Odd that it was hidden away like that.

Indeed. I haven't a clue why it ended up like that


Refreshing offers does not work

Problem with changing the status of the exchange offer. After sending the offer and accepting the exchange offer, the status does not change, status remains: Active or Created Needs Confirmatio.

I think it has something to do with steam-tradeoffer-manager. Maybe the code is outdated


Revertible behaviour for Deployaccount

TITLE
Description
Description of the pull request changes and motivation.
Checklist

[x] Linked to Github Issue
[x] Unit tests added
[ ] Integration tests added.
[ ] This change requires new documentation.
[ ] Documentation has been added/updated.

Codecov Report

Merging #1168 (95dadb2) into main (c2cf08b) will increase coverage by 0.12%.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1168      +/-   ##
==========================================
+ Coverage   89.47%   89.59%   +0.12%
==========================================
  Files          50       50
  Lines       14369    14412      +43
==========================================
+ Hits        12856    12912      +56
+ Misses       1513     1500      -13

Files
Coverage Δ

src/transaction/deploy_account.rs
79.33% <100.00%> (+1.16%)
:arrow_up:

... and 7 files with indirect coverage changes


refactor (core-api): make schema names consistent in openapi spec

@petermetz Hello! I think this branch is good to go :)

Codecov Report

Merging #1349 (c4765ec) into main (32a06a3) will increase coverage by 0.00%.
The diff coverage is 100.00%.

:exclamation: Current head c4765ec differs from pull request most recent head b5b1e49. Consider uploading reports for the commit b5b1e49 to get more accurate results

@@           Coverage Diff           @@
##             main    #1349   +/-   ##
=======================================
  Coverage   68.63%   68.63%
=======================================
  Files         301      301
  Lines       10948    10949    +1
  Branches     1347     1348    +1
=======================================
+ Hits         7514     7515    +1
  Misses       2733     2733
  Partials      701      701

Impacted Files
Coverage Δ

...tus-common/src/main/typescript/js-object-signer.ts
90.90% <100.00%> (+0.28%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 32a06a3...b5b1e49. Read the comment docs.


Help text for ballerina test prints the help text for ballerina build

Description:
$title.
$ ballerina test -h

Affected Versions:
$ ballerina -v
Ballerina 1.0.0-beta
Language specification 2019R3
Ballerina tool 1.0.0

Related Issues (optional):
https://github.com/ballerina-platform/ballerina-lang/issues/18464

Fix will send a PR


First time using - Questions/Problems(?)

Hello! I hope this is the right place for this kind of post. Can't find where else to post.
So this will be my first time self-hosting anything like this, so I am running into hurdles as I figure this all. I have finally hit a total block.
Following the instructions on the site, I just built the app with npm and ran it. Before doing this, I had confusion:

What do I do with the HASH_SALT variable? Do I generate something using a tool or it is done on its own?
After any change to the .env file, does the program need rebuilding?

Additionally, I had issues with postgresql. May have fixed them, but I received a database authentication error on my first attempt. (My Postgresql user had no password, so I set one. Might have to apply the changes by rebuilding before trying again?)

So I did fix the issue with Postgresql. Just needed to change the DB name, and actually give my psql username a password.
So now I'm just confused on the HASH_SALT variable.

The HASH_SALT can be any random string. All it does it generate unique values for your installation.

The HASH_SALT can be any random string. All it does it generate unique values for your installation.

So I can just make it anything (might just use random.org)?

Yes, you can.

Well, I've got it running fine on my DigitalOcean server, but now I have just one more concern... being indexed by search engines.
Going to need to add a robots.txt file... I'm guessing I place it in the "pages" directory and it won't break anything?

I think you can place it anywhere as long as you can access it via yourwebsite.com/robots.txt.

Got it to work... I had to add something to the ngnix server block config file. Now umami is running... and I think ready to go.
The only user is admin as stated in the install guide, created when creating the database tables. Besides having to change the password, are there any risks to using this user, or should I create another?
Sorry for the many questions... just trying to make sure I do this right and not fatally screw something up.

It's fine. I personally just use the default admin account. But if you want to be sure, you can add another.


Raster Calculator panics (Permission error)

In reference to #197 I experience the same issue with a dockerized Python install. For me the raster_calculator results in the same failure and backtrace. I find it a pity that the raster calculator doesn't work out of the box with a Python install and would hope the Python would get fixed.
By the way, thanks for the great work on these tools!
./whitebox_tools --run="RasterCalculator" --wd="/opt/project/utils/waterbodies/workspace/breached" --statement="raster1" --output='raster2'

thread 'main' panicked at 'failed to execute process: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', whitebox-tools-app/src/tools/mod.rs:1258:26
stack backtrace:
0:     0x5638694f19dc - std::backtrace_rs::backtrace::libunwind::trace::h7f0f727c679b121e
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
1:     0x5638694f19dc - std::backtrace_rs::backtrace::trace_unsynchronized::h27b8207adc787597
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2:     0x5638694f19dc - std::sys_common::backtrace::_print_fmt::h18c4a15687f3f453
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/sys_common/backtrace.rs:67:5
3:     0x5638694f19dc - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h7077f94cc0b2a619
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/sys_common/backtrace.rs:46:22
4:     0x56386952fdaf - core::fmt::write::hd1fcbdc89ccede50
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/core/src/fmt/mod.rs:1096:17
5:     0x5638694f11e6 - std::io::Write::write_fmt::h3030f95a96ab63e0
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/io/mod.rs:1568:15
6:     0x563869506365 - std::sys_common::backtrace::_print::hce920b6e4ede72f2
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/sys_common/backtrace.rs:49:5
7:     0x563869506365 - std::sys_common::backtrace::print::h63694f3a744810f6
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/sys_common/backtrace.rs:36:9
8:     0x563869506365 - std::panicking::default_hook::{{closure}}::h2f22ad38e825d5e1
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/panicking.rs:208:50
9:     0x563869505f33 - std::panicking::default_hook::hc0998dccd7f968a3
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/panicking.rs:225:9
10:     0x563869506995 - std::panicking::rust_panic_with_hook::h618d5ded1dbe5ea3
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/panicking.rs:591:17
11:     0x5638694f21f7 - std::panicking::begin_panic_handler::{{closure}}::h64f3a351a9df3931
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/panicking.rs:497:13
12:     0x5638694f1b3c - std::sys_common::backtrace::__rust_end_short_backtrace::hf7a8c7450479e920
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/sys_common/backtrace.rs:141:18
13:     0x563869506542 - rust_begin_unwind
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/panicking.rs:493:5
14:     0x56386952fae1 - core::panicking::panic_fmt::hac8d59bba791921f
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/core/src/panicking.rs:92:14
15:     0x56386952b583 - core::result::unwrap_failed::h386947b3c6c45634
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/core/src/result.rs:1284:5
16:     0x563868c35345 - whitebox_tools::tools::ToolManager::run_tool::h324febd58ab9a2e8
17:     0x563868906abf - whitebox_tools::run::hf0adb91db1a610a3
18:     0x563868903e2a - whitebox_tools::main::h48bb4032c3c51024
19:     0x5638691096f3 - std::sys_common::backtrace::__rust_begin_short_backtrace::h9669996f076d0ae7
20:     0x5638686f4dc9 - std::rt::lang_start::{{closure}}::h4d629acb5d2e5dbf
21:     0x563869506d4a - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::hacf21ab16c4aa1f7
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/core/src/ops/function.rs:259:13
22:     0x563869506d4a - std::panicking::try::do_call::h002bd74c4d814788
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/panicking.rs:379:40
23:     0x563869506d4a - std::panicking::try::hae0844c0aa736d3d
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/panicking.rs:343:19
24:     0x563869506d4a - std::panic::catch_unwind::hec4fe4ae39575e8f
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/panic.rs:431:14
25:     0x563869506d4a - std::rt::lang_start_internal::h024664467cde3297
at /build/rustc-h1hlaa/rustc-1.51.0+dfsg1+llvm/library/std/src/rt.rs:51:25
26:     0x563868907f02 - main
27:     0x7f4f46d5d0b3 - __libc_start_main
28:     0x5638686f4cda - _start
29:                0x0 - <unknown>

I have not used docker, so I don't know why docker behaves differently than a regular installation using conda. You can check the file permission of the WhiteboxTools binary in the following path and change the permission chmod 755 if needed.
~/.conda/envs/ENV_NAME/lib/python3.x/site-packages/whitebox/whitebox_tools

The whitebox python package should handle the permission during installation. Not sure why it does not work with docker.
https://github.com/giswqs/whitebox-python/blob/master/whitebox/download_wbt.py#L101
            if platform.system() != "Windows":  # grant executable permission
                os.system("chmod 755 " + exe_path)

Hello. I have just checked this one again and made sure that all files in "/usr/local/lib/python3.8/dist-packages/whitebox" have the permission 0755. But unfortunately I get the same permission error:
./whitebox_tools --run="RasterCalculator" --wd="/usr/local/lib/python3.8/dist-packages/whitebox" --statement="..."
thread 'main' panicked at 'failed to execute process: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', whitebox-tools-app/src/tools/mod.rs:1258:26

Looking at the code in whitebox-tools-app/src/tools/mod.rs:1258:26,
  let mut child = Command::new(exe)
      .arg("run")
      .args(&args2)
      .spawn()
      .expect("failed to execute process");

I wonder if this might be a rust issue and that the arguments to this command are not properly passed?

Do you mean that all WBT tools work with Python except RasterCalculator? Or is the Python frontend not working at all?

Do you mean that all WBT tools work with Python except RasterCalculator? Or is the Python frontend not working at all?

Yes. Exactly

Then this is probably an issue related to the WBT backend rather than the Python frontend.

I use Docker via WSL2 on Windows. Seems I am not the only one who experienced this issue.

Then this is probably an issue related to the WBT backend rather than the Python frontend.

Anything I could do here?

Have you tried it directly on Windows without using WSL2?

Sorry for my late replay. I tried on Windows and it works. I tried on a vanilla Ubuntu with Python 3.8 in WSL and it failed with a similar error:
thread 'main' panicked at 'Error creating output settings.json file.: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', whitebox-common/src/configs/mod.rs:57:46

It looks like your WBT folder is currently in a directory that you do not have write privileges for. The WhiteboxTools executable will attempt to write to the settings.json file contained in the WBT directory when you run a tool.

The command being executed is:
./whitebox_tools --run="RasterCalculator" --wd="/usr/local/lib/python3.8/dist-packages/whitebox" --statement="/opt/project/utils/waterbodies/workspace/dem_breached/dem.RemoveDemDepressions.dem_removed.7e18282af9250c092896cc4ab007b4669928d92a.tif" - 3.0 * "/tmp/tmpgywdh2so/streams_thickened.tif" --output='/opt/project/utils/waterbodies/workspace/dem_burned/dem.BurnDemStreams.burned_dem.5a9d5bed68e0480dc6e2269a23956c80e24d914d.tif'

My observations is that both on a WSL Linux as well as in Docker linux container the default install of Whitebox tools as Python package (Download of the tool) creates a problematic permission. Seems I need to execute my script as root. The WD for instance is the default WD: /usr/local/lib/python3.8/dist-packages/whitebox

That means the package was incorrectly installed to a system directory rather than a user directory. That's probably the way how docker or WSL was set up. You need to make sure the package is installed to a directory you have write permission to.

@giswqs, agreed!

I think I found the issue. I had set my Docker script to even set the permissions to 0777 to the folder /usr/local/lib/python3.8/dist-packages/whitebox as can be seen here:
#7 260.4 -rwxrwxrwx 1 root staff    175 Nov 22 23:53 __init__.py
#7 260.4 drwxrwsrwx 2 root staff   4096 Nov 22 23:53 __pycache__
#7 260.4 -rwxrwxrwx 1 root staff   3920 Nov 22 23:53 automation.py
#7 260.4 -rwxrwxrwx 1 root staff    416 Nov 22 23:53 cli.py
#7 260.4 -rwxrwxrwx 1 root staff   4950 Nov 22 23:53 download_wbt.py
#7 260.4 -rwxrwxrwx 1 root staff   2469 Nov 22 23:53 example.py
#7 260.4 -rwxrwxrwx 1 root staff  58695 Nov 22 23:53 wb_runner.py
#7 260.4 -rwxrwxrwx 1 root staff    148 Nov 22 23:53 whitebox.py
#7 260.4 -rwxrwxrwx 1 root staff   6146 Nov 22 23:53 whitebox_example.py
#7 260.4 -rwxrwxrwx 1 root staff 426790 Nov 22 23:53 whitebox_tools.py

But I kept on getting the same problem, despite giving all permission possible. When opening a shell to my container afterwards, I found that I still had folders being created later, after my Docker container was build. This is how it looks on container runtime:
drwxrwsrwx 1 root staff     4096 Nov 22 23:54 .
drwxrwsr-x 1 root staff     4096 Nov 22 23:54 ..
drwxr-sr-x 5 root staff     4096 Nov 22 23:54 WBT
-rw-r--r-- 1 root staff 15383585 Nov 22 23:54 WhiteboxTools_linux_amd64.zip
-rwxrwxrwx 1 root staff      175 Nov 22 23:53 __init__.py
drwxrwsrwx 2 root staff     4096 Nov 22 23:53 __pycache__
-rwxrwxrwx 1 root staff     3920 Nov 22 23:53 automation.py
-rwxrwxrwx 1 root staff      416 Nov 22 23:53 cli.py
-rwxrwxrwx 1 root staff     4950 Nov 22 23:53 download_wbt.py
-rwxrwxrwx 1 root staff     2469 Nov 22 23:53 example.py
drwxr-sr-x 2 root staff     4096 Nov 22 23:54 img
drwxr-sr-x 2 root staff     4096 Nov 22 23:54 plugins
-rw-r--r-- 1 root staff      148 Nov 22 23:54 settings.json
drwxr-sr-x 2 root staff     4096 Nov 22 23:54 testdata
-rwxrwxrwx 1 root staff    58695 Nov 22 23:53 wb_runner.py
-rwxrwxrwx 1 root staff      148 Nov 22 23:53 whitebox.py
-rwxrwxrwx 1 root staff     6146 Nov 22 23:53 whitebox_example.py
-rwxr-xr-x 1 root staff 35129928 Nov 22 23:54 whitebox_tools
-rwxrwxrwx 1 root staff   426790 Nov 22 23:53 whitebox_tools.py

Because the new folders where missing the correct permissions I got the permission error and panic error.
So far I initialised the Docker image with the following script to make sure the whitebox binary is downloaded already on Docker build time:
RUN echo "import whitebox" > wb.py \
        && python3 wb.py \
        && chmod -R 0777 `find / -type d -name "whitebox"` \
        && ls -la `find / -type d -name "whitebox"` \

I need to find out how to get the additional files and folders being created on in the docker image at build time.
I suspect the whitebox package too also set the 0755 permission too early?

Solution:
I changed the whitebox initialisation in my Dockerfile to:
RUN echo "from whitebox.whitebox_tools import WhiteboxTools" > wb.py \
 && echo "wbt = WhiteboxTools()" >> wb.py \
 && python3 wb.py \
 && chmod -R 0777 `find / -type d -name "whitebox"`

This downloads all files and when additionally setting the permissions, I have no permission errors/panics in my container later on.

Thanks for all your fast feedback and help. Very much appreciated!


The camera rotates below the ground

In cesium version 1.56.1,   camera. Lookat() function is used to rotate the camera around a target, but the camera rotates down to the ground.  I didn't use terrain, I used 3d tiles data.
Excese me, How to solve this problem?

I think I have a similar issue - I registered it with the angular-cesium repo (https://github.com/articodeltd/angular-cesium/issues/262), but they think this is a cesium issue.
Intended outcome:
Draw corridors with terrain enabled
Actual outcome:
The corridors are misaligned and change with the view, the georeference of the corridor appears incorrect relative to the aerial image. If I disable terrain, then it works fine.
How to reproduce the issue:
create a map with terrain provider by cesium ion, e.g.:
export class MapLayerComponent {
  sceneMode = SceneMode.SCENE3D;
  MapLayerProviderOptions = MapLayerProviderOptions;
  arcGisMapServerProvider = MapLayerProviderOptions.ArcGisMapServer;
  @ViewChild(AcLayerComponent) layer: AcLayerComponent;

  constructor(private viewerConf: ViewerConfiguration, public appSettingsService: AppSettingsService) {
    viewerConf.viewerOptions = {
      selectionIndicator: false,
      timeline: false,
      infoBox: false,
      fullscreenButton: false,
      animation: false,
      shouldAnimate: false,
      homeButton: false,
      geocoder: true,
      navigationHelpButton: false,
      navigationInstructionsInitiallyVisible: false,
      baseLayerPicker: false,
    };

    viewerConf.viewerModifier = (viewer: any) => {
      viewer.screenSpaceEventHandler.removeInputAction(Cesium.ScreenSpaceEventType.LEFT_DOUBLE_CLICK);
      viewer.imageryProvider = new Cesium.createWorldImagery({
        style : Cesium.IonWorldImageryStyle.AERIAL_WITH_LABELS
      });
      viewer.terrainProvider = new Cesium.CesiumTerrainProvider({
        url: Cesium.IonResource.fromAssetId(1),
      });
      this.appSettingsService.showRoadsLayer = true;
    };
  }
}

Create a corridor, e.g.:
  <ac-corridor-desc props="{
    name: entity.name,
    positions: entity.positions,
    width : 10,
    extrudedHeight : 100,
    height : 400,
    material : Cesium.Color.BLUE.withAlpha(0.1),
    outline : true,
  }">
  </ac-corridor-desc>

Thanks for bringing this up - I believe this is the same issue as https://github.com/AnalyticalGraphicsInc/cesium/issues/5837.
For @shortwavedave , it's hard to tell without seeing it, but I think this is an issue of depth testing against terrain being turned off. Please try turning it on with:
viewer.scene.globe.depthTestAgainstTerrain = true;

If that doesn't fix it, please open a new issue with a Sandcastle code example of the issue.