ROS2 Humble - nav2-costmap-2d build error

Describe the bug
Hi, i'm trying build nav2-costmap-2d in Humble distro on "kirkstone". And i got this error:
[13/36] /media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/aarch64-poky-linux-g++ --sysroot=/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot -DDEFAULT_RMW_IMPLEMENTATION=rmw_fastrtps_cpp -DTINYXML2_IMPORT -Dnav2_costmap_2d_core_EXPORTS -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/git/include -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/eigen3 -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/geometry_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/laser_geometry -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/map_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/message_filters -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/nav2_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/nav_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/pluginlib -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rclcpp -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rclcpp_lifecycle -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/sensor_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/std_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/std_srvs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/tf2 -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/tf2_geometry_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/tf2_ros -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/visualization_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/angles -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/lifecycle_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rclcpp_action -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/bond -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/action_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcl_interfaces -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/builtin_interfaces -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosidl_runtime_c -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcutils -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosidl_typesupport_interface -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosidl_runtime_cpp -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosidl_typesupport_fastrtps_cpp -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rmw -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosidl_typesupport_fastrtps_c -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosidl_typesupport_introspection_c -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosidl_typesupport_introspection_cpp -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/ament_index_cpp -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/libstatistics_collector -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcl -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcl_logging_interface -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcl_yaml_param_parser -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/tracetools -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcpputils -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/statistics_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosgraph_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosidl_typesupport_cpp -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosidl_typesupport_c -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/unique_identifier_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/class_loader -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcl_lifecycle -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/orocos_kdl -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcl_action -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/tf2_msgs -mcpu=cortex-a53 -march=armv8-a+crc -mbranch-protection=standard -fstack-protector-strong  -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security  --sysroot=/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot  -O2 -pipe -g -feliminate-unused-debug-types -fmacro-prefix-map=/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0=/usr/src/debug/nav2-costmap-2d/1.1.12-1-r0                      -fdebug-prefix-map=/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0=/usr/src/debug/nav2-costmap-2d/1.1.12-1-r0                      -fdebug-prefix-map=/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot=                      -fdebug-prefix-map=/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot-native=  -fvisibility-inlines-hidden -Wno-error=deprecated -Wno-error=deprecated-declarations -Wno-error=maybe-uninitialized -DNDEBUG -fPIC -Wall -Wextra -Wpedantic -Werror -Wdeprecated -fPIC -std=gnu++17 -MD -MT CMakeFiles/nav2_costmap_2d_core.dir/src/clear_costmap_service.cpp.o -MF CMakeFiles/nav2_costmap_2d_core.dir/src/clear_costmap_service.cpp.o.d -o CMakeFiles/nav2_costmap_2d_core.dir/src/clear_costmap_service.cpp.o -c /media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/git/src/clear_costmap_service.cpp
FAILED: CMakeFiles/nav2_costmap_2d_core.dir/src/clear_costmap_service.cpp.o
/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/aarch64-poky-linux-g++ --sysroot=/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot -DDEFAULT_RMW_IMPLEMENTATION=rmw_fastrtps_cpp -DTINYXML2_IMPORT -Dnav2_costmap_2d_core_EXPORTS -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/git/include -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/eigen3 -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/geometry_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/laser_geometry -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/map_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/message_filters -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/nav2_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/nav_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/pluginlib -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rclcpp -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rclcpp_lifecycle -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/sensor_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/std_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/std_srvs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/tf2 -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/tf2_geometry_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/tf2_ros -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/visualization_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/angles -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/lifecycle_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rclcpp_action -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/bond -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/action_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcl_interfaces -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/builtin_interfaces -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosidl_runtime_c -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcutils -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosidl_typesupport_interface -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosidl_runtime_cpp -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosidl_typesupport_fastrtps_cpp -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rmw -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosidl_typesupport_fastrtps_c -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosidl_typesupport_introspection_c -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosidl_typesupport_introspection_cpp -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/ament_index_cpp -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/libstatistics_collector -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcl -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcl_logging_interface -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcl_yaml_param_parser -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/tracetools -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcpputils -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/statistics_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosgraph_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosidl_typesupport_cpp -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rosidl_typesupport_c -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/unique_identifier_msgs -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/class_loader -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcl_lifecycle -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/orocos_kdl -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcl_action -I/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/tf2_msgs -mcpu=cortex-a53 -march=armv8-a+crc -mbranch-protection=standard -fstack-protector-strong  -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security  --sysroot=/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot  -O2 -pipe -g -feliminate-unused-debug-types -fmacro-prefix-map=/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0=/usr/src/debug/nav2-costmap-2d/1.1.12-1-r0                      -fdebug-prefix-map=/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0=/usr/src/debug/nav2-costmap-2d/1.1.12-1-r0                      -fdebug-prefix-map=/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot=                      -fdebug-prefix-map=/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot-native=  -fvisibility-inlines-hidden -Wno-error=deprecated -Wno-error=deprecated-declarations -Wno-error=maybe-uninitialized -DNDEBUG -fPIC -Wall -Wextra -Wpedantic -Werror -Wdeprecated -fPIC -std=gnu++17 -MD -MT CMakeFiles/nav2_costmap_2d_core.dir/src/clear_costmap_service.cpp.o -MF CMakeFiles/nav2_costmap_2d_core.dir/src/clear_costmap_service.cpp.o.d -o CMakeFiles/nav2_costmap_2d_core.dir/src/clear_costmap_service.cpp.o -c /media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/git/src/clear_costmap_service.cpp
In file included from /media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rclcpp/rclcpp/logging.hpp:24,
                 from /media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rclcpp/rclcpp/client.hpp:40,
                 from /media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rclcpp/rclcpp/callback_group.hpp:24,
                 from /media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rclcpp/rclcpp/any_executable.hpp:20,
                 from /media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rclcpp/rclcpp/memory_strategy.hpp:25,
                 from /media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rclcpp/rclcpp/memory_strategies.hpp:18,
                 from /media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rclcpp/rclcpp/executor_options.hpp:20,
                 from /media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rclcpp/rclcpp/executor.hpp:37,
                 from /media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rclcpp/rclcpp/executors/multi_threaded_executor.hpp:25,
                 from /media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rclcpp/rclcpp/executors.hpp:21,
                 from /media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rclcpp/rclcpp/rclcpp.hpp:155,
                 from /media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/git/include/nav2_costmap_2d/clear_costmap_service.hpp:22,
                 from /media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/git/src/clear_costmap_service.cpp:20:
/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/git/src/clear_costmap_service.cpp: In member function 'void nav2_costmap_2d::ClearCostmapService::clearExceptRegionCallback(std::shared_ptr<rmw_request_id_s>, std::shared_ptr<nav2_msgs::srv::ClearCostmapExceptRegion_Request_<std::allocator<void> > >, std::shared_ptr<nav2_msgs::srv::ClearCostmapExceptRegion_Response_<std::allocator<void> > >)':
/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcutils/rcutils/logging_macros.h:72:18: error: format not a string literal and no format arguments [-Werror=format-security]
   72 |       rcutils_log(&__rcutils_logging_location, severity, name, __VA_ARGS__); \
      |       ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcutils/rcutils/logging_macros.h:500:3: note: in expansion of macro 'RCUTILS_LOG_COND_NAMED'
  500 |   RCUTILS_LOG_COND_NAMED( \
      |   ^~~~~~~~~~~~~~~~~~~~~~
/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rclcpp/rclcpp/logging.hpp:535:5: note: in expansion of macro 'RCUTILS_LOG_INFO_NAMED'
  535 |     RCUTILS_LOG_INFO_NAMED( \
      |     ^~~~~~~~~~~~~~~~~~~~~~
/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/git/src/clear_costmap_service.cpp:69:3: note: in expansion of macro 'RCLCPP_INFO'
   69 |   RCLCPP_INFO(
      |   ^~~~~~~~~~~
/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/git/src/clear_costmap_service.cpp: In member function 'void nav2_costmap_2d::ClearCostmapService::clearEntireCallback(std::shared_ptr<rmw_request_id_s>, std::shared_ptr<nav2_msgs::srv::ClearEntireCostmap_Request_<std::allocator<void> > >, std::shared_ptr<nav2_msgs::srv::ClearEntireCostmap_Response_<std::allocator<void> > >)':
/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcutils/rcutils/logging_macros.h:72:18: error: format not a string literal and no format arguments [-Werror=format-security]
   72 |       rcutils_log(&__rcutils_logging_location, severity, name, __VA_ARGS__); \
      |       ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcutils/rcutils/logging_macros.h:500:3: note: in expansion of macro 'RCUTILS_LOG_COND_NAMED'
  500 |   RCUTILS_LOG_COND_NAMED( \
      |   ^~~~~~~~~~~~~~~~~~~~~~
/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rclcpp/rclcpp/logging.hpp:535:5: note: in expansion of macro 'RCUTILS_LOG_INFO_NAMED'
  535 |     RCUTILS_LOG_INFO_NAMED( \
      |     ^~~~~~~~~~~~~~~~~~~~~~
/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/git/src/clear_costmap_service.cpp:89:3: note: in expansion of macro 'RCLCPP_INFO'
   89 |   RCLCPP_INFO(
      |   ^~~~~~~~~~~
cc1plus: all warnings being treated as errors

To Reproduce
Layers: poky, meta-openembedded, meta-raspberrypi
Machine: raspberrypi3-64
Can anyone help me?
Thank you in advance!

Thanks for reporting this.  Did you use kirkstone or kirkstone-next for this?
I haven't seen this particular compiler warning before:
/media/minhlang102/Share/yocto/build/tmp/work/cortexa53-poky-linux/nav2-costmap-2d/1.1.12-1-r0/recipe-sysroot/usr/include/rcutils/rcutils/logging_macros.h:72:18: error: format not a string literal and no format arguments [-Werror=format-security]

I believe that it happened, but I am confused why I didn't see it when building for qemux86_64.

Hello @robwoolley, thanks for your reply.
I think my project was not set up correctly. You're right, i have tried follow step in REAME and i built it successfully with qemux86_64 and raspberrypi3-64.
Thank you again.

Hello @robwoolley, thanks for your reply.
I think my project was not set up correctly. You're right, i have tried follow step in REAME and i built it successfully with qemux86_64 and raspberrypi3-64.
Thank you again.


Table is broken

The table is incorrectly formatted

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: d2913d10-a6b6-243e-66b4-f202d0946b92
Version Independent ID: c9627ced-6342-6205-0390-db25e9dfc16f
Content: Executive Summary
Content Source: WindowsServerDocs/identity/ad-ds/manage/component-updates/Executive-Summary.md
Service: windows-server-threshold
GitHub Login: @billmath
Microsoft Alias: billmath

@sttelv thanks for identifying this I will get this fixed.

@sttelv resolved this in an internal pull request. The fix should publish later today or tomorrow.

Hi - great and thank you all! Amazing turnaround, updating docu used to be
a chore when I was still at MS last year :)
Stefan
On Wed, May 9, 2018 at 2:19 AM Alma Jenks<EMAIL_ADDRESS>wrote:

Closed #770
https://github.com/MicrosoftDocs/windowsserverdocs/issues/770 via
d6f9703
https://github.com/MicrosoftDocs/windowsserverdocs/commit/d6f97034de785102068cd7127a2bc5686c696e95
.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/windowsserverdocs/issues/770#event-1616477532,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AjYrY_Uc1NzXEDNM-1J8Cx3r8Cxw2ur9ks5twifrgaJpZM4T2ucS
.

--
Thanks,
Stefan


Request to Enable Edge-to-Edge Support

Hello Natalia and Andrei,
I've noticed the sample app doesn't utilize edge-to-edge layout, which enhances user experience by extending the UI to cover the entire screen, including the status and navigation bar areas. This is a recommended practice for modern Android apps, and according to the Android Developers Guide, it's straightforward to implement.
Enabling edge-to-edge could significantly improve the app's aesthetic and functionality. Could this feature be considered for an upcoming update?
Thank you for your work on this project!

Hi, edge-to-edge support was already introduced as a part of this issue. I am closing this one as it seems duplicated, but if you expect something different then please let us know. Cheers!

My bad. Looks good. Thanks!


Make export paths relative

Godot version:
3.1
Issue description:
Every export preset has now an export path. However the path is absolute, which makes it useless on shared projects (and is a valid reason to add export settings to .gitignore, like it used to be). It would be probably better if the path was relative to project's path.

Yes, I want this to happen too. I also noticed that with shared projects.

I agree, it's a little annoying to have to remove these lines before committing the export_presets.cfg file.
My personal preference is that these lines wouldn't be in this file at all but rather in a .config file that could simply be ignored in the ignore file. It's pretty likely that two different team members want to build to separate locations intentionally. IE. QA might want to build it to a completely separate drive, whereas I might want to just build them to the same folder.
Nevertheless, the relative path shouldn't be relative to res:// but should be relative to the project root folder. So, if it was one directory up in a bin folder it would be "../bin/export.exe"

Since I'm interested in working on this and no one seems to be updating this with progress, I'll take this on! I work full time though, so I'm expecting this to be done in around 2 weeks or so.

@KoBeWi Yeah, the export templates are also absolute paths, so for that reason at least, I .gitignore the export configs.


ModuleNotFoundError: No module named 'carla'

In what area(s)?

/area runtime

/area operator

/area placement

/area docs

/area test-and-releas

e

Describe the proposal

I encounter the wrong when 'python main.py':
Traceback (most recent call last):
File "main.py", line 11, in
import carla
ModuleNotFoundError: No module named 'carla'

It seems like the Carla Python API was not found.
Did you run the  script install.sh?
After that you can source ~/.bashrc and try again

Type vim ~/.bashrc and check if the Carla PythonAPI is added to PYTHONPATH. Then run source ~/.bashrc


deprecated ArcGisImageServerTerrainProvider

Resolves https://github.com/AnalyticalGraphicsInc/cesium/issues/4955.
Do we know if there is anything roadmapped for browser TIFF support? Or, out of curiosity for someone who knows very little about how imagery servers work, how impractical is in-engine TIFF -> RGBA PNG conversion if the TIFF can just be fetched as a binary or something?

Looks good, please submit an issue to remove this with the remove in 1.32 label.

Also in that issue note that there are a few @see ArcGisImageServerTerrainProvider items in the reference doc that should also be removed when the file and tests are removed.

Part of #4897


Fix cabinet

@UuljanAitnazarova please, review the changes and approve :pray:
Feel free to reach out if you have any questions.

looks sane to me


Remove vendor-specific cluster setup instructions

Instead, assume a cluster already exists, or briefly document using
kind to set up a local cluster for testing.
Rationale for this change (first in a series) is outlined in this doc (shared with tekton-dev@): https://docs.google.com/document/d/1sMt06g40Jt0Pr5g0Rgfe02az1A9FAFme8mf962UuSEQ/edit
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:

[n] Includes tests (if functionality changed/added)
[y] Includes docs (if user facing)
[y] Commit messages follow commit message best practices
[y] Release notes block has been filled in or deleted (only if no user facing changes)

See the contribution guide for more details.
Double check this list of stuff that's easy to miss:

If you are adding a new binary/image to the cmd dir, please update
the release Task to build and release this image.

Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes
NONE

/assign @sergetron

/kind documentation

/lgtm


⚠ Bofrost.lu has degraded performance

In e136081, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 951 ms

Resolved: Bofrost.lu performance has improved in 71a9a78.


Migrate to OpenSSL 3.0

OpenSSL 1.1.1 is hitting EOL on September 11th (https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/), this gives us about 5 months to migrate to OpenSSL 3.0 if we want to ensure we keep getting security updates for it. We'll need to scan the code for where the library is used, as well as ensure any dependencies that relay on OpenSSL (like cURL) are updated to the new version.

There is not a label identifying the kind of this issue.
Please specify it either using /kind <group> or manually from the side menu.

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


Reasearch availble Microcontrollers with CAN support

We need to create a list of micro-controllers that we have an interest in using that also have support for using the CAN bus.
Suff to keep in mind:

Low cost
CAN Peripheral
CRC Peripheral for preforming checksums
TWI/I2C support
SPI support
USART support
Low power, might need to be battery powered at some point.

We currently have found a decent list of possible options,

ch32v2003
stm32 (multiple)
esp32c3
AVR

Research into options finished at this point.


ARROW-7303: [C++] Refactor CSV benchmarks to use Result APIs

Shall we have a nightly GHA action where we exercise the benchmarks?

Not a bad idea. We don't care about the results in GHA but it would be good to know that they work

Created a tracking issue before we forget it https://issues.apache.org/jira/browse/ARROW-7337


Add changelog file

Commit messages is not the right place for tracking user-facing API changes. It would be nice if this repository had a proper changelog file.

If someone contributes a changelog, I will happy accept it.


feat(biome_cli): add --changed option

Summary
Implements #346
Adds a --changed and --since options to the CLI. Also adds vcs.defaultBranch.
Currently it's only added for the lint command. Once the implementation is correct and testing is figured out, I plan to add it to the format, check and ci commands.
As discussed in the issue, I've implemented the following behaviour:

The --changed flag checks against the default branch set in vcs.defaultBranch config. If it's not present, error is thrown.
The --since option can be used to specify an arbitrary git branch/ref in combination with the --changed flag. It takes precedence over the vcs.defaultBranch config if set. If used without the --changed flag, an incompatible_end_configuration error is raised.

Test Plan
Now this is where I'd ask for some pointers. The whole feature depends the output of git diff, I assume I'd need to mock that somehow, but I have not found an example of that in the repo, so any advice on how to test this is welcome.

thanks for adding this! do you know if it'd be possible to add an option to only format/lint changed lines instead of the whole file? could be helpful for very big codebases to incrementally migrate to biome. it's completely fine if you don't add it, but it would be really nice. amazing job anyways 🎉

I think it makes sense! I just need to wrap my head around the MemoryFileSystem part and how that can be implemented, but I think I can figure it out.

@ematipico I've implemented getting the changed files using the FileSystem trait and it works wonderfully with the testing, thanks for the tip! I've written some tests just to verify that basic stuff works and to show how I'd go about the testing.
When you have the time, could you look over the implementation and spot anything that could be implemented in a better way? If so then I'll do the refactor, if not I'll implement it for the other commands, add more tests and add documentation.


Parallel metadiags

The changes fix an issue with the plot generated for plot set 5. Also fixed is an issue with metadiags to account for the table in plotset 1.

Just curious... Did you see mpi-metadiags.py in either the brian/ branch or
maybe an mpi/ branch?
On Wed, May 25, 2016 at 2:42 PM, James McEnerney<EMAIL_ADDRESS>wrote:

The changes fix an issue with the plot generated for plot set 5. Also
fixed is an issue with metadiags to account for the table in plotset 1.
You can view, comment on, or merge this pull request online at:
https://github.com/UV-CDAT/uvcmetrics/pull/187
Commit Summary

Repaired the customize for plot set 5; RMSE and correlation
I need to handle the case of a table
This version corrects an issue so that set 1 will run.
Change baseline plot for plot set 5 to fix an issue with customize
template.

File Changes

M src/python/frontend/metadiags.py
https://github.com/UV-CDAT/uvcmetrics/pull/187/files#diff-0 (87)
M src/python/packages/amwg/amwg.py
https://github.com/UV-CDAT/uvcmetrics/pull/187/files#diff-1 (9)
M
test/baselines/plotset5/figure-set5_Global_ANN_T_plot-combined.png
https://github.com/UV-CDAT/uvcmetrics/pull/187/files#diff-2 (0)

Patch Links:

https://github.com/UV-CDAT/uvcmetrics/pull/187.patch
https://github.com/UV-CDAT/uvcmetrics/pull/187.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/UV-CDAT/uvcmetrics/pull/187


SemTK/SPARQLgraph restriction explorer

SPARQLgraph "explore restrictions" screen to improve ability to address quantified cardinality from model ("has at most...")

show violations vs incomplete (> max cardinality vs < min)
show frequency as percentage of target class
browse the violating URI (like a construct query)

completed.


Fixing internal server errors for external sources

References
Add references/links to any related issues or PRs. These may include:

Fixes #2981

Description
For the full scope/history of the problem, have a read through the linked issue.
Long story short: A bunch of the externalsources endpoints resulted in 500 code error.
This PR adds in additional checks to avoid these exceptions ending up in the response, but rather, that if there are no results, an empty paginated response is sent.
Instructions for Reviewers
Changes done to the code
For the sherpaJournal/sherpaPublisher, it returns an empty list similar to the other providers (Where it previously returned null.
ORCID NullPointerException -> This was partly because the actual processing code needed some additional NullPointer checks. (If a person is being returned without 'name' information). The code now adds in additional checks to avoid these kinds of errors.
After that fix, there was another issue however when going through the calls:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<error xmlns="http://www.orcid.org/ns/error">
    <response-code>400</response-code>
    <developer-message>The start parameter for API users without credentials must be an integer between 0 and 10,000 Full validation error: The start parameter for API users without credentials must be an integer between 0 and 10,000</developer-message>
    <user-message>The start parameter for API users without credentials must be an integer between 0 and 10,000</user-message>
    <error-code>9043</error-code>
    <more-info>https://members.orcid.org/api/resources/troubleshooting</more-info>
</error>

The underlying reason is that the query being done contained too much results, and the pagination simply took that number of results as is. The actual ORCID API can't properly handle it in all cases through (As mentioned in the <developer-message>, it can only handle up to 10k records in a call)
This has been subsequently handled by making sure that

the initial call only retrieves the max number of results that the API allows
This limit is also propagated to the pagination (So that for example the 'last' page link doesn't link to records that don't exist/can't be retrieved)

Checklist
This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome). If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

[x] My PR is small in size (e.g. less than 1,000 lines of code, not including comments & integration tests). Exceptions may be made if previously agreed upon.
[x] My PR passes Checkstyle validation based on the Code Style Guide.
[x] My PR includes Javadoc for all new (or modified) public methods and classes. It also includes Javadoc for large or complex private methods.
[x] My PR passes all tests and includes new/updated Unit or Integration Tests based on the Code Testing Guide.
[x] If my PR includes new, third-party dependencies (in any pom.xml), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
[x] If my PR modifies the REST API, I've linked to the REST Contract page (or open PR) related to this change.

hi @jonas-atmire
thanks to work on that. Unfortunately, the orcid v2 provider will be replaced soon by the updated v3 so I think that your fixes if needed should be redone on the new version, see https://github.com/DSpace/DSpace/pull/2780

#2780

@abollini I agree that these fixes would need to be redone on the new version, but since this feature upgrade hasn't been merged into main just yet, I think it would not be the best course of action to first merge v3 into main, then check if the errors are there as well, and then create another PR to fix them separately. (Since that would basically mean we are merging 'broken' code into main at that point).
Since these fixes are not very extensive, and at the moment, specific to v2 code that is in main (Basically some NullPointer checks and setting a 'max' parameter on a particular call)
Could you

Make sure that these particular types of errors are also present in the ORCID v3 PR
If so -> Check out if the code that is related to those errors is similar to the code in this PR
Check if the fixes done in these PR also fix those in the V3
Update the related PR

This way we are not introducing code creeps into this PR (Possibly delaying a PR with some fixes that are not extremely extensive)

Hi @jonas-atmire : Just a note... the ORCID v3 changes have now been merged into main, which caused merge conflicts in this PR.  If you can find time to rebase & fix those conflicts it'd be appreciated!

@jonas-atmire : Just to follow-up.  It looks (to me) like your changes in this PR to OricdV2AuthorDataProvider can be easily copied into the new OrcidV3AuthorDataProvider class (on main).  The code differences between those two classes is very minor (only 64 lines changed...most were renaming "V2" to "V3" with a few other minor syntax changes required to call the V3 API)...see https://github.com/DSpace/DSpace/pull/2780/files#diff-e7212bf9756781b0531484b7f600b948a7374f97009bcc18e4d3debc5c89a784
So, the next steps for this PR should be to simply move your changes to OrcidV3AuthorDataProvider, as they seem to be applicable there as well.  At that point, I'll gladly do a review/test & (if needed) pull in @abollini for secondary advice.


Improve compiler error message

When an attribute or relation that is part of the constructor the following message is given for example:
attributes police are part of an index and should be set in the constructor. (reported in Construct(pm::Rate) /module/model/mpls/ciscoxr.cf:77))

However this message could be improved by doing the following:

In this case it is a relation but the message says attributes.
It only implicitly mentions the type
The import rewrites the name so it does not point directly to the type or the index

A potential improved message could be:
Relation police of type ciscoxr_services::policy_map::Rate is part of an index and should be set in the constructor.
For an attribute it should say attribute
It might also be useful to mention:

Where the relation or attribute is defined
Where the index is defined

or perhaps even
Invalid Constructor call: missing attribute 'police'. The attribute ciscoxr_services::policy_map::Rate.police is part of an index.

Hey team! Please add your planning poker estimate with ZenHub @arnaudsjs @bartv @FloLey @Hugo-Inmanta @sanderr


Performance Best Practices for CuPy

It's better to have a performance docs focusing on CuPy, like as we did for Chainer Performance Best Practices.

Use Numba
Take care of GPU/CPU implicit transfer
How to benchmark correctly (cupyx.time.repeat)
How to profile correctly (nvvp / nvprof)
Use float32 instead of float64 (#4891)
...

Use Numba

Now that CuPy has its own JIT compiler, I don't think this is that important anymore 🙂


Simplify FixedLengthEncoding

Which issue does this PR close?

Part of #2677
Rationale for this change

Const generics have a lot of rough edges, including https://github.com/rust-lang/rust/issues/80528
They were always a bit overkill for the needs here, it was only a lack of imagination on my part that made me reach for them :sweat_smile:
What changes are included in this PR?

Are there any user-facing changes?
No, this trait is an implementation detail of the row format

Benchmarks show no major change in performance, this doesn't change any of the types involved, just the trait plumbing, and so it would be surprising if this changed performance (although stranger things have happened)


Unused attributes in the code

WalkingModule::m_firstStep
The WalkingModule::m_firstStep attribute is updated once, but it is never used by the program. Instead the WalkingFK::m_firstStep is actually used.
Perhaps it could make sense to remove WalkingModule::m_firstStep?
WalkingFSM::Stance
The Stance state of the FSM is never used. Perhaps it could make sense to remove it?

This will be fixed by #33

Fixed by https://github.com/robotology/walking-controllers/pull/33 .


[Mock Observations] Incorrect error message when duration is 0

Description of the Error
In mock observations plugin -> global config,  when the duration = o , then inappropriate error message is received.
Expected Behaviour

More descriptive and suitable error message, like "Duration should be greater than 0" or similar.
Actual Behaviour
The following error is received
"RangeError:     Maximum call stack size exceeded"
Steps to Reproduce

Run the manifest file , provided below, where duration = 0

Manifest File That Generated the Error

description: a manifest demonstrating how to use the mock observations feature
tags:
initialize:
 #outputs: ['yaml']
  plugins:
    mock-observations:
      kind: plugin
      method: MockObservations
      path: "@grnsft/if-plugins"
      global-config:
        timestamp-from: 2023-07-06T00:00
        timestamp-to: 2023-07-06T00:10
        duration: 0
        components:
          - cloud/instance-type: A1
          - cloud/instance-type: B1
        generators:
          common:
            region: uk-west
            common-key: common-val
          randint:
            cpu/utilization:
              min: 1
              max: 99
            memory/utilization:
              min: 1
              max: 99
tree:
  children:
    child:
      pipeline:
        - mock-observations
      inputs:  ```

![Uploading Screenshot 2024-05-16 at 12.49.20 AM.png…]()

@MariamKhalatova  @jmcook1186  I made sure that the value of duration is checked to be greater than 0 in validateGlobalConfig(). Now, I have this result for the manifest file you provided :

I also added a test that checks that this error is thrown if duration is null. Is this suffiscient?

Hi @mouhamadalmounayar sorry I didn't see your message sooner- this error arises from a small bug in the framework that is already fixed and will be included in the next release. If you want to work on IF, there are still some open good-first-issues on the board!

Closing as fixed


Fix ffmpeg/tests/test_ffmpeg.py: test_pipe() (v2: recalculate PTS)

When trimming, FFmpeg 5.x retains the input presentation timestamp (PTS) in the output.  This causes the trimmed output frames to be duplicates of the first.
#726 detects and ignores the duplicate frames.  This PR prevents the duplicate frames by recalculating the PTS.

This fix didn’t work for me on FFmpeg 7, whereas https://github.com/kkroening/ffmpeg-python/pull/726 does.

Closing in favor of #726.


ExoMAST patch for setup.py

This PR makes some changes to setup.py per request of the ExoMAST team.

Note that the Travis CI builds are failing for this for reasons that are not clear.  The error is with installing batman-package.  What is strange is that there have been no changes to our Travis environment nor the batman-package itself since our last successful builds ~9 days ago.
Furthermore, I don't think the reason for the failed builds have anything to do with this particular change -- several of the current open pull requests are failing with the same error.
Jeff has told me that it is critical that this change be implemented this week, as it is a roadblock for the team's progress.  As such, we are merging this PR despite the failed Travis build and we will try to figure out the reason for the batman-package errors separately.


Move database from json to GDrive sheet

This will bring the following benefits:

Easier maintenance
No need to commit to update the DB --> separation between code and data

See :

https://spreadsheets.google.com/feeds/list/15DoM_Y1uH9zQWAgPxpiSegYGlP7gnoelFpxv4d91zJI/od6/public/values?alt=json
http://stackoverflow.com/a/23641716/1734119
https://developers.google.com/gdata/samples/spreadsheet_sample


Strange interaction between plot functions

If I combine plot with area, the plotted area is incorrect if the plot line is on or near the displayed region, and plot is called before area.  I first noticed this kind of behavior with draw_polygon instead of area, but I did more testing with area since using it is a little bit simpler--there is only one defined edge.  I haven't experimented with other combinations involving area or draw_polygon.
Experiment 1:
module M = Owl.Mat;;
module P = Owl.Plot;;

let xs = M.sequential 1 10;;
let ys = M.map (fun x -> x**2.)  xs;;

(* An area plot: *)
let h = P.create "foo.pdf" in P.(area ~h xs ys; output h);;

(* Let's add line along the top edge: *)
let h = P.create "foo.pdf" in
P.(area ~h xs ys;
   plot ~h ~spec:[RGB(0,0,255); LineWidth 5.] xs ys;
   output h);;

(* Try the same thing but call plot for the line first: *)
let h = P.create "foo.pdf" in
P.(plot ~h ~spec:[RGB(0,0,255); LineWidth 5.] xs ys;
   area ~h xs ys;
   output h);;
(* Where did the blue line go? *)

(* Let's make the line wide.  First call area and then call plot. *)
let h = P.create "foo.pdf" in
P.(area ~h xs ys;
   plot ~h ~spec:[RGB(0,0,255); LineWidth 50.] xs ys;
   output h);;
(* It looks as if the line is centered along the edge of the area;
 * that makes sense. *)

(* Now lets try calling plot first: *)
let h = P.create "foo.pdf" in
P.(plot ~h ~spec:[RGB(0,0,255); LineWidth 50.] xs ys;
   area ~h xs ys;
   output h);;
(* Very strange.  It looks as if the plot line is missing, and the entire `area` region
 * has an extra wide edge on all sides, with some diagonal corners.  *)

Experiment 2:  Same as experiment 1, but for plot, give arguments xs xs rather than xs ys, so that a straight line is (supposed to be) drawn over the area.  With plot second, it behaves as expected.  With plot first, and LineWidth 50., the image seems to be identical to the last example in experiment 1.
Experiment 3:
let ys' = M.map (fun x -> (x**2.) +. 10.)  xs;;

Now pass xs ys to area, and xs ys' to plot.  In this case, the line is blue even when plot is called first.  When LineWidth is 5.,  the image is as you would expect, whether plot is called first or second.  However, when LineWidth is called first, the area region again shows the distorted shape illustrated in experiments 1 and 2.
Here is the last image from experiment 3.  Notice the shape of the area region:
foo.pdf

At least part of what's happening is that LineWidth in plot is affecting the width of the lines used for the fill pattern--i.e. what FillPattern specifies.  My guess is that there's an underlying pattern that's used to generate the solid fill for FillPattern 0, so a very thick line width ends up giving the area output a weird shape.

I copied the two line_width lines from plot to area.  This allows area to override plot's line width, but only when LineWidth is specified explicitly in area's ~spec value.  I don't understand this.  There's something I'm not seeing.
This is what I did.  The two lines containing line_width are new:
let area ?(h=_default_handle) ?(spec=[]) x y=
  let open Plplot in
  let x = Owl_dense_matrix.D.to_array x in
  let y = Owl_dense_matrix.D.to_array y in
  let xmin, xmax = Owl_stats.minmax x in
  let x = Array.(append (append [|xmin|] x) [|xmax|]) in
  let y = Array.(append (append [|0.|] y) [|0.|]) in
  _adjust_range h x X;
  _adjust_range h y Y;
  (* prepare the closure *)
  let p = h.pages.(h.current_page) in
  let color = _get_rgb spec p.fgcolor in
  let r, g, b = color in
  let line_style = _get_line_style spec 1 in
  let line_width = _get_line_width spec (-1.) in
  let fill_pattern = _get_fill_pattern spec 0 in
  (* drawing function *)
  let f = (fun () ->
    let r', g', b' = plgcol0 1 in
    plscol0 1 r g b;
    plcol0 1;
    if line_width > (-1.) then plwidth line_width;
    pllsty line_style;
    plline x y;
    plpsty fill_pattern;
    plfill x y;
    (* restore original settings *)
    plscol0 1 r' g' b';
    plcol0 1;
    pllsty 1
  )
  in
  (* add closure as a layer *)
  p.plots <- Array.append p.plots [|f|];
  (* add legend item to page *)
  _add_legend_item p BOX line_style color "" color fill_pattern color;
  if not h.holdon then output h

The problem seems to be that the closure created in plot includes a let in the scope of an if test that is usually false.  As a result, all of the rest of the code in the closure doesn't get executed, including the code that restores settings to previous values.  Submitting a PR that fixes this, as well as a similar bug in loglog.

This is a great bug report, really appreciate that you managed to fix it. 👍


API Version Support is Incompatible with OData for Web API Library 6.0

Changes in the OData library 6.0 for Web API introduces changes that are incompatible with the OData API versioning support.  OData API versioning should also support 6.0. Various incompatibility issues arise as reported by issue #35.

Hi,
Is this issue being addressed by anyone?
I'm working on a fix, but it won't be backwards-compatible with the current version.
The solution requires a change of interface in the MapVersionedODataRoutes methods to something like:
public static IReadOnlyList<ODataRoute> MapVersionedODataRoutes(this HttpConfiguration configuration, string routeName, string routePrefix, Action<IContainerBuilder> configureAction, IEnumerable<IEdmModel> models)
Thanks

Unfortunately, it's just been me and I've been tied up with other priorities; primarily my day job. I'm a strong advocate and consumer of OData, so being able to move past 5.9.1 to 6.0+ is something I definitely want to see happen.
From my cursory examination, I know that support for 6.0+ won't be backward compatible. There are significant breaking changes in the OData library. It's unfortunate that the changes are breaking, but the from what I've seen, I'm pleased with the changes they've made; I think it's in the right direction.
I believe you're right, most of the changes are in the related MapVersionedODataRoutes. Since DI has now been introduced with first-class support, I'm not even sure these methods are required anymore. They were needed to change the behaviors of how routing was setup, including behaviors like conventions, casing, etc. I believe that most or all of these aspects can now be changed via the DI support.
I'll see if I can dedicate some time this week. If you have anything to show or share, I'm more than happy to take a look.

Sure, I already have a POC working on .Net 4.5.2. and will push the code to
my fork so that you can have a look / comment.
João Nogueira
2017-01-05 18:04 GMT+00:00 Chris Martinez<EMAIL_ADDRESS>
Unfortunately, it's just been me and I've been tied up with other
priorities; primarily my day job. I'm a strong advocate and consumer of
OData, so being able to move past 5.9.1 to 6.0+ is something I definitely
want to see happen.
From my cursory examination, I know that support for 6.0+ won't be
backward compatible. There are significant breaking changes in the OData
library. It's unfortunate that the changes are breaking, but the from what
I've seen, I'm pleased with the changes they've made; I think it's in the
right direction.
I believe you're right, most of the changes are in the related
MapVersionedODataRoutes. Since DI has now been introduced with
first-class support, I'm not even sure these methods are required anymore.
They were needed to change the behaviors of how routing was setup,
including behaviors like conventions, casing, etc. I believe that most or
all of these aspects can now be changed via the DI support.
I'll see if I can dedicate some time this week. If you have anything to
show or share, I'm more than happy to take a look.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/aspnet-api-versioning/issues/36#issuecomment-270713002,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABj7JiYPPPfr0By2wTet_JftIpln9bO7ks5rPTDDgaJpZM4KaGkt
.

Have a look at my latest commit here

With the exception of VersionedMetadataRoutingConventionTest.cs all tests pass on Microsoft.AspNet.OData.Versioning.Tests
I'm not sure how to reference types "MetadataPathSegment/EntitySetPathSegment", or if the tests still makes sense.


test: fix parse set value format

Please provide a description of this PR:

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

/test all