.

Some logs
Experimental means I made them not be built. They selected us such because I couldn't build them on a common glibc toolchain.

g++-15

 g++-15 --version
g++-15 (Gentoo 15.0.0_pre20240804 p8) 15.0.0 20240804 (experimental)
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

with "experimental" targets
git clone https://github.com/Arniiiii/fast_io_cmake_cpm --branch next fast_io_cmake_clone
cd fast_io_cmake_clone

  cmake -S. -Bbuild -DCMAKE_CXX_COMPILER=g++-15 -DCMAKE_C_COMPILER=gcc-15 -DCMAKE_GENERATOR="Ninja" -DCMAKE_BUILD_TYPE=Debug -Dfast_io_ENABLE_TESTS_EXPERIMENTAL=1 -Dfast_io_ENABLE_FUZZING_EXPERIMENTAL=1 -Dfast_io_ENABLE_BENCHMARKS_EXPERIMENTAL=1 -Dfast_io_ENABLE_EXAMPLES_EXPERIMENTAL=1 -DCPM_SOURCE_CACHE=~/.cache/cpm -DCMAKE_CXX_FLAGS='-pipe -march=native -ggdb3 -flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing'
-- The CXX compiler identification is GNU 15.0.0
-- The C compiler identification is GNU 15.0.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++-15 - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc-15 - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found Git: /usr/bin/git (found version "2.44.2")
-- CPM: Adding package AddBoost.CMake@ (main at /home/paxu/.cache/cpm/addboost.cmake/7f2f1b531b72316af1def09259a71465379d6535)
-- Tests that are with Boost::uuid are enabled.
-- Boost: Debug build, static libraries, MPI OFF, Python OFF, testing OFF
-- Boost: libraries included: ;uuid
CMake Warning at /home/paxu/.cache/cpm/boost/4114d97be4ef0aa34d469d86b53d263424992d65/tools/cmake/include/BoostRoot.cmake:252 (message):
  Library '' given in BOOST_INCLUDE_LIBRARIES has not been found.
Call Stack (most recent call first):
  /home/paxu/.cache/cpm/boost/4114d97be4ef0aa34d469d86b53d263424992d65/CMakeLists.txt:20 (include)

-- CPM: Adding package<EMAIL_ADDRESS>(1.86.0 at /home/paxu/.cache/cpm/boost/4114d97be4ef0aa34d469d86b53d263424992d65)
-- Tests that are experimental and with Boost::uuid are enabled
-- Tests that are for Windows only are disabled, because CMake
  thinks you are on a not so Windows-like system. Check yourself: Linux
-- Tests that are UNIX-only are enabled
-- Tests that are experimental are enabled
-- Performing Test HAVE_FFI_CALL
-- Performing Test HAVE_FFI_CALL - Success
-- Found FFI: /usr/lib64/libffi.so
-- Found ZLIB: /usr/lib64/libz.so (found version "1.3.1")
-- Found zstd: /usr/lib64/libzstd.so
-- Found LibXml2: /usr/lib64/libxml2.so (found version "2.12.7")
-- Found CURL: /usr/lib64/libcurl.so (found version "8.8.0")
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found OpenSSL: /usr/lib64/libcrypto.so (found suitable version "3.0.13", minimum required is "3.0.0") found components: Crypto SSL
-- Found Brotli: /usr/include  found components: common encoder decoder
-- Found httplib: /usr/lib64/libhttplib.so.0.15.3 (found version "0.15.3")
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- Benchmarks that are Windows-only are NOT going to be build, because
  CMake thinks you are not on something Windows-like
-- Benchmarks that are Linux-only are going to be build.
-- Benchmarks that are experimental and for Linux only are
    NOT going to be build, because fast_io_ENABLE_BENCHMARKS_EXPERIMENTAL is set to
  1
-- Performing Test HAVE_STDATOMIC
-- Performing Test HAVE_STDATOMIC - Success
-- Found WrapAtomic: TRUE
-- Benchmarks with Qt that are experimental are going to be build.
-- Benchmarks with Qt are going to be build with Qt6.
-- CPM: Adding package dragonbox@ (master at /home/paxu/.cache/cpm/dragonbox/7695f05b5d3939cd583585d3bee17807cf67d1d3)
-- Benchmarks with dragonbox are going to be build.
-- Benchmarks that are experimental and with dragonbox are NOT going to be build,
  because fast_io_ENABLE_BENCHMARKS_EXPERIMENTAL is set to
  1
--
-- Override standard malloc (MI_OVERRIDE=ON)
-- Performing Test mi_has_libpthread
-- Performing Test mi_has_libpthread - Success
-- Performing Test mi_has_librt
-- Performing Test mi_has_librt - Success
-- Performing Test mi_has_libatomic
-- Performing Test mi_has_libatomic - Success
--
-- Library base name: mimalloc-debug
-- Version          : 2.1
-- Build type       : debug
-- C Compiler       : /usr/bin/gcc-15
-- Compiler flags   : -Wall;-Wextra;-Wno-unknown-pragmas;-fvisibility=hidden;-Wstrict-prototypes;-ftls-model=initial-exec;-fno-builtin-malloc
-- Compiler defines :
-- Link libraries   : pthread;rt;atomic
-- Build targets    : shared;static;object;tests
--
-- CPM: Adding package<EMAIL_ADDRESS>(v2.1.7 at /home/paxu/.cache/cpm/mimalloc/72f0d2cb40cc97ffde9214409da7eaed994d09ec)
-- Benchmarks with mimalloc are going to be build.
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- Benchmarks that requires LLVM libraries are going to be build.
-- Benchmarks that are experimental and with LLVM are NOT going to be build,
  because fast_io_ENABLE_BENCHMARKS_EXPERIMENTAL is set to
  1
-- Benchmarks that are experimental are going to be build.
-- Android only example is added as build target.
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/gcc-15
=> Project : cryptopp-cmake v8.9.0
-- Crypto++ auto fetched at: /home/paxu/code/experiments/fast_io_cmake_clone/build/_deps/cryptopp-cmake-build/cryptopp
-- Using branch master for tests
-- Adding unit test: disable-asm
-- Adding unit test: include-prefix
-- Adding unit test: no-install
-- Adding unit test: standard-cpm
-- Adding install integration test: int-install-default
-- Adding install integration test: int-install-prefix
=> Module : cryptopp
-- [cryptopp] CMake version 3.28.5
-- [cryptopp] System Linux
-- [cryptopp] Processor x86_64
-- [cryptopp] CMAKE_HOST_SYSTEM_PROCESSOR : x86_64
-- [cryptopp]      CMAKE_SYSTEM_PROCESSOR : x86_64
-- [cryptopp] Target architecture detected as: x86_64 -> CRYPTOPP_AMD64
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE2
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE2 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE3
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE3 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSSE3
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSSE3 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE41
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE41 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE42
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE42 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_CLMUL
-- [cryptopp] Performing Test CRYPTOPP_HAVE_CLMUL - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AESNI
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AESNI - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AVX
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AVX - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AVX2
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AVX2 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SHANI
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SHANI - Success
-- [cryptopp] Generating cmake package config files
-- [cryptopp] Generating pkgconfig files
-- [cryptopp] Platform: x86_64
-- [cryptopp] Compiler definitions:
-- [cryptopp] Compiler options: -pipe -march=native -ggdb3 -flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -fno-devirtualize
-- [cryptopp] Build type: Debug
-- CPM: Adding package cryptopp-cmake@ (master at /home/paxu/.cache/cpm/cryptopp-cmake/73b344efa35049118ad849a4726500346a39cc97)
-- Examples with CryptoPP are added using cryptopp-cmake.
-- Found OpenSSL: /usr/lib64/libcrypto.so (found version "3.0.13") found components: Crypto SSL
-- Examples with OpenSSL are going to be build.
-- examples with Qt that are experimental are going to be build.
-- examples with Qt are going to be build with Qt6.
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- examples that requires LLVM libraries are going to be build.
-- Examples that are experimental and require LLVM libraries are going to be build.
-- Examples that are Windows-only are NOT going to be build,
  because it seems the system that CMake is running on seems to be not so Windows-like.
-- Found Lua: /usr/lib64/liblua5.4.so;/usr/lib64/libm.so (found version "5.4.6")
-- Examples with Lua are going to be build.
-- Found Python: /usr/include/python3.12 (found version "3.12.3") found components: Development Development.Module Development.Embed
-- Examples with Python are going to be build.
-- Examples with Emscripten, which are WASM only, are NOT going to
  be build, because you are not using Emscripten's CMake toolchain.
-- Found PkgConfig: /usr/bin/pkg-config (found version "2.2.0")
-- Checking for module 'libpulse-simple'
--   Found libpulse-simple, version 17.0
-- Examples with PulseAudio's libpulse are going to be build.
-- Example with kernel driver for Linux is going to be build.
-- Example with kernel driver for Windows is NOT going to be
  build, because CMake thinks you are not on something Windows-like.
-- Examples that are experimental are going to be build.
-- CPM: Adding package<EMAIL_ADDRESS>(v1.11.2 to /home/paxu/.cache/cpm/packageproject.cmake/22a22b995c2ac2f08b6a2de2a824df412150cf64)
CMake Warning at /usr/share/cmake/Modules/GenerateExportHeader.cmake:416 (message):
  This macro can only be used with libraries
Call Stack (most recent call first):
  /home/paxu/.cache/cpm/packageproject.cmake/22a22b995c2ac2f08b6a2de2a824df412150cf64/CMakeLists.txt:49 (generate_export_header)
  CMakeLists.txt:135 (packageProject)

-- Configuring done (8.3s)
-- Generating done (0.2s)
-- Build files have been written to: /home/paxu/code/experiments/fast_io_cmake_clone/build

wgetpaste -s 0x0 -c 'cmake --build ./build/ -j24 -- -k 0'
Your paste can be seen here: http://0x0.st/X47c.txt

 without "experimental" targets

 cmake -S. -Bbuild -DCMAKE_CXX_COMPILER=g++-15 -DCMAKE_C_COMPILER=gcc-15 -DCMAKE_GENERATOR="Ninja" -DCMAKE_BUILD_TYPE=Debug -Dfast_io_ENABLE_TESTS_EXPERIMENTAL=0 -Dfast_io_ENABLE_FUZZING_EXPERIMENTAL=0 -Dfast_io_ENABLE_BENCHMARKS_EXPERIMENTAL=0 -Dfast_io_ENABLE_EXAMPLES_EXPERIMENTAL=0 -DCPM_SOURCE_CACHE=~/.cache/cpm -DCMAKE_CXX_FLAGS='-pipe -march=native -ggdb3 -flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing'

-- The CXX compiler identification is GNU 15.0.0
-- The C compiler identification is GNU 15.0.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++-15 - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc-15 - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found Git: /usr/bin/git (found version "2.44.2")
-- CPM: Adding package AddBoost.CMake@ (main at /home/paxu/.cache/cpm/addboost.cmake/7f2f1b531b72316af1def09259a71465379d6535)
-- Tests that are with Boost::uuid are enabled.
-- Tests that are experimental and with Boost::UUID are disabled, because fast_io_ENABLE_TESTS_EXPERIMENTAL is set to 0
-- Tests that are for Windows only are disabled, because CMake
  thinks you are on a not so Windows-like system. Check yourself: Linux
