GPU code fails to compile for provided CMake examples

Bug description
With a recent change to CudaTensor.hpp (#50 ) we can no longer compile GPU support without explicitly using nvcc. This also brings many unwanted side-effects due to the level of C++17 support in nvcc. As such, the cuTENSOR enabled tests and benchmark examples no longer compile or run using the provided CMake scripts.

Expected behavior: The cuTENSOR enabled code should run and pass all tests, and all examples should be runnable.

Actual behavior: The cuTENSOR enabled code fails to compile for the given test-cases, and all benchmark examples using GPU support fail to compile.

Reproduces how often: Always using CMake on a GPU-enabled system with -DENABLE_CUTENSOR=1 .

System information: Linux, AMD64, nvcc 11.3, cuTensor 1.3.1, g++ 10.2.0/10.3.0/11.1.0, GTX 1060

Source code and backtraces
Build command:
cmake . -BBuild -DENABLE_NATIVE=1 -DENABLE_OPENMP=1 -DENABLE_CUTENSOR=1 -DBUILD_TESTS=1
cmake --build ./Build

Output:
Consolidate compiler generated dependencies of target test_cutensor
[  9%] Building CXX object test/CMakeFiles/test_cutensor.dir/Test_CudaTensor.cpp.o
In file included from /home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_capturer.hpp:4,
                 from /home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_flow.hpp:4,
                 from /home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cudaflow.hpp:9,
                 from /home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp:22,
                 from /home/mlxd/BugFixes/Ref/jet/test/Test_CudaTensor.cpp:10:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_optimizer.hpp: In member function ‘std::vector<tf::cudaNode*> tf::cudaCapturingBase::_toposort(tf::cudaGraph&)’:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_optimizer.hpp:56:11: error: unused variable ‘hu’ [-Werror=unused-variable]
   56 |     auto& hu = std::get<cudaNode::Capture>(u->_handle);
      |           ^~
In file included from /home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_flow.hpp:4,
                 from /home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cudaflow.hpp:9,
                 from /home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp:22,
                 from /home/mlxd/BugFixes/Ref/jet/test/Test_CudaTensor.cpp:10:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_capturer.hpp: In lambda function:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_capturer.hpp:686:8: error: expected primary-expression before ‘<’ token
  686 |     f<<<g, b, s, stream>>>(args...);
      |        ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_capturer.hpp:686:26: error: expected primary-expression before ‘>’ token
  686 |     f<<<g, b, s, stream>>>(args...);
      |                          ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_capturer.hpp:686:32: error: expected ‘)’ before ‘...’ token
  686 |     f<<<g, b, s, stream>>>(args...);
      |                           ~    ^~~
      |                                )
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_capturer.hpp: In lambda function:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_capturer.hpp:795:8: error: expected primary-expression before ‘<’ token
  795 |     f<<<g, b, s, stream>>>(args...);
      |        ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_capturer.hpp:795:26: error: expected primary-expression before ‘>’ token
  795 |     f<<<g, b, s, stream>>>(args...);
      |                          ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_capturer.hpp:795:32: error: expected ‘)’ before ‘...’ token
  795 |     f<<<g, b, s, stream>>>(args...);
      |                           ~    ^~~
      |                                )
In file included from /home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cudaflow.hpp:10,
                 from /home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp:22,
                 from /home/mlxd/BugFixes/Ref/jet/test/Test_CudaTensor.cpp:10:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp: In function ‘void tf::cuda_for_each(I, size_t, F)’:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp:25:14: error: ‘blockIdx’ was not declared in this scope
   25 |   size_t i = blockIdx.x*blockDim.x + threadIdx.x;
      |              ^~~~~~~~
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp:25:25: error: ‘blockDim’ was not declared in this scope
   25 |   size_t i = blockIdx.x*blockDim.x + threadIdx.x;
      |                         ^~~~~~~~
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp:25:38: error: ‘threadIdx’ was not declared in this scope
   25 |   size_t i = blockIdx.x*blockDim.x + threadIdx.x;
      |                                      ^~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp: In function ‘void tf::cuda_for_each_index(I, I, size_t, F)’:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp:38:14: error: ‘blockIdx’ was not declared in this scope
   38 |   size_t i = blockIdx.x*blockDim.x + threadIdx.x;
      |              ^~~~~~~~
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp:38:25: error: ‘blockDim’ was not declared in this scope
   38 |   size_t i = blockIdx.x*blockDim.x + threadIdx.x;
      |                         ^~~~~~~~
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp:38:38: error: ‘threadIdx’ was not declared in this scope
   38 |   size_t i = blockIdx.x*blockDim.x + threadIdx.x;
      |                                      ^~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp: In lambda function:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp:134:26: error: expected primary-expression before ‘<’ token
  134 |     cuda_for_each<I, C><<<(N+B-1)/B, B, 0, stream>>>(first, N, c);
      |                          ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp:134:52: error: expected primary-expression before ‘>’ token
  134 |     cuda_for_each<I, C><<<(N+B-1)/B, B, 0, stream>>>(first, N, c);
      |                                                    ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp: In lambda function:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp:151:32: error: expected primary-expression before ‘<’ token
  151 |     cuda_for_each_index<I, C><<<(N+B-1)/B, B, 0, stream>>>(beg, inc, N, c);
      |                                ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp:151:58: error: expected primary-expression before ‘>’ token
  151 |     cuda_for_each_index<I, C><<<(N+B-1)/B, B, 0, stream>>>(beg, inc, N, c);
      |                                                          ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp: In lambda function:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp:164:26: error: expected primary-expression before ‘<’ token
  164 |     cuda_for_each<I, C><<<(N+B-1)/B, B, 0, stream>>>(first, N, c);
      |                          ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp:164:52: error: expected primary-expression before ‘>’ token
  164 |     cuda_for_each<I, C><<<(N+B-1)/B, B, 0, stream>>>(first, N, c);
      |                                                    ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp: In lambda function:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp:183:32: error: expected primary-expression before ‘<’ token
  183 |     cuda_for_each_index<I, C><<<(N+B-1)/B, B, 0, stream>>>(beg, inc, N, c);
      |                                ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp:183:58: error: expected primary-expression before ‘>’ token
  183 |     cuda_for_each_index<I, C><<<(N+B-1)/B, B, 0, stream>>>(beg, inc, N, c);
      |                                                          ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp: In lambda function:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp:191:26: error: expected primary-expression before ‘<’ token
  191 |     cuda_single_task<C><<<1, 1, 0, stream>>>(c);
      |                          ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp:191:44: error: expected primary-expression before ‘>’ token
  191 |     cuda_single_task<C><<<1, 1, 0, stream>>>(c);
      |                                            ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp: In lambda function:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp:199:26: error: expected primary-expression before ‘<’ token
  199 |     cuda_single_task<C><<<1, 1, 0, stream>>>(c);
      |                          ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_for_each.hpp:199:44: error: expected primary-expression before ‘>’ token
  199 |     cuda_single_task<C><<<1, 1, 0, stream>>>(c);
      |                                            ^
In file included from /home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cudaflow.hpp:11,
                 from /home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp:22,
                 from /home/mlxd/BugFixes/Ref/jet/test/Test_CudaTensor.cpp:10:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_transform.hpp: In function ‘void tf::cuda_transform(I, size_t, F, S ...)’:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_transform.hpp:15:14: error: ‘blockIdx’ was not declared in this scope
   15 |   size_t i = blockIdx.x*blockDim.x + threadIdx.x;
      |              ^~~~~~~~
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_transform.hpp:15:25: error: ‘blockDim’ was not declared in this scope
   15 |   size_t i = blockIdx.x*blockDim.x + threadIdx.x;
      |                         ^~~~~~~~
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_transform.hpp:15:38: error: ‘threadIdx’ was not declared in this scope
   15 |   size_t i = blockIdx.x*blockDim.x + threadIdx.x;
      |                                      ^~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_transform.hpp: In lambda function:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_transform.hpp:70:33: error: expected primary-expression before ‘<’ token
   70 |     cuda_transform<I, C, S...><<<(N+B-1)/B, B, 0, stream>>>(first, N, c, srcs...);
      |                                 ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_transform.hpp:70:59: error: expected primary-expression before ‘>’ token
   70 |     cuda_transform<I, C, S...><<<(N+B-1)/B, B, 0, stream>>>(first, N, c, srcs...);
      |                                                           ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_transform.hpp:70:78: error: expected ‘)’ before ‘...’ token
   70 |     cuda_transform<I, C, S...><<<(N+B-1)/B, B, 0, stream>>>(first, N, c, srcs...);
      |                                                            ~                 ^~~
      |                                                                              )
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_transform.hpp: In lambda function:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_transform.hpp:86:33: error: expected primary-expression before ‘<’ token
   86 |     cuda_transform<I, C, S...><<<(N+B-1)/B, B, 0, stream>>>(first, N, c, srcs...);
      |                                 ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_transform.hpp:86:59: error: expected primary-expression before ‘>’ token
   86 |     cuda_transform<I, C, S...><<<(N+B-1)/B, B, 0, stream>>>(first, N, c, srcs...);
      |                                                           ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_transform.hpp:86:78: error: expected ‘)’ before ‘...’ token
   86 |     cuda_transform<I, C, S...><<<(N+B-1)/B, B, 0, stream>>>(first, N, c, srcs...);
      |                                                            ~                 ^~~
      |                                                                              )
