Clamping added later?

I have a question about the calmping in RNVPCouplingBlock and GLOWCouplingBlock.
Code from RNVPCouplingBlock:
def e(self, s):
        # return torch.exp(torch.clamp(s, -self.clamp, self.clamp))
        # return (self.max_s-self.min_s) * torch.sigmoid(s) + self.min_s
        return torch.exp(self.clamp * 0.636 * torch.atan(s))

The atan() call is not described in the paper. Has it been added later?

Perhaps it would be a good idea to mention that 2 / pi ≃ 0.636 (actually, correctly rounded it's 0.637).

Were the results from the Analyzing Inverse problems with Invertible Neural Networks paper obtained including the atan?

Hi!
Thanks for bringing this up.
Yes, indeed, the clamping was also present in the paper.
The clamping itself was already introduced by the Real-NVP paper, but you are right, it would have been good to include a detailed description of the coupling blocks, at least in the appendix of the paper.
I will close this issue and move it to the paper's own repository (this one now being only for FrEIA itself, which can implement various other bi-directional architectures and methods)


[HOPS-1154] Fixed HopsFS rapid ID generation bug

Make sure there is no duplicate PR for this issue

Please check if the PR fulfills these requirements

[x] Tests for the changes have been added and passed (for bug fixes / features)
[x] HOPS JIRA issue has been opened for this PR
[x] All commits have been squashed down to a single commit
[x] The commit message has the following format: [HOPS-XXX] message

Post a link to the associated JIRA issue
https://hopshadoop.atlassian.net/browse/HOPS-1554

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
bug fix

What is the new behavior (if this is a feature change)?

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

Other information:

Can one of the admins verify this patch?

Jenkins test this please.


Feature/power grid simulation in python

Make the MNASimulation callable from Python. This required making SparseLU be a shared library.
@parijatm I needed to change "install.sh". You'll need to see how this effects your PR.
@854768750 @Lastdayends I need a way to test the MNASimulation. Do you have a testcase (preferably from the examples directory) that we can use to drive this. (See align/pnr/toplevel.py)

@stevenmburns
You can use the switched_capacitor_filter case to test the MNA Simulation.
To test the functionality, you will need do the following modifications in the toplevel.cpp:
line 132: bool PDN_mode = false -> bool PDN_mode = true
line 135: bool dataset_generation = false -> bool dataset_generation = true
There are some hardcoded filenames which are internally used to test the functionality of MNA Simulation.
Currently, MNA Simulation is a separate function from P&R flow. So in PDN_mode, the P&R will return after MNA simulation without generating a layout of the top level. This might be a problem.

@parijatm I needed to change "install.sh". You'll need to see how this effects your PR.

Hi Steve. Can you try using using -DCMAKE_POSITION_INDEPENDENT_CODE=ON instead of -DBUILD_SHARED_LIBS=ON? #572 does this already.

@Lastdayends I can't seem to make the switched_capacitor_filter example work after adding those switches in either the .cpp version or the .py version of toplevel. I'm getting this error:
COLAMD failed at line 52 in file /home/smburns/DARPA/ALIGN-public/superlu/SuperLU_5.2.1/SRC/get_perm_c.c

Is this expected?

@stevenmburns
Not expected. I will look into it. (Guess two files, InputCurrent_initial.txt and Power_Grid_Conf.txt, are not read in by pnr_compiler.)

@parijatm I want to check this in. It is better than what is there now and doesn't break anything that wasn't already broken.

@stevenmburns
I fixed a minor bug.
The error you meet is due to power grid is not full connected. I changed the power grid configuration to make the power grid fully connected. high_speed_comparator and switched_capacitor_filter are tested, here are the results:

Merged this into #576, so closing this.


build error: error: no match for ‘operator=’ (operand types are ‘mjuiDef’ {aka ‘mjuiDef_’} and ‘’)

Hi, thanks for the great work. I want to try out the software and see whether it can help me to generate some datasets for my research. However, I encounter the error no match for ‘operator=’ (operand types are ‘mjuiDef’ {aka ‘mjuiDef_’} and ‘<brace-enclosed initializer list>’) when building with gcc-10. Could you please help me solve the problem? Thanks!
The complete log is following:
[main] Building folder: mujoco_mpc
[main] Configuring folder: mujoco_mpc
[proc] Executing command: /usr/bin/cmake --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/gcc-10 -S/home/xingyuan/mujoco_mpc/mjpc -B/home/xingyuan/mujoco_mpc/build -G "Unix Makefiles"
[cmake] Not searching for unused variables given on the command line.
[cmake] -- The C compiler identification is GNU 10.3.0
[cmake] -- The CXX compiler identification is GNU 9.4.0
[cmake] -- Check for working C compiler: /usr/bin/gcc-10
[cmake] -- Check for working C compiler: /usr/bin/gcc-10 -- works
[cmake] -- Detecting C compiler ABI info
[cmake] -- Detecting C compiler ABI info - done
[cmake] -- Detecting C compile features
[cmake] -- Detecting C compile features - done
[cmake] -- Check for working CXX compiler: /usr/bin/c++
[cmake] -- Check for working CXX compiler: /usr/bin/c++ -- works
[cmake] -- Detecting CXX compiler ABI info
[cmake] -- Detecting CXX compiler ABI info - done
[cmake] -- Detecting CXX compile features
[cmake] -- Detecting CXX compile features - done
[cmake] -- Performing Test CAN_BUILD_AVX
[cmake] -- Performing Test CAN_BUILD_AVX - Success
[cmake] -- Performing Test SUPPORTS_LLD
[cmake] -- Performing Test SUPPORTS_LLD - Failed
[cmake] -- Performing Test SUPPORTS_GOLD
[cmake] -- Performing Test SUPPORTS_GOLD - Success
[cmake] -- Performing Test SUPPORTS_GC_SECTIONS
[cmake] -- Performing Test SUPPORTS_GC_SECTIONS - Success
[cmake] -- Looking for pthread.h
[cmake] -- Looking for pthread.h - found
[cmake] -- Performing Test CMAKE_HAVE_LIBC_PTHREAD
[cmake] -- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
[cmake] -- Looking for pthread_create in pthreads
[cmake] -- Looking for pthread_create in pthreads - not found
[cmake] -- Looking for pthread_create in pthread
[cmake] -- Looking for pthread_create in pthread - found
[cmake] -- Found Threads: TRUE
[cmake] CHECK_STARTmujoco::FindOrFetch: checking for targets in package `mujoco`
[cmake] CHECK_FAILtarget `mujoco::mujoco` not defined.
[cmake] CHECK_STARTmujoco::FindOrFetch: Using FetchContent to retrieve `mujoco`
[cmake] CHECK_STARTmujoco::FindOrFetch: checking for targets in package `qhull`
[cmake] CHECK_FAILtarget `qhull` not defined.
[cmake] CHECK_STARTmujoco::FindOrFetch: Using FetchContent to retrieve `qhull`
[cmake] -- Looking for sys/types.h
[cmake] -- Looking for sys/types.h - found
[cmake] -- Looking for inttypes.h
[cmake] -- Looking for inttypes.h - found
[cmake] -- Looking for stddef.h
[cmake] -- Looking for stddef.h - found
[cmake] -- Looking for stdint.h
[cmake] -- Looking for stdint.h - found
[cmake] -- Check size of off_t
[cmake] -- Check size of off_t - done
[cmake] -- Looking for fseeko
[cmake] -- Looking for fseeko - found
[cmake] -- Looking for ftello
[cmake] -- Looking for ftello - found
[cmake] -- Looking for PRIdMAX
[cmake] -- Looking for PRIdMAX - found
[cmake] --
[cmake] -- ========== qhull Build Information ==========
[cmake] -- Build Version:                             8.1-alpha1
[cmake] -- Install Prefix (CMAKE_INSTALL_PREFIX):     /usr/local
[cmake] -- Binary Directory (BIN_INSTALL_DIR):        bin
[cmake] -- Library Directory (LIB_INSTALL_DIR):       lib
[cmake] -- Include Directory (INCLUDE_INSTALL_DIR):   include
[cmake] -- Documentation Directory (DOC_INSTALL_DIR): share/doc/qhull
[cmake] -- Man Pages Directory (MAN_INSTALL_DIR):     share/man/man1
[cmake] -- CMake Directory (CMAKE_INSTALL_DIR):       lib/cmake/QHull
[cmake] -- PkgConfig Directory (PKGCONFIG_INSTALL_DIR):lib/pkgconfig
[cmake] -- Build Type (CMAKE_BUILD_TYPE):             Debug
[cmake] -- Build static libraries:                    ON
[cmake] -- Build shared library:                      OFF
[cmake] -- Use shared library for linking apps:       OFF
[cmake] -- Build tests:				   OFF
[cmake] -- To override these options, add -D{OPTION_NAME}=... to the cmake command
[cmake] --   Build the debug targets                  -DCMAKE_BUILD_TYPE=Debug
[cmake] --
[cmake] -- To build and install qhull, enter "make" and "make install"
[cmake] -- To smoketest qhull, enter "ctest"
[cmake] --
[cmake] CHECK_PASSDone
[cmake] CHECK_STARTmujoco::FindOrFetch: checking for targets in package `tinyxml2`
[cmake] CHECK_FAILtarget `tinyxml2` not defined.
[cmake] CHECK_STARTmujoco::FindOrFetch: Using FetchContent to retrieve `tinyxml2`
[cmake] CHECK_PASSDone
[cmake] CHECK_STARTmujoco::FindOrFetch: checking for targets in package `tinyobjloader`
[cmake] CHECK_FAILtarget `tinyobjloader` not defined.
[cmake] CHECK_STARTmujoco::FindOrFetch: Using FetchContent to retrieve `tinyobjloader`
[cmake] CHECK_PASSDone
[cmake] CHECK_STARTmujoco::FindOrFetch: checking for targets in package `ccd`
[cmake] CHECK_FAILtarget `ccd` not defined.
[cmake] CHECK_STARTmujoco::FindOrFetch: Using FetchContent to retrieve `ccd`
[cmake] CMake Warning (dev) at /home/xingyuan/mujoco_mpc/build/_deps/ccd-src/CMakeLists.txt:9 (project):
[cmake]   Policy CMP0048 is not set: project() command manages VERSION variables.
[cmake]   Run "cmake --help-policy CMP0048" for policy details.  Use the cmake_policy
[cmake]   command to set the policy and suppress this warning.
[cmake]
[cmake]   The following variable(s) would be set to empty:
[cmake]
[cmake]     PROJECT_VERSION
[cmake]     PROJECT_VERSION_MAJOR
[cmake]     PROJECT_VERSION_MINOR
[cmake]     PROJECT_VERSION_PATCH
[cmake] This warning is for project developers.  Use -Wno-dev to suppress it.
[cmake]
[cmake] -- Performing Test COMPILER_SUPPORTS_VISIBILITY
[cmake] -- Performing Test COMPILER_SUPPORTS_VISIBILITY - Success
[cmake] CHECK_PASSDone
[cmake] CHECK_PASSDone
[cmake] CHECK_STARTmujoco::FindOrFetch: checking for targets in package `GTest`
[cmake] CHECK_FAILtarget `gtest` not defined.
[cmake] CHECK_STARTmujoco::FindOrFetch: Using FetchContent to retrieve `googletest`
[cmake] -- Found Python: /home/xingyuan/miniconda3/bin/python3.9 (found version "3.9.13") found components: Interpreter
[cmake] CHECK_PASSDone
[cmake] CHECK_STARTmujoco::FindOrFetch: checking for targets in package `absl`
[cmake] CHECK_FAILtarget `absl::core_headers` not defined.
[cmake] CHECK_STARTmujoco::FindOrFetch: Using FetchContent to retrieve `abseil-cpp`
[cmake] CHECK_PASSDone
[cmake] CHECK_STARTmujoco::FindOrFetch: checking for targets in package `glfw`
[cmake] CHECK_FAILtarget `glfw` not defined.
[cmake] CHECK_STARTmujoco::FindOrFetch: Using FetchContent to retrieve `glfw`
[cmake] -- Using X11 for window creation
[cmake] -- Found X11: /usr/include
[cmake] -- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so
[cmake] -- Looking for XOpenDisplay in /usr/lib/x86_64-linux-gnu/libX11.so;/usr/lib/x86_64-linux-gnu/libXext.so - found
[cmake] -- Looking for gethostbyname
[cmake] -- Looking for gethostbyname - found
[cmake] -- Looking for connect
[cmake] -- Looking for connect - found
[cmake] -- Looking for remove
[cmake] -- Looking for remove - found
[cmake] -- Looking for shmat
[cmake] -- Looking for shmat - found
[cmake] -- Looking for IceConnectionNumber in ICE
[cmake] -- Looking for IceConnectionNumber in ICE - found
[cmake] CHECK_PASSDone
[cmake] -- Configuring done
[cmake] -- Generating done
[cmake] -- Build files have been written to: /home/xingyuan/mujoco_mpc/build
[build] Starting build
[proc] Executing command: /usr/bin/cmake --build /home/xingyuan/mujoco_mpc/build --config Debug --target all -j 10 --
[build] [  0%] Building C object _deps/qhull-build/CMakeFiles/qhullstatic_r.dir/src/libqhull_r/global_r.c.o
[build] [  0%] Building C object _deps/ccd-build/src/CMakeFiles/ccd.dir/ccd.c.o
[build] [  0%] Built target tinyobjloader
[build] [  0%] Built target absl_spinlock_wait
[build] [  0%] Built target absl_log_severity
[build] [  0%] Built target tinyxml2
[build] [  0%] Built target absl_random_seed_gen_exception
[build] [  1%] Built target lodepng
[build] [  2%] Built target absl_int128
[build] [  2%] Building C object _deps/ccd-build/src/CMakeFiles/ccd.dir/mpr.c.o
[build] [  2%] Building C object _deps/qhull-build/CMakeFiles/qhullstatic_r.dir/src/libqhull_r/stat_r.c.o
[build] [  2%] Built target absl_random_internal_platform
[build] [  4%] Building C object _deps/ccd-build/src/CMakeFiles/ccd.dir/polytope.c.o
[build] [  4%] Building C object _deps/qhull-build/CMakeFiles/qhullstatic_r.dir/src/libqhull_r/geom2_r.c.o
[build] [  4%] Copying tasks into binary directory
[build] [  4%] Building C object _deps/ccd-build/src/CMakeFiles/ccd.dir/support.c.o
[build] [  5%] Built target absl_civil_time
[build] [  8%] Built target absl_time_zone
[build] [  8%] Building C object _deps/ccd-build/src/CMakeFiles/ccd.dir/vec3.c.o
[build] [  8%] Building C object _deps/qhull-build/CMakeFiles/qhullstatic_r.dir/src/libqhull_r/poly2_r.c.o
[build] [  8%] Building C object _deps/qhull-build/CMakeFiles/qhullstatic_r.dir/src/libqhull_r/libqhull_r.c.o
[build] [ 10%] Building C object _deps/qhull-build/CMakeFiles/qhullstatic_r.dir/src/libqhull_r/merge_r.c.o
[build] [ 10%] Built target copy_resources
[build] [ 10%] Building C object _deps/qhull-build/CMakeFiles/qhullstatic_r.dir/src/libqhull_r/geom_r.c.o
[build] [ 11%] Built target absl_exponential_biased
[build] [ 11%] Built target absl_flags_commandlineflag_internal
[build] [ 11%] Linking C static library ../../../lib/libccd.a
[build] [ 11%] Building C object _deps/qhull-build/CMakeFiles/qhullstatic_r.dir/src/libqhull_r/poly_r.c.o
[build] [ 11%] Building C object _deps/qhull-build/CMakeFiles/qhullstatic_r.dir/src/libqhull_r/qset_r.c.o
[build] [ 13%] Building C object _deps/qhull-build/CMakeFiles/qhullstatic_r.dir/src/libqhull_r/mem_r.c.o
[build] [ 14%] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/context.c.o
[build] [ 14%] Building C object _deps/qhull-build/CMakeFiles/qhullstatic_r.dir/src/libqhull_r/random_r.c.o
[build] [ 14%] Built target ccd
[build] [ 16%] Built target gtest
[build] [ 16%] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/init.c.o
[build] [ 16%] Built target absl_raw_logging_internal
[build] [ 16%] Building C object _deps/qhull-build/CMakeFiles/qhullstatic_r.dir/src/libqhull_r/usermem_r.c.o
[build] [ 16%] Building C object _deps/qhull-build/CMakeFiles/qhullstatic_r.dir/src/libqhull_r/userprintf_r.c.o
[build] [ 17%] Building C object _deps/qhull-build/CMakeFiles/qhullstatic_r.dir/src/libqhull_r/user_r.c.o
[build] [ 17%] Building C object _deps/qhull-build/CMakeFiles/qhullstatic_r.dir/src/libqhull_r/io_r.c.o
[build] [ 17%] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/input.c.o
[build] [ 19%] Built target absl_random_internal_randen_slow
[build] [ 19%] Built target absl_random_internal_randen_hwaes_impl
[build] [ 19%] Building C object _deps/qhull-build/CMakeFiles/qhullstatic_r.dir/src/libqhull_r/accessors_r.c.o
[build] [ 19%] Building C object _deps/qhull-build/CMakeFiles/qhullstatic_r.dir/src/libqhull_r/rboxlib_r.c.o
[build] [ 19%] Built target absl_debugging_internal
[build] [ 19%] Built target absl_cordz_functions
[build] [ 19%] Building C object _deps/qhull-build/CMakeFiles/qhullstatic_r.dir/src/libqhull_r/userprintf_rbox_r.c.o
[build] [ 19%] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/monitor.c.o
[build] [ 20%] Built target absl_bad_variant_access
[build] [ 20%] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/vulkan.c.o
[build] [ 20%] Built target gmock
[build] [ 22%] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/window.c.o
[build] [ 22%] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/x11_init.c.o
[build] [ 22%] Built target gtest_main
[build] [ 22%] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/x11_monitor.c.o
[build] [ 22%] Built target absl_bad_optional_access
[build] [ 22%] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/x11_window.c.o
[build] [ 22%] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/xkb_unicode.c.o
[build] [ 23%] Built target absl_base
[build] [ 23%] Built target absl_throw_delegate
[build] [ 25%] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/posix_time.c.o
[build] [ 25%] Built target absl_random_internal_randen_hwaes
[build] [ 25%] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/posix_thread.c.o
[build] [ 25%] Built target absl_malloc_internal
[build] [ 26%] Built target absl_demangle_internal
[build] [ 26%] Built target absl_stacktrace
[build] [ 26%] Built target absl_graphcycles_internal
[build] [ 26%] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/osmesa_context.c.o
[build] [ 26%] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/glx_context.c.o
[build] [ 26%] Built target absl_city
[build] [ 28%] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/linux_joystick.c.o
[build] [ 29%] Built target absl_low_level_hash
[build] [ 29%] Building C object _deps/glfw-build/src/CMakeFiles/glfw.dir/egl_context.c.o
[build] [ 29%] Linking C static library ../../lib/libqhullstatic_rd.a
[build] Scanning dependencies of target threadpool
[build] [ 31%] Built target absl_strings_internal
[build] [ 31%] Building CXX object CMakeFiles/threadpool.dir/threadpool.cc.o
[build] [ 31%] Built target absl_random_internal_randen
[build] [ 31%] Built target qhullstatic_r
[build] [ 35%] Built target absl_strings
[build] [ 37%] Built target absl_time
[build] [ 37%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_callback.c.o
[build] [ 37%] Built target absl_symbolize
[build] [ 38%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_collision_convex.c.o
[build] [ 40%] Built target absl_random_internal_seed_material
[build] [ 40%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_collision_box.c.o
[build] [ 40%] Linking C static library ../../../lib/libglfw3.a
[build] [ 40%] Built target absl_random_distributions
[build] [ 41%] Built target absl_flags_commandlineflag
[build] [ 43%] Built target absl_hash
[build] [ 43%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_collision_driver.c.o
[build] [ 46%] Built target absl_cord_internal
[build] [ 47%] Built target absl_random_internal_pool_urbg
[build] [ 50%] Built target absl_synchronization
[build] [ 53%] Built target absl_str_format_internal
[build] [ 53%] Built target absl_flags_private_handle_accessor
[build] [ 53%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_collision_primitive.c.o
[build] [ 53%] Built target glfw
[build] [ 53%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_core_constraint.c.o
[build] [ 53%] Built target absl_random_seed_sequences
[build] [ 53%] Built target absl_hashtablez_sampler
[build] [ 53%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_core_smooth.c.o
[build] [ 55%] Built target absl_flags_program_name
[build] [ 56%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_crossplatform.c.o
[build] [ 58%] Built target absl_cordz_handle
[build] [ 58%] Built target absl_flags_marshalling
[build] [ 58%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_derivative.c.o
[build] [ 58%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_file.c.o
[build] [ 58%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_forward.c.o
[build] [ 59%] Built target absl_raw_hash_set
[build] [ 61%] Built target absl_flags_config
[build] [ 61%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_inverse.c.o
[build] [ 61%] Building CXX object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_plugin.cc.o
[build] [ 61%] Built target absl_cordz_info
[build] [ 62%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_io.c.o
[build] [ 62%] Built target absl_flags_internal
[build] [ 62%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_print.c.o
[build] [ 62%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_ray.c.o
[build] [ 62%] Built target absl_cord
[build] [ 62%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_sensor.c.o
[build] [ 64%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_setconst.c.o
[build] [ 64%] Built target absl_flags_reflection
[build] [ 64%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_solver.c.o
[build] [ 64%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_support.c.o
[build] [ 64%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_util_blas.c.o
[build] [ 64%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_util_errmem.c.o
[build] [ 65%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_util_misc.c.o
[build] [ 65%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_util_solve.c.o
[build] [ 65%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_util_sparse.c.o
[build] [ 65%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_util_spatial.c.o
[build] [ 65%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_vfs.c.o
[build] [ 67%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_vis_init.c.o
[build] [ 67%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_vis_interact.c.o
[build] [ 67%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_vis_visualize.c.o
[build] [ 67%] Building CXX object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/user/user_composite.cc.o
[build] [ 67%] Building CXX object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/user/user_mesh.cc.o
[build] [ 68%] Building CXX object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/user/user_model.cc.o
[build] [ 68%] Building CXX object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/user/user_objects.cc.o
[build] [ 68%] Linking CXX static library lib/libthreadpool.a
[build] [ 68%] Building CXX object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/user/user_util.cc.o
[build] [ 68%] Building CXX object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/xml/xml_api.cc.o
[build] [ 68%] Building CXX object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/xml/xml_base.cc.o
[build] [ 68%] Built target threadpool
[build] [ 68%] Building CXX object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/xml/xml.cc.o
[build] [ 68%] Built target absl_flags
[build] [ 70%] Building CXX object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/xml/xml_native_reader.cc.o
[build] [ 71%] Built target absl_flags_usage_internal
[build] [ 71%] Built target absl_flags_usage
[build] [ 73%] Built target absl_flags_parse
[build] [ 73%] Building CXX object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/xml/xml_numeric_format.cc.o
[build] [ 73%] Building CXX object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/xml/xml_native_writer.cc.o
[build] [ 73%] Building CXX object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/xml/xml_urdf.cc.o
[build] [ 73%] Building CXX object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/xml/xml_util.cc.o
[build] [ 74%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/render/glad/glad.c.o
[build] [ 74%] Building CXX object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/render/glad/loader.cc.o
[build] [ 74%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/render/render_context.c.o
[build] [ 74%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/render/render_gl2.c.o
[build] [ 74%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/render/render_gl3.c.o
[build] [ 76%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/render/render_util.c.o
[build] [ 76%] Building C object _deps/mujoco-build/CMakeFiles/mujoco.dir/src/ui/ui_main.c.o
[build] [ 76%] Linking CXX shared library ../../lib/libmujoco.so
[build] [ 76%] Built target mujoco
[build] [ 76%] Built target lqr
[build] [ 76%] Built target finite_difference
[build] [ 76%] Built target load
[build] Scanning dependencies of target libmjpc
[build] [ 76%] Building CXX object CMakeFiles/libmjpc.dir/states/state.cc.o
[build] [ 76%] Building CXX object CMakeFiles/libmjpc.dir/agent.cc.o
[build] [ 76%] Building CXX object CMakeFiles/libmjpc.dir/states/include.cc.o
[build] [ 76%] Building CXX object CMakeFiles/libmjpc.dir/trajectory.cc.o
[build] [ 77%] Building CXX object CMakeFiles/libmjpc.dir/utilities.cc.o
[build] [ 77%] Building CXX object CMakeFiles/libmjpc.dir/tasks/tasks.cc.o
[build] [ 77%] Building CXX object CMakeFiles/libmjpc.dir/tasks/acrobot/acrobot.cc.o
[build] [ 77%] Building CXX object CMakeFiles/libmjpc.dir/tasks/hand/hand.cc.o
[build] [ 77%] Building CXX object CMakeFiles/libmjpc.dir/tasks/cartpole/cartpole.cc.o
[build] [ 79%] Building CXX object CMakeFiles/libmjpc.dir/tasks/humanoid/humanoid.cc.o
[build] [ 79%] Building CXX object CMakeFiles/libmjpc.dir/tasks/particle/particle.cc.o
[build] [ 79%] Building CXX object CMakeFiles/libmjpc.dir/tasks/quadrotor/quadrotor.cc.o
[build] [ 79%] Building CXX object CMakeFiles/libmjpc.dir/tasks/quadruped/quadruped.cc.o
[build] /home/xingyuan/mujoco_mpc/mjpc/agent.cc: In member function ‘void mjpc::Agent::Gui(mjUI&)’:
[build] /home/xingyuan/mujoco_mpc/mjpc/agent.cc:288:57: error: no match for ‘operator=’ (operand types are ‘mjuiDef’ {aka ‘mjuiDef_’} and ‘<brace-enclosed initializer list>’)
[build]   288 |                           DataAt(task_.weight, i), "0 1"};
[build]       |                                                         ^
[build] In file included from /home/xingyuan/mujoco_mpc/build/_deps/mujoco-src/include/mujoco/mujoco.h:40,
[build]                  from /home/xingyuan/mujoco_mpc/mjpc/agent.h:23,
[build]                  from /home/xingyuan/mujoco_mpc/mjpc/agent.cc:15:
[build] /home/xingyuan/mujoco_mpc/build/_deps/mujoco-src/include/mujoco/mjui.h:303:8: note: candidate: ‘constexpr mjuiDef_& mjuiDef_::operator=(const mjuiDef_&)’
[build]   303 | struct mjuiDef_ {                 // table passed to mjui_add()
[build]       |        ^~~~~~~~
[build] /home/xingyuan/mujoco_mpc/build/_deps/mujoco-src/include/mujoco/mjui.h:303:8: note:   no known conversion for argument 1 from ‘<brace-enclosed initializer list>’ to ‘const mjuiDef_&’
[build] /home/xingyuan/mujoco_mpc/build/_deps/mujoco-src/include/mujoco/mjui.h:303:8: note: candidate: ‘constexpr mjuiDef_& mjuiDef_::operator=(mjuiDef_&&)’
[build] /home/xingyuan/mujoco_mpc/build/_deps/mujoco-src/include/mujoco/mjui.h:303:8: note:   no known conversion for argument 1 from ‘<brace-enclosed initializer list>’ to ‘mjuiDef_&&’
[build] /home/xingyuan/mujoco_mpc/mjpc/agent.cc:307:74: error: no match for ‘operator=’ (operand types are ‘mjuiDef’ {aka ‘mjuiDef_’} and ‘<brace-enclosed initializer list>’)
[build]   307 |     defFeatureParameters[0] = {mjITEM_SEPARATOR, "Residual Parameters", 1};
[build]       |                                                                          ^
[build] In file included from /home/xingyuan/mujoco_mpc/build/_deps/mujoco-src/include/mujoco/mujoco.h:40,
[build]                  from /home/xingyuan/mujoco_mpc/mjpc/agent.h:23,
[build]                  from /home/xingyuan/mujoco_mpc/mjpc/agent.cc:15:
[build] /home/xingyuan/mujoco_mpc/build/_deps/mujoco-src/include/mujoco/mjui.h:303:8: note: candidate: ‘constexpr mjuiDef_& mjuiDef_::operator=(const mjuiDef_&)’
[build]   303 | struct mjuiDef_ {                 // table passed to mjui_add()
[build]       |        ^~~~~~~~
[build] /home/xingyuan/mujoco_mpc/build/_deps/mujoco-src/include/mujoco/mjui.h:303:8: note:   no known conversion for argument 1 from ‘<brace-enclosed initializer list>’ to ‘const mjuiDef_&’
[build] /home/xingyuan/mujoco_mpc/build/_deps/mujoco-src/include/mujoco/mjui.h:303:8: note: candidate: ‘constexpr mjuiDef_& mjuiDef_::operator=(mjuiDef_&&)’
[build] /home/xingyuan/mujoco_mpc/build/_deps/mujoco-src/include/mujoco/mjui.h:303:8: note:   no known conversion for argument 1 from ‘<brace-enclosed initializer list>’ to ‘mjuiDef_&&’
[build] /home/xingyuan/mujoco_mpc/mjpc/agent.cc:312:14: error: no match for ‘operator=’ (operand types are ‘mjuiDef’ {aka ‘mjuiDef_’} and ‘<brace-enclosed initializer list>’)
[build]   312 |         "0 1"};
[build]       |              ^
[build] In file included from /home/xingyuan/mujoco_mpc/build/_deps/mujoco-src/include/mujoco/mujoco.h:40,
[build]                  from /home/xingyuan/mujoco_mpc/mjpc/agent.h:23,
[build]                  from /home/xingyuan/mujoco_mpc/mjpc/agent.cc:15:
[build] /home/xingyuan/mujoco_mpc/build/_deps/mujoco-src/include/mujoco/mjui.h:303:8: note: candidate: ‘constexpr mjuiDef_& mjuiDef_::operator=(const mjuiDef_&)’
[build]   303 | struct mjuiDef_ {                 // table passed to mjui_add()
[build]       |        ^~~~~~~~
[build] /home/xingyuan/mujoco_mpc/build/_deps/mujoco-src/include/mujoco/mjui.h:303:8: note:   no known conversion for argument 1 from ‘<brace-enclosed initializer list>’ to ‘const mjuiDef_&’
[build] /home/xingyuan/mujoco_mpc/build/_deps/mujoco-src/include/mujoco/mjui.h:303:8: note: candidate: ‘constexpr mjuiDef_& mjuiDef_::operator=(mjuiDef_&&)’
[build] /home/xingyuan/mujoco_mpc/build/_deps/mujoco-src/include/mujoco/mjui.h:303:8: note:   no known conversion for argument 1 from ‘<brace-enclosed initializer list>’ to ‘mjuiDef_&&’
[build] [ 79%] Building CXX object CMakeFiles/libmjpc.dir/tasks/swimmer/swimmer.cc.o
[build] [ 80%] Building CXX object CMakeFiles/libmjpc.dir/tasks/walker/walker.cc.o
[build] make[2]: *** [CMakeFiles/libmjpc.dir/build.make:89: CMakeFiles/libmjpc.dir/agent.cc.o] Error 1
[build] make[2]: *** Waiting for unfinished jobs....
[build] make[1]: *** [CMakeFiles/Makefile2:1249: CMakeFiles/libmjpc.dir/all] Error 2
[build] make: *** [Makefile:141: all] Error 2
[proc] The command: /usr/bin/cmake --build /home/xingyuan/mujoco_mpc/build --config Debug --target all -j 10 -- exited with code: 2 and signal: null
[build] Build finished with exit code 2

Are you building with C++ 20?

Also you're using different compilers for C++ and C.
[cmake] -- The CXX compiler identification is GNU 9.4.0```

Thanks for the help, @kevinzakka @saran-t. Following the GitHub action, I switch to clang-12 and the code can be compiled correctly!
FYI, I fix the mismatch of the version between the C compiler and the C++ compiler, and it still raises the same error. I also try GNU 8, and GNU 9, and the error stays the same.  Could be some bugs in the compiler.


[feat] Add scroll end callback to support lazy loading functionality

Add a new prop scrollEndCallback for the BoxVirtualizer component to provide a scroll end event handler.

Resolves #13


Execution Dashboard Backend Pagination & Frontend Loading Icon

This PR addresses the issue #3016 that execution dashboard takes long time to load.
Changed made:

Add loading icon in the frontend while loading the execution info
Move the pagination to backend, including the sorting and filtering function.

The sorting function on execution names should be worked. It seems not working might because of the default name for each execution is the same. The id in the parenthesis is not included in the execution name.


Migrate kapt to ksp

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).
Fixes #2470
Description
To be polished.

move stdlib to 1.9.22 ( to be compatible with ksp 1.9.22)
use ksp instead of kapt

Alternative(s) considered
Have to run the demo in admin mode on windows but not possible due to our entreprise policy
Type
Bug fix
Screenshots (if applicable)
Checklist

[x] I have read and acknowledged the Code of conduct.
[x] I have read the Contributing page.
[x] I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA.
[x] I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach.
[x] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project.
[x] I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally.
[x] I have built and run the demo app(s) to verify my change fixes the issue and/or does not break the demo app(s).

thanks for this pr this looks fine to me if tests pass

push a new version with something similar to other plugins.
3 tests are failing with this error:
java.lang.IllegalStateException: Illegal connection pointer 4411. Current pointers for thread Thread[arch_disk_io_1 @coroutine#204,5,SDK 24] []
Will try to investigate today. don't know the root cause for now

I fixed some unit tests:

NpmFileManagerTest: was failing on Windows due to File separator.
FhirSyncWorkerTest: I add to start in test mode and clean up FhirEngineProvider to let the test pass. Without this modification I get the  error java.lang.IllegalStateException: Illegal connection pointer 4411

Some tests are still failing and I suppose it's due to my locale:

For instance QuestionnaireUiEspressoTest (expected: 2005-01-05T06:10 but was : 2005-01-05T18:10)

I believe the test failing in QuestionnaireUiEspressoTest is dateTimePicker_shouldSetAnswerWhenDateAndTimeAreFilled. It's a flaky test.  Even this PR has this problem.
@jingtang10 Is someone working on this flaky test ?

Some tests are still failing and I suppose it's due to my locale:

thanks for these! we shouldn't have tests that fail in different locales - we should fix those - can you point out which tests those are?

I believe the test failing in QuestionnaireUiEspressoTest is dateTimePicker_shouldSetAnswerWhenDateAndTimeAreFilled. It's a flaky test. Even this PR has this problem. @jingtang10 Is someone working on this flaky test ?

got ya - can you take a look at this?

FYI I have created #2485 re. the flaky QuestionnaireUiEspressoTest$dateTimePicker_shouldSetAnswerWhenDateAndTimeAreFilled test 12/24h problem.

Hello, thanks for your answers. Is there another step to let this PR be accepted ? I see that Kokoro step is still pending but I can't have the details.

Hello, thanks for your answers. Is there another step to let this PR be accepted ?

I (only now, didn't look before) noticed that it already has 2 approvals and auto-merge, so it just needs a green build, then it will go in.

I see that Kokoro step is still pending but I can't have the details.

There were some problems which were just solved, see #2485 and #2488, I've tried to click Update branch to see if it helps.

@icrc-fdeniger following the merge of #2463 there is a small conflict - can you have a look and (manually) resolve that? Tx!


test framework: analyze tests without running them

What:

Moves validation/failure for feature labels out of the actual test flow and into a nearly-instant analysis test
Produces a validation result YAML that tells us which tests are

Valid (right now the only thing that invalidates is the lack of feature label)
Allow single-cluster (maxClusters < 2)
Allow multi-cluster (maxClusters != 1)
Tests marked notImplemented
Why:

I share the pain in https://github.com/istio/istio/pull/24875 when trying to quickly iterate locally; adding subtests to existing whitelisted tests (see mirrorTest) will trigger a failure. Small annoyance, but easy to run into; have to wait for ~1-2 mins of setup again.
As part of https://github.com/istio/istio/issues/24581 I needed a good way to track whether or not a test supported multicluster; that didn't fit cleanly into the feature labels.

We could integrate this to some dashboard or other, for now I'd just like to add a prow job to quickly check for the feature labels validation and use it myself for tracking the multicluster test migration.

Example output
suiteid: pilot
labels: []
singlecluster: true
multicluster: false
tests:
- testid: TestWait
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestVersion
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestDescribe
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestAddToAndRemoveFromMesh
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestProxyConfig
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestProxyStatus
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestAuthZCheck
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestMirroring
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestMirroringExternalService
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestReachability
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestSniffing
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestTrafficRouting
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestServiceEntryDNS
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestServiceEntryDNSNoSelfImport
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestServiceEntryStatic
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestSidecarScopeIngressListener
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestSidecarListeners
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestTrafficShifting
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false

Example output (rebased on #24549)
suiteid: pilot
labels: []
singlecluster: true
multicluster: true
tests:
- testid: TestWait
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestVersion
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestDescribe
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestAddToAndRemoveFromMesh
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestProxyConfig
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestProxyStatus
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestAuthZCheck
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestMirroring
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: true
  notimplemented: false
- testid: TestMirroringExternalService
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: true
  notimplemented: false
- testid: TestReachability
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: true
  notimplemented: false
- testid: TestSniffing
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: true
  notimplemented: false
- testid: TestTrafficRouting
  labels: []
  features:
    traffic.routing:
    - ""
  valid: true
  singlecluster: true
  multicluster: true
  notimplemented: false
- testid: TestServiceEntryDNS
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: true
  notimplemented: false
- testid: TestServiceEntryDNSNoSelfImport
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: true
  notimplemented: false
- testid: TestServiceEntryStatic
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: true
  notimplemented: false
- testid: TestSidecarScopeIngressListener
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: true
  notimplemented: false
- testid: TestSidecarListeners
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false
- testid: TestTrafficShifting
  labels: []
  features: {}
  valid: true
  singlecluster: true
  multicluster: false
  notimplemented: false

[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[X] Test and Release
[ ] User Experience
[X] Developer Infrastructure

@stevenctl: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
a3e56a8580a5d106ec87e7cf8fca396d587018f7
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevenctl: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
a3e56a8580a5d106ec87e7cf8fca396d587018f7
link
/test lint_istio

gencheck_istio
a3e56a8580a5d106ec87e7cf8fca396d587018f7
link
/test gencheck_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevenctl: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

gencheck_istio
a3e56a8580a5d106ec87e7cf8fca396d587018f7
link
/test gencheck_istio

lint_istio
071a32dbfffd428e2d3bf15e8c126c4563c2a94f
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevenctl: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
278f7948bbc8db39f47321620310088f47fce0e2
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevenctl: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
2e1cc3371a02615acb75e3291462fcdf2f016159
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevenctl: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
17986d16a1be14b2c9125802558eb51a4a5009a1
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevenctl: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
1db1fc0991ff1d2a1d8c103d98232588fd9cff87
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@stevenctl: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
57b6608141a7a10b46d84e2a41a24af916545651
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Multiple calls writeAndflush at the same time  will  delay 3-5 seconds

There is no problem when there are not many users. When there are about 2000 users online（call writeAndFlush 2000 times per second） at the same time, the response will be delayed for a few seconds.
This is my code
Main Thread:
     ResourceLeakDetector.setLevel(ResourceLeakDetector.Level.ADVANCED);
     EventLoopGroup bossGroup = new NioEventLoopGroup();
     EventLoopGroup workGroup = new NioEventLoopGroup(128);
     try {
         ServerBootstrap b = new ServerBootstrap();
         b.group(bossGroup, workGroup)
                 .channel(NioServerSocketChannel.class)
                 .handler(new LoggingHandler(LogLevel.DEBUG))
                 .childOption(ChannelOption.SO_KEEPALIVE, true)
                 .childOption(ChannelOption.WRITE_BUFFER_WATER_MARK, new WriteBufferWaterMark(128*1024, 256*1024))
                 .childHandler(
                         new ChannelInitializer<SocketChannel>() {
                             public void initChannel(SocketChannel ch) {
                                 ch.pipeline().addLast(new IdleStateHandler(60, 60, 60));
                                 ch.pipeline().addLast("http-codec", new HttpServerCodec());
                                 ch.pipeline().addLast("aggregator", new HttpObjectAggregator(65536));
                                 ch.pipeline().addLast("http-chunked", new ChunkedWriteHandler());
                                 ch.pipeline().addLast("decoder",new FixedLengthFrameDecoder(2*1024*1024));
                                 ch.pipeline().addLast("handler", new WebSocketServerHandler(port));
                             }
                         }
                 );
         ChannelFuture f = b.bind(port).sync();
         f.channel().closeFuture().sync();
     } catch (Exception e) {
         e.printStackTrace();
     } finally {
         bossGroup.shutdownGracefully();
         workGroup.shutdownGracefully();
     }

Logic Thread
public static void sendMsgToChannel(Channel channel, WebMessage message) {
    if (channel == null || !channel.isActive()) {
        return;
    }
    //logger.info("----sendMsgToChannel----{}", JSON.toJSONString(message));
    channel.writeAndFlush(new TextWebSocketFrame(JSON.toJSONString(message, new SerializerFeature[]{SerializerFeature.DisableCircularReferenceDetect})));
}

There are lots of Logic Threads,  and every thread will send msg to client by channel after process.
When the call of sendMsgToChannel less than 1500 times per second, all are good. But more than 2000 times, some msg will delay about 5 seconds. I check the tcp win and buffer, both are enough, and the network also good, no delay.
And I also thought maybe some channel got the  WRITE_BUFFER_WATER_MARK level,  but when i print log. every channel send one msg  in a few seconds and msg is small one.
I find the problem from internet, some one also has the same problem.

using netty-all-4.1.6.Final.jar

http://normanmaurer.me/presentations/2014-facebook-eng-netty/slides.html#10.0
I saw this PPT
I only use ChunkedWriteHandler, also checked channel.isWritable()

Please upgrade to the latest version of Netty 4.1.

Please upgrade to the latest version of Netty 4.1.
already found the issue and repaired?

I try the latest version , but it also the same.

hello,  no one help me

Are you blocking any Event loop?

Let me close this for now... Please re-open if the problem still shows up after you applied the suggestions

spark shuffle has the same problem when using netty

@vajaw please open a new issue and provide details


Mention the 'unknown' CVE severity in descriptions

Actually there's no functional change needed for EC to support the new CVE severity, but we mention in the documentation and commentary what the expected value for CVE severity are, so this patch updates that.
Additionally I added 'unknown' to the dummy data in the tests, and added some test coverage so it includes some output for the 'unknown' results. It's also not really needed, but I think it helps communicate the intention for future readers of the code.
Resolves: https://issues.redhat.com/browse/EC-36

Codecov Report

Merging #751 (86e3b22) into main (9ed75d7) will not change coverage.
Report is 1 commits behind head on main.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main      #751   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           84        84
  Lines         3072      3072
=========================================
  Hits          3072      3072

Files
Coverage Δ

policy/lib/rule_data.rego
100.00% <ø> (ø)

policy/release/cve.rego
100.00% <ø> (ø)

policy/release/cve_test.rego
100.00% <ø> (ø)

Resolved a conflict with the slsa v1 changes in #733, but should be good now. Let's merge.

Added one more commit to tidy up some repeated dummy data in the tests.


Disable auto-complete on comments

Resolves #4907 by disabling any auto-completion on comments.
As flodiebold pointed out, in the future we may want to support some form of auto-completion within doc comments, but for now it was suggested to just disable auto-completion on them entirely.
The implementation involves adding a new field is_comment to CompletionContext and checking if the immediate token we auto-completed on is a comment. I couldn't see a case where we need to check any of the ancestors, but let me know if this is not sufficient. I also wasn't sure if it was necessary to add a new field to this struct, but I decided it's probably the best option if we want to potentially do auto-completion on doc comments in the future.
Finally, the three tests I added should I think ideally not filter results by CompletionKind::Keyword, but if I want to get unfiltered results, I need access to a non-public function get_all_completion_items which I don't know if I should make public just for this.

I think only keyword completion is triggered in comments, so let’s at least move the check to keywords.
All the other completion contributors are more specific, and just don’t match comments at all.
I wonder why keywords match thoug? Perhaps there’s some bug?
What I am getting at is that “should this completion be triggered here” check is supposed to be precise, if keywords trigger in comments, there might be some additional cases where they falsely trigger, and we need to avoid that as well.

Good call. Somehow it didn't occur to me as odd that only one set of checks (complete_expr_keyword) was returning completions in comments...
However, I still think explicitly checking if we are on a comment in complete_expr_keyword may be a good solution. The checks that are currently used for keyword completion items I feel are probably correct in the majority of cases, although I'm not certain. The checks for all keyword completion items are just checking the state of various combinations of CompletionContext fields. For example, these are the only two requirements to add the const and type completion items:
if ctx.has_item_list_or_source_file_parent || ctx.block_expr_parent {
    add_keyword(ctx, acc, "const", "const ");
    add_keyword(ctx, acc, "type", "type ");
}

It's easy to see that something like:
fn foo() {
    x = 2 // A comment<|>
}

will still add const and type to the list of completion items because the parent is a block (ctx.has_item_list_or_source_file_parent and ctx.block_expr_parent are actually actually true/false respectively ATM which I'm pretty sure is wrong, but I can create a separate PR for this). Other completion functions (ie. complete_fn_param, complete_qualified_path) end up ignoring comments by doing an early return at the beginning. For example, complete_qualified_path returns early if it's not dealing with a path.
Because the rules to add keywords in complete_expr_keyword seem correct when not dealing with comments, I think adding an early return if we are dealing with a comment might be appropriate. Unlike the other completion functions, this one is active in multiple contexts where we can't just do an early return if we're not dealing with a function/path/record/etc. I think here we probably should explicitly check for these edge cases.

scoping is comment check to only keywords seems fine by me!

@matklad I changed the implementation to just check if the current token is a comment in complete_expr_keyword.
Hope it's ok to do a direct token comparison here. I can't see another way to check if it's a comment.
Also, it looks like npm audit is failing for ubuntu-latest, but I don't think this is from any of my changes.

bors r+


BUG: ValueError: Got a larger chunk overlap (200) than chunk size (173), should be smaller.

Just upgraded to the latest version (0.4.14 -> 0.4.19) and my working code is throwing the following error when calling query.
File "/Users/ankit/miniforge3/lib/python3.10/site-packages/llama_index/langchain_helpers/text_splitter.py", line 36, in init
raise ValueError(
ValueError: Got a larger chunk overlap (200) than chunk size (173), should be smaller.
Using a GPTSimpleVectorIndex with LLMPredictor(llm=OpenAI(temperature=0, model_name="text-davinci-003", max_tokens=2048))

Seems to have resolved itself now.
I did upgrade OpenAI and tenacity packages to the latest versions.

@ankitb82 do you mean the error has resolved? if so i'll close the issue

Closing since I can no longer repro! Btw, thanks for continuing to make frequent changes and adding features.

np, let me know if it pops up again!

facing the same issue with flan t5

@jerryjliu Facing the issue with flan-t5.

Facing the issue with flan-t5

@ankitb82 Please re-open the issue.

I got: ValueError: A single term is larger than the allowed chunk size.
Term size: 5613
Chunk size: 3900Effective chunk size: 3900

Me too "ValueError: Got a larger chunk overlap (40) than chunk size (-43), should be smaller."

Same to me.
llm_predictor = LLMPredictor(llm=ChatOpenAI(temperature=0.2, model_name="gpt-3.5-turbo"))
service_context = ServiceContext.from_defaults(llm_predictor=llm_predictor, chunk_size_limit=4000)

ValueError: A single term is larger than the allowed chunk size.
Term size: 3548
Chunk size: 3375Effective chunk size: 3375


Type URLs for x/authz messages not present

In cosmos-sdk-proto, I'm not seeing any Type URL implementations for any of the messages in the x/authz module. For example, MsgGrant, or GenericAuthorization.

https://github.com/cosmos/cosmos-rust/blob/main/cosmos-sdk-proto/src/type_urls.rs This file maybe have not impl for the type.

Yeah, right now adding the type URLs is a manual process unfortunately.
I opened an upstream PR which attempts to upstream some of the work from these crates so it can be automated with prost-build: https://github.com/tokio-rs/prost/pull/858

Gotcha. Yeah it's not a super big deal even now as I can manually input the Type URLs when serializing to any. Just would be nice to have this all consistent!

As a stopgap we could possibly add something to proto-build

We now autogenerate prost::Name annotations using buf for all types


All builds stuck until exceeding time limit

I've tried setting up this action yesterday, but it seems like nothing ever happens.
There is no console log, and after 6 hours github eventually cancelled all my builds.
The project is fairly simple, so that shouldnt be the issue (however note it does use C#/.NET).

If you need more details, you can find the failed run here.

It looks like the editor is running in headless mode while doing nothing. Remember to use the --export command line argument if you want the project to be exported – the editor will exit automtaically in this case.

It looks like the editor is running in headless mode while doing nothing. Remember to use the --export command line argument if you want the project to be exported – the editor will exit automtaically in this case.
The command line should look similar to this:
path/to/godot.binary --headless --export "Windows Desktop" path/to/output.exe

The action seems to be using --export-release

The action seems to be using --export-release

This is correct (--export is a legacy option, which acted the same as --export-release). I've edited my comment accordingly.

so.. it is doing exactly what you are suggesting already?

so.. it is doing exactly what you are suggesting already?

Yes :slightly_smiling_face:
Try adding --quit-after 100 in the command line.

but I dont have access to the process's command line..


UPI Intent flow

Not able to do UPI Intent flow, have to add UPI Id again for the payments. As Drop Checkout flow and UPI Intent flow discussed in the native Android doc, not covered in the Flutter doc.

Hi @knightowlRaising, Intent is part of drop checkout.

Thanks @suhas-cashfree for clarifying it. But I'm not able to select UPI apps directly, have to enter UPI Id after choosing one of the options.

I am not able to select UPI Mode, how can I select UPI mode, by default it is raising a collect request.

Add the permissions present here in Android manifest and try https://docs.cashfree.com/docs/android-sdk#upi-intent

Hi @suhas-cashfree I have tried this and then we launched the app on Prod, but still not working.
<queries>     <intent>         <action android:name="android.intent.action.VIEW" />         <data android:scheme="upi" android:host="pay"/>     </intent>     <package android:name="com.android.chrome" /> </queries>
Added the above code in Manifest.

Hi @knightowlRaising
There is web checkout option too. Can you try with that

We have tried web checkout as well and got the same thing. Instead of taking me to the UPI app directly, it's asking me to enter UPI Id. Please refer attached screenshot below. 1st Screenshot is web and 2nd is App based.

Please write to<EMAIL_ADDRESS>

@suhas-cashfree the issue is resolved. Thanks for the support 🎉

@knightowlRaising What was the solution?


Add support for pre-gzipped static files

Hi, @tshemsedinov.
It would be nice to have pre-gzipped static files support. For example, if there is a file in static directory with *.gz extension, then it should be added as gzipped assert into application file cache.
This would be useful for compressing quite large files or compression with zopfli which takes a lot of cpu time. Also e.g. if there are a lot of servers in cluster it will be better to compress static files once (for example in some CI tool like jenkins) and distribute it all over the servers instead of gzipping all on each server.
I believe this can be done in impress.application.js, maybe somewhere in compress function https://github.com/tshemsedinov/impress/blob/master/lib/impress.application.js#L598. But I'm not sure what is the best way to do this: whether add check for existing file with same name, but with .gz extension before calling api.zlib.gzip or it can be done earlier in separate function which will be called on application start or static cache initialization. Also if you want I can submit a pull request, but then I need to know which option is better from your point of view.

I think we can do this putting gzipped file to /static, i.e.: /static/js/file.js.gz and addressing them like this: <script src="/js/file.js"></script>. To do this we need to change Client.prototype.static in this place: https://github.com/tshemsedinov/impress/blob/master/lib/impress.client.js#L827 so if /static/js/file.js not exists we will try to find /static/js/file.js.gz to send back and put to memory cache.
Another way to do that is to put uncompressed files to /client and use CI tools to build it into  /static so we may stop using /static for uncompressed, even more, for not precompiled and not minified files.
You can do this and send me PR if you have time or I can do this later.

@tshemsedinov in my case uncompressed files are in client folder, then all of the files are built with gulp and copied to static folder (including both uncompressed, e.g. index.html and compressed - index.html.gz). In real world those files could be even in separate repository.
I think that maybe it will be better if we check /static/js/file.js.gz first and then /static/js/file.js as "fallback", so it will be compressed version first.
Also may be it will be good idea to implement such behavior for almost all static files except images, because they are gzipped very rarely and, e.g. using zopflipng images will be aleady compressed inside png container, so gzipping them one more time will be redundant.
I'll take a look at this in few days, and if I'll be succesfull with this one, I'll submit a PR.

Some optimization: https://github.com/tshemsedinov/impress/commit/61612b38678a8c0dde3734765affb6ed8fea3eef
But it still searches for /images/logo.gif.gz

Works and optimized, but need to fix this #467 and #468


Wemake python styldeguide in workflow

ref: #44

@blablatdinov check the CI jobs, not all of them pass now

@yegor256 violations fixed

@blablatdinov thanks!


Adding Solidjs templates to vite create

Description
The solidjs framework is one of the best of JavaScript nowadays.
It's going to be much better for any developer using Vite to have it with the create templates rather then having it in a community template which isn't the best case for it.
Suggested solution
We can use the solid templates and add them with the vite settings we might need.
Alternative
No response
Additional context
I'm aware there have been an attempt to add it in the issue #5572, but I'm just asking to see if there's any changes in that policy yet as that attempt was a year ago.
I've read the entire package of createe-vite and know how a new template should be added.
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

duplicated with https://github.com/vitejs/vite/issues/12218


the performance in a100 is slower than the nvidia-tensorflow

env: A100 8gpu  + horovod
framework: DeepRec1.15.5  vs nvidia-tensorflow 1.15.4
model: transformer + mmoe
result:   DeepRec 1.8s/step,   nv-tf:0.55s/step

Duplicate issue as https://github.com/alibaba/DeepRec/issues/110


wildcard with case-insensitive?

Hi,
How do I get fields using wildcards with case-insensitive?
Pseudocode
        String filter = "*Email*,*Holder*";
        ObjectMapper mapper = Squiggly.init(new ObjectMapper(), filter);
        String res = SquigglyUtils.stringify(mapper, payments);

You can't do case-insensitive with wildcards, but you can do it with regular expressions
String filter = "/.*Email.*/i,/.*Holder.*/i";
ObjectMapper mapper = Squiggly.init(new ObjectMapper(), filter);
String res = SquigglyUtils.stringify(mapper, payments);

I'm closing this issue because I have provided an alternative to wildcards (regex), which allows you to do case insensitive matching.


Making HttpConnection restartable (C#)

(a.k.a. Opening Pandora box)

This needs a bunch of rebasing and adjusting after merging #1165 . I'll do that and ping this when I'm done.

Ok, it should be :up: to :date: now. I had to refactor some things to handle the new AbortAsync. Also, some tests seem to have been broken by the fact that Dispose waits on Start to finish, but I fixed that.
Finally, there was a test for Received not firing after Dispose is called which isn't really possible since the state changes that trigger that all occur after the channel is marked completed anyway. The test was broken so I just removed it (because it is no longer relevant).

Should be green after this next build. ping @BrennanConroy @mikaelm12
This one is unfortunately a bit of a tricky one, and I'm thinking I might do some test refactoring after this PR to make them clearer as they're a bit messy now (due to how tests tend to grow organically)


Setting user agent on Firefox and using seleniumAddress at the same time does not work

Hi,
I want to set a specific user agent using Firefox. If I use directConnect on protractor.conf.js, it works:
var firefox = require('selenium-webdriver/firefox');
var firefoxProfile = new firefox.Profile();
firefoxProfile.setPreference("general.useragent.override", 'monitoring1152936086');

exports.config = {
    directConnect: true,

    capabilities: {
        'browserName': 'firefox',
        'firefox_profile': firefoxProfile
    },
    ...
}

However, if I use seleniumAddress instead of directConnect it does not work. For example:
var firefox = require('selenium-webdriver/firefox');
var firefoxProfile = new firefox.Profile();
firefoxProfile.setPreference("general.useragent.override", 'monitoring1152936086');

exports.config = {
    seleniumAddress: 'http://localhost:4444/wd/hub',

    capabilities: {
        'browserName': 'firefox',
        'firefox_profile': firefoxProfile
    },
    ...
}

As a side note, I cannot use chrome since I am trying to use Firefox as a workaround to the not so stable combination of protractor and selenium-docker with chrome (https://github.com/SeleniumHQ/docker-selenium/issues/87).
Any ideas? Thanks!

Hi there!
Your question is better suited for StackOverflow or Gitter. Please ask a question there with the 'protractor' tag or post in the Gitter Channel to get help.
From the the getting help section of the README:

Please ask usage and debugging questions on StackOverflow (use the "protractor" tag) or in the Angular discussion group. (Please do not ask support questions here on Github.)

I haven't personally encountered this issue; my gut is that it's to do with selenium. Let's get to the bottom of it on one of the mediums above. Thanks!

Ok, I just find it strange that one way works and the other not. I have checked protractor source and it looks like different code is used to get a web driver (if I had it right):

on directConnect it uses (protractor/lib/driverProviders/direct.js):

driver = new firefox.Driver(this.config_.capabilities);

seleniumAddress it uses (protractor/lib/driverProviders/driverProvider.js):

 var newDriver = new webdriver.Builder().
      usingServer(this.config_.seleniumAddress).
      withCapabilities(this.config_.capabilities).
      build();

But let's see on stack overflow. I posted it here: http://stackoverflow.com/questions/33545039/setting-user-agent-on-firefox-with-protractor-and-using-seleniumaddress-does-not

I answered the SO question to the best of my understanding.  Thanks for reposting there!


Update the links around example data

Update the link to be raw for the download and also for the readme
cc: @moveson

Looks great. Thanks!


Using NetBox for router list

Issue type
[x] Feature request
[ ] Bug report
[ ] Documentation
Environment

Python version: 3.7
Peering Manager version:  master

Description
Using multiple tools for managing a network and its automation can lead to data duplication. This is never good in most cases because at one point one of the tools will not be updated and the data duplication will start causing some misbehavior or misunderstanding.
NetBox is a DCIM/IPAM tool in which people can document their infrastructures and track the devices they are managing.
It will be a good idea and feature to be able for Peering Manager users to use the devices they have already created inside NetBox instead of creating Router objects.
We can consider that if a user is using NetBox as source for routers details, there will be no points for him to create routers locally. The UI and the permissions related to it must be reviewed accordingly.

We use netbox here so would definitely test if you need help on that.  My python is OK so not sure how much development help I can be, but would love to try.

Implementation started with a4c415e. We do need more work on this (frontend and backend).

Using management details found in NetBox
Using platform (with NAPALM support) found in NetBox
Keep details in sync

Any other stuff?

Implementation started with a4c415e. We do need more work on this (frontend and backend).

I was just looking at this as part of some work to communicate with devices via NetBox's NAPALM API call (instead of talking directly via NAPALM) and it looks like this isn't handling pagination in the API response, so if there are more than 50 devices you'll only get a subset.
It'd probably be better to pass the device roles as filter parameters to the NetBox API as well, rather than grabbing all the devices and filtering client-side.
Would you be opposed to pulling in pynetbox? It handles the pagination issues.

Would you be opposed to pulling in pynetbox? It handles the pagination issues.

It sounds legit. So I'm not against adding pynetbox to requirements.

@2bithacker are you happy with the way Peering Manager is interacting now or do you have more improvements in mind that we could include in this issue?

I'm happy with how it's working at the moment.

@2bithacker thanks for the feedback.
Closing, further improvements can still be documented in other issues.


Fix div and friends

Gracious me, coding by copy/paste does have its downsides.
This one was my fault from back in 2014, I believe. Amazing it's not been noticed before.

I am not on a computer right now so I couldn't just test this :)
Was the problem here the return type of the div operator? It seems odd to me that the result would be an integer (in all cases).

This is what happens on master:
julia> using FixedPointNumbers
INFO: Recompiling stale cache file /home/tim/.julia/lib/v0.5/FixedPointNumbers.ji for module FixedPointNumbers.

julia> x = 16uf8
UFixed{UInt8,8}(0.063)

julia> y = 2uf8
UFixed{UInt8,8}(0.008)

julia> div(x, y)
UFixed{UInt8,8}(0.031)

julia> div(Float32(x), Float32(y))
8.0f0

julia> r = 1uf8:1uf8:10uf8
UFixed{UInt8,8}(0.004):UFixed{UInt8,8}(0.004):UFixed{UInt8,8}(0.039)

julia> length(r)
------ InexactError -------------------- Stacktrace (most recent call last)

 [1] — length(::StepRange{FixedPointNumbers.UFixed{UInt8,8},FixedPointNumbers.UFixed{UInt8,8}}) at range.jl:364

 [2] — unsafe_length(::StepRange{FixedPointNumbers.UFixed{UInt8,8},FixedPointNumbers.UFixed{UInt8,8}}) at range.jl:361

InexactError()

None of those problems happen with this branch.

Hm I see. I am still trying to wrap my head around this. Isn't the problem
that the result of the division is not representable as a UF8? I am still
wondering how falling back to integer division solves this, wouldn't it
make more sense to fall back to floating point division?
Can I also note that the printing of 2uf8 is broken on master? Or the
conversion to Float32.
On Sun, 11 Sep 2016, 21:14 Tim Holy<EMAIL_ADDRESS>wrote:

This is what happens on master:
julia> using FixedPointNumbers
INFO: Recompiling stale cache file /home/tim/.julia/lib/v0.5/FixedPointNumbers.ji for module FixedPointNumbers.
julia> x = 16uf8
UFixed{UInt8,8}(0.063)
julia> y = 2uf8
UFixed{UInt8,8}(0.008)
julia> div(x, y)
UFixed{UInt8,8}(0.031)
julia> div(Float32(x), Float32(y))8.0f0
julia> r = 1uf8:1uf8:10uf8
UFixed{UInt8,8}(0.004):UFixed{UInt8,8}(0.004):UFixed{UInt8,8}(0.039)
julia> length(r)------ InexactError -------------------- Stacktrace (most recent call last)
[1] — length(::StepRange{FixedPointNumbers.UFixed{UInt8,8},FixedPointNumbers.UFixed{UInt8,8}}) at range.jl:364
[2] — unsafe_length(::StepRange{FixedPointNumbers.UFixed{UInt8,8},FixedPointNumbers.UFixed{UInt8,8}}) at range.jl:361
InexactError()
None of those problems happen with this branch.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/JeffBezanson/FixedPointNumbers.jl/pull/47#issuecomment-246218174,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAI3aoPhk_fZTORDySMnW9r5KoX6YV6wks5qpKdXgaJpZM4J6Igf
.

Yes, it's not representable, but in general you expect it not to be. The definition of div is just "Computes x/y, truncated to an integer." So the result should be 8, not 0.031.
I'm not sure I follow what's broken about the printing/conversion to Float32:
julia> x = 2uf8
UFixed{UInt8,8}(0.008)

julia> Float32(x)
0.007843138f0

(except I'm bummed about how verbose the printing is, I thought we'd fixed that)

Ahhh, I am too tired. You are of course right.

div should return integers.
and I compared Float32(2uf8) to the wrong number

Thanks for explaining. LGTM  from my side.


Update attribute cardinality and evaluatyion

HDR_WCG_Idc and video_properties_tag attributes are always present in the descriptor.
semantic definition of video_properties_tag depends on HDR_WCG_idc to select colour format (BT709 vs BT2020 vs BT2100)

Hi @paulhiggs
Did you try the display routine? It seems to me that the following won't work:
    const uint8_t vprop_tag = buf.getBits<uint8_t>(4);
    disp << ", video properties: " << VVCVideoDescriptor::VVCVideoProperties(hdr_wcg_idc, vprop_tag)
         << " (" << vprop_tag << ")" << std::endl;

Specifically, << vprop_tag <<  will probably display some garbage. When vprop_tag was declared as uint16_t, the value was interpreted as integer and displayed in decimal. With the updated declaration as uint8_t, it will be interpreted as a character, ie. the ASCII code of a character, and displayed as that character. This is the old and annoying inability of C/C++ to discriminate between characters and 8-bit integers.

UStream::Format(u"%d", {vprop_tag}) call which I assume will display it correctly as a decimal.

Yes it will. But << int(vprop_tag) <<  is probably simpler.


Fix buffered plugin spec

Use a double-quoted string for the newline in the expected response
since single-quoted strings don't convert \n to a newline.
Expect fluentd_tags field to exist since the plugin outputs it by
default.

Hey @IvanVergiliev!
Any reason you are using the non-buffered plugin? I was actually thinking of removing this one entirely as it is highly in-effective

Hey @roiravhon!
The commit message was actually wrong; these fixes are for the buffered plugin.
However, we are indeed using the unbuffered plugin (hence my other PR) as we were having some issues with the buffered one not flushing messages. I contacted support a couple weeks ago and they said they'll open a ticket for that but it's fine to use the unbuffered one in the meantime.

Care to describe the issue you have with the buffered one?
The unbuffered is opening a new connection for each log, this is bad :)
And this is the reason I want to remove it, or at least deprecate it.

I don't have a lot of insight, the logs just weren't getting to logz.io. When I switched to the unbuffered one, things started working.
One error message that I saw in one of the buffer files was this:
<93><AB>fluent.warn<CE>YJa<8C><85><AA>retry_time^E<B2>next_retry_seconds<B9>2017-06-21 12:07:40 +0000<A5>chunk<D9> 55272265e78bae4081ee6b71c4113c4c<A5>error<C4>0#<Yajl::EncodeError: 'NaN' is an invalid number><A7>messageٿfailed to flush the buffer. retry_time=5 next_retry_seconds=2017-06-21 12:07:40 +0000 chunk="55272265e78bae4081ee6b71c4113c4c" error_class=Yajl::EncodeError error="'NaN' is an invalid number"

However, I'm not sure this has anything to do with the matter at hand. If you have hints on how to debug this, I'd be happy to try them.

Can you attach your configuration for using the buffered plugin? and td-agent's version

This is the config we used before switching to the unbuffered version:
        - directive: match
          directive_arg: '**'
          attrs:
            - '@type': logzio_buffered
            - endpoint_url: https://listener.logz.io:8071?token=<token>&type=log
            - output_include_time: 'true'
            - output_include_tags: 'true'
            - buffer_type: file
            - buffer_path: /var/lib/fluent/all
            - flush_interval: 10s
            - buffer_chunk_limit: 1m

fluentd version:
heap@fluentd-asg-i-02712ab19ec61584f:/usr/local/heap$ fluentd --version
fluentd 0.14.17

Have you tried installing td-agent?
Basically this is the recommended way to run fluentd
you need to install our gem using the internal gem provided in td-agent, and have your configuration file under /etc/td-agent/td-agent.conf
Based on https://www.fluentd.org/download
The latest stable version is 0.12.0 when installing as gem, so that might be the reason for this error (a configuration added in this version that is not backward compatible)

@roiravhon I managed to debug the issue - see https://github.com/logzio/fluent-plugin-logzio/pull/15 . Basically we have a message that contains a NaN value which breaks Yajl.dump, which then causes a cascading failure of the whole buffered output plugin.

Pushed https://rubygems.org/gems/fluent-plugin-logzio/versions/0.0.11
Thanks for the feedback and contribution @IvanVergiliev!


[Spotify Player] Menu Bar command not working:

Extension – Spotify Player
Author: @mattisssa

Description
The command does not function for me. Spotify app is open, everything needed however, the command does not show-up in the menu bar, refreshing does not work either.

Steps To Reproduce

Open Raycast
Search 'Menu Bar Player'
Press 'return'

Uploading Screen Recording 2022-09-05 at 6.00.08 pm.mov.zip…

The current behavior
Does not show in the menu bar. I understand this is an BETA but I'd think something should show.
The expected behavior
To show in the menu bar.
Raycast version
Version: 1.39.2

Fixed after a full reinstall of command line.


Left-nav flashes close on initial page load

Tracking issue.

cc @qchong

Left-nav flashing is now fixed.  (some icons flash in, but we can open a separate issue)


Suggest changing your escape code mechanism

Hi, just saw you starred my repo so I wanted to check this one out as well. I think you should change the escape code you're using for HTML output. I'll put this into a design document over at my repo soon but in the mean time:

You should use a custom DSR to decide if your terminal supports HTML or not. We could standardize on one like DSR 1866, then you can use a shell script like this to decide to enable your integrations or not.
You should use an OSC to read a complete HTML blob at a time, rather than having the output stream wait until a NUL byte. An OSC is strictly a sequence of printable characters, meaning that if your HTML program crashes, the next escape sequence printed (e.g. color code) will cause the OSC to be invalid, resulting in HTMl getting dumped to the terminal as text but critically not ruining the terminal for other programs who aren't aware of HTML.

Since you support outputting HTML and so do I, I definitely think it makes sense to standardize the escape codes we use. I picked 1866 because it wasn't in use and is a reference to RFC 1866.

Right now the code to dump HTML into the terminal is commented out in the Extraterm code. The reason being that I need to have a good think about how it should work and what it actually should do to be really useful.
Some questions that need better answers:

Terminals are a keyboard oriented interface. How does that mesh with HTML which is often more mouse oriented? How can we make any HTML shown in the terminal keyboard friendly?
Extraterm's cursor/selection mode which lets you copy stuff and move around the screen and scrollback via the keyboard is actually extremely useful. How would this mode interact with a HTML display mode?

Another very big consideration is figuring out how to make this kind of functionality secure, safe and robust. For example, if you use cat to show the contents of a file then NONE of the escape codes should be available for use. Always accepting escape codes would make it possible for people to embed HTML and Javascript code in a file and use it to attack the user's via the terminal itself when someone views it using cat or less. This is why Extraterm's escape codes require a cookie value to be present before they are accepted. This cookie value is made available to terminal applications as an environmental variable.
I would be happy to see some kind of standardisation of this kind of functionality in the future, but there is an awful lot of work and experimentation which has to be done first.

 How does that mesh with HTML which is often more mouse oriented? How can we make any HTML shown in the terminal keyboard friendly?

Arrows to change focus and space to activate buttons doesn't seem like the worst, but you're right. I think the mouse interfaces are a nice to have for more complex apps, but the bulk of the value is in richer visuals for components (less replaced with a text overflow div, but all the keyboard controls for less are still intact).

Extraterm's cursor/selection mode which lets you copy stuff and move around the screen and scrollback via the keyboard is actually extremely useful. How would this mode interact with a HTML display mode?

This actually looks really cool. You could maybe use contenteditable to make the HTML region editable, although I'm not sure it's as useful as text-mode commands being editable, because I imagine programs that output HTML are probably unlikely to produce output suitable for being input to other programs.

Another very big consideration is figuring out how to make this kind of functionality secure, safe and robust.

Ah, cookie makes sense then. There are 2 key principles that need to be adhered to:

Program output must not cause the terminal to send input based on previous output the terminal has received (this applies to all terminal programs; think about ssh being able to read data out of your scrollback).

Program output must not cause the terminal to transmit data over the network (this is unique to HTML-enabled terminals).

The way to safely accomplish both of these is to parse any received HTML and transform it into "safe" HTML, using a whitelist of tags and attributes. For me, this is going to be basic HTML tags and a limited set of attributes like class or image's src but restricted to data URIs (but not style, because that could have URLs). For richer components (I'm thinking like progress-bar), those are bundled with the terminal program (or installed by the user as extensions). This last set allows you to have rich components without needing to allow programs to use JavaScript.
This works out rather nicely: if you overwrite an HTML blob (think clearing the screen and rewriting it), React will detect this as a prop change rather than a delete and recreate, meaning that for no extra work my progress-bar component can smoothly animate between different states, rather than flickering.
I have not implemented any of the security features I talk about above, but the code to do that is going to look at lot like HTMLParser.js. If you're interested, we could split off that file into a module suitable for parsing "Terminal-safe HTML" and both share it?

Extraterm is more or less powered by CodeMirror. That is where the cursor, selection and editing capabilities come from. I was thinking of doing something similar for HTML and rich text formats. Integrating ProseMirror or some other WYSIWYG editing into Extraterm and using it to display the content and handle cursors and selections etc.
As for displaying 'application' HTML safely, I lean towards sandboxing instead of trying to clean up HTML. Web browsers work the same way when displaying or running a web page.


Takes a long time to run the command.

Describe the bug
It can take upwards of 10 seconds for me to run the command.
To Reproduce
run the following command and hit Q as soon as it reaches the tui:
$ time curl -fsSL https://christitus.com/linux | sh
Expected behavior
Faster launchtimes.
Screenshots

Additional context

EndeavourOS
Download speeds for me are ~11 MB/s
Linutil 08.01
Ran the command a few times to see variance.

I will address mainly how we can improve the weight of the binary, as it's to my knowledge the only thing we can affect when it comes to GitHub and distribution of the solution.
So far, I can only see 3 improvement that can be done, but they come at a cost or are not in line with the current vision of Chris.

Optimise the release profile for weight rather than speed.

From my test, we can go from a binary of 2.2 MB to 1.5 MB, so about a 33% reduction in weight. I would expect a non-linear reduction in download time.
Ofc, we lose in performance, but so far even in debug mode, the TUI is really responsive.
I will submit the ticket for that one, as the cost in responsiveness is transparent to the user so far and this is really easy to implement and revert.

Extract the commands from the binary and download them as needed.

That one, I am less a fan of as we are still in the process of finding a groove for how commands are shown/called and we are displacing waiting time in the preparation stage for waiting time at runtime.
Plus the additional complexity of dealing with async calls and executing the scripts that would add to the weight of the binary. So maybe not a real reduction in weight for now.
But, as the number of commands grow, it might become a needed solution at some point.

Caching the binary

That one is straight out not aligned with Chris's vision so far. So, I can't imagine this being implemented in the near future. But I still wanted to put it out there, as caching is a solution for users repeating the process of calling the solution.

@SoapyDev Reducing the binary size from 2.2 MB to 1.1 MB will not have any effect because as per @Kingproone , the average download speed is 11 MB/s so 2.2 MB binary should not be a issue here. I think it maybe a network latency due to geographical reasons. I think the more robust solution would be caching the binary by installing linutil.

@jeevithakannan2, I agree. But as stated in #178, the only trade-off being done is at compile time, as the level is set to 3 to maintain performance. That way we still get reduced weight (1.3 MB) for the same performance. It might not fix this issue, but I don't see any reason to not move forward with it.

Yeah I agree with you


Added a mask to check the beginning of the game finish.

The current mask checks the end of the game finish.
In this case, if the game finish takes a long time more than 15 secs,
the time out logic triggers. It then fails handling the game result data.
This PR contains only Japanese version. For other languages, the current
filter (for the end of the game finish) is used.

Thanks!


Compiling TF serve with my new op

Compiling tensorflow-serving with a custom op
First of all, thanks so much for the awesome examples of custom ops. They've been extremely helpful. I'm wondering whether you have any working examples of how to include the custom ops built with this format in TensorFlow serving?
What I've tried
I built a library of custom ops, call it custom_ops. At a high level, here's the structure:
custom_ops
|_ custom_ops/
|   |_first_op/
|   |   |_cc/
|   |   |   |_ ...
|   |   |_python/
|   |   |   |_ ...
|   |_second_op/
|   |   |_cc/
|   |   |   |_ ...
|   |   |_python/
|   |   |   |_ ...
|   |_BUILD
|_ third_party/
|   |_ ...
|_ tf/
|   |_BUILD
|   |_BUILD.tpl
|   |_tf_configure.bzl
|_ BUILD
|_ WORKSPACE

FWIW, I'm able to build the entire project, load the python bindings, and all unit tests for all ops pass. So now I want to get these ops into TensorFlow serving...
Here's the cc_library target that builds the shared custom ops library:
# /custom_ops/custom_ops/BUILD
cc_library(
  name="custom_ops_lib",
  srcs=[
    "first_op/cc/fo_kernel.cc",
    "first_op/cc/fo_op.cc",
    "second_op/cc/so_kernel.cc",
    "second_op/cc/so_op.cc",
  ],
  deps=[
    "@local_config_tf//:libtensorflow_framework",
    "@local_config_tf//:tf_header_lib",
  ],
  alwayslink=1,
  includes=[
    "custom_ops",
    "third_party",
  ],
  copts=[
    "-fPIC",
    "-pthread",
    "-std=c++11",
    "-D_GLIBCXX_USE_CXX11_ABI=0",
    "-ggdb",
  ],
  visibility=["//visibility:public"],
)

The structure of my file system:
...
/custom_ops
/tensorflow-serving
...

Inside of tensorflow-serving/tensorflow_serving/model_servers/BUILD, I've added my op:
SUPPORTED_TENSORFLOW_OPS = [
    "@org_tensorflow//tensorflow/contrib:contrib_kernels",
    "@org_tensorflow//tensorflow/contrib:contrib_ops_op_lib",
    "@my_custom_ops//custom_ops:custom_ops_lib",
]

I've added this to the tensorflow-serving/WORKSPACE file (after copying custom_ops/tf into tensorflow-serving—this part I am not sure about):
load("//tf:tf_configure.bzl", "tf_configure")
tf_configure(name = "local_config_tf")

local_repository(
    name = "my_custom_ops",
    path = "/custom-ops"
)

... and this into the tensorflow-serving/.bazelrc file:
build --workspace_status_command=/proc/self/cwd/tools/gen_status_stamp.sh
# A reduced version of the custom_ops bazelrc.
build --action_env TF_HEADER_DIR="/usr/local/lib/python3.6/dist-packages/tensorflow/include"
build --action_env TF_SHARED_LIBRARY_DIR="/usr/local/lib/python3.6/dist-packages/tensorflow"
build --action_env TF_SHARED_LIBRARY_NAME="libtensorflow_framework.so"
build --action_env TF_NEED_CUDA="0"

Compiling
Here's how I compile tf serve, which succeeds:
$ bazel build --color=yes --curses=yes \
    ${TF_SERVING_BAZEL_OPTIONS} \
    --verbose_failures \
    --output_filter=DONT_MATCH_ANYTHING \
    --config=mkl --copt=-march=skylake-avx512 --copt=-O3 \
    tensorflow_serving/model_servers:tensorflow_model_server && \
    cp bazel-bin/tensorflow_serving/model_servers/tensorflow_model_server \
    /usr/local/bin/

Running (and stack trace)
When I run TensorFlow serving (after updating LIBRARY_PATH and LD_LIBRARY_PATH), here's what I get:
$ tensorflow_model_server --model_base_path="/path-to-servable" --model_name="my-model" --enable_batching
2019-05-29 21:19:22.564025: F external/org_tensorflow/tensorflow/stream_executor/host/host_platform.cc:94] Non-OK-status: MultiPlatformManager::RegisterPlatform(std::move(platform)) status: Internal: platform is already registered with name: "Host"
Aborted (core dumped)

It would seem from rooting around that what's happening is the libtensorflow_framework.so dependency is being loaded twice (I'm guessing due to the custom_ops dependency on it?)
This is where I am out of my depth in debugging things and I cannot seem to find any end-to-end example on this anywhere. Do you have an example of how you'd integrate the custom ops in this lib (on which mine were modeled) into TF serve?

I was able to get this to work by no longer depending on @local_config_tf, as is used in this tutorial, but @org_tensorflow instead. That means that my ops can no longer use the WORKSPACE file created by this tutorial if I wish for them to live harmoniously with TensorFlow serving.
That is:

"@local_config_tf//:libtensorflow_framework" -> "@org_tensorflow//tensorflow/core:framework"
"@local_config_tf//:tf_header_lib" -> "@org_tensorflow//tensorflow/core:lib"

Also the following steps:

Copy the inner custom_ops dir to be inside the TensorFlow serving root:
$ cp -R custom-ops/custom_ops tensorflow-serving/

Copy the third party dependencies into the TensorFlow serving third_party dir:
$ cp -R custom-ops/third_party/* tensorflow-serving/third_party/

Add "//custom_ops:custom_ops_lib", to the SUPPORTED_TENSORFLOW_OPS instruction in the tensorflow_serving/model_servers/BUILD file:
SUPPORTED_TENSORFLOW_OPS = [
  "@org_tensorflow//tensorflow/contrib:contrib_kernels",
  "@org_tensorflow//tensorflow/contrib:contrib_ops_op_lib",
  "//custom_ops:custom_ops_lib",
]

This appears to solve it, however it seems like this may not be the perfect solution if you want the op to live on its own... you may consider updating the examples here to reflect something that can live in its own package but also be easily compiled with TensorFlow serving.


can't build extension properly

Everything in my extension is working locally when the files are hosted on localhost:3000 using npm run dev. I'm at a point now where I need to build the extension and deploy it.
When running npm run build, it builds the project into the build folder but when trying to run it packed or unpacked I get the error
Hot Module replacement API enabled. You should disable react-transform-hmr in production by using env section in Babel configuration. See the example in README: https://github.com/gaearon/react-transform-hmr
Ok great so it appears this transform thing should only be ran on development when hot reloading is enabled. I go to the linked readme and find the code to disable this transform babel addon in production environment:
// original .babelrc
{
  "presets": ["es2015", "stage-0", "react"],
  "plugins": ["add-module-exports", "transform-decorators-legacy", "transform-runtime"]
}

// updated .babelrc
{
  "presets": ["es2015", "stage-0", "react"],
  "env": {
    "development": {
      "plugins":  ["add-module-exports", "transform-decorators-legacy", "transform-runtime"]
    }
  }
}

I set my NODE_ENV=production and then rebuild my extension. After loading it again unpacked I don't get any error in the injected portion of the extension, but it does not work. When I open the background, I see the console error Uncaught ReferenceError: regeneratorRuntime is not defined. I try packing the extension and loading it through the crx, but I get the same error. It appears to be related to chrome.tabs.onUpdated.addListener(async (tabId, changeInfo, tab) => {}) but I haven't found a way to get rid of the error and have the extension work after a production build.
I've been going around in circles for a few days between this package, react-transform-hmr, babel, etc but can't find any solution.

I had the same issue, and I deleted the query: react-hmr and copy pasted the postCSS config inside the production config for webpack.
Thanks for saying that I have to set my NODE_ENV by this I solved my issue, good luck with yours :P

As your comment helped me realize I was updating my development webpack file instead of the production... Thanks.


Questions about the vector database

Hi there 👋
I have a few questions about the context's vector database, which is only mentioned once in the README.md.

What library versions are stored in the vector database? Only the latest major/minor version?
How responsive is the vector database to library updates? Especially for (breaking) major version releases?
Do you plan to extend the existing vector database with more libraries? I believe it would be awesome to discover newer or smaller libraries using context.
Is it or will it be possible to self-host a vector database?

Maybe I have overseen some already answered questions in the readme. If so, sorry for that 😅

Hey! Appreciate your interest in the project :)

We store the latest major version. We are working on also storing historical context. This would enable users to ask questions like "what were the major changes between pydantic version 1.0 vs 2.0" and get meaningful answers. It would also enable you to filter and ask questions only about a specific version of a library like "what was deprecated in numpy 1.26.2"
The vector database is updated regularly. Right now every month for each library if we detect a change. In the future we want to make updates more or less frequent on a library-specific basis.
We would love to add more libraries. Join our discord  & send your suggestions!
We are very interested in adding self-hosted vector dbs. Feel free to make a PR! Right now we have a hosted pinecone instance with all the vectors - but you can download any of the vectors on our website or via the CLI!


Improve testing inside Val

With the introduction of end-to-end tests, we should be able to use Val programs to create tests.
We need to make sure we can report non-zero exit codes, and we can implement asserts in Val.

Fixed with #509