-- Tests that are UNIX-only are enabled
-- Tests that are experimental are disabled, because fast_io_ENABLE_TESTS_EXPERIMENTAL is set to 0
-- Performing Test HAVE_FFI_CALL
-- Performing Test HAVE_FFI_CALL - Success
-- Found FFI: /usr/lib64/libffi.so
-- Found ZLIB: /usr/lib64/libz.so (found version "1.3.1")
-- Found zstd: /usr/lib64/libzstd.so
-- Found LibXml2: /usr/lib64/libxml2.so (found version "2.12.7")
-- Found CURL: /usr/lib64/libcurl.so (found version "8.8.0")
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found OpenSSL: /usr/lib64/libcrypto.so (found suitable version "3.0.13", minimum required is "3.0.0") found components: Crypto SSL
-- Found Brotli: /usr/include  found components: common encoder decoder
-- Found httplib: /usr/lib64/libhttplib.so.0.15.3 (found version "0.15.3")
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- Benchmarks that are Windows-only are NOT going to be build, because
  CMake thinks you are not on something Windows-like
-- Benchmarks that are Linux-only are going to be build.
-- Benchmarks that are experimental and for Linux only are
    NOT going to be build, because fast_io_ENABLE_BENCHMARKS_EXPERIMENTAL is set to
  0
-- Performing Test HAVE_STDATOMIC
-- Performing Test HAVE_STDATOMIC - Success
-- Found WrapAtomic: TRUE
-- Benchmarks with Qt that are experimental are NOT going to
    be build because fast_io_ENABLE_BENCHMARKS_EXPERIMENTAL is set to 0
-- Benchmarks with Qt are going to be build with Qt6.
-- CPM: Adding package dragonbox@ (master at /home/paxu/.cache/cpm/dragonbox/7695f05b5d3939cd583585d3bee17807cf67d1d3)
-- Benchmarks with dragonbox are going to be build.
-- Benchmarks that are experimental and with dragonbox are NOT going to be build,
  because fast_io_ENABLE_BENCHMARKS_EXPERIMENTAL is set to
  0
--
-- Override standard malloc (MI_OVERRIDE=ON)
-- Performing Test mi_has_libpthread
-- Performing Test mi_has_libpthread - Success
-- Performing Test mi_has_librt
-- Performing Test mi_has_librt - Success
-- Performing Test mi_has_libatomic
-- Performing Test mi_has_libatomic - Success
--
-- Library base name: mimalloc-debug
-- Version          : 2.1
-- Build type       : debug
-- C Compiler       : /usr/bin/gcc-15
-- Compiler flags   : -Wall;-Wextra;-Wno-unknown-pragmas;-fvisibility=hidden;-Wstrict-prototypes;-ftls-model=initial-exec;-fno-builtin-malloc
-- Compiler defines :
-- Link libraries   : pthread;rt;atomic
-- Build targets    : shared;static;object;tests
--
-- CPM: Adding package<EMAIL_ADDRESS>(v2.1.7 at /home/paxu/.cache/cpm/mimalloc/72f0d2cb40cc97ffde9214409da7eaed994d09ec)
-- Benchmarks with mimalloc are going to be build.
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- Benchmarks that requires LLVM libraries are going to be build.
-- Benchmarks that are experimental and with LLVM are NOT going to be build,
  because fast_io_ENABLE_BENCHMARKS_EXPERIMENTAL is set to
  0
-- Benchmarks that are experimental are NOT going to be build,
  becuase fast_io_ENABLE_BENCHMARKS_EXPERIMENTAL is set to
  0
-- Android only example is added as build target.
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/gcc-15
=> Project : cryptopp-cmake v8.9.0
-- Crypto++ auto fetched at: /home/paxu/code/experiments/fast_io_cmake_clone/build/_deps/cryptopp-cmake-build/cryptopp
-- Using branch master for tests
-- Adding unit test: disable-asm
-- Adding unit test: include-prefix
-- Adding unit test: no-install
-- Adding unit test: standard-cpm
-- Adding install integration test: int-install-default
-- Adding install integration test: int-install-prefix
=> Module : cryptopp
-- [cryptopp] CMake version 3.28.5
-- [cryptopp] System Linux
-- [cryptopp] Processor x86_64
-- [cryptopp] CMAKE_HOST_SYSTEM_PROCESSOR : x86_64
-- [cryptopp]      CMAKE_SYSTEM_PROCESSOR : x86_64
-- [cryptopp] Target architecture detected as: x86_64 -> CRYPTOPP_AMD64
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE2
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE2 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE3
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE3 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSSE3
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSSE3 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE41
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE41 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE42
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE42 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_CLMUL
-- [cryptopp] Performing Test CRYPTOPP_HAVE_CLMUL - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AESNI
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AESNI - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AVX
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AVX - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AVX2
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AVX2 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SHANI
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SHANI - Success
-- [cryptopp] Generating cmake package config files
-- [cryptopp] Generating pkgconfig files
-- [cryptopp] Platform: x86_64
-- [cryptopp] Compiler definitions:
-- [cryptopp] Compiler options: -pipe -march=native -ggdb3 -flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -fno-devirtualize
-- [cryptopp] Build type: Debug
-- CPM: Adding package cryptopp-cmake@ (master at /home/paxu/.cache/cpm/cryptopp-cmake/73b344efa35049118ad849a4726500346a39cc97)
-- Examples with CryptoPP are added using cryptopp-cmake.
-- Found OpenSSL: /usr/lib64/libcrypto.so (found version "3.0.13") found components: Crypto SSL
-- Examples with OpenSSL are going to be build.
-- examples with Qt that are experimental are NOT going to
    be build because fast_io_ENABLE_EXAMPLES_EXPERIMENTAL is set to 0
-- examples with Qt are going to be build with Qt6.
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- examples that requires LLVM libraries are going to be build.
-- Examples that are experimental and require LLVM libraries are NOT going to be build,
    because fast_io_ENABLE_EXAMPLES_EXPERIMENTAL is set to 0.
-- Examples that are Windows-only are NOT going to be build,
  because it seems the system that CMake is running on seems to be not so Windows-like.
-- Found Lua: /usr/lib64/liblua5.4.so;/usr/lib64/libm.so (found version "5.4.6")
-- Examples with Lua are going to be build.
-- Found Python: /usr/include/python3.12 (found version "3.12.3") found components: Development Development.Module Development.Embed
-- Examples with Python are going to be build.
-- Examples with Emscripten, which are WASM only, are NOT going to
  be build, because you are not using Emscripten's CMake toolchain.
-- Found PkgConfig: /usr/bin/pkg-config (found version "2.2.0")
-- Checking for module 'libpulse-simple'
--   Found libpulse-simple, version 17.0
-- Examples with PulseAudio's libpulse are going to be build.
-- Example with kernel driver for Linux is going to be build.
-- Example with kernel driver for Windows is NOT going to be
  build, because CMake thinks you are not on something Windows-like.
-- Examples that are experimental are NOT going to be build,
  because fast_io_ENABLE_EXAMPLES_EXPERIMENTAL is set to 0.
-- CPM: Adding package<EMAIL_ADDRESS>(v1.11.2 at /home/paxu/.cache/cpm/packageproject.cmake/22a22b995c2ac2f08b6a2de2a824df412150cf64)
CMake Warning at /usr/share/cmake/Modules/GenerateExportHeader.cmake:416 (message):
  This macro can only be used with libraries
Call Stack (most recent call first):
  /home/paxu/.cache/cpm/packageproject.cmake/22a22b995c2ac2f08b6a2de2a824df412150cf64/CMakeLists.txt:49 (generate_export_header)
  CMakeLists.txt:135 (packageProject)

-- Configuring done (9.3s)
-- Generating done (0.1s)
-- Build files have been written to: /home/paxu/code/experiments/fast_io_cmake_clone/build

wgetpaste -s 0x0 -c 'cmake --build ./build/ -j24 -- -k 0'
Your paste can be seen here: http://0x0.st/X471.txt

clang++-20

 clang++-20 --version
clang version 20.0.0gitfd7d7882
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm/20/bin
Build config: +assertions
Configuration file: /etc/clang/x86_64-pc-linux-gnu-clang++.cfg

 with "experimental" targets

 cmake -S. -Bbuild -DCMAKE_CXX_COMPILER=clang++-20 -DCMAKE_C_COMPILER=clang-20 -DCMAKE_GENERATOR="Ninja" -DCMAKE_BUILD_TYPE=Debug -Dfast_io_ENABLE_TESTS_EXPERIMENTAL=1 -Dfast_io_ENABLE_FUZZING_EXPERIMENTAL=1 -Dfast_io_ENABLE_BENCHMARKS_EXPERIMENTAL=1 -Dfast_io_ENABLE_EXAMPLES_EXPERIMENTAL=1 -DCPM_SOURCE_CACHE=~/.cache/cpm -DCMAKE_CXX_FLAGS='-pipe -march=native -ggdb3 -flto -Werror=odr -Werror=strict-aliasing'

-- The CXX compiler identification is Clang 20.0.0
-- The C compiler identification is Clang 20.0.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/lib/llvm/20/bin/clang++-20 - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/lib/llvm/20/bin/clang-20 - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found Git: /usr/bin/git (found version "2.44.2")
-- CPM: Adding package AddBoost.CMake@ (main at /home/paxu/.cache/cpm/addboost.cmake/7f2f1b531b72316af1def09259a71465379d6535)
-- Tests that are with Boost::uuid are enabled.
-- Boost: Debug build, static libraries, MPI OFF, Python OFF, testing OFF
-- Boost: libraries included: ;uuid
CMake Warning at /home/paxu/.cache/cpm/boost/4114d97be4ef0aa34d469d86b53d263424992d65/tools/cmake/include/BoostRoot.cmake:252 (message):
  Library '' given in BOOST_INCLUDE_LIBRARIES has not been found.
Call Stack (most recent call first):
  /home/paxu/.cache/cpm/boost/4114d97be4ef0aa34d469d86b53d263424992d65/CMakeLists.txt:20 (include)

-- CPM: Adding package<EMAIL_ADDRESS>(1.86.0 at /home/paxu/.cache/cpm/boost/4114d97be4ef0aa34d469d86b53d263424992d65)
-- Tests that are experimental and with Boost::uuid are enabled
-- Tests that are for Windows only are disabled, because CMake
  thinks you are on a not so Windows-like system. Check yourself: Linux
-- Tests that are UNIX-only are enabled
-- Tests that are experimental are enabled
-- Performing Test HAVE_FFI_CALL
-- Performing Test HAVE_FFI_CALL - Success
-- Found FFI: /usr/lib64/libffi.so
-- Found ZLIB: /usr/lib64/libz.so (found version "1.3.1")
-- Found zstd: /usr/lib64/libzstd.so
-- Found LibXml2: /usr/lib64/libxml2.so (found version "2.12.7")
-- Found CURL: /usr/lib64/libcurl.so (found version "8.8.0")
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found OpenSSL: /usr/lib64/libcrypto.so (found suitable version "3.0.13", minimum required is "3.0.0") found components: Crypto SSL
-- Found Brotli: /usr/include  found components: common encoder decoder
-- Found httplib: /usr/lib64/libhttplib.so.0.15.3 (found version "0.15.3")
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- Benchmarks that are Windows-only are NOT going to be build, because
  CMake thinks you are not on something Windows-like
-- Benchmarks that are Linux-only are going to be build.
-- Benchmarks that are experimental and for Linux only are
    NOT going to be build, because fast_io_ENABLE_BENCHMARKS_EXPERIMENTAL is set to
  1
-- Performing Test HAVE_STDATOMIC
-- Performing Test HAVE_STDATOMIC - Success
-- Found WrapAtomic: TRUE
-- Benchmarks with Qt that are experimental are going to be build.
-- Benchmarks with Qt are going to be build with Qt6.
-- CPM: Adding package dragonbox@ (master at /home/paxu/.cache/cpm/dragonbox/7695f05b5d3939cd583585d3bee17807cf67d1d3)
-- Benchmarks with dragonbox are going to be build.
-- Benchmarks that are experimental and with dragonbox are NOT going to be build,
  because fast_io_ENABLE_BENCHMARKS_EXPERIMENTAL is set to
  1
