Barretenberg failing to publish

Problem
When attempting to publish barretenberg, we get:
https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609
Copying and pasting the log incase it expires:
CC="clang"
[10](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:11)
  CMAKE_EXPORT_COMPILE_COMMANDS="ON"
[11](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:12)
  CXX="clang++"
[12](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:13)

[13](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:14)
-- The CXX compiler identification is Clang 16.0.0
[14](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:15)
-- The C compiler identification is Clang 16.0.0
[15](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:16)
-- Detecting CXX compiler ABI info
[16](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:17)
-- Detecting CXX compiler ABI info - done
[17](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:18)
-- Check for working CXX compiler: /usr/local/bin/clang++ - skipped
[18](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:19)
-- Detecting CXX compile features
[19](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:20)
-- Detecting CXX compile features - done
[20](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:21)
-- Detecting C compiler ABI info
[21](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:22)
-- Detecting C compiler ABI info - done
[22](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:23)
-- Check for working C compiler: /usr/local/bin/clang - skipped
[23](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:24)
-- Detecting C compile features
[24](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:25)
-- Detecting C compile features - done
[25](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:26)
-- Build type: RelWithAssert
[26](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:27)
-- Target architecture: westmere
[27](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:28)
-- Multithreading is enabled.
[28](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:29)
-- OMP multithreading is disabled.
[29](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:30)
-- Intel Thread Building Blocks is disabled.
[30](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:31)
CMake Deprecation Warning at build/_deps/gtest-src/CMakeLists.txt:4 (cmake_minimum_required):
[31](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:32)
  Compatibility with CMake < 3.5 will be removed from a future version of
[32](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:33)
  CMake.
[33](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:34)

[34](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:35)
  Update the VERSION argument <min> value or use a ...<max> suffix to tell
[35](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:36)
  CMake that the project does not need compatibility with older versions.
[36](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:37)

[37](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:38)

[38](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:39)
CMake Deprecation Warning at build/_deps/gtest-src/googletest/CMakeLists.txt:56 (cmake_minimum_required):
[39](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:40)
  Compatibility with CMake < 3.5 will be removed from a future version of
[40](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:41)
  CMake.
[41](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:42)

[42](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:43)
  Update the VERSION argument <min> value or use a ...<max> suffix to tell
[43](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:44)
  CMake that the project does not need compatibility with older versions.
[44](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:45)

[45](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:46)

[46](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:47)
CMake Warning (dev) at build/_deps/gtest-src/googletest/cmake/internal_utils.cmake:243 (find_package):
[47](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:48)
  Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs modules
[48](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:49)
  are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
[49](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:50)
  the cmake_policy command to set the policy and suppress this warning.
[50](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:51)

[51](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:52)
Call Stack (most recent call first):
[52](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:53)
  build/_deps/gtest-src/googletest/CMakeLists.txt:91 (include)
[53](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:54)
This warning is for project developers.  Use -Wno-dev to suppress it.
[54](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:55)

[55](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:56)
-- Found PythonInterp: /usr/bin/python (found version "3.8.10")
[56](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:57)
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
[57](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:58)
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
[58](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:59)
-- Looking for pthread_create in pthreads
[59](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:60)
-- Looking for pthread_create in pthreads - not found
[60](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:61)
-- Looking for pthread_create in pthread
[61](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:62)
-- Looking for pthread_create in pthread - found
[62](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:63)
-- Found Threads: TRUE
[63](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:64)
-- Failed to find LLVM FileCheck
[64](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:65)
-- Found Git: /usr/bin/git (found version "2.42.0")
[65](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:66)
-- git version: v1.7.1 normalized to 1.7.1
[66](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:67)
-- Version: 1.7.1
[67](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:68)
-- Looking for shm_open in rt
[68](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:69)
-- Looking for shm_open in rt - found
[69](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:70)
-- Performing Test HAVE_CXX_FLAG_WALL
[70](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:71)
-- Performing Test HAVE_CXX_FLAG_WALL - Success
[71](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:72)
-- Performing Test HAVE_CXX_FLAG_WEXTRA
[72](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:73)
-- Performing Test HAVE_CXX_FLAG_WEXTRA - Success
[73](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:74)
-- Performing Test HAVE_CXX_FLAG_WSHADOW
[74](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:75)
-- Performing Test HAVE_CXX_FLAG_WSHADOW - Success
[75](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:76)
-- Performing Test HAVE_CXX_FLAG_WFLOAT_EQUAL
[76](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:77)
-- Performing Test HAVE_CXX_FLAG_WFLOAT_EQUAL - Success
[77](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:78)
-- Performing Test HAVE_CXX_FLAG_WERROR
[78](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:79)
-- Performing Test HAVE_CXX_FLAG_WERROR - Success
[79](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:80)
-- Performing Test HAVE_CXX_FLAG_WSUGGEST_OVERRIDE
[80](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:81)
-- Performing Test HAVE_CXX_FLAG_WSUGGEST_OVERRIDE - Success
[81](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:82)
-- Performing Test HAVE_CXX_FLAG_PEDANTIC
[82](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:83)
-- Performing Test HAVE_CXX_FLAG_PEDANTIC - Success
[83](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:84)
-- Performing Test HAVE_CXX_FLAG_PEDANTIC_ERRORS
[84](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:85)
-- Performing Test HAVE_CXX_FLAG_PEDANTIC_ERRORS - Success
[85](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:86)
-- Performing Test HAVE_CXX_FLAG_WSHORTEN_64_TO_32
[86](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:87)
-- Performing Test HAVE_CXX_FLAG_WSHORTEN_64_TO_32 - Success
[87](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:88)
-- Performing Test HAVE_CXX_FLAG_FSTRICT_ALIASING
[88](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:89)
-- Performing Test HAVE_CXX_FLAG_FSTRICT_ALIASING - Success
[89](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:90)
-- Performing Test HAVE_CXX_FLAG_WNO_DEPRECATED_DECLARATIONS
[90](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:91)
-- Performing Test HAVE_CXX_FLAG_WNO_DEPRECATED_DECLARATIONS - Success
[91](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:92)
-- Performing Test HAVE_CXX_FLAG_WNO_DEPRECATED
[92](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:93)
-- Performing Test HAVE_CXX_FLAG_WNO_DEPRECATED - Success
[93](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:94)
-- Performing Test HAVE_CXX_FLAG_WSTRICT_ALIASING
[94](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:95)
-- Performing Test HAVE_CXX_FLAG_WSTRICT_ALIASING - Success
[95](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:96)
-- Performing Test HAVE_CXX_FLAG_WD654
[96](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:97)
-- Performing Test HAVE_CXX_FLAG_WD654 - Failed
[97](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:98)
-- Performing Test HAVE_CXX_FLAG_WTHREAD_SAFETY
[98](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:99)
-- Performing Test HAVE_CXX_FLAG_WTHREAD_SAFETY - Success
[99](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:100)
-- Enabling additional flags: -DINCLUDE_DIRECTORIES=/home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/build/_deps/benchmark-src/include
[100](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:101)
-- Compiling and running to test HAVE_THREAD_SAFETY_ATTRIBUTES
[101](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:102)
-- Performing Test HAVE_THREAD_SAFETY_ATTRIBUTES -- success
[102](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:103)
-- Performing Test HAVE_CXX_FLAG_COVERAGE
[103](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:104)
-- Performing Test HAVE_CXX_FLAG_COVERAGE - Success
[104](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:105)
-- Compiling and running to test HAVE_STD_REGEX
[105](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:106)
-- Performing Test HAVE_STD_REGEX -- success
[106](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:107)
-- Compiling and running to test HAVE_GNU_POSIX_REGEX
[107](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:108)
-- Performing Test HAVE_GNU_POSIX_REGEX -- failed to compile
[108](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:109)
-- Compiling and running to test HAVE_POSIX_REGEX
[109](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:110)
-- Performing Test HAVE_POSIX_REGEX -- success
[110](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:111)
-- Compiling and running to test HAVE_STEADY_CLOCK
[111](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:112)
-- Performing Test HAVE_STEADY_CLOCK -- success
[112](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:113)
-- Check if compiler accepts -pthread
[113](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:114)
-- Check if compiler accepts -pthread - yes
[114](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:115)
-- Using optimized assembly for field arithmetic.
[115](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:116)
-- Compiling all-in-one barretenberg archive
[116](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:117)
-- Configuring done (13.5s)
[117](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:118)
-- Generating done (0.2s)
[118](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:119)
-- Build files have been written to: /home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/build
[119](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:120)
[1/152] Creating directories for 'msgpack-c'
[120](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:121)
[2/152] Performing download step (git clone) for 'msgpack-c'
[121](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:122)
Cloning into 'msgpack-c'...
[122](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:123)
HEAD is now at af447c28 fix(wasm): Throw => THROW
[123](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:124)
[3/152] No update step for 'msgpack-c'
[124](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:125)
[4/152] No patch step for 'msgpack-c'
[125](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:126)
[5/152] No configure step for 'msgpack-c'
[126](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:127)
[6/152] No build step for 'msgpack-c'
[127](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:128)
[7/152] No install step for 'msgpack-c'
[128](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:129)
[8/152] Completed 'msgpack-c'
[129](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:130)
[9/152] Building CXX object src/barretenberg/env/CMakeFiles/env_objects.dir/logstr.cpp.o
[130](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:131)
[10/152] Building CXX object src/barretenberg/env/CMakeFiles/env_objects.dir/data_store.cpp.o
[131](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:132)
[11/152] Building CXX object src/barretenberg/env/CMakeFiles/env_objects.dir/hardware_concurrency.cpp.o
[132](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:133)
[12/152] Linking CXX static library lib/libenv.a
[133](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:134)
[13/152] Building CXX object src/barretenberg/common/CMakeFiles/common_objects.dir/mem.cpp.o
[134](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:135)
[14/152] Building CXX object src/barretenberg/common/CMakeFiles/common_objects.dir/c_bind.cpp.o
[135](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:136)
[15/152] Building CXX object src/barretenberg/common/CMakeFiles/common_objects.dir/parallel_for_atomic_pool.cpp.o
[136](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:137)
[16/152] Building CXX object src/barretenberg/common/CMakeFiles/common_objects.dir/parallel_for_omp.cpp.o
[137](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:138)
[17/152] Building CXX object src/barretenberg/common/CMakeFiles/common_objects.dir/parallel_for_mutex_pool.cpp.o
[138](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:139)
[18/152] Building CXX object src/barretenberg/common/CMakeFiles/common_objects.dir/parallel_for_moody.cpp.o
[139](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:140)
[19/152] Building CXX object src/barretenberg/common/CMakeFiles/common_objects.dir/parallel_for_spawning.cpp.o
[140](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:141)
[20/152] Building CXX object src/barretenberg/common/CMakeFiles/common_objects.dir/parallel_for_queued.cpp.o
[141](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:142)
[21/152] Building CXX object src/barretenberg/common/CMakeFiles/common_objects.dir/thread_utils.cpp.o
[142](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:143)
[22/152] Building CXX object src/barretenberg/common/CMakeFiles/common_objects.dir/thread.cpp.o
[143](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:144)
[23/152] Building CXX object src/barretenberg/common/CMakeFiles/common_objects.dir/slab_allocator.cpp.o
[144](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:145)
[24/152] Building CXX object src/barretenberg/srs/CMakeFiles/srs_objects.dir/c_bind.cpp.o
[145](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:146)
FAILED: src/barretenberg/srs/CMakeFiles/srs_objects.dir/c_bind.cpp.o
[146](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:147)
/usr/local/bin/clang++ -DNO_OMP_MULTITHREADING -DNO_TBB -I/home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/src -I/home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/build/_deps/msgpack-c/src/msgpack-c/include -std=gnu++20 -O3 -march=westmere -pthread -Werror -Wall -Wextra -Wconversion -Wsign-conversion -Wfatal-errors -fcolor-diagnostics -fconstexpr-steps=100000000 -MD -MT src/barretenberg/srs/CMakeFiles/srs_objects.dir/c_bind.cpp.o -MF src/barretenberg/srs/CMakeFiles/srs_objects.dir/c_bind.cpp.o.d -o src/barretenberg/srs/CMakeFiles/srs_objects.dir/c_bind.cpp.o -c /home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/src/barretenberg/srs/c_bind.cpp
[147](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:148)
In file included from /home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/src/barretenberg/srs/c_bind.cpp:2:
[148](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:149)
In file included from /home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/src/barretenberg/srs/./io.hpp:2:
[149](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:150)
In file included from /home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/src/barretenberg/srs/../ecc/curves/bn254/bn254.hpp:6:
[150](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:151)
In file included from /home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/src/barretenberg/srs/../ecc/curves/bn254/../bn254/g1.hpp:3:
[151](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:152)
In file included from /home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/src/barretenberg/srs/../ecc/curves/bn254/../../groups/group.hpp:4:
[152](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:153)
In file included from /home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/src/barretenberg/srs/../ecc/curves/bn254/../../groups/./affine_element.hpp:189:
[153](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:154)
/home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/src/barretenberg/srs/../ecc/curves/bn254/../../groups/./affine_element_impl.hpp:260:26: fatal error: variable of non-literal type 'std::vector<uint8_t>' (aka 'vector<unsigned char>') cannot be defined in a constexpr function before C++2b
[154](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:155)
    std::vector<uint8_t> target_seed(seed);
