Unable to build on Linux, possible version issues

I am unable to build this on Linux. I created a new conda env. As it turns out,
pip install -r requirements.txt
fails unless I first do
conda install pip python==3.8.5
Other versions may work as well, but the default one (for me, it was 3.9.2) wasn't working. After this, I also had to execute
conda install numpy-base cudatoolkit-dev cudnn
to get it to build. Perhaps these packages and their versions should be fixed?
Even after this, when I try building (after having done git submodule update --init), I get errors. Here is the output from make

$ make
mkdir -p build && cd build && cmake ../csrc/liars_dice -DCMAKE_LIBRARY_OUTPUT_DIRECTORY=../cfvpy && make -j
-- The C compiler identification is GNU 8.3.0
-- The CXX compiler identification is GNU 8.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Deprecation Warning at /user/up2139/ciamac/rebel/third_party/googletest/CMakeLists.txt:4 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.
Update the VERSION argument  value or use a ... suffix to tell
CMake that the project does not need compatibility with older versions.
CMake Deprecation Warning at /user/up2139/ciamac/rebel/third_party/googletest/googlemock/CMakeLists.txt:45 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.
Update the VERSION argument  value or use a ... suffix to tell
CMake that the project does not need compatibility with older versions.
CMake Deprecation Warning at /user/up2139/ciamac/rebel/third_party/googletest/googletest/CMakeLists.txt:56 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.
Update the VERSION argument  value or use a ... suffix to tell
CMake that the project does not need compatibility with older versions.
-- Found PythonInterp: /user/up2139/.conda/envs/rebel/bin/python (found version "3.8.5")
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Found PythonInterp: /user/up2139/.conda/envs/rebel/bin/python (found suitable version "3.8.5", minimum required is "3.7")
-- Found PythonLibs: /user/up2139/.conda/envs/rebel/lib/libpython3.8.so (found suitable version "3.8.5", minimum required is "3.7")
-- Found CUDA: /user/up2139/.conda/envs/rebel (found version "10.1")
-- Caffe2: CUDA detected: 10.1
-- Caffe2: CUDA nvcc is: /user/up2139/.conda/envs/rebel/bin/nvcc
-- Caffe2: CUDA toolkit directory: /user/up2139/.conda/envs/rebel
-- Caffe2: Header version is: 10.1
-- Found CUDNN: /user/up2139/.conda/envs/rebel/lib/libcudnn.so
-- Found cuDNN: v7.6.5  (include: /user/up2139/.conda/envs/rebel/include, library: /user/up2139/.conda/envs/rebel/lib/libcudnn.so)
-- Added CUDA NVCC flags for: -gencode;arch=compute_60,code=sm_60;-gencode;arch=compute_70,code=sm_70
CMake Warning (dev) at /user/up2139/.conda/envs/rebel/share/cmake-3.19/Modules/FindPackageHandleStandardArgs.cmake:426 (message):
The package name passed to find_package_handle_standard_args (torch) does
not match the name of the calling package (Torch).  This can lead to
problems in calling code that expects find_package result variables
(e.g., _FOUND) to follow a certain pattern.
Call Stack (most recent call first):
/user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/share/cmake/Torch/TorchConfig.cmake:122 (find_package_handle_standard_args)
CMakeLists.txt:34 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.
-- Found torch: /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libtorch.so
-- Found PythonInterp: /user/up2139/.conda/envs/rebel/bin/python (found version "3.8.5")
-- Found PythonLibs: /user/up2139/.conda/envs/rebel/lib/libpython3.8.so
-- pybind11 v2.3.dev1
-- Performing Test HAS_FLTO
-- Performing Test HAS_FLTO - Success
-- LTO enabled
-- Configuring done
-- Generating done
-- Build files have been written to: /user/up2139/ciamac/rebel/build
make[1]: Entering directory '/user/up2139/ciamac/rebel/build'
make[2]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
Scanning dependencies of target liars_dice_lib
Scanning dependencies of target gtest
Scanning dependencies of target _rela
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
[  3%] Building CXX object third_party/googletest/googletest/CMakeFiles/gtest.dir/src/gtest-all.cc.o
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
[  7%] Building CXX object CMakeFiles/liars_dice_lib.dir/real_net.cc.o
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
[ 11%] Building CXX object CMakeFiles/liars_dice_lib.dir/liars_dice.cc.o
[ 23%] Building CXX object CMakeFiles/liars_dice_lib.dir/subgame_solving.cc.o
[ 23%] Building CXX object CMakeFiles/liars_dice_lib.dir/stats.cc.o
[ 23%] Building CXX object CMakeFiles/liars_dice_lib.dir/recursive_solving.cc.o
[ 26%] Building CXX object CMakeFiles/_rela.dir/rela/types.cc.o
[ 30%] Linking CXX static library ../../../lib/libgtest.a
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
[ 30%] Built target gtest
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
Scanning dependencies of target gtest_main
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
[ 34%] Building CXX object third_party/googletest/googletest/CMakeFiles/gtest_main.dir/src/gtest_main.cc.o
[ 38%] Linking CXX static library ../../../lib/libgtest_main.a
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
[ 38%] Built target gtest_main
[ 42%] Linking CXX static library lib_rela.a
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
[ 42%] Built target rela
[ 46%] Linking CXX static library libliars_dice_lib.a
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
[ 46%] Built target liars_dice_lib
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
Scanning dependencies of target liar_subgame_solving_test
Scanning dependencies of target liar_tree_test
Scanning dependencies of target recursive_eval
Scanning dependencies of target liar_game_test
Scanning dependencies of target gen_benchmark
Scanning dependencies of target rela
Scanning dependencies of target liar_recursive_solving_test
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: *** No rule to make target '/usr/local/cuda/lib64/libnvToolsExt.so', needed by 'liar_game_test'.  Stop.
make[3]: *** Waiting for unfinished jobs....
make[3]: *** No rule to make target '/usr/local/cuda/lib64/libnvToolsExt.so', needed by 'liar_tree_test'.  Stop.
make[3]: *** Waiting for unfinished jobs....
[ 53%] Building CXX object CMakeFiles/liar_tree_test.dir/tree_test.cc.o
[ 53%] Building CXX object CMakeFiles/liar_game_test.dir/liars_dice_test.cc.o
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: *** No rule to make target '/usr/local/cuda/lib64/libnvToolsExt.so', needed by 'recursive_eval'.  Stop.
make[3]: *** Waiting for unfinished jobs....
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: *** No rule to make target '/usr/local/cuda/lib64/libnvToolsExt.so', needed by 'liar_subgame_solving_test'.  Stop.
make[3]: *** Waiting for unfinished jobs....
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: *** No rule to make target '/usr/local/cuda/lib64/libnvToolsExt.so', needed by 'liar_recursive_solving_test'.  Stop.
make[3]: *** Waiting for unfinished jobs....
[ 61%] Building CXX object CMakeFiles/recursive_eval.dir/recursive_eval.cc.o
[ 61%] Building CXX object CMakeFiles/liar_subgame_solving_test.dir/subgame_solving_test.cc.o
[ 65%] Building CXX object CMakeFiles/liar_recursive_solving_test.dir/recursive_solving_test.cc.o
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: *** No rule to make target '/usr/local/cuda/lib64/libnvToolsExt.so', needed by 'gen_benchmark'.  Stop.
make[3]: *** Waiting for unfinished jobs....
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: *** No rule to make target '/usr/local/cuda/lib64/libnvToolsExt.so', needed by '/user/up2139/ciamac/rebel/cfvpy/rela.cpython-38-x86_64-linux-gnu.so'.  Stop.
make[3]: *** Waiting for unfinished jobs....
[ 69%] Building CXX object CMakeFiles/gen_benchmark.dir/gen_benchmark.cc.o
[ 73%] Building CXX object CMakeFiles/rela.dir/rela/pybind.cc.o
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[2]: *** [CMakeFiles/Makefile2:361: CMakeFiles/liar_game_test.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[2]: *** [CMakeFiles/Makefile2:275: CMakeFiles/liar_tree_test.dir/all] Error 2
In file included from /user/up2139/ciamac/rebel/csrc/liars_dice/rela/thread_loop.h:20,
from /user/up2139/ciamac/rebel/csrc/liars_dice/rela/context.h:22,
from /user/up2139/ciamac/rebel/csrc/liars_dice/gen_benchmark.cc:22:
/user/up2139/ciamac/rebel/csrc/liars_dice/rela/model_locker.h:54:7: warning: ‘rela::ModelLocker’ declared with greater visibility than the type of its field ‘rela::ModelLocker::pyModels’ [-Wattributes]
class ModelLocker {
^~~~~~~~~~~
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[2]: *** [CMakeFiles/Makefile2:304: CMakeFiles/liar_subgame_solving_test.dir/all] Error 2
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[2]: *** [CMakeFiles/Makefile2:418: CMakeFiles/liar_recursive_solving_test.dir/all] Error 2
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[2]: *** [CMakeFiles/Makefile2:192: CMakeFiles/recursive_eval.dir/all] Error 2
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[2]: *** [CMakeFiles/Makefile2:389: CMakeFiles/gen_benchmark.dir/all] Error 2
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[2]: *** [CMakeFiles/Makefile2:332: CMakeFiles/rela.dir/all] Error 2
make[2]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[1]: *** [Makefile:160: all] Error 2
make[1]: Leaving directory '/user/up2139/ciamac/rebel/build'
make: *** [Makefile:5: compile] Error 2

Note that the file it is looking for -- libnvToolsExt.so, is available in my Conda environment (~/.conda/envs//lib/), but for some reason it is looking for that file in /usr/local/cuda/lib64, a path that doesn't even exist. After looking at the CMake generated makefiles, it seems it is also looking for libcudart.so in /usr/local/cuda/lib64, another file that is available in my local environment.

$ grep "/usr/local/cuda/lib64" -nRIi build
build/CMakeFiles/liar_recursive_solving_test.dir/link.txt:1:/usr/bin/c++  -I .. -Wall -mcmodel=medium -march=native -Wextra -Wno-register -fPIC -Wfatal-errors -O3 -g -fno-omit-frame-pointer -rdynamic CMakeFiles/liar_recursive_solving_test.dir/recursive_solving_test.cc.o -o liar_recursive_solving_test   -L/usr/local/cuda/lib64  -Wl,-rpath,/user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib:/usr/local/cuda/lib64:/user/up2139/.conda/envs/rebel/lib64:/user/up2139/.conda/envs/rebel/lib libliars_dice_lib.a lib/libgtest_main.a /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libtorch.so /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libc10_cuda.so /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libc10.so /user/up2139/.conda/envs/rebel/lib64/libcudart.so -lnvToolsExt -lcudart /user/up2139/.conda/envs/rebel/lib64/libcufft.so /user/up2139/.conda/envs/rebel/lib64/libcurand.so /user/up2139/.conda/envs/rebel/lib64/libcublas.so /user/up2139/.conda/envs/rebel/lib/libcudnn.so lib/libgtest.a -lpthread
build/CMakeFiles/liar_recursive_solving_test.dir/build.make:107:liar_recursive_solving_test: /usr/local/cuda/lib64/libnvToolsExt.so
build/CMakeFiles/liar_recursive_solving_test.dir/build.make:108:liar_recursive_solving_test: /usr/local/cuda/lib64/libcudart.so
build/CMakeFiles/liar_tree_test.dir/link.txt:1:/usr/bin/c++  -I .. -Wall -mcmodel=medium -march=native -Wextra -Wno-register -fPIC -Wfatal-errors -O3 -g -fno-omit-frame-pointer -rdynamic CMakeFiles/liar_tree_test.dir/tree_test.cc.o -o liar_tree_test   -L/usr/local/cuda/lib64  -Wl,-rpath,/user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib:/usr/local/cuda/lib64:/user/up2139/.conda/envs/rebel/lib64:/user/up2139/.conda/envs/rebel/lib libliars_dice_lib.a lib/libgtest_main.a /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libtorch.so /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libc10_cuda.so /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libc10.so /user/up2139/.conda/envs/rebel/lib64/libcudart.so -lnvToolsExt -lcudart /user/up2139/.conda/envs/rebel/lib64/libcufft.so /user/up2139/.conda/envs/rebel/lib64/libcurand.so /user/up2139/.conda/envs/rebel/lib64/libcublas.so /user/up2139/.conda/envs/rebel/lib/libcudnn.so lib/libgtest.a -lpthread
build/CMakeFiles/liar_tree_test.dir/build.make:107:liar_tree_test: /usr/local/cuda/lib64/libnvToolsExt.so
build/CMakeFiles/liar_tree_test.dir/build.make:108:liar_tree_test: /usr/local/cuda/lib64/libcudart.so
build/CMakeFiles/rela.dir/link.txt:1:/usr/bin/c++ -fPIC  -I .. -Wall -mcmodel=medium -march=native -Wextra -Wno-register -fPIC -Wfatal-errors -O3 -g -fno-omit-frame-pointer -shared  -o /user/up2139/ciamac/rebel/cfvpy/rela.cpython-38-x86_64-linux-gnu.so CMakeFiles/rela.dir/rela/pybind.cc.o   -L/usr/local/cuda/lib64  -Wl,-rpath,/user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib:/usr/local/cuda/lib64:/user/up2139/.conda/envs/rebel/lib64:/user/up2139/.conda/envs/rebel/lib -flto lib_rela.a libliars_dice_lib.a /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libtorch.so -lpthread /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libc10_cuda.so /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libc10.so /user/up2139/.conda/envs/rebel/lib64/libcudart.so -lnvToolsExt -lcudart /user/up2139/.conda/envs/rebel/lib64/libcufft.so /user/up2139/.conda/envs/rebel/lib64/libcurand.so /user/up2139/.conda/envs/rebel/lib64/libcublas.so /user/up2139/.conda/envs/rebel/lib/libcudnn.so
build/CMakeFiles/rela.dir/build.make:107:/user/up2139/ciamac/rebel/cfvpy/rela.cpython-38-x86_64-linux-gnu.so: /usr/local/cuda/lib64/libnvToolsExt.so
build/CMakeFiles/rela.dir/build.make:108:/user/up2139/ciamac/rebel/cfvpy/rela.cpython-38-x86_64-linux-gnu.so: /usr/local/cuda/lib64/libcudart.so
build/CMakeFiles/recursive_eval.dir/link.txt:1:/usr/bin/c++  -I .. -Wall -mcmodel=medium -march=native -Wextra -Wno-register -fPIC -Wfatal-errors -O3 -g -fno-omit-frame-pointer -rdynamic CMakeFiles/recursive_eval.dir/recursive_eval.cc.o -o recursive_eval   -L/usr/local/cuda/lib64  -Wl,-rpath,/user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib:/usr/local/cuda/lib64:/user/up2139/.conda/envs/rebel/lib64:/user/up2139/.conda/envs/rebel/lib libliars_dice_lib.a /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libtorch.so -lpthread /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libc10_cuda.so /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libc10.so /user/up2139/.conda/envs/rebel/lib64/libcudart.so -lnvToolsExt -lcudart /user/up2139/.conda/envs/rebel/lib64/libcufft.so /user/up2139/.conda/envs/rebel/lib64/libcurand.so /user/up2139/.conda/envs/rebel/lib64/libcublas.so /user/up2139/.conda/envs/rebel/lib/libcudnn.so
build/CMakeFiles/recursive_eval.dir/build.make:106:recursive_eval: /usr/local/cuda/lib64/libnvToolsExt.so
build/CMakeFiles/recursive_eval.dir/build.make:107:recursive_eval: /usr/local/cuda/lib64/libcudart.so
build/CMakeFiles/liar_game_test.dir/link.txt:1:/usr/bin/c++  -I .. -Wall -mcmodel=medium -march=native -Wextra -Wno-register -fPIC -Wfatal-errors -O3 -g -fno-omit-frame-pointer -rdynamic CMakeFiles/liar_game_test.dir/liars_dice_test.cc.o -o liar_game_test   -L/usr/local/cuda/lib64  -Wl,-rpath,/user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib:/usr/local/cuda/lib64:/user/up2139/.conda/envs/rebel/lib64:/user/up2139/.conda/envs/rebel/lib libliars_dice_lib.a lib/libgtest_main.a /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libtorch.so /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libc10_cuda.so /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libc10.so /user/up2139/.conda/envs/rebel/lib64/libcudart.so -lnvToolsExt -lcudart /user/up2139/.conda/envs/rebel/lib64/libcufft.so /user/up2139/.conda/envs/rebel/lib64/libcurand.so /user/up2139/.conda/envs/rebel/lib64/libcublas.so /user/up2139/.conda/envs/rebel/lib/libcudnn.so lib/libgtest.a -lpthread
build/CMakeFiles/liar_game_test.dir/build.make:107:liar_game_test: /usr/local/cuda/lib64/libnvToolsExt.so
build/CMakeFiles/liar_game_test.dir/build.make:108:liar_game_test: /usr/local/cuda/lib64/libcudart.so
build/CMakeFiles/gen_benchmark.dir/link.txt:1:/usr/bin/c++  -I .. -Wall -mcmodel=medium -march=native -Wextra -Wno-register -fPIC -Wfatal-errors -O3 -g -fno-omit-frame-pointer -rdynamic CMakeFiles/gen_benchmark.dir/gen_benchmark.cc.o -o gen_benchmark   -L/usr/local/cuda/lib64  -Wl,-rpath,/user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib:/usr/local/cuda/lib64:/user/up2139/.conda/envs/rebel/lib64:/user/up2139/.conda/envs/rebel/lib libliars_dice_lib.a lib_rela.a /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libtorch.so -lpthread /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libc10_cuda.so /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libc10.so /user/up2139/.conda/envs/rebel/lib64/libcudart.so -lnvToolsExt -lcudart /user/up2139/.conda/envs/rebel/lib64/libcufft.so /user/up2139/.conda/envs/rebel/lib64/libcurand.so /user/up2139/.conda/envs/rebel/lib64/libcublas.so /user/up2139/.conda/envs/rebel/lib/libcudnn.so
build/CMakeFiles/gen_benchmark.dir/build.make:107:gen_benchmark: /usr/local/cuda/lib64/libnvToolsExt.so
build/CMakeFiles/gen_benchmark.dir/build.make:108:gen_benchmark: /usr/local/cuda/lib64/libcudart.so
build/CMakeFiles/liar_subgame_solving_test.dir/link.txt:1:/usr/bin/c++  -I .. -Wall -mcmodel=medium -march=native -Wextra -Wno-register -fPIC -Wfatal-errors -O3 -g -fno-omit-frame-pointer -rdynamic CMakeFiles/liar_subgame_solving_test.dir/subgame_solving_test.cc.o -o liar_subgame_solving_test   -L/usr/local/cuda/lib64  -Wl,-rpath,/user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib:/usr/local/cuda/lib64:/user/up2139/.conda/envs/rebel/lib64:/user/up2139/.conda/envs/rebel/lib libliars_dice_lib.a lib/libgtest_main.a /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libtorch.so /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libc10_cuda.so /user/up2139/.conda/envs/rebel/lib/python3.8/site-packages/torch/lib/libc10.so /user/up2139/.conda/envs/rebel/lib64/libcudart.so -lnvToolsExt -lcudart /user/up2139/.conda/envs/rebel/lib64/libcufft.so /user/up2139/.conda/envs/rebel/lib64/libcurand.so /user/up2139/.conda/envs/rebel/lib64/libcublas.so /user/up2139/.conda/envs/rebel/lib/libcudnn.so lib/libgtest.a -lpthread
build/CMakeFiles/liar_subgame_solving_test.dir/build.make:107:liar_subgame_solving_test: /usr/local/cuda/lib64/libnvToolsExt.so
build/CMakeFiles/liar_subgame_solving_test.dir/build.make:108:liar_subgame_solving_test: /usr/local/cuda/lib64/libcudart.so

I am not able to understand why CMake is trying to find these libs in a path that doesn't exist. It doesn't even seem like this path is hardcoded anywhere. Can you please help?

Yeah, there's a known issue. These paths are harcoded in pytroch-1.4 cmake. You can edit them manually in
$CONDA_PREFIX/lib/python3.7/site-packages/torch/share/cmake/Caffe2/Caffe2Targets.cmake

Thanks! I found this line: INTERFACE_LINK_LIBRARIES "protobuf::libprotobuf;c10;Threads::Threads;caffe2::mkl;caffe2::mkldnn;torch::cudart;c10_cuda;/usr/local/cuda/lib64/libnvToolsExt.so;/usr/local/cuda/lib64/libcudart.so;caffe2::cufft;caffe2::curand;caffe2::cublas;caffe2::cudnn"
How should I edit this again if I don't want to give exact paths? I tried replacing the entire path with just libnvToolsExt and libcudart respectively, but that didn't work. Just nvToolsExt and cudart also didn't work.
To sum up, how should I edit this so that it automatically picks the right libraries from the correct location depending on my conda env?

OK, if I delete the two libraries entirely, it seems to almost work but fails somewhere else. Here is the output from make after cmake has done building.

make[1]: Entering directory '/user/up2139/ciamac/rebel/build'
make[2]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
Scanning dependencies of target liars_dice_lib
Scanning dependencies of target gtest
Scanning dependencies of target _rela
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
[  3%] Building CXX object third_party/googletest/googletest/CMakeFiles/gtest.dir/src/gtest-all.cc.o
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
[  7%] Building CXX object CMakeFiles/liars_dice_lib.dir/liars_dice.cc.o
[ 11%] Building CXX object CMakeFiles/liars_dice_lib.dir/real_net.cc.o
[ 19%] Building CXX object CMakeFiles/liars_dice_lib.dir/recursive_solving.cc.o
[ 19%] Building CXX object CMakeFiles/liars_dice_lib.dir/subgame_solving.cc.o
[ 23%] Building CXX object CMakeFiles/liars_dice_lib.dir/stats.cc.o
[ 26%] Building CXX object CMakeFiles/_rela.dir/rela/types.cc.o
[ 30%] Linking CXX static library ../../../lib/libgtest.a
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
[ 30%] Built target gtest
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
Scanning dependencies of target gtest_main
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
[ 34%] Building CXX object third_party/googletest/googletest/CMakeFiles/gtest_main.dir/src/gtest_main.cc.o
[ 38%] Linking CXX static library ../../../lib/libgtest_main.a
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
[ 38%] Built target gtest_main
[ 42%] Linking CXX static library lib_rela.a
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
[ 42%] Built target rela
[ 46%] Linking CXX static library libliars_dice_lib.a
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
[ 46%] Built target liars_dice_lib
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
Scanning dependencies of target recursive_eval
Scanning dependencies of target liar_tree_test
Scanning dependencies of target liar_subgame_solving_test
Scanning dependencies of target rela
Scanning dependencies of target liar_game_test
Scanning dependencies of target liar_recursive_solving_test
Scanning dependencies of target gen_benchmark
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
[ 53%] Building CXX object CMakeFiles/liar_tree_test.dir/tree_test.cc.o
[ 53%] Building CXX object CMakeFiles/liar_game_test.dir/liars_dice_test.cc.o
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
[ 57%] Building CXX object CMakeFiles/recursive_eval.dir/recursive_eval.cc.o
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
[ 61%] Building CXX object CMakeFiles/liar_subgame_solving_test.dir/subgame_solving_test.cc.o
[ 65%] Building CXX object CMakeFiles/liar_recursive_solving_test.dir/recursive_solving_test.cc.o
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
make[3]: Entering directory '/user/up2139/ciamac/rebel/build'
[ 69%] Building CXX object CMakeFiles/gen_benchmark.dir/gen_benchmark.cc.o
[ 73%] Building CXX object CMakeFiles/rela.dir/rela/pybind.cc.o
[ 76%] Linking CXX executable liar_game_test
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
[ 76%] Built target liar_game_test
[ 80%] Linking CXX executable liar_tree_test
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
[ 80%] Built target liar_tree_test
In file included from /user/up2139/ciamac/rebel/csrc/liars_dice/rela/thread_loop.h:20,
from /user/up2139/ciamac/rebel/csrc/liars_dice/rela/context.h:22,
from /user/up2139/ciamac/rebel/csrc/liars_dice/gen_benchmark.cc:22:
/user/up2139/ciamac/rebel/csrc/liars_dice/rela/model_locker.h:54:7: warning: ‘rela::ModelLocker’ declared with greater visibility than the type of its field ‘rela::ModelLocker::pyModels’ [-Wattributes]
class ModelLocker {
^~~~~~~~~~~
[ 84%] Linking CXX executable liar_recursive_solving_test
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
[ 84%] Built target liar_recursive_solving_test
[ 88%] Linking CXX executable liar_subgame_solving_test
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
[ 88%] Built target liar_subgame_solving_test
[ 92%] Linking CXX executable recursive_eval
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
[ 92%] Built target recursive_eval
[ 96%] Linking CXX executable gen_benchmark
/usr/bin/ld: CMakeFiles/gen_benchmark.dir/gen_benchmark.cc.o: in function _Py_DECREF': /user/up2139/.conda/envs/rebel/include/python3.8/object.h:478: undefined reference to _Py_Dealloc'
/usr/bin/ld: /user/up2139/.conda/envs/rebel/include/python3.8/object.h:478: undefined reference to `_Py_Dealloc'
collect2: error: ld returned 1 exit status
make[3]: *** [CMakeFiles/gen_benchmark.dir/build.make:113: gen_benchmark] Error 1
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[2]: *** [CMakeFiles/Makefile2:389: CMakeFiles/gen_benchmark.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....
[100%] Linking CXX shared module /user/up2139/ciamac/rebel/cfvpy/rela.cpython-38-x86_64-linux-gnu.so
make[3]: Leaving directory '/user/up2139/ciamac/rebel/build'
[100%] Built target rela
make[2]: Leaving directory '/user/up2139/ciamac/rebel/build'
make[1]: *** [Makefile:160: all] Error 2
make[1]: Leaving directory '/user/up2139/ciamac/rebel/build'
make: *** [Makefile:5: compile] Error 2

Did I break something else when I removed the libraries entirely?

I have seen this issue when using python=3.8. The issue is gone when I switch to python=3.7. You can give it a try.

I have seen this issue when using python=3.8. The issue is gone when I switch to python=3.7. You can give it a try.

Did you compile it successfully? I ran into the same problem.

why displays such an error?
CMake Error at /root/anaconda3/envs/myenv/lib/python3.7/site-packages/torch/share/cmake/Caffe2/Caffe2Config.cmake:96 (message):
Your installed Caffe2 version uses cuDNN but I cannot find the cuDNN
libraries.  Please set the proper cuDNN prefixes and / or install cuDNN.
Call Stack (most recent call first):
/root/anaconda3/envs/myenv/lib/python3.7/site-packages/torch/share/cmake/Torch/TorchConfig.cmake:40 (find_package)
CMakeLists.txt:34 (find_package)

I have seen this issue when using python=3.8. The issue is gone when I switch to python=3.7. You can give it a try.

Did you compile it successfully? I ran into the same problem.

Switching to python=3.7 solves my problem.


Update README.md

Can one of the admins verify this patch?

I signed it!

@av8ramit does this look good to you (note it is targeting the r1.1 branch)


content_changed implementation

https://github.com/DMTF/libspdm/blob/704d5652b2eeb451fffbd1bb1129046e377c9cf3/include/hal/library/responder/measlib.h#L77
Hi,
I have a question about content_changed implementation.
The integrator will need the knowledge about measurement logs in current L2 contents as a basis to check if there is any measurement changed. But the function didn't seem to be able to provide such information.
Is there a design/mechanism for integrators to acquire the information from libspdm?

The Integrator needs to monitor request_attribute and the SignatureRequested bit, since content_change can only be asserted when a signature is requested. So it keeps track of measurements when SignatureRequested is not set, and does a comparison when SignatureRequested is set.

Thanks and I think that works for normal scenario. But as "Any communication between Requester and Responder other than a GET_MEASUREMENTS request or response re-initializes L1/L2 computation to null .", the integrator seems not able to know if L1/L2 has been re-inited?

Yes, that looks like it's an issue. The state of the l1/l2 transcript is stored in the spdm_context but it is currently not public. We would need to provide a public function to query the transcript state. @jyao1 does that sound good?

I feel a callback function to notify L1/L2 was reset might be easier for integrators to track the measurement.
Maybe provide a callback function for transcript state change (similar to connection state callback)?

I will draw up the two approaches and we can see which ones looks the best: callback versus querying the transcript from the spdm_context.


Improve parameter-binding performance of large instructions

Summary
Previously, the parameter-assignment methods of QuantumCircuit had poor performance when an instruction had a complex definition that involved many of the parameters being bound.  The strategy of binding each parameter separately led to each definition being copied and rebound multiple times, with each rebinding being recursive all the way down.
This commit makes the definition rebinding happen only once per instruction, and updates the data model used to make it a complete recursion through QuantumCircuit.assign_parameters.  This has the side effect of fixing an issue where internal global phases would not be updated.
The algorithmic change that enables this (just rebind the definition at the end) is rather simpler than the length of this patch suggests.  This is just because the previous structure of separating out a single _assign_parameter method made it harder to restructure the logic without introducing unpleasant stateful coupling between the driver and helper methods.  Instead, I inlined most of the helper functions into the driver body, so we can treat some components of the binding in a per-parameter way and some in a per-operation way, in whatever way is better.

Details and comments
Fix #10282
Fix #10283
As an example, take a setup of
import math
from qiskit.circuit.library import EfficientSU2

qc = EfficientSU2(100, entanglement="linear", reps=100)
qc.measure_all()
ps = {x: math.pi / 2 for x in qc.parameters}

then the binding example
qc.assign_parameters(ps)

(or bind_parameters) took my machine about 7m10s on main, and 1.24s after this PR (so a ~350x speedup).  It's probably not quite as fast as the flattening in #10269 because we still have some overhead from dealing with the extra structure, but it's a big general step in a good direction, with (hopefully) no other user-facing implications.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

76 of 77 (98.7%)  changed or added relevant lines in 3 files are covered.
5 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.02%) to 85.96%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit/circuit/quantumcircuit.py
72
73
98.63%

Files with Coverage Reduction
New Missed Lines
%

qiskit/circuit/parametertable.py
1
88.19%

crates/qasm2/src/lex.rs
4
91.39%

Totals

Change from base Build<PHONE_NUMBER>:
0.02%

Covered Lines:
71334

Relevant Lines:
82985

💛  - Coveralls

For the PEC slowdown: thanks for reminding me.  I had seen a small slowdown, but not of the same magnitude as you. The reason is likely because the PEC code passes a vector of parameters to bind rather than a dictionary, and there's a bit more overhead in the new code to normalise the input formats.  I should be able to fix that.

I've done a little bit of lazy-evaluation trickery to remove the overhead from input normalisation, so nothing gets calculated until it's actually used.  Stemming from that abstraction, I was able to remove some overhead from the dictionary input form as well (no need to make a separate filtered dictionary; the filtering is just done as part of the iteration).


Can I get a real time image instead of taking a photo?

Question
Can I get a real time image instead of taking a photo?
What I tried
No response
VisionCamera Version
2.12.0
Additional information

[ ] I am using Expo
[X] I have read the Troubleshooting Guide
[X] I agree to follow this project's Code of Conduct
[X] I searched for similar questions in the issues page as well as in the discussions page and found none.

Read the docs. Frame Processors is what you're looking for.


mercurial: 6.1.1 -> 6.1.2

Description of changes
Release notes: https://www.mercurial-scm.org/wiki/Release6.1
Importantly: "Fix incorrect metadata causing dirstate-v2 data loss in edge case"
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)
[ ] 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
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.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
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

New test failure: https://bz.mercurial-scm.org/show_bug.cgi?id=6696

Setting HGMODULEPOLICY=rust+c allows the test to pass.


assert res == GL_FRAMEBUFFER_COMPLETE

I want to make my Pytorch-a2c-ppo work for your environment.
I cloned and installed the package but when I do:
./manual_control.py --env-name MiniWorld-Hallway-v0
I get this:
Registered env: MiniWorld-CollectHealth-v0
Registered env: MiniWorld-FourRooms-v0
Registered env: MiniWorld-Hallway-v0
Registered env: MiniWorld-Maze-v0
Registered env: MiniWorld-MazeS3-v0
Registered env: MiniWorld-OneRoom-v0
Registered env: MiniWorld-PutNext-v0
Registered env: MiniWorld-TMaze-v0
Registered env: MiniWorld-ThreeRooms-v0
Registered env: MiniWorld-WallGap-v0
Traceback (most recent call last):
  File "./manual_control.py", line 23, in <module>
    env = gym.make(args.env_name)
  File "/home/lcswillems/miniconda3/lib/python3.6/site-packages/gym/envs/registration.py", line 167, in make
    return registry.make(id)
  File "/home/lcswillems/miniconda3/lib/python3.6/site-packages/gym/envs/registration.py", line 119, in make
    env = spec.make()
  File "/home/lcswillems/miniconda3/lib/python3.6/site-packages/gym/envs/registration.py", line 86, in make
    env = cls(**self._kwargs)
  File "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/gym-miniworld/gym_miniworld/envs/oneroom.py", line 18, in __init__
    **kwargs
  File "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/gym-miniworld/gym_miniworld/miniworld.py", line 517, in __init__
    self.obs_fb = FrameBuffer(obs_width, obs_height, 8)
  File "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/gym-miniworld/gym_miniworld/opengl.py", line 183, in __init__
    assert res == GL_FRAMEBUFFER_COMPLETE
AssertionError

Do you know what I did wrong?

:O
Seems there's some issue with OpenGL drivers. Are you running Mac/Linux? What kind of GPU?

I am running on Linux. For the GPU, I don't really know.
If I execute sudo lshw -C display, I get:
  *-display
       description: VGA compatible controller
       product: 4th Gen Core Processor Integrated Graphics Controller
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 06
       width: 64 bits
       clock: 33MHz
       capabilities: msi pm vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: irq:30 memory:f7800000-f7bfffff memory:e0000000-efffffff ioport:f000(size=64) memory:c0000-dffff

I don't know if it helps...

Yes that is useful. Your GPU is the one that comes built into your Intel CPU. The driver you use is probably the default one that comes with Linux.
I added some extra debugging code which will hopefully give us more information about the specific frame buffer error that happened. Could you do a git pull and run it again?

gym-miniworld$ ./manual_control.py --env-name MiniWorld-Hallway-v0Registered env: MiniWorld-CollectHealth-v0
Registered env: MiniWorld-FourRooms-v0
Registered env: MiniWorld-Hallway-v0
Registered env: MiniWorld-Maze-v0
Registered env: MiniWorld-MazeS3-v0
Registered env: MiniWorld-OneRoom-v0
Registered env: MiniWorld-PutNext-v0
Registered env: MiniWorld-TMaze-v0
Registered env: MiniWorld-ThreeRooms-v0
Registered env: MiniWorld-WallGap-v0
Traceback (most recent call last):
  File "./manual_control.py", line 23, in <module>
    env = gym.make(args.env_name)
  File "/home/lcswillems/miniconda3/lib/python3.6/site-packages/gym/envs/registration.py", line 167, in make
    return registry.make(id)
  File "/home/lcswillems/miniconda3/lib/python3.6/site-packages/gym/envs/registration.py", line 119, in make
    env = spec.make()
  File "/home/lcswillems/miniconda3/lib/python3.6/site-packages/gym/envs/registration.py", line 86, in make
    env = cls(**self._kwargs)
  File "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/gym-miniworld/gym_miniworld/envs/hallway.py", line 19, in __init__
    **kwargs
  File "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/gym-miniworld/gym_miniworld/miniworld.py", line 517, in __init__
    self.obs_fb = FrameBuffer(obs_width, obs_height, 8)
  File "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/gym-miniworld/gym_miniworld/opengl.py", line 196, in __init__
    assert res == GL_FRAMEBUFFER_COMPLETE, FB_ERROR_ENUMS.get(res, res)
AssertionError: GL_FRAMEBUFFER_UNSUPPORTED

Okay, might be making progress :)
I added an extra check. Could you please try running it once more.
Then, if it doesn't work, can you try:

Setting num_samples = 1 before the try block.
Replacing this line with just assert False: https://github.com/maximecb/gym-miniworld/blob/master/gym_miniworld/opengl.py#L134

I'd like to know if either of these fix the problem. Sorry this is taking multiple iterations to debug.

This works when I do the modifications 1. and 2. you suggest.

I keep trying to make your repository working for mine, but now, I have a new bug:
torch-rl$ python -m scripts.train --algo ppo --env MiniWorld-Hallway-v0
Registered env: MiniWorld-CollectHealth-v0
Registered env: MiniWorld-FourRooms-v0
Registered env: MiniWorld-Hallway-v0
Registered env: MiniWorld-Maze-v0
Registered env: MiniWorld-MazeS3-v0
Registered env: MiniWorld-OneRoom-v0
Registered env: MiniWorld-PutNext-v0
Registered env: MiniWorld-TMaze-v0
Registered env: MiniWorld-ThreeRooms-v0
Registered env: MiniWorld-WallGap-v0
/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/torch-rl/scripts/train.py --algo ppo --env MiniWorld-Hallway-v0

Namespace(algo='ppo', batch_size=256, clip_eps=0.2, discount=0.99, entropy_coef=0.01, env='MiniWorld-Hallway-v0', epochs=4, frames=10000000,frames_per_proc=None, gae_lambda=0.95, instr=False, log_interval=1, lr=0.0007, max_grad_norm=0.5, mem=False, model=None, optim_alpha=0.99, optim_eps=1e-05, procs=16, recurrence=1, save_interval=0, seed=1, tb=False, value_loss_coef=0.5)

loading texture "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/gym-miniworld/gym_miniworld/textures/concrete_1.png"
loading texture "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/gym-miniworld/gym_miniworld/textures/floor_tiles_bw_1.png"
loading texture "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/gym-miniworld/gym_miniworld/textures/concrete_tiles_1.png"
Model successfully created

ACModel(
  (image_conv): Sequential(
    (0): Conv2d(3, 16, kernel_size=(2, 2), stride=(1, 1))
    (1): ReLU()
    (2): MaxPool2d(kernel_size=(2, 2), stride=(2, 2), padding=0, dilation=1, ceil_mode=False)
    (3): Conv2d(16, 32, kernel_size=(2, 2), stride=(1, 1))
    (4): ReLU()
    (5): Conv2d(32, 64, kernel_size=(2, 2), stride=(1, 1))
    (6): ReLU()
  )
  (actor): Sequential(
    (0): Linear(in_features=63936, out_features=64, bias=True)
    (1): Tanh()
    (2): Linear(in_features=64, out_features=3, bias=True)
  )
  (critic): Sequential(
    (0): Linear(in_features=63936, out_features=64, bias=True)
    (1): Tanh()
    (2): Linear(in_features=64, out_features=1, bias=True)
  )
)

CUDA available: False

bonjour
i965: Failed to submit batchbuffer: Invalid argument
i965: Failed to submit batchbuffer: Invalid argument
i965: Failed to submit batchbuffer: Invalid argument
bonjour
Traceback (most recent call last):
  File "/home/lcswillems/miniconda3/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/lcswillems/miniconda3/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/torch-rl/scripts/train.py", line 152, in <module>
    logs = algo.update_parameters()
  File "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/torch-rl/torch_rl/torch_rl/algos/ppo.py", line 32, in update_parameters
    exps, logs = self.collect_experiences()
  File "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/torch-rl/torch_rl/torch_rl/algos/base.py", line 136, in collect_experiences
    obs, reward, done, _ = self.env.step(action.cpu().numpy())
  File "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/torch-rl/torch_rl/torch_rl/utils/penv.py", line 50, in step
    results = zip(*[(obs, reward, done, info)] + [local.recv() for local in self.locals])
  File "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/torch-rl/torch_rl/torch_rl/utils/penv.py", line 50, in <listcomp>
    results = zip(*[(obs, reward, done, info)] + [local.recv() for local in self.locals])
  File "/home/lcswillems/miniconda3/lib/python3.6/multiprocessing/connection.py", line 250, in recv
    buf = self._recv_bytes()
  File "/home/lcswillems/miniconda3/lib/python3.6/multiprocessing/connection.py", line 407, in _recv_bytes
    buf = self._recv(4)
  File "/home/lcswillems/miniconda3/lib/python3.6/multiprocessing/connection.py", line 383, in _recv
    raise EOFError
EOFError

It seems there is a problem with multiprocessing and OpenGL, especially when the subprocesses try to communicate with the parent.

Great that you got the graphics working. I will try to come up with a cleaner fix for that.
For the second issue, thankfully, I already have a workaround. You have to set the fork method to 'forkserver':
https://github.com/maximecb/gym-miniworld/blob/master/pytorch-a2c-ppo-acktr/vec_env/subproc_vec_env.py#L2
https://github.com/maximecb/gym-miniworld/blob/master/pytorch-a2c-ppo-acktr/vec_env/subproc_vec_env.py#L39
This changes something in the way resources are shared between subprocesses I believe.

I now have this bug:
Traceback (most recent call last):
  File "/home/lcswillems/miniconda3/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/lcswillems/miniconda3/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/torch-rl/scripts/train.py", line 138, in <module>
    args.optim_eps, args.clip_eps, args.epochs, args.batch_size, preprocess_obss)
  File "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/torch-rl/torch_rl/torch_rl/algos/ppo.py", line 18, in __init__
    value_loss_coef, max_grad_norm, recurrence, preprocess_obss, reshape_reward)
  File "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/torch-rl/torch_rl/torch_rl/algos/base.py", line 49, in __init__
    self.env = ParallelEnv(envs)
  File "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/torch-rl/torch_rl/torch_rl/utils/penv.py", line 35, in __init__
    p.start()
  File "/home/lcswillems/miniconda3/lib/python3.6/multiprocessing/process.py", line 105, in start
    self._popen = self._Popen(self)
  File "/home/lcswillems/miniconda3/lib/python3.6/multiprocessing/context.py", line 223, in _Popen
    return _default_context.get_context().Process._Popen(process_obj)
  File "/home/lcswillems/miniconda3/lib/python3.6/multiprocessing/context.py", line 291, in _Popen
    return Popen(process_obj)
  File "/home/lcswillems/miniconda3/lib/python3.6/multiprocessing/popen_forkserver.py", line 35, in __init__
    super().__init__(process_obj)
  File "/home/lcswillems/miniconda3/lib/python3.6/multiprocessing/popen_fork.py", line 19, in __init__
    self._launch(process_obj)
  File "/home/lcswillems/miniconda3/lib/python3.6/multiprocessing/popen_forkserver.py", line 47, in _launch
    reduction.dump(process_obj, buf)
  File "/home/lcswillems/miniconda3/lib/python3.6/multiprocessing/reduction.py", line 60, in dump
    ForkingPickler(file, protocol).dump(obj)
ValueError: ctypes objects containing pointers cannot be pickled

This I'm not sure about. Are you trying to pickle the whole env or something?

@lcswillems I added a check to the frame buffer to automatically get the maximum number of samples supported. Does this allow you to run manual_control.py without modifications?

No, it doesn't work... Here is the error:
gym-miniworld$ ./manual_control.py --env-name MiniWorld-Hallway-v0
Registered env: MiniWorld-CollectHealth-v0
Registered env: MiniWorld-FourRooms-v0
Registered env: MiniWorld-Hallway-v0
Registered env: MiniWorld-Maze-v0
Registered env: MiniWorld-MazeS3-v0
Registered env: MiniWorld-OneRoom-v0
Registered env: MiniWorld-PutNext-v0
Registered env: MiniWorld-TMaze-v0
Registered env: MiniWorld-ThreeRooms-v0
Registered env: MiniWorld-WallGap-v0
Traceback (most recent call last):
  File "./manual_control.py", line 23, in <module>
    env = gym.make(args.env_name)
  File "/home/lcswillems/miniconda3/lib/python3.6/site-packages/gym/envs/registration.py", line 167, in make
    return registry.make(id)
  File "/home/lcswillems/miniconda3/lib/python3.6/site-packages/gym/envs/registration.py", line 119, in make
    env = spec.make()
  File "/home/lcswillems/miniconda3/lib/python3.6/site-packages/gym/envs/registration.py", line 86, in make
    env = cls(**self._kwargs)
  File "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/gym-miniworld/gym_miniworld/envs/hallway.py", line 19, in __init__
    **kwargs
  File "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/gym-miniworld/gym_miniworld/miniworld.py", line 517, in __init__
    self.obs_fb = FrameBuffer(obs_width, obs_height, 8)
  File "/mnt/Data/Documents/Education/2017 2018 - M1/Stage/Code/gym-miniworld/gym_miniworld/opengl.py", line 208, in __init__
    assert res == GL_FRAMEBUFFER_COMPLETE, FB_ERROR_ENUMS.get(res, res)
AssertionError: GL_FRAMEBUFFER_UNSUPPORTED

In the opengl.py file, you have ); at the end of some lines.

Yes!! This works now :)

Wonderful.

Great that you got the graphics working. I will try to come up with a cleaner fix for that.
For the second issue, thankfully, I already have a workaround. You have to set the fork method to 'forkserver':
https://github.com/maximecb/gym-miniworld/blob/master/pytorch-a2c-ppo-acktr/vec_env/subproc_vec_env.py#L2
https://github.com/maximecb/gym-miniworld/blob/master/pytorch-a2c-ppo-acktr/vec_env/subproc_vec_env.py#L39
This changes something in the way resources are shared between subprocesses I believe.

A problem with this modifications is that it doesn't make MiniGrid working anymore.


All food has same hunger value

It seems unreal that main food/farmer addon for TFC has this issue. Am I doing something wrong? Forge 1.20.1

I'd assume this mod is using the food's vanilla food value, not its TFC food value, so that's normal. TFC food value is data-driven and whatever mod you're using probably is checking the vanilla food value. This is the same for all Firmalife foods.
What mod is it?

closing based on lack of info


validate binding behaviour fails when controller isn't instanced yet.

Current behavior:
If a validation controller isn't instanced before the view attaches, the validate binding behaviour fails.
Expected/desired behavior:
I want it to reevaluate the binding if the controller context changes and not crash when it isn't set yet.

What is the motivation / use case for changing the behavior?
Our scenario works likes this:
https://gist.run/?id=a366ac61762992e3e4e227a67264cad6

We never create viewModels using the container, they are always created by the outer "routed" viewModel. The viewModel is also created when the data has finished loading. We don't want to load the required view data in activate because not loading the interface before the loading is bad UX. We want the user to get the view feedback instantly then show with spinners/disabled fields that things aren't ready yet.
However since the controller isn't there yet until the viewmodel is created the binding behaviour crashes.
I'm not sure how other people approach this, maybe there is a clean workaround already that I havn't found. I feel like this should be considered fixing since it worked in the previous versions of validation.
Cheers!

I could work around it by creating a custom attribute like the old version used.
Bind the controller and viewmodel into it, use a propertyobserver to observe the property changes then manually call controller.validate and send the result to a renderer.
If you hadn't used the binding to trigger the validation, the controller doesn't have an internal binding registered to work with and thus the results arent even send propertly to the render, cause the element sent to the renderer along with the result, is null.
`import { inject, bindable } from 'aurelia-framework';
import { BindingEngine } from 'aurelia-binding';
import { WindowAbstraction } from '../browser-abstractions/window-abstraction';
import { BootstrapFormRenderer } from './bootstrap-form-renderer';
@inject(Element, BindingEngine, WindowAbstraction, BootstrapFormRenderer)
export class ValidationControllerCustomAttribute {
_element = null;
_controllerLoaded = false;
_bindingEngine = null;
@bindable controller;
@bindable viewmodel;
constructor(element, bindingEngine, window) {
this._element = element;
this._bindingEngine = bindingEngine;
this._window = window;
this._renderer = new BootstrapFormRenderer();
}
controllerChanged(controller) {
if (controller && this.viewmodel) {
this._controllerLoaded = true;
}
}
viewmodelChanged(viewmodel) {
if (viewmodel) {
this._viewmodelLoaded = true;
}
}
async bind(binding, source, rulesOrController, rules) {
if (!this.controller && !this.viewmodel) {
this._window.queue(() => this.bind(), 10);
} else {
let bindAttribute = this._element.attributes['value.bind'];
let bindValue = bindAttribute.value;
let split = bindValue.split('.');
let propertyName = split[split.length - 1];
let observer = this._bindingEngine.propertyObserver(this.viewmodel, propertyName).subscribe(async (value) => {
let result = await this.controller.validate({ object: this.viewmodel, propertyName: propertyName });
this._renderer.clearAndRender(this._element, result.results[0]);
});
}
}`
<input class="form-control" id="billing_street" placeholder="Gatuaddress" type="text" value.bind="viewModel.header.billingStreet" validation-controller="controller.bind:viewModel.header.validationController; viewmodel.bind:viewModel.header"/>
This feels very ugly but at least it works. Although we had to bypass alot of the nice features the framewould normally handles.

The validation binding behavior requires a controller. Use the if binding controller to postpone data-binding your form until the view model (and controller) are available.
Updated version of your gist:
https://gist.run/?id=611ca9293371aed1c587a2511c3ef13c
Diff:
https://gist.github.com/jdanyow/611ca9293371aed1c587a2511c3ef13c/revisions

I know that is à possible workaround but I still think its a very bad restriction in the framwork and should be thought of and fixed eventually.

I disagree. I think it's bad to have the form visible and accepting user input before the view model it will be bound to has been instantiated.


It reloads when you switch fragments

I use navigation to jump the fragment, and when I go back to the previous fragment it reloads the init call.
This is probably because of navigation. I would like to ask if you have any good solutions?

@RDSunhy init in your ViewModel? That shouldn't happen. Please attach a sample project that reproduces this.

I found the problem.
EpoxyRecyclerView externally added NestedScrollView, the list returns to the top whenever I toggle fragments.BottomNavigationView is also used in my project.I think this may not be MvRx's problem.
I refer to your product (Airbnb app), I think everything is great!
I would like to ask you how do you handle switching between fragments?Can you give me some ideas?I'd like to refer to your design ideas.

@RDSunhy MvRx has no opinions on navigation. You can do whatever you would like.
I have seem navigation sealed classes that you can subscribe to with uniqueOnly() which seems to work well.


Create simple copy job for design files

Design workflow is too fast for "mvn package" therefore a job that simply copies all necessary css/html/js files to tomee folder. Idea is to replace those files in exploded war to make visual changes appear immediately.

Build an ant task that does the copy job.


Create Cost function patch 1.py

Hey there I have written a cost function kindly check it and merge it to your repo

Yeahhh I have seen your code is correct . I approve you


Confirm Ruby 3 support

As Ruby 2.7 EOL is supposed to be end of March 2023, would you be able to confirm Ruby 3 compatibility? Thanks.

Ruby 3.x tests have passed.
see https://github.com/winebarrel/faraday_middleware-aws-sigv4/blob/09367bd5e26ee6a6a9af24c7c08b5cf7be22e799/.github/workflows/test.yml#L15-L17


How do channels work?

I downloaded surge and saw i need to upload files on channels.
All channels i add/create will be automatically visible to other users?? Or they need to add the channel manually?
If they need to add channels manually then i suggest to create a public channel.. the #Surge Official does not work (i cannot upload any files in it)

closing because i saw the other closed issue that replies to this, anyways i recommend to add a way to make channels public and share them......


Add E2E tests

I want to add E2E tests for:

[ ] Package Report is visible in npmjs.com
[ ] Package Report is visible in PyPI.org
[ ] Test the Package Report (tooltip) itself by validating there are advisories loaded into the list.
[ ] Test the popup visibility
[ ] Test the popup changes that affect the overlay on the page

Can you please assign this to me?

Hi @baruchiro, I think that case #4 (Test the popup visibility) cannot be tested using Playwright.
According to Playwright's documentation about testing chrome extensions and this issue, accessing the Popup is possible only using the extension's URL (chrome-extension://${extensionId}/popup/index.html).

@rzarviv It's OK, let's test it with the URL, why not?


Interrupting benchmark run persists partial cache file

I stated a benchdiff run, and then realized I had gotten it wrong and stopped it with ^C.
When I reran it, it said "skipping benchmark for ref "HEAD^" because output file exists" although the file in the cache was just a couple lines from the first benchmark.
Instead, the output should go to a temporary file and only get moved to the cache upon success.

Relatedly, interrupting a run also leaves behind a git worktree. It would be nice if the signal was caught and a cleanup step run anyway.

Thanks. I haven't run across this before, probably because I typically use --force-base.
The next few weeks are busy for me, so I don't think I will have time to get to this for a while. If you can identify a fix, I can make time for a PR review. Otherwise it may be a while before this is fixed.


Document Type Support

Adds preliminary support for a documentType field for crossref & plos harvesters

Coverage increased (+0.004%) to 93.452% when pulling 536cd97b4c62507e9e19b3bc0d00c063d6d7ce2b on wearpants:feature/document-type into<PHONE_NUMBER>1f52e3c955d0b190c5628dd221389a on CenterForOpenScience:develop.

Pull request with initial support for a documentType field for crossref and plos. See SHARE-294 in Jira. /cc @chrisseto  It supports the following values: "article", "abstract", "dataset", "book", "book-chapter", "dissertation", "correction", "preprint", "source-code", "clinical-trial", "reference-entry", "monograph"
To update production, we'll need to renormalize after merging: invoke migrate renormalize -s 'crossref,plos' --no-dry. I estimate this will take about 23 machine hours - may be able to get some speedup by using more celery tasks, but not 100% sure where the bottleneck is. Be sure to merge branch on all harvester machines before running this migration.
@alexschiller if you'd like to start adding frontend support, checkout the feature/document-type branch from my fork: https://github.com/wearpants/scrapi/ ; You can either renormalize an existing database or re-run the crossref & plos harvesters to generate new data. The OSF web server should pass through documentType field in share_search API results.

Coverage increased (+0.004%) to 93.452% when pulling f0941bd28685b105c7455fda25600cc9351011aa on wearpants:feature/document-type into<PHONE_NUMBER>1f52e3c955d0b190c5628dd221389a on CenterForOpenScience:develop.


ZIO 2  RC3

@toxicafunk should i update it to RC4 ?

@toxicafunk should i update it to RC4 ?

Let's wait till I can successfully merge RC3


Fix adapter function always needs a bind

Update adapter to arrow function
Remove CallAdapter from public api
What

Why

How Tested

Process & policy checklist

[ ] I have updated the project documentation to reflect my changes if necessary.
[ ] I have read the CONTRIBUTING documentation.

Is this a breaking change?

[ ] This change causes current functionality to break.

Can we link the bug/issue that this change is related to in order to build some context?

@PorterNan  can we close this since we did the binding as part of prathmesh's change?

Will open another one to remove some apis from our public api files


optional rubberband teleport

Someone who likes to run would like it if minions automatically teleported with them to keep up.

I think with weapons of command this is no longer needed


Changing environment is not propagated to machines

Really a missing feature, but I was kind of surprised.

Fixed


Adjust spacing of intro screen so that CTA is visible on iPhone SE

Main CTA for iPhone SE is below the fold, and could be missed easily. Let's compress about the spacing for everyone so this doesn't happen.

fixed, avail in next build

Looks good to me. Thank you


cf help should behave like cf help -a when STDOUT is being piped

Command
cf help | grep bindings

What occurred, incl. error and/or stack trace
Nothing was printed on my terminal

What you expected to occur
Something (in this case, the equivalent of cf help -a | grep bindings) was printed on my terminal. Because I am piping the output, I most likely want the full -a output, so this should be detected and enabled.

CLI Version
6.22.2+a95e24c-2016-10-27

Platform & Shell Details
MacOS 10.12.1 iTerm 2 3.0.12

Hi @wendorf
Interesting suggestion!
I've discussed this with our designers. I feel the value of assuming that the user wants all when piping (the "80%") does not outway the confusion when they don't (e.g. when doing a cf h | more to reduce the amount of output or cf h > common-help.txt for whatever reason.
I noticed git --help | more (git is one of the commands we used for reference when redesigning the help as it addressed the issue we had with long help text and is a command most CF users are familiar with) doesn't do this either. Have you seen this with any other common commands?
I think what many existing users of the cf CLI, including myself, are experiencing is that cf h | grep ... is in our fingers and it takes a few times to get used to adding the -a. That said, the feedback I get is that it doesn't take that long (YMMV ;)) to get used to.
Regards,
Dies Koper
CF CLI PM

Closing for the reasons above: it would be unexpected to get different output when piping to e.g. more.
Thanks again for the interesting suggestion.


Why own implementation jwt?

Why not use IdentityServer or OpenIdDict? Which are most complete and tested frameworks
You use ROPC
I recently read that ROPC may have several security holes, this link addresses some of them:
https://tools.ietf.org/html/rfc6749#section-10.7
brute force, save password in client log, others ...
What is your opinion about this?

We didn't use Identity Server or other similar solution, simply, because we wanted to show the end users how the JWT works under the hood and that it could be easily implemented.
Our code uses well-tested system libraries, so, there's no real threat or bugs AFAIK. The password is being hashed using one way PBKDF2 etc. - so basically, it's almost impossible to do a brute force if your password is strong enough. Our code doesn't save a password in any logs.
IdentityServer is a great solution, and it might be a part of the next release of ASP.NET Core, but, we didn't want the programmers who explore the code, to get familiar with another quite sophisticated library.
At some point in the future, there's a chance, that we will create a new service using one of the solutions that you suggested.

@spetz thanks
great solution


Consistency with descriptions

This PR provides slightly better consistency in the check-box descriptions.
BEFORE:

AFTER:

We might also want to reduce the size of the sink/drive pin labels by changing sink: 10mA, drive: 5mA into something like -10mA / +5mA or even split them into two separate labels to reduce the overall size a bit.

Great work - much more consistent now!

We might also want to reduce the size of the sink/drive pin labels by changing sink: 10mA, drive: 5mA into something like -10mA / +5mA or even split them into two separate labels to reduce the overall size a bit.

Yeah, true. I also thought of using arrows to indicate "sink" and "drive", but couldn't come up with something I liked. Using just -10mA / +5mA seems like a good idea :+1:


Restructure module 1 to be a function

Remove the namespace from Module 1
Make Module 1 usable in main.py

Addressed in PR #42

I have run it and it seems like nothing got printed on terminal. Im not sure either so dont take my word for it.

So I suggest add print function to the code. And perhaps #Example of Usage and also logger. And need to add exception and error handling to the code as well. There will be marks for each of this I think.


Unpack archive files for hdfs

What this PR does / why we need it:
Thanks for the PR @I321506. This is rebase of the PR #2812
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #2813
Type of changes
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Feature/Issue validation/testing:
Please describe the tests that you ran to verify your changes and relevant result summary. Provide instructions so it can be reproduced.
Please also list any relevant details for your test configuration.

[ ] Test A

[ ] Test B

Logs

Special notes for your reviewer:

Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

Checklist:

[ ] Have you added unit/e2e tests that prove your fix is effective or that this feature works?
[ ] Has code been commented, particularly in hard-to-understand areas?
[ ] Have you made corresponding changes to the documentation?

Release note:

NONE

@sivanantha321 Have you verified this? not sure if we have any test with hdfs

not sure if we have any test with hdfs

there aren't any, unfortunately 😥

@sivanantha321 Have you verified this? not sure if we have any test with hdfs

Tested it in my local machine. Working as expected :)

/lgtm
/approve


ECC-98 Subscribe for specific service when CDS Enrolment exists - prepared for dev discussion

Closing as discussed during the meeting


merge package template from Kronos-Tools/npm-package-template

Updated standard to latest version

Codecov Report

Merging #79 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #79   +/-   ##
=======================================
  Coverage   83.33%   83.33%
=======================================
  Files           1        1
  Lines          12       12
=======================================
  Hits           10       10
  Misses          2        2

Continue to review full report at Codecov.

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


fix: MD012/no-multiple-blanks

Multiple consecutive blank lines

@nschonni : Thanks for your contribution! The author(s) have been notified to review your proposed change. @evanwindom

Verified the updates; merging.


fix failing seed reporting

Failing seed reporting seems to be incorrect when scalaCheckInitialSeed is not overridden. In that case def seed would use def scalaCheckInitialSeed: String = Seed.random().toBase64 and be different every time. Hence the 2 seeds seen here are actually not the ones causing test failure.
https://travis-ci.org/github/spotify/magnolify/jobs/708925430#L369
Failing seed: z9omj4mAsT7BcJQoh95CcofqurdkO_jIAGEWFPx7xZA=
You can reproduce this failure by adding the following override to your suite:
  override val scalaCheckInitialSeed = "5E72c0hWZ5ioOvDIj2udNT9KuVs1mGz8EBcV-3zyKgH="

Not sure how to test though, probably need some variation of FrameworkTest, extract the seed from error message & verify.

Actually DO NOT MERGE. Let me verify if this actually works as expected first.

I am happy to merge without a test case (although it would be nice to have a test 😄 )

Think this actually broke another case. It's hard to verify since the test is non-deterministic :sob:. At least let me verify some basic scenarios.


This creates a KafkaBinding.

/hold
I don't plan to land this for 0.14, but want to start socializing this for 0.15 and beyond.
For (much) broader context, see here.
This PR creates a binding to pair with KafkaSource in the spirit of the above document.  This is also (very) loosely based on prior work in github.com/mattmoor/bindings (I didn't do Kafka).
Generally the idea is that a user could configure:
apiVersion: bindings.knative.dev/v1alpha1
kind: KafkaBinding
metadata: ...
spec:
  subject:
    apiVersion: serving.knative.dev/v1
    kind: Service
    selector:
      matchLabels:
        kafka: "true"  # or something

  # This matches KafkaSource
  bootstrapServers: foo,bar
  net:
    tls:
      enable: true
      cert:
        secretKeyRef:
          name: kafka-tls-secret
          key: tls.crt
      key:
        secretKeyRef:
          name: kafka-tls-secret
          key: tls.key
      caCert:
        secretKeyRef:
          name: kafka-tls-secret
          key: ca.crt

Then in my Service, I would simply need the following to get an authenticated client:
import "knative.dev/eventing-contrib/kafka"

// Get a client for reading.
client, err := kafka.NewConsumer(ctx)
if err != nil { ... }

// Get a client for writing.
client, err := kafka.NewConsumer(ctx)
if err != nil { ... }

🎁 Add new feature

Release Note
Introduce GitHubBinding

Docs
Needs docs, but see my note about targeting 0.15.

Note that this parallels: https://github.com/knative/eventing-contrib/pull/1113

/assign
Hi @mattmoor, thanks so much for this example implementation, it really helps to grasp the idea.
I like the idea of providing a simple configuration for golang/sarama duo, however my main concern here is "the persona" who should use this KafkaBinding:

You provide env reader only for golang/sarama, but what about other libraries out there? User should rewrite an "env" parser for the library of his choice or are we supposed to provide it to him?
Every library it's potentially configurable in different ways, abstracting over it it's not so easy: just look at librdkafka difference with sarama. The configuration we have in KafkaSource makes sense for sarama, but perhaps it doesn't for other libraries or it needs to be changed to reflect the other library capabilities.
The average Kafka developer uses a JVM language (Java/Scala/Kotlin usually) and interacts with the official Kafka client. You could argue that we still inject the configuration through env variables, but the JVM Kafka client already provides a simple configuration mechanism through application.properties file. Users usually mounts this file from a configmap straight into the classpath. My point is that I doubt that who uses the official JVM client will be interested in such env injection.

And another thing, in the example you use a ksvc, which doesn't make sense for an application that consumes/produces kafka messages, because it can't be scaled with serving.

Related to: https://docs.google.com/document/d/1PLYm8amLRKmKK5FAo_34ZOKwTbYU9ooMjrjwkiPc7qA/edit
@aslom

I agree with @slinkydeveloper for majority of Kafka developers they expect application.properties or similar as discussed in https://github.com/knative/eventing-contrib/issues/655 (which should be extended to cover Kafka binding)

for majority of Kafka developers they expect application.properties or similar as discussed in #655

My goal here was merely to factor the logic we have to start the conversation.  I'm absolutely not a kafka expert, so I will happily defer to your judgement on the proper idioms here.  If there is an idiomatic way of exposing this same information, then we should absolutely adopt that mechanism rather than inventing something new.
Honestly, my ideal world is one where the way we bind the information works with unmodified clients (dare to dream), but that only world in cases that have plumbed through hooks (like Google Application Default Credentials, or DOCKER_CONFIG, or ...).

You provide env reader only for golang/sarama, but what about other libraries out there

That's mostly because that's what we use now.  I could see us providing alternate implementations for other Go libraries (e.g. the one needing CGO?), but I think there's value in having a pure-Go version.  The canonical example of needing multiple implementations of this interface is multiple languages.
Perhaps I could move this to a kafka/sarama directory?

I guess the question I have here is how much we want for this change vs. for follow-up?  I'd rather keep this change somewhat mechanical, so if someone with more expertise could change some of the idioms we use to be better aligned either before (internally) or after this change that'd be great.
A couple other thing that I'd be happy to tackle, but wanted to wait for some discussion:

Making the Source use this internally (helps reduce duplication),
E2E tests (we have them for source/channel, which I so so so appreciate 😍)

If there is an idiomatic way of exposing this same information, then we should absolutely adopt that mechanism rather than inventing something new.

My worry is that I'm not sure such mechanism exists for kafka, unless you want to allow configuration of basic things (kafka cluster to connect to, topic to send messages). For all the other configurations, it's really client specific. This includes auth configuration, retry mechanisms, definition of things like what partitioner to use, what consumer group partition assignor to use, all of these are specific to the clients. And it's really common to configure such things when you use kafka.
Unfortunately, Kafka is not so easy as HTTP where the configuration to "bind" two services is usually as simple as the target URL.

@slinkydeveloper I think in that case it's harmless to have our own schema (or adopt the "most used", for some subjective definition) and surface bindings for clients that pull that information in appropriately.

I've updated this PR so that the event that is generated to trigger the source is done via a Job bound through the Binding in a new test image.

/unhold

@mattmoor  the release notes are wrong, mention GithubBinding

/hold
doesn't this add some complexity to the source? especially since kafka is different than http.. :thinking:

doesn't this add some complexity to the source? especially since kafka is different than http

@matzew I don't follow the context for this comment, I haven't changed the source really at all (some superficial stuff at the Go-level, but nothing visible).

@mattmoor did i understood correctly that this PR makes KafkaSource dependant on KafkaBinding?

@slinkydeveloper It does not, but that is a direction we could take things if we wanted.

From my comment above:

A couple other thing that I'd be happy to tackle, but wanted to wait for some discussion:

Making the Source use this internally (helps reduce duplication),
E2E tests (we have them for source/channel, which I so so so appreciate 😍)

I have done 2. now, but not 1..  This change is big enough.

@mattmoor ah i see, in that case i think it's fine since it just moves some client bootstrap stuff in another module.

doesn't this add some complexity to the source? especially since kafka is different than http.. 🤔

It does not. It removes complexity.
/lgtm
/approve

I have rebased this now that the GithubBinding has landed.

CamelSource :-/
/retest

/unhold

/lgtm


Set-CsOnlineLisLocation not working

We need to amend the numbers for our ELIN field but the below commands are not working at all.
We have also tried the phone number with " "
Can someone help please we have already validated the address etc.
ValidationStatus         : Validated
NumberOfVoiceUsers       : 0
NumberOfTelephoneNumbers : 0
Command used :
Set-CsOnlineLisLocation -CivicAddressId 3e8c8fff-4a81-4bc0-b7ba-b14f72eab43c -ELIN +443000xxxxx
Error:
WARNING: Correlation id for the request is cdf0c5ad-db4b-4a66-xxxxx
WARNING: BVD correlation id for the request is cdf0c5ad-db4b-4a66-xxxxx
Unable to update record
+ CategoryInfo          : NotSpecified: (System.Object[]:Object[]) [Set-CsOnlineLisLocation], BvdCmdletException
+ FullyQualifiedErrorId : Unspecified,Microsoft.Rtc.Management.Hosted.Lis.SetCsOnlineLisLocationCmdlet
+ PSComputerName        : api.interfaces.records.teams.microsoft.com
I know Civic address is for not validated but still tried it.
Command Used:
Set-CsOnlineLisCivicAddress -CivicAddressId 3e8c8fff-4a81-4bc0-b7ba-xxxxxxx -ELIN +443000xxxxx
Error:
Unable to update a validated Civic Address 3e8c8fff-4a81-4bc0-b7ba-xxxxxxx
+ CategoryInfo          : NotSpecified: (System.Object[]:Object[]) [Set-CsOnlineLisCivicAddress], BvdCmdletException
+ FullyQualifiedErrorId : Unspecified,Microsoft.Rtc.Management.Hosted.Lis.SetCsOnlineLisCivicAddressCmdlet
+ PSComputerName        : api.interfaces.records.teams.microsoft.com
Thanks in advance .

Hello @SGurjitsk how are you? hope you are doing good 👍
Is there any specific article that you see needs correction? as here we are limited to documentation fixes and improvements.
Maybe the best in your scenario would be to open a support ticket directly from your tenant.
Thank you,

@get-itips Thank you very much for the contribution and sharing this explanation. @SGurjitsk Hope this comment is helpful for you. Considering the nature of the issue, as advised, please open a service ticket in your tenant and follow with them for the resolution. We proceed here to close it.
We will be very happy if you can share the outcome or resolution with us if you see documentation update is required. We will certainly update this documentation with that valuable information. Thanks again, for taking out some time to open the issue. Appreciate and encourage you to do the same in future also.


Using NAME to replace ID in help string

ref  #9511

@erictune Could you please review this PR?

@feihujiang: You need to run hack/run-gendocs.sh on your PR at the very least.

@k8s-bot: ok to test

LGTM

shippable says: /root/workspace/src/github.com/GoogleCloudPlatform/kubernetes/docs/ is out of date. Please run hack/run-gendocs.sh
You need to install our hooks to catch this at presubmit.
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/devel/development.md#hooks

@thockin @zmerlynn @erictune  I have run hack/run-gendocs.sh. Could you please review this PR again?

LGTM

LGTM
On Thu, Jul 2, 2015 at 11:53 AM, Brian Grant<EMAIL_ADDRESS>wrote:

LGTM
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/10598#issuecomment-118125604
.


MQTTnet won' work with dot net framework 4.8

Hi,
Just installed MQTTnet <IP_ADDRESS> via Nuget but it wouldn't recognise the referenced dll. Environment VS2019. Project target AnyCPU, dot net framework 4.8. While running the code where it references the component, it stops and shows error in debug:
System.IO.FileNotFoundException: 'Could not load file or assembly 'MQTTnet, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b69712f52770c0a7'. The system cannot find the file specified.'
Does it not support framework 4.8? I do notice that v4.6.1 and v5.0 are mentioned.
Many thanks
Jim

In my opinion VS should select netstandard1.3 in this case!?
https://nugettoolsdev.azurewebsites.net/3.5.0-beta2-1484/get-nearest-framework?project=net48&package=netstandard1.3
netstandard2.0

Thanks Christian.  My project was created long time ago (about 10 years) and updated to the .net framework 4.8 last year.

I assume, that this issue is now solved. If not, just re-open the issue, please.


Php 8.1 Compability

Package phpro/mage2-module-translations has requirements incompatible with your PHP version, PHP extensions and Composer version:
- phpro/mage2-module-translations 0.1.1 requires php ^7.1 which does not match your installed version 8.1.2.

Hi @gokhanakdag, thanks for using our module. You should at least upgrade to version 1.2.0 which has compatibility for PHP 7.4 and 8.1.

Please try to install it via composer. It doenst work.

hi @gokhanakdag , but I can see you are using an old version (0.1.1) of the module. Probably you need to update the version in your composer.json file first.

Please try installing it vith a fresh magento 2 via composer command : composer require phpro/mage2-module-translations.
And then see what happens.


Carousel fixes & improvements

Fix a carousel bug when carousel arrow buttons didn't work in certain cases
Adjust the carousel so that arrow buttons slide by one slide at a time rather than two on smaller viewports
Fix a broken link in docs
Update Dialog demo contents so it’s not confused with an AlertDialog

Closes #282, #283, #284

Thanks for the improvements for #282 💛  looking great!


Pass output of function to text / code box?

Is this possible with easygui. I've been trying to find a way, but without much success yet.
All I want to do is keep the output of my py code inside easygui, without displaying results in the terminal from which the py script was invoked.
Thanks.

Hi @fiddybux , I don't quite understand your problem.
You have a text box or a code box. You (the user) enters some value into that box. What do you want to do with the return value (the user entered value)? If you store it as a variable then you can use it within Python, or pass it through to a new box as desired. You don't have to print it to console, or lose it.
Could you provide a code segment, or additional description of the scenario, to help me understand it please?

Away from a computer at the moment, but I suspect the problem is that you are trying to pass the codebox a tulle for the text argument where it expects a string.
So from this: easygui.codebox(msg_b, title_b, (x, ("\n"), y))
I think that the problem is that the third arg (x, ("\n"), y) should be a string.
Try replacing it with: easygui.codebox( msg_b, title_b, str(x) + "\n" + str(y) )
And see if that works. If not I can check this later when I get my hands back on my laptop.
On Tue, Sep 26, 2017 at 14:39, fiddybux<EMAIL_ADDRESS>wrote:
Hi,
Thanks for the prompt reply.
Working in Python 3.4.2, I'm trying to count 0 and 1 characters in a short
test file that looks like this, and present it in easygui:
0
00
1111
As requested, here is a code snippet. At the moment, I'm getting the error:
Exception when trying to convert <class 'tuple'> to text in self.textArea
The code:
import easygui
msg_a = ("Print file contents first (y/n)?")
title_a = "Please Confirm"
msg_b = ("Character count results...")
title_b = "Result"
input_file = open('', 'r')
file_content = input_file.read()
input_file.close()
x = file_content.count('0')
y = file_content.count('1')
if easygui.ynbox(msg_a, title_a):
pass
easygui.codebox('', '', (file_content, ("\n"), x, ("\n"), y))
else:
easygui.codebox(msg_b, title_b, (x, ("\n"), y))
If I run the same code but without the easygui elements, with added print
lines for x and y, it works fine.
For example:
input_file = open('', 'r')
file_content = input_file.read()
input_file.close()
x = file_content.count('0')
y = file_content.count('1')
print("Print x:", x)
print("Print y:", y)
Here, I get the expected result of 3 zero's and 4 one's, as per my test
file, but naturally only within the python interpreter.
I can pass simple strings into easygui, as such ('hammer' and 'time'):
import easygui
msg_a = ("Print file contents first (y/n)?")
title_a = "Please Confirm"
msg_b = ("Just print hammer time...")
title_b = "Result"
input_file = open('/home/russell/Dropbox/python/coding'
'/01vshort.txt', 'r')
file_content = input_file.read()
input_file.close()
x = 'hammer'
y = 'time'
if easygui.ynbox(msg_a, title_a):
pass
easygui.codebox('', '', (file_content, ("\n"), x, ("\n"), y))
else:
easygui.codebox(msg_b, title_b, (x, ("\n"), y))
I've put about 6 hours into this today. Where am I going wrong?
Thanks.
On 25 September 2017 at 22:20, zadacka<EMAIL_ADDRESS>wrote:

Hi @fiddybux https://github.com/fiddybux , I don't quite understand
your problem.
You have a text box or a code box. You (the user) enters some value into
that box. What do you want to do with the return value (the user entered
value)? If you store it as a variable then you can use it within Python, or
pass it through to a new box as desired. You don't have to print it to
console, or lose it.
Could you provide a code segment, or additional description of the
scenario, to help me understand it please?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/robertlugg/easygui/issues/130#issuecomment-332016781,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AX8VkTwWM5TKhXLxy4Cwuc-AtxX81C6Jks5smBkTgaJpZM4Pipbm
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub [https://github.com/robertlugg/easygui/issues/130#issuecomment-332184954] , or mute the thread [https://github.com/notifications/unsubscribe-auth/ADV8oWNRHciWgMIXh1D53M0iVYPA-Tcuks5smPCEgaJpZM4Pipbm] .

Yep, I tried passing str into the x and y, but that then fails too. I'm
also away right now, so can check, but I think from human memory it was a
different error relating to type.
On 26 Sep 2017 2:50 pm, "zadacka"<EMAIL_ADDRESS>wrote:

Away from a computer at the moment, but I suspect the problem is that you
are trying to pass the codebox a tulle for the text argument where it
expects a string.
So from this: easygui.codebox(msg_b, title_b, (x, ("\n"), y))
I think that the problem is that the third arg (x, ("\n"), y) should be a
string.
Try replacing it with: easygui.codebox( msg_b, title_b, str(x) + "\n" +
str(y) )
And see if that works. If not I can check this later when I get my hands
back on my laptop.
On Tue, Sep 26, 2017 at 14:39, fiddybux<EMAIL_ADDRESS>wrote:
Hi,
Thanks for the prompt reply.
Working in Python 3.4.2, I'm trying to count 0 and 1 characters in a short
test file that looks like this, and present it in easygui:
0
00
1111
As requested, here is a code snippet. At the moment, I'm getting the error:
Exception when trying to convert <class 'tuple'> to text in self.textArea
The code:
import easygui
msg_a = ("Print file contents first (y/n)?")
title_a = "Please Confirm"
msg_b = ("Character count results...")
title_b = "Result"
input_file = open('', 'r')
file_content = input_file.read()
input_file.close()
x = file_content.count('0')
y = file_content.count('1')
if easygui.ynbox(msg_a, title_a):
pass
easygui.codebox('', '', (file_content, ("\n"), x, ("\n"), y))
else:
easygui.codebox(msg_b, title_b, (x, ("\n"), y))
If I run the same code but without the easygui elements, with added print
lines for x and y, it works fine.
For example:
input_file = open('', 'r')
file_content = input_file.read()
input_file.close()
x = file_content.count('0')
y = file_content.count('1')
print("Print x:", x)
print("Print y:", y)
Here, I get the expected result of 3 zero's and 4 one's, as per my test
file, but naturally only within the python interpreter.
I can pass simple strings into easygui, as such ('hammer' and 'time'):
import easygui
msg_a = ("Print file contents first (y/n)?")
title_a = "Please Confirm"
msg_b = ("Just print hammer time...")
title_b = "Result"
input_file = open('/home/russell/Dropbox/python/coding'
'/01vshort.txt', 'r')
file_content = input_file.read()
input_file.close()
x = 'hammer'
y = 'time'
if easygui.ynbox(msg_a, title_a):
pass
easygui.codebox('', '', (file_content, ("\n"), x, ("\n"), y))
else:
easygui.codebox(msg_b, title_b, (x, ("\n"), y))
I've put about 6 hours into this today. Where am I going wrong?
Thanks.
On 25 September 2017 at 22:20, zadacka<EMAIL_ADDRESS>wrote:

Hi @fiddybux https://github.com/fiddybux , I don't quite understand
your problem.
You have a text box or a code box. You (the user) enters some value into
that box. What do you want to do with the return value (the user entered
value)? If you store it as a variable then you can use it within Python,
or
pass it through to a new box as desired. You don't have to print it to
console, or lose it.
Could you provide a code segment, or additional description of the
scenario, to help me understand it please?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/robertlugg/easygui/issues/130#issuecomment-332016781
,
or mute the thread
<https://github.com/notifications/unsubscribe-
auth/AX8VkTwWM5TKhXLxy4Cwuc-AtxX81C6Jks5smBkTgaJpZM4Pipbm>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub [https://github.com/
robertlugg/easygui/issues/130#issuecomment-332184954] , or mute the
thread [https://github.com/notifications/unsubscribe-auth/
ADV8oWNRHciWgMIXh1D53M0iVYPA-Tcuks5smPCEgaJpZM4Pipbm] .
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/robertlugg/easygui/issues/130#issuecomment-332204284,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AX8Vke9TEC3xjWyVwcK2eyO_wOAwdo_Hks5smQEHgaJpZM4Pipbm
.

Actually, you're right!
I thought I'd tried every possible iteration to get this to work. Turns out
I stipulated str in my code everywhere except within the easygui lines.
Thank you! Learned a lot today.
I've only been learning python for 6 weeks.
Now I can get on and implement easygui more widely in my coding practice.
Thanks again.
On 26 September 2017 at 14:50, zadacka<EMAIL_ADDRESS>wrote:

Away from a computer at the moment, but I suspect the problem is that you
are trying to pass the codebox a tulle for the text argument where it
expects a string.
So from this: easygui.codebox(msg_b, title_b, (x, ("\n"), y))
I think that the problem is that the third arg (x, ("\n"), y) should be a
string.
Try replacing it with: easygui.codebox( msg_b, title_b, str(x) + "\n" +
str(y) )
And see if that works. If not I can check this later when I get my hands
back on my laptop.
On Tue, Sep 26, 2017 at 14:39, fiddybux<EMAIL_ADDRESS>wrote:
Hi,
Thanks for the prompt reply.
Working in Python 3.4.2, I'm trying to count 0 and 1 characters in a short
test file that looks like this, and present it in easygui:
0
00
1111
As requested, here is a code snippet. At the moment, I'm getting the error:
Exception when trying to convert <class 'tuple'> to text in self.textArea
The code:
import easygui
msg_a = ("Print file contents first (y/n)?")
title_a = "Please Confirm"
msg_b = ("Character count results...")
title_b = "Result"
input_file = open('', 'r')
file_content = input_file.read()
input_file.close()
x = file_content.count('0')
y = file_content.count('1')
if easygui.ynbox(msg_a, title_a):
pass
easygui.codebox('', '', (file_content, ("\n"), x, ("\n"), y))
else:
easygui.codebox(msg_b, title_b, (x, ("\n"), y))
If I run the same code but without the easygui elements, with added print
lines for x and y, it works fine.
For example:
input_file = open('', 'r')
file_content = input_file.read()
input_file.close()
x = file_content.count('0')
y = file_content.count('1')
print("Print x:", x)
print("Print y:", y)
Here, I get the expected result of 3 zero's and 4 one's, as per my test
file, but naturally only within the python interpreter.
I can pass simple strings into easygui, as such ('hammer' and 'time'):
import easygui
msg_a = ("Print file contents first (y/n)?")
title_a = "Please Confirm"
msg_b = ("Just print hammer time...")
title_b = "Result"
input_file = open('/home/russell/Dropbox/python/coding'
'/01vshort.txt', 'r')
file_content = input_file.read()
input_file.close()
x = 'hammer'
y = 'time'
if easygui.ynbox(msg_a, title_a):
pass
easygui.codebox('', '', (file_content, ("\n"), x, ("\n"), y))
else:
easygui.codebox(msg_b, title_b, (x, ("\n"), y))
I've put about 6 hours into this today. Where am I going wrong?
Thanks.
On 25 September 2017 at 22:20, zadacka<EMAIL_ADDRESS>wrote:

Hi @fiddybux https://github.com/fiddybux , I don't quite understand
your problem.
You have a text box or a code box. You (the user) enters some value into
that box. What do you want to do with the return value (the user entered
value)? If you store it as a variable then you can use it within Python,
or
pass it through to a new box as desired. You don't have to print it to
console, or lose it.
Could you provide a code segment, or additional description of the
scenario, to help me understand it please?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/robertlugg/easygui/issues/130#issuecomment-332016781
,
or mute the thread
<https://github.com/notifications/unsubscribe-
auth/AX8VkTwWM5TKhXLxy4Cwuc-AtxX81C6Jks5smBkTgaJpZM4Pipbm>
.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub [https://github.com/
robertlugg/easygui/issues/130#issuecomment-332184954] , or mute the
thread [https://github.com/notifications/unsubscribe-auth/
ADV8oWNRHciWgMIXh1D53M0iVYPA-Tcuks5smPCEgaJpZM4Pipbm] .
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/robertlugg/easygui/issues/130#issuecomment-332204284,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AX8Vke9TEC3xjWyVwcK2eyO_wOAwdo_Hks5smQEHgaJpZM4Pipbm
.

No problem. I think that the issue was that: (x, ("\n"), y) is a tuple whereas str(x) + "\n" + str(y) is a string. A nicer way to do this might be to format your string with .format() like: '{number_of_zeros}\n{number_of_ones}'.format(number_of_zeros=x, number_of_ones=y).
In any case,  happy to help and hope that EasyGUI continues to be useful for you :)


Removed default values for several properties

Removed the default values from properties that would result in possibly unwanted side effects when provisioning a template if those properties where not specified. If the values on existing sites was different than the default values unexpected changes to the site would happen.
This PR needs update to the provisioning engine that I'm working on.
This PR starts the work on fixing issue #2413 in PnP-Sites-Core

PR added for changes in the provisioning engine PR #2500

Hi @jensotto,
As I wrote in the other https://github.com/SharePoint/PnP-Sites-Core/pull/2500 PR, thanks for your work. We will merge the proposed changes in the new schema, as soon as it will come out, and right after we will update the provisioning engine accordingly. Thanks.