[Bug Report]: Containers may not drop/give contents when broken with Telepathy enchantment

Spark link
No response
Server Version
1.20.2
Server Platform
Paper
Describe the bug
Some combinations of blocks holding inventories and tools with Telepathy cause items in the blocks' inventory to vanish.
Breaking a jukebox, lectern, barrel, or chiseled bookshelf with a pickaxe, axe, hoe, or shovel does not drop nor give the player the contents of the container.
Breaking a brewing stand, dispenser, hopper, smoker, dropper, blast furnace, or furnace with a pickaxe also does not drop nor give the player the items inside.
Steps to reproduce

Break a block containing items (except a chest and shulker box) with a tool having Telepathy enchantment.
You would obtain the block, but the content would disappear.

Additional context
No response
Agreements

[X] I have searched for and ensured there isn't already an open issue regarding this.
[ ] I ticked all the boxes without actually reading them
[X] My version of Minecraft is supported by CrazyCrew.

The plugin version is 2.1.2. (I guess I should have provided this information as the additional context; sorry)
I tried the build, and it worked fine! When I break a container with a Telepathy tool, I get the content in my inventory.
Thank you.


More gradient color scales

I like the Greens and Greys scales - but could you add more gradient color scales lige eg. Blues and Reds ?

It has the plotly bluered scale:

I just added all the scales:Greys,YlGnBu,Greens,YlOrRd,Bluered,RdBu,Reds,Blues,Picnic,Rainbow,Portland,Jet,Hot,Blackbody,Earth,Electric,Viridis,Cividis.


fix pageDownstream kill propagation

follow up of https://github.com/crate/crate/commit/7ddec91a0b7b904f293834612cf50fa24fd9c515

@mfussenegger pls review


Errors installing on MacOSX Sierra, Cuda 9,