--
-- Override standard malloc (MI_OVERRIDE=ON)
-- Performing Test mi_has_libpthread
-- Performing Test mi_has_libpthread - Success
-- Performing Test mi_has_librt
-- Performing Test mi_has_librt - Success
-- Performing Test mi_has_libatomic
-- Performing Test mi_has_libatomic - Success
--
-- Library base name: mimalloc-debug
-- Version          : 2.1
-- Build type       : debug
-- C Compiler       : /usr/lib/llvm/20/bin/clang-20
-- Compiler flags   : -Wall;-Wextra;-Wpedantic;-Wno-unknown-pragmas;-fvisibility=hidden;-Wstrict-prototypes;-Wno-static-in-inline;-ftls-model=initial-exec;-fno-builtin-malloc
-- Compiler defines :
-- Link libraries   : pthread;rt;atomic
-- Build targets    : shared;static;object;tests
--
-- CPM: Adding package<EMAIL_ADDRESS>(v2.1.7 at /home/paxu/.cache/cpm/mimalloc/72f0d2cb40cc97ffde9214409da7eaed994d09ec)
-- Benchmarks with mimalloc are going to be build.
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- Benchmarks that requires LLVM libraries are going to be build.
-- Benchmarks that are experimental and with LLVM are NOT going to be build,
  because fast_io_ENABLE_BENCHMARKS_EXPERIMENTAL is set to
  1
-- Benchmarks that are experimental are going to be build.
-- Android only example is added as build target.
-- The ASM compiler identification is Clang with GNU-like command-line
-- Found assembler: /usr/lib/llvm/20/bin/clang-20
=> Project : cryptopp-cmake v8.9.0
-- Crypto++ auto fetched at: /home/paxu/code/experiments/fast_io_cmake_clone/build/_deps/cryptopp-cmake-build/cryptopp
-- Using branch master for tests
-- Adding unit test: disable-asm
-- Adding unit test: include-prefix
-- Adding unit test: no-install
-- Adding unit test: standard-cpm
-- Adding install integration test: int-install-default
-- Adding install integration test: int-install-prefix
=> Module : cryptopp
-- [cryptopp] CMake version 3.28.5
-- [cryptopp] System Linux
-- [cryptopp] Processor x86_64
-- [cryptopp] CMAKE_HOST_SYSTEM_PROCESSOR : x86_64
-- [cryptopp]      CMAKE_SYSTEM_PROCESSOR : x86_64
-- [cryptopp] Target architecture detected as: x86_64 -> CRYPTOPP_AMD64
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE2
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE2 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE3
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE3 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSSE3
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSSE3 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE41
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE41 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE42
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE42 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_CLMUL
-- [cryptopp] Performing Test CRYPTOPP_HAVE_CLMUL - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AESNI
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AESNI - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AVX
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AVX - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AVX2
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AVX2 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SHANI
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SHANI - Success
-- [cryptopp] Generating cmake package config files
-- [cryptopp] Generating pkgconfig files
-- [cryptopp] Platform: x86_64
-- [cryptopp] Compiler definitions:
-- [cryptopp] Compiler options: -pipe -march=native -ggdb3 -flto -Werror=odr -Werror=strict-aliasing
-- [cryptopp] Build type: Debug
-- CPM: Adding package cryptopp-cmake@ (master at /home/paxu/.cache/cpm/cryptopp-cmake/73b344efa35049118ad849a4726500346a39cc97)
-- Examples with CryptoPP are added using cryptopp-cmake.
-- Found OpenSSL: /usr/lib64/libcrypto.so (found version "3.0.13") found components: Crypto SSL
-- Examples with OpenSSL are going to be build.
-- examples with Qt that are experimental are going to be build.
-- examples with Qt are going to be build with Qt6.
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- examples that requires LLVM libraries are going to be build.
-- Examples that are experimental and require LLVM libraries are going to be build.
-- Examples that are Windows-only are NOT going to be build,
  because it seems the system that CMake is running on seems to be not so Windows-like.
-- Found Lua: /usr/lib64/liblua5.4.so;/usr/lib64/libm.so (found version "5.4.6")
-- Examples with Lua are going to be build.
-- Found Python: /usr/include/python3.12 (found version "3.12.3") found components: Development Development.Module Development.Embed
-- Examples with Python are going to be build.
-- Examples with Emscripten, which are WASM only, are NOT going to
  be build, because you are not using Emscripten's CMake toolchain.
-- Found PkgConfig: /usr/bin/pkg-config (found version "2.2.0")
-- Checking for module 'libpulse-simple'
--   Found libpulse-simple, version 17.0
-- Examples with PulseAudio's libpulse are going to be build.
-- Example with kernel driver for Linux is going to be build.
-- Example with kernel driver for Windows is NOT going to be
  build, because CMake thinks you are not on something Windows-like.
-- Examples that are experimental are going to be build.
-- CPM: Adding package<EMAIL_ADDRESS>(v1.11.2 at /home/paxu/.cache/cpm/packageproject.cmake/22a22b995c2ac2f08b6a2de2a824df412150cf64)
CMake Warning at /usr/share/cmake/Modules/GenerateExportHeader.cmake:416 (message):
  This macro can only be used with libraries
Call Stack (most recent call first):
  /home/paxu/.cache/cpm/packageproject.cmake/22a22b995c2ac2f08b6a2de2a824df412150cf64/CMakeLists.txt:49 (generate_export_header)
  CMakeLists.txt:135 (packageProject)

-- Configuring done (6.3s)
-- Generating done (0.1s)
-- Build files have been written to: /home/paxu/code/experiments/fast_io_cmake_clone/build

wgetpaste -s 0x0 -c 'cmake --build ./build/ -j24 -- -k 0'
Your paste can be seen here: http://0x0.st/X47W.txt

  without "experimental" targets

 cmake -S. -Bbuild -DCMAKE_CXX_COMPILER=clang++-20 -DCMAKE_C_COMPILER=clang-20 -DCMAKE_GENERATOR="Ninja" -DCMAKE_BUILD_TYPE=Debug -Dfast_io_ENABLE_TESTS_EXPERIMENTAL=0 -Dfast_io_ENABLE_FUZZING_EXPERIMENTAL=0 -Dfast_io_ENABLE_BENCHMARKS_EXPERIMENTAL=0 -Dfast_io_ENABLE_EXAMPLES_EXPERIMENTAL=0 -DCPM_SOURCE_CACHE=~/.cache/cpm -DCMAKE_CXX_FLAGS='-pipe -march=native -ggdb3 -flto -Werror=odr -Werror=strict-aliasing'

-- The CXX compiler identification is Clang 20.0.0
-- The C compiler identification is Clang 20.0.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/lib/llvm/20/bin/clang++-20 - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/lib/llvm/20/bin/clang-20 - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Found Git: /usr/bin/git (found version "2.44.2")
-- CPM: Adding package AddBoost.CMake@ (main at /home/paxu/.cache/cpm/addboost.cmake/7f2f1b531b72316af1def09259a71465379d6535)
-- Tests that are with Boost::uuid are enabled.
-- Tests that are experimental and with Boost::UUID are disabled, because fast_io_ENABLE_TESTS_EXPERIMENTAL is set to 0
-- Tests that are for Windows only are disabled, because CMake
  thinks you are on a not so Windows-like system. Check yourself: Linux
-- Tests that are UNIX-only are enabled
-- Tests that are experimental are disabled, because fast_io_ENABLE_TESTS_EXPERIMENTAL is set to 0
-- Performing Test HAVE_FFI_CALL
-- Performing Test HAVE_FFI_CALL - Success
-- Found FFI: /usr/lib64/libffi.so
-- Found ZLIB: /usr/lib64/libz.so (found version "1.3.1")
-- Found zstd: /usr/lib64/libzstd.so
-- Found LibXml2: /usr/lib64/libxml2.so (found version "2.12.7")
-- Found CURL: /usr/lib64/libcurl.so (found version "8.8.0")
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found OpenSSL: /usr/lib64/libcrypto.so (found suitable version "3.0.13", minimum required is "3.0.0") found components: Crypto SSL
-- Found Brotli: /usr/include  found components: common encoder decoder
-- Found httplib: /usr/lib64/libhttplib.so.0.15.3 (found version "0.15.3")
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- Benchmarks that are Windows-only are NOT going to be build, because
  CMake thinks you are not on something Windows-like
-- Benchmarks that are Linux-only are going to be build.
-- Benchmarks that are experimental and for Linux only are
    NOT going to be build, because fast_io_ENABLE_BENCHMARKS_EXPERIMENTAL is set to
  0
-- Performing Test HAVE_STDATOMIC
-- Performing Test HAVE_STDATOMIC - Success
-- Found WrapAtomic: TRUE
-- Benchmarks with Qt that are experimental are NOT going to
    be build because fast_io_ENABLE_BENCHMARKS_EXPERIMENTAL is set to 0
-- Benchmarks with Qt are going to be build with Qt6.
-- CPM: Adding package dragonbox@ (master at /home/paxu/.cache/cpm/dragonbox/7695f05b5d3939cd583585d3bee17807cf67d1d3)
-- Benchmarks with dragonbox are going to be build.
-- Benchmarks that are experimental and with dragonbox are NOT going to be build,
  because fast_io_ENABLE_BENCHMARKS_EXPERIMENTAL is set to
  0
--
-- Override standard malloc (MI_OVERRIDE=ON)
-- Performing Test mi_has_libpthread
-- Performing Test mi_has_libpthread - Success
-- Performing Test mi_has_librt
-- Performing Test mi_has_librt - Success
-- Performing Test mi_has_libatomic
-- Performing Test mi_has_libatomic - Success
--
-- Library base name: mimalloc-debug
-- Version          : 2.1
-- Build type       : debug
-- C Compiler       : /usr/lib/llvm/20/bin/clang-20
-- Compiler flags   : -Wall;-Wextra;-Wpedantic;-Wno-unknown-pragmas;-fvisibility=hidden;-Wstrict-prototypes;-Wno-static-in-inline;-ftls-model=initial-exec;-fno-builtin-malloc
-- Compiler defines :
-- Link libraries   : pthread;rt;atomic
-- Build targets    : shared;static;object;tests
--
-- CPM: Adding package<EMAIL_ADDRESS>(v2.1.7 at /home/paxu/.cache/cpm/mimalloc/72f0d2cb40cc97ffde9214409da7eaed994d09ec)
-- Benchmarks with mimalloc are going to be build.
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- Benchmarks that requires LLVM libraries are going to be build.
-- Benchmarks that are experimental and with LLVM are NOT going to be build,
  because fast_io_ENABLE_BENCHMARKS_EXPERIMENTAL is set to
  0
-- Benchmarks that are experimental are NOT going to be build,
  becuase fast_io_ENABLE_BENCHMARKS_EXPERIMENTAL is set to
  0