[155](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:156)
                         ^
[156](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:157)
/usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_vector.h:389:11: note: 'vector<unsigned char>' is not literal because it is not an aggregate and has no constexpr constructors other than copy or move constructors
[157](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:158)
    class vector : protected _Vector_base<_Tp, _Alloc>
[158](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:159)
          ^
[159](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:160)
1 error generated.
[160](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:161)
[25/152] Building CXX object src/barretenberg/numeric/CMakeFiles/numeric_objects.dir/random/engine.cpp.o
[161](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:162)
[26/152] Building CXX object src/barretenberg/srs/CMakeFiles/srs_objects.dir/factories/file_crs_factory.cpp.o
[162](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:163)
FAILED: src/barretenberg/srs/CMakeFiles/srs_objects.dir/factories/file_crs_factory.cpp.o
[163](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:164)
/usr/local/bin/clang++ -DNO_OMP_MULTITHREADING -DNO_TBB -I/home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/src -I/home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/build/_deps/msgpack-c/src/msgpack-c/include -std=gnu++20 -O3 -march=westmere -pthread -Werror -Wall -Wextra -Wconversion -Wsign-conversion -Wfatal-errors -fcolor-diagnostics -fconstexpr-steps=100000000 -MD -MT src/barretenberg/srs/CMakeFiles/srs_objects.dir/factories/file_crs_factory.cpp.o -MF src/barretenberg/srs/CMakeFiles/srs_objects.dir/factories/file_crs_factory.cpp.o.d -o src/barretenberg/srs/CMakeFiles/srs_objects.dir/factories/file_crs_factory.cpp.o -c /home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/src/barretenberg/srs/factories/file_crs_factory.cpp
[164](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:165)
In file included from /home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/src/barretenberg/srs/factories/file_crs_factory.cpp:1:
[165](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:166)
In file included from /home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/src/barretenberg/srs/factories/file_crs_factory.hpp:2:
[166](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:167)
In file included from /home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/src/barretenberg/srs/factories/../io.hpp:2:
[167](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:168)
In file included from /home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/src/barretenberg/srs/factories/../../ecc/curves/bn254/bn254.hpp:6:
[168](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:169)
In file included from /home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/src/barretenberg/srs/factories/../../ecc/curves/bn254/../bn254/g1.hpp:3:
[169](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:170)
In file included from /home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/src/barretenberg/srs/factories/../../ecc/curves/bn254/../../groups/group.hpp:4:
[170](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:171)
In file included from /home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/src/barretenberg/srs/factories/../../ecc/curves/bn254/../../groups/./affine_element.hpp:189:
[171](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:172)
/home/runner/work/aztec-packages/aztec-packages/barretenberg/cpp/src/barretenberg/srs/factories/../../ecc/curves/bn254/../../groups/./affine_element_impl.hpp:260:26: fatal error: variable of non-literal type 'std::vector<uint8_t>' (aka 'vector<unsigned char>') cannot be defined in a constexpr function before C++2b
[172](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:173)
    std::vector<uint8_t> target_seed(seed);
[173](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:174)
                         ^
[174](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:175)
/usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_vector.h:389:11: note: 'vector<unsigned char>' is not literal because it is not an aggregate and has no constexpr constructors other than copy or move constructors
[175](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:176)
    class vector : protected _Vector_base<_Tp, _Alloc>
[176](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:177)
          ^