OS: MacOSX 10.12.6
clang --version Apple LLVM version 8.1.0 (clang-802.0.42)
Xcode: 8.3.1
Cuda 9.0.103
hardware: a Pascal GPU
I read #797  and I tried also: export TORCH_NVCC_FLAGS="-D__CUDA_NO_HALF_OPERATORS__"
Excerpt from output:
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCTensorRandom.cuh(156): error: specified alignment (4) is different from alignment (2) specified on a previous declaration
detected during instantiation of "void sampleMultinomialOnce<T,AccT>(long *, long, int, T *, T *) [with T=float, AccT=float]"
output for luarocks install cutorch :
Installing https://raw.githubusercontent.com/torch/rocks/master/cutorch-scm-1.rockspec...
Using https://raw.githubusercontent.com/torch/rocks/master/cutorch-scm-1.rockspec... switching to 'build' mode
Cloning into 'cutorch'...
remote: Counting objects: 229, done.
remote: Compressing objects: 100% (183/183), done.
remote: Total 229 (delta 63), reused 89 (delta 44), pack-reused 0
Receiving objects: 100% (229/229), 241.67 KiB | 0 bytes/s, done.
Resolving deltas: 100% (63/63), done.
Warning: unmatched variable LUALIB
jopts=$(getconf _NPROCESSORS_CONF)
echo "Building on $jopts cores"
cmake -E make_directory build && cd build && cmake .. -DLUALIB= -DLUA_INCDIR=/Users/user/torch/install/include -DCMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS} -DCMAKE_BUILD_TYPE=Release -DCMAKE_PREFIX_PATH="/Users/user/torch/install/bin/.." -DCMAKE_INSTALL_PREFIX="/Users/user/torch/install/lib/luarocks/rocks/cutorch/scm-1" && make -j$jopts install
Building on 4 cores
-- The C compiler identification is AppleClang <IP_ADDRESS>20042
-- The CXX compiler identification is AppleClang <IP_ADDRESS>20042
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++
-- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Torch7 in /Users/user/torch/install
-- Found CUDA: /Developer/NVIDIA/CUDA-9.0 (found suitable version "9.0", minimum required is "6.5")
-- Removing -DNDEBUG from compile flags
-- TH_LIBRARIES: TH
-- MAGMA not found. Compiling without MAGMA support
-- Autodetected CUDA architecture(s): 6.1
-- got cuda version 9.0
-- Found CUDA with FP16 support, compiling with torch.CudaHalfTensor
-- CUDA_NVCC_FLAGS: -D__CUDA_NO_HALF_OPERATORS__;-gencode;arch=compute_61,code=sm_61;-DCUDA_HAS_FP16=1
-- THC_SO_VERSION: 0
-- Performing Test HAS_LUAL_SETFUNCS
-- Performing Test HAS_LUAL_SETFUNCS - Failed
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/luarocks_cutorch-scm-1-4066/cutorch/build
[  3%] Building NVCC (Device) object lib/THC/CMakeFiles/THC.dir/THC_generated_THCHalf.cu.o
[  3%] Building NVCC (Device) object lib/THC/CMakeFiles/THC.dir/THC_generated_THCReduceApplyUtils.cu.o
[  3%] Building NVCC (Device) object lib/THC/CMakeFiles/THC.dir/THC_generated_THCSleep.cu.o
[  4%] Building NVCC (Device) object lib/THC/CMakeFiles/THC.dir/THC_generated_THCBlas.cu.o
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCHalf.h:24:17: warning: 'THC_float2half' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THC_float2half(float a);
^
[  5%] Building NVCC (Device) object lib/THC/CMakeFiles/THC.dir/THC_generated_THCStorage.cu.o
1 warning generated.
[  6%] Building NVCC (Device) object lib/THC/CMakeFiles/THC.dir/THC_generated_THCStorageCopy.cu.o
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCHalf.h:24:17: warning: 'THC_float2half' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THC_float2half(float a);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCStorage.h:28:17: warning: 'THCudaHalfStorage_get' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfStorage_get(THCState * state, const THCudaHalfStorage *, ptrdiff_t);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:127:17: warning: 'THCudaHalfTensor_get1d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get1d(THCState * state, const THCudaHalfTensor * tensor, long x0);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:128:17: warning: 'THCudaHalfTensor_get2d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get2d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:129:17: warning: 'THCudaHalfTensor_get3d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get3d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:130:17: warning: 'THCudaHalfTensor_get4d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get4d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2, long x3);
^
6 warnings generated.
[  7%] Building NVCC (Device) object lib/THC/CMakeFiles/THC.dir/THC_generated_THCTensor.cu.o
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCHalf.h:24:17: warning: 'THC_float2half' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THC_float2half(float a);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCStorage.h:28:17: warning: 'THCudaHalfStorage_get' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfStorage_get(THCState * state, const THCudaHalfStorage *, ptrdiff_t);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:127:17: warning: 'THCudaHalfTensor_get1d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get1d(THCState * state, const THCudaHalfTensor * tensor, long x0);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:128:17: warning: 'THCudaHalfTensor_get2d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get2d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:129:17: warning: 'THCudaHalfTensor_get3d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get3d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:130:17: warning: 'THCudaHalfTensor_get4d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get4d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2, long x3);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCHalf.h:24:17: warning: 'THC_float2half' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THC_float2half(float a);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCStorage.h:28:17: warning: 'THCudaHalfStorage_get' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfStorage_get(THCState * state, const THCudaHalfStorage *, ptrdiff_t);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:127:17: warning: 'THCudaHalfTensor_get1d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get1d(THCState * state, const THCudaHalfTensor * tensor, long x0);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:128:17: warning: 'THCudaHalfTensor_get2d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get2d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:129:17: warning: 'THCudaHalfTensor_get3d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get3d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:130:17: warning: 'THCudaHalfTensor_get4d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get4d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2, long x3);
^
6 warnings generated.
[  8%] Building NVCC (Device) object lib/THC/CMakeFiles/THC.dir/THC_generated_THCTensorCopy.cu.o
6 warnings generated.
[ 10%] Building NVCC (Device) object lib/THC/CMakeFiles/THC.dir/THC_generated_THCTensorMath.cu.o
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCHalf.h:24:17: warning: 'THC_float2half' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THC_float2half(float a);
^
1 warning generated.
[ 11%] Building NVCC (Device) object lib/THC/CMakeFiles/THC.dir/THC_generated_THCTensorMath2.cu.o
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCHalf.h:24:17: warning: 'THC_float2half' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THC_float2half(float a);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCStorage.h:28:17: warning: 'THCudaHalfStorage_get' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfStorage_get(THCState * state, const THCudaHalfStorage *, ptrdiff_t);
^
2 warnings generated.
[ 12%] Building NVCC (Device) object lib/THC/CMakeFiles/THC.dir/THC_generated_THCTensorMathBlas.cu.o
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCHalf.h:24:17: warning: 'THC_float2half' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THC_float2half(float a);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCStorage.h:28:17: warning: 'THCudaHalfStorage_get' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfStorage_get(THCState * state, const THCudaHalfStorage *, ptrdiff_t);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:127:17: warning: 'THCudaHalfTensor_get1d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get1d(THCState * state, const THCudaHalfTensor * tensor, long x0);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:128:17: warning: 'THCudaHalfTensor_get2d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get2d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:129:17: warning: 'THCudaHalfTensor_get3d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get3d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:130:17: warning: 'THCudaHalfTensor_get4d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get4d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2, long x3);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:35:17: warning: 'THCudaHalfTensor_minall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_minall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:36:17: warning: 'THCudaHalfTensor_maxall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_maxall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:37:17: warning: 'THCudaHalfTensor_medianall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_medianall(THCState * state, THCudaHalfTensor * self);
^
9 warnings generated.
[ 13%] Building NVCC (Device) object lib/THC/CMakeFiles/THC.dir/THC_generated_THCTensorMathMagma.cu.o
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCHalf.h:24:17: warning: 'THC_float2half' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THC_float2half(float a);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCStorage.h:28:17: warning: 'THCudaHalfStorage_get' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfStorage_get(THCState * state, const THCudaHalfStorage *, ptrdiff_t);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:127:17: warning: 'THCudaHalfTensor_get1d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get1d(THCState * state, const THCudaHalfTensor * tensor, long x0);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:128:17: warning: 'THCudaHalfTensor_get2d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get2d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:129:17: warning: 'THCudaHalfTensor_get3d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get3d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:130:17: warning: 'THCudaHalfTensor_get4d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get4d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2, long x3);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:35:17: warning: 'THCudaHalfTensor_minall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_minall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:36:17: warning: 'THCudaHalfTensor_maxall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_maxall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:37:17: warning: 'THCudaHalfTensor_medianall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_medianall(THCState * state, THCudaHalfTensor * self);
^
9 warnings generated.
[ 14%] Building NVCC (Device) object lib/THC/CMakeFiles/THC.dir/THC_generated_THCTensorMathPairwise.cu.o
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCHalf.h:24:17: warning: 'THC_float2half' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THC_float2half(float a);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCStorage.h:28:17: warning: 'THCudaHalfStorage_get' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfStorage_get(THCState * state, const THCudaHalfStorage *, ptrdiff_t);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:127:17: warning: 'THCudaHalfTensor_get1d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get1d(THCState * state, const THCudaHalfTensor * tensor, long x0);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:128:17: warning: 'THCudaHalfTensor_get2d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get2d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:129:17: warning: 'THCudaHalfTensor_get3d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get3d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:130:17: warning: 'THCudaHalfTensor_get4d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get4d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2, long x3);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:35:17: warning: 'THCudaHalfTensor_minall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_minall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:36:17: warning: 'THCudaHalfTensor_maxall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_maxall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:37:17: warning: 'THCudaHalfTensor_medianall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_medianall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCHalf.h:24:17: warning: 'THC_float2half' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THC_float2half(float a);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCStorage.h:28:17: warning: 'THCudaHalfStorage_get' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfStorage_get(THCState * state, const THCudaHalfStorage *, ptrdiff_t);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:127:17: warning: 'THCudaHalfTensor_get1d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get1d(THCState * state, const THCudaHalfTensor * tensor, long x0);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:128:17: warning: 'THCudaHalfTensor_get2d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get2d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:129:17: warning: 'THCudaHalfTensor_get3d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get3d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:130:17: warning: 'THCudaHalfTensor_get4d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get4d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2, long x3);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:35:17: warning: 'THCudaHalfTensor_minall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_minall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:36:17: warning: 'THCudaHalfTensor_maxall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_maxall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:37:17: warning: 'THCudaHalfTensor_medianall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_medianall(THCState * state, THCudaHalfTensor * self);
^
9 warnings generated.
[ 15%] Building NVCC (Device) object lib/THC/CMakeFiles/THC.dir/THC_generated_THCTensorMathReduce.cu.o
9 warnings generated.
[ 16%] Building NVCC (Device) object lib/THC/CMakeFiles/THC.dir/THC_generated_THCTensorMathScan.cu.o
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCHalf.h:24:17: warning: 'THC_float2half' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THC_float2half(float a);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCStorage.h:28:17: warning: 'THCudaHalfStorage_get' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfStorage_get(THCState * state, const THCudaHalfStorage *, ptrdiff_t);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:127:17: warning: 'THCudaHalfTensor_get1d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get1d(THCState * state, const THCudaHalfTensor * tensor, long x0);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:128:17: warning: 'THCudaHalfTensor_get2d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get2d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:129:17: warning: 'THCudaHalfTensor_get3d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get3d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:130:17: warning: 'THCudaHalfTensor_get4d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get4d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2, long x3);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:35:17: warning: 'THCudaHalfTensor_minall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_minall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:36:17: warning: 'THCudaHalfTensor_maxall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_maxall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:37:17: warning: 'THCudaHalfTensor_medianall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_medianall(THCState * state, THCudaHalfTensor * self);
^
9 warnings generated.
[ 17%] Building NVCC (Device) object lib/THC/CMakeFiles/THC.dir/THC_generated_THCTensorIndex.cu.o
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCHalf.h:24:17: warning: 'THC_float2half' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THC_float2half(float a);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCStorage.h:28:17: warning: 'THCudaHalfStorage_get' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfStorage_get(THCState * state, const THCudaHalfStorage *, ptrdiff_t);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:127:17: warning: 'THCudaHalfTensor_get1d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get1d(THCState * state, const THCudaHalfTensor * tensor, long x0);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:128:17: warning: 'THCudaHalfTensor_get2d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get2d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:129:17: warning: 'THCudaHalfTensor_get3d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get3d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:130:17: warning: 'THCudaHalfTensor_get4d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get4d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2, long x3);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCHalf.h:24:17: warning: 'THC_float2half' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THC_float2half(float a);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCStorage.h:28:17: warning: 'THCudaHalfStorage_get' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfStorage_get(THCState * state, const THCudaHalfStorage *, ptrdiff_t);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:127:17: warning: 'THCudaHalfTensor_get1d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get1d(THCState * state, const THCudaHalfTensor * tensor, long x0);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:128:17: warning: 'THCudaHalfTensor_get2d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get2d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:129:17: warning: 'THCudaHalfTensor_get3d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get3d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:130:17: warning: 'THCudaHalfTensor_get4d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get4d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2, long x3);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:35:17: warning: 'THCudaHalfTensor_minall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_minall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:36:17: warning: 'THCudaHalfTensor_maxall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_maxall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:37:17: warning: 'THCudaHalfTensor_medianall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_medianall(THCState * state, THCudaHalfTensor * self);
^
9 warnings generated.
[ 18%] Building NVCC (Device) object lib/THC/CMakeFiles/THC.dir/THC_generated_THCTensorConv.cu.o
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCHalf.h:24:17: warning: 'THC_float2half' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THC_float2half(float a);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCStorage.h:28:17: warning: 'THCudaHalfStorage_get' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfStorage_get(THCState * state, const THCudaHalfStorage *, ptrdiff_t);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:127:17: warning: 'THCudaHalfTensor_get1d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get1d(THCState * state, const THCudaHalfTensor * tensor, long x0);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:128:17: warning: 'THCudaHalfTensor_get2d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get2d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:129:17: warning: 'THCudaHalfTensor_get3d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get3d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:130:17: warning: 'THCudaHalfTensor_get4d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get4d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2, long x3);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:35:17: warning: 'THCudaHalfTensor_minall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_minall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:36:17: warning: 'THCudaHalfTensor_maxall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_maxall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:37:17: warning: 'THCudaHalfTensor_medianall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_medianall(THCState * state, THCudaHalfTensor * self);
^
6 warnings generated.
[ 20%] Building NVCC (Device) object lib/THC/CMakeFiles/THC.dir/THC_generated_THCTensorRandom.cu.o
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCHalf.h:24:17: warning: 'THC_float2half' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THC_float2half(float a);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCStorage.h:28:17: warning: 'THCudaHalfStorage_get' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfStorage_get(THCState * state, const THCudaHalfStorage *, ptrdiff_t);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:127:17: warning: 'THCudaHalfTensor_get1d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get1d(THCState * state, const THCudaHalfTensor * tensor, long x0);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:128:17: warning: 'THCudaHalfTensor_get2d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get2d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:129:17: warning: 'THCudaHalfTensor_get3d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get3d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:130:17: warning: 'THCudaHalfTensor_get4d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get4d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2, long x3);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:35:17: warning: 'THCudaHalfTensor_minall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_minall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:36:17: warning: 'THCudaHalfTensor_maxall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_maxall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:37:17: warning: 'THCudaHalfTensor_medianall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_medianall(THCState * state, THCudaHalfTensor * self);
^
9 warnings generated.
[ 21%] Building NVCC (Device) object lib/THC/CMakeFiles/THC.dir/THC_generated_THCTensorScatterGather.cu.o
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCTensorRandom.cuh(156): error: specified alignment (4) is different from alignment (2) specified on a previous declaration
detected during instantiation of "void sampleMultinomialOnce<T,AccT>(long *, long, int, T *, T *) [with T=half, AccT=float]"
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorRandom.cu(191): here
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCTensorRandom.cuh(95): error: specified alignment (4) is different from alignment (2) specified on a previous declaration
detected during instantiation of "void renormRowsL1(T *, long, long) [with T=float]"
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorRandom.cu(120): here
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCTensorRandom.cuh(156): error: specified alignment (4) is different from alignment (2) specified on a previous declaration
detected during instantiation of "void sampleMultinomialOnce<T,AccT>(long *, long, int, T *, T *) [with T=float, AccT=float]"
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorRandom.cu(191): here
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCTensorRandom.cuh(95): error: specified alignment (8) is different from alignment (2) specified on a previous declaration
detected during instantiation of "void renormRowsL1(T *, long, long) [with T=double]"
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorRandom.cu(120): here
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCTensorRandom.cuh(156): error: specified alignment (8) is different from alignment (2) specified on a previous declaration
detected during instantiation of "void sampleMultinomialOnce<T,AccT>(long *, long, int, T *, T *) [with T=double, AccT=double]"
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorRandom.cu(191): here
5 errors detected in the compilation of "/var/folders/bk/h0__6hp95zd6hsdn1h4jxb_c0000gn/T//tmpxft_000009ec_00000000-6_THCTensorRandom.cpp1.ii".
CMake Error at THC_generated_THCTensorRandom.cu.o.cmake:267 (message):
Error generating file
/tmp/luarocks_cutorch-scm-1-4066/cutorch/build/lib/THC/CMakeFiles/THC.dir//./THC_generated_THCTensorRandom.cu.o
make[2]: *** [lib/THC/CMakeFiles/THC.dir/THC_generated_THCTensorRandom.cu.o] Error 1
make[2]: *** Waiting for unfinished jobs....
9 warnings generated.
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCHalf.h:24:17: warning: 'THC_float2half' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THC_float2half(float a);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCStorage.h:28:17: warning: 'THCudaHalfStorage_get' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfStorage_get(THCState * state, const THCudaHalfStorage *, ptrdiff_t);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:127:17: warning: 'THCudaHalfTensor_get1d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get1d(THCState * state, const THCudaHalfTensor * tensor, long x0);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:128:17: warning: 'THCudaHalfTensor_get2d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get2d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:129:17: warning: 'THCudaHalfTensor_get3d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get3d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:130:17: warning: 'THCudaHalfTensor_get4d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get4d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2, long x3);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:35:17: warning: 'THCudaHalfTensor_minall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_minall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:36:17: warning: 'THCudaHalfTensor_maxall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_maxall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:37:17: warning: 'THCudaHalfTensor_medianall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_medianall(THCState * state, THCudaHalfTensor * self);
^
9 warnings generated.
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/THCHalf.h:24:17: warning: 'THC_float2half' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THC_float2half(float a);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCStorage.h:28:17: warning: 'THCudaHalfStorage_get' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfStorage_get(THCState * state, const THCudaHalfStorage *, ptrdiff_t);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:127:17: warning: 'THCudaHalfTensor_get1d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get1d(THCState * state, const THCudaHalfTensor * tensor, long x0);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:128:17: warning: 'THCudaHalfTensor_get2d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get2d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:129:17: warning: 'THCudaHalfTensor_get3d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get3d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensor.h:130:17: warning: 'THCudaHalfTensor_get4d' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_get4d(THCState * state, const THCudaHalfTensor * tensor, long x0, long x1, long x2, long x3);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:35:17: warning: 'THCudaHalfTensor_minall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_minall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:36:17: warning: 'THCudaHalfTensor_maxall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_maxall(THCState * state, THCudaHalfTensor * self);
^
/tmp/luarocks_cutorch-scm-1-4066/cutorch/lib/THC/generic/THCTensorMathReduce.h:37:17: warning: 'THCudaHalfTensor_medianall' has C-linkage specified, but returns user-defined type 'half' (aka '__half') which is incompatible with C [-Wreturn-type-c-linkage]
extern "C" half THCudaHalfTensor_medianall(THCState * state, THCudaHalfTensor * self);
^
9 warnings generated.
make[1]: *** [lib/THC/CMakeFiles/THC.dir/all] Error 2
make: *** [all] Error 2
Error: Build error: Failed building.