-- Android only example is added as build target.
-- The ASM compiler identification is Clang with GNU-like command-line
-- Found assembler: /usr/lib/llvm/20/bin/clang-20
=> Project : cryptopp-cmake v8.9.0
-- Crypto++ auto fetched at: /home/paxu/code/experiments/fast_io_cmake_clone/build/_deps/cryptopp-cmake-build/cryptopp
-- Using branch master for tests
-- Adding unit test: disable-asm
-- Adding unit test: include-prefix
-- Adding unit test: no-install
-- Adding unit test: standard-cpm
-- Adding install integration test: int-install-default
-- Adding install integration test: int-install-prefix
=> Module : cryptopp
-- [cryptopp] CMake version 3.28.5
-- [cryptopp] System Linux
-- [cryptopp] Processor x86_64
-- [cryptopp] CMAKE_HOST_SYSTEM_PROCESSOR : x86_64
-- [cryptopp]      CMAKE_SYSTEM_PROCESSOR : x86_64
-- [cryptopp] Target architecture detected as: x86_64 -> CRYPTOPP_AMD64
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE2
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE2 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE3
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE3 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSSE3
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSSE3 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE41
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE41 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE42
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SSE42 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_CLMUL
-- [cryptopp] Performing Test CRYPTOPP_HAVE_CLMUL - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AESNI
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AESNI - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AVX
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AVX - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AVX2
-- [cryptopp] Performing Test CRYPTOPP_HAVE_AVX2 - Success
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SHANI
-- [cryptopp] Performing Test CRYPTOPP_HAVE_SHANI - Success
-- [cryptopp] Generating cmake package config files
-- [cryptopp] Generating pkgconfig files
-- [cryptopp] Platform: x86_64
-- [cryptopp] Compiler definitions:
-- [cryptopp] Compiler options: -pipe -march=native -ggdb3 -flto -Werror=odr -Werror=strict-aliasing
-- [cryptopp] Build type: Debug
-- CPM: Adding package cryptopp-cmake@ (master at /home/paxu/.cache/cpm/cryptopp-cmake/73b344efa35049118ad849a4726500346a39cc97)
-- Examples with CryptoPP are added using cryptopp-cmake.
-- Found OpenSSL: /usr/lib64/libcrypto.so (found version "3.0.13") found components: Crypto SSL
-- Examples with OpenSSL are going to be build.
-- examples with Qt that are experimental are NOT going to
    be build because fast_io_ENABLE_EXAMPLES_EXPERIMENTAL is set to 0
-- examples with Qt are going to be build with Qt6.
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- LLVM_INCLUDE_DIRS: /usr/lib/llvm/20/include
-- LLVM_FOUND: 1
-- LLVM_VERSION: 20.0.0gitfd7d7882
-- examples that requires LLVM libraries are going to be build.
-- Examples that are experimental and require LLVM libraries are NOT going to be build,
    because fast_io_ENABLE_EXAMPLES_EXPERIMENTAL is set to 0.
-- Examples that are Windows-only are NOT going to be build,
  because it seems the system that CMake is running on seems to be not so Windows-like.
-- Found Lua: /usr/lib64/liblua5.4.so;/usr/lib64/libm.so (found version "5.4.6")
-- Examples with Lua are going to be build.
-- Found Python: /usr/include/python3.12 (found version "3.12.3") found components: Development Development.Module Development.Embed
-- Examples with Python are going to be build.
-- Examples with Emscripten, which are WASM only, are NOT going to
  be build, because you are not using Emscripten's CMake toolchain.
-- Found PkgConfig: /usr/bin/pkg-config (found version "2.2.0")
-- Checking for module 'libpulse-simple'
--   Found libpulse-simple, version 17.0
-- Examples with PulseAudio's libpulse are going to be build.
-- Example with kernel driver for Linux is going to be build.
-- Example with kernel driver for Windows is NOT going to be
  build, because CMake thinks you are not on something Windows-like.
-- Examples that are experimental are NOT going to be build,
  because fast_io_ENABLE_EXAMPLES_EXPERIMENTAL is set to 0.
-- CPM: Adding package<EMAIL_ADDRESS>(v1.11.2 at /home/paxu/.cache/cpm/packageproject.cmake/22a22b995c2ac2f08b6a2de2a824df412150cf64)
CMake Warning at /usr/share/cmake/Modules/GenerateExportHeader.cmake:416 (message):
  This macro can only be used with libraries
Call Stack (most recent call first):
  /home/paxu/.cache/cpm/packageproject.cmake/22a22b995c2ac2f08b6a2de2a824df412150cf64/CMakeLists.txt:49 (generate_export_header)
  CMakeLists.txt:135 (packageProject)

-- Configuring done (7.9s)
-- Generating done (0.1s)
-- Build files have been written to: /home/paxu/code/experiments/fast_io_cmake_clone/build

wgetpaste -s 0x0 -c 'cmake --build ./build/ -j24 -- -k 0'
Your paste can be seen here: http://0x0.st/X47J.txt

a lot of things got updated.


No OpenIDConnect method to obtain id_token ?

Hi,
Is there any option to obtain id_token using this tool?  I can get access_token and refresh_token using
access_token = oidc.get_access_token()
refresh_token = oidc.get_refresh_token()

But i didn't find an option for id_token. Is there any way ?

Ok, I got a method,
from oauth2client.client import OAuth2Credentials
id_token_jwt = OAuth2Credentials.from_json(oidc.credentials_store[info.get('sub')]).id_token_jwt


Rename httpclient

This is branched on top of https://github.com/sigstore/sigstore/pull/18 , so that can be


⚠ Processors has degraded performance

In b833a84, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 179 ms

Resolved: Processors performance has improved in 2fd790b.

Resolved: Processors performance has improved in 7f95276.


[Functionality]] Link "Всі Партнери"is not displayed on the  StreetCode page for editing..

**Environment:**Windows 10,  Google Chrom.
Reproducible: always.
Build found:
Preconditions
Open the StreetCode page for editing
Steps to reproduce

Go to   the main page' StreetCode page for editing..'
Scroll main the StreetCode page to block “Наші партнери “
Click on the link “ Всі партнери”

Actual result
link “ Всі партнери”  is   missing
Expected result
page “ Всі партнери”  is opened
User story and test case links
User story #136
Test case #1520

It is not clear from the title whether it is on the main page or the StreetCode page.


canvas 1.2.4 is broken

I forced version 1.2.3, waiting for a fix: https://github.com/Automattic/node-canvas/issues/588

fixed with 615e6bd4df682fab27b66c109b044d0337dc24ca


Fail to load texture

Been trying extensively to load a texture into a (ground type) model, but continue to get this error.
I am able to see the render on a latest three js version environment, but for some reason I continue to get this error within spacevr

would really appreciate any help!!

can i see the code?

pretty sure this is unrelated to spacesvr, or if it is then probably due to to #84 ... i saw you fixed it recently so lmk if i'm wrong, but closing for now


 This does not test things
that cannot currently be guaranteed to be represented in a schema, for example,
normalized URL requirements and optional "format" for "pattern".
Closes #244

I hope I didn't get too many false/true validity tests wrong as typos due to faulty cut & paste.

Maybe I’ll split this up more in each file...

Ok, I added a second commit that groups every better and also orders them as they appear in the spec.

This also now closes #301.

hope I didn't get too many false/true validity tests wrong

Hopefully you ran them against an implementation first? 🐙

@karenetheridge I started testing them today now that my new validator Is just about done. I wrote one so I could better understand the spec and hence the tests. I’ve already found one test error.

I just added a way for the meta tests to be tested as schemas and not just as plain instances. There's currently "isAllSchemas" for each test set, and for finer control, "isSchema" for each test. I don't love "isAllSchemas", perhaps "allAreSchemas" is better, I haven't decided what word is best.

Just changed "isAllSchemas" to "isMetaSchema" and removed "isSchema".

I am puzzled by some of the changes here so it would be helpful to itemize what problems it is proposing to solve.

It adds tests for the meta-schema keywords. I'm moving the "isMetaSchema" stuff and some of the non-validatable tests into a "Phase II".

I haven't reviewed every test in detail and I can't run them yet against my implementation as I don't yet support $refs to foreign documents, but I think these should be ok.
As an aside, however, they still aren't addressing the lack of test coverage that I was getting at a week or two ago on slack about detecting outright errors in schemas.  Turning the schemas into data instances and using the draft2019-19 metaschema as the schema pushes all these tests into the normal validation path, rather than the can-the-implementation-detect-schema-errors path. To do that, just move the schemas into 'schema' for each test (and use anything at all as the data instance, as it isn't relevant).

Moving them into "schema" won't cause test failures unless all tests whose schemas have errors are marked as FAIL.

This is not currently mandated,

What does this mean?

won't necessarily work

What does this mean? How are you defining "work"?  The tests won't produce a valid result, so the results must be "valid": false.
If the tests in this PR are to be simply testing bad data (which happen to be schemas) against a schema (which happens to be the draftX metaschema), then please rename the tests to "meta-foo.json", rather than "meta/foo.json" -- the use of subdirectories has so far been reserved for optional tests.   Or, failing that, update the test suite documentation to explain the directory structure and what each subdirectory is for.

I don’t agree that non-optional tests can’t be in subdirectories, because it’s easy enough to walk a tree in the test runner. However, I do agree that it should be documented. Thanks for that; I will update the README.
Also, having a bunch of files prefixed with “meta-“ is a good indicator that a subdirectory is needed. That’s just my personal experience and opinions talking, though. @julian can decide, but in the meantime, I’ll update the README.

I've removed the meta/ directory and put all meta-tests into their respective keywords.

Force-pushed to track changes in master.

I'll only do  "merge" if that's @Julian's preference. Otherwise I'll continue to do rebasing. And please don't suggest process again, unless you run it by @julian.

I'll add: You may have missed that I've been rebasing against master regularly, above. No need to suggest that. And besides, it won't even let you merge anything if there's conflicts. I'm keeping on top of those.

Rebasing against master during a review causes some history to be lost, which is I think what @handrews was mentioning the other day.
If you were going to rebase anyway before merging, then that's great, and my comment was redundant! :)

No history is lost. All the history in a PR is accessible, even the ones that may appear lost after a force-push. Before I merge in a PR, my practice is to reduce to a minimum set of applicable commits. This keeps the commit history clean. This is also why my personal preference is to have the submitter do the merge (assuming trust) because there's a last chance to squash relevant commits into one or more, as opposed to squashing everything into one commit.

Ok, since this has gone through a few iterations and a bunch of waiting time, I'll use this comment as a summary of what's happening in this PR. I just updated the description to be:

This adds tests using the meta-schema as a schema. This does not test things that cannot currently be represented in a schema, for example, normalized URL requirements and optional "format" for "pattern".

This PR adds tests that can be tested currently, and tests that cannot be tested currently will be pushed to a future PR pending some more discussion on how we can add those tests.

I am obviously still behind, but just clarifying the "policy" -- as usual this is just de facto (it's what I do on all other repos I manage/maintain, as well as $WORK, etc. -- it may not be what @Relequestual / @awwright / Henry do on other repos, which does not mean I disagree! I just didn't coordinate with them, so we can reconcile if need be or write things down if need be, whatever helps, but laying it out here):

the only hard-fast policy is "do not squash when you merge to master if there are multiple units of work in your branch" -- i.e. always create a merge commit, and don't mash work together if it was done separately, so merging to master should create 2 or more commits.

The soft policy is I personally don't generally squash things if each commit does one thing. But that much is up to your personal taste if it happens on a feature branch -- if you want to squash fixme commits that's fine with me (though as I say, generally I'll only do that when the initial commit is "defective" for what it's meant for, not if additional self contained pieces are added to it, but fine if others do what they usually do).
The medium-to-hard tangential policy is also "keep commits small and self contained" -- 200 lines or so is the max. I generally will not personally review things that are much larger than that -- once or twice I'll give a free pass :) but after that I just won't do it and ask to break it into smaller self contained chunks that are each independently 200 lines or less. In this repo, I'll also ignore if it's copy pasting 200 lines across draft versions.
And yes, I generally do "submitter commits / merges" after approval (which is as simple as any person with commit bit saying "you are good" or hitting green buttons or whatever they feel like doing).
And yeah again :) all the above is meant just to facilitate, so we can of course discuss or reconcile or write this down if there's other preferences or if I've contradicted what we do in the spec repo (which I don't contribute to as much as I should, so I don't know the rules there!).

