catkin_make error

First of all, thanks for your works and share it with all of us 🙂
i'm actually trying to catkin_make the Livox mapping but i have 2 make errors as shown in the pictures. can you help me to identify the problem and solve it?
glic@GLIC:~/catkin_ws$ catkin_make
Base path: /home/glic/catkin_ws
Source space: /home/glic/catkin_ws/src
Build space: /home/glic/catkin_ws/build
Devel space: /home/glic/catkin_ws/devel
Install space: /home/glic/catkin_ws/install

Running command: "cmake /home/glic/catkin_ws/src -DCATKIN_DEVEL_PREFIX=/home/glic/catkin_ws/devel -DCMAKE_INSTALL_PREFIX=/home/glic/catkin_ws/install -G Unix Makefiles" in "/home/glic/catkin_ws/build"

-- Using CATKIN_DEVEL_PREFIX: /home/glic/catkin_ws/devel
-- Using CMAKE_PREFIX_PATH: /opt/ros/melodic
-- This workspace overlays: /opt/ros/melodic
-- Found PythonInterp: /usr/bin/python2 (found suitable version "2.7.17", minimum required is "2")
-- Using PYTHON_EXECUTABLE: /usr/bin/python2
-- Using Debian Python package layout
-- Using empy: /usr/bin/empy
-- Using CATKIN_ENABLE_TESTING: ON
-- Call enable_testing()
-- Using CATKIN_TEST_RESULTS_DIR: /home/glic/catkin_ws/build/test_results
-- Found gtest sources under '/usr/src/googletest': gtests will be built
-- Found gmock sources under '/usr/src/googletest': gmock will be built
-- Found PythonInterp: /usr/bin/python2 (found version "2.7.17")
-- Using Python nosetests: /usr/bin/nosetests-2.7
-- catkin 0.7.29
-- BUILD_SHARED_LIBS is on
-- BUILD_SHARED_LIBS is on
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- ~~  traversing 8 packages in topological order:
-- ~~  - ad_localization_msgs
-- ~~  - dnb_msgs
-- ~~  - camera_control_msgs
-- ~~  - pylon_camera
-- ~~  - livox_ros_driver
-- ~~  - livox_mapping
-- ~~  - livox_odometry
-- ~~  - xsens_mti_driver
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- +++ processing catkin package: 'ad_localization_msgs'
-- ==> add_subdirectory(Livox-Mapping/ad_localization_msgs)
-- Using these message generators: gencpp;geneus;genlisp;gennodejs;genpy
-- ad_localization_msgs: 1 messages, 0 services
-- +++ processing catkin package: 'dnb_msgs'
-- ==> add_subdirectory(dragandbot_common/dnb_msgs)
-- Using these message generators: gencpp;geneus;genlisp;gennodejs;genpy
-- dnb_msgs: 4 messages, 4 services
-- +++ processing catkin package: 'camera_control_msgs'
-- ==> add_subdirectory(pylon-ros-camera/camera_control_msgs)
-- Using these message generators: gencpp;geneus;genlisp;gennodejs;genpy
-- Generating .msg files for action camera_control_msgs/GrabAndSaveImage /home/glic/catkin_ws/src/pylon-ros-camera/camera_control_msgs/action/GrabAndSaveImage.action
-- Generating .msg files for action camera_control_msgs/GrabHDRImage /home/glic/catkin_ws/src/pylon-ros-camera/camera_control_msgs/action/GrabHDRImage.action
-- Generating .msg files for action camera_control_msgs/GrabImages /home/glic/catkin_ws/src/pylon-ros-camera/camera_control_msgs/action/GrabImages.action
-- camera_control_msgs: 22 messages, 14 services
-- +++ processing catkin package: 'pylon_camera'
-- ==> add_subdirectory(pylon-ros-camera/pylon_camera)
-- Using these message generators: gencpp;geneus;genlisp;gennodejs;genpy
-- +++ processing catkin package: 'livox_ros_driver'
-- ==> add_subdirectory(livox_ros_driver)
-- livox_ros_driver version: 2.6.0
-- Boost version: 1.65.1
-- Found the following Boost libraries:
--   system
--   thread
--   chrono
--   date_time
--   atomic
-- Using these message generators: gencpp;geneus;genlisp;gennodejs;genpy
-- Boost version: 1.65.1
-- Found the following Boost libraries:
--   system
--   filesystem
--   thread
--   date_time
--   iostreams
--   serialization
--   chrono
--   atomic
--   regex
-- Could NOT find ensenso (missing: ENSENSO_LIBRARY ENSENSO_INCLUDE_DIR)
** WARNING ** io features related to ensenso will be disabled
-- Could NOT find DAVIDSDK (missing: DAVIDSDK_LIBRARY DAVIDSDK_INCLUDE_DIR)
** WARNING ** io features related to davidSDK will be disabled
-- Could NOT find DSSDK (missing: _DSSDK_LIBRARIES)
** WARNING ** io features related to dssdk will be disabled
** WARNING ** io features related to pcap will be disabled
** WARNING ** io features related to png will be disabled
-- The imported target "vtkRenderingPythonTkWidgets" references the file
"/usr/lib/x86_64-linux-gnu/libvtkRenderingPythonTkWidgets.so"
but this file does not exist.  Possible reasons include:

The file was deleted, renamed, or moved to another location.
An install or uninstall procedure did not complete successfully.
The installation package was faulty and contained
"/usr/lib/cmake/vtk-6.3/VTKTargets.cmake"
but not all the files it references.

-- The imported target "vtk" references the file
"/usr/bin/vtk"
but this file does not exist.  Possible reasons include:

The file was deleted, renamed, or moved to another location.
An install or uninstall procedure did not complete successfully.
The installation package was faulty and contained
"/usr/lib/cmake/vtk-6.3/VTKTargets.cmake"
but not all the files it references.

** WARNING ** io features related to libusb-1.0 will be disabled
-- Could NOT find ensenso (missing: ENSENSO_LIBRARY ENSENSO_INCLUDE_DIR)
** WARNING ** visualization features related to ensenso will be disabled
-- Could NOT find DAVIDSDK (missing: DAVIDSDK_LIBRARY DAVIDSDK_INCLUDE_DIR)
** WARNING ** visualization features related to davidSDK will be disabled
-- Could NOT find DSSDK (missing: _DSSDK_LIBRARIES)
** WARNING ** visualization features related to dssdk will be disabled
-- Could NOT find RSSDK (missing: _RSSDK_LIBRARIES)
** WARNING ** visualization features related to rssdk will be disabled
-- looking for PCL_COMMON
-- looking for PCL_OCTREE
-- looking for PCL_IO
-- looking for PCL_KDTREE
-- looking for PCL_SEARCH
-- looking for PCL_SAMPLE_CONSENSUS
-- looking for PCL_FILTERS
-- looking for PCL_2D
-- looking for PCL_GEOMETRY
-- looking for PCL_FEATURES
-- looking for PCL_ML
-- looking for PCL_SEGMENTATION
-- looking for PCL_VISUALIZATION
-- looking for PCL_SURFACE
-- looking for PCL_REGISTRATION
-- looking for PCL_KEYPOINTS
-- looking for PCL_TRACKING
-- looking for PCL_RECOGNITION
-- looking for PCL_STEREO
-- looking for PCL_APPS
-- looking for PCL_IN_HAND_SCANNER
-- looking for PCL_MODELER
-- looking for PCL_POINT_CLOUD_EDITOR
-- looking for PCL_OUTOFCORE
-- looking for PCL_PEOPLE
-- livox_ros_driver: 2 messages, 0 services
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Checking for module 'apr-1'
--   Found apr-1, version 1.6.3
/usr/include/apr-1.0
apr-1
find livox sdk library success
-- +++ processing catkin package: 'livox_mapping'
-- ==> add_subdirectory(Livox-Mapping/SC-PGO)
-- Using these message generators: gencpp;geneus;genlisp;gennodejs;genpy
-- Boost version: 1.65.1
-- Found the following Boost libraries:
--   system
--   filesystem
--   thread
--   date_time
--   iostreams
--   serialization
--   chrono
--   atomic
--   regex
-- Could NOT find ensenso (missing: ENSENSO_LIBRARY ENSENSO_INCLUDE_DIR)
** WARNING ** io features related to ensenso will be disabled
-- Could NOT find DAVIDSDK (missing: DAVIDSDK_LIBRARY DAVIDSDK_INCLUDE_DIR)
** WARNING ** io features related to davidSDK will be disabled
-- Could NOT find DSSDK (missing: _DSSDK_LIBRARIES)
** WARNING ** io features related to dssdk will be disabled
** WARNING ** io features related to pcap will be disabled
** WARNING ** io features related to png will be disabled
-- The imported target "vtkRenderingPythonTkWidgets" references the file
"/usr/lib/x86_64-linux-gnu/libvtkRenderingPythonTkWidgets.so"
but this file does not exist.  Possible reasons include:

The file was deleted, renamed, or moved to another location.
An install or uninstall procedure did not complete successfully.
The installation package was faulty and contained
"/usr/lib/cmake/vtk-6.3/VTKTargets.cmake"
but not all the files it references.

-- The imported target "vtk" references the file
"/usr/bin/vtk"
but this file does not exist.  Possible reasons include:

The file was deleted, renamed, or moved to another location.
An install or uninstall procedure did not complete successfully.
The installation package was faulty and contained
"/usr/lib/cmake/vtk-6.3/VTKTargets.cmake"
but not all the files it references.

** WARNING ** io features related to libusb-1.0 will be disabled
-- Could NOT find ensenso (missing: ENSENSO_LIBRARY ENSENSO_INCLUDE_DIR)
** WARNING ** visualization features related to ensenso will be disabled
-- Could NOT find DAVIDSDK (missing: DAVIDSDK_LIBRARY DAVIDSDK_INCLUDE_DIR)
** WARNING ** visualization features related to davidSDK will be disabled
-- Could NOT find DSSDK (missing: _DSSDK_LIBRARIES)
** WARNING ** visualization features related to dssdk will be disabled
-- Could NOT find RSSDK (missing: _RSSDK_LIBRARIES)
** WARNING ** visualization features related to rssdk will be disabled
-- looking for PCL_COMMON
-- looking for PCL_OCTREE
-- looking for PCL_IO
-- looking for PCL_KDTREE
-- looking for PCL_SEARCH
-- looking for PCL_SAMPLE_CONSENSUS
-- looking for PCL_FILTERS
-- looking for PCL_2D
-- looking for PCL_GEOMETRY
-- looking for PCL_FEATURES
-- looking for PCL_ML
-- looking for PCL_SEGMENTATION
-- looking for PCL_VISUALIZATION
-- looking for PCL_SURFACE
-- looking for PCL_REGISTRATION
-- looking for PCL_KEYPOINTS
-- looking for PCL_TRACKING
-- looking for PCL_RECOGNITION
-- looking for PCL_STEREO
-- looking for PCL_APPS
-- looking for PCL_IN_HAND_SCANNER
-- looking for PCL_MODELER
-- looking for PCL_POINT_CLOUD_EDITOR
-- looking for PCL_OUTOFCORE
-- looking for PCL_PEOPLE
-- Found required Ceres dependency: Eigen version 3.3.4 in /usr/lib/cmake/eigen3
-- Found required Ceres dependency: glog
-- Found required Ceres dependency: gflags
-- Found Ceres version: 2.1.0 installed in: /usr/local with components: [EigenSparse, SparseLinearAlgebraLibrary, LAPACK, SuiteSparse, CXSparse, SchurSpecializations, Multithreading]
-- Found OpenMP_C: -fopenmp
-- Found OpenMP_CXX: -fopenmp
-- Found OpenMP: TRUE
-- GTSAM include directory:  /usr/local/lib/cmake/GTSAM/../../../include
-- +++ processing catkin package: 'livox_odometry'
-- ==> add_subdirectory(Livox-Mapping/LIO-Livox)
-- Using these message generators: gencpp;geneus;genlisp;gennodejs;genpy
-- Found Eigen3: /usr/include/eigen3 (Required is at least version "2.91.0")
-- Boost version: 1.65.1
-- Found the following Boost libraries:
--   system
--   filesystem
--   thread
--   date_time
--   iostreams
--   serialization
--   chrono
--   atomic
--   regex
-- Could NOT find ensenso (missing: ENSENSO_LIBRARY ENSENSO_INCLUDE_DIR)
** WARNING ** io features related to ensenso will be disabled
-- Could NOT find DAVIDSDK (missing: DAVIDSDK_LIBRARY DAVIDSDK_INCLUDE_DIR)
** WARNING ** io features related to davidSDK will be disabled
-- Could NOT find DSSDK (missing: _DSSDK_LIBRARIES)
** WARNING ** io features related to dssdk will be disabled
** WARNING ** io features related to pcap will be disabled
** WARNING ** io features related to png will be disabled
-- The imported target "vtkRenderingPythonTkWidgets" references the file
"/usr/lib/x86_64-linux-gnu/libvtkRenderingPythonTkWidgets.so"
but this file does not exist.  Possible reasons include:

The file was deleted, renamed, or moved to another location.
An install or uninstall procedure did not complete successfully.
The installation package was faulty and contained
"/usr/lib/cmake/vtk-6.3/VTKTargets.cmake"
but not all the files it references.

-- The imported target "vtk" references the file
"/usr/bin/vtk"
but this file does not exist.  Possible reasons include:

The file was deleted, renamed, or moved to another location.
An install or uninstall procedure did not complete successfully.
The installation package was faulty and contained
"/usr/lib/cmake/vtk-6.3/VTKTargets.cmake"
but not all the files it references.

** WARNING ** io features related to libusb-1.0 will be disabled
-- Could NOT find ensenso (missing: ENSENSO_LIBRARY ENSENSO_INCLUDE_DIR)
** WARNING ** visualization features related to ensenso will be disabled
-- Could NOT find DAVIDSDK (missing: DAVIDSDK_LIBRARY DAVIDSDK_INCLUDE_DIR)
** WARNING ** visualization features related to davidSDK will be disabled
-- Could NOT find DSSDK (missing: _DSSDK_LIBRARIES)
** WARNING ** visualization features related to dssdk will be disabled
-- Could NOT find RSSDK (missing: _RSSDK_LIBRARIES)
** WARNING ** visualization features related to rssdk will be disabled
-- looking for PCL_COMMON
-- looking for PCL_OCTREE
-- looking for PCL_IO
-- looking for PCL_KDTREE
-- looking for PCL_SEARCH
-- looking for PCL_SAMPLE_CONSENSUS
-- looking for PCL_FILTERS
-- looking for PCL_2D
-- looking for PCL_GEOMETRY
-- looking for PCL_FEATURES
-- looking for PCL_ML
-- looking for PCL_SEGMENTATION
-- looking for PCL_VISUALIZATION
-- looking for PCL_SURFACE
-- looking for PCL_REGISTRATION
-- looking for PCL_KEYPOINTS
-- looking for PCL_TRACKING
-- looking for PCL_RECOGNITION
-- looking for PCL_STEREO
-- looking for PCL_APPS
-- looking for PCL_IN_HAND_SCANNER
-- looking for PCL_MODELER
-- looking for PCL_POINT_CLOUD_EDITOR
-- looking for PCL_OUTOFCORE
-- looking for PCL_PEOPLE
-- Found required Ceres dependency: Eigen version 3.3.4 in /usr/lib/cmake/eigen3
-- Found required Ceres dependency: glog
-- Found required Ceres dependency: gflags
-- Found Ceres version: 2.1.0 installed in: /usr/local with components: [EigenSparse, SparseLinearAlgebraLibrary, LAPACK, SuiteSparse, CXSparse, SchurSpecializations, Multithreading]
-- A library with BLAS API found.
-- Found AMD headers in: /usr/include/suitesparse
-- Found AMD library: /usr/lib/x86_64-linux-gnu/libamd.so
-- Found CAMD headers in: /usr/include/suitesparse
-- Found CAMD library: /usr/lib/x86_64-linux-gnu/libcamd.so
-- Found COLAMD headers in: /usr/include/suitesparse
-- Found COLAMD library: /usr/lib/x86_64-linux-gnu/libcolamd.so
-- Found CCOLAMD headers in: /usr/include/suitesparse
-- Found CCOLAMD library: /usr/lib/x86_64-linux-gnu/libccolamd.so
-- Found CHOLMOD headers in: /usr/include/suitesparse
-- Found CHOLMOD library: /usr/lib/x86_64-linux-gnu/libcholmod.so
-- Found SUITESPARSEQR headers in: /usr/include/suitesparse
-- Found SUITESPARSEQR library: /usr/lib/x86_64-linux-gnu/libspqr.so
-- Did not find Intel TBB library, assuming SuiteSparseQR was not compiled with TBB.
-- Found SUITESPARSE_CONFIG headers in: /usr/include/suitesparse
-- Found SUITESPARSE_CONFIG library: /usr/lib/x86_64-linux-gnu/libsuitesparseconfig.so
-- Found LIBRT library: /usr/lib/x86_64-linux-gnu/librt.so
-- Adding librt: /usr/lib/x86_64-linux-gnu/librt.so to SuiteSparse_config libraries (required on Linux & Unix [not OSX] if SuiteSparse is compiled with timing).
-- Did not find METIS library (optional SuiteSparse dependency)
-- Found SuiteSparse: TRUE (found version "5.1.2")
CMake Warning at /home/glic/catkin_ws/build/Livox-Mapping/LIO-Livox/cmake/livox_odometry-genmsg.cmake:3 (message):
Invoking generate_messages() without having added any message or service
file before.
You should either add add_message_files() and/or add_service_files() calls
or remove the invocation of generate_messages().
Call Stack (most recent call first):
/opt/ros/melodic/share/genmsg/cmake/genmsg-extras.cmake:307 (include)
Livox-Mapping/LIO-Livox/CMakeLists.txt:46 (generate_messages)
-- livox_odometry: 0 messages, 0 services
-- +++ processing catkin package: 'xsens_mti_driver'
-- ==> add_subdirectory(xsens_ros_mti_driver)
-- Using these message generators: gencpp;geneus;genlisp;gennodejs;genpy
-- Configuring done
CMake Warning (dev) at Livox-Mapping/SC-PGO/CMakeLists.txt:46 (add_executable):
Policy CMP0028 is not set: Double colon in target name means ALIAS or
IMPORTED target.  Run "cmake --help-policy CMP0028" for policy details.
Use the cmake_policy command to set the policy and suppress this warning.
Target "livox_mapping" links to target "Boost::timer" but the target was
not found.  Perhaps a find_package() call is missing for an IMPORTED
target, or an ALIAS target is missing?
This warning is for project developers.  Use -Wno-dev to suppress it.
-- Generating done
-- Build files have been written to: /home/glic/catkin_ws/build

Running command: "make -j12 -l12" in "/home/glic/catkin_ws/build"