I got the same errs while reinstalling torch on a new machine. Seems torch7 works with cuda 7.5/8 only. You can download the local install package from
https://developer.nvidia.com/cuda-toolkit-archive

I get the same error with cuda 8 :/
did you eventually fix it?

I gave up. Will try again in couple of months when I return to DeepL.

Seems P100 GPU does not support CUDA version < 9 while torch does not support CUDA 9. So it's definitely an issue.
Interestingly I tried PyTorch with cuda version 9 and it works...


[Bugfix] Fix the default value for temperature in ChatCompletionRequest

FIX #10930
Set the default value for temperature in ChatCompletionRequest to 1.0.
References:
https://github.com/vllm-project/vllm/blob/571da8fc431ec36427ee1034a7779b23229b015e/vllm/sampling_params.py#L176
https://platform.openai.com/docs/api-reference/chat

This modifies the default behavior of the vLLM OpenAI Compatible Server. Considering that temperature is a field that is very likely to be customized by users, I believe the impact is minimal.

Some tests failed, and it doesn’t seem to be caused by my PR. @simon-mo

Out of curiosity, why was this change made? 0.7 has been the default temperature for a long time, and changing from 0.7 to 1 is not a small difference in terms of behavior, and in particular it may impact the quality of tool calls using auto tool choice without a temperature manually specified

Out of curiosity, why was this change made? 0.7 has been the default temperature for a long time, and changing from 0.7 to 1 is not a small difference in terms of behavior, and in particular it may impact the quality of tool calls using auto tool choice without a temperature manually specified出于好奇，为什么要做出这样的改变？ 0.7 长期以来一直是默认温度，从 0.7 更改为 1 在行为方面差异不小，特别是它可能会影响使用自动工具选择而不手动指定温度的工具调用质量

The default temperature for offline inference (LLM class) is 1.0, same as OpenAI’s official implementation. It’s also the default in most frameworks. I didn’t check past PRs to see why the OpenAI Compatible Server uses 0.7 as the default. It’s a bit odd.
Also, like I mentioned before, in temperature-sensitive cases, it’s common for users to set their own temperature. This shouldn’t affect too many use cases. Maybe we should note this change in the OpenAI Compatible Server docs? @simon-mo

I actually don't recall why is 0.7 given both huggingface and OpenAI have it at 1.0. Are we aware of any breakage?

I actually don't recall why is 0.7 given both huggingface and OpenAI have it at 1.0. Are we aware of any breakage?实际上我不记得为什么是 0.7，因为 Huggingface 和 OpenAI 的值都是 1.0。我们是否意识到有任何破损？

This value has been 0.7 since it was introduced, see https://github.com/vllm-project/vllm/pull/116. What’s strange is that ChatCompletionRequest uses 0.7, while CompletionRequest uses 1.0.
I searched Google for the source of 0.7, and it seems to be because OpenAI chatbots like ChatGPT use it (though no solid proof). The default for OpenAI’s Chat Completion API is 1.0. I think aligning with that makes sense.