We mandate very little.
@karenetheridge is impressive for even attempting to review this. I wouldn't.
I MIGHT consider reviewing it if there were many commits, but there's just too much here for someone to sensibly review.
I generally find if it's going to take more than 20-30 minutes to review, you'll have to really convince me it's worth my time.
That being said, @Julian has ownership over this repo. Pretty much what he says goes because he puts in monumental effort, and we got to support that as much as possible.

This was too much for me to review manually, but I did run the tests through Hyperjump JSV and they all passed, so it looks good as far as I can tell.

I’m working on simplifying this PR into smaller chunks, starting with some README updates.

@ssilverman just in case you happen to be around -- I'm going to start pulling additional chunks out of this PR to merge. Thanks again for sending it and sorry it took so long.


UI: WoWSims v3.0

Documenting the v3.0 UI discussions from the Discord server.
Overview
@Nord on the Discord server put together some amazing mockups for a revamped UI featuring cleaner, more-modern styling. This issue is documenting the conversation and can be used to divide up the work.
From @Nord

WoWSims 3.0. Revamped an old concept but I took the existing structure and worked on that to make it more feasible rather than a big overhaul. I've been wanting to make an updated visual for quite some time now. Not by request but just for the passion of making.
It consists of many subtle changes that gives a bigger impact. Working with more marginals of the elements so the content gets more room. Bigger changes are more suggestions of dividing sections of DPS and Stat Weights in the left columns and moving the stats to the right together with the gear. And a re-design of the headers. Making the Import and Export more visual and not as hidden as now with the Addon is a big feature of the WoWSims. Note that not every single detail is correct because its not necessary for a concept.

WIP Mockups

Additional Discussion Points

@Pokpoong
Love it! Some initial thoughts:

Really like the header navigation changes. These are also easy enough that I might be able to get them done in the next few weeks.

Gear Stats isn't a good label for the stats section because it includes all stat sources, not just from Gear.

Moving the stats out of the left-side panel will make it not visible while in the other tabs, specifically Settings and Talents. It's important that it still be visible while viewing those tabs because stats can change depending on buffs/consumes/talents/etc and being able to watch the stats change when various settings are toggled is a very helpful sanity check to improve trust in the sim.

We have enough problems with EP already so we'd rather not make it more prominent. 🙂

@lologarithm
big agree with making stats visible from all input tabs because they come together (gear+consumes+talents) to make the stats

@Lucenia
What do y'all think about putting sigil below off-hand and adding a bit of separation between Wrists and Weapon+Offhand+Sigil? Keeps it a little closer to the in-game UI. I've gotten tripped up a couple of times because of where sigil is
@Pokpoong
Not specifically against this but again, on smaller screens (even typical laptops) we already have a vertical scrollbar. If you can do this and pair it with some better size adaptations to avoid having scrollbars then sure
@lologarithm
I think having some visual separation for the weapons/ranged slot would be good

this looks to be all set now?


qmk_hid init at 0.1.5

Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Oh cool :D @Janik-Haag are you actually using it already?

I just played around with it a bit and packaging was easy so :shrug:
But the package only contains the cli and not the gui since python packaging in nix is meh when you don't have a "actual python package" with like setuptools or pyproject.toml or something. Looking at the package now I should probably also add udev rules :see_no_evil:
Nice to see the author of the package comment on my PR :D
If you want further disscusion this is probably not the right place and we should move to matrix or the fediverse :)

Looking at the package now I should probably also add udev rules

udev rules are already supported by hardware.keyboard.qmk.enable = true.

But the package only contains the cli and not the gui since python packaging in nix is meh when you don't have a "actual python package" with like setuptools or pyproject.toml or something.

Oh I should do that. Even though the GUI is more of an afterthought. The python script was just a quick prototype and also serves as a reference for non-rustaceans.

If you want further disscusion this is probably not the right place and we should move to matrix or the fediverse :)
Sure! You can reach me at @johnazoidberg:matrix.org


meta-balena-imx8mm:layer.conf: Fix typo for u-boot-fw-utils provider

Changelog-entry: Fix typo that prevented setting the preferred provider as u-boot-compulab-fw-utils for u-boot-fw-utils
Signed-off-by: Florin Sarbu<EMAIL_ADDRESS>

@balena-ci I self-certify!


Suddenly, Atom is dead

As of today, when I open Atom, nothing really works.
https://drive.google.com/file/d/0By0MxtGl4s2YOW1ZaHBrck1JeFU/view?usp=drivesdk
That's all I get.  There's an option for Atom in the menu and that's it.  Eventually it  does this:
https://drive.google.com/file/d/0By0MxtGl4s2YTkJvd3ZMWTNfeGc/view?usp=drivesdk
I've uninstalled and deleted everything I could find in my AppData folders related to Atom.  Reinstalling does not fix the issue.

I loaded it in safe mode (for those wondering, add --safe to the end of Target on Windows) and now it seems to be working.

Can you open the dev tools (cmd-option-i) when it's not working and paste in any messages?

Def caused by some package, but the error messages might indicate which package.

@mikeytusa Have you tried clicking the "Keep Waiting" button?  Usually that'll load Atom for me if it's stuck like that (which reminds me, I need to make an issue for that...).

Arg.  Doing the same thing again.  The console has no info whatsoever.
https://drive.google.com/file/d/0By0MxtGl4s2YajkxcHhKdEdtdlE/view?usp=drivesdk

It finally loaded, lol. Window load time: 104851ms
Don't see anything useful in the dev tools though.

Pigments?  https://drive.google.com/file/d/0By0MxtGl4s2YVUUwZFpMVzdseTQ/view?usp=drivesdk

Yep, that must have been the issue.  Seems to be working fine now.

Please open an issue on pigments and if you can link to your project. I
know pigments does some file analysis and your project may be hitting some
weird edge case.
On Wednesday, October 7, 2015, Mike Thompson<EMAIL_ADDRESS>wrote:

Yep, that must have been the issue. Seems to be working fine now.
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/9071#issuecomment-146300347.

Same happened to me on Ubuntu 15.04 x64.
Close Atom
apm uninstall pigments
Open Atom
Fixed.

Closing due to a package. cc @abe33


(4895) uncaught exception: Cannot read property 'id' of undefined

Hello,
I've tried to install your adapter in2 different ioBroker. Both time the same error.
(4895) uncaught exception: Cannot read property 'id' of undefined. Installed version. 0.9.6

Hi
Hm...this shouldn't happend. Got the same error a while ago: https://github.com/baerengraben/ioBroker.swiss-weather-api/issues/48
Can you please run adapter in debug-mode and post the log?