In file included from /home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cudaflow.hpp:12,
                 from /home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp:22,
                 from /home/mlxd/BugFixes/Ref/jet/test/Test_CudaTensor.cpp:10:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_reduce.hpp: In function ‘void tf::cuda_reduce(I, size_t, T*, C)’:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_reduce.hpp:28:16: error: ‘threadIdx’ was not declared in this scope
   28 |   size_t tid = threadIdx.x;
      |                ^~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_reduce.hpp:36:20: error: ‘blockDim’ was not declared in this scope
   36 |   for(size_t i=tid+blockDim.x; i<N; i+=blockDim.x) {
      |                    ^~~~~~~~
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_reduce.hpp:40:3: error: there are no arguments to ‘__syncthreads’ that depend on a template parameter, so a declaration of ‘__syncthreads’ must be available [-fpermissive]
   40 |   __syncthreads();
      |   ^~~~~~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_reduce.hpp:40:3: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated)
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_reduce.hpp:42:18: error: ‘blockDim’ was not declared in this scope
   42 |   for(size_t s = blockDim.x / 2; s > 32; s >>= 1) {
      |                  ^~~~~~~~
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_reduce.hpp:46:5: error: there are no arguments to ‘__syncthreads’ that depend on a template parameter, so a declaration of ‘__syncthreads’ must be available [-fpermissive]
   46 |     __syncthreads();
      |     ^~~~~~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_reduce.hpp: In lambda function:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_reduce.hpp:188:34: error: expected primary-expression before ‘<’ token
  188 |     cuda_reduce<I, T, C, false><<<1, B, B*sizeof(T), stream>>>(
      |                                  ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_reduce.hpp:188:62: error: expected primary-expression before ‘>’ token
  188 |     cuda_reduce<I, T, C, false><<<1, B, B*sizeof(T), stream>>>(
      |                                                              ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_reduce.hpp: In lambda function:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_reduce.hpp:206:33: error: expected primary-expression before ‘<’ token
  206 |     cuda_reduce<I, T, C, true><<<1, B, B*sizeof(T), stream>>>(
      |                                 ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_reduce.hpp:206:61: error: expected primary-expression before ‘>’ token
  206 |     cuda_reduce<I, T, C, true><<<1, B, B*sizeof(T), stream>>>(
      |                                                             ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_reduce.hpp: In lambda function:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_reduce.hpp:224:34: error: expected primary-expression before ‘<’ token
  224 |     cuda_reduce<I, T, C, false><<<1, B, B*sizeof(T), stream>>>(
      |                                  ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_reduce.hpp:224:62: error: expected primary-expression before ‘>’ token
  224 |     cuda_reduce<I, T, C, false><<<1, B, B*sizeof(T), stream>>>(
      |                                                              ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_reduce.hpp: In lambda function:
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_reduce.hpp:242:33: error: expected primary-expression before ‘<’ token
  242 |     cuda_reduce<I, T, C, true><<<1, B, B*sizeof(T), stream>>>(
      |                                 ^
/home/mlxd/BugFixes/Ref/jet/Build/_deps/taskflow-src/taskflow/cuda/cuda_algorithm/cuda_reduce.hpp:242:61: error: expected primary-expression before ‘>’ token
  242 |     cuda_reduce<I, T, C, true><<<1, B, B*sizeof(T), stream>>>(
      |                                                             ^
In file included from /home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp:11,
                 from /home/mlxd/BugFixes/Ref/jet/test/Test_CudaTensor.cpp:10:
/home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp: In destructor ‘Jet::CudaTensor<T, CUDA_DEVICE>::~CudaTensor()’:
/home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp:215:50: error: expected primary-expression before ‘ctx’
  215 |         JET_CUDA_IS_SUCCESS(tf::cudaScopedDevice ctx(CUDA_DEVICE);
      |                                                  ^~~
/home/mlxd/BugFixes/Ref/jet/include/jet/Abort.hpp:31:11: note: in definition of macro ‘JET_ABORT_IF_NOT’
   31 |     if (!(expression)) {                                                       \
      |           ^~~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp:215:9: note: in expansion of macro ‘JET_CUDA_IS_SUCCESS’
  215 |         JET_CUDA_IS_SUCCESS(tf::cudaScopedDevice ctx(CUDA_DEVICE);
      |         ^~~~~~~~~~~~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp:215:50: error: expected ‘)’ before ‘ctx’
  215 |         JET_CUDA_IS_SUCCESS(tf::cudaScopedDevice ctx(CUDA_DEVICE);
      |                                                  ^~~
/home/mlxd/BugFixes/Ref/jet/include/jet/Abort.hpp:31:11: note: in definition of macro ‘JET_ABORT_IF_NOT’
   31 |     if (!(expression)) {                                                       \
      |           ^~~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp:215:9: note: in expansion of macro ‘JET_CUDA_IS_SUCCESS’
  215 |         JET_CUDA_IS_SUCCESS(tf::cudaScopedDevice ctx(CUDA_DEVICE);
      |         ^~~~~~~~~~~~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/include/jet/Abort.hpp:31:10: note: to match this ‘(’
   31 |     if (!(expression)) {                                                       \
      |          ^
/home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensorHelpers.hpp:26:5: note: in expansion of macro ‘JET_ABORT_IF_NOT’
   26 |     JET_ABORT_IF_NOT(err == cudaSuccess, cudaGetErrorString(err))
      |     ^~~~~~~~~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp:215:9: note: in expansion of macro ‘JET_CUDA_IS_SUCCESS’
  215 |         JET_CUDA_IS_SUCCESS(tf::cudaScopedDevice ctx(CUDA_DEVICE);
      |         ^~~~~~~~~~~~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp:215:66: error: expected ‘)’ before ‘;’ token
  215 |         JET_CUDA_IS_SUCCESS(tf::cudaScopedDevice ctx(CUDA_DEVICE);
      |                                                                  ^
/home/mlxd/BugFixes/Ref/jet/include/jet/Abort.hpp:31:11: note: in definition of macro ‘JET_ABORT_IF_NOT’
   31 |     if (!(expression)) {                                                       \
      |           ^~~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp:215:9: note: in expansion of macro ‘JET_CUDA_IS_SUCCESS’
  215 |         JET_CUDA_IS_SUCCESS(tf::cudaScopedDevice ctx(CUDA_DEVICE);
      |         ^~~~~~~~~~~~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/include/jet/Abort.hpp:31:8: note: to match this ‘(’
   31 |     if (!(expression)) {                                                       \
      |        ^
/home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensorHelpers.hpp:26:5: note: in expansion of macro ‘JET_ABORT_IF_NOT’
   26 |     JET_ABORT_IF_NOT(err == cudaSuccess, cudaGetErrorString(err))
      |     ^~~~~~~~~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp:215:9: note: in expansion of macro ‘JET_CUDA_IS_SUCCESS’
  215 |         JET_CUDA_IS_SUCCESS(tf::cudaScopedDevice ctx(CUDA_DEVICE);
      |         ^~~~~~~~~~~~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp:215:66: error: suggest braces around empty body in an ‘if’ statement [-Werror=empty-body]
  215 |         JET_CUDA_IS_SUCCESS(tf::cudaScopedDevice ctx(CUDA_DEVICE);
      |                                                                  ^
/home/mlxd/BugFixes/Ref/jet/include/jet/Abort.hpp:31:11: note: in definition of macro ‘JET_ABORT_IF_NOT’
   31 |     if (!(expression)) {                                                       \
      |           ^~~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp:215:9: note: in expansion of macro ‘JET_CUDA_IS_SUCCESS’
  215 |         JET_CUDA_IS_SUCCESS(tf::cudaScopedDevice ctx(CUDA_DEVICE);
      |         ^~~~~~~~~~~~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/include/jet/Abort.hpp:31:21: error: expected ‘;’ before ‘)’ token
   31 |     if (!(expression)) {                                                       \
      |                     ^
/home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensorHelpers.hpp:26:5: note: in expansion of macro ‘JET_ABORT_IF_NOT’
   26 |     JET_ABORT_IF_NOT(err == cudaSuccess, cudaGetErrorString(err))
      |     ^~~~~~~~~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp:215:9: note: in expansion of macro ‘JET_CUDA_IS_SUCCESS’
  215 |         JET_CUDA_IS_SUCCESS(tf::cudaScopedDevice ctx(CUDA_DEVICE);
      |         ^~~~~~~~~~~~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp: In instantiation of ‘Jet::CudaTensor<T, CUDA_DEVICE>::~CudaTensor() [with T = float2; int CUDA_DEVICE = 0]’:
/home/mlxd/BugFixes/Ref/jet/test/Test_CudaTensor.cpp:54:20:   required from here
/home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensorHelpers.hpp:26:26: error: value computed is not used [-Werror=unused-value]
   26 |     JET_ABORT_IF_NOT(err == cudaSuccess, cudaGetErrorString(err))
/home/mlxd/BugFixes/Ref/jet/include/jet/Abort.hpp:31:11: note: in definition of macro ‘JET_ABORT_IF_NOT’
   31 |     if (!(expression)) {                                                       \
      |           ^~~~~~~~~~
/home/mlxd/BugFixes/Ref/jet/include/jet/CudaTensor.hpp:215:9: note: in expansion of macro ‘JET_CUDA_IS_SUCCESS’
  215 |         JET_CUDA_IS_SUCCESS(tf::cudaScopedDevice ctx(CUDA_DEVICE);
      |         ^~~~~~~~~~~~~~~~~~~
make[2]: *** [test/CMakeFiles/test_cutensor.dir/build.make:76: test/CMakeFiles/test_cutensor.dir/Test_CudaTensor.cpp.o] Interrupt
make[1]: *** [CMakeFiles/Makefile2:890: test/CMakeFiles/test_cutensor.dir/all] Interrupt
make: *** [Makefile:146: all] Interrupt

Additional information
Any additional information, configuration or data that might be necessary to reproduce the issue.

Thanks for writing up the issue! I guess this is what happens when you don't have proper CI in place for GPU code.
We can make an 0.2.1 release with the relevant patch when its ready; however, until then, the GPU benchmarks should be run using Jet at commit d74502bef054cc4d9faff7ccc74137b3ad084357.


Remote Desktop: Mouse cursor for text selection is black on black

VSCode Version: Code - Insiders 1.3.0-insider (d0c2b891903d73e83dcdc7786398ebfa764fc4ee, 2016-06-28T05:07:32.441Z)
OS Version: Windows_NT ia32 6.3.9600

Steps to Reproduce:

Remote Desktop for OSX to Windows 8.1 (not sure if RD matters).
Move the mouse inside the editor area or console text area.
The cursor for text selection shows mostly black on black background and is very difficult to see at all.

@chrmarti I'm assuming you're using the dark theme. I tried on Windows 10 and the I is rendered by Windows in white. Maybe it does have something to do with your setup? Do you see the Windows cursor or the OSX cursor?

I'm using the default Dark+. The cursor seems to be from Windows (no extra horizontal line in the middle). It's Windows 8.1, but nothing else I'm aware of that would make the setup special.

This is how it looks for me:

Here are my cursor pointer settings:

I am on Windows 10. How does the cursor look like for you if you visit https://code.visualstudio.com/ and hover over the copyright text at the bottom in Chrome?

Indeed, the cursor shows the same behavior (black on black text selection cursor) on the code.visualstudio.com website.

@chrmarti In this case, please file a bug against Chromium (or if the black on black text selection is reproducible in IE against Windows)

Appears to be a known issue with Remote Desktop for OSX. Older versions reportedly did not have this. The discussion linked below suggests to swap out the text selection pointer with "beam_r.cur", that works for me.
(https://social.technet.microsoft.com/Forums/windowsserver/en-US/cf05826e-63a4-49d9-b812-7a4695832ab8/rdc-mac-version-8024091-can-not-see-cursor-in-any-editor-with-black-background-because-it-is?forum=winRDc)

@chrmarti Nice!

@alexandrudima Thanks for helping track this down!


Provide an example in the samples or documentation for doing code coverage

Please provide an example through documentation or sample project or in this issue of how to do code coverage using gwtmockito and specifically with GwtMockitoTestRunner. I've read the issue #65 and clearly there are some problems with jacoco and I've tried the offline instrumentation and it doesn't work. We happen to be using Ant but I don't mind how you do the example.
I don't mind the solution or framework if it is emma, cobertura or some other idea. Custom jar or command line etc..
If it is not possible then unfortunately this library doesn't have any real use or purpose as code coverage metrics are nowadays mandatory in most places.
Thanks

Maybe the solution is to go to PowerMock who are addressing this problem. Perhaps it could be possible to use bytebuddy as well from GWTMockito??


fix some Symbol methods signature

This fixes some Symbol methods signature, based on the equivalent String methods.
Motivation
Improving accuracy of Sorbet checks.
Test plan
I haven't found any test for this class yet.

We have a policy of testing changes to Sorbet against Stripe's codebase before
merging them. I've kicked off a test run for the current PR.  When the build
finishes, I'll share with you whether or how it failed. Thanks!
Stripe employees can see the build result here:
→ https://go/builds/bui_HRaxB5b6w46xUN

Could you rebase off of master? The bug that failed your build was fixed yesterday.

Could you rebase off of master? The bug that failed your build was fixed yesterday.

Done! 👍

We have a policy of testing changes to Sorbet against Stripe's codebase before
merging them. I've kicked off a test run for the current PR.  When the build
finishes, I'll share with you whether or how it failed. Thanks!
Stripe employees can see the build result here:
→ https://go/builds/bui_HRn03PVM4ni5UU

We have a policy of testing changes to Sorbet against Stripe's codebase before
merging them. I've kicked off a test run for the current PR.  When the build
finishes, I'll share with you whether or how it failed. Thanks!
Stripe employees can see the build result here:
→ https://go/builds/bui_HRn7qDjCDC56KY

Build passing on stripe ci: https://go/builds/bui_HRnSHmYbi8DzDM

Thank you, too! 🙂


State showing offline when alseep since 2024.14.9

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
Since the update 2024.14.9, my cas is always showing as Offline state when it should be Alseep.
I know this has been a common issue but as far as I understood, this has been fixed.
Therefore, I don't know why the issue happens again on my side.
It used to work well before this update (to be honnest I'm not 100% sure the bug appeared just after the update, but fore sure around this period)
It's probably just a miss configuration or a minor bug on my side but if anyone still encounters the issue, I would be pleased to contribute to a bug fix.
Thanks :)
Expected Behavior
Car is showing Offline when it should be Asleep
Steps To Reproduce
Tesla Model 3 LR Highland (2024)

Park the car
Wait for it to go to sleep
See the state in Teslamate

Relevant log output
2024-07-07 03:31:33.983 [info] Version: 1.29.2
2024-07-07 03:31:35.142 [info] POST https://auth.tesla.com/oauth2/v3/token -> 200 (647.961 ms)
2024-07-07 03:31:35.142 [info] Refreshed api tokens
2024-07-07 03:31:36.391 [info] Scheduling token refresh in 6 h
2024-07-07 03:31:36.414 [info] Running TeslaMateWeb.Endpoint with cowboy 2.10.0 at :::4000 (http)
2024-07-07 03:31:36.630 [info] Access TeslaMateWeb.Endpoint at http://localhost
2024-07-07 03:31:36.856 [info] Starting logger for 'Black Swan'
2024-07-07 03:31:38.651 [info] MQTT connection has been established
2024-07-07 03:31:39.524 car_id=1 [info] Start / :offline
2024-07-07 09:31:36.446 [info] Refreshing access token ...
2024-07-07 09:31:37.106 [info] POST https://auth.tesla.com/oauth2/v3/token -> 200 (607.697 ms)
2024-07-07 09:31:37.142 [info] Scheduling token refresh in 6 h
2024-07-07 10:11:07.187 car_id=1 [info] Start / :online
2024-07-07 10:11:07.303 car_id=1 [info] Connecting ...
2024-07-07 10:11:07.322 [info] Start of drive initiated by: %TeslaApi.Vehicle.State.Drive{active_route_destination: nil, active_route_energy_at_arrival: nil, active_route_latitude: 50.612271, active_route_longitude: XXX, active_route_miles_to_arrival: nil, active_route_minutes_to_arrival: nil, active_route_traffic_minutes_delay: 0.0, gps_as_of: -823242471, heading: 300, latitude: XXX, longitude: XXX, native_latitude: XXX, native_location_supported: 1, native_longitude: XXX, native_type: "wgs", power: 1, shift_state: "D", speed: 0, timestamp:<PHONE_NUMBER>485}
2024-07-07 10:11:07.323 car_id=1 [info] Driving / Start
2024-07-07 10:12:01.496 [info] End of drive initiated by: %TeslaApi.Vehicle.State.Drive{active_route_destination: nil, active_route_energy_at_arrival: nil, active_route_latitude: nil, active_route_longitude: nil, active_route_miles_to_arrival: nil, active_route_minutes_to_arrival: nil, active_route_traffic_minutes_delay: nil, gps_as_of:<PHONE_NUMBER>, heading: 300, latitude: XXX, longitude: XXX, native_latitude: XXX, native_location_supported: 1, native_longitude: XXX, native_type: "wgs", power: 1, shift_state: "P", speed: 0, timestamp:<PHONE_NUMBER>935}
2024-07-07 10:12:01.496 car_id=1 [info] Driving / Ended / 0 km – 0 min
2024-07-07 10:12:01.497 car_id=1 [info] Start / :online
2024-07-07 10:12:03.285 [info] Start of drive initiated by: %TeslaApi.Stream.Data{time: ~U[2024-07-07 10:11:53.777Z], speed: 0, odometer: 3644.3, soc: 56, elevation: 40, est_heading: 300, est_lat: 50.612285, est_lng: 3.078967, power: 1, shift_state: "D", range: 189, est_range: 160, heading: 301}
2024-07-07 10:12:03.286 car_id=1 [info] Driving / Start
2024-07-07 10:12:14.689 [info] GET https://nominatim.openstreetmap.org/reverse -> 200 (188.813 ms)
2024-07-07 10:12:15.178 [info] GET https://nominatim.openstreetmap.org/reverse -> 200 (480.498 ms)
2024-07-07 10:12:15.198 [info] End of drive initiated by: %TeslaApi.Vehicle.State.Drive{active_route_destination: "", active_route_energy_at_arrival: 53, active_route_latitude: XXX, active_route_longitude: XXX, active_route_miles_to_arrival: XXX, active_route_minutes_to_arrival: 20.633333, active_route_traffic_minutes_delay: 0.0, gps_as_of:<PHONE_NUMBER>, heading: 266, latitude: XXX, longitude: 3.078936, native_latitude: XXX, native_location_supported: 1, native_longitude: XXX, native_type: "wgs", power: 1, shift_state: "P", speed: 1, timestamp:<PHONE_NUMBER>938}
2024-07-07 10:12:15.198 car_id=1 [info] Driving / Ended / 0 km – 0 min
2024-07-07 10:12:15.199 car_id=1 [info] Start / :online
2024-07-07 10:12:17.312 [info] Start of drive initiated by: %TeslaApi.Stream.Data{time: ~U[2024-07-07 10:12:07.803Z], speed: 0, odometer: 3644.3, soc: 56, elevation: 40, est_heading: 265, est_lat: 50.612298, est_lng: 3.07894, power: 1, shift_state: "D", range: 189, est_range: 160, heading: 270}
2024-07-07 10:12:17.312 car_id=1 [info] Driving / Start
2024-07-07 10:33:36.255 [info] GET https://nominatim.openstreetmap.org/reverse -> 200 (270.248 ms)
2024-07-07 10:33:36.768 [info] GET https://nominatim.openstreetmap.org/reverse -> 200 (502.666 ms)
2024-07-07 10:33:36.817 [info] End of drive initiated by: %TeslaApi.Vehicle.State.Drive{active_route_destination: nil, active_route_energy_at_arrival: 53, active_route_latitude: 50.673895, active_route_longitude: 3.191087, active_route_miles_to_arrival: nil, active_route_minutes_to_arrival: nil, active_route_traffic_minutes_delay: 0.0, gps_as_of:<PHONE_NUMBER>, heading: 127, latitude: XXX, longitude: XXX, native_latitude: 50.673293, native_location_supported: 1, native_longitude: XXX, native_type: "wgs", power: 1, shift_state: "P", speed: 0, timestamp:<PHONE_NUMBER>984}
2024-07-07 10:33:36.817 car_id=1 [info] Driving / Ended / 16 km – 21 min
2024-07-07 10:33:36.818 car_id=1 [info] Start / :online
2024-07-07 10:33:52.285 car_id=1 [warning] Received stale stream data: %TeslaApi.Stream.Data{time: ~U[2024-07-07 10:33:42.932Z], speed: 0, odometer: 3654.3, soc: 53, elevation: 43, est_heading: 127, est_lat: 50.673293, est_lng: 3.191703, power: 1, shift_state: "P", range: 181, est_range: 175, heading: 129}
2024-07-07 10:36:16.445 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/929774667546738/vehicle_data -> 408 (9072.296 ms)
2024-07-07 10:36:16.445 [warning] TeslaApi.Error / %{"error" => "{\"error\": \"timeout\"}", "error_description" => "", "response" => nil}
2024-07-07 10:36:16.446 car_id=1 [error] Error / :unknown
2024-07-07 10:36:45.544 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/929774667546738/vehicle_data -> 408 (9097.130 ms)
2024-07-07 10:36:45.545 [warning] TeslaApi.Error / %{"error" => "{\"error\": \"timeout\"}", "error_description" => "", "response" => nil}
2024-07-07 10:36:45.545 car_id=1 [error] Error / :unknown
2024-07-07 10:37:14.622 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/929774667546738/vehicle_data -> 408 (9075.594 ms)
2024-07-07 10:37:14.622 [warning] TeslaApi.Error / %{"error" => "{\"error\": \"timeout\"}", "error_description" => "", "response" => nil}
2024-07-07 10:37:14.623 car_id=1 [error] Error / :unknown
2024-07-07 10:37:36.947 [warning] GET https://owner-api.teslamotors.com/api/1/vehicles/929774667546738/vehicle_data -> 540 (2322.419 ms)
2024-07-07 10:37:36.947 [warning] TeslaApi.Error / vehicle error: it is online but not responsive
2024-07-07 10:37:36.947 car_id=1 [error] Error / :unknown
2024-07-07 10:37:59.339 [warning] GET https://owner-api.teslamotors.com/api/1/vehicles/929774667546738/vehicle_data -> 540 (2391.172 ms)
2024-07-07 10:37:59.340 [warning] TeslaApi.Error / vehicle error: it is online but not responsive
2024-07-07 10:37:59.340 car_id=1 [error] Error / :unknown
2024-07-07 10:38:19.790 car_id=1 [warning] User present ...
2024-07-07 10:38:34.101 [notice]     :alarm_handler: {:set, {TeslaMate.Vehicles.Vehicle_1_api_error, :fuse_blown}}
2024-07-07 10:38:50.245 [info] Start of drive initiated by: %TeslaApi.Vehicle.State.Drive{active_route_destination: nil, active_route_energy_at_arrival: nil, active_route_latitude: 50.673895, active_route_longitude: 3.191087, active_route_miles_to_arrival: nil, active_route_minutes_to_arrival: nil, active_route_traffic_minutes_delay: 0.0, gps_as_of:<PHONE_NUMBER>, heading: 127, latitude: XXX, longitude: XXX, native_latitude: XXX, native_location_supported: 1, native_longitude: XXX, native_type: "wgs", power: 1, shift_state: "D", speed: 0, timestamp:<PHONE_NUMBER>492}
2024-07-07 10:38:50.246 car_id=1 [info] Driving / Start
2024-07-07 10:39:01.409 [warning] Too many disconnects from streaming API
2024-07-07 10:39:01.409 car_id=1 [info] Creating new connection …
2024-07-07 10:39:01.411 car_id=1 [info] Disconnecting ...
2024-07-07 10:39:01.428 car_id=1 [info] Connecting ...
2024-07-07 10:41:13.275 [info] GET https://nominatim.openstreetmap.org/reverse -> 200 (178.166 ms)
2024-07-07 10:41:13.774 [info] GET https://nominatim.openstreetmap.org/reverse -> 200 (492.468 ms)
2024-07-07 10:41:13.802 [info] End of drive initiated by: %TeslaApi.Vehicle.State.Drive{active_route_destination: nil, active_route_energy_at_arrival: 53, active_route_latitude: XXX, active_route_longitude: XXX, active_route_miles_to_arrival: nil, active_route_minutes_to_arrival: nil, active_route_traffic_minutes_delay: 0.0, gps_as_of: XXX, heading: 303, latitude: 50.676135, longitude: XXX, native_latitude: XXX, native_location_supported: 1, native_longitude: XXX, native_type: "wgs", power: 1, shift_state: "P", speed: 0, timestamp:<PHONE_NUMBER>405}
2024-07-07 10:41:13.802 car_id=1 [info] Driving / Ended / 1 km – 2 min
2024-07-07 10:41:13.803 car_id=1 [info] Start / :online
2024-07-07 10:45:00.648 car_id=1 [info] Suspending logging
2024-07-07 10:45:25.098 [warning] Too many disconnects from streaming API
2024-07-07 10:45:25.098 car_id=1 [info] Creating new connection …
2024-07-07 10:45:25.098 car_id=1 [info] Disconnecting ...
2024-07-07 10:45:25.109 car_id=1 [info] Connecting ...
2024-07-07 10:45:34.106 [notice]     :alarm_handler: {:clear, TeslaMate.Vehicles.Vehicle_1_api_error}
2024-07-07 10:51:49.325 [warning] Too many disconnects from streaming API
2024-07-07 10:51:49.325 car_id=1 [info] Creating new connection …
2024-07-07 10:51:49.325 car_id=1 [info] Disconnecting ...
2024-07-07 10:51:49.335 car_id=1 [info] Connecting ...
2024-07-07 10:58:14.556 [warning] Too many disconnects from streaming API
2024-07-07 10:58:14.556 car_id=1 [info] Creating new connection …
2024-07-07 10:58:14.556 car_id=1 [info] Disconnecting ...
2024-07-07 10:58:14.566 car_id=1 [info] Connecting ...
2024-07-07 11:00:38.877 [info] Streaming API: Vehicle offline
2024-07-07 11:00:38.878 car_id=1 [warning] Stream reports vehicle as offline, fetching vehicle state ...
2024-07-07 11:00:39.249 car_id=1 [info] Start / :offline
2024-07-07 11:00:39.285 car_id=1 [info] Disconnecting ...
2024-07-07 12:09:36.847 car_id=1 [info] Start / :online
2024-07-07 12:09:36.898 car_id=1 [info] Connecting ...
2024-07-07 12:09:58.862 [info] Start of drive initiated by: %TeslaApi.Stream.Data{time: ~U[2024-07-07 12:09:56.545Z], speed: 0, odometer: 3654.8, soc: 53, elevation: 32, est_heading: 303, est_lat: XXX, est_lng: XXX, power: 2, shift_state: "D", range: 181, est_range: 175, heading: 308}
2024-07-07 12:09:58.862 car_id=1 [info] Driving / Start
2024-07-07 12:30:42.613 [info] GET https://nominatim.openstreetmap.org/reverse -> 200 (177.011 ms)
2024-07-07 12:30:43.088 [info] GET https://nominatim.openstreetmap.org/reverse -> 200 (469.040 ms)
2024-07-07 12:30:43.118 [info] End of drive initiated by: %TeslaApi.Vehicle.State.Drive{active_route_destination: nil, active_route_energy_at_arrival: 50, active_route_latitude: 50.612271, active_route_longitude: 3.07919, active_route_miles_to_arrival: nil, active_route_minutes_to_arrival: nil, active_route_traffic_minutes_delay: 0.0, gps_as_of:<PHONE_NUMBER>, heading: 301, latitude: XXX, longitude: XXX, native_latitude: XXX, native_location_supported: 1, native_longitude: XXX, native_type: "wgs", power: 1, shift_state: "P", speed: 0, timestamp:<PHONE_NUMBER>669}
2024-07-07 12:30:43.118 car_id=1 [info] Driving / Ended / 17 km – 21 min
2024-07-07 12:30:43.119 car_id=1 [info] Start / :online
2024-07-07 12:33:16.042 car_id=1 [warning] Received stale stream data: %TeslaApi.Stream.Data{time: ~U[2024-07-07 12:33:13.882Z], speed: 0, odometer: 3665.7, soc: 50, elevation: 33, est_heading: 301, est_lat: 50.612304, est_lng: 3.078974, power: 0, shift_state: "P", range: 171, est_range: 195, heading: 300}
2024-07-07 12:34:24.915 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/929774667546738/vehicle_data -> 408 (9113.926 ms)
2024-07-07 12:34:24.916 [warning] TeslaApi.Error / %{"error" => "{\"error\": \"timeout\"}", "error_description" => "", "response" => nil}
2024-07-07 12:34:24.916 car_id=1 [error] Error / :unknown
2024-07-07 12:34:44.988 [info] GET https://owner-api.teslamotors.com/api/1/vehicles/929774667546738/vehicle_data -> 408 (69.875 ms)
2024-07-07 12:34:56.404 car_id=1 [info] Start / :offline
2024-07-07 12:34:56.426 car_id=1 [info] Disconnecting ...
2024-07-07 12:52:47.529 [info] GET /geo-fences/new
2024-07-07 12:52:47.733 [info] Sent 200 in 204ms
2024-07-07 12:52:48.739 [info] GET /
2024-07-07 12:52:48.762 [info] Sent 200 in 22ms

Screenshots

Additional data
No response
Type of installation
Docker
Version
v1.24.1

Please see #3753. Healthy discussion there.

Please see #3753. Healthy discussion there.

Thanks I'll take a look, totally forgot to look at the discussion part


RFC: set gasnetex by default when building with USE_GASNET/Legion_USE_GASNet

Realm's gasnetex backend has been stable for some time now. I am wondering if it makes sense to set it as the default, i.e., when USE_GASNET=1 (Makefile build) or Legion_USE_GASNet=ON (CMake build) we set REALM_NETWORKS=gasnetex / Legion_NETWORKS=gasnetex instead of gasnet1.
If you were already setting REALM_NETWORKS/Legion_NETWORKS this would have no effect.
Thoughts?
Here's a sample MR based on this approach: https://gitlab.com/StanfordLegion/legion/-/merge_requests/840

I'm not sure if the issue has been fixed but AFAIK the gasnetex layer requires setting the runtime flag -gex:obcount followed by a large number, which depends on the number of nodes involved in a calculation. The last time I've seen an execution failing because of the missing -gex:obcount there wasn't any error message and it was up to the user to understand that the flag was required. I believe that switching by default to the gasnetex backend without fixing the issue could break many applications that need to run at large scale.

I have run S3D on 2048 nodes (16k ranks) on Frontier using gasnetex without needing -gex:obcount. This could be application dependent though.

Yes, I have seen hangs without -gex:obcount as well.

I'm generally in favor. gasnetex has shown better performance than gasnet1 for legate, but we have run into some papercuts when using gasnetex that don't happen with gasnet1. These are bit old, so they may have been fixed since.

Slow memory registration at startup: gasnetex would try to register all of -ll:csize with the NIC, and that could lead to multi-minute delays at startup.

-gex:obcount issue: With gasnet1 there was only a small number of endpoints per rank, that require the allocation of an output buffer. With gasnetex there's now also 2 endpoints per GPU (one for fsize and one for ib_fsize) (because we can have direct communication between GPUs), so now the default limit may not be large enough if we need to instantiate all endpoints, which happens in cases of all-to-all communication. Realm can't calculate a good setting at gasnet initialization time, because it doesn't know at that point how many GPU processors are going to be created. Setting -gex:obcount to (4 + 2 * gpus/node) * nodes should be sufficient for the worst-case scenario, but this pessimistic setting will almost always be overkill (if you don't have true all-to-all communication). Previously this would result in a hang.

Too many simultaneous local client threads:  With -gex:immediate 1 (default) meta-tasks will inject AM requests directly into gasnet, and gasnet wants to record all the thread IDs that have ever called into it, in a statically-sized data structure, and this limit can be reached at larger scales, producing an error message like GASNet Extended API: Too many simultaneous local client threads (limit=256). To raise this limit, configure GASNet using --with-max-pthreads-per-node=N. We work around this by setting -gex:immediate 0.

Slow memory registration at startup

Fixed.

-gex:obcount issue

Not fixed.  Fixing should be a gate to switching gasnetex to the default.

Too many simultaneous local client threads

Requires both -gex:immediate 1 (the default) and also -ll:force_kthreads (not the default, but a very common opt-in) to occur.  Should eventually be fixed, but probably doesn't need to be a blocker.

-gex:obcount issue

Not fixed. Fixing should be a gate to switching gasnetex to the default.

Could someone explain what this issue actually is? What causes it, and what options do we have for fixing it? Is there a timeline on a fix?

Too many simultaneous local client threads

Requires both -gex:immediate 1 (the default) and also -ll:force_kthreads (not the default, but a very common opt-in) to occur. Should eventually be fixed, but probably doesn't need to be a blocker.

Same.

Could someone explain what this issue actually is? What causes it, and what options do we have for fixing it? Is there a timeline on a fix?

I talked with @streichler. My understanding of this issue is that Realm makes a certain number of output buffers for receiving messages from senders in the registered memory segment for GASNet. Right now Realm assigns these buffers to senders as it receives messages, but once a buffer is assigned to a sender it will always be associated with that sender. If you run out of buffers because they've all been assigned to other senders then nothing can receive the incoming message and we hang. As @streichler suggested there are two solutions:

Allocate enough of these buffers on every node using the formula that Manolis gave above to ensure that there are enough buffers so every sender can have one and therefore you'll never run out. This is overly pessimistic and results in memory consumption on each node that grows with the scale of the machine, so while it is a sound work-around it's not a reasonable one if we're going to care about scalability.
Have a way to temporally multiplex (share) buffers between endpoints so that multiple endpoints can receive messages into the same buffer in a non-interfering way.

Sean says:

I think (2) is the better answer, but it requires messing with a bunch of finicky and aggressive multi-threaded code and neither breaking it nor slowing it down

I think @eddy16112 is going to take a look at this now that he has a reproducer although it's likely going to take a while to get all the details right and get it tested well.

Same.

GASNet right now has a build parameter that puts a static upper bound on the number of threads that can send active messages, presumably because they have some per-thread data structures for performance. If you run with -gex:immediate 1 Realm will send messages immediately instead of sticking them in a queue for active message sender threads to push out, which means that pretty much any Realm thread can send an active message for things like event triggers or DMAs or ... whatever. If you also run with -ll:force_kthreads, then Realm will create and destroy many more threads for running tasks on processors. From GASNets' perspective each of those threads is a new sender thread (GASNet doesn't track when threads are destroyed; once it's seen a thread it assumes it's alive forever). So if you run with both -gex:immediate 1 and -ll:force_kthreads it's not surprising that you quickly exceed the static upper bound on the number of threads that GASNet sets for sending active messages. I don't think we need to fix this one other than maybe just automatically switching -gex:immediate to 0 if -ll:force_kthreads is set.

I am trying to figure out if we can turn the obcount hang into an error message telling people to increase the obcount. I reproduced the hang with the memspeed. Apparently, the program will fall into the overflow code path and never send the packet, which is the place the hang comes from. https://gitlab.com/StanfordLegion/legion/-/blob/master/runtime/realm/gasnetex/gasnetex_internal.cc?ref_type=heads#L1841-1854 @streichler is this code path typical for the obcount hang? Is there any other case that will fall into the same code path? If not, can we throw an error message of Insufficient obcount here?

Just for myself, the updated line numbers are https://gitlab.com/StanfordLegion/legion/-/blob/master/runtime/realm/gasnetex/gasnetex_internal.cc#L1890-1904


[beta-1.70] backport #12165

Beta backports:

https://github.com/rust-lang/cargo/pull/12165

Adjusted a bit since TomlDebugInfo::None was not there in 1.70.0. It was a simple u32 0.

In order to make CI pass, the following PRs are also cherry-picked:

https://github.com/rust-lang/cargo/pull/12065
https://github.com/rust-lang/cargo/pull/12136

https://github.com/rust-lang/cargo/actions/runs/5057792442/jobs/9077009414?pr=12167
-Zbuild-std failed. This is going to be painful. The fix of build-std shouldn't be backported but without a backport we cannot bypass the CI pipeline. I guess the obvious way is running build-std only when the PR aims to merging into master. Let's see how to solve this.

The fix of build-std shouldn't be backported but without a backport we cannot bypass the CI pipeline

Can you say why not? I would imagine backporting #12088 should be fine.

I guess the obvious way is running build-std only when the PR aims to merging into master. Let's see how to solve this.

It seems reasonable to stop running nightly tests on beta/stable. It might be a little tricky to do it correctly in CI due to the way bors works, so I'm not sure how that can be done.

The fix of build-std shouldn't be backported but without a backport we cannot bypass the CI pipeline

Can you say why not? I would imagine backporting #12088 should be fine.

libsysroot only exists in nightly right now. I didn't think about it much but I believe some stuff like library/sysroot directooy cannot be found on beta and it may fail something.

I guess the obvious way is running build-std only when the PR aims to merging into master. Let's see how to solve this.

It seems reasonable to stop running nightly tests on beta/stable. It might be a little tricky to do it correctly in CI due to the way bors works, so I'm not sure how that can be done.

Yeah I've tried but no luck. bors knows nothing about branches on rust-lang/cargo 😞.

libsysroot only exists in nightly right now. I didn't think about it much but I believe some stuff like library/sysroot directooy cannot be found on beta and it may fail something.

The build-std tests are disabled on stable and beta, so I don't think it should be a concern. The only place they run is in Cargo's CI on the nightly builders, and those are always using the latest nightly.  These tests don't run on rust-lang/rust, so it isn't a concern there.

I think it might be a bit too late to get this into beta. It's not clear to me how likely it is that a project will run into this issue. If you think it is sufficiently rare, then this should probably be closed.

Yup sure. Given they already have some workaround I think it's fine just closing this.
Actually I was waiting for #12181. Still want it or  something else to get landed.


Unable to install

Throwing this error (windows, latest node v)
C:\Users\Nick\Desktop\webapp\frontend>npm i @vue-hero-icons/outline
npm ERR! code ENOENT
npm ERR! syscall spawn git
npm ERR! path git
npm ERR! errno -4058
npm ERR! enoent Error while executing:
npm ERR! enoent undefined ls-remote -h -t https://github.com/refactoringui/heroicons.git
npm ERR! enoent
npm ERR! enoent
npm ERR! enoent spawn git ENOENT
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

npm ERR!      C:\Users\Nick\AppData\Roaming\npm-cache\_logs\2020-07-21T20_22_52_561Z-debug.log

nvm, just realised git doesn't want to run in the cli for some weird reason :/


Omero 5.4.6

Prep for coming 5.4.6
provisionally set Thursday as release date

Staged at https://snoopycrimecop.github.io/www.openmicroscopy.org/omero/downloads/ and https://snoopycrimecop.github.io/www.openmicroscopy.org/2018/05/10/omero-5-4-6.html


cbuildgen / make cmake default config files more generic with toolchain version

Hi
Default cmake config files:
https://github.com/Open-CMSIS-Pack/devtools/tree/main/tools/buildmgr/cbuildgen/config
For ex, I am with GCC 10.3.1, but GCC.10.2.1.cmake is used.
It seems that some parts will not be correct:
https://github.com/Open-CMSIS-Pack/devtools/blob/main/tools/buildmgr/cbuildgen/config/GCC.10.2.1.cmake#L156-L158
We can't know which version has all users... How can we make these file more generic ?
Thx

By design each cmake file in this directory should reflect what is installed in the environment. Different compiler versions can potentially have differences impacting this mapping.
In my opinion CMSIS-Build needs a toolchain discover and register utility.
It could enclose generic templates for the supported toolchain version ranges.
Such utility could automatically recognize compatible toolchains for example by searching them in the system PATH and in the most common system directories, check their versions and if compatible generate/register them in $CMSIS_COMPILER_ROOT.
It could also take as argument one or more specified directories to register or unregister toolchains contained in it.
@jeromecoutant What do you think about it?

In my opinion CMSIS-Build needs a toolchain discover and register utility.

Yes, install procedure in CMSIS toolbox should include this...

@jeromecoutant I suggest to close this issue.  We understand that we should work on a better installation process.


Angular templates don't play well with strictNullChecks

I'm submitting a ...

[ ] bug report
[x] feature request
[ ] other (Please do not submit support requests here (see above))

Current behavior:
Currently if Typescript has strictNullChecks=true then it is very hard to work with variables that are nullable.
For example, if I have: hero?: Hero; inside my HeroDetailComponent class from the Heroes tutorial, then
<ng-container *ngIf="hero; else no_hero">

{{hero.name}} details!

		<input ([hero])="hero.name" placeholder="name"/>
</ng-container>

Then there will be an error for hero.name as it might be null and the binding won't work.
Expected / new behavior:
The template engine should be able to determine that the variable hero is not null within the if statement and so both of the components above should work. Alternatively, it could add syntax to allow you to explicitly cast a variable to a more specific type.
Minimal reproduction of the problem with instructions:
Open up the Heroes demo and change hero to a nullable variable and add strictNullChecks into tsconfig.json
AngularJS version: 4.4.4
Browser: Chrome 61
Anything else:
Current workaround:
<ng-container *ngIf="hero; else no_hero; let HERO">

{{HERO.name}} details!

		<input [ngModel]="HERO.name" (ngModelChange)="HERO.name=$event" placeholder="name"/>
	</ng-container>

And Angular issues don't play well with the AngularJS repo ;)


[WIP] feat(properties-panel): add number field component

Not used by any property so far, but could be important to have it in the future.

Let's wait with merging this when the split up is done (cf. #5)

Ready to review again.

Perhaps we should also add step if we want to make it complete. Apart from that it looks good.

Perhaps we should also add step if we want to make it complete. Apart from that it looks good.

Added 👍
I updated the reviewers due to the holidays.


Remove references to add_operator in tutorial creating-multi-node-applications

Thanks! @agirault could you please help merge the PR? (I don't have write access.)


device oldestDate and newestDate added to persist device sync progress

@carlossalasamper since you are touching here, this import seems to be unused, you could remove it :p
Also, seems to be some conflicts on the branch


Update to python 3 & django 1.8 / 1.9

Hi,
Thanks for your script !
I added support for argparse, and sorted the results in order to get always the same files.

Very nice, thank you. :+1:


Islands not hydrating

I am not sure how to narrow it down, but when upgrading to Fresh 1.5.0 or 1.5.1 one of my projects, the islands don't hydrate though I can see the client side JS being downloaded. Reverting back to 1.4.3 restores the capability.
Under 1.5.1 with a deno task build and then deno task preview (the same behaviour occurs with deno task start:

Under 1.4.3, only change being the version of Fresh in the deno.json, you can see the interactive :

The code is here: https://github.com/kitsonk/kview (using 1.4.3) but the application currently needs to run on a local Deno instance and requires a valid Deploy API key to be able to navigate to the point of using the interactive island. I can try to create a minimal reproduction, but right now it is just easier for me to develop on 1.4.3.

Thanks for the detailed reproduction. That allowed me to find the cause pretty quickly 👍

Ha, so it was all because my island was named KeyExplorer? 🤣

yeah, it's an embarrassing bug if I'm honest 😬

Some people, when confronted with a problem, think
“I know, I'll use regular expressions.”
Now they have two problems.

At least I stumbled upon it quickly, it being such a strange edge case which could have been hiding for years before stumbling across it. I will admit I delayed two days reporting it because I though "naw, I gotta be doing something wrong or someone else will come across it too and then I can just go 'me too' on the issue."

Please always report any issues you find. I'd rather have more issue reports that turn out to be non-issues compared to not being aware of the issues at all.


I want that badge!

Hello!

@SietseDEV Hi, can you just delete this issue, this issue is completely useless and just neglected.

@SietseDEV This aims to ensure that no issues are neglected

@SietseDEV hi?

It's literally closed

On the issues page you will see the open ones only except when you filter to closed ones

ohhhhmyyygodddd It's like North Korea

The problem is that you entered my repository and I checked my repo and you weren't there

That's what made me want to find out what the solution was

@Schweinepriester Delete These Issues So That I Can Be Free


Adopt (or not) plot strategies used by bayesplot

I just wanted to make sure folks saw the very nice plots being generated (in R) in bayesplot:
https://github.com/stan-dev/bayesplot
Here's one:

Edit: add image

Nice, thanks!

Would be really nice to pool efforts with pystan, edward and pymc3. CC @dustintran.

We will certainly keep an eye on Bayesplot.


[Feature] hero section of name "neon glow"

Description
Making a hero section that glows and fades.
Screenshots
https://github.com/Rakesh9100/Beautiify/assets/162733812/cb5cf6f6-68a8-4c28-b2f0-326f2ef9c3b8
Checklist

[X] I have checked the existing issues.
[X] I follow Contributing Guidelines of this project.
[X] I am a GSSOC'24 contributor.
[ ] I am a IWOC'24 contributor.
[ ] I am a JWOC'24 contributor.
[ ] I am a SWOC'24 contributor.

Code of Conduct

[X] I agree to follow this project's "Code of Conduct".

@Rakesh9100 please assign me this issue i want to work on it

What exactly do you want to add, pls clarify your issue nicely @Maana-Ajmera

@Rakesh9100 Creating a hero section with neon glows can be a striking and visually appealing choice for a website.

Okay go ahead @Maana-Ajmera


Bump all examples and docs to v1alpha3

Description of your changes

Updates the docs to match the below PRs.
https://github.com/crossplaneio/stack-aws/pull/58
https://github.com/crossplaneio/stack-gcp/pull/70
https://github.com/crossplaneio/stack-azure/pull/49
Checklist

I have:

[x] Run make reviewable to ensure this PR is ready for review.
[x] Ensured this PR contains a neat, self documenting set of commits.
[ ] Updated any relevant documentation, examples, or release notes.
[ ] Updated the RBAC permissions in clusterrole.yaml to include any new types.

@negz I'm doing a quick test on the three providers using this branch. will update when I'm done


Format Decimal values directly as strings

The failure listed in the issue is rooted in how tabulate handles Decimal objects, which, at bottom, end up being rendered via
>>> format(float(Decimal(10000000)), 'g')
'1e+07'

The 'g' format specifier is parameterized in tabulate, but changing it to '' only fixes some of the cases.
Next, I tried asking psycopg2 to return these values as strings rather than Decimal objects, but this also fails due to tabulate's aggressive coercion logic, which ends up giving you
>>> format(float('10000000'), 'g')
'1e+07'

The best solution is to render Decimal values directly as strings, which will correctly handle the difference between 10000000 and 10000000.0. Here is an example in pgcli
postgres> SELECT * FROM numeric_test ORDER BY a
+---------------+
| a             |
|---------------|
| 1.0           |
| 1.01          |
| 10.0          |
| 100           |
| 10000000      |
| 10000000.0    |
|<PHONE_NUMBER>000 |
+---------------+
SELECT 7
Command Time: 9.05990600586e-06
Format Time: 0.00118017196655
postgres>

and the same query in psql
postgres=# select * from numeric_test order by a;
       a
---------------
           1.0
          1.01
          10.0
           100
      10000000
    10000000.0
<PHONE_NUMBER>000
(7 rows)

postgres=#

I would normally avoid patching a vendored library like this, but this seems like the cleanest solution under the circumstances and matches previous fixes to a few other types.
Closes #169

I started poking around the format() function and the float format specifier. Eventually I found this answer: http://stackoverflow.com/a/2440786
Which renders a reasonably good output:
misago_testforum> SELECT * FROM numeric_test ORDER BY a;
+----------------------+
|                    a |
|----------------------|
|                 1    |
|                 1    |
|                 1.01 |
|                10    |
|               100    |
|               100    |
|          10000000    |
|<PHONE_NUMBER>0    |
|<PHONE_NUMBER>0    |
|<PHONE_NUMBER>0000000    |
+----------------------+
SELECT 10

Compared to psql output:
         a
-------------------
               100
          10000000
                 1
               1.0
              1.01
              10.0
               100
<PHONE_NUMBER>0
<PHONE_NUMBER>0.0
<PHONE_NUMBER>0000000

But then it removes the decimals and insignificant zeros, which can be misleading in some rare cases. So I think you made the right choice by forcing them to render as strings. We'll miss out on the right alignment, oh well.
BTW, the tests are failing on Python 2.6 because the tests you wrote use a 2.7 feature for formatting strings.
"insert into numbertest (a) values ({})".format(value)) should be rewritten as "insert into numbertest (a) values ({0})".format(value)), notice the {0} in the place holder instead of the empty {}.
Would you mind updating the test to have it pass on 2.6? I'll merge it in once that is resolved.
Thank you for diving into the code and finding the root cause. :+1:

Done! I always manage to forget that the shorter format syntax is a 2.7+ thing… :/
If, in the future, you wanted to add decimal alignment, I don't think it would be too hard: it would mostly be a matter of teaching tabulate how to treat the Decimal type. It would probably require some tabulate surgery, since the tool doesn't expose the hook points that would be needed, but the actual change would probably be pretty straightforward.
Cheers!
dan

Yeah I've been meaning to do a lot of improvements to Tabulate to feed it the types instead of having it guess them. But haven't found the time to do it yet. :P
Thank you for updating the tests.
:alien:


Toc2: enabling toc cell produces a a long number of empty MD cells

It made the browser window unresponsive for a while (chrome told me if I wanted to close the notebook tabs) and afterwards I had a lot (100+) of empty MD cells in the notebook.

This presumably is down to an error in deciding whether we're rendering the toc cell or a regular markdown cell. Since ToC is rebuilt on every rendered.MarkdownCell event, we have to be careful that rendering the ToC cell itself doesn't trigger another rebuild & hence render. It looks like that's what's happening here - that somehow the ToC cells is trying to be reinserted repeatedly, as the extension can;t find an existing one. Why this is happening is less clear, but it might be similar to the issue which prompted #536 - I think if the render callback for the new markdown cell errors, then perhaps the insert cell call also fails - which in this case means that the cell metadata value (which distinguishes the cell as the ToC cell) won't get set in toc2/main.js#L289-L290. I'm not sure whether this constitutes a notebook bug or not...

Good analysis and hypotheses @jcb91. There exists a flag "rendering_toc_cell" introduced precisely in order to avoid repetive calls to the insertion of the toc_cell. There should be something else. @janschulz is this reproductible?

I tried to reproduce in a small notebook, but can't...
Just had a different case, where I had two md cells open for editing (and a working toc cell included in the nb) and then tried to render one md cell and it crashed the nb tabs :-(  As I lost some small edits (had to close the tab to get my browser back), I removed the toc cell for now :-(
My nb are medium big (20+ headlines, multiple tables + plots, ...) and I have the table-beautifier extensions enabled, so there are already two (probably no so unexpensive) callbacks per md render.
Could there be an assumption that the toc cell code is run straight after the toc widget code? Maybe decouple the two by adding a periodic callback to toggle the toc cell and only run that code when a flag was set which is set by the toc widget code? Then the periodic code could set another flag to indicate that the toc widget should not run while the toc cell code renders the md... Or simple add a button under the toc cell to recompute the toc cell..

Another strange thing is that the tabs seem to share this state: I had to close all tabs until the 100% CPU (1 core => 25% ) went away :-(

@janschulz I'm not really sure what you're getting at here - the toc cell and widget code are both part of the same function, so they can't really interfere with each other. Your description of a flag sounds pretty much like what's going on already - the flag set at toc2/main.js#L287 is used in main.js#L248-L250 to make sure that the toc isn't updated again until after the metadata flag has been set in toc2/main.js#L290. I suspect what's happening is that the metadata never gets set. You might try wrapping lines 289/290 in a try {} finally {} pair to make sure it gets set?
The shared state might (I have no idea, stabbing in the dark here) be a result of pages from the same domain sharing a single javascript engine?

@janschulz oh, but maybe worth a try, I think I had this problem at least once when I messed up the flagging while playing with ToC, and I just killed the process with high CPU usage, then had chrome decide what had died. Might save other open tabs (might not, of course!)

Thanks for working on this!
I get the freeze and empty MD cells (after a while of running a notebook with the toc) every time I convert a raw cell to an MD cell (toolbar or Ctrl M + M).

@janschulz @fabboe do either of you have a notebook you could share which (semi-)repeatably triggers this problem? Would be handy for diagnosis.

@fabboe I tried to reproduce your problem but couldn't :-(
@jcb91 I tried to get a reproducable example (or at least a problem once) with my notebook but right now I can't: even repeated removal and addition of the toc cell does not trigger it anymore :-(

Haven't found any hint for the trigger yet. Closing and reopening helps for a (good) while. Restarting only the kernel doesn't help.
Btw, using it with IPython and initializing PySpark inside.
Seems that it's connecting with the length of the session. Will let you know if I notice a pattern!

The reopening part doesn't seem to be about the notebook but the browser, I'm observing that these freezes / empty MD cells stop (again, for a good while) after reconnecting in a fresh window to the notebook. No actual notebook closing required.
Could I serve with some debug info from Chrome's developer tools, once it happens again?

@fabboe well, that (no freeze for a while after opening a new window) sounds consistent with it being a slow-building javascript bug - the kernel isn't affected by ToC, and the notebook server isn't directly affected, until a save/autosave writes any new content produced by ToC to disk along with the rest of the notebook. If you can run with Chrome devtools open, I'd recommend swapping main.js#L287 and main.js#L373 for rendering_toc_cell += 1;, then add a conditional breakpoint just before main.js#L248 to stop when rendering_toc_cell > 1 to allow you to try to inspect the stack and see how you got there... once the breakpoint triggers, I'd guess you can run through several calls to try to see what's going on... make sense?

These are good suggestions @jcb91.

Personnaly I do not have this kind of problem and doubt that the freeze/empty md cells/etc are due to the toc extension itself, but rather to the fact that there may exist some competitions between extensions/javascripts functions that introduce an overload and a slowness to update cell metadata. This may be linked to the number of extensions that run together or to particular associations, to the length and load of the browser or javascript engine. The investigation seems complicated.


Stray '\341' (was \240 previously) in redock_2018_1.def breaks make

File redock_2018_1.def - both from cloning this repo (error is '\240') and from colleague (error is '\341') - appears to be corrupted upon translation
In file included from /home/todd/code/gnina/gninasrc/lib/cnn_data.cpp:50: /home/todd/code/gnina/gninasrc/lib/models/weights/redock_2018_1.def:36705:24: error: stray ‘\341’ in program 36705 |   0xed, 0x08, 0x4d, 0x3�, 0xd9, 0x12, 0xef, 0x39, 0x16, 0x48, 0x0c, 0xb9
Steps to reproduce
Everything from the instructions, this occurs during make in the build directory.

--   CUDA              :   Yes (ver. 12.1)
-- NVIDIA CUDA:
--   Target GPU(s)     :   Auto
--   GPU arch(s)       :   sm_89
--   cuDNN             :   Not found
-- Python:
--   Interpreter       :   /usr/bin/python3 (ver. 3.10.12)
--   Libraries         :   /usr/lib/x86_64-linux-gnu/libpython3.10.so (ver 3.10.12)
--   NumPy             :   /home/todd/.local/lib/python3.10/site-packages/numpy/core/include (ver 1.23.1)
-- Documentaion:
--   Doxygen           :   /usr/bin/doxygen (1.9.1)
--   config_file       :   /home/todd/code/gnina/caffe/.Doxyfile
-- Install:
--   Install path      :   /usr/local

I'm not sure what to do on my end.  There's no issue when I clone the repository and when you look at the file online (https://raw.githubusercontent.com/gnina/gnina/master/gninasrc/lib/models/weights/redock_2018_1.def) there is also no issue.
Does git realize the files are different?  Then checking it out again should fix the problem.

David, thanks for getting back to me.
I've edited the file and should be good to go - fyi, here's what it looks like:

Let's close and chalk it up to something on my end.


AppMaps from remote recordings are stored according to appmap_dir in appmap.yml

Currently, the appmap_dir in appmap.yml is not respected when an AppMap is created from a remote recording in VS Code.

:tada: This issue has been resolved in version 0.93.0 :tada:
The release is available on:

v0.93.0
GitHub release

Your semantic-release bot :package::rocket:


Enhancement : Support for "Fedwire extended format"

Wire Version: v0.8.0
What were you trying to do?
Generate a wire file in the "Fedwire extended format" (not sure of the terminology) for sharing with a banker's bank.
What do you expect to see?
A file generated by Moov looks similar to
{1500}30User ReqT  {1510}1000 {1520}20220324WebBanki000001 {2000}000100000000 {3100}125109048Bank Name XXXXXXXX {3400}062000019An Souphorn        {3600}CTR    {4200}D000000219                         An Souphorn                                                                                {5000}D1001295                           Christiane YWalker                 Address 1
Unlike a bank with a direct connection to the fed, which can use the file generated by the Moov wire library as is, for sharing the file with a banker's bank, a few changes are required with respect to delimiters. Each message starts with “YFT811 “, instead of fixed width, they are using variable width with asterisk (*) as the delimiter, and no new line characters are used in between and tags are present in the order of increasing numerical order.
A file that can be accepted by the Banker's Bank looks similar to
YFT811 {1500}303O004HE8P {1510}1000{1520}2022032400000000000001{2000}000000022200{3100}123456780Xxxxx Corresponden*{3400}021000021JPMCHASE*{3600}CTR{4100}F021000021*JPMC*123 Test st*Test*Test*{4200}D123455*Test Name*123 Test St*Town*MO*{5000}D123456*John Doe*123 Anywhere St*Anywhere*MO*{5100}D998877*Xxxx First Bank*158 Anywhere St*Anywhere*MO*{5200}F404123787*Xxxxxxx Bank*144 Anywhere St*Anywhere*MO*{6000}Test*{6500}Test*
Key differences:

”YTF811 ” Static data; Marks the beginning of each wire

No new line character in the entire message structure (single line message)

A field delimiter (*) is used to terminate mandatory or optional variable length elements or optional fixed length elements. Mandatory fixed length elements do not require a delimiter. Mandatory elements always precede optional elements in a field tag. If an element is not present we must include asterisk. For e.g.

{4200} is the beneficiary of the wire. The tag is broken up into 5 elements: (1) Account (2) Name (3) Address Line 1 (4) Address Line 2 (5) Address Line 3
Each element is delimited by an asterisk. If the element is not present, you must include an asterisk. For example: {4200}D123456789*BeneficiaryName*AddressLine1*AddressLine2*AddressLine3* {4200}D123456789*BeneficiaryName*AddressLine1**AddressLine3 *{4200}D123456789*BeneficiaryName*AddressLine1*AddressLine2**

Three characters are defined as restricted special characters. They are: Asterisk (*), Left brace ({), and Right brace (}) The asterisk is used only as a delimiter, to terminate a mandatory or optional variable-length element or an optional fixed length element. The braces are used only as tag delimiters.

What did you want to see?
An optional field in the Moov wire library, say "useExtendedFormat" (not sure if I am using the right terminology)  that allows toggling between the default format to the format described above

Thanks for submitting this issue @vishwasbabu!
I think this may actually be at least two separate ideas:

Add support for a configurable static value to mark the beginning of each wire in a file
Add support for variable length fields (I believe we only have support for fixed length at the moment)

Am I understanding you correctly?

@atonks2: This is an extension of the conversation at https://moov-io.slack.com/archives/CJV1WSCKF/p1648192600145649. I am trying to find docs to check if the static value at the beginning of the file needs to be configurable (or can be skipped entirely and still be processed by the Bankers bank we are trying to submit this file to). The crux of the issue is the field delimiters and newline

Sounds good. I opened an issue a couple weeks ago to look more into variable length records (e.g. using * as a delimiter instead of fixed field lengths and newlines): https://github.com/moov-io/wire/issues/190
The static value is something new to me though (your Slack thread was the first I'd heard of it). I've found it to be difficult to find documentation for Wire files and the official specs we do have don't make any mention of a static value being used to mark the start of each wire. That's not all that surprising, though, because the official specs seem to be strictly for interacting with the fed, not with other banks.
I think this is something we can accommodate with some sort of flag/configuration.

@vishwasbabu could you try out https://github.com/moov-io/wire/pull/211 and see if it works for variable width fields?


Reproduce issue #426

Reproduces #426

@lucivpav I just ran into this issue too.
I found a solution for this -
https://github.com/estools/escodegen/blob/ab53cd5489fd15c3624386465d1f7a0544cda6c8/escodegen.js#L946-L949
this should be
var strExpr = expr.toString();
if (strExpr[0] === '{' || strExpr[strExpr.length - 1] === '}') {
  expr = ['(', expr, ')'];
}

I'm pretty sure the last character cannot be part of the comment, in that case the comment would not be part of the node

I wonder if this fix works for the affected parenthesized expressions in general, or just in function bodies 🤔

@lucivpav a better solution is to check the node types:
if (node.type === Syntax.ArrowFunctionExpression && node.body.type === Syntax.ObjectExpression) {
  expr = ['(', expr, ')'];
}

@lucivpav This PR does not cover this scenario:
var a = b => ({}.hasOwnProperty.call(b, "c"));
This is a CallExpression and not an ObjectExpression.
Maybe it should be simply:
if (node.type === Syntax.ArrowFunctionExpression) {   expr = ['(', expr, ')']; }

@lucivpav This PR does not cover this scenario:
var a = b => ({}.hasOwnProperty.call(b, "c"));
This is a CallExpression and not an ObjectExpression.
Maybe it should be simply:
if (node.type === Syntax.ArrowFunctionExpression) {   expr = ['(', expr, ')']; }


Upgrade to pytest-docker v1

https://pypi.org/project/pytest-docker/
pytest-docker==1.0.0 was released earlier today, and it includes support for Docker compose v2, which is not a Python package. We'll be able to use that to drop our dev dependency on Docker compose v1, which in turn will let us upgrade to the latest major version of jsonschema, which is the final Meltano dependency that is considered "out of date" by libraries.io/SourceRank.
We should wait a week or two to see if any issues come up with the new major release. We're in no rush to make this change, so maybe we'll end up using pytest-docker==1.0.1, or something like that instead.

@WillDaSilva interesting! So pytest-docker doesn't depend on docker-compose (and in turn on docker, which is likely to become unmaintained: https://github.com/docker/docker-py/pull/2989)?
That'd be neat and I that might fix the failing tests on Windows for Python 3.10.

@edgarrmondragon Yes, it seems like the only reason we have a dependency on docker is because of pytest-docker, so it should fix the failures observed on Python 3.10. In light of that, I've moved this up to the next iteration.
Relates to #6479

@visch since you're currently looking into https://github.com/meltano/meltano/issues/6479, you probably want to be aware of this.


Allow PPO to turn off advantage normalization

Description
Allow PPO to turn of advantage normalization. Follow up from https://github.com/DLR-RM/stable-baselines3/pull/763, #60
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation (update in the documentation)

Checklist:

[x] I've read the CONTRIBUTION guide (required)
[ ] The functionality/performance matches that of the source (required for new training algorithms or training-related features).
[ ] I have updated the tests accordingly (required for a bug fix or a new feature).
[ ] I have included an example of using the feature (required for new features).
[ ] I have included baseline results (required for new training algorithms or training-related features).
[ ] I have updated the documentation accordingly.
[ ] I have updated the changelog accordingly (required).
[x] I have reformatted the code using make format (required)
[x] I have checked the codestyle using make check-codestyle and make lint (required)
[x] I have ensured make pytest and make type both pass. (required)

Note: we are using a maximum length of 127 characters per line

Had the following error, seems to relate to https://github.com/DLR-RM/stable-baselines3/pull/782
ImportError: cannot import name 'GoalEnv' from 'gym' (/home/costa/.cache/pypoetry/virtualenvs/cleanrl-ghSZGHE3-py3.9/lib/python3.9/site-packages/gym/__init__.py)

Ok should be good now.


Enhancement: Display a different background on secondary screens

An idea I had was to display the BG image from the game used prior to the login screen on secondary monitors. This would make the theme more like conventional login screens where only the primary monitor displays the text boxes and such.

I'm guessing some users would prefer the current style so we could make it configurable as well.
I'm still a bit new to SDDM and QML in general but I can try and implement it if that's OK with you.

i don't own second monitor but do whatcha want, it's free country, if it will be optional or something then it's all fine. Currently in SDM themes i think the login displays on all displays so it definitely should be optional (idk if my theme displays on all displays)

Currently yes, each monitor will show the username and password fields and
you can just pick one and type in it.
On Tue, Jul 14, 2020 at 12:16 Michał Szczepaniak<EMAIL_ADDRESS>wrote:

i don't own second monitor but do whatcha want, it's free country, if it
will be optional or something then it's all fine. Currently in SDM themes i
think the login displays on all displays so it definitely should be
optional (idk if my theme displays on all displays)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Michal-Szczepaniak/sddm-theme-amadeus/issues/8#issuecomment-658363336,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHO7WMZASVEB6FNK6UKMWSTR3SVHLANCNFSM4OZZIGQA
.

So if it will be optional, feel free. I'm thinking about making splash theme (it's rather simple from what've seen) with s;g splash (in reddit threads someone just played mp4 on login) so that would be cool addition. Another thing is lock screen theme which currently is not themable but i could change sources.

I was thinking about making an Amadeus splash screen as well but I wasn't able to get plymouth working. If I'm able to I can try to help with that (or if there is something else that works better than plymouth). That video is a lot better quality than the frames I extracted from the game so we should definitely use that.
What desktop environment would you implement the lock screen for?

@pmdevita kde obviously, and when talking about splashscreen i mean the one after login so it's not plymouth it's part of kde

@pmdevita https://github.com/Michal-Szczepaniak/amadeus-kde-splashscreen :) Now we are missing first part of the video that i took it from, we could make it into plymouth theme but plymouth doesn't work on my pc so can't do shit

Looks good! I can't get plymouth working either lol I dunno if I'll be able to do it
Additionally, I can't find any documentation for how to differentiate screens in sddm so I'm not sure if showing the different background on secondary monitors is even possible.

You might want to ask on kde irc channel but here is my idea, hide all controls and fade wallpaper to the second one if current screen isn't focused (put mousearea on background or smth)

I figured it out. https://github.com/sddm/sddm/blob/1231b5fce8b7f9d99b3a0b8fa17e10d797890c43/data/themes/maui/Main.qml#L66
There is apparently an undocumented global variable that can tell a component if it is displaying on the primary screen or not. SDDM documentation is really, really bad.
Anyways, I'll be finishing the changes soon. Should the behavior be default or one you have to configure for?

Well my idea wasn't bad either, i think current behaviour should be default

I did try your idea prior, it was very clever. This method should hopefully be more consistent though.
I'll fix my pull request to keep current behavior default.


Add Https and service import export test, bug fix for ervice import and export

Changes

Add https traffic test case
Add service import and export test case
Further Test Framework imporvement, add more properly resource clean up logic ,make e2e test more stable
Bug fix for service import and export: when handling Kind: ServiceExport k8s resource, the latticestore should create create a IsServiceImport == true cache for it

Test:
make presubmit pass
make e2etest all pass, full log: https://gist.github.com/zijun726911/d1be4a93e8ea4a99e2af2430a553ff95
------------------------------

Ran 4 of 4 Specs in 1089.167 seconds
SUCCESS! -- 4 Passed | 0 Failed | 0 Pending | 0 Skipped
--- PASS: TestIntegration (1089.40s)
PASS
ok  	github.com/aws/aws-application-networking-k8s/test/suites/integration	1089.994s

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

4 of 4 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 31.824%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
3169

Relevant Lines:
9958

💛  - Coveralls


Adding transcription for output devices

Hello, I think a trascription for output devices would be great.
In my company we are about to spend 800 USD just to transcribe one-to-one interviews hiring google workspace.
If this software would accept filter for output devices this would be a far better app because it's LOCAL, but currently it is not useful because I cant take the output devices and create a file that differentiate mic from speakers/headset. ( or even add two different devices)
Thanks, I appreciate your work

@agustinFeijoo Please see updated FAQ section on notes how to get transcription from non-microphones https://chidiwilliams.github.io/buzz/docs/faq
Audio device routing is quite complex to implement for multiple operating systems due to their specifics, I have not found a solution that works stable and reliably, so for time being I see that bet solution is to do the routing on OS level and create virtual input device that you can hook up to the current recording mechanism in Buzz.
If anybody can recommend a solution that does this on code level, it could be implemented.


Installation from PyPI fails

Trying to install from PyPI without first installing Cython fails:
Collecting stratify (from ESMValTool==2.0a1)
  Downloading https://files.pythonhosted.org/packages/f9/a6/067946d74affbd4bb1130f157f7be6b9f8ce6be56d8eb694cffce9b53e19/stratify-0.1.tar.gz (231kB)
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-install-492vc9kg/stratify/setup.py", line 8, in <module>
        from Cython.Build import cythonize
    ModuleNotFoundError: No module named 'Cython'

Ping @bouweandela - closed by https://github.com/SciTools-incubator/python-stratify/pull/29
I'll be tagging a patch release and updating PyPI and conda-forge with the fix :smile:

Hey @bouweandela... The latest python-stratify version 0.1.1 which addresses this issue is now available on conda-forge and PyPI :wink:


Module not found: Error: Can't resolve 'crypto'

So basically I am watching the tutorial and trying to get this whole app to work. WIthout success cause I am getting errors while opening "localhost:3000".

. I was trying to install all the missing packages using both npm install "crypto-browserify" and yarn add "crypto-browserify".
I am also having errors with packages "stream-http" "https-browserify" "stream-http" "os-browserify" . Of course I was looking for the answer in google but no success. What can I do to fix that problem?
Yarn version:
1.22.15
Node version:
16.14.0
Compiler version:
0.8.1 - it was giving errors with 0.8.0 and screaming at me I should use 0.8.1

Potentially solved the problem. I will give here the solution so I guess it might be usefull for someone.
Just two commands:

yarn remove react-scripts
yarn add<EMAIL_ADDRESS>

Hello, I am watching the tutorial I am at the end of part 5, I can deploy my smart contract but the connect() func seem doesn't work, account stay undefined despite the change from my wallet metamask.

Plz colud you tell me how to debug this func ?


feat: return errors if filter specified by flag does not exist.

Closes #216
📑 Description

This PR adds an else clause to the AnalyzeFilters method in order to handle cases where a specified filter does not exist. Previously, when an unknown filter was passed, the method would simply return No problems detected. With this change, if the filter is not found in the analyzerMap, the method will return an error message that includes the name of the filter, directing the user to run k8sgpt filters list.
This enhancement improves the user experience and helps ensure that errors are caught and reported in a clear and helpful manner.
k8sgpt git:(feature/log-on-unexisted-filters) ✗ ./k8sgpt analyze --filter fake --namespace k8sgpt
Error: "fake" filter does not exist. Please run k8sgpt filters list.

✅ Checks

[x] My pull request adheres to the code style of this project
[ ] My code requires changes to the documentation
[ ] I have updated the documentation as required
[x] All the tests have passed

ℹ Additional Information

Nice!


More browser support?

I use brave browser, can we add custom options to extend this one allow them?

You can add support for browsers by changing the customization profiles field in the plugin's settings panel.
Say you want to use the brave browser, an example on Windows would look like this (you may need to change the execution file path)
{
    "brave": [
        "C:/Program Files/BraveSoftware/Brave-Browser/Application/brave.exe"
    ],
    "brave-private": [
        "C:/Program Files/BraveSoftware/Brave-Browser/Application/brave.exe",
        "-incognito"
    ]
}

Then you can find the brave in the browser drop-down menu

How about we add more common used browsers into this list :smile: or, allow user to add custom path :smile:


Fails to build: cannot use h.allow0RTT (variable of type bool) as tls.QUICSessionTicketOptions

I've ran xcaddy build --with github.com/caddy-dns/cloudflare on latest go (1.21.0 linux/amd64) and it fails because of quic-go for some reason (I assume generic types error?):
2023/08/08 21:57:39 [INFO] Temporary folder: /tmp/buildenv_2023-08-08-2157.3516867617
2023/08/08 21:57:39 [INFO] Writing main module: /tmp/buildenv_2023-08-08-2157.3516867617/main.go
package main

import (
caddycmd "github.com/caddyserver/caddy/v2/cmd"

// plug in Caddy modules here
_ "github.com/caddyserver/caddy/v2/modules/standard"
_ "github.com/caddy-dns/cloudflare"
)

func main() {
caddycmd.Main()
}
2023/08/08 21:57:39 [INFO] Initializing Go module
2023/08/08 21:57:39 [INFO] exec (timeout=0s): /home/v1rtl/go/bin/go mod init caddy
go: creating new go.mod: module caddy
go: to add module requirements and sums:
go mod tidy
2023/08/08 21:57:39 [INFO] Pinning versions
2023/08/08 21:57:39 [INFO] exec (timeout=0s): /home/v1rtl/go/bin/go get -d -v github.com/caddyserver/caddy/v2
go: added github.com/beorn7/perks v1.0.1
go: added github.com/caddyserver/caddy/v2 v2.7.3
go: added github.com/caddyserver/certmagic v0.19.1
go: added github.com/cespare/xxhash/v2 v2.2.0
go: added github.com/go-task/slim-sprig v0.0.0-20230315185526-52ccab3ef572
go: added github.com/golang/mock v1.6.0
go: added github.com/golang/protobuf v1.5.3
go: added github.com/google/pprof v0.0.0-20210720184732-4bb14d4b1be1
go: added github.com/google/uuid v1.3.0
go: added github.com/klauspost/cpuid/v2 v2.2.5
go: added github.com/libdns/libdns v0.2.1
go: added github.com/matttproud/golang_protobuf_extensions v1.0.1
go: added github.com/mholt/acmez v1.2.0
go: added github.com/miekg/dns v1.1.55
go: added github.com/onsi/ginkgo/v2 v2.9.5
go: added github.com/prometheus/client_golang v1.14.0
go: added github.com/prometheus/client_model v0.3.0
go: added github.com/prometheus/common v0.37.0
go: added github.com/prometheus/procfs v0.8.0
go: added github.com/quic-go/qpack v0.4.0
go: added github.com/quic-go/qtls-go1-20 v0.3.1
go: added github.com/quic-go/quic-go v0.37.3
go: added github.com/zeebo/blake3 v0.2.3
go: added go.uber.org/multierr v1.11.0
go: added go.uber.org/zap v1.25.0
go: added golang.org/x/crypto v0.11.0
go: added golang.org/x/exp v0.0.0-20230310171629-522b1b587ee0
go: added golang.org/x/mod v0.11.0
go: added golang.org/x/net v0.12.0
go: added golang.org/x/sys v0.10.0
go: added golang.org/x/term v0.10.0
go: added golang.org/x/text v0.11.0
go: added golang.org/x/tools v0.10.0
go: added google.golang.org/protobuf v1.31.0
2023/08/08 21:57:42 [INFO] exec (timeout=0s): /home/v1rtl/go/bin/go get -d -v github.com/caddy-dns/cloudflare github.com/caddyserver/caddy/v2
go: added github.com/caddy-dns/cloudflare v0.0.0-20230807034102-74f004e1c1ab
go: added github.com/libdns/cloudflare v0.1.0
2023/08/08 21:57:44 [INFO] exec (timeout=0s): /home/v1rtl/go/bin/go get -d -v
2023/08/08 21:57:54 [INFO] Build environment ready
2023/08/08 21:57:54 [INFO] Building Caddy
2023/08/08 21:57:54 [INFO] exec (timeout=0s): /home/v1rtl/go/bin/go mod tidy -e
2023/08/08 21:57:54 [INFO] exec (timeout=0s): /home/v1rtl/go/bin/go build -o /home/v1rtl/caddy -ldflags -w -s -trimpath
# github.com/quic-go/quic-go/internal/handshake
/home/v1rtl/go/pkg/mod/github.com/quic-go/quic-go@v0.37.3/internal/handshake/crypto_setup.go:362:37: cannot use h.allow0RTT (variable of type bool) as tls.QUICSessionTicketOptions value in argument to h.conn.SendSessionTicket
2023/08/08 21:57:56 [INFO] Cleaning up temporary folder: /tmp/buildenv_2023-08-08-2157.3516867617
2023/08/08 21:57:56 [FATAL] exit status 1

Quic-go cannot be built with Go 1.21 yet. (This has nothing to do with caddy-dns/cloudflare btw)

switched to go 1.20, it builds successfully


Eco mode not showing in control AS25XCAHRA

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to 'Control device'
Click on '....'
Scroll down to '....'
See error

Expected behavior
See switch to enable Eco mode
Screenshots
https://photos.app.goo.gl/F9w3GMef3VhnvQP17
Environment (please complete the following information):

Home Assistant Version: [e.g. 2024.10.4]
hOn Integration Version [e.g. 0.14.0, can be found in HACS or device log]
pyhOn Version [e.g. 0.17.5, can be found in device log]

Additional context
Add any other context about the problem here.
Home Assistant Logs
Check System -> Logs if you can find any logs related to this integration and post it here.
Device Log
Post your device info here (if available)

Enable the "Show Device Info" button
This button can be found in the diagnostic section of your device or in the entity overview if "show disabled entities" is enabled.
Press the button to create a notification
Open home assistant notifications and copy the message (Crtl+A, Ctrl+C)

Data Archive
For further analysis, please add your appliance data archive here (if available)
Navigate to Settings -> Device & Services -> Haier hOn -> your device and press the Create Data Archive button.
Then open notifications to download the data zip archive.
To attach the file:

GitHub Web: Use the "Attach files by dragging & dropping, selecting or pasting them." function
GitHub Mobile: Upload the zip archive as image

It actually seems to be missing on the screenshot in the readme as well.
All options like, silent, speed are available, just not eco mode.
There's the eco pilot but it is something different.
The eco mode is available through Hon app.