Aligning with default behavior 100% makes sense, but it's also to avoid risking breaking workflows that depend on existing defaults.
It seems like this should be at least a minor version bump in semver, if not a major due to potentially breaking behavior; although it's definitely fuzzy


Is it possible to have a multi-architecture file?

e.g. managed AnyCPU with 32bit unmanaged, for maximum compatibility.
Obviously there's no such feature now, I'd like to know if it's even possible at all.
Use case: I'm writing a plugin for a managed AnyCPU program. Some user love to ignore usage tutorial and double click dll files trying to install. Normal Windows system will ask "You are trying to open a system file", but some random modified Windows will default open dll using Regsvr32.
I would like to export a DllRegisterServer to pop a MessageBox, while able to run on both 32bit and 64bit system.

Is it possible to have a multi-architecture file?

Native pe module cannot work with different architectures. This impossible even because of different headers, like the optional header structure:

https://docs.microsoft.com/en-us/windows/desktop/api/winnt/ns-winnt-_image_optional_header
https://docs.microsoft.com/en-us/windows/desktop/api/winnt/ns-winnt-_image_optional_header64

typedef struct _IMAGE_NT_HEADERS64 {
  DWORD                   Signature;
  IMAGE_FILE_HEADER       FileHeader;
  IMAGE_OPTIONAL_HEADER64 OptionalHeader;
} IMAGE_NT_HEADERS64, *PIMAGE_NT_HEADERS64;

https://github.com/3F/Conari/blob/master/Conari/PE/Hole/ExportDirectory.cs#L197

            // move to NumberOfRvaAndSizes

            if(ifh.SizeOfOptionalHeader == 0xE0) { // IMAGE_OPTIONAL_HEADER32
                stream.Seek(0x5C, SeekOrigin.Current);
            }
            else if(ifh.SizeOfOptionalHeader == 0xF0) { // IMAGE_OPTIONAL_HEADER64
                stream.Seek(0x6C, SeekOrigin.Current); // <<< +0x10

Thus, finally you should provide either pe32 or pe32+ module (aka pe64).
But, you can just provide both pe32 and pe32+ modules and just execute the one of this for related architecture.
The most easy way, you can use some installation wizard. Or just combine modules via other your 32bit application that will just select 32/64 architecture.
Our DllExport may provide both 32 & 64 pe-modules (dll or exe) in relevant folders:

-action Configure then select both arch (x86 + x64)
Now you can provide both architectures from output folder \x32\Library.dll and \x64\Library.dll

The most complex way
Actually, pe module may contain anything including code for several architectures, but we need also wrap the entry point to inject our specific tool that will understand this (for example, extract and execute code only for related architecture 32/64). Something like UPX.
But, as I was saying before, our modified .net modules are not really true native modules. They initially contains injected a common entry point by default for communicate with _CorExeMain / _CorDllMain -> mscoree.dll. Because it still contains opcodes only for CLR (of course except native wrapping and so on).
However, I will also be happy to hear other possible ways if I missed something :)

This is what got me thinking that it may be possible.

I know basic nothing about file struct before asking. After checking dnSpy's code, I understand the difference between AnyCPU and x86, and if a file contain not only managed IL code then it's x86 only. Tried to play with Is32BitRequired Is32BitPreferred IsILOnly, but apparently Microsoft did a great job checking if a executable file is valid. If any of that three is changed to a "incorrect" value, .NET will throw a BadImageFormatException when calling Assambly.LoadFrom.
Well, it's not possible I guess.

If any of that three is changed to a "incorrect" value, .NET will throw a BadImageFormatException when calling Assambly.LoadFrom.

It's a little bit other story. I mean, it will be still under CLR and its domains. While LoadLibrary (from Kernel32) will just try to understand this through specific header.
Independent arch (AnyCPU) is possible because of wrapping as I mentioned above.
That is, for my understanding or view, in general, this multi-architecture is possible thing by wrapping over CLR wrapping :) i.e. custom injection for entry point (see my note for DllMain issue).
But truth is that .., this is really giant overhead for an insignificant convenience (moreover, some things will add other new inconvenience for this ~convenience). Therefore, the easiest or more stable way is to provide both.


[stable/home-assistant] vscode image tag not available

Describe the bug
vscode sidecar fails to start with the default image codercom/code-server:2.1571-vsc1.38.1 since the tag is not available anymore.
Which chart:
stable/home-assistant

It appears that the code-server docker images are frequently deleted.  I just submitted #18636 to reference an code-server image that is associated with an actual release which hopefully means that the docker tag won't be removed.


[Feature] Export Silhouette Studio Project File

Find some way to export a Silhouette Studio Project File with cut marks.
https://www.silhouetteamerica.com/

Seems not to be that easy. best way might be to export a Graphtec Cutting file or to send the commands directly to the Silhouette Cutter:
https://github.com/pmonta/gerber2graphtec/issues/21
https://github.com/fablabnbg/inkscape-silhouette/blob/main/Commands.md


Maybe update to kalilinux/kali-rolling ?

See https://hub.docker.com/r/kalilinux/kali-rolling
The other does not seem to work...
Great repo though, THX!

Sorry for the late reply. Thanks for the correction, I've just updated the image reference to kalilinux/kali-rolling.


Missing AntDesign Icons

[X] Review the documentation: https://github.com/oblador/react-native-vector-icons
[X] Search for existing issues (including closed issues): https://github.com/oblador/react-native-vector-icons/issues

Environment
OS: macOS High Sierra 10.13.6
Target Platform: iOS
react-native: 0.57.2
react-native-vector-icons: v6.0.2

Description
After upgrading from v4.6.0 -> 6.0.1, some icons from AntDesign, like ('caret-right', 'minus-circle') showed up as a question mark (?).
That's when I created a brand new react-native project, now using version 6.0.2 of react-native-vector-icons, and the same occurred.

Reproducible Demo
react-native init iconsTest
cd iconsTest
npm i --save react-native-vector-icons
react-native link react-native-vector-icons

Run the app with the following code in App.js

import Icon from 'react-native-vector-icons/AntDesign'

export default class App extends Component<Props> {
  render() {
    return (
      <View style={styles.container}>
        <Icon name="caret-right" size={40}/>
      </View>
    );
  }
}

Hi, this is not really a helpful issue. Can you provide some context besides your env?

Sorry @oblador , I pressed SHIFT + Enter, submitting the issue by accident while editing

You seem to be using the wrong names for your icons. You can use https://github.com/oblador/react-native-vector-icons/blob/master/glyphmaps/AntDesign.json or https://oblador.github.io/react-native-vector-icons/ when looking up the name.
caret-right should be caretright for example.
https://github.com/oblador/react-native-vector-icons/blob/77c0010a627e4b84b6eaa563886ee68e98ce6056/glyphmaps/AntDesign.json#L6.

@hampustagerud You're right, I was using AntDesign's website as a guidance for the names. Sorry for the confusion


Load times have gotten a lot higher in recent commits