Hi
Log with adapter in debug mode is attached.
Regards
Peter
Von: baerengraben @.>
Gesendet: Mittwoch, 16. Juni 2021 09:47
An: baerengraben/ioBroker.swiss-weather-api @.>
Cc: hdse @.>; Author @.>
Betreff: Re: [baerengraben/ioBroker.swiss-weather-api] (4895) uncaught exception: Cannot read property 'id' of undefined (#50)
Hi
Hm...this shouldn't happend. Got the same error a while ago: #48https://github.com/baerengraben/ioBroker.swiss-weather-api/issues/48
Can you please run adapter in debug-mode and post the log?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/baerengraben/ioBroker.swiss-weather-api/issues/50#issuecomment-862134285, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIQVB3MAUG52O3LDNSHU4WDTTBJITANCNFSM46YYNHZA.
2021-06-16 10:29:01.940 - info: host.mint01 "system.adapter.swiss-weather-api.0" disabled
2021-06-16 10:37:07.572 - info: host.mint01 "system.adapter.swiss-weather-api.0" enabled
2021-06-16 10:37:07.616 - info: host.mint01 instance system.adapter.swiss-weather-api.0 started with pid 6991
2021-06-16 10:37:08.081 - info: swiss-weather-api.0 (6991) starting. Version 0.9.6 in /opt/iobroker/node_modules/iobroker.swiss-weather-api, node: v12.22.1, js-controller: 3.2.16
2021-06-16 10:37:08.093 - info: swiss-weather-api.0 (6991) longitude/longitude not set, get data from system
2021-06-16 10:37:08.128 - info: swiss-weather-api.0 (6991) system longitude: 8.449569708547877 latitude: 47.29478805
2021-06-16 10:37:18.356 - error: swiss-weather-api.0 (6991) uncaught exception: Cannot read property 'id' of undefined
2021-06-16 10:37:18.357 - error: swiss-weather-api.0 (6991) TypeError: Cannot read property 'id' of undefined
at IncomingMessage. (/opt/iobroker/node_modules/iobroker.swiss-weather-api/main.js:2920:23)
at IncomingMessage.emit (events.js:326:22)
at endReadableNT (_stream_readable.js:1241:12)
at processTicksAndRejections (internal/process/task_queues.js:84:21)
2021-06-16 10:37:18.357 - error: swiss-weather-api.0 (6991) Cannot read property 'id' of undefined
2021-06-16 10:37:18.369 - info: swiss-weather-api.0 (6991) cleaned everything up...
2021-06-16 10:37:18.369 - info: swiss-weather-api.0 (6991) terminating
2021-06-16 10:37:18.369 - warn: swiss-weather-api.0 (6991) Terminated (UNCAUGHT_EXCEPTION): Without reason
2021-06-16 10:37:18.913 - error: host.mint01 instance system.adapter.swiss-weather-api.0 terminated with code 6 (UNCAUGHT_EXCEPTION)
2021-06-16 10:37:18.913 - info: host.mint01 Restart adapter system.adapter.swiss-weather-api.0 because enabled
2021-06-16 10:37:48.953 - info: host.mint01 instance system.adapter.swiss-weather-api.0 started with pid 7007
2021-06-16 10:37:49.391 - info: swiss-weather-api.0 (7007) starting. Version 0.9.6 in /opt/iobroker/node_modules/iobroker.swiss-weather-api, node: v12.22.1, js-controller: 3.2.16
2021-06-16 10:37:49.408 - info: swiss-weather-api.0 (7007) longitude/longitude not set, get data from system
2021-06-16 10:37:49.442 - info: swiss-weather-api.0 (7007) system longitude: 8.449569708547877 latitude: 47.29478805
2021-06-16 10:37:59.657 - error: swiss-weather-api.0 (7007) uncaught exception: Cannot read property 'id' of undefined
2021-06-16 10:37:59.658 - error: swiss-weather-api.0 (7007) TypeError: Cannot read property 'id' of undefined
at IncomingMessage. (/opt/iobroker/node_modules/iobroker.swiss-weather-api/main.js:2920:23)
at IncomingMessage.emit (events.js:326:22)
at endReadableNT (_stream_readable.js:1241:12)
at processTicksAndRejections (internal/process/task_queues.js:84:21)
2021-06-16 10:37:59.658 - error: swiss-weather-api.0 (7007) Cannot read property 'id' of undefined
2021-06-16 10:37:59.670 - info: swiss-weather-api.0 (7007) cleaned everything up...
2021-06-16 10:37:59.670 - info: swiss-weather-api.0 (7007) terminating
2021-06-16 10:37:59.670 - warn: swiss-weather-api.0 (7007) Terminated (UNCAUGHT_EXCEPTION): Without reason
2021-06-16 10:38:00.216 - error: host.mint01 instance system.adapter.swiss-weather-api.0 terminated with code 6 (UNCAUGHT_EXCEPTION)
2021-06-16 10:38:00.217 - info: host.mint01 Restart adapter system.adapter.swiss-weather-api.0 because enabled
2021-06-16 10:38:13.810 - info: host.mint01 "system.adapter.swiss-weather-api.0" disabled
2021-06-16 10:38:30.749 - error: swiss-weather-api.0 (7022) adapter disabled
2021-06-16 10:38:30.758 - warn: swiss-weather-api.0 (7022) Terminated (NO_ADAPTER_CONFIG_FOUND): Without reason
2021-06-16 10:38:31.286 - error: swiss-weather-api.0 (7022) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
2021-06-16 10:38:31.286 - error: swiss-weather-api.0 (7022) unhandled promise rejection: Cannot read property 'error' of undefined
2021-06-16 10:38:31.291 - error: swiss-weather-api.0 (7022) TypeError: Cannot read property 'error' of undefined
at SwissWeatherApi.onUnload (/opt/iobroker/node_modules/iobroker.swiss-weather-api/main.js:3015:13)
at SwissWeatherApi.emit (events.js:314:20)
at process.stop (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:8620:22)
at Object.onceWrapper (events.js:421:26)
at process.emit (events.js:314:20)
at process.exit (internal/process/per_thread.js:168:15)
at Timeout._onTimeout (/opt/iobroker/node_modules/iobroker.js-controller/lib/adapter.js:352:25)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
2021-06-16 10:38:31.291 - error: swiss-weather-api.0 (7022) Cannot read property 'error' of undefined
2021-06-16 10:38:31.775 - error: host.mint01 instance system.adapter.swiss-weather-api.0 terminated with code 3 (NO_ADAPTER_CONFIG_FOUND)
2021-06-16 10:38:31.776 - info: host.mint01 Do not restart adapter system.adapter.swiss-weather-api.0 because disabled or deleted
2021-06-16 10:45:25.979 - info: host.mint01 "system.adapter.swiss-weather-api.0" enabled
2021-06-16 10:45:26.025 - info: host.mint01 instance system.adapter.swiss-weather-api.0 started with pid 7193
2021-06-16 10:45:26.478 - debug: swiss-weather-api.0 (7193) Redis Objects: Use Redis connection: <IP_ADDRESS>:9001
2021-06-16 10:45:26.516 - debug: swiss-weather-api.0 (7193) Objects client ready ... initialize now
2021-06-16 10:45:26.517 - debug: swiss-weather-api.0 (7193) Objects create System PubSub Client
2021-06-16 10:45:26.518 - debug: swiss-weather-api.0 (7193) Objects create User PubSub Client
2021-06-16 10:45:26.518 - debug: swiss-weather-api.0 (7193) Objects client initialize lua scripts
2021-06-16 10:45:26.540 - debug: swiss-weather-api.0 (7193) Objects connected to redis: <IP_ADDRESS>:9001
2021-06-16 10:45:26.542 - debug: swiss-weather-api.0 (7193) objectDB connected
2021-06-16 10:45:26.543 - debug: swiss-weather-api.0 (7193) Redis States: Use Redis connection: <IP_ADDRESS>:9000
2021-06-16 10:45:26.550 - debug: swiss-weather-api.0 (7193) States create System PubSub Client
2021-06-16 10:45:26.550 - debug: swiss-weather-api.0 (7193) States create User PubSub Client
2021-06-16 10:45:26.557 - debug: swiss-weather-api.0 (7193) States connected to redis: <IP_ADDRESS>:9000
2021-06-16 10:45:26.557 - debug: swiss-weather-api.0 (7193) statesDB connected
2021-06-16 10:45:26.673 - info: swiss-weather-api.0 (7193) starting. Version 0.9.6 in /opt/iobroker/node_modules/iobroker.swiss-weather-api, node: v12.22.1, js-controller: 3.2.16
2021-06-16 10:45:26.698 - info: swiss-weather-api.0 (7193) longitude/longitude not set, get data from system
2021-06-16 10:45:26.730 - info: swiss-weather-api.0 (7193) system longitude: 8.449569708547877 latitude: 47.29478805
2021-06-16 10:45:26.731 - debug: swiss-weather-api.0 (7193) use system language for weekday names: de
2021-06-16 10:45:36.716 - debug: swiss-weather-api.0 (7193) Successfull DNS resolve for api.srgssr.ch: ["<IP_ADDRESS>"]
2021-06-16 10:45:36.717 - debug: swiss-weather-api.0 (7193) There is no geolocationId, so getting one before calling forecasts...
2021-06-16 10:45:36.718 - debug: swiss-weather-api.0 (7193) getting Token...
2021-06-16 10:45:36.718 - debug: swiss-weather-api.0 (7193) "IRP7MB0jlG2ORWwmTkzIUPylHEorzENZ:u52oqyuUZzux9kdq" converted to Base64 is "SVJQN01CMGpsRzJPUld3bVRreklVUHlsSEVvcnpFTlo6dTUyb3F5dVVaenV4OWtkcQ=="
2021-06-16 10:45:36.718 - debug: swiss-weather-api.0 (7193) Options to get Access Token: {"json":true,"method":"POST","hostname":"api.srgssr.ch","port":null,"path":"/oauth/v1/accesstoken?grant_type=client_credentials","headers":{"Authorization":"Basic SVJQN01CMGpsRzJPUld3bVRreklVUHlsSEVvcnpFTlo6dTUyb3F5dVVaenV4OWtkcQ==","Cache-Control":"no-cache","Content-Length":0,"Postman-Token":"24264e32-2de0-f1e3-f3f8-eab014bb6d76"}}
2021-06-16 10:45:36.878 - debug: swiss-weather-api.0 (7193) Answer of Request Access Token: {"access_token":"fUFTFdI9eK4UmZU2K5vSvUDg6Nv5", "expires_in": 2591999, "token_type":"Bearer"}
2021-06-16 10:45:36.878 - debug: swiss-weather-api.0 (7193) Access_Token : fUFTFdI9eK4UmZU2K5vSvUDg6Nv5
2021-06-16 10:45:36.878 - debug: swiss-weather-api.0 (7193) Getting GeolocationId....
2021-06-16 10:45:36.878 - debug: swiss-weather-api.0 (7193) Options to get GeolocationId: {"method":"GET","hostname":"api.srgssr.ch","port":null,"path":"/srf-meteo/geolocations?latitude=47.29478805&longitude=8.449569708547877","headers":{"authorization":"Bearer fUFTFdI9eK4UmZU2K5vSvUDg6Nv5"}}
2021-06-16 10:45:36.984 - debug: swiss-weather-api.0 (7193) Answer of getGeolocation Request: {"fault":{"faultstring":"Invalid API call as no apiproduct match found","detail":{"errorcode":"keymanagement.service.InvalidAPICallAsNoApiProductMatchFound"}}}
2021-06-16 10:45:36.984 - debug: swiss-weather-api.0 (7193) Body: {"fault":{"faultstring":"Invalid API call as no apiproduct match found","detail":{"errorcode":"keymanagement.service.InvalidAPICallAsNoApiProductMatchFound"}}}
2021-06-16 10:45:36.985 - error: swiss-weather-api.0 (7193) uncaught exception: Cannot read property 'id' of undefined
2021-06-16 10:45:36.985 - error: swiss-weather-api.0 (7193) TypeError: Cannot read property 'id' of undefined
at IncomingMessage. (/opt/iobroker/node_modules/iobroker.swiss-weather-api/main.js:2920:23)
at IncomingMessage.emit (events.js:326:22)
at endReadableNT (_stream_readable.js:1241:12)
at processTicksAndRejections (internal/process/task_queues.js:84:21)
2021-06-16 10:45:36.985 - error: swiss-weather-api.0 (7193) Cannot read property 'id' of undefined
2021-06-16 10:45:36.995 - debug: swiss-weather-api.0 (7193) Cron job destroyed
2021-06-16 10:45:36.999 - info: swiss-weather-api.0 (7193) cleaned everything up...
2021-06-16 10:45:37.000 - info: swiss-weather-api.0 (7193) terminating
2021-06-16 10:45:37.000 - warn: swiss-weather-api.0 (7193) Terminated (UNCAUGHT_EXCEPTION): Without reason
2021-06-16 10:45:37.523 - error: host.mint01 instance system.adapter.swiss-weather-api.0 terminated with code 6 (UNCAUGHT_EXCEPTION)
2021-06-16 10:45:37.523 - info: host.mint01 Restart adapter system.adapter.swiss-weather-api.0 because enabled
2021-06-16 10:45:37.523 - warn: host.mint01 Do not restart adapter system.adapter.swiss-weather-api.0 because restart loop detected

This is probably the Problem: Invalid API call as no apiproduct match found
2021-06-16 10:45:36.984 - debug: swiss-weather-api.0 (7193) Body: {"fault":{"faultstring":"Invalid API call as no apiproduct match found","detail":{"errorcode":"keymanagement.service.InvalidAPICallAsNoApiProductMatchFound"}}}
Did you create a new Freemium-App?
Please check readme: https://github.com/baerengraben/ioBroker.swiss-weather-api/blob/master/README.md

#Attention!!! SRG has completely rebuilt its API. The old API (<= adapter version 0.3.2) is NOT supported anymore. From adapter version 0.9.x the new API of the SRG is used. That's why a new SRG APP (eg product "Freemium") must be created (https://developer.srgssr.ch/apis/srf-weather). See also Readme, chapter "Getting started" (below). Please also note that the new API will also create completely new objects.
The good news is that the new API also provides more data. ;)
Update procedure
So my recommendation for the update from 0.3.2 to 0.9.x is:

remove the old adapter before installing version 0.9.x.
please note that the data-objects will be removed accordingly as well.
create a new freemium app on srg developer portal (https://developer.srgssr.ch/apis/srf-weather)
install new version 0.9.x and set configuration with new consumerkey and consumersecret
on startup, the new adapter will create new, different data-objects.

Hi,
The Freemium APP was correctly showed in the SRG portal.
After deleting and new creating, it works now. Very special.
But many thanks for your help
Regards
Von: baerengraben @.>
Gesendet: Mittwoch, 16. Juni 2021 13:20
An: baerengraben/ioBroker.swiss-weather-api @.>
Cc: hdse @.>; Author @.>
Betreff: Re: [baerengraben/ioBroker.swiss-weather-api] (4895) uncaught exception: Cannot read property 'id' of undefined (#50)
This is probably the Problem: Invalid API call as no apiproduct match found
2021-06-16 10:45:36.984 - debug: swiss-weather-api.0 (7193) Body: {"fault":{"faultstring":"Invalid API call as no apiproduct match found","detail":{"errorcode":"keymanagement.service.InvalidAPICallAsNoApiProductMatchFound"}}}
Did you create a new Freemium-App?
Please check readme: https://github.com/baerengraben/ioBroker.swiss-weather-api/blob/master/README.md
#Attention!!! SRG has completely rebuilt its API. The old API (<= adapter version 0.3.2) is NOT supported anymore. From adapter version 0.9.x the new API of the SRG is used. That's why a new SRG APP (eg product "Freemium") must be created (https://developer.srgssr.ch/apis/srf-weather). See also Readme, chapter "Getting started" (below). Please also note that the new API will also create completely new objects.
The good news is that the new API also provides more data. ;)
Update procedure
So my recommendation for the update from 0.3.2 to 0.9.x is:

remove the old adapter before installing version 0.9.x.
please note that the data-objects will be removed accordingly as well.
create a new freemium app on srg developer portal (https://developer.srgssr.ch/apis/srf-weather)
install new version 0.9.x and set configuration with new consumerkey and consumersecret
on startup, the new adapter will create new, different data-objects.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/baerengraben/ioBroker.swiss-weather-api/issues/50#issuecomment-862295446, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIQVB3IJNPXISWFJYMVEU4DTTCCFFANCNFSM46YYNHZA.

Good to hear :)
But the adapter should handle this better. This shoud be done for next release:

When getting GeolocationId the following error can occur:
Body: {"fault":{"faultstring":"Invalid API call as no apiproduct match found","detail":{"errorcode":"keymanagement.service.InvalidAPICallAsNoApiProductMatchFound"}}}
The Adapter should handle faults like this and should give a meaningful error message to ioBroker-Log.

resolved with V0.9.7


typescript-react-query custom fetcher not using correct import with near-operation-file

Is your feature request related to a problem? Please describe.
Using near-oparation-file has a wrong import using custom fetcher.
Describe the solution you'd like
The path should be correct.
Describe alternatives you've considered
Using typescript alias path fixes it but might be an easier fix within the plugin

    generates: {
        "./src/utils/__generated__/types.ts": {
            documents: ['src/**/*.gql'],
            plugins: ["typescript", "typescript-operations"],
            config: {
                dedupeFragments: true,
             }
        },
        "src/": {
            preset: "near-operation-file",
            documents: ['src/**/*.gql'],
            plugins: ["typescript-react-query"],
            config: {
                fetcher: {
                    func: "@gql-fetcher#fetchData", // this is always a fixed path and not a relative path
                    isReactHook: false
                },
                reactQueryVersion: 5,
                dedupeFragments: true,
                importOperationTypesFrom: "Types",
            }
        }
    }


zerotomastery Master the interview

https://medium.com/zerotomastery/learn-to-code-in-2019-get-hired-and-have-fun-along-the-way-d4197f96be27
https://coggle.it/diagram/W5u8QkZs6r4sZM3J/t/master-the-interview

Algorithms Roadmap: https://coggle.it/diagram/W5E5tqYlrXvFJPsq/t/master-the-interview-click-here-for-course-link

https://visualgo.net

https://www.cs.usfca.edu/~galles/visualization/AVLtree.html

https://medium.com/basecs

https://cs.williams.edu/~cs136


README: cleanup

Various grammatical fixes and edits to increase readability.

correct comma usage
remove verbiage (e.g.,simply and just) to create stronger intent
correct word order

Closing as no activity
feel free to reopen


Add multitrack recording

A simple record button should allow the local recording of raw audio for each session participant. It would be nice if the recorded sessions could be downloaded and removed via the GUI.

recording of the full mono audio bus from 9fef2cb seems good enough for now. in the future, it might be nice to get individual stems and a way of grabbing tracks via the GUI somehow (a separate http file server?)


Housekeeping a0126633j

Coverage decreased (-0.004%) to 87.147% when pulling c19afa9d48a42291639332af3e41d39bfcbeef33 on housekeeping_a0126633j into 0179beb501eb010a4518bd9bc7e6900d4963f63d on master.


Default border still exists

Hi there, I was wondering if it was intentional that the default border still exists even though there is now the option of including the class to add a border:
https://github.com/filamentgroup/tablesaw/blob/950db5cce0a4a64d6fb6e0d56954afcd755f3d3f/dist/tablesaw.css#L424

Hmm, good question. That border is specifically for the stack table when rows are actively stacked.
I’d be wary to remove it before a 4.0, but I would be on board with making it opt-in.

Sounds good :D


Eager loading manyToMany relations pivot error on php 7.4

Laravel version: 6.10.1
php version: 7.4
using latest Laravel Homestead

Type of Illuminate\Database\Eloquent\Relations\Pivot::$ must be array (as in class Illuminate\Database\Eloquent\Model)

the issue happens on:

vendor/laravel/framework/src/Illuminate/Database/Eloquent/Relations/Pivot.php:8
vendor/laravel/framework/src/Illuminate/Database/Eloquent/Model.php:1078

Inserting, updating intermediate tables works. Whenever I try to eager load with ->with() or ->load() I get the error on the Pivot class.
I think it's a php 7.4 issue, since it worked fine on 7.3
edit:
App\Models\Grow
    public function waterings()
    {
        return $this->hasMany(Watering::class);
    }

App\Models\Watering
    public function nutrients()
    {
        return $this->belongsToMany(Nutrient::class)->withPivot('value');
    }

App\Models\Plant
    public function waterings()
    {
        return $this->belongsToMany(Watering::class);
    }

App\Http\Controllers\GrowController
    public function show(Grow $grow)
    {
        $grow->load([
            'user', 'plants.medium.type', 'plants.medium.company', 'plants.strain.company', 'waterings.nutrients'
        ]);
        return new GrowResource($grow);
    }

I dies when I try to load 'waterings.nutrients'
or the second case is:
App\Repositores\GrowRepository
    public function getByRequest(Request $request)
    {
        $query = $this->grow->with(['user', 'plants.medium.type', 'plants.medium.company', 'plants.strain.company', 'plants.waterings']);

        if ($request->get('done')) $query->whereNotNull('finished_at');

        $this->sortQuery($request, $query);

        return $this->paginateResults($request, $query);
    }

Here it dies when trying to load 'plants.waterings'

Can you post minimal piece of code.

I edited the issue post.

After upgrading homestead to the lastest version and vagrant box to the latest version also, the error changed to

Type of Illuminate\Database\Eloquent\Relations\Pivot::$guarded must be array (as in class Illuminate\Database\Eloquent\Model)

It gets fixed by editing line 24 on:

vendor/laravel/framework/src/Illuminate/Database/Eloquent/Relations/Pivot.php

My guess is that you're using a PHP 7.4 property type for guarded. You can't do this for any properties inherited from framework classes because any properties from the framework aren't typed yet because we still need to support PHP 7.2 and 7.3

My guess is that you're using a PHP 7.4 property type for guarded. You can't do this for any properties inherited from framework classes because any properties from the framework aren't typed yet because we still need to support PHP 7.2 and 7.3

Is there any trick to bypass this problem? I have the same problems.

No there isn't.

I updated my laravel 6 project and I got this error on all my models. I fixed them but I got this error on laravel's own models.
Type of Illuminate\Database\Eloquent\Relations\Pivot::$guarded must be array (as in class Illuminate\Database\Eloquent\Model)

Type of Illuminate\Notifications\DatabaseNotification::$table must be string (as in class Illuminate\Database\Eloquent\Model)

Laravel version: 6.20.16
php version: 7.4
using with ubuntu/nginx


exp/lighthorizon: Minor ledgerexporter infrastructure improvements

Push the stellar/horizon-ledgerexporter docker image when pushing to the lighthorizon branch
Fix the ledger exporter aws batch jobs when running on the first batch

Tests are failing due to https://github.com/stellar/go/issues/4462


fix forwarding issues for packets destinated to AllThreadNodes when multiple SEDs exist

@jwhui , please have a review.

Thanks for catching this issue.  OpenThread maintains a fragment offset for each child in the child table.  I think a more complete fix would set the message offset based on the child's fragment offset when preparing to transmit.  What do you think about something like:
void MeshForwarder::ScheduleTransmissionTask()
{
    ....
    for (int i = 0; i < numChildren; i++)
    {
     	if (children[i].mState == Child::kStateValid &&
            children[i].mDataRequest &&
            (mSendMessage = GetIndirectTransmission(children[i])) != NULL)
        {
            mSendMessage->SetOffset(children[i].mFragmentOffset);  ///< Set offset here.
            mMac.SendFrameRequest(mMacSender);
            ExitNow();
        }
    }
    ....
}

Current coverage is 67.23% (diff: 100%)

No coverage report found for master at bb84b9a.

Powered by Codecov. Last update bb84b9a...8bb6950

Good idea! Updated, thanks!

LGTM 👍


Make report text fields configurable

I want to be able to configure the text / fields shown in the reports generated in PRISM. Right now, some of the text is hard-coded incorrectly.
Here are 4 specific fields where it's a problem:

The report title currently uses the label 'Event name'. This isn't correct and seems to be a copy from ADAM reports
Admin labels are hard-coded as 'Province', 'District', 'Township', which are not universal and we may not always have 3 admin levels.
'Sources' text will vary based on the deployment and layers used for the analysis.
Flood maps will change from a simple flooded vs not-flooded layer. We should be able to configure the label in case needed

We need to revisit how these reports are setup so that they can be configured correctly, and so that local variations can be accommodated if needed.
The incorrect fields that were mentioned are highlighted below:

@HarryMytilinaios - thanks for the summary and recommendation. Your proposed approach for keys like in the example of APPLICATION_TITLE is clear and makes sense to me. What do you think @ericboucher ?

Potentially linked to https://github.com/WFP-VAM/prism-app/issues/714

Yes, I think that makes sense for the title part, but maybe less for the rest of the info. Another option would be to do this at the layer level. So it might be easier to configure. @wadhwamatic maybe you could give us a few examples of different configurations you would like to set up?

@ericboucher - sure I'll add that here soon. I think I'm not fully convinced if we should make this happen within layers or instead follow an approach like what was done with table configuration (in tables.json).

How should we approach on this? @wadhwamatic @ericboucher

@wadhwamatic you mean like what's proposed in https://github.com/WFP-VAM/prism-app/issues/714 ?
I agree that we should probably merge these two tasks.
Amit when you have time, add a bit more info in here/the other issue with a bit more details on your expectations. Then @HarryMytilinaios and I can have a quick meeting to discuss our options. We could indeed introduce a reports.json file that leverages the layers defined in layers.json. Or add a subsection with details in layers.json.

@ericboucher and @HarryMytilinaios - I am open to your suggestions between having a new a reports.json file or having this configured within layers.json. I know I previously mentioned doing this within layers.json but I think we're hitting a saturation point with too many parameters for a layer. We could instead have a layer attribute for a report_id which is then configured in reports.json. What do you think?
In either case, I would like to be able to configure each of the elements mentioned in this issue: report title, admin level names (ideally this can simply be read from the boundary layer configuration), and footer text.

Agreed, having a new "reports.json" will likely make things more readable. We will need to do the matching between layers.json and reports.json but that should be fine. For now, we will assume that only one report type per layer_id is possible.
As such this issue is mergeable with https://github.com/WFP-VAM/prism-app/issues/714


⚠ Secret Website 3 has degraded performance

In d8cd17f, Secret Website 3 ($SECRET_WEBSITE_3) experienced degraded performance:

HTTP code: 200
Response time: 2346 ms

Resolved: Secret Website 3 performance has improved in 2d125ff.


Don't return id on EUMAPI user creation

Fixes #9455
It has been decided that since EUMAPI works with usernames, it's misleading to return ids.
Please CR @juanignaciosl

CR please @javitonino

Nitpicking aside, :rocket: it!


aalc: modify fan8 to fan15

Summary:

modify fan 8 to fan 15
latch gpio FM_BIC_READY_R_N
modify FW_BIC_P12V_PUMP_EN to output pin

Test Plan:

build code: PASS

closed by #1858


Update build in benchcab once the updated CABLE build is released

Once the CABLE build is modified to use CMake and Spack, the build in benchcab will break. We will need to update the build in benchcab to reflect the changes.
We will have to see if benchcab should use Spack or CMake directly to build CABLE.

Use the build script to build each model
As mentioned in Slack, it might be a good to work only with the build script again as a lot of the reasons why I removed the build script dependence are no longer relevant (see https://github.com/CABLE-LSM/benchcab/issues/138). There are a couple issues with the current way of specifying a build script that should be addressed first:

[ ] https://github.com/CABLE-LSM/benchcab/issues/244
[ ] https://github.com/CABLE-LSM/benchcab/issues/249.

Use spack to build each model
Benchcab could use spack to build different versions of CABLE. Benchcab could invoke the following spack commands:
# 1. build CABLE serial and MPI executables from source for branch <branch_name>
# Note: this command will probably run for a while the first time as no dependencies are installed.
spack install cable@<branch_name> <spec for compiler and dependencies>

# 2. load CABLE spack package and symlink to executables
spack load cable@<branch_name>
ln -s $(which cable) path/to/experiment/dir
# or copy path to executable in payu config for MPI case
spack unload --all

# 3. load CABLE spack package and run the model
spack load cable@<branch_name>
cable cable.nml
# or `payu run` for MPI case
spack unload --all

With spack:

Only versions of CABLE that support the new CMake build system will be able to use spack.
Use spack dependencies instead of environment module dependencies.
Use spack install cable@<branch_name> instead of benchcab checkout(git clone ...) and benchcab build.
Use spack load instead of module load.

The requirement on benchcab to build legacy versions of cable means we will probably have to support the current way of doing things as well as doing things the spack way and seems like it would be hard to maintain. However, if we removed the requirement on benchcab to build legacy versions of cable, then moving to the spack way of doing things would be a good approach as using a package manager to install different versions of CABLE instead of doing this manually is more modular and easier to maintain from the developer perspective.
In summary, I think using a build script seems like the easiest approach for solving this issue. IMO using spack is only worth it if we deprecate support for building and running legacy versions of CABLE as it considerable change to how benchcab currently does things.

We can't remove support for legacy versions yet. We will need to run benchcab on the CABLE-POP_TRENDY branch as part of CABLE4 work. Once CABLE4 is released, and the BIOS3 to CABLE-POP_TRENDY has been done (this should happen before CABLE4), we should be in a position to drop the support for legacy versions. There are a few other legacy branches, but these are smaller features and it should be possible to get them to be compatible with CABLE main without benchcab.
This means using a build script for now.

After discussing with @ccarouge, we have decided to add support for spack and to deprecate support for legacy CABLE build systems in benchcab. This adds the requirement that users will only be able to test benchcab on branches that can be built by spack. ACCESS-NRI will help with transitioning legacy build systems to use the latest build system compatible with spack.
Moving to spack will solve existing issues around supporting bespoke build scripts (e.g. #244, #249). This is the best way forward considering support for legacy build systems is a temporary that will be deprecated sooner or later.

After scoping out the work necessary for supporting spack, it is worth considering whether we should use spack or invoke CMake directly for building CABLE.
Pros and cons - spack
Pros:

Model agnostic approach to building models.
Improves portability of benchcab to other machines.
Using a package manager like spack to install different versions of CABLE is more modular and easier to maintain from the developer perspective than doing this manually. For example, moving to spack will simplify code and remove complex abstractions - resolving issues like:

https://github.com/CABLE-LSM/benchcab/issues/210
https://github.com/CABLE-LSM/benchcab/issues/211

Fixes https://github.com/CABLE-LSM/benchcab/issues/130 due to recent CMake changes.

Cons:

Requires significant changes to how benchcab currently does things (see #275 for a discussion around implementing this).
It might not be the right time to make the transition as:

We currently do not have a formal release process for CABLE with spack which may shape how we design things.
This requires that spack is accessible to users on Gadi. There currently is no spack "module" that can be loaded on Gadi and requires manual installation.

Pros and cons - CMake
Pros:

Easy to implement (copy functionality of existing build script) and should not take long. This would be beneficial for anyone currently doing CABLE development and would allow them to test their development branches using the latest build system.
Fixes https://github.com/CABLE-LSM/benchcab/issues/130 due to recent CMake changes.

Cons:

Duplicate code between the build script and benchcab.

@ccarouge I think we should go with invoking CMake in benchcab for now as it is low effort and leave the spack implementation for now.

OK. Let's go with CMake for now.


Update Docs: Configuration “beta-features”

Automatically generated by Netlify CMS

Closing in favor of this pull request since it explains the issue in detail.


Recipe-app

Recipe-app
In this PR, with my partner @collinsmezie , we created an app that has:

A login page.
A registration page.
A food list (with all CRUD implementation, except for 'update').
A recipes list (with all CRUD implementation, except for 'update').
A general shopping list view (all missing food for all your recipes and total price).
A list of all public recipes from other users with their names and total prices.

Thank you @VICTOR-CHUKWU


Do not use reentry scan

AiiDA 2.0 does not require to use reentry scan anymore.

This change should be merged into a support-aiida-2.0 branch.


rmp: use std::atomic for Blif::call_id_ static data member

Protect concurrent access to the Blif::call_id_ using an atomic data type: it is cheaper than a lock and for a machine word it is sufficent.
Resolves rmp in #5981.

Part of the goal in #5981 is to allow multiple instances of OpenRoad to operate on different designs independently.  This would solve thread-safety but not isolation (you would get different values of call_id_ depending on what each instance is doing).

So I looked through the code, and this is very similar to what I'm doing in my rewrite. The std::atomic change is good, but we need to add a new class variable to the Blif class that stores the current value of the std::atomic.

@QuantamHD it if it is a class var there is no need for atomic or static.

It's supposed to provide a unique id (for instance naming purposes) across the whole application even if threads are creating multiple blif objects.
call_id_instance_ = Blif::call_id.fetch_add(1);

It's supposed to provide a unique id (for instance naming purposes) across the whole application even if threads are creating multiple blif objects.
call_id_instance_ = Blif::call_id.fetch_add(1);

The names will be unstable and if abc has any dependency on them then the results will be unstable.  It seems better to put the counter inside the thread than share it regardless of atomic/lock.

So making it thread_local? You need some way to persist the id across constructors.

Maybe there's a bit of confusion here. The point of this call_id is to give unique object names to things coming back into OpenROAD from ABC

Are different threads adding to the same db? If so, then thread local won't ensure uniqueness (and requires a lock).  If not then thread local would work.

Thank you both for your comments.
First, let me explain how I understand this code, what the PR does, and then we can be more explicit about what's required.
Blif::call_id_ is a static data member, therefore a global not tied to any instance. It essentially counts instances because it is only incremented in the constructor (blif.cpp:80). It is read a number of times in Blif::readBlif to create unique names. AFAICT, the constructor is also called only once in rmp.i:86.
By making it atomic, we ensure it is correctly incremented as a global counter (operator ++ on std::atomic does a fetch_and_add). I will continue to count instances, and indeed, with the current way it is used, every read will give you the latest value written, not identify a particular instance.
It will also only count instances in the same process; that is, as long as we only spawn threads, we'll get the global counter behavior (and it is thread safe). If we fork a different process, that process will start counting from the current value, and the two processes will have overlapping sequences.
What do we want?

If we want global counting to generate unique names, we'll need to increment call_id_ when we create the nets in Blif::readBlif. The atomic static data member will work as long as we do not fork processes.
If we want to count instances in a multithreaded environment, then, yes, @QuantamHD's suggestion of saving the instance counter as a data member and using that to create the names will generate unique names for each instance.
If we want a global counter across multiple processes, then we need a different protocol -- one that allows information exchange across processes. In principle that can be done through common storage or by using Message Passing Interface (MPI) like naming rank_id:instance_id.

Let me know which one of these is the intended design.

Are different threads adding to the same db? If so, then thread local won't ensure uniqueness (and requires a lock). If not then thread local would work.

No I think this is meant to be single threaded. @maliberty I think option 2 of @cc10512's should be what we move forward with. Do you concur?

Does option 2 mean "So making it thread_local? You need some way to persist the id across constructors."?  If so, yes.

@maliberty option 2 means that you make it "instance local". You have a global counter that's thread safe, and if you save that in your instance, then each instance will have a unique value.
What option 2 will not do is guarantee thread safety for instances -- that is, if you share an instance pointer across threads, then we'll have to look at the thread safety for all the other methods and data members. However, the since this new instance_id data member will be currently assigned once (in the constructor, therefore before one can share the pointer) and then only read, then all threads "using" this instance will see the same value.

Based on our discussion until now, I believe option 2 is what we want. I pushed a commit to that effect so that @maliberty can see the code and decide.

Here is a code example that shows how this works in a multithreaded environment:
#include <atomic>
#include <cassert>
#include <future>
#include <iostream>
#include <thread>
#include <vector>

class A {
public:
  static int              _non_safe_counter;
  static std::atomic<int> _safe_counter;
  int                     _instance_id;

  A() {
    _non_safe_counter++;
    _instance_id = ++_safe_counter;
  }
};

int A::_non_safe_counter = 0;
std::atomic<int> A::_safe_counter{0};
constexpr int ITERS = 10000;

void worker(std::promise<int> promise)
{
  A *a;
  for(int i = 0; i < ITERS; i++)
    a = new A();

  promise.set_value(a->_instance_id);
}

int main()
{
  constexpr int N = 10;
  std::vector<std::thread> pool;
  std::vector<std::promise<int>> results;
  std::vector<std::future<int>> futures;

  // setup the return results as futures based on promises
  for (int n = 0; n < N; n++) {
    std::promise<int> *default_promise = new std::promise<int>();
    futures.push_back(default_promise->get_future());
    results.push_back(std::move(*default_promise));
  }

  // create the treads; they start running as soon as they are constructed
  for (int n = 0; n < N; n++)
    pool.push_back(std::thread(worker, std::move(results[n])));

  // join the thread so that we ensure that all the work is finished
  for (int n = 0; n < N; n++)
    pool[n].join();

  // create one new instance: its id should be N * ITERS + 1
  A *a = new A();
  for (int n = 0; n < N; n++) {
    auto ai = futures[n].get();
    // show a proper interleaving of threads; these should be random numbers
    // close to max (N * ITERS)
    std::cout << "Thread " << n << ": instance id is: " << ai << "\n";
  }
  std::cout << "Global: atomic counter is " << a->_safe_counter << "\n\t"
            << "non-atomic counter is " << a->_non_safe_counter << "\n\t"
            << "instance_id is " << a->_instance_id << "\n";

  assert(a->_instance_id == N * ITERS + 1);
  return 0;
}

Compile with clang++ --std=c++20 instances.cc
The output of this program is:
Thread 0: instance id is: 61030
Thread 1: instance id is: 72861
Thread 2: instance id is: 92077
Thread 3: instance id is: 81543
Thread 4: instance id is: 98120
Thread 5: instance id is: 82180
Thread 6: instance id is: 95331
Thread 7: instance id is: 77188
Thread 8: instance id is: 99926
Thread 9: instance id is: 100000
Global: atomic counter is 100001
	non-atomic counter is 41803
	instance_id is 100001

I hope this convinces you that the handling of instances is thread safe.

I am confused about the goal here.  @QuantamHD is rewritting this code not use blif at all but to directly call abc.  The current code doesn't use threads.  It seems we are expending effort on condemned code.
When we have multiple OpenRoad objects in a single process then we don't want any sharing through instance_counter_ even if atomic.  It makes the object names non-deterministic and anything that depends on them will be such.  @QuantamHD suggested have name generation happen in odb which is reasonable and would kill this variable altogether (replacing it with a non-static in the db).

I hadn't had a chance to respond, but I realized you were right @maliberty. The end state we want is to have hermetic objects in the same thread.
Design x1;
Design x2;

x1.doStuff();
x2.doStuff();

x1.writeVerilog();
x2.writeVerilog();

If we leave the static around the output of x1 and x2 will depend on the order in which they're run. We should in-fact move the counter to this class which has a 1-1 correspondence with Design https://github.com/The-OpenROAD-Project/OpenROAD/blob/master/src/rmp/include/rmp/Restructure.h as @maliberty.
Sorry for the confusion @cc10512, we should in-fact remove the static and move it to Restructure.h and pipe it to this location. Otherwise we'll create non-hermetic outputs.

It seems we are expending effort on condemned code.

I need this functionality for my rewrite, so it's not wasted effort @maliberty

Ok so it sounds like this PR is moot and you'll approach solving it as you suggest.