Scanning dependencies of target std_msgs_generate_messages_nodejs
Scanning dependencies of target _ad_localization_msgs_generate_messages_check_deps_NavStateInfo
Scanning dependencies of target std_msgs_generate_messages_cpp
Scanning dependencies of target geometry_msgs_generate_messages_cpp
Scanning dependencies of target geometry_msgs_generate_messages_py
Scanning dependencies of target std_msgs_generate_messages_py
Scanning dependencies of target geometry_msgs_generate_messages_nodejs
Scanning dependencies of target std_msgs_generate_messages_lisp
Scanning dependencies of target geometry_msgs_generate_messages_lisp
Scanning dependencies of target std_msgs_generate_messages_eus
Scanning dependencies of target geometry_msgs_generate_messages_eus
[  0%] Built target geometry_msgs_generate_messages_cpp
[  0%] Built target std_msgs_generate_messages_cpp
[  0%] Built target geometry_msgs_generate_messages_py
[  0%] Built target std_msgs_generate_messages_lisp
[  0%] Built target std_msgs_generate_messages_py
[  0%] Built target geometry_msgs_generate_messages_eus
[  0%] Built target geometry_msgs_generate_messages_lisp
[  0%] Built target geometry_msgs_generate_messages_nodejs
[  0%] Built target std_msgs_generate_messages_eus
[  0%] Built target std_msgs_generate_messages_nodejs
[  0%] Built target _dnb_msgs_generate_messages_check_deps_RunProgramWithArguments
[  0%] Built target _ad_localization_msgs_generate_messages_check_deps_NavStateInfo
[  0%] Built target _dnb_msgs_generate_messages_check_deps_SetInt32
[  0%] Built target _dnb_msgs_generate_messages_check_deps_ComponentStatus
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_SetGamma
[  0%] Built target _dnb_msgs_generate_messages_check_deps_Program
[  0%] Built target _dnb_msgs_generate_messages_check_deps_Argument
[  0%] Built target _dnb_msgs_generate_messages_check_deps_SetString
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabAndSaveImageActionResult
[  0%] Built target _dnb_msgs_generate_messages_check_deps_StringMultiArray
[  0%] Built target _dnb_msgs_generate_messages_check_deps_GetProgramsList
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabHDRImageActionGoal
[  0%] Built target sensor_msgs_generate_messages_cpp
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabImagesActionResult
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabAndSaveImageResult
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_SetFloatValue
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabAndSaveImageActionGoal
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_SetIntegerValue
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_SetGain
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GetIntegerValue
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_currentParams
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabHDRImageActionFeedback
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabImagesGoal
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_SetBinning
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabImagesActionGoal
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GetCamProperties
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabHDRImageActionResult
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_SetExposure
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GetFloatValue
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabAndSaveImageActionFeedback
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_SetSleeping
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabImagesActionFeedback
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_SetROI
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_SetStringValue
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabHDRImageResult
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabAndSaveImageFeedback
[  0%] Built target actionlib_msgs_generate_messages_cpp
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_SetWhiteBalance
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabAndSaveImageGoal
[  0%] Built target actionlib_msgs_generate_messages_nodejs
[  0%] Built target sensor_msgs_generate_messages_nodejs
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabHDRImageGoal
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabImagesFeedback
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabHDRImageAction
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabImagesResult
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabHDRImageFeedback
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_SetBrightness
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabAndSaveImageAction
[  0%] Built target actionlib_msgs_generate_messages_lisp
[  0%] Built target _camera_control_msgs_generate_messages_check_deps_GrabImagesAction
[  0%] Built target sensor_msgs_generate_messages_lisp
[  0%] Built target actionlib_msgs_generate_messages_eus
Scanning dependencies of target rosgraph_msgs_generate_messages_py
Scanning dependencies of target rosgraph_msgs_generate_messages_nodejs
[  0%] Built target actionlib_msgs_generate_messages_py
[  0%] Built target sensor_msgs_generate_messages_eus
Scanning dependencies of target rosgraph_msgs_generate_messages_lisp
Scanning dependencies of target rosgraph_msgs_generate_messages_eus
[  0%] Built target diagnostic_msgs_generate_messages_py
[  0%] Built target sensor_msgs_generate_messages_py
[  0%] Building CXX object pylon-ros-camera/pylon_camera/CMakeFiles/write_device_user_id_to_camera.dir/src/pylon_camera/write_device_user_id_to_camera.cpp.o
Scanning dependencies of target rosgraph_msgs_generate_messages_cpp
Scanning dependencies of target roscpp_generate_messages_lisp
[  0%] Building CXX object pylon-ros-camera/pylon_camera/CMakeFiles/IPConfigAuto.dir/src/pylon_camera/IPConfigAuto.cpp.o
[  0%] Built target rosgraph_msgs_generate_messages_py
Scanning dependencies of target roscpp_generate_messages_py
Scanning dependencies of target roscpp_generate_messages_nodejs
[  0%] Built target rosgraph_msgs_generate_messages_nodejs
[  0%] Built target rosgraph_msgs_generate_messages_lisp
Scanning dependencies of target roscpp_generate_messages_eus
Scanning dependencies of target roscpp_generate_messages_cpp
[  0%] Built target rosgraph_msgs_generate_messages_cpp
[  0%] Built target rosgraph_msgs_generate_messages_eus
[  0%] Built target roscpp_generate_messages_lisp
[  0%] Built target roscpp_generate_messages_py
[  0%] Built target roscpp_generate_messages_nodejs
[  0%] Built target roscpp_generate_messages_eus
[  0%] Built target roscpp_generate_messages_cpp
[  0%] Built target _catkin_empty_exported_target
[  0%] Built target actionlib_generate_messages_py
[  0%] Built target actionlib_generate_messages_nodejs
[  0%] Built target std_srvs_generate_messages_eus
[  0%] Built target actionlib_generate_messages_lisp
[  0%] Built target actionlib_generate_messages_cpp
[  0%] Built target std_srvs_generate_messages_lisp
[  0%] Built target diagnostic_msgs_generate_messages_eus
[  0%] Built target diagnostic_msgs_generate_messages_cpp
[  0%] Built target actionlib_generate_messages_eus
[  0%] Built target diagnostic_msgs_generate_messages_lisp
Scanning dependencies of target _livox_ros_driver_generate_messages_check_deps_CustomPoint
Scanning dependencies of target _livox_ros_driver_generate_messages_check_deps_CustomMsg
Scanning dependencies of target livox_mapping
Scanning dependencies of target livox_odometry_generate_messages_py
Scanning dependencies of target livox_odometry_generate_messages_lisp
[  0%] Built target std_srvs_generate_messages_nodejs
[  0%] Built target diagnostic_msgs_generate_messages_nodejs
[  0%] Built target std_srvs_generate_messages_cpp
Scanning dependencies of target livox_odometry_generate_messages_eus
[  0%] Built target std_srvs_generate_messages_py
[  0%] Built target livox_odometry_generate_messages_lisp
[  0%] Built target livox_odometry_generate_messages_py
Scanning dependencies of target livox_odometry_generate_messages_cpp
Scanning dependencies of target livox_odometry_generate_messages_nodejs
[  0%] Generating EusLisp manifest code for livox_odometry
Scanning dependencies of target PoseEstimation
Scanning dependencies of target ScanRegistration
Scanning dependencies of target ad_localization_msgs_generate_messages_nodejs
[  0%] Built target livox_odometry_generate_messages_nodejs
[  0%] Built target _livox_ros_driver_generate_messages_check_deps_CustomPoint
[  0%] Built target livox_odometry_generate_messages_cpp
[  0%] Built target _livox_ros_driver_generate_messages_check_deps_CustomMsg
[  0%] Generating Javascript code from ad_localization_msgs/NavStateInfo.msg
[  1%] Building CXX object xsens_ros_mti_driver/CMakeFiles/xsens_mti_node.dir/src/main.cpp.o
Scanning dependencies of target ad_localization_msgs_generate_messages_cpp
Scanning dependencies of target ad_localization_msgs_generate_messages_lisp
Scanning dependencies of target ad_localization_msgs_generate_messages_py
[  1%] Building CXX object xsens_ros_mti_driver/CMakeFiles/xsens_mti_node.dir/src/xdainterface.cpp.o
[  1%] Generating C++ code from ad_localization_msgs/NavStateInfo.msg
[  1%] Generating Lisp code from ad_localization_msgs/NavStateInfo.msg
[  2%] Generating Python from MSG ad_localization_msgs/NavStateInfo
[  2%] Built target ad_localization_msgs_generate_messages_nodejs
[  2%] Building CXX object xsens_ros_mti_driver/CMakeFiles/xsens_mti_node.dir/src/xdacallback.cpp.o
[  2%] Built target ad_localization_msgs_generate_messages_lisp
Scanning dependencies of target ad_localization_msgs_generate_messages_eus
[  2%] Building CXX object Livox-Mapping/SC-PGO/CMakeFiles/livox_mapping.dir/src/laserPosegraphOptimization.cpp.o
[  2%] Generating EusLisp code from ad_localization_msgs/NavStateInfo.msg
[  2%] Building CXX object Livox-Mapping/LIO-Livox/CMakeFiles/ScanRegistration.dir/src/lio/ScanRegistration.cpp.o
[  2%] Building CXX object Livox-Mapping/LIO-Livox/CMakeFiles/PoseEstimation.dir/src/lio/PoseEstimation.cpp.o
[  3%] Generating EusLisp manifest code for ad_localization_msgs
[  3%] Built target ad_localization_msgs_generate_messages_cpp
[  3%] Generating Python msg init.py for ad_localization_msgs
[  4%] Building CXX object Livox-Mapping/LIO-Livox/CMakeFiles/ScanRegistration.dir/src/lio/LidarFeatureExtractor.cpp.o
[  4%] Built target ad_localization_msgs_generate_messages_py
[  7%] Built target dnb_msgs_generate_messages_nodejs
[  7%] Linking CXX executable /home/glic/catkin_ws/devel/lib/pylon_camera/write_device_user_id_to_camera
[  9%] Built target dnb_msgs_generate_messages_lisp
[  9%] Building CXX object Livox-Mapping/LIO-Livox/CMakeFiles/ScanRegistration.dir/src/segment/segment.cpp.o
[  9%] Built target write_device_user_id_to_camera
[  9%] Building CXX object Livox-Mapping/LIO-Livox/CMakeFiles/ScanRegistration.dir/src/segment/pointsCorrect.cpp.o
[  9%] Built target livox_odometry_generate_messages_eus
In file included from /home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/src/lio/ScanRegistration.cpp:1:0:
/home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/include/LidarFeatureExtractor/LidarFeatureExtractor.h:4:10: fatal error: livox_ros_driver/CustomMsg.h: Aucun fichier ou dossier de ce type
#include <livox_ros_driver/CustomMsg.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
[ 10%] Building CXX object Livox-Mapping/LIO-Livox/CMakeFiles/PoseEstimation.dir/src/lio/Estimator.cpp.o
Livox-Mapping/LIO-Livox/CMakeFiles/ScanRegistration.dir/build.make:62: recipe for target 'Livox-Mapping/LIO-Livox/CMakeFiles/ScanRegistration.dir/src/lio/ScanRegistration.cpp.o' failed
make[2]: *** [Livox-Mapping/LIO-Livox/CMakeFiles/ScanRegistration.dir/src/lio/ScanRegistration.cpp.o] Error 1
make[2]: *** Attente des tâches non terminées....
[ 11%] Building CXX object Livox-Mapping/SC-PGO/CMakeFiles/livox_mapping.dir/include/scancontext/Scancontext.cpp.o
In file included from /home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/src/lio/LidarFeatureExtractor.cpp:1:0:
/home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/include/LidarFeatureExtractor/LidarFeatureExtractor.h:4:10: fatal error: livox_ros_driver/CustomMsg.h: Aucun fichier ou dossier de ce type
#include <livox_ros_driver/CustomMsg.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
Livox-Mapping/LIO-Livox/CMakeFiles/ScanRegistration.dir/build.make:86: recipe for target 'Livox-Mapping/LIO-Livox/CMakeFiles/ScanRegistration.dir/src/lio/LidarFeatureExtractor.cpp.o' failed
make[2]: *** [Livox-Mapping/LIO-Livox/CMakeFiles/ScanRegistration.dir/src/lio/LidarFeatureExtractor.cpp.o] Error 1
[ 14%] Built target dnb_msgs_generate_messages_cpp
[ 14%] Building CXX object Livox-Mapping/LIO-Livox/CMakeFiles/PoseEstimation.dir/src/lio/IMUIntegrator.cpp.o
[ 14%] Built target ad_localization_msgs_generate_messages_eus
[ 17%] Built target dnb_msgs_generate_messages_eus
[ 20%] Built target dnb_msgs_generate_messages_py
[ 33%] Built target camera_control_msgs_generate_messages_cpp
[ 45%] Built target camera_control_msgs_generate_messages_nodejs
[ 58%] Built target camera_control_msgs_generate_messages_lisp
[ 70%] Built target camera_control_msgs_generate_messages_eus
[ 84%] Built target camera_control_msgs_generate_messages_py
Scanning dependencies of target livox_ros_driver_generate_messages_cpp
[ 85%] Generating C++ code from livox_ros_driver/CustomPoint.msg
[ 85%] Generating C++ code from livox_ros_driver/CustomMsg.msg
[ 85%] Built target livox_ros_driver_generate_messages_cpp
Scanning dependencies of target livox_ros_driver_generate_messages_eus
[ 85%] Generating EusLisp code from livox_ros_driver/CustomPoint.msg
[ 86%] Generating EusLisp code from livox_ros_driver/CustomMsg.msg
[ 86%] Generating EusLisp manifest code for livox_ros_driver
Scanning dependencies of target livox_ros_driver_generate_messages_nodejs
[ 86%] Generating Javascript code from livox_ros_driver/CustomPoint.msg
[ 86%] Generating Javascript code from livox_ros_driver/CustomMsg.msg
[ 86%] Built target livox_ros_driver_generate_messages_nodejs
[ 86%] Building CXX object Livox-Mapping/LIO-Livox/CMakeFiles/PoseEstimation.dir/src/lio/ceresfunc.cpp.o
[ 87%] Building CXX object Livox-Mapping/LIO-Livox/CMakeFiles/PoseEstimation.dir/src/lio/Map_Manager.cpp.o
[ 87%] Built target livox_ros_driver_generate_messages_eus
Scanning dependencies of target livox_ros_driver_generate_messages_lisp
[ 87%] Generating Lisp code from livox_ros_driver/CustomPoint.msg
[ 88%] Generating Lisp code from livox_ros_driver/CustomMsg.msg
[ 88%] Built target livox_ros_driver_generate_messages_lisp
Scanning dependencies of target livox_ros_driver_generate_messages_py
[ 89%] Generating Python from MSG livox_ros_driver/CustomPoint
[ 89%] Generating Python from MSG livox_ros_driver/CustomMsg
[ 89%] Generating Python msg init.py for livox_ros_driver
[ 89%] Built target livox_ros_driver_generate_messages_py
Scanning dependencies of target livox_odometry_generate_messages
[ 89%] Built target livox_odometry_generate_messages
Scanning dependencies of target ad_localization_msgs_generate_messages
[ 89%] Built target ad_localization_msgs_generate_messages
[ 89%] Built target dnb_msgs_generate_messages
[ 89%] Built target camera_control_msgs_generate_messages
[ 89%] Building CXX object pylon-ros-camera/pylon_camera/CMakeFiles/pylon_camera.dir/src/pylon_camera/binary_exposure_search.cpp.o
[ 90%] Linking CXX executable /home/glic/catkin_ws/devel/lib/xsens_mti_driver/xsens_mti_node
[ 90%] Built target xsens_mti_node
Scanning dependencies of target livox_ros_driver_node
[ 91%] Building CXX object livox_ros_driver/CMakeFiles/livox_ros_driver_node.dir/livox_ros_driver/lvx_file.cpp.o
[ 92%] Building CXX object pylon-ros-camera/pylon_camera/CMakeFiles/pylon_camera.dir/src/pylon_camera/encoding_conversions.cpp.o
[ 92%] Building CXX object livox_ros_driver/CMakeFiles/livox_ros_driver_node.dir/livox_ros_driver/ldq.cpp.o
[ 92%] Building CXX object livox_ros_driver/CMakeFiles/livox_ros_driver_node.dir/livox_ros_driver/lds.cpp.o
[ 92%] Building CXX object pylon-ros-camera/pylon_camera/CMakeFiles/pylon_camera.dir/src/pylon_camera/pylon_camera.cpp.o
[ 93%] Building CXX object livox_ros_driver/CMakeFiles/livox_ros_driver_node.dir/livox_ros_driver/lds_lvx.cpp.o
[ 93%] Building CXX object livox_ros_driver/CMakeFiles/livox_ros_driver_node.dir/livox_ros_driver/lds_lidar.cpp.o
[ 93%] Building CXX object livox_ros_driver/CMakeFiles/livox_ros_driver_node.dir/livox_ros_driver/lds_hub.cpp.o
/home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/src/lio/PoseEstimation.cpp: In function ‘bool TryMAPInitialization()’:
/home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/src/lio/PoseEstimation.cpp:250:33: warning: ‘LocalParameterization’ is deprecated: LocalParameterizations will be removed from the Ceres Solver API in version 2.2.0. Use Manifolds instead. [-Wdeprecated-declarations]
ceres::LocalParameterization quatParam = new ceres::QuaternionParameterization();
^~~~~~~~~
In file included from /usr/local/include/ceres/autodiff_local_parameterization.h:39:0,
from /usr/local/include/ceres/ceres.h:39,
from /home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/include/utils/ceresfunc.h:3,
from /home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/include/Estimator/Estimator.h:20,
from /home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/src/lio/PoseEstimation.cpp:1:
/usr/local/include/ceres/local_parameterization.h:121:18: note: declared here
CERES_EXPORT LocalParameterization {
^~~~~~~~~~~~~~~~~~~~~
/home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/src/lio/PoseEstimation.cpp:250:56: warning: ‘QuaternionParameterization’ is deprecated: Use QuaternionManifold instead. [-Wdeprecated-declarations]
ceres::LocalParameterization quatParam = new ceres::QuaternionParameterization();
^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/local/include/ceres/autodiff_local_parameterization.h:39:0,
from /usr/local/include/ceres/ceres.h:39,
from /home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/include/utils/ceresfunc.h:3,
from /home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/include/Estimator/Estimator.h:20,
from /home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/src/lio/PoseEstimation.cpp:1:
/usr/local/include/ceres/local_parameterization.h:211:18: note: declared here
CERES_EXPORT QuaternionParameterization : public LocalParameterization {
^~~~~~~~~~~~~~~~~~~~~~~~~~
/home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/src/lio/PoseEstimation.cpp:253:57: warning: ‘void ceres::Problem::AddParameterBlock(double, int, ceres::LocalParameterization)’ is deprecated: LocalParameterizations are deprecated. Use the version with Manifolds instead. [-Wdeprecated-declarations]
problem_quat.AddParameterBlock(para_quat, 4, quatParam);
^
In file included from /usr/local/include/ceres/ceres.h:65:0,
from /home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/include/utils/ceresfunc.h:3,
from /home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/include/Estimator/Estimator.h:20,
from /home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/src/lio/PoseEstimation.cpp:1:
/usr/local/include/ceres/problem.h:302:8: note: declared here
void AddParameterBlock(double* values,
^~~~~~~~~~~~~~~~~
[ 94%] Building CXX object livox_ros_driver/CMakeFiles/livox_ros_driver_node.dir/livox_ros_driver/lddc.cpp.o
[ 94%] Building CXX object livox_ros_driver/CMakeFiles/livox_ros_driver_node.dir/livox_ros_driver/livox_ros_driver.cpp.o
[ 94%] Building CXX object livox_ros_driver/CMakeFiles/livox_ros_driver_node.dir/timesync/timesync.cpp.o
[ 95%] Building CXX object livox_ros_driver/CMakeFiles/livox_ros_driver_node.dir/timesync/user_uart/user_uart.cpp.o
[ 95%] Building CXX object livox_ros_driver/CMakeFiles/livox_ros_driver_node.dir/common/comm/comm_protocol.cpp.o
[ 95%] Building CXX object livox_ros_driver/CMakeFiles/livox_ros_driver_node.dir/common/comm/sdk_protocol.cpp.o
[ 96%] Building CXX object livox_ros_driver/CMakeFiles/livox_ros_driver_node.dir/common/comm/gps_protocol.cpp.o
/home/glic/catkin_ws/src/Livox-Mapping/SC-PGO/include/scancontext/Scancontext.cpp: In function ‘float xy2theta(const float&, const float&)’:
/home/glic/catkin_ws/src/Livox-Mapping/SC-PGO/include/scancontext/Scancontext.cpp:36:1: warning: control reaches end of non-void function [-Wreturn-type]
} // xy2theta
^
[ 96%] Building CXX object pylon-ros-camera/pylon_camera/CMakeFiles/pylon_camera.dir/src/pylon_camera/pylon_camera_node.cpp.o
[ 97%] Building CXX object pylon-ros-camera/pylon_camera/CMakeFiles/pylon_camera.dir/src/pylon_camera/pylon_camera_parameter.cpp.o
CMakeFiles/Makefile2:7839: recipe for target 'Livox-Mapping/LIO-Livox/CMakeFiles/ScanRegistration.dir/all' failed
make[1]: *** [Livox-Mapping/LIO-Livox/CMakeFiles/ScanRegistration.dir/all] Error 2
make[1]: *** Attente des tâches non terminées....
In file included from /home/glic/catkin_ws/src/livox_ros_driver/livox_ros_driver/lddc.h:32:0,
from /home/glic/catkin_ws/src/livox_ros_driver/livox_ros_driver/lddc.cpp:25:
/opt/ros/melodic/include/pcl_ros/point_cloud.h:303:27: warning: variable templates only available with -std=c++14 or -std=gnu++14
constexpr static bool pcl_uses_boost = true;
^~~~~~~~~~~~~~
In file included from /home/glic/catkin_ws/src/livox_ros_driver/livox_ros_driver/lddc.h:32:0,
from /home/glic/catkin_ws/src/livox_ros_driver/livox_ros_driver/livox_ros_driver.cpp:32:
/opt/ros/melodic/include/pcl_ros/point_cloud.h:303:27: warning: variable templates only available with -std=c++14 or -std=gnu++14
constexpr static bool pcl_uses_boost = true;
^~~~~~~~~~~~~~
[ 97%] Linking CXX executable /home/glic/catkin_ws/devel/lib/livox_ros_driver/livox_ros_driver_node
[ 97%] Built target livox_ros_driver_node
In file included from /usr/include/pcl-1.8/pcl/sample_consensus/sac_model.h:52:0,
from /usr/include/pcl-1.8/pcl/sample_consensus/sac.h:45,
from /usr/include/pcl-1.8/pcl/sample_consensus/ransac.h:44,
from /home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/include/utils/pcl_utils.hpp:4,
from /home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/include/Estimator/Estimator.h:21,
from /home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/src/lio/Estimator.cpp:1:
/usr/include/pcl-1.8/pcl/sample_consensus/model_types.h: In function ‘void __static_initialization_and_destruction_0(int, int)’:
/usr/include/pcl-1.8/pcl/sample_consensus/model_types.h:99:3: warning: ‘pcl::SAC_SAMPLE_SIZE’ is deprecated: This map is deprecated and is kept only to prevent breaking existing user code. Starting from PCL 1.8.0 model sample size is a protected member of the SampleConsensusModel class [-Wdeprecated-declarations]
SAC_SAMPLE_SIZE (sample_size_pairs, sample_size_pairs + sizeof (sample_size_pairs) / sizeof (SampleSizeModel));
^~~~~~~~~~~~~~~
/usr/include/pcl-1.8/pcl/sample_consensus/model_types.h:99:3: note: declared here
In file included from /usr/include/pcl-1.8/pcl/sample_consensus/sac_model.h:52:0,
from /usr/include/pcl-1.8/pcl/sample_consensus/sac.h:45,
from /usr/include/pcl-1.8/pcl/sample_consensus/ransac.h:44,
from /home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/include/utils/pcl_utils.hpp:4,
from /home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/include/Estimator/Estimator.h:21,
from /home/glic/catkin_ws/src/Livox-Mapping/LIO-Livox/src/lio/PoseEstimation.cpp:1:
/usr/include/pcl-1.8/pcl/sample_consensus/model_types.h: In function ‘void __static_initialization_and_destruction_0(int, int)’:
/usr/include/pcl-1.8/pcl/sample_consensus/model_types.h:99:3: warning: ‘pcl::SAC_SAMPLE_SIZE’ is deprecated: This map is deprecated and is kept only to prevent breaking existing user code. Starting from PCL 1.8.0 model sample size is a protected member of the SampleConsensusModel class [-Wdeprecated-declarations]
SAC_SAMPLE_SIZE (sample_size_pairs, sample_size_pairs + sizeof (sample_size_pairs) / sizeof (SampleSizeModel));
^~~~~~~~~~~~~~~
/usr/include/pcl-1.8/pcl/sample_consensus/model_types.h:99:3: note: declared here
[ 97%] Linking CXX shared library /home/glic/catkin_ws/devel/lib/libpylon_camera.so
[ 97%] Built target pylon_camera
In file included from /usr/include/pcl-1.8/pcl/sample_consensus/sac_model.h:52:0,
from /usr/include/pcl-1.8/pcl/sample_consensus/sac.h:45,
from /usr/include/pcl-1.8/pcl/sample_consensus/ransac.h:44,
from /usr/include/pcl-1.8/pcl/registration/icp.h:45,
from /home/glic/catkin_ws/src/Livox-Mapping/SC-PGO/src/laserPosegraphOptimization.cpp:19:
/usr/include/pcl-1.8/pcl/sample_consensus/model_types.h: In function ‘void __static_initialization_and_destruction_0(int, int)’:
/usr/include/pcl-1.8/pcl/sample_consensus/model_types.h:99:3: warning: ‘pcl::SAC_SAMPLE_SIZE’ is deprecated: This map is deprecated and is kept only to prevent breaking existing user code. Starting from PCL 1.8.0 model sample size is a protected member of the SampleConsensusModel class [-Wdeprecated-declarations]
SAC_SAMPLE_SIZE (sample_size_pairs, sample_size_pairs + sizeof (sample_size_pairs) / sizeof (SampleSizeModel));
^~~~~~~~~~~~~~~
/usr/include/pcl-1.8/pcl/sample_consensus/model_types.h:99:3: note: declared here
[ 97%] Linking CXX executable /home/glic/catkin_ws/devel/lib/pylon_camera/IPConfigAuto
[ 97%] Built target IPConfigAuto
[ 97%] Linking CXX executable /home/glic/catkin_ws/devel/lib/livox_mapping/livox_mapping
/usr/bin/ld : ne peut trouver -lBoost::timer
collect2: error: ld returned 1 exit status
Livox-Mapping/SC-PGO/CMakeFiles/livox_mapping.dir/build.make:479: recipe for target '/home/glic/catkin_ws/devel/lib/livox_mapping/livox_mapping' failed
make[2]: *** [/home/glic/catkin_ws/devel/lib/livox_mapping/livox_mapping] Error 1
CMakeFiles/Makefile2:7372: recipe for target 'Livox-Mapping/SC-PGO/CMakeFiles/livox_mapping.dir/all' failed
make[1]: *** [Livox-Mapping/SC-PGO/CMakeFiles/livox_mapping.dir/all] Error 2
[ 97%] Linking CXX executable /home/glic/catkin_ws/devel/lib/livox_odometry/PoseEstimation
[ 97%] Built target PoseEstimation
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2
Invoking "make -j12 -l12" failed

/usr/bin/ld : ne peut trouver -lBoost::timer
collect2: error: ld returned 1 exit status
Livox-Mapping/SC-PGO/CMakeFiles/livox_mapping.dir/build.make:479: recipe for target '/home/glic/catkin_ws/devel/lib/livox_mapping/livox_mapping' failed
make[2]: *** [/home/glic/catkin_ws/devel/lib/livox_mapping/livox_mapping] Error 1
CMakeFiles/Makefile2:7372: recipe for target 'Livox-Mapping/SC-PGO/CMakeFiles/livox_mapping.dir/all' failed
make[1]: *** [Livox-Mapping/SC-PGO/CMakeFiles/livox_mapping.dir/all] Error 2
Makefile:140: recipe for target 'all' failed
make: *** [all] Error 2
Invoking "make -j12 -l12" failed
i think i resolved the error of sourcing livox_ros_driver but still have the error of -lboost::timer
how can i solve it?

You need to install iboost related.
Did you test on our docker?

when i check the version of boost librery with "dpkg -s libboost-dev | grep 'Version'" i have this result "Version: <IP_ADDRESS>ubuntu1"
sorry but i'm a beginner. how can i test on your docker?

First of all, I cannot understand your terminal information with “/usr/bin/ld : ne peut trouver -lBoost::timer”. So no further help could be offer.
For the docker usage, please take a look at: https://github.com/PJLab-ADG/Livox-Mapping#23-docker

if i use docker to run the test with docker , do i need to build the project with catkin_make?
thanks for your time.

Yes, you need
pull the docker -> get into the docker -> pull the project -> build the project
Bests

hi, i still have the same problem. can you provide me more informations or tutorial for docker build project please?
Thanks a lot

Hi,
I would recommend you the official tutorial: https://docs.docker.com/get-started/
Since the docker part is not our main focus, I would suggest you go for help in the docker-related forum, where the people there are more professional than us.
Bests,
Siyuan

Since no more active comments, I will close this issue. You can re-open it when needed.

I have the same problem

I fix it try add next line at src\Livox-Mapping\SC-PGO\CMakeLists.txt
it seems livox_mapping need boost::timer but compiler does not find it
# src\Livox-Mapping\SC-PGO\CMakeLists.txt
find_package(Boost REQUIRED COMPONENTS timer)

Can you try it in our docker?

I installed docker and followed the instructions but seems it doesn’t work 😅
Someone can provide us a tutorial of the installation? Do we need to install Gtsam?

Can you try it in our docker?

I using it on WLS and VM
I am unfamiliar to docker , I may learn docker if I have some leisure time next weekend hhhh

I installed docker and followed the instructions but seems it doesn’t work 😅 Someone can provide us a tutorial of the installation? Do we need to install Gtsam?

Hi @geoarch2021 , if you use the docker, I guess no more installation is needed since we have pre-installed everything we need in the docker environment.
For GTSAM, one possible reference would be: https://github.com/gisbi-kim/FAST_LIO_SLAM/issues/8.
For docker usage, please check the official guidance and tutorial.
Best

Can you try it in our docker?

I using it on WSL and VM I am unfamiliar to docker , I may learn docker if I have some leisure time next weekend hhhh

@BrightSoulXYHY It definitely worth it using docker to try out the slam algorithms.
Best

Since no further questions, I will close this issue.


Feature/save data hook

Save Data Hook added
Save Data Hook based demo project added
demo project README, repository README, and hook/README are updated
build configuration updated and deployed again with Client Hint version
Client Hint based demo project updated in naming

@addyosmani
I think this project is sibling project with the previous Client Hint version.
So please review the project naming as well.
I think we should update the projects naming according to https://github.com/GoogleChromeLabs/adaptive-loading/issues/65

For my knowledge, will this PR be getting updated or are you aiming to PR all the changes based on the values feedback at the same time?

For my knowledge, will this PR be getting updated or are you aiming to PR all the changes based on the values feedback at the same time?

I think we can merge all current PRs based on your comments then we can branch out for hook update like returning values and memory hook.
In this way, we could reduce duplicated works I guess.
So for now, my priority is to handle all your comments so we can land on PRs.

Cool. Thank you. Once the conflicts on this one have been resolved we should be able to merge.

@addyosmani
This is ready now.
All comments and relevant updates are done.

Would you mind resolving the conflicts just one more time?

Would you mind resolving the conflicts just one more time?

Sure thing!

Would you mind resolving the conflicts just one more time?

Absolutely! It's done. Please review it.


Suppress GPG signatures when getting the git last revision year

With git log signatures enabled, in my .gitconfig file:
[log]
	showSignature = true

...the build script would fail...
./devel/addon/certmanager/install.sh
...
Target //devel/addon/certmanager:bundle up-to-date (nothing to build)
INFO: Elapsed time: 4.904s, Critical Path: 4.40s
INFO: 25 processes: 1 internal, 24 linux-sandbox.
INFO: Build completed successfully, 25 total actions
INFO: Build completed successfully, 25 total actions
/tmp/tmp.1romCJipzn: line 9: export: `gpg:=         There is no indication that the signature belongs to the owner.': not a valid identifier

This patch disables the printing of signatures in the command which gets the copyright YEAR of the last revision,
introduced in https://github.com/jetstack/cert-manager/pull/3357
/kind cleanup
NONE

/approve
/lgtm
I would have never suspected that...


Allow adding link hints to images

Currently, it is not really possible to show a link hint on top of an image, since the corresponding link hint is generated within the  tag instead of next to it.
Goal:
Recognize in autogeneration when an image is being operated on, and generate something like this:

            dp

If you currently want to have a link hint shown next to an image, it's doable with a manually added wrapper around both:

manager.autogenerate(manager.GenerationEnum.class_tagged, "BHK")
This will add the link hint within the outer span. Since the default action added by autogenerate is clicking the element, you need to make sure that the manually added wrapper does what you intend to happen when clicked.

Implemented. If you care about details, see ./notesToSelf/overlayMode.md


test: Change the fdouser file location to /etc/fdo

Workaround issue https://bugzilla.redhat.com/show_bug.cgi?id=2026795#c24

/test-rhel-9-3-simplified

/test-rhel-9-3-simplified

/test-rhel-9-2-simplified

/test-rhel-8-9-simplified


Issues with current ACL implementation and solution proposal

This pull request is not really meant to be merged, but to try and explain the issues with the current ACL's and propose an alternative. This was discussed with @kradalby on discord.
I hope that the issue is correctly explained.

I really like this and is basically what I've done with my Headscale instance. Removing sharing and just relying on ACLs to control access seems like a good solution.
One thing to note - I'm pretty sure I read somewhere on the Tailscale docs that peers are only sent to people who have permission to access them via ACLs (I can't find the page now where I read it). Perhaps this is something that Headscale could implement in the future, it doesn't really help security as a connection can't be made if an ACL doesn't allow it, but it just means that tailscale status / Windows tray menu would only show nodes that are allowed for that particular user/device via ACLs.

This adaptation of the ACL would need breaking changes, but I also see no problem with that as the project is still in constant developed and we won't need a backwards compatibility.
Furthermore if we complete rework the ACL maybe we also should add  the ACL configuration to a API. So a more dynamical configuration is possible. As for now we would need to change the configuration file, which will need a restart/reload of the server.
All in all I think that is a great proposal.
I also would love to write the ACL in Yaml. Not important just nice to have.

This adaptation of the ACL would need breaking changes, but I also see no problem with that as the project is still in constant developed and we won't need a backwards compatibility.
Furthermore if we complete rework the ACL maybe we also should add the ACL configuration to a API. So a more dynamical configuration is possible. As for now we would need to change the configuration file, which will need a restart/reload of the server.
All in all I think that is a great proposal.
I also would love to write the ACL in Yaml. Not important just nice to have.

I consider the ACL configuration as an API a very good thing to do. Restart Headscale to reload ACLs is not quite good.
I didn't think of YAML to write configuration but it should be nice and quite easy to implement !

I think this makes sense. I think it has been like this since the usecases of the maintainers has currently been 100% personal usage and we just have not ran into this. But I can see how it is better.
My other comments should probably be read before this, as this is the last section:
However my main concern is the migration path.
I am contemplating two relativeliy different one:
1. Change the logic

By this I mean, implement the new proposed solution, allowing access between all namespaces and fixing the ACL system. As a part of allowing access, remove the shared node code, table, tests etc.
It would be a breaking change, but we are not 1.0.0, so that "should be fine" tm.
2. "rename" namespace to user

This is a "even more" breaking change, while I think it would make sense to clean up the naming to avoid confusion and bring it closer to the upstream lingo.
Basically this would:
* Implement the new suggestion as User (to reflect what it actually is)

* Remove share node feature

* Remove the namespace (cli, table, code, etc).

This would make the user/group keywords in ACLs make more sense aswell.
Before doing either, we should make sure we "get it right", I can't see any concerns right now, but would like to get some more eyes on it.
@juanfont @madjam002 @ohdearaugustin @cure
Edit: I also want to write the ACLs in YAML (as well as HUJSON), but this should be trivial.

Thank you for you extensive review of this ! I agree with all points raised here. All those features are quite too much in my opinion for a single pull request. For migration path, we could either go slow and not change too much default behavior. Either by adding a flag to enable the new version of the ACLs or only enabling behavior if ACLs are enabled or completely break everything since it's a pre 1.0 release.
Your second part of the migration path seems to me to be the natural next step of this rework. Removing the namespace cli seems a lot because not every users would be using OIDC. I think we should rename this cli but keeping it is a must have. For a personal instance OIDC is often too much a burden to setup.

I think that this document should be moved into docs/proposals or something, and maybe have a 001- in front.
Proposal is a bit more versatile than Issues since it is easier to comment on the actual text.

I consider the ACL configuration as an API a very good thing to do. Restart Headscale to reload ACLs is not quite good.

Then I think that we should make a new proposal for this, because it does require some design and concern:

How do we maintain the current setup, allowing "config as code"
were do we store/update changes and how do we treat it comparing to the already defined as code

Removing the namespace cli seems a lot because not every users would be using OIDC. I think we should rename this cli but keeping it is a must have. For a personal instance OIDC is often too much a burden to setup.

I recon it would make sense to rename it in any case, for non-OIDC setups aswell, my argument for this is to make it more aligned with the upstream, allowing us to scrap extra documentation to explain what stuff means.
And you could probably argue that when all machines can talk to all machines, it makes more sense to associate them with a user, rather than namespace. User is also used in the ACL IIRC?
This would probably also make sense to have in the proposal folder.

All those features are quite too much in my opinion for a single pull request. For migration path, we could either go slow and not change too much default behavior.

I agree, lets do it gradually, and do it from 0.14.0, since 0.13.0 is quite a big release already.

Either by adding a flag to enable the new version of the ACLs or only enabling behavior if ACLs are enabled or completely break everything since it's a pre 1.0 release.

I will personally vote for full change rather than "flag guarding" it, as it just means we need to maintain more logic.

Ok, I've moved the content into a proposals folder. Do you want me to try and write some other proposals for new user command and acl command or should we do this in another pull request ?
As for this format, I think we will loose the comments. I could modify this document to try and integrate your comments, but I think we will still loose informations.

Ok, I've moved the content into a proposals folder. Do you want me to try and write some other proposals for new user command and acl command or should we do this in another pull request ?

Let us do that in separate PRs, one (big) problem at the time.


DSA <IP_ADDRESS>_Doubly_Linked_List_Introduction_Video

Description
What is doubly linked list? Explain. Discuss it's implementation in C/Cpp or Java.
Important: Do not use assign command for this issue.
Task

[ ] Video

Note

After completion of your task, add your file in this folder and name it <IP_ADDRESS>_Doubly_Linked_List_Introduction_Video.md
While requesting the issue to be assigned, please mention your NAME & BATCH NUMBER.
Kindly refer to Issue Guidelines.
Changes should be made inside the DSA/directory & DSA branch.
This issue is only for 'GWOC' contributors of 'DSA' Domain.

I would like to work on this issue.
Name: Apoorv Yadav
Batch: 07
Type: Video


lots of windows love

This fixes #1093 100% and probably fixes a good bit of other Windows issues.
❤

@skellock I started off being selective on slashes fixes and tests, but then errors still existed and tests went red, so I kind of flip-flopped over to "Let me kill it with fire" mode.


Fix msg unit tests with new reward schema

Description
Fix msg_test.go unit tests with new reward schema

duplicated


Image does not show on Android

🐛 Bug Report
On Android the Image you can set in the Firebase Console when sending messages or with FirebaseAdmin (.NET) does not show on the right side. (e.g. a user avatar)
On iOS it's working with a Push Notification Service.
Expected behavior
The Image set in the Firebase Console when sending messages or through FirebaseAdmin (ImageUrl Property) is shown on the right side.
Also see here: https://firebase.google.com/docs/cloud-messaging/android/send-image
Reproduction steps
Send a message like this:
{
"to" : "...",
"priority" : "high",
"data": {
},
"notification" : {
"title" : "Test Title",
"body": "Test Body",
"image": "https://www.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png"
}
}
Configuration
XF 4.7 & FirebasePushNotificationPlugin 3.3.10
Version: 1.x
Platform:

[ ] :iphone: iOS
[x] :robot: Android
[ ] :checkered_flag: WPF
[ ] :earth_americas: UWP
[ ] :apple: MacOS
[ ] :tv: tvOS
[ ] :monkey: Xamarin.Forms

Hi,
any updates on this issue?  We are currently facing the same problems...

Has anyone had any success getting the image to show on android?


feat(markdown-docx): add thematic-break transformer - #397

Signed-off-by: K-Kumar-01<EMAIL_ADDRESS>

Changes

Transformer(CiceroMark<->OOXML)
Tests for the same

Screenshots or Video

Author Checklist

[x] Ensure you provide a DCO sign-off for your commits using the --signoff option of git commit.
[x] Vital features and changes captured in unit and/or integration tests
[x] Commits messages follow AP format
[ ] Extend the documentation, if necessary
[ ] Merging to master from fork:branchname

@algomaster99 I haven't changed the w:space property.
Let me know if there are any changes required.

@algomaster99
requesting your review

@algomaster99
I have pushed the changes as discussed in the meeting.
A point to be noted- The border thickness is the minimum. I tried changing w:sz to 1 and 3 but it didn't have any effect on the above.

@K-Kumar-01 Did you try using the between attribute which we discovered during the meeting?

@K-Kumar-01 Did you try using the between attribute which we discovered during the meeting?

@algomaster99 Yes I did try but I did not like it. The between attribute was being given to all paragraphs for which the line between them was needed.

@algomaster99
Can we merge this one?

@algomaster99
Added the test cases.

@K-Kumar-01 the 2nd test case is not rendering well on MS Word. It somehow does not render the first thematic break.

Could you look at it?

@K-Kumar-01 the 2nd test case is not rendering well on MS Word. It somehow does not render the first thematic break.

Could you look at it?

Yeah, I had a look at it and it seems off.
Continuous thematic breaks seem to have top, bottom borders. More than two continuous segments seem to have a between property between them.
However, by doing some changes we can achieve the desired result.

Change made:
Remove the w:spacing  tag and add <w:p/> tag.
I am not sure the exact reason as to why there is a need for such but it is easier than all other methods.
Other methods:
Check how many continuous horizontal rules are there and then use them to generate paragraphs. However, this itself is a complex task.
I am in favour of the first method as it is quite easy to implement. 😬

Remove the w:spacing tag and add <w:p/> tag.

Push this and I will see it once. This PR is quite close to getting merge so I don't think so there will be much work.

Check how many continuous horizontal rules are there and then use them to generate paragraphs. However, this itself is a complex task.

Yeah, this is onerous.


Add python3-nest-asyncio

Please add the following dependency to the rosdep database.
Package name:
python3-nest-asyncio
Package Upstream Source:
https://github.com/erdewit/nest_asyncio
Purpose of using this:
This is a widely used package to allow the nesting of asyncio run_until_complete.
Distro packaging links:
Links to Distribution Packages

Debian: https://packages.debian.org/bullseye/all/python3-nest-asyncio
Ubuntu: https://packages.ubuntu.com/jammy/python3-nest-asyncio
Fedora: https://packages.fedoraproject.org/pkgs/python-nest-asyncio/python3-nest-asyncio/
Arch: https://archlinux.org/packages/extra/any/python-nest-asyncio/
Gentoo: https://packages.gentoo.org/packages/dev-python/nest-asyncio
macOS: Not found
Alpine: https://pkgs.alpinelinux.org/package/v3.19/community/armv7/py3-nest_asyncio
NixOS/nixpkgs: https://search.nixos.org/packages?channel=24.05&show=python312Packages.nest-asyncio&from=0&size=50&sort=relevance&type=packages&query=nest+asyncio
openSUSE: https://software.opensuse.org/package/python-nest-asyncio?locale=en
rhel: https://rhel.pkgs.org/9/epel-aarch64/python3-nest-asyncio-1.5.6-1.el9.noarch.rpm.html

It seems the package is not correct for certain versions of Ubuntu, RHEL and OpenSuse, please take a look at the test.

It doesn't exist for versions of Ubuntu, RHEL and OpenSuse from 2020 and earlier.
I can't find any alternative version for those systems.

Yes, then you can just specify the package only for a certain release of the OS, i.e.:
https://github.com/ros/rosdistro/blob/08be95e0407cf768d4b37a6e36a99b0d741634c8/rosdep/python.yaml#L471
https://github.com/ros/rosdistro/blob/08be95e0407cf768d4b37a6e36a99b0d741634c8/rosdep/python.yaml#L514

Ah thank you, didn't know there was a syntax for all versions except.


Added "display: inline-block;" for a.sbtn

Issue:
#134

Sorry , it was my mistake I forgot to run ( npm run watch)

thank you!
@all-contributors please add @adityasinghbaghel for code and bug


MTAdapter update retrying

Fixes #469

Proposed Changes

MTAdapter Update() return errors if any, so that reconciling requeues source object and retries the update.

/retest

/cc @lionelvillard

Closing this, as not relevant anymore. More pressing issue to resolve is #195


README.md out of date

Readme.md has @FindView Annotations instead of @InjectView annotations and injection is done using bind() method instead of inject() method

v7.0 (currently snapshot) uses @FindView and bind().
So it is newer rather than out of date.
ref #258

Thanks :+1:

Release will be this weekend. Sorry for delay.
On Thu, Jun 25, 2015, 10:45 PM ashrko619<EMAIL_ADDRESS>wrote:

Closed #274 https://github.com/JakeWharton/butterknife/issues/274.
—
Reply to this email directly or view it on GitHub
https://github.com/JakeWharton/butterknife/issues/274#event-340809709.

wow. Glad to hear that!

@JakeWharton 7.0.0 not working yet. Any news?

What does "not working yet" mean? It's working fine here.

Sorry, now It's working... Bad connection

:+1:

Now I'm ashamed :(


DOC-7269 remove minifier from log export docs

Addresses: DOC-7269

Removed yaml minifier from both AWS and GCP log export enablement steps.
Adjusted shown command to reflect proper JSON quoting.
Noticed two codeblocks were missing a ,; added.

Staging
export-logs.md

Thanks @dhartunian , made your requested updates. Appreciate your description of configuring permissions vs target log names as required different degrees of explicitness: absolutely, makes sense -- and thus I've left the last instance of {log_group_name} unchanged! Let me know if you'd like to see any remaining changes. Thanks!

Will raise a new PR to prevent conflicts, address 23.2 docs, and merge to the newer main branch.


Snippet variable text isn't whitespace normalised

have a snippet like this
\n\t$TM_SELECTED_TEXT\n
$0
select indented text on two lines
insert that snippet
:bug: the second line of the selection isn't correctly indented.

This is because we normalise whitespace before parsing and snippet resolving: https://github.com/Microsoft/vscode/blob/master/src/vs/editor/contrib/snippet/browser/snippetSession.ts#L291

fyi @ramya-rao-a You ran into this

Works when selected text is single line or is multi line with 1 level indentation.
In the below case, you have multiple lines with multiple indentations.

@ramya-rao-a Stop filling "bugs" using nothing more than animated gif. Such a waste of time, just copy&paste the code and snippet in question

Code in question:
Exactly what you used when you filed this "bug". Just add another indent in the beginning of the selected text.
Unless you meant the code behind? In which case, I'll take a look at snippetSession.ts and get back.
Snippet in question:
The same that you used.

Exactly what you used when you filed this "bug". Just add another indent in the beginning of the selected text.

So how hard is it to copy&paste? You have just tried it, I trust you when you say it doesn't work with that sample. Why make me interpret a movie that doesn't show tab vs spaces, is very hard to get the exact selection from, takes you more time to create and attach etc etc.

good point. lesson learnt.

Sorry, slipping to August. This is complicated...

I might have gotten smarter over night

thanks! I tested this with a variety of different cases and am loving it.
I was able to remove a lot of indent and newline handling I had put in place for Emmet: Wrap with abbreviation feature to work well with multi cursors.
With this fix, I can remove all of it.
Thanks again!

Adding verified tag since ramya clearly verified it from the comment above

I can repro something like this, but I'm not sure if it's this issue or an emmet specific thing @ramya-rao-a?
Before:

Select the inner 2 divs
Emmet: wrap with abbreviation, p

After:

@roblourens I don't see it..

Today I don't see it either.


Convert all throws into Results

A small quality of life thing but one that should have some ergonomic benefits across our Actions. Basically makes this lib more like Rust. No more try/catch, just Result<T, string> (where the string is error text). There are still try/catch blocks in this library, of course, but nothing here throws errors. I've also streamlined a few other things, like assigning main and post hooks to IdsToolbox.
You can see an example in DeterminateSystems/nix-installer-action#81

Not a lot of projects do it, no, but throws and try/catch blocks are completely and utterly inscrutable and untraceable in JS. Anything can throw an error at any time and there's no guarantee that that error is properly handled or even surfaced in a way that indicates where it came from. This provides us with full control of the error handling "stack" in a way that JS on its own does not afford.

And not a lot of projects do it because this is widely seen as one of those this-is-fine.png aspects of working with JS. Just a kind of brute fact we all have to suffer under. It's up to you but I'd like to see us reject that "fact."

The library is much more well structured now, so I'm less concerned about stray throws.


Consider support for : and other formula operators in ml_* functions

Model Formulae support additional terms like :, ^, etc. Customers have reached out at least to support : but others should be considered.

See also https://github.com/rstudio/sparklyr/issues/554

Closing in favor of https://github.com/rstudio/sparklyr/issues/554


Fix ProjectUploaderSpec

The size of project thumbnail was changed on this commit but the spec wasn't updated :disappointed:.

LGTM


Improve Documentation and Instructions for End-to-End Flows

The set of instructions for the different flows (https://labs.hyperledger.org/weaver-dlt-interoperability/docs/external/getting-started/interop/overview) is a very dry read, even though one can run and test the flows/modes using the given instructions. We need to:

Represent these flows with examples that users can relate to (copying some ledger info, exchanging some asset, etc.)
Create suitable illustrations in the doc pages
Change names of keys, values, and assets to something meaningful (unlike a, Arcturus, etc.): this will involve changing both the configurations within the samples folder and updating the doc pages suitably.

I will try to create the new diagrams and content for the tutorial docs before the Cacti merge. Name changes can wait until the merge.


universalTransition for time series data

What problem does this feature solve?
I have a timeseries data that can switch between monthly, quarterly and yearly aggregate views and plotted either as a line or bar chart. The 5.2.0 feature of universalTransition is great but doesn't seem to be suitable for this type of data. What is happening is that lower granular data has more data points and so toggling from lower granular to higher granular view just removes all the points to the right and expands the starting set of points to occupy the entire chart. What is ideal is that all the monthly data should more into quarterly/yearly data. Similarly, when changing from year to month should similarly transform each year data points into it's corresponding monthly points.
The challenge I see is that the chart doesn't have the knowledge of this rollup. Such a rollup is also possible for other types of hierarchical dimensions such as geography.
What does the proposed API look like?
I am not entirely sure. If this is too specific, then if there is some way to create custom animations then that would be great.

I'm not sure if it's what you want. Universal transition can be applied on the drilldown/rollup case. Here is an example
https://echarts.apache.org/examples/zh/editor.html?c=bar-drilldown
The key is using the same dataGroupId to mapping the data.

Thanks @pissang . My use case is to be able to drill-down multiple levels, say Continent to Country to State. To do this, the data for Country should indicate which Continent it belong to and also the data for Country needs to indicate which Country groupId it belongs to so the transition can use that GroupId at the State level.


ISPN-7586 Rolling Upgrade: use of Remote Store in mode read-only causes data inconsistencies

…es data inconsistencies
https://issues.jboss.org/browse/ISPN-7586
Note for reviewers:
This changes a bit the Hot Rod rolling upgrade procedure. As described in the JIRA, it requires the RemoteStore to be in read-write mode rather than read only.
To enable that, and to prevent that the Rolling Upgrade itself triggers a write back to the source cluster via the remote store, it will use a new flag ROLLING_UPGRADE that will be handled internally in order to avoid such writes.

Updated with a bit more testing

Closing for now, will need to test another scenario...

Updated

@wburns updated.

Fixed test failures

This looks solid to me. @wburns any more notes ?

I've just rebased, moved it to the top of the CI queue

The test failure are not related

Merged, thanks


Revert 2 akashdeep tickoo patch 2

Hi Dear @Akashdeep-Tickoo
Great code
Thanks for your contribution......
Show your support on my youtube channel web Pixar(The institute of coding)
like , share , subscribe
youtube - https://youtu.be/5qnQjgdpFPg
telegram-channel - https://t.me/WebPixar
Join our telegram channel for more goodies , swag packs.
And also join a Hackathon - https://devfolio.co/signup?ref=33d4a02bef


[Backport 1.x] Add library to publish artifacts to PyPi  (#36)

Backport 75b24efe07a15a30772c9cd660477b8d3d304499 from #36

Codecov Report

:exclamation: No coverage uploaded for pull request base (1.x@9db6880). Click here to learn what that means.
The diff coverage is n/a.

:exclamation: Current head 75b24ef differs from pull request most recent head 0dea738. Consider uploading reports for the commit 0dea738 to get more accurate results

@@          Coverage Diff           @@
##             1.x      #37   +/-   ##
======================================
  Coverage       ?   83.95%
  Complexity     ?       24
======================================
  Files          ?       64
  Lines          ?      187
  Branches       ?       10
======================================
  Hits           ?      157
  Misses         ?       24
  Partials       ?        6

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Grade School sorted-grade-school test.

Currently, this test compares a sorted map against an unsorted hash map, where internal ordering isn't consistent. This needs to be changed.
The subsequent tests checks against a vector, which does maintain its internal order.

Good catch.


Refactor detector into a module and add Base64 Decoding

Refactor the detector into a module so that it can be called from other places (ie threat hunting notebooks)
Add a sample for Base64 obfuscation
Handle Base64 obfuscation in a more robust way vs looking only for a full string

Do we really have to renamed the python script name? Because of the - in the name?
This would most likely break some guides / scripts that use it.

The original script has the same name. I took the core detection code and moved it into a python module so that it can be loaded outside of the mainline executable. This will let people use it in jupyter threat hunt books

Understood. But we would have to change the "Getting started" and explain that users have to copy the complete folder to the target system and remove the ./tests/ folder before they do that to avoid moving maliciously looking payloads to their systems.

Or .. provide it as "releases" that are ZIPs without the ./tests folder.

Or release it on pypi.org ... but I guess that most system administrators don't like to install packages from pypi for a one-time task

Agree it is probably a long haul to publish this on Pypi - but you can install it directly from git from a notebook
python -m pip install git+https://github.com/JasonKeirstead/log4shell-detector/

Maybe we can store the tests in a gziped + base64 encoded data blob and save them to disk a the beginning of the test runs.

I'll refactor the tests

https://github.com/Neo23x0/log4shell-detector/pull/30/


Add issue template

Closes  #38  .
Changes :

[x] 🐛 Bug Report Issue template done
[x] 📄 Documentation Issue template done
[x] 💡 Feature Issue template done

Look the Changes :
3 Templates ..

1.  Bug Report Issue template

2. Documentation Issue template

3.  Feature Issue template

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

Amit Maity - GSSoC'22 Contributor.

@vedant-jain03 you can check this pr ..


JSDom 11.12 causes tests to fail

It looks like the latest version of JSDom is incompatible with one of the default settings in Jest.
Here's the Jest issue: https://github.com/facebook/jest/issues/6766
This appears to have been fixed but not yet released: https://github.com/facebook/jest/pull/6792
Even when the fix is released we will still be running an older version of Jest that may not be updated. I think our options for fixing this are:

Update to a newer version of Jest (I think there is at least one PR in the works to do this)
Add testURL: 'http://localhost' to our Jest config

On further investigation it looks like we already have testURL: 'http://localhost in our Jest config here: https://github.com/facebook/create-react-app/blob/next/packages/react-scripts/scripts/utils/createJestConfig.js#L37

The fix has been released with Jest 23.5 and the PR has been updated: #4846


[+] added zapLogger

Codecov Report
Attention: Patch coverage is 84.21053% with 3 lines in your changes missing coverage. Please review.

Please upload report for BASE (main@8c3e93f). Learn more about missing BASE report.

Files
Patch %
Lines

logger/zap.go
83.33%
3 Missing :warning:

Additional details and impacted files
@@           Coverage Diff           @@
##             main       #7   +/-   ##
=======================================
  Coverage        ?   92.51%
=======================================
  Files           ?       10
  Lines           ?      254
  Branches        ?        0
=======================================
  Hits            ?      235
  Misses          ?       18
  Partials        ?        1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Create and use utility class PromiseCompleter

Codecov Report

Merging #3736 (944206a) into beta (a9706a0) will decrease coverage by 0.47%.
The diff coverage is 52.17%.

@@            Coverage Diff             @@
##             beta    #3736      +/-   ##
==========================================
- Coverage   97.11%   96.63%   -0.48%
==========================================
  Files          50       50
  Lines        2391     2409      +18
  Branches      706      708       +2
==========================================
+ Hits         2322     2328       +6
- Misses         67       79      +12
  Partials        2        2

Impacted Files
Coverage Δ

src/core/utils.ts
94.08% <0.00%> (-5.92%)
:arrow_down:

src/core/retryer.ts
98.95% <92.30%> (-1.05%)
:arrow_down:

src/reactjs/useBaseQuery.ts
98.18% <0.00%> (-1.82%)
:arrow_down:

Continue to review full report at Codecov.

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


Fix iOS platform detection

It turns out that ${CMAKE_SYSTEM_NAME} is should now iOS instead of Darwin. I'm not sure of the reason of this change, but this might be related to the latest iOS 12 updates or something specific in our project.
Anyway, at this point, I added a condition check for iOS to fix the Unsupported platform error we get , but I left the initial checks to avoid introducing breaking changes.
If you feel you can come up with a better idea, let me know ;)

I can't reproduce the problem on the system with the following configuration:
macOS Version: 10.15 Catalina
XCode Version 11.1 (11A1027)
Cmake: 3.15.4
CMAKE_SYSTEM_NAME by default is set to the value of CMAKE_HOST_SYSTEM_NAME, which can only have the following values: Linux, Windows and Darwin.
Does your CMake system sets the value of CMAKE_SYSTEM_NAME? I guess that correct fix might be to use CMAKE_HOST_SYSTEM_NAME instead of CMAKE_SYSTEM_NAME.

OK, so it turned out that CMake 3.15 finally added official support for iOS and I believe you generated the solution by specifying -DCMAKE_SYSTEM_NAME=iOS in the command line, not as described here.
With your change the projects seem to be work OK, but third-party projects required to build Vulkan backend complain on unsupported platform. They still can be built using the tool-chain setup method.

OK, so it turned out that CMake 3.15 finally added official support for iOS and I believe you generated the solution by specifying -DCMAKE_SYSTEM_NAME=iOS in the command line, not as described here.
With your change the projects seem to be working OK, but third-party projects required to build Vulkan backend complain about unsupported platform. They still can be built using the tool-chain setup method.

Indeed, we specify -DCMAKE_SYSTEM_NAME=iOS in our project generation script. Thanks for the feedback.

Indeed, we specify -DCMAKE_SYSTEM_NAME=iOS in our project generation script. Thanks for the feedback.

This will work now too, if you don't need to build Vulkan back-end.

Indeed, we specify -DCMAKE_SYSTEM_NAME=iOS in our project generation script.

This will work now too, if you don't need to build Vulkan back-end.

If we'd want to, what would we need to change to make this work? Is this something that should be changed in Diligent Engine, or rather on our side?

You can use the old approach with manual toolchain specification. There are some issues in 3rd party projects when you use the new way: they need to update CMake files to detect iOS platform properly. This should not be a big problem as with the toolchain specification all third-party projects work fine on iOS already.

You can use the old approach with manual toolchain specification. There are some issues in 3rd party projects when you use the new way: they need to update CMake files to detect iOS platform properly. This should not be a big problem as with the toolchain specification all third-party projects work fine on iOS already.

Thanks for all these details ;)

https://github.com/KhronosGroup/SPIRV-Tools/issues/2994

https://github.com/KhronosGroup/SPIRV-Tools/issues/2994 is now fixed, so -DCMAKE_SYSTEM_NAME=iOS should work for Vulkan on iOS as well

\o/


Describe web session life time

Description of the bug or enhancement
See questions like asked in this forum topic: https://www.cuba-platform.com/discuss/t/session-timeout/13027
If I am not wrong, currently in the developer's manual there is no single page describing aspects of web session life time.
Only scattered configuration properties.
We should create separate page that describes behavior in one place.
What should be said:

In web client there are two sessions: web session and CUBA user session. Web session stored Vaadin UI components and is stored on web layer, while CUBA user session is stored on core layer in jgroups cluster, it stores security data and session attributes.
Lifetime of these sessions are configured by 2 different parameters: cuba.httpSessionExpirationTimeoutSec and cuba.userSessionExpirationTimeoutSec
Ideally these two parameters should have the same values. If not equal, CUBA user session timeout should be > web session timeout.
In web client there is such thing as heartbeat. If at least one browser window is active, web client periodically pings both web session and user session, not allowing it to expire.
heartbeat interval is configured by cuba.web.uiHeartbeatIntervalSec parameter.
you can turn on "cuba.web.closeIdleHttpSessions" and enable closing of idle http sessions, regardless of heartbeat.
each heartbeat request fires a SessionHeartbeatEvent - fired on heartbeat requests from a client web browser. (already mentioned in docs). You can use if for your own purposes.

Consult with web team guys what else should be mentioned.

Do it in a branch plz.


gendaylit - normRGB

Hey everyone,
I've been going through the gendaylit command as defined within the main code of bifacial_radiance.
Specifically, when defining the ground glow for each wavelength channel, the reflectance of each channel is normalized with normval = R*.263 + G*.655 + B.082 leading to:
skyfunc glow ground_glow
0
0
4 R/normval G/normval B/normval 0
Since I am interested in solar irradiance and not illuminance, do I still need to normalize each RGB reflectance value?
Regardless, by default the sky is defined to be grey, so I would assume that normalizing ground reflectance is unnecessary?
Any insights are highly appreciated,
Cheers,
Alex

Hi Alex (sorry for the delay)
I'm sorry that we're not going to be the best ones to give you an authoritative answer on this question.  I would refer to the gendaylit man pages where this topic is discussed.  I believe that the treatment of irradiance in this way is self-consistent because the definition of the sky brightness is in Wm-2, and the measurement of incident irradiance is in Wm-2.  My recollection was that defining the ground glow based on this default illuminance value will allow calculation back to Wm-2 using Radiance's default white light efficacy of 179 lm/W.

I'm going to close this issue as resolved - please reply back if it should be reopened.


is there a way to get any meta data from the original data in a cluster?

We want to be able to render custom map clusters, based on the original array of items and properties of that specific item.
I rendered all the data from the superClusterRef and the renderCluster props of this library and there doesn't seem to be anything about the underlying data of the cluster.
Am I missing something or is this not available?

I went to issues to ask the same question. I've been thinking about it all evening and haven't found anything

I had the same issue. Here is the solution that worked for me: https://github.com/venits/react-native-map-clustering/issues/142#issuecomment-626655410


Change import path as true name for clarity

For the time being, one requires a structure likewise:
var LinkedList = require('mnemonist/linked-list');

Would it be better to have:
var LinkedList = require('mnemonist/LinkedList');

@jacomyal what do you think of this?

I totally arbitrarily prefer var LinkedList = require('mnemonist/linked-list'); and I can't say why.

Case closed then.


Rewrote ArrayTransform.xsac

Should now use type patterns correctly.

Build still fails. This seems to happen because of the usage of A[i], with A an array, and i an index, which is unrecognized in ArrayTransform.


Add PowerShell

Hi!
Thanks for accepting the request! I've one question, this contribution is valid for the hacktoberfest?

https://hacktoberfestchecker.herokuapp.com/
Check it out here!


Excluding audio container

Proposed Changes
Hassio now includes a new hassio_audio container. Adding this to the default exclude list for Portainer.

Closing, as this was resolved by https://github.com/hassio-addons/addon-portainer/commit/85bad73f4859f8230a5853c615e464832b47ec1f


Add mock errinj unit test

fpga_reset,
fpga_port_umsg_enable
fpga_port_umsg_disable
The ioctl above have not been implemented/turn on as DEFAULT_IOCTL_HANDLER in ioctl_handlers.cpp. Those tests are temporary commented out.

All the tests are testing with uninitialized handle. I will discard them except for the last one which tests fpgaAssignPortToInterface with a valid handle.

Don't discard them, necessarily.  It would also be valid to just update the comments to reflect the scenario under test.


Question: How deterministic is EnTT (ECS side)?

Context: This is a probing question to see how much effort I need to put into a sync system between a server and clients (or in other network models)
Hope everything's going well @skypjack! Have a broad but hopefully not too broad question on EnTT:
How deterministic is the ECS aspect of the library exactly? Specifically...

If entt::registry is provided with the exact same inputs on the same architecture, will it result in identical state? (Such as entity ids and entity + component order)

Assuming there's no <random> usage or other sources of noise as well

Would the order when looping via registry::view ever differ, assuming groups and sorts are either completely unused or identically used in the same way (ie, same order of calls and relevant inputs on the same machine)?
Cross-platform determinism: To the best of your knowledge, would any of the above differ across various architectures? Eg, if a simulation on two very different architectures are using EnTT in "equivalent" fashion (at least in order of calls and otherwise identical inputs to entt::registry), would they always result in the same order of execution for views + identical entity ids and internal component order + otherwise roughly the same (observable) state?

I've seen a few interesting mentions in other question issues - eg, #24 and #161 - but from a quick skim, they don't seem to answer the above question. Thus I'm interested in learning more about EnTT's determinism before I over- or under-engineer some relevant mechanisms =)

Interesting question. In general:

If entt::registry is provided with the exact same inputs on the same architecture, it results in identical state.
Would the order when looping via registry::view ever differ [...]? No but this derives from the previous question actually.
Cross-platform determinism: To the best of your knowledge, would any of the above differ across various architectures? Yes.

As for the third question, you can make it fully deterministic if you like but it may differ out of the box.
Briefly, EnTT uses PRETTY_FUNCTION and FUNC_SIG to create an identifier for a given type and the major compilers return different values sometimes.
This could affect for example the order of iteration of the pools when destroying an entity. It never affects the order of iteration of the entities when iterating a view though.
Like everything else in EnTT, you have control over this part too. In fact, everything in the type info system is customizable. 👍

Interesting, this almost certainly means I have less work ahead of me than I thought and multiple options to knowingly modify the relevant parts of EnTT here as needed.
Thank you for the detailed response! This'll definitely come in handy ^_^


Get hover from multiple lsps

I don't really intend for this to be merged, but it could perhaps be a stepping stone for a more robust solution.
What I've done is I have the Hover function retrieve a list of LSPs for the current buffer that have the hover feature. And then loop through these and request the hover information. For the LSP that can't find hover info for the current position, it will just print out an error saying it can't find any info. This is the same behavior as today. But if another LSP finds something to display in the hover popup, it will display this.
So my test consists of angular-language-server, typescript-language-server and vscode-html-language-server. In a typescript document with inline html, I can hover on the html-properties and angular-ls will respond with a popup. But if I hover on something in typescript, typescript-ls will respond. Works as indented.
Here I'm hovering on a html property within a string in typescript, and angular-ls responds.

Here I'm hovering over a typescript property and typescript-ls responds.

The warning on the bottom comes from the other LSP that didn't find any hover info. This should be pretty easy to hide?
There is however an issue when two or more LSPs can show hover on the same position. In html-documents both vscode-html-ls and angular-ls can show hover on html-tags. Vscode has a lot of info on what kind of tag you are hovering over and also you can hover on attribute names. Angular-ls just says what kind of tag it is. But the overlap can give a result you didn't want, so here a mechanism for prioritizing the LSP is needed. I couldn't really figure out a decent way to do that yet.
Again, I don't really expect you to merge this, but what do you think if the idea that two or more LSPs can respond on the same feature on the same document? If this would work on things like completion and such it would really be terrific for my when I work with my angular projects in particular.

The warning message if the hover information is not found can be changed to display only if all the LSP servers return empty information.
Also, after valid information is returned by an LSP server, there is no need to query other subsequent servers (as this will slow down the operation).
This approach can be used for synchronous LSP requests.  But for asynchronous LSP requests this approach will not work.  Completion currently uses asynchronous RPC to get the completion matches from the LSP server.

@MartinAskestad I like this idea. One major problem in implementing this is that :LspHover is async as it requests the server for hover information. Which means that we would proper have to refactor quite a bit of code to be able to only request hover from just enough servers to get a valid result.

Full disclaimer, I'm not that versed in vim-script. But if there is something similar to JavaScripts Promise.all, it would be pretty trivial to call several LSPs asyncly and handle the results.


[react] cellEditorFramework wraps editor component in

While trying to switch from a standard cellEditor to a react cellEditorFramework I noticed that the rendered component is wrapped in a <div> element, which doesn't happen when using the non-framework variant.
This has the negative side-effect that it's difficult to style the editor without having control of the wrapping <div>.
This wrapper should be removed in my opinion, or is there a reason for it to exist?

yes it's needed to host the little mini React engine for the cell - that's how react works - it needs a parent div for us to inject the cell into.
if interested, here is the code:
https://github.com/ceolter/ag-grid-react/blob/master/src/agReactComponent.ts#L23
for styling, this element is passed to the react cellRenderer as parameter reactContainer, maybe this can help you?


Missing icons

What would cause missing icons? I dont have a volume icon, or a start menu icon like the example picture shows

Since all icons are just font glyphs, you may not have a NerdFont installed. In the default style.css it tries to draw OS button using JetBrainsMono Nerd Font, however waybar will usually fallback to any nerdfont available on your system.
Closing this because this is not my config issue.


Things relating to the compareTo method on Strings...

Question Description

Q4: Note the use of compareTo in the compare method of the LexiComp class. By referring to the String class in the Java API, what can you find out about the compareTo method?

Your contribution:
They check each and every letter of the original and the target string, and should there be any difference, then said difference is returned.
If there are no differences, then the length is taken instead.
See screenshot below for more info.
But still, this may present problems if we desire our sorting algorithm to do something else.
Thanks @samuelneo for notifying me of the error!
Screenshots

Taken from here
`

They consider string size first (if different the difference of the string lengths is returned), otherwise they will compare them letter-by-letter.

this doesn't seem to match the screenshot you've attached - the documentation in the screenshot notes that the strings are compared pairwise until there is a difference. if there is no difference in the pairwise comparisons, only then is the string length used as comparison

Took a look again, you’re right!
Will have to go back and change my contribution.
Thanks!
Get Outlook for iOShttps://aka.ms/o0ukef

From: Samuel Neo @.>
Sent: Sunday, February 18, 2024 1:23:48 PM
To: nus-cs2030/2324-s2 @.>
Cc: Zhang Hao Dong @.>; Author @.>
Subject: Re: [nus-cs2030/2324-s2] Things relating to the compareTo method on Strings... (Issue #107)
They consider string size first (if different the difference of the string lengths is returned), otherwise they will compare them letter-by-letter.
this doesn't seem to match the screenshot you've attached - the documentation in the screenshot notes that the strings are compared pairwise until there is a difference. if there is no difference in the pairwise comparisons, only then is the string length used as comparison
—
Reply to this email directly, view it on GitHubhttps://github.com/nus-cs2030/2324-s2/issues/107#issuecomment-1950966442, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BBRJ5GXBCJAYT2GTDAB2EELYUGF6JAVCNFSM6AAAAABDNODYAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJQHE3DMNBUGI.
You are receiving this because you authored the thread.Message ID: @.***>

Included in Lecture 2 notes.


Add api method to specify name of resulted image

https://github.com/imagemin/imagemin#usage. Have a look at gulp-rename.

Thanks, I missed that.


Handling Missing data on the merged data

Merge Data cleaning for whole data

Merger Data cleaning features for combined data

Data cleaning and EDA tasks-1 branch merged with main

Compotator distance and promo effect added