Right after merging the help menu PR, (copy of that state at https://hastebin.com/fomikikeze.js, misses some changes but mostly that), loading times were of about 250ms.

In the latest commit, loading times are about 1500ms (yes, 1.5 seconds, 6 times as much)

where do you get the loading info?

Output viewer (in this case from Eclipse)

ah

It should also appear in Vanilla/MultiMC viewer

ye. woudl you mind seeing more or less after exactly which commit it increased?

The problem is that history here is not linear, which means that commits from a PR can be mixed within commits of another PR.
(BTW, I'd recommend when merging, using Rebase and Merge, so commits get added to the top and not in this weird order, history becoming linear. You could also squash, but then you lose info).

Although I think this is because of the write_file() call on initialization. Does Scarpet allow writing files async?

I don't see why it shouldn't, according to what I found when writing the JSON PR (file IO has a general lock which I don't see why it should be thread-specific).

Although I think this is because of the write_file() call on initialization (it wasn't there before, not sure though). Does Scarpet allow writing files async?
no, cos the write_file() call on initialisation is called only occasionally, even on the version that you posted in the issue desc

True, don't know how I read that.

Can you rebase when merging a PR in github?

There is a drop-down next to the merge button where you can select the merge mode.

could the long load time be due to like 38kb freaking size?

and complex handling of help function at load?

ok, maybe more the sheer amount of code than the file size, but still.

and complex handling of help function at load?

I also thought the command map processing could be the cause, but the previous state compared here also has it. It is only about 5-20ms (according to my testing in that time).
And I don't think that only the new code presence would increase it that much, since we are comparing with one with 800 lines, the current one being around 960. If it was related to the quantity of code, I think it would be more linear.

Maybe the command registration?

I noticed that I was running _parde_config for global_Default_lang for every single language. After taking it outside, and only running it once, I brought load time down to ~1100 ms.

Command: reduce([range(100)],_a+profile_expr(_parse_config(global_default_lang)),0)/100

(high is better)
FIRST CODE:
_parse_config(config) -> (
    if(type(config) != 'list', config = [config]);
    ret = {};
    for(config,
        if(_ ~ '^\\w+ ?= *.+$' != null,
            key = _ ~ '^\\w+(?= ?= *.+)';
            value = _ ~ str('(?<=%s ?= ?) *([^ ].*)',key);
            ret:key = value
        )
    );
    ret
);

SECOND CODE:
_parse_config(config) -> (
    if(type(config) != 'list', config = [config]);
    ret = {};
    for(config,
        key = (t=split('=',_)):0 - ' ';
        value = join('=',slice(t,1))~' *([^ ].*)';
        if(key && value,
            ret:key = value
        )
    );
    ret
);

I can't understand why the execution time of the function 100 times is about the same, but the profile_expr() functions rates the second one much better compared to the first one...

Command: reduce([range(100)],_a+profile_expr(_parse_config(global_default_lang)),0)/100

(high is better)
FIRST CODE:
_parse_config(config) -> (
    if(type(config) != 'list', config = [config]);
    ret = {};
    for(config,
        if(_ ~ '^\\w+ ?= *.+$' != null,
            key = _ ~ '^\\w+(?= ?= *.+)';
            value = _ ~ str('(?<=%s ?= ?) *([^ ].*)',key);
            ret:key = value
        )
    );
    ret
);

SECOND CODE:
_parse_config(config) -> (
    if(type(config) != 'list', config = [config]);
    ret = {};
    for(config,
        key = (t=split('=',_)):0 - ' ';
        value = join('=',slice(t,1))~' *([^ ].*)';
        if(key && value,
            ret:key = value
        )
    );
    ret
);

I can't understand why the execution time of the function 100 times is about the same, but the profile_expr() functions rates the second one much better compared to the first one...

Can't believe it but I found it!

Can't believe it but I found it!

It gets down to almost nothing by commenting line 497!
https://github.com/Ghoulboy78/World-edit-scarpet/blob/0d0bbf037a891b4997673b370c4ea2d6ea22bf84/world-edit.sc#L485-L497
What does that _permutation function do??

It gets down to almost nothing by commenting line 497!
https://github.com/Ghoulboy78/World-edit-scarpet/blob/0d0bbf037a891b4997673b370c4ea2d6ea22bf84/world-edit.sc#L485-L497
What does that _permutation function do??

Added in b48dcfe8fbf6e5df4546c4c8c445ead5daa1c0cb. Why is it recursive?

Added in b48dcfe8fbf6e5df4546c4c8c445ead5daa1c0cb. Why is it recursive?

Oh... I see...

 I see...

There must be another way...

we thought abt it, but we couldnt find solution...

we thought abt it, but we couldnt find solution...

Am I right by supposing that finds every possible combination for the flags suggester? Or what does it do?

Am I right by supposing that finds every possible combination for the flags suggester? Or what does it do?

ye thats what it does

ye thats what it does

we werent sure abt the best way to do it tbh...

we werent sure abt the best way to do it tbh...

PR coming soon (probably)

PR coming soon (probably)

PR with a fix ready

PR with a fix ready

Am I right by supposing that finds every possible combination for the flags suggester? Or what does it do?

I think we used it to validate the input.
It should not be difficult to find another way:
You can check which flags already wrote and suggest all the missing appended to the current parameter.

Am I right by supposing that finds every possible combination for the flags suggester? Or what does it do?

I think we used it to validate the input.
It should not be difficult to find another way:
You can check which flags already wrote and suggest all the missing appended to the current parameter.


Add possibility to get tree as string

I added the possibility to retrieve the tree as a string instead of instantly printing it.

Nice!!! Thank you for you contribution!


add openvino support for igpu acceleation

Is your feature request related to a problem? Please describe.
only SYCL acceleraiton is available but intel CPU, even old (> gen6) includes openvino acceleration witch works pretty well (equivalent to google coral for what i've tested on frigate)
enabling openvino could strongly accelerate models even in old / small / cheap systems, no need for cuda
Describe the solution you'd like
docker images including openvino and /dev/dri/renderD128 passthrough to access igpu
Describe alternatives you've considered

Additional context
buildind accelerated local hosted voice assistants for homeassistant including distil-whisper or whisper.cpp / wyioming protocol

Thanks for showing interest in LocalAI and OpenVINO , I'll close this one as there is already another one already opened here: https://github.com/mudler/LocalAI/issues/1722

ok thanks !


Add extension points to render custom POST form

@mikekelly Spring Data REST is using this project (via webjars) as a plugin, so anybody that builds a HAL-based service can easily serve up a HAL Browser front end with next to no effort.
A bonus feature Spring Data REST comes with is ALPS metadata which includes the properties for every resource. A feature I have wanted to add for some time is to use this metadata and make the HAL Browser's POST form more sophisticated by listing each property by name with separate fields, instead of a raw body field where the user must type in all the fields in JSON, and include the right names.
I am tinkering with a fork of the app to craft some extension point where someone could drop in extra JavaScript to fetch this extra metadata, but I'm finding it tricky to do so. I didn't know if you were interested in working on such an extension point for this project, or if you are too busy with other projects.
/cc @olivergierke

@mikekelly I have written a working solution to plugin a custom non-GET dialog. You can view it at https://github.com/gregturn/hal-browser/commits/use-alps. There is just one commit at the time of this comment to skim over.

It uses Spring Data REST's ALPS metadata to fetch the property names associated with a given resource.
My tentative extension point is called HAL.customPost. In a couple places in the code, there are checks to see whether or not HAL.customPost is defined. If not, proceed with default behavior. If it is, then make some calls to alter the dialog.
To parse the ALPS metadata, I have a JSONPath library hard-coded into my custom.js code. Naturally this needs to migrate to the collection of other libraries. But I didn't want to do that yet if you were on the cusp of migrating to bower or something.
To plug in my custom JavaScript module, I had to customize the browser.html page. THis might be a step best left up to my application. Since I don't know any dynamic way to "look" for other modules, pulling in hal-browser via WebJars and then coding my own HTML frontend may be the best approach and remove the number of changes to this project.

What do you think?

Thanks for this. Sounds and looks reasonable at first glance. Please could you strip out custom.js and raise a PR?

Also, please could you add some docs for this feature to the README?

Sure thing.

awesome, thanks

Thanks to this patch, I have now plugged in a nice customization. Thanks!
http://docs.spring.io/spring-data/rest/docs/2.4.0.RC1/reference/html/#_the_hal_browser

Awesome! Good stuff


I'm not able to use "-" in channel name but it's allowed to use in java

I'm trying to use the channel name "private-id", but I get an error saying
Error authorizing channel [private-215474]: Optional("{"detail":"Method \"GET\" not allowed."}")
is it possible to use "-" in channel name in swift or am I implementing wrong?
CC @pusher/mobile

@MahendraRaj that sounds like an error coming from your server's auth endpoint.
How have you implemented your auth in the Swift code?

Thank you @hamchapman  :)
I have the issue fixed on my end as it was the error in the server api's header fields.
Since the issue is fixed, I would close this issue


The response is not in JSON format

Hi all,
I have just implemented the Request-a-team app and now i am trying to open it under a normal user.
When i open the app i immediately see a error on top.

In English its saying:
The gave up record is not found. Serveranswer: Team Request Settings failed. The response is not in JSON format.
When i choose the option 'From Scratch', i see it also and i am not able to use the dropdown 'Visibility' in the first step.
Anyone any idea?

@MaxwellvDijk Did you follow the step to remove the existing data sources from the Power App and re-add these, pointing at your SharePoint site? That may be your issue.

Hi Alexc-MSFT, thank you for your quick reply.
I saw that step, but i couldn't find any demo resources.
I have checked again and this is what i see.

@alexc-MSFT did you see my last post last week?

Closed due to inactivity - reopen if required


Add ability to give requests CPU usage quotas

Related to #200, it'd be good to have an automated method for flat out killing requests that are hogging the CPU and blocking other requests.

props to @alienth for the suggestion


Add support for Google trusted publishing

Draft while we get https://github.com/pypi/warehouse/pull/15143 and https://github.com/pypi/warehouse/pull/14063 https://github.com/pypi/warehouse/pull/15148 merged.
On top of #15143, 09812df38d5d826f43cf6a07422a9d26f055e5fe is the relevant commit.
Still needs:

[x] Tests for the PendingPublisher
[ ] Tests for the Publisher
[ ] Docs

Fixes #13551.

Looks like https://squidfunk.github.io/mkdocs-material/reference/content-tabs/#linked-content-tabs-feature-enabled might be the answer for the doc updates needed here.

Looks like https://squidfunk.github.io/mkdocs-material/reference/content-tabs/#linked-content-tabs-feature-enabled might be the answer for the doc updates needed here.

I'll do a separate PR for this today!

OK, I think this is good to go, we can queue up docs for this in https://github.com/pypi/warehouse/pull/15173.


Provide a way to run configure-commands again for workspaced elements

See original issue on GitLab
In GitLab by [Gitlab user @cs-shadow] on Apr 23, 2018, 12:07
Now that #209 is closed, we only run configure-commands only once for workspaced elements. It it possible that the user might want to run the configure-commands again in certain cases. This is currently possible by playing the workspace close/workspace open --no-checkout game but it will be nicer to do this in one step.
As originally mentioned in https://gitlab.com/BuildStream/buildstream/merge_requests/126#note_46286435, one way to solve it is by providing a soft reset functionality - bst workspace reset --soft. This option would simply unset the prepare flag.

In GitLab by [Gitlab user @cs-shadow] on May 7, 2018, 23:20
mentioned in commit 98442bcd3482792c8d2418a4e73e59c4599438a7

In GitLab by [Gitlab user @cs-shadow] on May 8, 2018, 20:36
mentioned in merge request !457

In GitLab by [Gitlab user @tristanvb] on May 10, 2018, 13:25
mentioned in commit edf3e029976ba0c605f5ff41bbb5568868c8f699

In GitLab by [Gitlab user @tristanvb] on May 10, 2018, 13:26
mentioned in merge request !459

In GitLab by [Gitlab user @tristanvb] on May 10, 2018, 13:27
This will be closed by !459, but it would be nice to also have a regression test for this.

In GitLab by [Gitlab user @tristanvb] on May 10, 2018, 13:42
closed via merge request !459


Brew search returns "invalid tap name"

brew doctor output
Your system is ready to brew.

Verification

[X] My "brew doctor output" above says Your system is ready to brew. and am still able to reproduce my issue.
[X] I ran brew update twice and am still able to reproduce my issue.
[X] This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

brew config output
HOMEBREW_VERSION: 4.2.7-43-g6775171
ORIGIN: https://github.com/Homebrew/brew
HEAD:<PHONE_NUMBER>82b276ba1c4ba77456adf7540d99ba
Last commit: 35 minutes ago
Core tap JSON: 06 Feb 20:10 UTC
Core cask tap JSON: 06 Feb 20:10 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 20
HOMEBREW_SORBET_RUNTIME: set
Homebrew Ruby: 3.1.4 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.1.4/bin/ruby
CPU: 20-core 64-bit arm_firestorm_icestorm
Clang: 15.0.0 build 1500
Git: 2.43.0 => /opt/homebrew/bin/git
Curl: 8.4.0 => /usr/bin/curl
macOS: 14.3-arm64
CLT: <IP_ADDRESS>.1.1700200546
Xcode: 15.2
Rosetta 2: false

What were you trying to do (and why)?
I want to search the database for packages... well, the reason is obvious...
What happened (include all command output)?
❯ brew search python
Error: Invalid tap name 'mysql-connector-python/'
❯ brew search hello
Error: Invalid tap name 'helo/'
❯ brew search -d hello
/opt/homebrew/Library/Homebrew/brew.rb (Formulary::FormulaAPILoader): loading jello from API
/opt/homebrew/Library/Homebrew/brew.rb (Formulary::FormulaAPILoader): loading helm from API
/opt/homebrew/Library/Homebrew/brew.rb (Formulary::FormulaAPILoader): loading hello from API
/opt/homebrew/Library/Homebrew/brew.rb (Cask::CaskLoader::FromAPILoader): loading helo
Error: Invalid tap name 'helo/'
/opt/homebrew/Library/Homebrew/tap.rb:48:in fetch' /opt/homebrew/Library/Homebrew/cask/cask_loader.rb:460:in tap_cask_token_type'
/opt/homebrew/Library/Homebrew/cask/cask_loader.rb:502:in block in for' /opt/homebrew/Library/Homebrew/cask/cask_loader.rb:495:in each'
/opt/homebrew/Library/Homebrew/cask/cask_loader.rb:495:in for' /opt/homebrew/Library/Homebrew/cask/cask_loader.rb:455:in load'
/opt/homebrew/Library/Homebrew/search.rb:96:in block in search_casks' /opt/homebrew/Library/Homebrew/search.rb:95:in map'
/opt/homebrew/Library/Homebrew/search.rb:95:in search_casks' /opt/homebrew/Library/Homebrew/search.rb:115:in search_names'
/opt/homebrew/Library/Homebrew/cmd/search.rb:85:in search' /opt/homebrew/Library/Homebrew/brew.rb:86:in '
What did you expect to happen?
get a result
Step-by-step reproduction instructions (by running brew commands)
not really a step, i assume. The error just occurs... undependent on what to search for.
brew search hello

I'm seeing this with other commands as well. For example, any upgrade or install involving a cask. It looks like there's already a potential fix in #16608.

This is also happening to me with the install command
brew install --cask xxx

Thanks for the reports, the issue will be resolved shortly

awesome - that was fast, fixed it for me!

Fixed for me too!


Switch to our own LZO wrapper

See attached Trello card for details.

 Find/use non-GPL LZO library for uploader


🚀 Feature Request: add CF_PAGES variables to getPlatformProxy env

Describe the solution
getPlatformProxy doesn't populate the Pages injected environment variables meaning that those are only available in production.
Not finding them locally might confuse people (e.g. https://github.com/cloudflare/next-on-pages/issues/758) and we should always strive for parity between local and prod, so ideally we should add some mocks for such values in getPlatformProxy, similarly to how Astro used to.
Notes/Questions:

the variables should naturally be only populated if the target application is a Pages one (an extra flag to signal getPlatformProxy when the target application is a Pages one, as mentioned in https://github.com/cloudflare/workers-sdk/issues/5742 could come in handy here... 🤔)
should the ASSETS binding also be included?

Related to https://github.com/cloudflare/workers-sdk/issues/1440


Merge review: rippled 2.2.2. job queue slot for validation ledger check & inbound validation

Impact & merge need review:

https://github.com/XRPLF/rippled/commit/fbbea9e6e25795a8a6bd1bf64b780771933a9579
https://github.com/XRPLF/rippled/commit/774148389467781aca7c01bac90af2fba870570c

@dangell7 @RichardAH FH nodes seem to do better after this (in terms of transitions & lagging)

Merging
https://github.com/Xahau/xahaud/tree/merge/2.2.2-jobqueue

https://github.com/Xahau/xahaud/pull/360


Apply gofmt fixes

Align the code with gofmt.
We carry many gofmt issues, and now is the time to fix them all.
We should make sure every Ubiquity developer set automatic gofmt in its IDE to prevent pushing formatting issues in the future.
We should keep go report in high score as much as possible.

This change is

Reviewed 6 of 6 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Review status: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

Comments from Reviewable


Commit Search shortcut disables the backslash key on german macOS

Commit Search
Adds a Search Commits command (gitlens.showCommitSearch) with a shortcut of alt+/ to search for commits by message, author, file(s), commit id, or code changes

https://github.com/eamodio/vscode-gitlens/tree/e81d893bdd7b80ff8d4d67b78785389e439eac61#commit-search
On a german macOS, the keybinding alt+/ collides with the backslash (shift+alt+7). Hence, with the default config, I cannot type a backslash into my code because it opens the Commit Search. I just want to hint at an unlucky default config ;)

Please open the GitLens settings (run GitLens: Open Settings from the command palette) and jump to Keyboard Shortcuts and change it to either the chorded set or custom set. The alternate set which used to be the default, can both conflict with mnemonics and entering characters in different keyboard layouts.
While the chorded set is the new default, I didn't want to change the settings of existing installs.
Hope that helps.


Small UI fixes on form titles

Small fixed with center title, as below

Reference: https://github.com/gogits/gogs/pull/3786

LGTM

@tboerger did we remove the less-files? :)

Ooops, totally forgot the less file. @joubertredrat please update the .less file.

wtf, sorry guys, was PR from wrong branch


[Draft] verbatim modifier for box

verbatim modifier for box
In this draft, we propose the introduction of the verbatim modifier for box. verbatim is a compiler flag to notify the compiler to not touch the decorated box. The purpose is to give users precise control of the boxed operations without them being transformed, optimized or re-synthesized by the compiler.
An example is as follows:
// verbatim box demo
OPENQASM 3;
include "stdgates.inc";

z $0;

verbatim box {
     delay[20ns] $1;
     cx $0, $1;
     x $1;
     x $1;
}

z $0;

In the above example, the two x  gates in the verbatim box will not be merged (cancelled) by a compiler. However, just same as box without the modifier, gates around the verbatim box can commute through the box and cancel each other. Thus, the above two Z gates are allowed to be moved over the box and cancelled by the compiler.
What is preserved by the verbatim modifier
The following are preserved:

The order and length of the gate sequences (so no gates are moved or cancelled, no gate insertion as well).
Linking of native gates to calibration definitions. Native gates will be directly linked to their defcal and will not be replaced with any other (potentially more optimized) pulse calibrations by any compiler passes .
Timing and duration. No compiler optimization passes can alter the timing operations specified in the box, even if the new scheduling is functionally equivalent to the original and more optimized. But the compiler is allowed to resolve undetermined timing/duration of gates.
Qubit mapping. No temporary physical qubit re-mapping, ancilla qubit or SWAP gate insertion is allowed. If the circuit is not mapped at the end of the compilation, the compiler will throw an error.

In other words, any compiler passes other than  (1)  timing/duration resolution and (2) calibration linking should not be modifying the code in a verbatim box.
What is disallowed in a verbatim box
As mentioned above, the only two compiler passes that look inside a verbatim box are (1)  timing/duration resolution and (2) calibration linking. As a result, having any of the following high-level constructs in a verbatim box will result in a runtime error since related compiler passes will not be able to look inside to properly compile these:

Virtual qubits

Composite gates without a defcal

Subroutine/kernel calls

Any other language constructs cannot be compiled down to determined pulse schedules by the timing/duration resolution compiler pass and the calibration linking pass.

What is allowed in a verbatim box

barrier  is allowed but will raise a compiler warning since it takes no effects.

Language constructs that can be compiled down to determined pulse schedules by the timing/duration resolution compiler pass and the calibration linking pass.

Assigning a duration to a verbatim box is allowed:

verbatim box [1ms] {
    stretch a;

    delay[a] $0;
    cx $0, $1;
    cx $0, $1;
    delay[a] $0;
}

The above codes would be useful for centering the two cx gates.
verbatim levels
As shown in some of the use cases below (e.g. the flag qubit scheme), it’s inconvenient to only allow gates with defcal to be inside a verbatim box.  We introduce level 1 verbatim box to give users more granular control of a verbatim box. We propose:

the default verbatim box to be level 0. In the default verbatim box, no composite gates are allowed.
level 1 be denoted as verbatim(1) box {...}. We allow virtual qubits inside a level 1 box.
We allow virtual qubits and composite  inside a level 2 box.

gate cz a, b{ // assume cx, hadamard has a defcal, but not cz.
    h a;
    cx a, b;
    h a;
}

verbatim(2) box {
     cz q[0], q[1]; // level 2 box accept and decompose it.

inline modifier
As an alternative to level 2 verbatim box, we can also provide an inline modifier to allow composite gates. This inline approach will improve the readability of the program and is closely aligned to the C language. An example is as follows:
gate cz a, b{ // assume cx, hadamard has a defcal
    h a;
    cx a, b;
    h a;
}

verbatim(1) inline box {
    cz q[0], q[1]; // with inline modifier, this piece of code will not raise an error.
}

Use cases
Digital zero noise extrapolation (ZNE)
// Using unitary folding to perform
// digital zero noise extrapolation
// for a single z gate.
// d-ZNE is proposed in https://arxiv.org/pdf/2005.10921.pdf
// Example taken from https://mitiq.readthedocs.io/en/stable/guide/guide-zne.html

OPENQASM 3;
include "stdgates.inc";

bit c;

verbatim box {
    h $0;  // assume h has a defcal
    h $0;
    h $0;
}

cx $0, $1;

measure $0 -> c;

Randomized benchmarking (RB)
// One randomized benchmarking sequence
OPENQASM 3;
include "stdgates.inc";

qubit q[2];
bit c[2];
verbatim(1) box {
    //assuming h, cz, s, z has defcal
    reset q;
    h q[0];
    cz q[0], q[1];
    s q[0];
    cz q[0], q[1];
    s q[0];
    z q[0];
    h q[0];
    measure q -> c;
}

With verbatim box, RB programs can be written in a clean way.
Flag qubit scheme in QEC [Ref 1, Ref 2]
// Flag fault-tolerant circuit for measuring the logical Hadamard
// operator of the [[7, 1, 3]] Steane code. Taken from page 6,
// https://quantum-journal.org/papers/q-2019-05-20-143/pdf/.

OPENQASM 3;
include "stdgates.inc";

qubit steane_reg[7];
qubit flag_reg[4];

def ft_ctrl_hadamard qubit[7]: logical_qubits,
                     qubit[1]: ancilla,
                     qubit[4] flag_qubits -> bool {
    bool success;

    verbatim(2) box{
        bit checks[4];

        x ancilla; // prepare |+>
        ch ancilla, logical_qubits[0];
        cx flag_qubits[0], ancilla;
        ch ancilla, logical_qubits[1];
        cx flag_qubits[1], ancilla;
        ch ancilla, logical_qubits[2];
        cx flag_qubits[2], ancilla;
        cx flag_qubits[1], ancilla;
        cx flag_qubits[3], ancilla;
        ch ancilla, logical_qubits[5];
        cx flag_qubits[3], ancilla;
        cx flag_qubits[2], ancilla;
        ch ancilla, logical_qubits[3];
        ch ancilla, logical_qubits[6];
        cx flag_qubits[0], ancilla;
        ch ancilla, logical_qubits[4];

        checks = measure flag_qubits;
    }

  success = ~(bool(checks[0]) | bool(checks[1]) |
              bool(checks[2]) | bool(checks[3]))

  return success;
}

All paired flag qubits in the lower register can be scheduled together and be cancelled, verbatim box will keep them intact.
In general, we suggest QEC circuits be written in a verbatim inline box.
Discussion
Higher verbatim levels
With verbatim level 1 and leve 2 introduced, we have the option to define higher verbatim levels for more granular control. In this PR, we do not address the problem of defining higher verbatim levels since there are not enough real-world examples to support it. We do provide a possible definition to demonstrate the potential use cases of higher verbatim levels. As an example, we can define higher levels as follows:

level 3: composite gates, virtual qubits and gate cancellation are allowed.
level 4: composite gates, virtual qubits, gate cancellation and gate commutation are allowed.

Relations between barrier and verbatim box
verbatim box shares some similarities with barrier functionally in that both of them limit certain compiler optimizations and the freedom of scheduling. However, the purpose of these two do not entirely overlap. First, the effect of verbatim box is regional, thus, it provides a clean way for users to precisely control a long gate sequence in which case using barrier can be tedious and lengthy, e.g. the RB example below. Second, temporally, barrier is global (on the qubits it applies to) in that it blocks all gates before and all gates after from commuting. In contrast, verbatim box allows commutation of gates around it (e.g. the first example above in this PR). Third, there are compilation optimizations performed on single gates, such as replacing pulse-level calibration definition with more optimized ones and noise-tailoring operations like randomized compilation, that barrier cannot prevent but verbatim box can.
Other options of the syntax
Other than the syntax we proposed, there are two other options:

verbatim_box

verbatim_box {
     delay[20ns] q;
     x q;
     x q;
}

The reason we recommended the current syntax is that, if we want to introduce another kind of box, say, nonparallel box where no parallelization is allowed. With the verbatim box we can simply define nonparallel box or nonparallel verbatim box. While with verbatim_box, we have to define a new box nonparallel_box.

box(verbatim)

Since verbatim is not an argument and the box is not a function, this syntax is not preferred.

The may discussion around this topic it seems focus more on the syntax extension than in the semantic itself.
I talked with @aspcompiler and it seems this is a good candidate for a pragma. For example, the following annotation could mean verbatim box:
# verbatim
box {
     delay[20ns] $1;
     cx $0, $1;
     x $1;
     x $1;
}

I'm aware I'm coming in very new and without any of the background, but when I had first read this proposal it felt like making it a #pragma would offer the most flexibility, both for users and for implementations.
I had understood #pragma to be intended as hints or instructions for the compiler, which may be used slightly differently by different compilers (similar to how it is in C).  The "other syntax options" section gets into something similar; it suggests the idea of a parallel_box idea, and this is exactly something that's typically handled by #pragma directives in C (for OpenMP), so that different compilers or compilers without that particular feature can still parse the structure, and silently degrade to an equivalent program.
I would worry a little bit if we start having a quite restricted syntax (integer levels) for defining which compiler optimisations are allowed in a region.  As compilers gain more options, it would be a bit like trying to mandate the -O0, -O1, -O2, ... levels in C compilers at the language level in a way that was consistent across every possible implementation.  To extend the analogy, allowing them to be controlled instead with -finline-functions, -funroll-loops and similar via the more free-form pragma would allow different compilers to advance and add new features, without breaking box.

Yeah, agree with @1ucian0 @jakelishman That is also the conclusion from the last TSC meeting. I closed the PR but left the issue here. Will open it another PR for verbatim pragma.

@shiyunon should we close this issue?

Closing this issue.


add PodSecurityPolicy support and introduce generic securityContext param

Proposed changes
Kubernetes clusters (e.g. AKS, EKS, or VMware PKS in my case) that have PodSecurityPolicy enabled would benefit from OOTB PodSecurityPolicy support in Splunk Connect for Kubernetes.
This also will benefit from changing the openshift parameter to the more generic securityContext as this setting has nothing to do with OpenShift per se, and is more of something required for any locked down Kubernetes cluster with PodSecurityPolicy enabled.
This patch introduces

optional (default disabled) PodSecurityPolicy objects (wide open privileged for now - probably could be eventually tailored to be more restrictive) for the helm charts,
a new securityContext parameter that acts like the openshift parameter, but doesn't eliminate the latter for backwards compatibility

Types of changes
What types of changes does your code introduce?
Put an x in the boxes that apply

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

Checklist
Put an x in the boxes that apply.

[x] I have read the CONTRIBUTING doc
[x] I have read the CLA
[x] I have added necessary documentation (if appropriate)
[x] Any dependent changes have been merged and published in downstream modules

Let me know when its ready for review. I think the changes you are suggesting make the implementation generic, and I would love to incorporate the changes.
Thanks

Yep sorry my collaborator and I had a branching issue, will force push this as a cleaned up commit today

@svrc-pivotal this ready?

yes it's ready !
On Fri, Sep 13, 2019 at 9:27 AM Chaitanya Phalak<EMAIL_ADDRESS>wrote:

@svrc-pivotal https://github.com/svrc-pivotal this ready?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/splunk/splunk-connect-for-kubernetes/pull/240?email_source=notifications&email_token=ACRFZLZQ5KISKPKYAFONHFLQJOWMTA5CNFSM4IUM57N2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6VLWHI#issuecomment-531282717,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACRFZL3M5M2PW34PDAEM6TDQJOWMTANCNFSM4IUM57NQ
.

--
Stuart Charlton
Pivotal Software | Platform Architecture
Mobile:<PHONE_NUMBER> | Email<EMAIL_ADDRESS>

@jsiegele i'd say have the helm chart install the service accounts, disable RBAC in this helm chart, and create your own RoleBinding/Roles/PSPs.  Unless you were looking for specific tweaks of the out-of-the-box PSPs or RoleBindings I'm providing here?

will do

Would it be possible to parameterize the security context user, group, and fsgroup in order to run as a non-root user or is it not possible to run as non-root?

@limscoder in the current implementation for logging component, its not possible to run as non-root yet.

Inbetween the PodSecurityPolicy K8s feature is deprecated.
https://github.com/kubernetes/kubernetes/pull/97171


containerservice.ManagedClusterPropertiesAutoScalerProfile (AKS) does not accept some duration values which are otherwise valid

Bug Report

github.com/Azure/azure-sdk-for-go/profiles/latest/containerservice/mgmt/containerservice
<EMAIL_ADDRESS>
Specify the exact commit if possible; one way to get this is the REVISION
column output by dep status "github.com/Azure/azure-sdk-for-go.

go version go1.15.6 darwin/amd64

What is the error? -> containerservice.ManagedClusterPropertiesAutoScalerProfile.ScanInterval = &("1m") throws an error: "containerservice.ManagedClustersClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="InvalidParameter" Message="Invalid value specified for the cluster-autoscaler parameter 'scan-interval'. Please refer to https://aka.ms/cluster-autoscaler for more details."
What is expected? -> Cluster creation should pass.
How to reproduce? -> Create AKS cluster with containerservice.ManagedClusterPropertiesAutoScalerProfile.ScanInterval = &("1m")

Extra observations
containerservice.ManagedClusterPropertiesAutoScalerProfile.ScanInterval = &("1m") fails but containerservice.ManagedClusterPropertiesAutoScalerProfile.ScanInterval = &("60s") passes.
Similar issues exist with other fields, for example:
containerservice.ManagedClusterPropertiesAutoScalerProfile.ScaleDownDelayAfterFailure = &("3m30s") throws an error: "containerservice.ManagedClustersClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="InvalidParameter" Message="Invalid value specified for the cluster-autoscaler parameter 'scale-down-delay-after-failure'. Please refer to https://aka.ms/cluster-autoscaler for more details." even though it is a valid value.
Similarly:
containerservice.ManagedClusterPropertiesAutoScalerProfile.ScaleDownDelayAfterFailure = &("180s") throws an error: "containerservice.ManagedClustersClient#CreateOrUpdate: Failure sending request: StatusCode=400 -- Original Error: Code="InvalidParameter" Message="Invalid value specified for the cluster-autoscaler parameter 'scale-down-delay-after-failure'. Please refer to https://aka.ms/cluster-autoscaler for more details."
but
containerservice.ManagedClusterPropertiesAutoScalerProfile.ScaleDownDelayAfterFailure = &("3m") passes.

Hi @krishna-birla thanks for this issue!
This sounds like an API issue rather than the SDK itself. Therefore I have tagged this issue so that the corresponding service team could have a look at this.

Thanks @ArcturusZhang

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @qike-ms, @jwilder, @thomas1206, @seanmck.
Issue Details

Any update?


Ice & snow tile modernization

About the PR

requires https://github.com/space-wizards/RobustToolbox/pull/4341

adds ice tiles which modify acceleration/friction for mobs
adds dug snow
adds tile edges to snow & dug snow
adds tile edge prio support to existing tile edge stuff
updates nukieplanet with an ice rink
adds to planetgen for snowies

Why / Balance

snow planet juice. more funny
Technical details

in movercontroller now resolves the tiledef early and passes it onto footstepsound etc
this is needed so we can get the tile mob friction/accel overrides and use them
needs https://github.com/space-wizards/RobustToolbox/pull/4341 for tile edge priority

Media

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

planet

DA RINKY?

tile edges (MINOR VISual bug when 3 intersect im not going to fix it here sorry)

movement
https://github.com/space-wizards/space-station-14/assets/19853115/a0e428a3-aaaf-4865-9055-68702c107417
Breaking changes

n/a probably
Changelog

:cl:

add: Snow planets can now spawn with ice, which gives you very floaty movement!
add: The nukie planet now spawns with some ice, and a mini rink to let off some steam
add: Snow now has tile edge support like grass

needs @metalgearsloth review on mover shit

drafting 2 try some sprite stuff

reviewable ghosts are wonk with the tile accel but im going to fix it in a later PR which will also fix chasm n lava stuff

actually this can be merged without the engine PR edge prio just wont work until thats in