[177](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:178)
1 error generated.
[178](https://github.com/AztecProtocol/aztec-packages/actions/runs/6630613410/job/18012362609#step:6:179)
ninja: build stopped: subcommand failed.

closed by #3019


open selection keypad by default

In the input field has something selected before hand, then by default open selection keypad.

I have never encountered a screnario where I could highlight something and then open the keyboard!
How did you do it?

by clicking on the address bar on an active page in firefor.
On Tue, 22 Dec 2020, 21:54 Glitchy-Tozier<EMAIL_ADDRESS>wrote:

I have never encountered a screnario where I could highlight something and
then open the keyboard!
How did you do it?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/flide/8VIM/issues/150#issuecomment-749632715, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABX5WR7X4RW6U7LU2HV5RLDSWDB3TANCNFSM4VFWWV4A
.

Ah yeah, forgot about that!
In that case, I think it's better to keep the normal keyboard however!
Especially since Firefox (and other browsers as well) have the feature that you can long-click the address-bar and immediately copy or paste & go.
If I actually short-click on the address bar, I want to edit the URL. And in that case, the normal keypad is more helpful.

Huh!! I never knew about this feature of firefox. Makes sense actually, don't know why I never tried...
Anyways, apart from this I know of no use case. If no one reports in support for this feature, say within 20 days, I will cancel this.


Is it possible to include multiple files and then compile and link them ?

Is it possible to include multiple files and then compile and link them ?
Or do we have to put all the code after %%cu in the cell of the notebook ?

hello @AvanteElectro
yes, you can compile multiple files with v2 of the extension. Please review the readme.
For each file you'll need something like
%%cuda --name example.cu --compile false

The new version of the package does this using the concept of groups. Read more about them here.


Create an Endorser Service based on ACA-Py

Please create a basic Endorser Service using ACA-Py that can be deployed as needed and used to provide Hyperledger Indy network endorsing of transactions for authors to a given network.  The following is a brief summary of the requirements for the service, all of which are based on current functionality of ACA-Py.

Be configured to have a public DID that is used for connections

Since we ultimately want to allow a single Endorser service to support multiple networks, the Endorser DID and public DID should be handled separately, even if they are the same DID.

Be configured to start up with a given endorser DID for a given network

The Service should know what network there Endorser is far, even if it Endorsers transactions only for a single network.

An "allow" list of connections for which Endorsements are permitted.
A mechanism to allow for extending the "allow" list of authors in a way that is as convenient as possible.

For example, accept the connection, receive an endorsement request, reject it, notify (somehow) somebody that a new author has a requested endorsing, update the allow list.
Ultimately, we want a UI for the service that allows for interactive handling of the allow list.
We need right away a method to know what authors are authorized to use the service. Perhaps an endpoint that lists the allow list along with the metadata about the authors.  That means that the administrators should include sufficient information on the allow list to be displayed -- e.g. name of service, URL for service, name of service contact, etc.

Define a deployment approach for DTS that enables deploying two instances of the service (dev, test, prod each) supporting:

dev: BCovrin, CANdy-Dev
test:  Sovrin Staging, CANdy-Dev (later test)
prod: Sovrin MainNet, CANdy-Dev (later prod)

Instructions for how to setup authors to use the service.

This could become a Hyperledger Aries repo.

@ianco -- please take a look at this and come up with the best way to do this short term and long.  We need a short term version pretty quickly, but would like this to be a complete service in the long run -- e.g. handling endorsing transactions for multiple Indy networks, a user interface for administrators of the service, etc. However, we can take shortcuts initially -- e.g. restarting the service to add authors to the allow list.  But figuring out how to bootstrap an author in a reasonable smooth way is important.
One important use case right away is LSBC on Sovrin MainNet for revocations.  Somehow, we have to make sure that we can transition that instance from being an Endorser to being an Author without losing any revocations.

We have an endorser service in the traction repo (https://github.com/bcgov/traction/tree/develop/services/endorser)
Currently this is setup to auto-accept connections and auto-endorse any transaction requests, but could be modified per your requirements.  There is a controller implemented in python/FastAPI that currently doesn't do much other than make sure the connection meta-data is setup.

One important use case right away is LSBC on Sovrin MainNet for revocations. Somehow, we have to make sure that we can transition that instance from being an Endorser to being an Author without losing any revocations.

Can you change a DID's role once it's written to the ledger?

I've created a hackmd here:  https://hackmd.io/@H1HgS-RdQMukDzKQtR7iNg/BJ_woLTH9
... and I've started populating the https://github.com/bcgov/aries-endorser-service repo

Done and deployed.  The initial set of issuers are rooted on CANdy, with a couple author services (IDIM and BC VC Pilot) connected.


Possible error

int tagval=-1;
When I use GetTag("NM", tagval);
The function is stuck at line: if ( !TagTypeHelper::CanConvertFrom(type)
in BamAlignment.h
When I looked at the TagData it was like:  NMC^AMDZ98T2
const char type = *(pTagData - 1);
The type variable has a value of 'C' instead of 'i'.  I am using the latest version of bwa.  Looking into
the code of bwa, it is using the type i.  The MD string is properly typed as Z.
Not sure this is caused by some modification from my part or not.  Any one can give a pointer as to how to fix this bug?  I will do the fixing.

so far my temporary fix is like the following in the GetTag() function:
if (type == 'C' && (tag == "NM" || tag == "AS" || tag == "XS")) { // patch a bug
   //type = Constants::BAM_TAG_TYPE_INT32;
  //cout << __FILE__ << ":" << __LINE__ << ": pTagData: "
  //   << pTagData << endl;
  //cerr << "NM int val at pTagData: " << (int)(*pTagData) << " at 2 bytes later: "
  //   << (int)(*(pTagData+2)) << endl;
   // this is a short term patch for the bug
  destination=(int)(*pTagData);
  return true;
}
else if ( !TagTypeHelper<T>::CanConvertFrom(type) ) {
    // TODO: set error string ?
   cerr << __FILE__ << ":" << __LINE__ << ":"
      << "Failed to convert to " << typeid(destination).name()
      << " from " << type << endl;
    return false;
}

This is a patch,  not a real fix.

I used the GetTagType function (http://pezmaster31.github.io/bamtools/struct_bam_tools_1_1_bam_alignment.html#ac9cac21df9ef4a0a3414387b97cf14da) to identify the 'c' type (http://pezmaster31.github.io/bamtools/_bam_constants_8h.html) and ended up using int8_t to read the NM tag.

Does the bam definition have C type?

Any progress on this?  I may be seeing the same error.  samtools view shows the read as:
ST-E00216:212:H5MHMCCXY:1:2208:25033:50832      99      NMWX01000001.1  99      60      7S144M  =       515     567     AATTCCAGACAGCGGATGCGCCTCCATTCGAGCACCAAATCGTTAAGGTCGTGGAACCTGCGGAGTGGGTGGGAAACTGCGTTAAAGTACCGGATGAAAAGTGGAAACGCTGGGTAAGTGTTTGAAAATGTGTTTCTCTTAAAACAATGGA        A<A<FJFFJJJJJFJJFJFJJJFA7AJJJJAAFAJJFFFJJFJ<J-FJJJJFJF7---<FFJJ<F-F777FJJJ-7F7JJFA7FAFJ-FJFFJFAA7J7AFJJJF-7FJJFFJF77-AJJF<J-7-<7FFFJA7F--AFF77-AF7F-7-<        MC:Z:151M      MD:Z:37G25T52T25A1      NM:i:4  MQ:i:60 AS:i:127        XS:i:19 RG:Z:QF-1499-T1-37_S2

and the Alignment is
Alignment = {
        Name = "ST-E00216:212:H5MHMCCXY:1:2208:25033:50832", Length = 151,
        QueryBases = "AATTCCAGACAGCGGATGCGCCTCCATTCGAGCACCAAATCGTTAAGGTCGTGGAACCTGCGGAGTGGGTGGGAAACTGCGTTAAAGTACCGGATGAAAAGTGGAAACGCTGGGTAAGTGTTTGAAAATGTGTTTCTCTTAAAACAATGGA",
        AlignedBases = "GACAGCGGATGCGCCTCCATTCGAGCACCAAATCGTTAAGGTCGTGGAACCTGCGGAGTGGGTGGGAAACTGCGTTAAAGTACCGGATGAAAAGTGGAAACGCTGGGTAAGTGTTTGAAAATGTGTTTCTCTTAAAACAATGGA",
        Qualities = "A<A<FJFFJJJJJFJJFJFJJJFA7AJJJJAAFAJJFFFJJFJ<J-FJJJJFJF7---<FFJJ<F-F777FJJJ-7F7JJFA7FAFJ-FJFFJFAA7J7AFJJJF-7FJJFFJF77-AJJF<J-7-<7FFFJA7F--AFF77-AF7F-7-<", TagData = "MCZ151M\000MDZ37G25T52T25A1\000NMC\004MQC<ASC\177XSC\023RGZQF-1499-T1-37_S2", RefID = 0,

Zooming in on the tags shows the read has:
MC:Z:151M      MD:Z:37G25T52T25A1      NM:i:4  MQ:i:60 AS:i:127        XS:i:19 RG:Z:QF-1499-T1-37_S2

which results in the Alignment containing
TagData = "MCZ151M\000MDZ37G25T52T25A1\000NMC\004MQC<ASC\177XSC\023RGZQF-1499-T1-37_S2"

I am seeing C in place of i and the \023 separating it from RGZ (how I am seeing the bug) is equivalent to the decimal 19 (which follows XS:i:) in octal.
The same pattern appears for other tags and :i: in this read.  NM:i:4 produces NMC\004, MQ:i:60 produced MQC<, and AS:i:127 produced ASC\177.

Yes, see Section 1.5 of http://samtools.github.io/hts-specs/SAMv1.pdf.  Integer types on tags (e.g., XS:i:20 in SAM format) may be encoded into the smallest integer that can hold the integer value.  In the case of XS:i:20, this was encoded as XSC\024.  The C indicates a uint8_t.  Use GetTagType() to figure out the tag type (for C, the value Constants::BAM_TAG_TYPE_UINT8 will be returned) and then store it in an appropriate variable.


Avoid redundant declarations of bindings

Problem
Currently, we don't have a way to reuse bindings across different bindings. Hence, we have the following issues related to not having a way to share declaration across different language id like c and c++ or js/typescript.

https://github.com/VSpaceCode/VSpaceCode/pull/193#issuecomment-849956477
https://github.com/VSpaceCode/VSpaceCode/issues/201

Solution
Supply location of the configuration to value of "bindings". For example:
{
    "key": "b",
    "name": "+Buffers/Editors",
    "type": "bindings",
    "bindings": "whichkey.bindingsRef.buffers"
}

This will refer to the bindings defined at whichkey.bindingsRef.buffers in the configuration for example
Alternatives
We can change the conditional key to support logical or to solve issue of sharing bindings between different language mode like c and c++; however, that is limited in what it can solve, and could make the declarations the key for the condition.
Additional context

The implementation of layer mode (https://github.com/VSpaceCode/VSpaceCode/issues/199) might affect the solutions to this issue
The purposed solution can share an identical copies of bindings; however, that would not able to support if a user want to mutate some part of the same config. For example: imaging this as an inheritance relationship, where the c++ bindings are inherited from the c bindings with some extra overrides.

On the last point of inheritance, we might able to do something like
[
    {
        "key": "languageId:c",
        "name": "+Buffers/Editors",
        "type": "bindings",
        "bindings": "vspacecode.bindingRef.c"
    },
    {
        "key": "languageId:cpp",
        "name": "+Buffers/Editors",
        "type": "bindings",
        "bindings": {
            "ref": "vspacecode.bindingRef.c",
            "overrides": "vspacecode.overridesRef.cpp"
        }
    }
]

Instead of inheritance, we could use composition, i.e. we have some group of bindings called "shared c/c++" and both c and c++ include those bindings.
This could be useful because we could share all the common bindings across all major modes

I think I understand mostly what you are saying, but to drive it home. Can you provide an example of the "composition"?

Something like this:
{
	"vspacecode.bindings": {
		"type": "array",
		"markdownDescription": "The bindings of the which key menu",
		"lsp": [
			{
				"key": "=",
				"name": "+Format",
				"type": "bindings",
				"bindings": [
					{
						"key": "=",
						"name": "Format region or buffer",
						"type": "command",
						"command": "editor.action.format"
					}
				]
			}
		],
		"default": [
			{
				"key": "languageId:rust",
				"name": "Rust",
				"type": "bindings",
				"common_bindings": ["lsp"],
				"bindings": [
					{
						"key": "T",
						"name": "Toggle inlay hints",
						"type": "command",
						"command": "rust-analyzer.toggleInlayHints"
					}
				]
			},
			{
				"key": "languageId:c",
				"name": "C",
				"type": "bindings",
				"common_bindings": ["lsp"],
				"bindings": [
					{
						"key": "X",
						"name": "Do amazing c Stuff",
						"type": "command",
						"command": "c-analyzer.command"
					}
				]
			}
		]
	}
}

This is just a sketch to give you the idea, do not take into consideration field names and syntax  :)

Thank you for the example. It still feels a little bit like an inheritance and can have conflicting bindings where two common binding ref might have conflicting bindings.
To keep it simple, we can offer a simple binding reference like
[
    {
        "key": "languageId:c",
        "name": "+Buffers/Editors",
        "type": "bindings",
        "bindings": "vspacecode.bindingRef.c"
    },
]

so we don't have duplicate bindings for c/c++ and js/ts.
In addition, we will just use strict composition, for some case it may still be tedious to declare not exact duplicate bindings but at least it is clear.
[
    {
        "key": "languageId:c",
        "name": "+Buffers/Editors",
        "type": "bindings",
        "bindings": [
            {
                "key": "g",
		        "name": "+Go to",
		        "type": "bindings",
		        "bindings": "vspacecode.lsp.goto"
            }
            // ...
        ]
    },
]

Also, I am thinking the thinking in implementation of layers might change how this should be implemented. See https://github.com/VSpaceCode/VSpaceCode/issues/199

sorry but it's not very clear to me. Maybe it would be helpful if you reproduce my example with your syntax, if you don't mind.

{
	"vspacecode.bindings": {
		"type": "array",
		"markdownDescription": "The bindings of the which key menu",
		"lsp": [
			{
				"key": "=",
				"name": "+Format",
				"type": "bindings",
				"bindings": [
					{
						"key": "=",
						"name": "Format region or buffer",
						"type": "command",
						"command": "editor.action.format"
					}
				]
			}
		],
		"lsp2": [
			{
				"key": "=",
				"name": "+Format",
				"type": "command",
				"bindings": [
					{
						"key": "=",
						"name": "do something else",
						"type": "command",
						"command": "do.something.else"
					},
					{
						"key": "x",
						"name": "do something else2",
						"type": "command",
						"command": "do.something.else2"
					}
				]
			}
		],
		"default": [
			{
				"key": "languageId:rust",
				"name": "Rust",
				"type": "bindings",
				"common_bindings": ["lsp", "lsp2"],
				"bindings": [
					{
						"key": "T",
						"name": "Toggle inlay hints",
						"type": "command",
						"command": "rust-analyzer.toggleInlayHints"
					}
				]
			}
		]
	}
}

Thank you for bearing with me. For example, default will have two common bindings lsp and lsp2; however, lsp and lsp2 both defined = key. We will have conflict in this case, we will have figure out how to resolve them (e.g. subsequent common_bindings override or merging automatically). It reminds me of multiple inheritance problems, which can introduce a lot of complicity.
I was suggesting to start something simple which allows direct reference only like
{
	"vspacecode.bindings": {
		"type": "array",
		"markdownDescription": "The bindings of the which key menu",
		"lsp2": [
				{
					"key": "=",
					"name": "do something else",
					"type": "command",
					"command": "do.something.else"
				},
				{
					"key": "x",
					"name": "do something else2",
					"type": "command",
					"command": "do.something.else2"
				}
		],
		"default": [
			{
				"key": "languageId:rust",
				"name": "Rust",
				"type": "bindings",
				"bindings": [
					{
						"key": "=",
						"name": "+Format",
						"type": "bindings",
						"bindings": "vspacecode.bindings.lsp2"
					}
					{
						"key": "T",
						"name": "Toggle inlay hints",
						"type": "command",
						"command": "rust-analyzer.toggleInlayHints"
					}
				]
			}
		]
	}
}

However, it is quite inflexible as it requires a set of bindings to defined elsewhere. In addition, the implementation of layer will influence how we should declare bindings greatly.

Oh, I see now, thanks a lot for bearing with me too!
Yes it looks good to me :D


scan_github_labels.rb:40: n.when -- let's find out when...

The puzzle 1-98d90b57 from #1 has to be resolved:
https://github.com/zerocracy/judges-action/blob/12e5e1f7fb71d21cd366145d92756bf82e494d5c/judges/scan/scan_github_labels/scan_github_labels.rb#L40-L40
The puzzle was created by @yegor256 on 22-May-24.
Estimate: 30 minutes,  role: DEV.
If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

The puzzle 1-98d90b57 has disappeared from the source code, that's why I closed this issue.


top navbar and menu button open should be fixed in mobile

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is.
so in mobile the top navbar and menu button should be fixed as its the navigation to all pages
Describe the solution you'd like
we can fix the navbar for mobile screens where the main covidindia link and menu button are there.
that should be fixed as it will help us to navigate to any page any section even if you scroll down in a page.
A clear and concise description of what you want to happen.
we need to fix the menu and navbar for mabile screens.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

please do assign it to me so that i can fix the navbar for the navbar and menu button for easy navigation in mobile screen

Addressed by #1477


Get coordinates of a shifted polygon or marker

Hi,
I have enabled the pmIgnore: false function on some points and polygons.
After clicking the finish button, I need the new coordinates which are shown in the console.log (e) function but the generated geojson is too big.
How can I find the new coordinates?
Also I would need to know which polygon or marker I have moved.
How can i do it?
Thanks for the reply

To get the changed coords:
map.on('pm:create', (e)=>{
    if(e.layer instanceof L.Polyline) {
      var latlngs = e.layer.getLatLngs();

      // if "finish" is pressed
      e.layer.on('pm:update', (ev) => {
        var layer = ev.layer;
        var latlngsNew = layer.getLatLngs();

        var flattenLatLngs = latlngs.flat();
        var flattenLatLngsNew = latlngsNew.flat();

        var newCoords = [];
        var oldCoords = [];
        // go through the coords and check if they are in the old latlngs
        flattenLatLngsNew.forEach((latlng) => {
          if (flattenLatLngs.find(l => l.equals(latlng))) {
            oldCoords.push(latlng)
          } else {
            newCoords.push(latlng)
          }
        });

        console.log(layer, newCoords, oldCoords)

        // update latlngs variable for the next edit
        latlngs = latlngsNew;
      })
    }
  })

You can get a changed layer over pm:dragend


Fix Imagemagick Bug

Removed resize flag to fix Imagemagick not working (Imagemagick couldn't generate a suitable palette)

This also slows down palette generation and is more of a band-aid than a solution. Throwing more colors at imagemagick will increase the chances of a valid palette but only in some cases.
A better solution is to tweak the convert command to always return enough colors. I'll push a fix shortly.


Custom Attributes Nav from SF

Is this the standard request made by AAD to SF?
https://[SuccessFactorsAPIEndpoint]/odata/v2/PerPerson?$format=json&
$filter=(personIdExternal in '[personIdExternalValue]')&$expand=employmentNav/userNav,employmentNav/jobInfoNav,personalInfoNav,personEmpTerminationInfoNav,phoneNav,phoneNav/phoneTypeNav,emailNav,employmentNav/jobInfoNav/businessUnitNav,employmentNav/jobInfoNav/companyNav,employmentNav/jobInfoNav/companyNav/countryOfRegistrationNav,employmentNav/jobInfoNav/costCenterNav,employmentNav/jobInfoNav/divisionNav,employmentNav/jobInfoNav/departmentNav,employmentNav/jobInfoNav/jobCodeNav,employmentNav/jobInfoNav/locationNav,employmentNav/jobInfoNav/locationNav/addressNavDEFLT,employmentNav/jobInfoNav/payGradeNav,employmentNav/empGlobalAssignmentNav,employmentNav/empGlobalAssignmentNav/assignmentTypeNav,employmentNav/jobInfoNav/emplStatusNav,employmentNav/jobInfoNav/employmentTypeNav,employmentNav/jobInfoNav/employeeClassNav,employmentNav/jobInfoNav/eventReasonNav
If there are additional attributes required to be imported which would need to modify this standard request, Is it possible?
For Example, My customer holds a custom information in the Nav $.employmentNav.results[0].userNav.results[0].externalCodeOfcust_ADID_DetailsNav.
Is it possible to expand this Nav in the request?
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 56401d85-b771-94ed-5505-c0ba929ba27b
Version Independent ID: d7a38614-2897-1c94-5d24-120431cb018a
Content: Azure Active Directory and SAP SuccessFactors integration reference
Content Source: articles/active-directory/app-provisioning/sap-successfactors-integration-reference.md
Service: active-directory
Sub-service: app-provisioning
GitHub Login: @kenwith
Microsoft Alias: kenwith

@sivabalaguru apologies for the inconvenience . We use azure-docs repository on GitHub for improvement of documentation specifically and would take requests like these on Microsoft QnA . I understand your request about knowing just the valid API call however since I do not have a ready test environment for the same its difficult to exactly provide the API call hence I requested yo to take this offline as I am hoping you would have a dev/test environment where someone from our side can help you on the same. I have reached out to you over email . We will take this offline .


Custom plugin needs updated after VSR api types change

#95 needs merged first

https://github.com/openshift/velero-plugin-for-csi/pull/20


Request configure permission of job build-scripts/release/refactor_openjdk_release_tool

For linux installer publish to releases repo I will need access the job build-scripts/release/refactor_openjdk_release_tool, which currently I can't even see it. The following jobs are visible but can't see the configurations. Would be helpful if I could get the visibility of the configurations to have a big picture of the release.
job/build-scripts/job/release/job/sign_build/
/job/build-scripts/job/release/job/sign_installer/
/job/build-scripts/job/release/job/create_installer_mac/
job/build-scripts/job/release/job/create_installer_windows/
Thanks @sxa

@sophia-guo I think you have the permission you need now? Can this be closed?

yep, close it as I do have the permission now. Thanks @sxa


Does this function pinocchio::impulseDynamics support automatic code generation via CppADCodeGen?

I tried to generate the code of function pinocchio::impulseDynamics but i got runtime error
terminate called after throwing an instance of 'CppAD::cg::CGException'
  what():  GreaterThanOrZero cannot be called for non-parameters

so this is function supports CppADCodeGen? or i miss some setup? And this there any function table can tell us which function support CppADCodeGen and which doesn't?
Thanks a lot!

also i tried computeMinverse, it will can not use too.
but those follwing function succeed.
  pinocchio::forwardKinematics(model, data, qPinocchio, vPinocchio);
  pinocchio::computeJointJacobians(model, data);
  pinocchio::updateFramePlacements(model, data);
  pinocchio::crba(model, data, qPinocchio);

Hello mate,
Thanks for opening an issue. We can't exactly reproduce it - could you
provide a complete minimum working example (a snippet of code that runs)
with your robot model?
On Thu, 14 Dec 2023, 20:35 Jiyu Yu, @.***> wrote:

also i tried computeMinverse, it will can not use too.
but those follwing function succeed.
pinocchio::forwardKinematics(model, data, qPinocchio, vPinocchio);
pinocchio::computeJointJacobians(model, data);
pinocchio::updateFramePlacements(model, data);
pinocchio::crba(model, data, qPinocchio);
—
Reply to this email directly, view it on GitHub
https://github.com/stack-of-tasks/pinocchio/issues/2121#issuecomment-1856462454,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFA427HGWEXVHYPA2FTLZUTYJNIGJAVCNFSM6AAAAABAVLRKCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJWGQ3DENBVGQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

@ManifoldFR yes, sure
my robot model is anymal_c a 4-legged robot with floating base. and i build model from urdf
and i try to use cppad to generate the following code:
using ad_base_t = CppAD::cg::CG<scalar_t>;
using ad_scalar_t = CppAD::AD<ad_base_t>;
using ad_vector_t = Eigen::Matrix<ad_scalar_t, Eigen::Dynamic, 1>;
using ad_matrix_t = Eigen::Matrix<ad_scalar_t, Eigen::Dynamic, Eigen::Dynamic>;
// the input of the function is stack of q and v
ad_vector_t qPinocchio = input.head(qPinocchio.rows());
ad_vector_t vPinocchio = input.head(vPinocchio.rows());
pinocchio::forwardKinematics(model, data, qPinocchio, vPinocchio);
pinocchio::computeJointJacobians(model, data);
pinocchio::updateFramePlacements(model, data);
pinocchio::crba(model, data, qPinocchio);

ad_matrix_t jacobian = ad_matrix_t::Zero(6, model.nq), jacobianXyz = ad_matrix_t::Zero(3, model.nq);

pinocchio::getFrameJacobian(model, data, model.getBodyId("FOOT"), pinocchio::LOCAL_WORLD_ALIGNED, jacobian);
jacobianXyz = jacobian.topRows(3);
pinocchio::impulseDynamics(model, data, vPinocchio, jacobianXyz, ad_scalar_t(0.1), ad_scalar_t(0.0));
ad_vector_t impulse = data.impulse_c; // impulseDynamics compute impulse and save it in data.impulse_c

return impulse; // i want to get the impulse by impulseDynamics as the function output

Could you provide a full self contained example ?

soory i can not give u guys a code can really running, it is in a large robotics project, but here is some code i copy from the project, i think this can make the question clear.
in fact i use those code to generate lots of function of pinocchio, it works well in my robot, but today, i first attempt to using impulseDynamics function and it gets error.
using ad_base_t = CppAD::cg::CG<scalar_t>;
using ad_scalar_t = CppAD::AD<ad_base_t>;
using ad_vector_t = Eigen::Matrix<ad_scalar_t, Eigen::Dynamic, 1>;
using ad_matrix_t = Eigen::Matrix<ad_scalar_t, Eigen::Dynamic, Eigen::Dynamic>;

void my_function(const ad_vector_t& input, ad_vector_t& output)
{
  // the input of the function is stack of q and v
  ad_vector_t qPinocchio = input.head(qPinocchio.rows());
  ad_vector_t vPinocchio = input.head(vPinocchio.rows());
  pinocchio::forwardKinematics(model, data, qPinocchio, vPinocchio);
  pinocchio::computeJointJacobians(model, data);
  pinocchio::updateFramePlacements(model, data);
  pinocchio::crba(model, data, qPinocchio);

  ad_matrix_t jacobian = ad_matrix_t::Zero(6, model.nq), jacobianXyz = ad_matrix_t::Zero(3, model.nq);

  pinocchio::getFrameJacobian(model, data, model.getBodyId("FOOT"), pinocchio::LOCAL_WORLD_ALIGNED, jacobian);
  jacobianXyz = jacobian.topRows(3);
  pinocchio::impulseDynamics(model, data, vPinocchio, jacobianXyz, ad_scalar_t(0.1), ad_scalar_t(0.0));
  ad_vector_t output = data.impulse_c; // impulseDynamics compute impulse and save it in data.impulse_c

  //return output; // i want to get the impulse by impulseDynamics as the function output
}

the following is where i use cppad:
{
  ad_vector_t xp(variableDim_);
  xp.setOnes();  // Ones are better than zero, to prevent devision by zero in taping
  CppAD::Independent(xp);

  my_function(xp, y);
  rangeDim_ = y.rows();
  // create f: xp -> y and stop tape recording
  ad_fun_t fun(xp, y);
  // Optimize the operation sequence
  fun.optimize();

  // generates source code
  CppAD::cg::ModelCSourceGen<scalar_t> sourceGen(fun, modelName_);
  setApproximationOrder(approximationOrder, sourceGen, fun);

  // Compiler objects, compile to temporary shared library file to avoid interference between processes
  CppAD::cg::ModelLibraryCSourceGen<scalar_t> libraryCSourceGen(sourceGen);
  CppAD::cg::GccCompiler<scalar_t> gccCompiler;
  CppAD::cg::DynamicModelLibraryProcessor<scalar_t> libraryProcessor(libraryCSourceGen, libraryName_ + tmpName_);

  // Compile and store the library
  dynamicLib_ = libraryProcessor.createDynamicLibrary(gccCompiler);
}

..or you guys have a example to use CppAdCodeGen to genorate  pinocchio::impulseDynamics? maybe i should change the setting of CppAdCodeGen?

You must understand with have limited time to help you. So the quicker we are able to dive into the topic, the quicker you will get an answer. So, could you provide a simple reproducible example ?

try this
#include <pinocchio/fwd.hpp>

#include <pinocchio/algorithm/contact-dynamics.hpp>
#include <pinocchio/algorithm/frames.hpp>
#include <pinocchio/algorithm/crba.hpp>
#include <pinocchio/algorithm/aba.hpp>
#include <pinocchio/parsers/urdf.hpp>

#include <cppad/cg.hpp>
#include <algorithm>
#include <functional>
#include <vector>

#include <urdf_model/model.h>
#include <urdf_parser/urdf_parser.h>

using scalar_t = double;
using ad_base_t = CppAD::cg::CG<scalar_t>;
using ad_scalar_t = CppAD::AD<ad_base_t>;
using ad_vector_t = Eigen::Matrix<ad_scalar_t, Eigen::Dynamic, 1>;
using ad_matrix_t = Eigen::Matrix<ad_scalar_t, Eigen::Dynamic, Eigen::Dynamic>;

int main() {
  // create model
  using joint_pair_t = std::pair<const std::string, std::shared_ptr<::urdf::Joint>>;
  const std::string urdfFilePath = "~/anymal_c_simple_description/urdf/anymal.urdf";
  urdf::ModelInterfaceSharedPtr urdfTree = urdf::parseURDFFile(urdfFilePath);
  if (urdfTree == nullptr) {
    throw std::invalid_argument("The file " + urdfFilePath + " does not contain a valid URDF model!");
  }

  // remove extraneous joints from urdf
  urdf::ModelInterfaceSharedPtr newModel = std::make_shared<::urdf::ModelInterface>(*urdfTree);
  std::vector<std::string> jointNames{"LF_HAA", "LF_HFE", "LF_KFE", "RF_HAA", "RF_HFE", "RF_KFE",
                                      "LH_HAA", "LH_HFE", "LH_KFE", "RH_HAA", "RH_HFE", "RH_KFE"};
  for (joint_pair_t& jointPair : newModel->joints_) {
    if (std::find(jointNames.begin(), jointNames.end(), jointPair.first) == jointNames.end()) {
      jointPair.second->type = urdf::Joint::FIXED;
    }
  }
  // add 6 DoF for the floating base
  pinocchio::JointModelComposite jointComposite(2);
  jointComposite.addJoint(pinocchio::JointModelTranslation());
  jointComposite.addJoint(pinocchio::JointModelSphericalZYX());
  pinocchio::ModelTpl<scalar_t> model;
  pinocchio::urdf::buildModel(urdfTree, jointComposite, model);

  //function
  ad_vector_t input(model.nq + model.nv);
  input.setOnes();  // Ones are better than zero, to prevent devision by zero in taping
  CppAD::Independent(input);
  // the input of the function is stack of q and v
  ad_vector_t qPinocchio = input.head(model.nq);
  ad_vector_t vPinocchio = input.tail(model.nv);

  auto cppAdModel = model.cast<ad_scalar_t>();
  pinocchio::DataTpl<ad_scalar_t> data(cppAdModel);

  pinocchio::forwardKinematics(cppAdModel, data, qPinocchio, vPinocchio);
  pinocchio::computeJointJacobians(cppAdModel, data);
  pinocchio::updateFramePlacements(cppAdModel, data);
  pinocchio::crba(cppAdModel, data, qPinocchio);

  ad_matrix_t jacobian = ad_matrix_t::Zero(6, model.nv), jacobianXyz = ad_matrix_t::Zero(3, model.nv);

  pinocchio::getFrameJacobian(cppAdModel, data, model.getBodyId("LF_LOOT"), pinocchio::LOCAL_WORLD_ALIGNED, jacobian);
  jacobianXyz = jacobian.topRows(3);
  std::cout << "here\n";
  pinocchio::impulseDynamics(cppAdModel, data, vPinocchio, jacobianXyz, ad_scalar_t(0.1), ad_scalar_t(0.0));
  ad_vector_t output = data.impulse_c; // impulseDynamics compute impulse and save it in data.impulse_c

  CppAD::ADFun<ad_base_t> fun(input, output);
  fun.optimize();

  // generates source code
  CppAD::cg::ModelCSourceGen<scalar_t> sourceGen(fun, "test");
  sourceGen.setCreateSparseJacobian(true);
  auto createJacobianSparsity = [&](CppAD::ADFun<ad_base_t>& fun){
    using SparsityPattern = std::vector<std::set<size_t>>;
    auto trueSparsity = CppAD::cg::jacobianSparsitySet<SparsityPattern>(fun);

    SparsityPattern jacobianSparsity(3);
    for (auto& sparsityRow : jacobianSparsity) {
      for (size_t i = 0; i < model.nq + model.nv; i++) {
        sparsityRow.insert(i);
      }
    }

    auto getIntersection = [&](const SparsityPattern& p0, const SparsityPattern& p1) {
      assert(p0.size() == p1.size());
      const auto numRows = p0.size();

      SparsityPattern result(p0.size());
      for (int row = 0; row < numRows; row++) {
        std::set_intersection(p0[row].begin(), p0[row].end(), p1[row].begin(), p1[row].end(), std::inserter(result[row], result[row].begin()));
      }
      return result;
    };
    return getIntersection(trueSparsity, jacobianSparsity);
  };
  sourceGen.setCustomSparseJacobianElements(createJacobianSparsity(fun));

  // Compiler objects, compile to temporary shared library file to avoid interference between processes
  CppAD::cg::ModelLibraryCSourceGen<scalar_t> libraryCSourceGen(sourceGen);
  CppAD::cg::GccCompiler<scalar_t> gccCompiler;
  CppAD::cg::DynamicModelLibraryProcessor<scalar_t> libraryProcessor(libraryCSourceGen, "/tmp/main/test");
  gccCompiler.setCompileLibFlags({"-O3", "-g", "-march=native", "-mtune=native", "-ffast-math"});
  gccCompiler.addCompileLibFlag("-shared");
  gccCompiler.addCompileLibFlag("-rdynamic");
  gccCompiler.setTemporaryFolder("/tmp/main");

  // Save sources
  gccCompiler.setSourcesFolder("/tmp/main");
  gccCompiler.setSaveToDiskFirst(true);

  auto dynamicLib_ = libraryProcessor.createDynamicLibrary(gccCompiler);
  auto model_ = dynamicLib_->model("test");

  return 0;
}

@jcarpent so any idea?

I don't understand; what do you mean here?

@jcarpent  i mean i provide a reproducible code above, and this run this code can reproduce my problem.
If you need more information or details, plz tell me.
Thanks again!

update: many be i should use no_compare_op?

Hello @Czworldy,
I have almost been able to reproduce your issue. My setup is not able to compile the last part of your program.
But If y comment the last part and build it in Debug mode, then, when I run the software, I see the following assert:
cppad-20230000.0 error from a known source:
A dependent variable value is not equal to its tape evaluation value,
perhaps it is nan.
Dependent variable value = nan
Tape evaluation value    = nan
Difference               = nan

Error detected by false result for
    0
at line 524 in the file
    $CONDA_PREFIX/include/cppad/core/fun_construct.hpp
a.out: $CONDA_PREFIX/include/cppad/utility/error_handler.hpp:206: static void CppAD::ErrorHandler::Default(bool, int, const char*, const char*, const char*): Assertion `false' failed.

This assert is raised from CppAD::ADFun<ad_base_t> fun(input, output);.
I'm not familiar with CppAD and can't help you right now, but I will try to have a look this week.

Hello @Czworldy,
I investigated a little more.
When running your code, the data.M matrix contains some nan. I don't really understand why, because when I'm running the same code with double as scalar type, the data.M matrix is then well computed (no nan inside).
I check this, because data.impulse_c is computed from data.M.
I replace anymal by solo and then the data.M matrix computed with CppAD::AD<ad_base_t> as scalar type is well computed.
But, the data.impulse_c still contains nan. By adding some damping in the pinocchio::impulseDynamics call, the nan disappear.
  pinocchio::impulseDynamics(cppAdModel, data, vPinocchio, jacobianXyz,
                             ad_scalar_t(0.1), ad_scalar_t(0.1));

I can't run the last part of the progarm. The createDynamicLibrary function is calling my compiler with some bad arguments…
I hope this will help you.

@jorisv
Thank for your help, i will add some damping and try again,
by the way, maybe the nan is caused by the floating base i add to it?
// add 6 DoF for the floating base
  // add 6 DoF for the floating base
  pinocchio::JointModelComposite jointComposite(2);
  jointComposite.addJoint(pinocchio::JointModelTranslation());
  jointComposite.addJoint(pinocchio::JointModelSphericalZYX());
  pinocchio::ModelTpl<scalar_t> model;
  pinocchio::urdf::buildModel(urdfTree, jointComposite, model); // the q of the model is 12+6=18

or
  // add 6 DoF for the floating base
  pinocchio::JointModelComposite jointComposite(2);
  pinocchio::ModelTpl<scalar_t> model;
  pinocchio::urdf::buildModel(urdfTree, pinocchio::JointModelFreeFlyer(), model);

@Czworldy, I tried with and without floating base and I still have nan. I think is more related to CPPAD, but I have to understand how this scalar type work to know why these nan appear…

@Czworldy, @jcarpent , @ManifoldFR
I have dug a little more about the nan.
They appear when calling Model::cast<ad_scalar_t>.
First nan is computed when adding the "universe" frame to the returned model.
A new inertia is computed with null mass because ::Eigen::NumTraits::epsilon() value is 0 for ad_scalar_t.
This issue is not visible, because the Model::frames are overwritted after.
But null division happen when casting Model::jointPlacements. The SE3Tpl::cast normalize the rotation matrix. The matrix is normalized if the epsilon of the new scalar type is inferior than the old one. Since epsilon is returning 0 for ad_scalar_t, we always enter in this condition.
The normalization then use a SVD that at some point divide by 0 (the SVD code call std::numeric_limits::min that also return 0…).
A lot of jointPlacements contains nan (but not all of them) for anymal C.
I don't know if we are already aware of this issue and if we know a workaround.

@Czworldy, Ok, the issue is well know and solve by adding the following header before all headers :
#include "pinocchio/codegen/cppadcg.hpp" // this file should be included first before all the others!

@Czworldy Did you try with the include ?

Closing this issues as there is no reply from @Czworldy


OLS-1015: Refactored runner.py, use types and proper logging

Description
Refactored runner.py, use types and proper logging
Type of change

[x] Refactor
[ ] New feature
[ ] Bug fix
[ ] CVE fix
[ ] Optimization
[ ] Documentation Update
[ ] Configuration Update
[ ] Bump-up dependent library
[ ] Bump-up library or tool used for development (does not change the final image)

Related Tickets & Documents

Related Issue #OLS-1015

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

Project coverage is 73.71%. Comparing base (3bc1fb5) to head (8dd79a7).
Report is 20 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #1578       +/-   ##
===========================================
- Coverage   94.83%   73.71%   -21.12%
===========================================
  Files          60       58        -2
  Lines        2671     2614       -57
===========================================
- Hits         2533     1927      -606
- Misses        138      687      +549

see 33 files with indirect coverage changes

/lgtm

/approve

/override "Red Hat Konflux / ols-enterprise-contract / lightspeed-service"


make a None or Null type

make a None or Null type

this feature was implemented
var name = null;
log(name);
name = "jack";
log(name);


Allow Gc and GcCell pointers to be reconstituted from raw pointers

This adds a from_raw method on the Gc and GcCell types to allow garbage-collected pointers to be round-tripped through raw pointers.  This is useful to allow these types to participate in e.g. pointer tagging and NaN boxing schemes.
This also fixes a soundness issue (detected by miri) regarding stacked borrows in Gc's as_ptr implementation.

WELL, I just merged #55 which adds this feature. I didn't actually realize it, but I guess there was already an open PR!
I am sorry I wasn't really active with the project at the time you opened your PR, I completely missed it. I even found the same stacked borrows issue that you did.
Closing as it is already implemented, I'm sorry I wasn't more responsive here.


Release 2.2.0 was not published

Summary
Jar for 2.2.0 release was having 2.1.0-jar and currently in confluent-hub we don`t have code changes made in 2.2.0 update

Hopefully fixed with the recent 2.3.x updates. Sorry about that!


request_serializer support for GET, DELETE and HEAD queries

request_serializer fields are added to the query params when the http request method is one of GET, DELETE or HEAD

I haven't tried this out yet, but is this not going to add query params for all GET queries, including the ones that don't actually need query params ? for e.g. a simple /resource/pk/ query which only uses the serializer for the response, will now add the serializer fields to query params in the docs ?
Maybe we need to add a yaml option to explicitly say if the serializer is to be used to generate query parameters ?

This PR works great, thank you!

@arshsingh Yes you are right. I have fixed it on my end. Will update the pull request soon.

Hey @swapnilsm thanks for this. This issue will go away in v2 / Django REST 3.4 as schema generation will be done by DRF. The new version will have breaking changes, so this feature may be valuable for existing projects. I'll probably make another release in the 0.x.x series before the v2 release.
It would be good to update so that query params are only added when explicitly requested.

@marcgibbons Great to know that. Sure I will add that flag. :)


Ordering various Pyscript script is unpredictable at cold boot

I need to read a state variable maintain by a Pyscript from another pyscript.
It works fine as long as I do not any cold boot.
I have tried to make an active wait by trying to watch the variable creation with:
state.names(domain=pyscript)
before creating the triggers but it blocks the boot process on pyscript initialisation.
A task.sleep(30) does not help either as it seems that initialisation of scripts is sequencial until a trigger call is reached.
How to overcome the issue of requiring the existence of a state variable before proceeding ?
A simple garanted startup order would do. Alphabetic, priority, ...

As you discovered, the load order isn't guaranteed, and each file is loaded sequentially so you can't introduce delays at the top level.
Inside HASS & HACS, the load order of integrations isn't guaranteed either.  So that's why pyscript doesn't arm any triggers until the EVENT_HOMEASSISTANT_STARTED event occurs.
There are various solutions you could consider.  For example, the script that sets the state variable can do so at load time (ie, not inside a function).  The script that watches it can do so via a @state_trigger and/or @time_trigger("startup").

Could be a good idea to make it clear in the documentation.
Thanks Dominig
Le 27 mars 2023 01:19:09 GMT+02:00, Craig Barratt @.***> a écrit :

As you discovered, the load order isn't guaranteed, and each file is loaded sequentially so you can't introduce delays at the top level.
Inside HASS & HACS, the load order of integrations isn't guaranteed either.  So that's why pyscript doesn't arm any triggers until the EVENT_HOMEASSISTANT_STARTED event occurs.
There are various solutions you could consider.  For example, the script that sets the state variable can do so at load time (ie, not inside a function).  The script that watches it can do so via a @.***_trigger and/or ***@***.***_trigger("startup").
--
Reply to this email directly or view it on GitHub:
https://github.com/custom-components/pyscript/issues/452#issuecomment-1484261908
You are receiving this because you authored the thread.
Message ID: @.***>


Replace 'optional' with 'proto2-optional' and 'singular' with 'proto3-optional'.

The term 'singular' could be used to refer to non-repeated fields. These
names make it clear which semantics are in use for a particular optional
field.

You have branch conflicts. Also I don't like this change. I like the :singular field as it conforms to the documentation, and the word optional is annoying and overloaded... Also it's weird to see proto2-optional in proto3.

You have branch conflicts. Also I don't like this change. I like the :singular field as it conforms to the documentation, and the word optional is annoying and overloaded... Also it's weird to see proto2-optional in proto3.

Posting this here as well: https://developers.google.com/protocol-buffers/docs/reference/cpp-generated
Sadly, it doesn't follow the documentation. The word "singular" is used as a synonym for "non-repeated".
Then again, this is documentation, not code. As for actual code: The C++ code handles this problem by having proto2 and proto3 singular fields share the label "optional". This is done for backwards compatibility reasons, which we don't have to worry about (?). For us, we can use separate labels for proto2 optional and proto3 optional fields. The only way to differentiate between these two is just proto2 vs proto3...

I was looking at our descriptor class hierarchy (or lack thereof) yesterday and thought of a different way to handle this. The base descriptor class could have the syntax slot, set to :proto2 or :proto3, hence all {file,field,message}-descriptor objects have easy access to the syntax.  Then we can continue to just use :optional as the field label but check the syntax when a distinction is necessary. WDYT?

I was looking at our descriptor class hierarchy (or lack thereof) yesterday and thought of a different way to handle this. The base descriptor class could have the syntax slot, set to :proto2 or :proto3, hence all {file,field,message}-descriptor objects have easy access to the syntax. Then we can continue to just use :optional as the field label but check the syntax when a distinction is necessary. WDYT?

Actually, we don't need to make that distinction at runtime at all. We only need to distinguish between proto2 & proto3 semantics at compile time (for creating the accessors and has-* functions). After that, both field types use the same interface for (de)serialization/text-format/json, thanks to Jon's changes.
So, I suggest that we use :optional for both, and don't even add a syntax slot.

SGTM

Closing this PR. I'll make a new one with the other change.


Workaround for PSSA v1.18 issue

Pull Request (PR) description
Implemented (temporary) workaround for 'PSDSCUseIdenticalMandatoryParametersForDSC' issue introduced in PSSA v1.18.
This Pull Request (PR) fixes the following issues
N/A

This change is

Codecov Report

Merging #1041 into dev will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##             dev   #1041   +/-   ##
=====================================
  Coverage     92%     92%
=====================================
  Files        118     118
  Lines      12232   12232
  Branches       1       1
=====================================
  Hits       11340   11340
  Misses       891     891
  Partials       1       1


Stupid Map Error Im Pissed

Is it really that big of a deal for the people who made this to go and fix it like come on!! I sick of all these errors and issues with this. Its soo annoying, And then they try and trick me to go in to session way which is risky and would rather do the email and password way. so idk Fix it!! lol

Your complaint is with GGG, if they proper supported 3rd party developers these kind of issues would not happen.

The new version of Procurement is out, which fixes this issue: https://github.com/Stickymaddness/Procurement/releases/tag/1.9.6
Unfortunately until GGG decide to support the dev community, these type of issues will continue to happen as it is out of our hands. http://i.imgur.com/yrPtajM.jpg

ty for the information, but when i made this complaint the new version wasn'y out yet i know you still have to wait for ggg, but was surprised that you didn't make the changes. but know that i see you did make the changes in 1.9.6 now we all just have to wait for ggg.


Support for Laravel 11 breaks support for Laravel 10.

Hello,
I am wondering why adding support to Laravel 11 had to "drop" laravel 10 from it's support.
Couldn't that have been in the form of "^10 || ^11"  allowing both versions as you already did with laravel/telescope previously ?

No, I can't remember off the top of my head, but I think I added some features that only work in Laravel 11.


Delay option to facilitate inspecting dropdown markup

Could we have a param (in milliseconds) to delay the moment of hiding the dropdown? This would facilitate styling esp when custom templates are being tested.
Currently the dropdown closes immediately a click occurs outside, including those within inspector.

What we do is to use this simple trick:
$('input.tt-input').val('query').trigger('input')

Being: input.tt-input the input field with typeahead and query the value you want to search by.
Doing it from the console, you can now easily inspect the DOM and play with the styles. Typeahead dropdown wont close even if you click anywhere in the app.
One gotcha: in order for this trick to work, you must run that statement with a different value every time. If the input contains: 'value' and you set val('value'), running that will show nothing.
You can give it a try here:
http://run.plnkr.co/1K5YGm2CpjmaB8s9/
Open console and run that command. This is good enough for us and we dont really need anything else.

Hi Jaime,
Thanks for a great tip! It deserves to be included on the web page.
Artur
On Sat, Feb 7, 2015 at 3:38 PM, Jaime Vega<EMAIL_ADDRESS>wrote:

What we do is to use this simple trick:
$('input.tt-input').val('query').trigger('input')
Being: input.tt-input the input field with typeahead and query the value
you want to search by.
Doing it from the console, you can now easily inspect the DOM and play
with the styles. Typeahead dropdown wont close even if you click anywhere
in the app.
One gotcha: in order for this trick to work, you must run that statement
with a different value every time. If the input contains: 'value' and you
set val('value'), running that will show nothing.
You can give it a try here:
http://run.plnkr.co/1K5YGm2CpjmaB8s9/
Open console and run that command. This is good enough for us and we dont
really need anything else.
—
Reply to this email directly or view it on GitHub
https://github.com/twitter/typeahead.js/issues/1086#issuecomment-73366619
.

Thanks. BTW I just noticed that the link to the plunkr was broken. I just fixed it


[WIP] Implemented starknet_getStorageAt

Implemented starknet_getStorageAt
Pull Request type

Please check the type of change your PR introduces:

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no API changes)
[ ] Build-related changes
[ ] Documentation content changes
[ ] Testing
[ ] Other (please describe):

What is the current behavior?

Issue Number: #362
What is the new behavior?

Does this introduce a breaking change?

[ ] Yes
[x] No

Other information

Hey man how is it going? Let's close the rpc asap.

Hey @phklive, I added the changes that are in the PR #371 to be able to implement the RPC endpoint without Helios errors. The RPC endpoint is functioning properly. However, I am getting an error in the "check" job. To merge this PR, the PR #371  where they update the Helios version must be merged first and all jobs must be executed without issues.

lgmt

Let's build 🚀


[bug] Duplicated users (non-merged) after calling init multiples times

Expected Behavior
Amplitude should not duplicate users.
I think it's related to the "device id" that is different in some situations that it may not be different.
My app, in some scenarios, for anonymous users (without userId defined), may run 3 events on the startup, even before the init function was called.
It works something like this:
onStartup() {
  analytics.track('OPEN_APP');
  analytics.track('SOME_OTHER_EVENT');
  analytics.track('GO_TO_MAIN_PAGE');
}

The problem there is that the analytics.track functions does:
let wasInited = false;

const init = async () => {
    await initAmplitude(apiKey).promise;
    wasInited = true;
};

const track = async (eventName) => {
  if (!wasInited) {
    await init();
  }

  trackEvent(eventName);
};

So, as you can see, if we call 3 times .track(), in will actually run 3 times the init function (because there is an await that will release the JS thread).
It seems like this scenario was working well with the old expo-analytics-aimplitude library (Amplitude-ReactNative).
If I did that thing, in the old library, those 3 inits will actually create the same user, and will actually track the 3 events in the same user.
Currently, it's creating 3 different users with 1 even on each of them.
Check this:

3 different users running those 3 events with LESS THAN 1 second of difference.
And, as I can tell you, those 3 events are run always one after the other one.
These are the resulting users:

As you can see, it's the same user IN THE APP, but different users on Amplitude.
It first create 1 user with 1 even, then 1 other user with the second event, and finally, the 3rd user with the last of the 3 events and ALSO all the remaining events that comes AFTER. As in:
Events of user 1:

Events of user 2:

Events of user 3:

It clearly should merge those users. But the device ID seems to be different.
This is resulting in a huge increment of new users, which actually then don't exists. Those 3 users were actually only 1.

Current Behavior
Not merging users
Possible Solution
Maybe merging the users? Maybe something related to the different DeviceID?
Steps to Reproduce
Check the code I added on the top.
It should be just:
1. Run 3 events on startup.
2. Inside the `track` function, call the `init`.
3. The `init` is going to create 3 different users, but whould have been only 1.

I insist that this was working well before. I have been using Amplitude since 3 years ago.
Environment

JS SDK Version: Expo SDK 46
Installation Method: Yarn (expo install)
Browser and Version: Actually happening in the device.

The workaround for this issue will be to only call init 1 time.
I'm implementing this... But... I want to repeat that this issue was not present in the old library.

Hi @BrodaNoel, thanks for choosing Amplitude. My best guess is that all the init calls race up to find and create their own device IDs hence seeing different device IDs. init sets up the SDK and performs read/writes to storage APIs to persist user session which include multiple async operations. Due to this, this SDK supports deferred initialization wherein you can send track() calls before or after init() calls.
In the meantime, I would suggest to avoid calling init() in parallel. We do support calling init() in sequence for cases you need to re-initialize with new configuration.
let wasInited = false;

const init = () => {
  wasInited = true; // block future init immediately
  amplitude.init(apiKey);
};

const track = (eventName) => {
  if (!wasInited) {
    init(); // no need to await
  }

  amplitude.track(eventName); // can be called with or without init completing
};

Let me know if you need further support on this. On our end, we can block parallel executions of init, and re-allow when no init is pending state.

@kevinpagtakhan thanks for the answer.
I already fixed the issue in my end. Now I just run init on the startup, and I guess it should be all.
I reported this mainly because I am 100% sure this "bug" was not there in the old library. It was clearly creating the same DeviceId even if you call the init 10 times in a row, in parallel (and maybe you want to keep it in the same way, in order to create a retro-compatibility).
Feel free to close this issue if you consider no work is needed in your side.

Hi, @BrodaNoel , thanks for reporting this! This lib is totally new and still in beta, so there might be some bugs. Also the behaviors might be different from the Expo one. We are working on the fix right now, thank you for supporting us and reporting these issues!
@kevinpagtakhan , thanks for the information!
As @kevinpagtakhan mentioned, now we support calling track before init, the events will be stored and fired after API key is fed with init. Closing this now.


fix issue #36

The fix makes sure that callbacks are queued while executing the queue.
See also issue #36
There is still a case which is not working:
If the watch callback is changing a value which should trigger this watch on the initial call it will not be called again because the callback can not be added before the initial call.
I added a test do validate and show the workaround.

Hey! Great work @jukart, this sounds like a pretty solid solution (no pun intended). I'll review it in more depth soon to confirm.

One thing I just realized is the nextTick handling.
nextTick is immediately resolving if there is nothing in the queueStack.
With this change it is now possible that nextTick is immediately resolved while the current queueStack is executed.
If this is an issue this should be changed to queue nextTick calls while executing the queueStack.

@justin-schroeder any progress on the review?

Seems good to me. Thanks!


[SMALLFIX]Add javadoc for the function createStandbyFileSystemMasterFromJournal() in MasterTestUtils.java

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/13368/
Test PASSed.

LGTM. thanks for the improvement!


[MAID-2670] chore/ci: update ci scripts to latest rust and rustfmt

r? @Fraser999
(maidsafe_highfive has picked a reviewer for you, use r? to override)


Allow quiet mode for tests

We should allow the user to set an env var to quiet Logplexer for testing errors in rspec.

Fixed in PR 4


Functions window: stack size

Is your feature request related to a problem? Please describe.
Could the functions window have a column for stack frame size?
Describe the solution you'd like
New optional column that lists the function's stack size.  Is this always know or easy to access with a quick lookup that this window would need (Would an undefined value be common until maybe prototype committed?)?
Describe alternatives you've considered
Not aware of ways to quickly access this
Additional context
Add any other context or screenshots about the feature request here.

Is this specifically StackFrame.getLocalSize() that you are hoping to see?  This is computed based upon the define local variables that utilize the stack.

Yeah, sorry if that wasn't clear.  Just wondering if that value could be in a column in the Functions window.  Like if viewing the function stack editor, the 'Local Size' or 'Frame Size'.  My interest would be sorting by amount of local stack variables.
But I understand if that would be too expensive to compute in that table


Split up archive.go into type-specific files; add wider zlib support

This PR splits up all of the archive-specific functions in archive.go into their own respective files for readability.
As part of this, I also added extension-agnostic zlib support depending on whether the file returns &{.Z, application/zlib} from programkind.File.
I also fixed a panic:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xd648e6]

goroutine 19400 [running]:
github.com/chainguard-dev/malcontent/pkg/action.extractGzip({0x2b5ce48?, 0xc0000ff6b0?}, {0xc001d680c0, 0x39}, {0xc0009b8240, 0x85})
	github.com/chainguard-dev/malcontent@v1.7.0/pkg/action/archive.go:249 +0x2c6
github.com/chainguard-dev/malcontent/pkg/action.extractArchiveToTempDir({0x2b5ce48, 0xc0000ff6b0}, {0xc0009b8240, 0x85})
	github.com/chainguard-dev/malcontent@v1.7.0/pkg/action/archive.go:653 +0x383
github.com/chainguard-dev/malcontent/pkg/action.processArchive({0x2b5ce48, 0xc0000ff6b0}, {0x8, 0x0, 0x0, 0x0, 0x0, 0x1, {0x0, 0x0, ...}, ...}, ...)
	github.com/chainguard-dev/malcontent@v1.7.0/pkg/action/scan.go:496 +0x134
github.com/chainguard-dev/malcontent/pkg/action.recursiveScan.func1({0xc0009b8240, 0x85})
	github.com/chainguard-dev/malcontent@v1.7.0/pkg/action/scan.go:328 +0xd0
github.com/chainguard-dev/malcontent/pkg/action.recursiveScan.func4()
	github.com/chainguard-dev/malcontent@v1.7.0/pkg/action/scan.go:436 +0xa2
golang.org/x/sync/errgroup.(*Group).Go.func1()
	golang.org/x/sync@v0.10.0/errgroup/errgroup.go:78 +0x50
created by golang.org/x/sync/errgroup.(*Group).Go in goroutine 19398
	golang.org/x/sync@v0.10.0/errgroup/errgroup.go:75 +0x96

This was happening because we were trying to print ft.Ext debug logs for files that returned nil from programkind.File.

It looks good; what do you think about moving this out of action and into an archive package? It feels like archive handling has grown up into its own feature at this point.

It looks good; what do you think about moving this out of action and into an archive package? It feels like archive handling has grown up into its own feature at this point.

I ran into some circular imports earlier but I can give it a try.

It looks good; what do you think about moving this out of action and into an archive package? It feels like archive handling has grown up into its own feature at this point.

Updated in 43b922d (#723).
I left archive_test.go in action since it uses Scan and CachedRules. I also moved the extension and archive map code to programkind since that seemed like a better fit.


Update set-password-to-never-expire.md

Removed the note about the cloud only accounts can have a password expiration policy as synchronized users can have password expiration policies setup on Azure
Reference:- https://dorcs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-password-hash-synchronization#enforcecloudpasswordpolicyforpasswordsyncedusers

@JohanFreelancer9 Please copy review

Issue#https://github.com/MicrosoftDocs/microsoft-365-docs/issues/5439

@msbemba


Use consistent top margin on pages

The margin was really big by default. We discussed that we would
like to reduce it a bit.

Current dependencies on/for this PR:

main

PR #475

PR #476   👈

PR #477

This comment was auto-generated by Graphite.

Merge Activity

Oct 2, 7:19 AM: @k-nut started a stack merge that includes this pull request via Graphite.


[docs] Fix typo in reporter example

Summary
Fix unexpected comma

Test plan
None

Codecov Report

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

@@           Coverage Diff           @@
##           master    #3671   +/-   ##
=======================================
  Coverage   62.57%   62.57%
=======================================
  Files         181      181
  Lines        6694     6694
  Branches        6        6
=======================================
  Hits         4189     4189
  Misses       2502     2502
  Partials        3        3

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 0f2107f...49bbbd9. Read the comment docs.


trouble with dollar

cssnano#30

Is this a bug with css-list? I am not transforming those values:
https://github.com/ben-eb/postcss-normalize-url/blob/master/index.js#L37-L45

Will look at this.


star already!help pls

Welcome to TheHudek's FandomVideoGenerator
Traceback (most recent call last):
File "\FandomVideoGenerator-master\main.py", line 10, in
n, length, number_of_comments, final_images = text_to_mp3()
File "\FandomVideoGenerator-master\voices.py", line 20, in text_to_mp3
n, final_images = get_pictures()
File "\FandomVideoGenerator-master\fanobject.py", line 56, in get_pictures
fanobject_chosen = fandom.page(title=os.getenv("PROMPT"))
File "C:\Users\XXXX\AppData\Local\Programs\Python\Python38\lib\site-packages\fandom\fandom.py", line 215, in page
return FandomPage(wiki, language, title=title, redirect=redirect, preload=preload)
File "C:\Users\XXXX\AppData\Local\Programs\Python\Python38\lib\site-packages\fandom\FandomPage.py", line 39, in init
self.__load(redirect=redirect, preload=preload)
File "C:\Users\XXXX\AppData\Local\Programs\Python\Python38\lib\site-packages\fandom\FandomPage.py", line 77, in __load
request = _wiki_request(query_params)
File "C:\Users\XXXX\AppData\Local\Programs\Python\Python38\lib\site-packages\fandom\util.py", line 86, in _wiki_request
raise RequestError(api_url, params)
fandom.error.RequestError: Your request to the url "https://daenerys_targaryen.fandom.com/en/api.php" with the paramaters "{'action': 'query', 'redirects': True, 'titles': '$P$G', 'format': 'json'}" either returned nothing or returned data in a format other than JSON. Please check your input data.

What’s your .env? I suspect you had daenerys_targaryen in the WIKI section.


Some sizeOf methods aren't exposed publicly from ProtoWriterTools

Several sizeOfXYZ() methods are not public in ProtoWriterTools. For example:

sizeOfTag()
sizeOfVarInt32()
sizeOfUnsignedVarInt32()
etc.

I don't know why other methods are public, but these aren't. My guess is these methods are too low level and aren't expected to be used by 3rd-party code. For example, to get size of an integer, they should always use sizeOfInteger(), which internally calls these private methods.
However, in MerkleDb PBJ code I do need at least sizeOfTag(), since MerkleDb writes and reads field tags manually, not using codecs. Also, sizeOfInteger() has valid optimization of skipping default int values (i.e. zero), but in case of MerkleDb it's sometimes helpful to write default values, too, to make file structure a little bit more regular (still protobuf compatible).

It looks like there are some utility methods in CodecOutputStream, but this is a class from com.google.protobuf, which isn't directly used by MerkleDb.

Make the methods above public...

Methods currently copied from PBJ repo to MerkleDb PBJ branch:

sizeOfTag(field, wireType) - copied from ProtoWriterTools
sizeOfVarInt32(value) - from ProtoWriterTools
sizeOfUnsignedVarInt32(value) - from ProtoWriterTools
sizeOfVarInt64(value)
sizeOfUnsignedVarInt64(value)
sizeOfDelimited(field, length) - copied from ProtoWriterTools

One more method is not related to sizes, but also copied:

writeTag(writeableSeqOut, field)

It would also be great to have a public method to read the next tag / field number from a buffer/stream. Today I do it by hand in several places:
            final int tag = in.readVarInt(false);
            final int number = tag >> TAG_FIELD_OFFSET;