issue when i try to use slam to build 3d model

Prerequisites
Please answer the following questions for yourself before submitting an issue. YOU MAY DELETE THE PREREQUISITES SECTION.

[yes ] I am running the latest version of GAAS
[yes ] I checked the Gitbook documentation and found no answer
[yes ] I checked to make sure that this issue has not already been filed
[yes ] I Googled/Binged the error messages generated by Ubuntu, Gazebo, and PX4
[yes ] I have posted questions regarding Ubuntu, Gazebo, and PX4 in corresponding forums.

Issue Template
Context
Please provide any relevant information about your setup.

Tutorial No.:Tutorial 2
Mavros: forgot
ROS: Kinetic
Gazebo: 7
Ubuntu: 16.04
System Platform: X86

Expected Behavior
In your tutorial, after running rostopic list, there are 2 topics called /gi/simulation/XX/image_raw.
But, I follow your tutorial on gitbook and build from source, when I get into the part2, I can't find anything about the camera and I don't know how to use the slam and SfM simulation.
Then I use the docker way for making sure that I didn't miss any tiny. But, still, when I tap in 'rostopic list', /gi doesn't show up.
Did I forget building the "gi package" or something related?
I see it has been raised months age, and you said you will fixed it. But I still been stuck in this. Can you give me some advices? THX
跟着gitbook的教程走，part1 还好说，part2的时候卡住了，毫无头绪，斗胆来issue提问下。找不到相机数据那个topic，是不是得自己设置相机。还有如何安装，调用slam模块?
这个问题之前看别人也提过，据当时说过一阵会被修复。但我还是在这里出现了同样的问题。能麻烦您帮忙解答下我该如何操作么？

Copy console log and paste it here.

And when I try to use the slam, it can not visualize left camera image in real time. It is only the dark screen./home/comac/图片/2019-10-18 16-29-44屏幕截图.png

when i roslaunch, it raise this
`comac@comac-HP-Z840-Workstation:~/GAAS/software/Obstacle_Map$ roslaunch px4 path_planning.launch
... logging to /home/comac/.ros/log/c85b50a4-f182-11e9-ac30-44334c49fbe0/roslaunch-comac-HP-Z840-Workstation-19074.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.
started roslaunch server http://comac-HP-Z840-Workstation:42703/
SUMMARY
CLEAR PARAMETERS

/mavros/

PARAMETERS

/mavros/cmd/use_comp_id_system_control: False
/mavros/conn/heartbeat_rate: 1.0
/mavros/conn/system_time_rate: 1.0
/mavros/conn/timeout: 10.0
/mavros/conn/timesync_rate: 10.0
/mavros/distance_sensor/hrlv_ez4_pub/field_of_view: 0.0
/mavros/distance_sensor/hrlv_ez4_pub/frame_id: hrlv_ez4_sonar
/mavros/distance_sensor/hrlv_ez4_pub/id: 0
/mavros/distance_sensor/hrlv_ez4_pub/orientation: PITCH_270
/mavros/distance_sensor/hrlv_ez4_pub/send_tf: True
/mavros/distance_sensor/hrlv_ez4_pub/sensor_position/x: 0.0
/mavros/distance_sensor/hrlv_ez4_pub/sensor_position/y: 0.0
/mavros/distance_sensor/hrlv_ez4_pub/sensor_position/z: -0.1
/mavros/distance_sensor/laser_1_sub/id: 3
/mavros/distance_sensor/laser_1_sub/orientation: PITCH_270
/mavros/distance_sensor/laser_1_sub/subscriber: True
/mavros/distance_sensor/lidarlite_pub/field_of_view: 0.0
/mavros/distance_sensor/lidarlite_pub/frame_id: lidarlite_laser
/mavros/distance_sensor/lidarlite_pub/id: 1
/mavros/distance_sensor/lidarlite_pub/orientation: PITCH_270
/mavros/distance_sensor/lidarlite_pub/send_tf: True
/mavros/distance_sensor/lidarlite_pub/sensor_position/x: 0.0
/mavros/distance_sensor/lidarlite_pub/sensor_position/y: 0.0
/mavros/distance_sensor/lidarlite_pub/sensor_position/z: -0.1
/mavros/distance_sensor/sonar_1_sub/id: 2
/mavros/distance_sensor/sonar_1_sub/orientation: PITCH_270
/mavros/distance_sensor/sonar_1_sub/subscriber: True
/mavros/fake_gps/eph: 2.0
/mavros/fake_gps/epv: 2.0
/mavros/fake_gps/fix_type: 3
/mavros/fake_gps/geo_origin/alt: 408.0
/mavros/fake_gps/geo_origin/lat: 47.3667
/mavros/fake_gps/geo_origin/lon: 8.55
/mavros/fake_gps/gps_rate: 5.0
/mavros/fake_gps/mocap_transform: True
/mavros/fake_gps/satellites_visible: 5
/mavros/fake_gps/tf/child_frame_id: fix
/mavros/fake_gps/tf/frame_id: map
/mavros/fake_gps/tf/listen: False
/mavros/fake_gps/tf/rate_limit: 10.0
/mavros/fake_gps/tf/send: False
/mavros/fake_gps/use_mocap: True
/mavros/fake_gps/use_vision: False
/mavros/fcu_protocol: v2.0
/mavros/fcu_url<EMAIL_ADDRESS>/mavros/gcs_url:
/mavros/global_position/child_frame_id: base_link
/mavros/global_position/frame_id: map
/mavros/global_position/gps_uere: 1.0
/mavros/global_position/rot_covariance: 99999.0
/mavros/global_position/tf/child_frame_id: base_link
/mavros/global_position/tf/frame_id: map
/mavros/global_position/tf/global_frame_id: earth
/mavros/global_position/tf/send: False
/mavros/global_position/use_relative_alt: True
/mavros/image/frame_id: px4flow
/mavros/imu/angular_velocity_stdev: 0.0003490659 // 0...
/mavros/imu/frame_id: base_link
/mavros/imu/linear_acceleration_stdev: 0.0003
/mavros/imu/magnetic_stdev: 0.0
/mavros/imu/orientation_stdev: 1.0
/mavros/landing_target/camera/fov_x: 2.0071286398
/mavros/landing_target/camera/fov_y: 2.0071286398
/mavros/landing_target/image/height: 480
/mavros/landing_target/image/width: 640
/mavros/landing_target/land_target_type: VISION_FIDUCIAL
/mavros/landing_target/listen_lt: False
/mavros/landing_target/mav_frame: LOCAL_NED
/mavros/landing_target/target_size/x: 0.3
/mavros/landing_target/target_size/y: 0.3
/mavros/landing_target/tf/child_frame_id: camera_center
/mavros/landing_target/tf/frame_id: landing_target
/mavros/landing_target/tf/listen: False
/mavros/landing_target/tf/rate_limit: 10.0
/mavros/landing_target/tf/send: True
/mavros/local_position/frame_id: map
/mavros/local_position/tf/child_frame_id: base_link
/mavros/local_position/tf/frame_id: map
/mavros/local_position/tf/send: False
/mavros/local_position/tf/send_fcu: False
/mavros/mission/pull_after_gcs: True
/mavros/mocap/use_pose: True
/mavros/mocap/use_tf: False
/mavros/odometry/in/child_frame_id: base_link
/mavros/odometry/in/frame_id: odom
/mavros/odometry/in/frame_tf/body_frame_orientation: flu
/mavros/odometry/in/frame_tf/local_frame: local_origin_ned
/mavros/odometry/out/frame_tf/body_frame_orientation: frd
/mavros/odometry/out/frame_tf/local_frame: vision_ned
/mavros/plugin_blacklist: ['safety_area', '...
/mavros/plugin_whitelist: []
/mavros/px4flow/frame_id: px4flow
/mavros/px4flow/ranger_fov: 0.118682
/mavros/px4flow/ranger_max_range: 5.0
/mavros/px4flow/ranger_min_range: 0.3
/mavros/safety_area/p1/x: 1.0
/mavros/safety_area/p1/y: 1.0
/mavros/safety_area/p1/z: 1.0
/mavros/safety_area/p2/x: -1.0
/mavros/safety_area/p2/y: -1.0
/mavros/safety_area/p2/z: -1.0
/mavros/setpoint_accel/send_force: False
/mavros/setpoint_attitude/reverse_thrust: False
/mavros/setpoint_attitude/tf/child_frame_id: target_attitude
/mavros/setpoint_attitude/tf/frame_id: map
/mavros/setpoint_attitude/tf/listen: False
/mavros/setpoint_attitude/tf/rate_limit: 50.0
/mavros/setpoint_attitude/use_quaternion: False
/mavros/setpoint_position/mav_frame: LOCAL_NED
/mavros/setpoint_position/tf/child_frame_id: target_position
/mavros/setpoint_position/tf/frame_id: map
/mavros/setpoint_position/tf/listen: False
/mavros/setpoint_position/tf/rate_limit: 50.0
/mavros/setpoint_raw/thrust_scaling: 1.0
/mavros/setpoint_velocity/mav_frame: LOCAL_NED
/mavros/startup_px4_usb_quirk: True
/mavros/sys/disable_diag: False
/mavros/sys/min_voltage: 10.0
/mavros/target_component_id: 1
/mavros/target_system_id: 1
/mavros/tdr_radio/low_rssi: 40
/mavros/time/time_ref_source: fcu
/mavros/time/timesync_avg_alpha: 0.6
/mavros/time/timesync_mode: MAVLINK
/mavros/vibration/frame_id: base_link
/mavros/vision_pose/tf/child_frame_id: vision_estimate
/mavros/vision_pose/tf/frame_id: map
/mavros/vision_pose/tf/listen: False
/mavros/vision_pose/tf/rate_limit: 10.0
/mavros/vision_speed/listen_twist: True
/mavros/vision_speed/twist_cov: True
/mavros/wheel_odometry/child_frame_id: base_link
/mavros/wheel_odometry/count: 2
/mavros/wheel_odometry/frame_id: map
/mavros/wheel_odometry/send_raw: True
/mavros/wheel_odometry/send_twist: False
/mavros/wheel_odometry/tf/child_frame_id: base_link
/mavros/wheel_odometry/tf/frame_id: map
/mavros/wheel_odometry/tf/send: True
/mavros/wheel_odometry/use_rpm: False
/mavros/wheel_odometry/vel_error: 0.1
/mavros/wheel_odometry/wheel0/radius: 0.05
/mavros/wheel_odometry/wheel0/x: 0.0
/mavros/wheel_odometry/wheel0/y: -0.15
/mavros/wheel_odometry/wheel1/radius: 0.05
/mavros/wheel_odometry/wheel1/x: 0.0
/mavros/wheel_odometry/wheel1/y: 0.15
/rosdistro: kinetic
/rosversion: 1.12.14
/use_sim_time: True

NODES
/
gazebo (gazebo_ros/gzserver)
gazebo_gui (gazebo_ros/gzclient)
mavros (mavros/mavros_node)
sitl (px4/px4)
vehicle_spawn_comac_HP_Z840_Workstation_19074_939596101739646439 (gazebo_ros/spawn_model)
auto-starting new master
process[master]: started with pid [19084]
ROS_MASTER_URI=http://localhost:11311
setting /run_id to c85b50a4-f182-11e9-ac30-44334c49fbe0
process[rosout-1]: started with pid [19097]
started core service [/rosout]
process[sitl-2]: started with pid [19122]
node name: sitl
data path: /home/comac/catkin_ws/src/Firmware
commands file: /home/comac/catkin_ws/src/Firmware/posix-configs/SITL/init/ekf2/iris_stereo_gray_gps
179 WARNING: setRealtimeSched failed (not run as root?)

| ___ \ \ \ / /   /   |
| |/ /  \ V /   / /| |
|  __/   /   \  / /| |
| |     / /^\ \ ___  |
_|     /   /     |_/
px4 starting.
INFO  [dataman] Unknown restart, data manager file 'rootfs/fs/microsd/dataman' size is 11405132 bytes
process[gazebo-3]: started with pid [19130]
INFO  [simulator] Waiting for initial data on UDP port 14560. Please start the flight simulator to proceed..
process[gazebo_gui-4]: started with pid [19139]
process[vehicle_spawn_comac_HP_Z840_Workstation_19074_939596101739646439-5]: started with pid [19144]
process[mavros-6]: started with pid [19145]
[ INFO] [1571387963.091587193]: FCU URL: udp://:14540@localhost:14557
[ INFO] [1571387963.095335822]: udp0: Bind address: <IP_ADDRESS>:14540
[ INFO] [1571387963.095465468]: udp0: Remote address: <IP_ADDRESS>:14557
[ INFO] [1571387963.095794926]: GCS bridge disabled
[ INFO] [1571387963.114057256]: Plugin 3dr_radio loaded
[ INFO] [1571387963.117837685]: Plugin 3dr_radio initialized
[ INFO] [1571387963.118103013]: Plugin actuator_control loaded
[ INFO] [1571387963.125185336]: Plugin actuator_control initialized
[ INFO] [1571387963.132415721]: Plugin adsb loaded
[ INFO] [1571387963.137400276]: Plugin adsb initialized
[ INFO] [1571387963.137567364]: Plugin altitude loaded
[ INFO] [1571387963.138952010]: Plugin altitude initialized
[ INFO] [1571387963.139083184]: Plugin cam_imu_sync loaded
[ INFO] [1571387963.139868783]: Plugin cam_imu_sync initialized
[ INFO] [1571387963.140040481]: Plugin command loaded
[ INFO] [1571387963.147091298]: Plugin command initialized
[ INFO] [1571387963.147249700]: Plugin companion_process_status loaded
[ INFO] [1571387963.150609851]: Plugin companion_process_status initialized
[ INFO] [1571387963.150751810]: Plugin debug_value loaded
[ INFO] [1571387963.164370184]: Plugin debug_value initialized
[ INFO] [1571387963.164429320]: Plugin distance_sensor blacklisted
[ INFO] [1571387963.164747450]: Plugin fake_gps loaded
Gazebo multi-robot simulator, version 7.0.0
Copyright (C) 2012-2016 Open Source Robotics Foundation.
Released under the Apache 2 License.
http://gazebosim.org
Gazebo multi-robot simulator, version 7.0.0
Copyright (C) 2012-2016 Open Source Robotics Foundation.
Released under the Apache 2 License.
http://gazebosim.org
[ INFO] [1571387963.185341186]: Plugin fake_gps initialized
[ INFO] [1571387963.185590640]: Plugin ftp loaded
[ INFO] [1571387963.195314650]: Plugin ftp initialized
[ INFO] [1571387963.195496593]: Plugin global_position loaded
[ INFO] [1571387963.218239093]: Plugin global_position initialized
[ INFO] [1571387963.218395573]: Plugin gps_rtk loaded
[ INFO] [1571387963.221902057]: Plugin gps_rtk initialized
[ INFO] [1571387963.222089773]: Plugin hil loaded
[ INFO] [1571387963.243618418]: Plugin hil initialized
[ INFO] [1571387963.243807112]: Plugin home_position loaded
[ INFO] [1571387963.249683184]: Plugin home_position initialized
[ INFO] [1571387963.249928354]: Plugin imu loaded
[ INFO] [1571387963.263704902]: Plugin imu initialized
[ INFO] [1571387963.263879095]: Plugin landing_target loaded
[ INFO] [1571387963.280729081]: Plugin landing_target initialized
[ INFO] [1571387963.280994006]: Plugin local_position loaded
[ INFO] [1571387963.294512072]: Plugin local_position initialized
[ INFO] [1571387963.294859941]: Plugin log_transfer loaded
[ INFO] [1571387963.304604736]: Plugin log_transfer initialized
[ INFO] [1571387963.304808938]: Plugin manual_control loaded
[ INFO] [1571387963.305552805]: Finished loading Gazebo ROS API Plugin.
[Msg] Waiting for master.
[ INFO] [1571387963.306764187]: waitForService: Service [/gazebo/set_physics_properties] has not been advertised, waiting...
[ INFO] [1571387963.312897452]: Plugin manual_control initialized
[ INFO] [1571387963.313143695]: Plugin mocap_pose_estimate loaded
[Msg] Connected to gazebo master @ http://<IP_ADDRESS>:11345
[Msg] Publicized address: <IP_ADDRESS>
[ INFO] [1571387963.334504127]: Plugin mocap_pose_estimate initialized
[ INFO] [1571387963.334529092]: Finished loading Gazebo ROS API Plugin.
[ INFO] [1571387963.334730878]: Plugin mount_control loaded
[Msg] Waiting for master.
[ INFO] [1571387963.335540459]: waitForService: Service [/gazebo/set_physics_properties] has not been advertised, waiting...
[ INFO] [1571387963.339429825]: Plugin mount_control initialized
[ INFO] [1571387963.339754307]: Plugin obstacle_distance loaded
[ INFO] [1571387963.343573143]: Plugin obstacle_distance initialized
[ INFO] [1571387963.343814833]: Plugin odom loaded
[Msg] Connected to gazebo master @ http://<IP_ADDRESS>:11345
[Msg] Publicized address: <IP_ADDRESS>
[ INFO] [1571387963.357569020]: Plugin odom initialized
[ INFO] [1571387963.357950873]: Plugin param loaded
[ INFO] [1571387963.363141051]: Plugin param initialized
[ INFO] [1571387963.363427879]: Plugin px4flow loaded
[ INFO] [1571387963.379834179]: Plugin px4flow initialized
[ INFO] [1571387963.379883085]: Plugin rangefinder blacklisted
[ INFO] [1571387963.380203986]: Plugin rc_io loaded
[ INFO] [1571387963.386745915]: Plugin rc_io initialized
[ INFO] [1571387963.386792012]: Plugin safety_area blacklisted
[ INFO] [1571387963.387032062]: Plugin setpoint_accel loaded
[ INFO] [1571387963.395093724]: Plugin setpoint_accel initialized
[ INFO] [1571387963.395435091]: Plugin setpoint_attitude loaded
[ INFO] [1571387963.417767032]: Plugin setpoint_attitude initialized
[ INFO] [1571387963.417994343]: Plugin setpoint_position loaded
[ INFO] [1571387963.440428421]: Plugin setpoint_position initialized
[ INFO] [1571387963.440665608]: Plugin setpoint_raw loaded
SpawnModel script started
[ INFO] [1571387963.453856927]: Plugin setpoint_raw initialized
[ INFO] [1571387963.454108343]: Plugin setpoint_velocity loaded
[ INFO] [1571387963.462385436]: Plugin setpoint_velocity initialized
[ INFO] [1571387963.462738506]: Plugin sys_status loaded
[ INFO] [1571387963.474775700]: Plugin sys_status initialized
[ INFO] [1571387963.474931246]: Plugin sys_time loaded
[ INFO] [1571387963.481231422]: TM: Timesync mode: MAVLINK
[ INFO] [1571387963.482522564]: Plugin sys_time initialized
[ INFO] [1571387963.482683313]: Plugin trajectory loaded
[ INFO] [1571387963.489281856]: Plugin trajectory initialized
[ INFO] [1571387963.489483080]: Plugin vfr_hud loaded
[ INFO] [1571387963.490288343]: Plugin vfr_hud initialized
[ INFO] [1571387963.490327831]: Plugin vibration blacklisted
[ INFO] [1571387963.490479730]: Plugin vision_pose_estimate loaded
[ INFO] [1571387963.500996114]: Plugin vision_pose_estimate initialized
[ INFO] [1571387963.501192242]: Plugin vision_speed_estimate loaded
[ INFO] [1571387963.506749120]: Plugin vision_speed_estimate initialized
[ INFO] [1571387963.506986196]: Plugin waypoint loaded
[ INFO] [1571387963.513392588]: Plugin waypoint initialized
[ INFO] [1571387963.513439628]: Plugin wheel_odometry blacklisted
[ INFO] [1571387963.513666539]: Plugin wind_estimation loaded
[ INFO] [1571387963.514632392]: Plugin wind_estimation initialized
[ INFO] [1571387963.514700456]: Autostarting mavlink via USB on PX4
[ INFO] [1571387963.514872936]: Built-in SIMD instructions: SSE, SSE2
[ INFO] [1571387963.514909094]: Built-in MAVLink package version: 2019.9.9
[ INFO] [1571387963.514961223]: Known MAVLink dialects: common ardupilotmega ASLUAV autoquad icarous matrixpilot paparazzi slugs standard uAvionix ualberta
[ INFO] [1571387963.514997654]: MAVROS started. MY ID 1.240, TARGET ID 1.1
[INFO] [1571387963.586990, 0.000000]: Loading model XML from file
[INFO] [1571387963.587357, 0.000000]: Waiting for service /gazebo/spawn_sdf_model
[INFO] [1571387964.193987, 0.000000]: Calling service /gazebo/spawn_sdf_model
[Wrn] [ColladaLoader.cc:1761] Triangle input semantic: 'TEXCOORD' is currently not supported
[Wrn] [ModelDatabase.cc:339] Getting models from[http://gazebosim.org/models/]. This may take a few seconds.
[Err] [InsertModelWidget.cc:298] Missing model.config for model "/home/comac/catkin_ws/src/Firmware/Tools/sitl_gazebo/cmake"
[Err] [InsertModelWidget.cc:298] Missing model.config for model "/home/comac/catkin_ws/src/Firmware/Tools/sitl_gazebo/external"
[Err] [InsertModelWidget.cc:298] Missing model.config for model "/home/comac/catkin_ws/src/Firmware/Tools/sitl_gazebo/include"
[Err] [InsertModelWidget.cc:298] Missing model.config for model "/home/comac/catkin_ws/src/Firmware/Tools/sitl_gazebo/models"
[Err] [InsertModelWidget.cc:298] Missing model.config for model "/home/comac/catkin_ws/src/Firmware/Tools/sitl_gazebo/msgs"
[Err] [InsertModelWidget.cc:298] Missing model.config for model "/home/comac/catkin_ws/src/Firmware/Tools/sitl_gazebo/scripts"
[Err] [InsertModelWidget.cc:298] Missing model.config for model "/home/comac/catkin_ws/src/Firmware/Tools/sitl_gazebo/src"
[Err] [InsertModelWidget.cc:298] Missing model.config for model "/home/comac/catkin_ws/src/Firmware/Tools/sitl_gazebo/worlds"
[Err] [InsertModelWidget.cc:298] Missing model.config for model "/home/comac/.gazebo/models/house_2"
[Err] [InsertModelWidget.cc:298] Missing model.config for model "/home/comac/.gazebo/models/house_2"
[Wrn] [ColladaLoader.cc:1761] Triangle input semantic: 'TEXCOORD' is currently not supported
[Err] [InsertModelWidget.cc:298] Missing model.config for model "/home/comac/.gazebo/models/house_3"
[Err] [InsertModelWidget.cc:298] Missing model.config for model "/home/comac/.gazebo/models/oak_tree"
[Err] [InsertModelWidget.cc:298] Missing model.config for model "/home/comac/.gazebo/models/oak_tree"
[Err] [InsertModelWidget.cc:298] Missing model.config for model "/home/comac/.gazebo/models/apartment"
[INFO] [1571388128.448725, 996.334000]: Spawn status: SpawnModel: Entity pushed to spawn queue, but spawn service timed out waiting for entity to appear in simulation under the name iris_stereo_gray_gps
Warning [parser.cc:778] XML Element[child], child of element[sensor] not defined in SDF. Ignoring[child]. You may have an incorrect SDF file, or an sdformat version that doesn't support this element.
Warning [parser.cc:778] XML Element[parent], child of element[sensor] not defined in SDF. Ignoring[parent]. You may have an incorrect SDF file, or an sdformat version that doesn't support this element.
[Wrn] [msgs.cc:1655] Conversion of sensor type[multicamera] not suppported.
[Wrn] [ColladaLoader.cc:1761] Triangle input semantic: 'TEXCOORD' is currently not supported
[Wrn] [ColladaLoader.cc:1761] Triangle input semantic: 'TEXCOORD' is currently not supported
[vehicle_spawn_comac_HP_Z840_Workstation_19074_939596101739646439-5] process has finished cleanly
log file: /home/comac/.ros/log/c85b50a4-f182-11e9-ac30-44334c49fbe0/vehicle_spawn_comac_HP_Z840_Workstation_19074_939596101739646439-5*.log
[Err] [Plugin.hh:165] Failed to load plugin libgazebo_ros_multicamera.so: libgazebo_ros_multicamera.so: cannot open shared object file: No such file or directory
[Dbg] [gazebo_mavlink_interface.cpp:138] <joint_name> not found for channel[0] no joint control will be performed for this channel.
[Dbg] [gazebo_mavlink_interface.cpp:138] <joint_name> not found for channel[1] no joint control will be performed for this channel.
[Dbg] [gazebo_mavlink_interface.cpp:138] <joint_name> not found for channel[2] no joint control will be performed for this channel.
[Dbg] [gazebo_mavlink_interface.cpp:138] <joint_name> not found for channel[3] no joint control will be performed for this channel.
[Wrn] [gazebo_mavlink_interface.cpp:127] joint [zephyr_delta_wing::propeller_joint] not found for channel[4] no joint control for this channel.
[Wrn] [gazebo_mavlink_interface.cpp:127] joint [zephyr_delta_wing::flap_left_joint] not found for channel[5] no joint control for this channel.
[Wrn] [gazebo_mavlink_interface.cpp:127] joint [zephyr_delta_wing::flap_right_joint] not found for channel[6] no joint control for this channel.
[Dbg] [gazebo_mavlink_interface.cpp:138] <joint_name> not found for channel[7] no joint control will be performed for this channel.
[Msg] Using MAVLink protocol v2.0
[ INFO] [1571388129.001918062,<PHONE_NUMBER>00]: waitForService: Service [/gazebo/set_physics_properties] is now available.
[ INFO] [1571388129.003013744,<PHONE_NUMBER>00]: waitForService: Service [/gazebo/set_physics_properties] is now available.
[ INFO] [1571388129.092667520,<PHONE_NUMBER>00]: Physics dynamic reconfigure ready.
[ INFO] [1571388129.093004609,<PHONE_NUMBER>00]: Physics dynamic reconfigure ready.
[Wrn] [msgs.cc:1655] Conversion of sensor type[multicamera] not suppported.
[Wrn] [Publisher.cc:140] Queue limit reached for topic /gazebo/default/iris_stereo_gray_gps/motors, deleting message. This warning is printed only once.
[Wrn] [Publisher.cc:140] Queue limit reached for topic /gazebo/default/iris_stereo_gray_gps/motor_speed/0, deleting message. This warning is printed only once.
[Wrn] [Publisher.cc:140] Queue limit reached for topic /gazebo/default/iris_stereo_gray_gps/motor_speed/1, deleting message. This warning is printed only once.
[Wrn] [Publisher.cc:140] Queue limit reached for topic /gazebo/default/iris_stereo_gray_gps/motor_speed/2, deleting message. This warning is printed only once.
[Err] [Scene.cc:2927] Light [sun] not found. Use topic ~/factory/light to spawn a new light.
INFO  [simulator] Got initial simulation data, running sim..
INFO  [pwm_out_sim] MODE_16PWM
INFO  [mavlink] mode: Normal, data rate: 4000000 B/s on udp port 14556 remote port 14550
INFO  [mavlink] mode: Onboard, data rate: 4000000 B/s on udp port 14557 remote port 14540
INFO  [mavlink] MAVLink only on localhost (set param MAV_BROADCAST = 1 to enable network)
INFO  [logger] logger started (mode=all)
pxh> INFO  [logger] Start file log
INFO  [logger] Opened log file: rootfs/fs/microsd/log/2019-10-18/08_42_10.ulg
INFO  [mavlink] partner IP: <IP_ADDRESS>
[ INFO] [1571388130.141964259,<PHONE_NUMBER>00]: udp0: Remote address: <IP_ADDRESS>:14557
[ INFO] [1571388130.288733430,<PHONE_NUMBER>00]: IMU: High resolution IMU detected!
INFO  [ecl/EKF] EKF aligned, (pressure height, IMU buf: 22, OBS buf: 14)
[ INFO] [1571388131.049769223,<PHONE_NUMBER>00]: CON: Got HEARTBEAT, connected. FCU: PX4 Autopilot
[ INFO] [1571388131.052932373,<PHONE_NUMBER>00]: IMU: High resolution IMU detected!
[ INFO] [1571388131.195906029,<PHONE_NUMBER>00]: IMU: Attitude quaternion IMU detected!
[Wrn] [Publisher.cc:140] Queue limit reached for topic /gazebo/default/iris_stereo_gray_gps/motor_speed/3, deleting message. This warning is printed only once.
[Wrn] [Publisher.cc:140] Queue limit reached for topic /gazebo/default/iris_stereo_gray_gps/imu, deleting message. This warning is printed only once.
[ INFO] [1571388132.056172691,<PHONE_NUMBER>00]: VER: 1.1: Capabilities         0x000000000000e4ef
[ INFO] [1571388132.056279553,<PHONE_NUMBER>00]: VER: 1.1: Flight software:     010800ff (96443b3cf3e3adae)
[ INFO] [1571388132.056336686,<PHONE_NUMBER>00]: VER: 1.1: Middleware software: 010800ff (96443b3cf3e3adae)
[ INFO] [1571388132.056399223,<PHONE_NUMBER>00]: VER: 1.1: OS software:         040f00ff<PHONE_NUMBER>000000)
[ INFO] [1571388132.056452638,<PHONE_NUMBER>00]: VER: 1.1: Board hardware:      00000001
[ INFO] [1571388132.056526471,<PHONE_NUMBER>00]: VER: 1.1: VID/PID:             0000:0000
[ INFO] [1571388132.056571226,<PHONE_NUMBER>00]: VER: 1.1: UID:<PHONE_NUMBER>000002
[ WARN] [1571388132.104512469,<PHONE_NUMBER>00]: CMD: Unexpected command 520, result 0
INFO  [ecl/EKF] EKF GPS checks passed (WGS-84 origin set)
INFO  [ecl/EKF] EKF commencing GPS fusion
[ INFO] [1571388141.069492081, 1008.390000000]: HP: requesting home position
[ INFO] [1571388146.076236950, 1013.390000000]: WP: mission received
ERROR [mavlink] [timesync] Time jump detected. Resetting time synchroniser.
[ERROR] [1571388255.475664445, 1122.634000000]: TM : Time jump detected. Resetting time synchroniser.
ERROR [mavlink] [timesync] Time jump detected. Resetting time synchroniser.
[ERROR] [1571388488.856532432, 1355.734000000]: TM : Time jump detected. Resetting time synchroniser.
`
I think the reason maybe this
[Err] [Plugin.hh:165] Failed to load plugin libgazebo_ros_multicamera.so: libgazebo_ros_multicamera.so: cannot open shared object file: No such file or directory
But I don't know how to fix it. Can you help me?

Sorry for the late response.
It seems like a misconfiguration of ros-gazebo-pkg, can you try the following command?
sudo apt install ros-kinetic-gazebo-ros-pkgs

thx for your guide. I have fix it. thank you.


Specifying Base Url in ASP.NET Core

I can't seem to see how to set the base url? I want to select only actions in a area at /api but it's picking up actions throughout the rest of my application.
I've looked at the ConfigureSwaggerDocument and ConfigureSwaggerSchema methods but can't seem to see any kinda of setter. Can anyone advise how this can be set?

So, just so I understand your issue fully - do you want to a) set the baseUrl (this tells the swagger-ui the host and port where it can access your API) or do you want to b) limit the operation descriptions that are displayed in your docs. Despite the issue name, I think you might be looking for the latter.
If so, there's a couple of different ways to do this. Probably the easiest would be to restrict the operations that are described by WebAPI's built-in metadata layer - ApiExplorer. The "ApiDescriptions" from there are used by Swashbuckle to generate a corresponding list of Swagger "Operations".
You can use an ApplicationConvention (a framework concept, not SB) to do this and control which controllers or actions should be described through ApiExplorer and hence Swashbuckle:
Startup.cs ...
services.AddSwaggerGen(c =>
{
    ...
});

services.Configure<MvcOptions>(c =>
    c.Conventions.Add(new ApiExplorerVisibilityConvention()));

ApiExplorerVisibilityConvention
public class ApiExplorerConvention : IApplicationModelConvention
{
    public void Apply(ApplicationModel application)
    {
        foreach (var controller in application.Controllers)
        {
            controller.ApiExplorer.IsVisible = (controller.ControllerName == "CrudActions");
            // in this trivial example I'm using controllername, you'll want to look at the metadata available on "controller" and use something more appropriate
        }
    }

Ah ok thanks for clearing that up, you were right I was looking to limit the descriptions that appeared. I had thought that the way to achieve that was to set the baseUrl to mydomain.com/api rather than just mydomain.com; I'll have a crack at restricting the ApiDescriptions as described. Cheers


Very slow typing with large amounts of mathjax in document

I love classeur, but for some reason it takes forever to type and update if I have a lot of math in the document, is this a known issue. If so will it ever be fixed? Its important that I can take my notes in math class and I really cannot be slowing down to wait for the UI to become responsive.
Regards,

Dear @asleepinthetrees,
Thank you for your report.
Can you please share the content of an example document with us so that we can try to reproduce the problem?
Thankfully,
-Robert

I've seen large documents that take a bit of time to render. However it should be fast once all the math expressions have been rendered (maybe 30 sec/1 min after opening the file).
Let me know if it doesn't.

Same problem if there many math equations to render.


fix git clone non-root permission issues

Fixes issue: https://github.com/buildsec/frsca/issues/396
Adds proper fsGroup permission for git-clone task.

@sudo-bmitch this will fix that issue with permission we saw a while back.


Consolidate framework dates in the content repo

Dates consistently change between frameworks. This moves all dates into
the digitalmarketplace-frameworks repo as messages. Ultimately it would
be good if these were stored in the API against a framework. However,
until we have a clear understanding of what dates are required, what
they mean, and how we want to manage them consolidating them in one
place is a good first step.

:+1:


Add documentation to EditorExportPlatformWeb

This PR fills in the class reference of EditorExportPlatformWeb. Yeah.
This also has the side-effect of displaying them when hovering over the settings in the Export window, which is really, really good:

Would be nice to get some feedback on factual correctness, sooner than later.

Sidenote, isn't it funny that html/experimental_virtual_keyboard has been "experimental" for 2 years? What a funny setting name.

Addressed all of the above feedback.

Thanks!


Long polling in Service Bus topics?

Hi,
Could you clarify if SB supports long polling with topics the same way it does with queues? That way clients subscribing to topics are not manually polling the topic for new messages.
The doc is hosted here: https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dotnet-how-to-use-topics-subscriptions

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

ID: 443c9051-c55e-1202-7b75-ce86f6977017
Version Independent ID: 677b6375-196f-fed8-7300-b9823c1031d5
Content: Get started with Azure Service Bus topics and subscriptions
Content Source: articles/service-bus-messaging/service-bus-dotnet-how-to-use-topics-subscriptions.md
Service: service-bus-messaging
GitHub Login: @axisc
Microsoft Alias: aschhab

Hi @Infinitism - Thank you for your feedback! We will review and update as appropriate.

@axisc / @clemensv can you share your thoughts here ?

The sample @Infinitism points to is using our SDK with a callback registration for the receive side, and that makes it -- by design -- entirely moot to debate whether there is "long polling", because the implementation hides the acquisition details completely.
That said, when using AMQP, which is the default protocol, messages are acquired over a stateful protocol and with a credit-based flow. "Long polling" implies that there is a request and the response is being waited for for an extended period of time, and that's never the case in AMQP.  See Flow Control in the AMQP spec.
This issue should be closed without action. Nevertheless, thank you very much for the feedback and contribution, @Infinitism.

@Infinitism We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Switch linting to standard

I too would like to use standard as my comrads, please @HugoGiraudel ;)

Done in #16


Update lgssm filtering output and port lgssm demos from JSL.

LGSSM Filtering Output
The function lgssm.inference.lgssm_filter is updated to return as LGSSMPosterior object to match the behaviour of lgssm.inference.lgssm_smoother.
The LGSSMPosterior dataclass is updated to allow so that it can be instantiated without values from the smoothing posterior.
Instances of the use of the filtering function have been updated to work with the new output.
There are also some changes to the docstrings in lgssm/inference.py to be more informative and to standardise formatting a bit.

LGSSM Inference Test
The test in lgssm/inference_test.py is updated to use a more rigorous dynamical system and to remove unnecessary additional calls to lgssm_filter which is called in LinearGaussianSSM.smoother().

LGSSM Demos
The kf_tracking.py demo is updated, and the kf_spiral.py and kf_parallel.py demos are ported from JSL as mentioned in issue #6.
A preliminary step towards making a simple test for these demos is made by separating inference and plotting into different functions.
Further, a number of plotting tools are added to ssm_jax/misc/plot_utils.py.

Also rename marginal_loglkhd to marginal_loglik in LGSSM code as per issue #6.
(Although it still needs to be done in the HMM code).

This is great!


Missing metadata support for metadata type customindex?

Describe the bug
When running the deploy_unmanaged_ee flow against a persistent org and the src folder is created, the error is raised: No parser configuration found for subdirectory customindex.  Seems that CumulusCI doesn't (yet?) support that metadata type. However, as we have multiple custom fields that are marked as external IDs Salesforce change tracking seems to want to pull these into source, so we have done so thus far.
Reproduction steps

Clone this repo and move to this branch
Run the flow client_org against a persistent org that already has NPSP installed (or possibly even a scratch org... haven't tried).
Error should occur during the update_package_xml phase of deploy_unmanaged_ee.

Your CumulusCI and Python versions
CumulusCI version: 3.66.0 (/Users/matthewmartin/.local/bin/cci)
Python version: 3.10.4 (/Users/matthewmartin/.local/pipx/venvs/cumulusci/bin/python)
Operating System
Macbook Pro, macOS Monterrey, Apple M1 Pro
Windows environment
No response
CumulusCI installation method
pipx
Error Gist
https://gist.github.com/mattmartin26/e1a4174acf5478db4a70c6cc6a2d8e28
Additional information
SFDC Articles on Custom Indexes

Improve Performance of SOQL Queries using a Custom Index
Metadata API Developer Guide: Indexes

Thanks for the report. We'll have a fix out in the next release.

@mattmartin26 There's a fix in review, but I wanted to bring this Known Issue to your attention. There are also reports that there are issues related to packaging.
FYI: You can try excluding any problematic components by adding them to your .forceignore file.

Thanks for the updates @jstvz !


Patch style bugs

Hello @justinwhall,Thanks again for the PR! We appreciate your contribution and look forward to                                              continued collaboration. Thanks!                                             Team SendGrid DX


Stuck Cluster - Removing Waiting For Machine

Setup

Rancher version: 2.7.1
Browser type & version: Chrome, Version 109.0.5414.120 (Official Build) (64-bit)

Describe the bug
Removed VMs from VMware, but now Rancher is stuck trying to delete cluster with status "Removing Waiting For Machine"
To Reproduce
Remove VMs in vCenter before trying to delete from Rancher first.
Result
Expected Result
I expected the clusters page to only show Active clusters and not leftovers from clusters which I've removed the VMs from in VMware.
Screenshots

Additional context
I removed them from VMware first because the nodes weren't connected with an IP; therefore, Rancher was not able to remove the cluster from the UI with them not being reachable.

@richard-cox Let me try that and thanks for your help.

Anyone that comes across this, I found a temporary solution:
https://github.com/rancher/rancher/issues/34650
kubectl -n fleet-default get clusters.provisioning.cattle.io # find the name of the cluster you want to delete
kubectl -n fleet-default patch clusters.provisioning.cattle.io <cluster_name> -p '{"metadata":{"finalizers":[]}}' --type=merge
kubectl -n fleet-default delete clusters.provisioning.cattle.io <cluster_name>


Layers panel doesn't scroll when many layers exist

What happened:
When many layers exist, the top panel shows only few(9 in my case)
when pressing down arrow, the Layers panel will mark the current layer until I reach the 9th, aftwer that the marker disappears and don't sow the currently marked command.
The layer details panel on the other hand, shows the correct layer.
So the layer is selected but not shown in the Layers panel, only in layers details panel.
What you expected to happen:
I would expect the top Layers panel to scroll and mark the selected layer
How to reproduce it (as minimally and precisely as possible):
Create a docker image with many layers (depends on screen, but I guess 15 -20)
inspect the image.
Try to select the last layer.
Anything else we need to know?:
Environment:

Ubuntu 22.04.4 (I'm using the docker installation docker run -ti --rm  -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive")
Docker version (if applicable): Docker version 27.0.3, build 7d4bcd8

Please build https://github.com/wagoodman/dive/pull/473 from source to fix it.

Duplicate of #494 and #469, possibly fixed in #473.


Setup experimental ML instance on AWS

Since we will host our machine learning infrastructure on AWS, it is important to get familiar with the platform.
For that purpose a simple (dummy) ML instance can be set up, as learning by doing does usually work best.

As we did not have full AWS access at the time, this item could not be fully completed.
However, several meaningful insights have been gained by experimenting with a free AWS instance.


Sizing of dialogs

I followed directions to change the dimensions of the dialog by changing the following style in site.less file. My changes do not have effect on changing the size of dialog box. I don't even see this style when inspecting the element. Many thanks in advance for pointing me in the right direction.
.s-ComplaintAttachmentDialog {
> .size { .widthAndMin(350px); }
.dialog-styles(@h: 560px, @l: 150px, @e: 400px);
.s-PropertyGrid .categories { height: 560px; }
}

Hi,
It appears that your class selector for the dialog should be something like .s-Complaint-AttachmentDialog
Take a look at the class that directly precedes s-Complaints-Complaint-AttachmentDialog in the class for the div.
David

The complete class is "ui-dialog ui-widget ui-widget-content ui-corner-all ui-front s-Dialog s-AttachmentDialog s-Complaints-Complaint-AttachmentDialog ui-draggable"
The "s-AttachmentDialog" and "s-Complaints-Complaint-AttachmentDialog" are not defined anywhere I can find.
Is there any other place besides site.less to look for these?

I know that I can just rename the class in site.less  to "s-AttachmentDialog" but I am wondering how these were generated and why the name went out of sync.

They are generated from namespace and class name putting dashes instead of dots. Prefer s-Module-ClassName version.

Looks like class "s-ComplaintAttachmentDialog" was generated but "s-Complaints-Complaint-AttachmentDialog" was actually used on the page. I was hoping to find a template that has the reference to "s-Complaints-Complaint-AttachmentDialog" but I cannot - it's probably dynamic. How are the css class names attached to dialogs at runtime?

As i explained in prior message its generated from your dialog class name and namespace. What is your dialog class name and namespace

I guess its AttachmentDialog, and module is Complaint, and solution name is Complaints.
So your dialog has following classes:
s-AttachmentDialog
s-Complaint-AttachmentDialog
s-Complaints-Complaint-AttachmentDialog
I have no idea how you got .s-ComplaintAttachmentDialog unless you manually write it or changed dialog class name later.

Yes, I manually created ComplaintAttachmentDialog class. So, I guess, css will not be generated for manually created classes. Thanks.


Sort out our handling of London/UTC dates

~This is a linking ticket for some ongoing refactoring work to reduce or remove our dependency on Moment, which is quite overpowered for what we're doing and a significant chunk of our bundle size.~
I'm rescoping this to cover the broader problem of "how do we do dates".

Alex says good enough for now.


Move converter to Apollo client

Part of master ticket #214

[ ] Merge :apollo-converter into :apollo-runtime.
[ ] Rename Apollo to ApolloClient
[ ] Change ApolloClient initialization to accept user OkHttpClient instead Retrofit
[ ] Add graphql server endpoint as a parameter to ApolloClient initialization
[ ] Introduce API calls to perform query execution in ApolloClient:

void fetch(Query, Callback<Operation.Data>) - async (aligned with iOS API)
void fetch(Query, Callback<Operation.Data>, Handler callbackHandler) - async (aligned with iOS API)
void perform(Mutation, Callback<Operation.Data>) - async (aligned with iOS API)
void perform(Mutation, Callback<Operation.Data>, Handler callbackHandler) - async (aligned with iOS API)
Operation.Data execute(Operation) - sync (this call user can wrap with Rx)

[ ] Merge logic from ApolloRequestBodyConverter and ApolloResponseBodyConverter into ApolloClient

Have you given thought to how async will work? Will apollo make a thread?  If so we should allow user to pass in their own executor.

Also if you make fetch with callback void, you won't have a way to prevent memory leak.  Ideally you need to return a subscription or disposable or something similar to allow user to cancel which would drop callback reference


Consider how to test GNOME roles

I possibly can just add another Travis CI job for all the GNOME make targets

Implemented by https://github.com/iancleary/personal-ansible/pull/86
Travis-CI probably uses a desktop iso, but the only difference is missing packages (relative to the desktop iso), so let's install them in .travis.tml.
- sudo apt install -y gnome-shell gnome
- sudo apt install -y dconf-gsettings-backend dconf-tools dconf-cli
- sudo apt install -y gsettings-desktop-schemas


Opening sound options in the instrument test tab makes it stop working

Ran into this minor issue while poking around and making sure some edits I made were working correctly. Reproduction steps:

Open an EarthBound ROM
Choose a song
Go to the "Instruments" tab and choose an instrument. I chose "Hospital" and selected instrument 18 (the noise instrument).
Click around or press the relevant keyboard keys to play notes. Observe that it works correctly.
Go to Options --> Sound options in the menu bar at the top
Without changing anything, click Cancel
Click around now again. No notes make sound.
Try switching to a different instrument. Now the instrument test rectangle stops responding to user input, until you switch to another tab and back.

This issue seems fixed with PR #53 so I'm closing it.


Travis: generate code coverage statistics

We could use coveralls to report test coverage. It has a good Github integration.

I'd prefer we use Codecov...or Codacy ... both free for open source projects
https://github.com/marketplace/codecov
https://github.com/marketplace/codacy
Codacy has a nicer view even for pull requests.

@thadguidry yeah any of these would do - the hard part is generating the coverage data in Travis. It looks like we have to migrate to Maven first (#1054 should help).

@wetneb Just use Gradle instead.  I've done the work already.  You can add anything else you need into the build.gradle file on our work in progress branch.  Then pull over what we need into master branch from it.
https://github.com/OpenRefine/OpenRefine/tree/java8-refactor

@thadguidry awesome!

@wetneb yeah, so we are already "gradleized" in the java8-refactor branch...

This is solved!

@wetneb sweet ! and looks like we now have the 2 new badge icons that are clickable on the main Github project page https://github.com/OpenRefine/OpenRefine
build passing Codacy B coverage 20% Bountysource $150 in 1 bounty


Regression: Sidebar doesn't remember that it was open before exiting

When the sidebar is open and Nuvola exits, the sidebar should open automatically when Nuvola is launched again.

Fix released in Nuvola 4.16.19-g31510b8.


Can you provide the whl of CUDAv11.8?

Try to build the whl of CUDAv11.8, but always report an error. Can you provide the whl of CUDAv11.8.
Building wheels for collected packages: exllama
Building wheel for exllama (setup.py) ... error
error: subprocess-exited-with-error
× python setup.py bdist_wheel did not run successfully.
│ exit code: 1
╰─> [1544 lines of output]

Done: https://github.com/jllllll/exllama/releases/latest


Revert "Update dependencies"

Reverts GreenImp/rpg-dice-roller#44
This included features from the ES6 port branch which were not meant to be included

I was wrong, this doesn't included the ES6 changes. I'm rejecting this pull request.


NewPullRequesting

Description

A clear and concise summary of the change and which issue (if any) it fixes. Should also include relevant motivation and context.
Resolved or fixed issue:
Affirmation

[ ] My code follows the CONTRIBUTING.md guidelines

New pull requesting


Just Plain Confusion (I Have A Simple Fix For This Though)

The Actual Module Doesn't Work.
This Is Because In The init.py File In The Main GeometryPy File In All Of The Commands You Have Structured It As For Example: "result = GDPyCommands.GetUserInfo(accID, PrintReturn)" Which Will Return The Error: "TypeError: GetUserInfo() takes 1 positional argument but 2 were given".
To Fix This All You Need To Do Is Remove The "PrintReturn" In the Arguments And The Commands Work Again.
I Have Tried Doing This And The Module Works For Me.
Thanks For Reading.
And BTW, I Love This Module, Thanks For Making It.

Hello stshrewsburyDev!
 The old functions had a "PrintReturn" parameter but i forgot to remove it in the main file, i'm going to update it right now.
Thanks for making this issue, have a good day!
(I'm happy that you like this module ^^)


Support for SSD1326

No, SSD1326 is not presently supported, only because we do not have a device to test against. If you (or anyone else) wants to fund or donate/loan a display to add support for this device please get in touch.

why close this?


Pr with issues

SonarQube analysis reported 2 issues

 2 major

Watch the comments in this conversation to review them.


Out-of-order function triggers result in data inconsistency between Firestore -> Typesense

Description
As noted in the Firebase functions documentation, background function triggers are not guaranteed to be received in the order the changes occured.
When rapid changes occur in the database, out-of-order events will result in out-of-order processing, meaning Typesense can end up with stale data in it which is not consistent with the final Firestore resting state after the influx of changes.
From all of the reading I've done, it is a fools-errand to try and fight the system to process them in order -- nevertheless without a solution, extensions like this are difficult to use in production environments.
Steps to reproduce

Write a demo script / perform an app action rapidly that writes to the database
Observe that the events are received out of order
Quite often, this will result in Firestore containing the wrong data from an old event

Expected Behavior
Regardless of the order the events are received, only events newer than the last-processed event should be processed.
Actual Behavior
Inconsistent data in Typesense
Other Findings / Info
In trying to solve for this, I've attempted to use a Firestore collection to "lock" the item being updated, send to Typesense, and then unlock for future events after writing event context back to the lock endpoint.
Simplified example (RTDB trigger used here, but Firestore is affected by this as well):
.database.ref(`tasks/{itemId}`)
.onWrite(async (change, context) => {
  /**
   * We use a Firestore transaction to create a "lock" at a DB location
   * for a given `itemId`
   */
    const { timestamp, eventId } = context;
    const { itemId } = context.params;
    const timestampRef = firestore
      .collection(`typesenseLocks_tasks`)
      .doc(itemId);
    await admin.firestore().runTransaction(async transaction => {
      const dataChangedTimestamp = new Date(timestamp).getTime();
      const lastUpdatedTimestampDoc = await transaction.get(timestampRef);
      const lastUpdatedData = lastUpdatedTimestampDoc.data();

      /**
       * If this is the first time this document was changed (no previous locks),
       * or the last-stored lock timestamp is older than the current event's timestamp,
       * prepare a payload and send to Typesense.
       */
      if (
        (!lastUpdatedData?.timestamp ||
          dataChangedTimestamp > lastUpdatedData.timestamp) &&
        lastUpdatedData?.eventId !== eventId
      ) {
        // Send to Typesense
        await updateTypesense(change, indexer, itemId);

        // Finalize Transaction by writing the event timestamp and eventId back to Firestore for comparison by the next events
        transaction.set(timestampRef, {
          timestamp: dataChangedTimestamp,
          eventId
        });
      } else {
        /**
         * Do nothing, current event is older than last-indexed event already recorded, can be safely discarded
         */
      }
    });

In an attempt to fix this, I've tried moving the await updateTypesense(change, indexer, itemId); line inside and outside of the transaction function block, but in both scenarios stale data ends up inside Typesense.
From logs I've added, the above transaction appears to work, old events are dropped if a newer one has already been processed. But if two events that are extremely close together are processed in the correct order, Typesense occasionally ends up with the first event's payload.
This led me to believe that perhaps Typesense was parallelizing indexing operations, but since they are confirmed as serialized, I'm back at square one.
Metadata
Typsense Version: v0.23
OS: Typesense Cloud
Relevant Slack Thread: https://typesense-community.slack.com/archives/C01P749MET0/p1655047418496499

Thank you for documenting this Ross!
Summarizing our additional discussions on Slack:
One potential solution to this could be to query Firestore on each change trigger and push the latest version of the Firestore document to Typesense, instead of using the snapshot document from the event (which is what could be stale based on the order of execution of events of the change triggers).
Also, to avoid redundant calls to Typesense when changes occur in quick succession, as an optimization we could have a way to store the last updated timestamp in a "sync_state" Firestore collection for each document... Thing to consider with this is the $ cost of maintaining another Firestore collection.

Proposed Solution
Add a query firestore instead of using event payload flag in the config (exact name tbd).
Enabling this flag would do as @jasonbosco described above and read directly from Firestore, ensuring the latest data is pulled. This option would mean consistent syncs at the cost of extra queries. Exposing this as a config option lets users determine if the tradeoff is worthwhile to them.

Created a PR #42 for this suggested change. It's a starting point and is shamefully untested.

@OrionReed Thank you for PR #42!
I've published the change in this RC release: v1.0.0-rc.3.
Could you visit the link above and use the installation link under "Installation Instructions" and let me know how it goes?

Switched over today, I'll report back with any problems after I let it run for a few days


Enforcing number of connected components

Great work! How do I use this to have the network output $k$ number of connected components?
Thanks.

@IssamLaradji this package doesn't enforce hard constraints such as exactly $k$ connected components but you can add a penalty on more than $k$ components, which will (hopefully) encourage at most that many components to form during optimization.
Assuming you know which filtration you're using, right now, the easiest function to use on a persistence diagram is PartialSumBarcodeLengths
https://github.com/bruel-gabrielsson/TopologyLayer#partialsumbarcodelengths
Connected components is in dimension zero, and the infinite length bar is automatically ignored, so you would modify the example in the README to be
feat = PartialSumBarcodeLengths(dim=0, skip=(k-1))

If you want a different type of penalty (e.g. L2 type penalty instead of L1) you can always write a custom class that does exactly what you want.  To get started, you can see how the PartialSumBarcodeLengths is defined and modify from there: https://github.com/bruel-gabrielsson/TopologyLayer/blob/master/topologylayer/nn/features.py#L153
Does this answer your question?

Oh this is great, it's working for me! Another related question, which layer should I use to get  dgminfo? I see LevelSetLayer2D, AlphaLayer, RipsLayer, but I don't get how they are different, thanks!

LevelSetLayer2D is for levelset filtration on a 2d grid, like a grayscale image (our paper have several examples). AlphaLayer and RipsLayer are a little bit similar and AlphaLayer can be thought of as the restriction of the Rips complex to the Delaunay Triangulation of the space. For understanding Rips filtration, check out Wikipedia or Google "Rips filtration" to read more. Does this help?


Livechat and desktop notifications not working on Mac OS

My Setup

Operating System: MacOs 10.12.6

App Version: 2.9

[x] I have tested with the latest version

[x] I can simulate the issue easily

Current Behavior
When a new live chat on on of our sites is initiated, there is no notification of this fact.
Expected Behavior
I would like to get notified when a new live chat is being initiated, so I can respond immediately and not lose that conversation.

Same on my macbook.

Please test if the problem persists with our latest release. I will be closing the issue but if there is any problem yet, we will open it again.


Problem with video uploading

This is an error I get when I try to upload a video. Image uploading works fine, I tried different 3 different videos and all they gave same error. What may cause this error?

Exception in thread "Thread-18" java.lang.IllegalStateException: Failed uploading video (400): Something is wrong. Please check your input and try again.
at org.brunocvcunha.instagram4j.requests.internal.InstagramUploadVideoJobRequest.execute(InstagramUploadVideoJobRequest.java:121)
at org.brunocvcunha.instagram4j.requests.internal.InstagramUploadVideoJobRequest.execute(InstagramUploadVideoJobRequest.java:41)
at org.brunocvcunha.instagram4j.Instagram4j.sendRequest(Instagram4j.java:281)
at org.brunocvcunha.instagram4j.requests.InstagramUploadVideoRequest.execute(InstagramUploadVideoRequest.java:101)
at org.brunocvcunha.instagram4j.requests.InstagramUploadVideoRequest.execute(InstagramUploadVideoRequest.java:52)
at org.brunocvcunha.instagram4j.Instagram4j.sendRequest(Instagram4j.java:281)
at App.APIClasses.Instagram.postVideo(Instagram.java:53)
at App.UIControllers.Controller.lambda$initialize$3(Controller.java:102)
at java.base/java.lang.Thread.run(Thread.java:834)

I have the same message "Something is wrong. Please check your input and try again." when uploading images.

Problem with Photo Upload
019-10-31 08:49:50 [main] INFO  org.brunocvcunha.instagram4j.Instagram4j  - Sending request: org.brunocvcunha.instagram4j.requests.InstagramUploadPhotoRequest
2019-10-31 08:49:50 [main] INFO  org.brunocvcunha.instagram4j.requests.InstagramUploadPhotoRequest  - URL Upload: https://i.instagram.com/api/v1/upload/photo/
2019-10-31 08:49:51 [main] INFO  org.brunocvcunha.instagram4j.requests.InstagramUploadPhotoRequest  - Photo Upload result: 400, Something is wrong. Please check your input and try again.
2019-10-31 08:49:51 [main] INFO  org.brunocvcunha.instagram4j.requests.InstagramRequest  - Reading InstagramConfigurePhotoResult from Something is wrong. Please check your input and try again.

Yea, I'm getting that too now (with images).

It worked now, I don't know why :D

News about what happened?  I'm still getting this error :(

same, have this error since today

Addressed in rewrite or no longer relevant.


Proposal: Native Roaring Bitmap support in LSM Store for faster large-scale filters

Motivation
When the current setup around the inverted index (and the LSM store that powers it) was designed in 2020, a large dataset for Weaviate would have been in the single digit or tens of millions. Today we have billion-scale datasets, and the inverted index can't always keep up. As a simple example, building a pre-filter inverted allow list that matches 80M object ids can take anywhere between 5-10s.
Bandaids
After an initial investigation over the past few days, optimizations could gain us anywhere from 10-30% improvements. It's unlikely that we can optimize the current setup to achieve sub-100ms latencies for a filter matching 100s of millions of objects.
Forward-looking
Instead, I propose something more drastic; to extend the LSM store to support data structures that can natively deal with these sizes. Because we have 100% control over the internals of our LSM store, we have the opportunity to do something novel here that no other mainstream solution does.
Proposal
I hereby propose to extend the LSMStore with a fourth type; RoaringSet. A RoaringSet generally behaves similar to the existing Set type in that it can pe partially written, including updates and deletes, can get merged during compactions, etc. The significant differences to the existing Set types are:

Instead of allowing arbitrary content in the Set, the RoaringSet is limited to uint64s.
Both the interfaces of the new bucket, as well as the internals make use of Roaring Bitmaps.

What this proposal is not

This proposal does not convert posting lists to a roaring bitmap at query time (and/or cache those subsequently). Based on my current understanding, this is what Lucene does. While a cached request would be fast, a previously unseen filter combination would be slow. Therefore our proposal should allow for much higher throughput on large-scale filter situations
This proposal is not to store a Roaring Bitmap in a regular LSM tree bucket. This would not achieve the same goals as updates would be very expensive. For an update, you would have to do a read-modify-write query. Instead, with native support, writing in the LSM-typical append-only fashion is supported and extremely fast.

Expected Benefits

In a fully compacted state, building an allow list containing 100M items should take single-digit milliseconds. (Verified here). This speed-up is primarily due to the omission of a decoding step at query time. Instead, we need to copy ~10MB of memory for 80M hits. This takes 1-2ms depending on GC pressure, etc.
Even in a suboptimal compaction state (which is temporary), building such a filter should typically take <100ms. This is because ANDing and ORing already initialized roaring bitmaps is very fast. (Verified here that merging two 80M bitmaps takes anywhere between 4 to 8ms).
This proposal does not change the HNSW graph traversal. The time for the vector search depends on various factors, including the percentage of dataset matched in the filter. However, our current investigation shows that this part is not the bottleneck, it's building the allow list, which happens first.

Limitations of this proposal

This proposal only focuses on RoaringSet as an alternative to Set. This means Map would still have the old logic for now. As a result only filters for data types bool, int, float ,etc. would be sped up. Filters for text and string would not yet benefit from this proposal. However, once complete, I believe the same can be applied for maps, and we could introduce a RoaringMap LSM type. This comes with a few other challenges, but we can cross this bridge when we get there.
The data structure on disk will change. We can build this in a fully backward-compatible fashion so the change is not breaking. However, to benefit from the new structure a reindex is necessary. Since Weaviate does not yet have a Reindex API, this would have to be done using some one-off migration at startup time.

Work involved
srbm = serialized roaring bitmap, e.g. dgraph-io/sroar
The following is a rough outline of what would have to happen to make this a reality:

[ ] inside lsmkv.Store

[x] add a BST (red-black) that uses srbms natively
[x] add memtable that uses the above BST
[x] flush memtable to disk
[ ] add commit log and commit log recovery options
[x] support querying across memtables and disk segment (read time merge)
[ ] support compactions
[ ] support cursors

[ ] in inverted.Searcher

[ ] support dynamically switching  between Set and RoaringSet for backward compat
[ ] restructure propValuePairs to natively use srbms
[ ] when merging filters, use srbm bitwise operations
[ ] add workaround for combining filters of Map and Set types which would use different posting list types

[ ] in hnsw.HNSW
[ ] in db.Shard

[ ] bump shard version for backward compat
[ ] add migration at startup option

[ ] large-scale stress testing

Proposal is considered accepted, will be part of v1.18.

Released in v1.18.


[Extensions] Inclusion Of Environments and Workspaces in meshmap

Current Behavior

Desired Behavior

Implementation

Acceptance Tests

Mockups

Contributor Guides and Handbook

📚 Meshery Build and Release Strategy
🎨 UI Design For Meshery Extensions Figma in Figma (open invite)
📚 Meshery Extensibility Providers
⌨ Meshery API Docs
🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack

@ritiksaxena124  please attach the  accepted mockups and any additional info here

Mockup link. How it should work is written below the mockup


List storage, modification and management

Ability to add new lists to store, add items, edit and delete items, share and stuff

I actually plan on moving this to the diaryapp project instead.


Issue #6999: read zlib checksum before checking bytes read.

Fixes #6999

This looks good to me, thanks @walshb! I'll leave it open for a bit in case @matthew-brett wants to have a peek.

LGTM, merged. Thanks @walshb!


perf: improve startup time

By now, packer_compiled.lua is too big, which is the cause of the slow startup time. So the correct solution should be to move configs into separate files.

Also lazy-loading etc is important.
ref: numToStr/dotfiles#10


weldr api delayed response after first /compose call

As part of releasing cockpit-composer to f35/36 it became apparent that the api calls following the first /compose call are delayed. After the POST /compose call there is a long delay and then next expected calls/response suddenly all submit (We receive multiple status responses at once).

Ah, is this the first request sent after rebooting the system? If that's the case it is probably downloading new dnf metadata. We've discussed ways to fix that in #2887 (basically do a depsolve on startup to preload the metadata cache).

The startup metadata preload added in #2941 has a little nasty side-effect: because it uses the same base solver to depsolve for all distros, they all share the same top-level cache, which dnf locks, so they're essentially running in order.
This isn't an issue when no depsolve is needed immediately after starting composer but, if it is, it will block waiting for the preload, which can take minutes.
We could create a separate solver for each distro in the registry, with its own cache as a subdirectory of the main cache dir.  I'm not sure what the memory load of that would be, given how much we cache in memory for each solver instance.  It might also be a bit "wasteful" depending on how much users do cross-distro builds.
Maybe we can instead only preload the host distro?

See #3317 for a possible solution to this.


[Monorepo Split Github Actions] [Question] access token requirements

My github actions are failing on pushing the final commit:
[NOTE] Pushing git commit

fatal: could not read Username for 'https://github.com': No such device or address

So it does pull the code and I see it creates a local commit with the new files. But pushing it fails.
As it's a private repo and the GA log shows the test file on the target repo that is to be deleted it means I at least have read access to that repo.
So I'm assuming my access token is not good, can you elaborate on how to set or check?
My yaml code is just copied and pasted:
env:
  GITHUB_TOKEN: ${{ secrets.ACCESS_TOKEN }}

my user-name and user-mail are the same as my standard commits, so assuming those are good

Hi,
this is how you add secret to repository: https://docs.github.com/en/actions/reference/encrypted-secrets#creating-encrypted-secrets-for-a-repository
I tested split only on public repositories, so there might be needed some extra security hacking. Not sure how Github Actions differ on private repositories.

Hi,
this is how you add secret to repository: https://docs.github.com/en/actions/reference/encrypted-secrets#creating-encrypted-secrets-for-a-repository
I tested split only on public repositories, so there might be needed some extra security hacking. Not sure how Github Actions differ on private repositories.


__emplace_back still causes compilation issues on m1

Hi y'all,
I'm running clang 14.0.3 on m1 pro, and instillation fails because of a compilation error in:
lzero/mcts/ctree/ctree_sampled_efficientzero/lib/cnode.cpp
specifically line 384:
disc_action_with_probs.__emplace_back(std::make_pair(iter, disturbed_probs[iter]));
When i remove the dunder from emplace_back everything is happy and works fine. Working line:
disc_action_with_probs.emplace_back(std::make_pair(iter, disturbed_probs[iter]));
Details:
2021 M1 Pro
MacOS 13.4.1
Apple clang version 14.0.3 (clang-14<IP_ADDRESS>.1)

Hello,
We have chosen to use emplace_back instead of push_back because it is more efficient in terms of implementation. However, in our actual implementation, we have been using __emplace_back due to our testing environment being macOS clang-13<IP_ADDRESS>.3. We plan to conduct tests on the latest version of clang, and if emplace_back works without any issues, we will update the installation instructions to specify the required clang version.
Thank you very much for your advice and support.


Turn off update_on_init for special model nodes

The adoption of #92 caused warnings to be logged by default during model initialization, because the special nodes for the log likelihood and log probability cannot always be updated directly on their initialization. This PR just sets update_on_init=False for these nodes, which solves the issue.

Makes sense


Includes version in API query

The API now needs a version specified. 2.1 is the newest version and
works with our client > https://npiregistry.cms.hhs.gov/registry/help-api

Once this is merged, I will create a bundle update PR for the Silversheet app.
If you'd like to test, you can pull this branch locally, and change your Silversheet gem file to point at the path of this repo. Then try and search for a provider to add from a facility account.

LGTM


Enhance KubeVirtNodeDriver Compute Driver

Enhance KubeVirtNodeDriver Compute Driver
Description
This pull request brings several improvements to the create_node method and related functions within the KubeVirtNodeDriver (libcloud/compute/drivers/kubevirt.py).
Features added to KubeVirtNodeDriver.create_node:

Improved compatibility with the base NodeDriver class:

Added support for the size: NodeSize parameter, while retaining legacy compatibility with ex_cpu and ex_memory.
Added support for the auth: NodeAuthSSHKey|NodeAuthPassword parameter.

Support for deployment (deploy_node):

KubeVirtNodeDriver now supports node deployment automatically, benefiting from the above compatibility changes.

Support for general volume (disks) types that KubeVirt supports:

(==Breaking change==) Modified the content of the ex_disks parameter to align with the related KubeVirt API, making it compatible with any volume types rather than hardcoded support for limited volume or disk types (previously only persistentVolumeClaim was supported).

Added support for the ex_template parameter, allowing users to customize the entire Kubernetes object declaring the virtual machine. This is particularly useful for:

Supporting advanced configurations not covered by other parameters.
Facilitating the reuse of existing virtual machine configurations.

Fixes:

_to_node: Improved the logic for parsing memory, eliminating crashes on virtual machines with more than 1 GiB RAM.
create_node: (==Breaking change==) Renamed the parameter from ports to ex_ports.
Addressed various bugs in the create_node method, which were eliminated during the refactor and implementation of new features.

Other Changes:

libcloud/compute/drivers/kubevirt.py:

Added a KubeVirtNodeSize function to assist in constructing NodeSize instances for KubeVirtNodeDriver.
Introduced a KubeVirtNodeImage function to help construct NodeImage instances for KubeVirtNodeDriver.
Code reorganization: Moved DISK_TYPES out of the create_node and exported it, enabling users to access a list of supported disk types.
Updated docstrings for new features, adhering to sphinx grammar standards.

libcloud/test/compute/test_kubevirt.py:

Introduced tests for the create_node method: This method was not tested previously.

Status

done, ready for review

Checklist (tick everything that applies)

[x] Code linting (required, can be done after the PR checks)
[x] Documentation
[x] Tests
[ ] ICLA (required for bigger changes)

would you mind documenting breaking changes (disks, ports) in docs/upgrades_notes.rst?

Sure, I will add it recently.

Codecov Report
Attention: Patch coverage is 36.79245% with 134 lines in your changes are missing coverage. Please review.

Project coverage is 83.25%. Comparing base (ee7768f) to head (1874bb7).
Report is 3 commits behind head on trunk.

Additional details and impacted files
@@            Coverage Diff             @@
##            trunk    #1983      +/-   ##
==========================================
- Coverage   83.26%   83.25%   -0.00%
==========================================
  Files         353      353
  Lines       81305    81445     +140
  Branches     8565     8606      +41
==========================================
+ Hits        67692    67807     +115
+ Misses      10823    10814       -9
- Partials     2790     2824      +34

Files
Coverage Δ

libcloud/test/compute/test_kubevirt.py
71.43% <80.00%> (+4.76%)
:arrow_up:

libcloud/compute/drivers/kubevirt.py
32.81% <32.29%> (+9.85%)
:arrow_up:

@cdfmlr Thanks.
I had a look again. It mostly looks good, but there are a couple of improvements which can be made:

_create_node() functionality could be refactored into multiple smaller methods. Right now the method is very large and complex.
Test case situation should be improved. There is a lot of code and conditional branches which are not not exercised / covered (https://app.codecov.io/gh/apache/libcloud/pull/1983?src=pr&el=tree&filepath=libcloud%2Fcompute%2Fdrivers%2Fkubevirt.py#diff-bGliY2xvdWQvY29tcHV0ZS9kcml2ZXJzL2t1YmV2aXJ0LnB5, https://github.com/apache/libcloud/pull/1983#issuecomment-2080694604). Existing test cases exercise only a small amount of "happy" code paths. I know you didn't add all of that code, but since you updated / touched a lot of it, it would be great to also improve the test coverage.

@Kami Thank you for the review. Indeed, the create_node() looks clumsy. I've actually started refactoring it, but recent higher priority tasks have delayed its completion.
Also, at the moment, I'm unable to add more test cases due to these priority. However, there are some existing test cases for _deep_merge_dict and _memory_in_MB that I believe were copied from our other projects. I plan to incorporate these tests soon.
Despite the problems with code readability and test coverage, we've been using this code in a production environment for several months. It has been performing well and handling a considerable number of situations that aren't covered by the test cases.

@cdfmlr Thanks.
Do you happen to have any ETA when you will be to add some more tests + refactor the code a bit? Since I'm planning to do a v3.9.0 release this week.

@Kami sorry for my delay.
I have added more tests covering the helper functions (_deep_merge_dict and _memory_in_MB) and some typical unhappy code paths. The _create_node() method has been refactored into smaller functions as well. Meanwhile, a useful new feature to set cpu/mem requests and limits separately is introduced and tested.

@cdfmlr Thanks for adding those changes.
I added a couple of more comments. It's mostly a couple of small things, plus the potential security issue with possible YAML injection in case the pub key or password is supplied by the end user and not sanitized before being passed to the Libcloud code.

Merged into trunk. Thanks.


Remove temporary setting of NUMEXPR_MAX_THREADS in ms2rescore

https://github.com/compomics/DeepLC/issues/19 has been fixed, so the following lines can be removed:
https://github.com/compomics/ms2rescore/blob/2699c1f6691c7c2c6ceb056155a7a5442dd0c4f3/ms2rescore/retention_time.py#L66-L68

Fixed in v3.0.0 🎉


Add account_service_log_out_url

@insacuri if you squash this I don't see any issue with merging it before runner is ready to use it.


How to export a library?

By using alias, you can be able to define some files that will be available to be require()d by other code, problem is that this can't be done for the main export. It's said, if you define an alias for the same file you have defined as the src of your target, grunt-browserify will fail saying it can't be able to find that file. It somewhat has some sense since there's no reference to the module, but how I can be able to do it? A hack that works is to define as src a dumb browser file that only export the real library export while the alias point to this real one, but it's a really nasty hack.
And no, by default It doesn't work to use require(), and no, I don't want to use standalone, because this is for a plugin system I'm doing and using standalone pollutes the global namespace.

What are you trying to achieve? Because it seems this is why standalone exists, but you don't want to use it.

No, standalone add a new element to the global namespace (window), but what I want instead is to be able to require() it from another module... Seems this is not feasable in its current status...

Hmm I don't understand. If you want to require it, don't use browserify and use directly your main file.

I want to require it in the browser... As I told you this is a plugin mechanism, where I have a central element and some third-party provided modules.

Ok then you should be able to just create your bundle by only using require with an exposed name.

But if I remove it from src, will it do the requires expansion?

Yep, you can easily create a bundle without anything in src. It's often used when you have to create a lib bundle. And it seems that's what you are trying to achieve.

Yes, this is mostly what I'm trying to achieve, I'll try to give it a chance :-)


feat: Rewrite generateUID function to use native crypto module.

Could you please add somewhere (READM or desciption) reason of creating this fork?


fix: devServer use searchIndexMiddleware first.

Summary
the middleware order is [unshift]->[internal]->[push].  If [push] is used, the request ends with 404.
The proposed change prioritizes the handling of public resources and search index data.
Please review the changes and let me know if any further modifications are required.
Related Issue

Checklist

[ ] I have added changeset via pnpm run change.
[ ] I have updated the documentation.
[ ] I have added tests to cover my changes.

If [push] is used, the request ends with 404.
Which request url will be ended with 404?

If [push] is used, the request ends with 404.

Which request url will be ended with 404?

Hi @sanyuan0704, I apologize for the confusion in my previous description.

What actually happens is that the search index returns a 404.html when running in the development server.

Thank you ❤


Levels should always convert column to CategoricalArray

With our recent migration to DataScienceTraits.jl, we need to explicitly convert a column of Int to a categorical array before applying the transform.

Fixed on master.


Fixed issue - CS-23842 - Work flow import is failing

Resolved issue of CS-23842 - Workflow import is failing

Added info log to make the user aware that we are skipping importing workflow admin users
Removed workflow admin users from workflow import payload

As discussed with @netrajpatel , this issue wont arise since its taken care off.


Miq Expression execution fails with operator token not supported

The following MiqExpression built from Automate Methods on a custom attribute causes a failure at execution time.
The :token is added during expression substitution
{"="=>{"field"=>"ExtManagementSystem-emstype_description", "value"=>"ManageIQ::Providers::Amazon::CloudManager"}, :token=>1}

The :token is added during expression substitution.
If the expression cannot be handled by SQL we end up deleting the expression but leave the :token key in the hash and when it comes to resolve the next piece it sees :token as an invalid operator and raises an exception. If we delete the expression because it cannot be handled we also need to delete the associated :token key.
https://github.com/ManageIQ/manageiq/blob/master/lib/miq_expression.rb#L315

@gtanzillo @imtayadeway
Please review

The :token is added during expression substitution

@mkanoor can you elaborate on where/why this is happening?

@imtayadeway
Expressions can be built with static data or they can be filled in at runtime by the user. The UI prompts the user for the fields and that substitutes the values into the expression which is then evaluated. An expression which has run time substitution looks like this
{"="=>{"field"=>"Flavor.ext_management_system-id", "value"=>:user_input}, :token=>1}

When the substitution happens user_input is replaced with the runtime value, but the :token is not removed.
This all works fine if the expression only contains SQL table columns, if the expression contains a custom attribute or virtual column then the check for sql column ends up deleting the first half of the expression leaving the token in the key and tripping on the :token

https://github.com/ManageIQ/manageiq/pull/17215 should resolve this issue

Fixed with #17215

issue was not fully resolved,
PR to resolve it when actual expression contain custom attribute: https://github.com/ManageIQ/manageiq/pull/19176


There is apparently no way to edit an existing connection

Issue Type: Feature Request
Can right click a connection and select "Edit Connection" to change - for example - the name or the connection string.

@drk-mtr we are tracking this missing feature with issue https://github.com/microsoft/azuredatastudio/issues/3963.  There are a couple workarounds document there that may help you until this capability is available.  Thanks!


Display number of reviews on article page

In line with search results, the number of reviews an article has obtained should also be displayed on the article page alongside comments and endorsements.
DoD

[ ] Add review count to top of article page mirroring lozenge in search results
[ ] Link from lozenge to first review on the article page

Add hard-coded number to http://localhost:8080/articles/10.1101/209320


Approach to killing stunner process does not work on macOS.

Changed approach to killing stunnel process as it was not working on ……macOS (the PID it tries to kill does not exist).

The script was developed on macOS and we don't see that problem at all. In testing, we get the right pid for the stunnel process and kill it appropriatly. Just killing running stunnel processes as your PR does is problematic for people running muliple instances of stunredis. Could you raise your problem as an issue and we can look into diagnosing it. For now, I'm closing this PR.


Inline parsing extensible

This PR is one idea to make an extensible inline process through the interface NodeExtension where the client can implement how they want that the parser understanding the nodes in that line by the method List<InlineBreakdown> lookup(String input);.
So taking this case for example https://github.com/noties/Markwon/issues/67.
The user needs to make the inline parser understanding how to handle this new format ~bug ~"Multiple word fea"
For this one is just needed one extension that based on the line provides the Nodes(or Custom Nodes) with their respective line positions:
InlineParser.NodeExtension nodeExtension = new InlineParser.NodeExtension() {
    @Override
    public List<InlineBreakdown> lookup(String inline) {
        Matcher matcher = MAGIC_PATTERN.matcher(inline);
        List<InlineBreakdown> inlinesBreakdown = new ArrayList<>();
        while (matcher.find()) {
                inlinesBreakdown.add(InlineBreakdown.of(new Image(...), matcher.start(), matcher.end()));
        }
        return inlinesBreakdown;
    }
};
Parser parser = Parser.builder().nodeExtension(nodeExtension).build();
Node document = parser.parse("Some text ~bug ~\"Multiple word fea\"");

There are some conventions in the case of conflicts such as:

If two nodes are in overlapping each other, the resolution will take the lowest beginIndex and the second it will be ignored;
If two extensions registered to provide Node with the same beginIndex, the first registered will win respecting the ArrayList sort. (As suggested #113 we can have an enhancement to set rank by NodeExtension ahead;

Pls, let me know what do you think and about the terminologies that I tried. All feedback is very welcome.
#113

One simple usage example
https://github.com/atlassian/commonmark-java/blob/f3360bbdf494b5304efbbd262a032211f3edfceb/commonmark/src/test/java/org/commonmark/test/UsageExampleTest.java#L73-L90

Hey @robinst , pls, let me know what do you think about it.

Hey, thanks for raising this. This seems promising, I like the simplicity of the API!
A couple of questions/first impressions:

I'm not sure about the naming yet. This seems more like a preprocessor thing, hmmm. Need to think about it more.
In parseInline, if a builtin syntax parses something and it overlaps with an extension, it looks like the builtin syntax wins, right? What happens to the extension node in that case? A test for that would be good. A good example would be if the extension matches something that is in code backticks.
It seems potentially slow to let extensions parse over the whole inline structure. When I was last thinking about this I was thinking about being able to register extensions in parseInline that get activated on certain trigger characters (similar to the current way the builtin syntax works), and can then do some parsing (or decide not to). It would be similar to custom delimiter processors, except without the constraints of those.  Have you considered this approach? What I like about it is that we could even make the bulitin syntax be implemented that way, similar to how the core block parsers implement the same interface as an extension does.

We implemented extensible inline parsing in the league/commonmark library for PHP - I can share some thoughts and lessons learned from our initial implementation:

I'm not sure about the naming yet. This seems more like a preprocessor thing, hmmm. Need to think about it more.

I am terrible at naming things, but we went with the concept of having "block parsers" and "inline parsers", the latter of which runs after the block has been parsed.

In parseInline, if a builtin syntax parses something and it overlaps with an extension, it looks like the builtin syntax wins, right? What happens to the extension node in that case? A test for that would be good. A good example would be if the extension matches something that is in code backticks.

We went with a somewhat-naive solution where all parsers (including both builtin and custom inline parsers) register themselves with a given priority - just an arbitrary integer that defaults to 0. If somebody wants their custom inline parser to "win" they have the option to set that priority to a higher number.
Individual parsers are not aware of others - we basically stop at a given point in the line and then ask the relevant parsers one-at-a-time if they can parse the text at the given position; if so, they'll parse whatever they can, otherwise we'll try the next eligible parser.  They can choose to parse as much or little as they need to.
This approach seems to work well for parsing CommonMark and GFM.

It seems potentially slow to let extensions parse over the whole inline structure. When I was last thinking about this I was thinking about being able to register extensions in parseInline that get activated on certain trigger characters (similar to the current way the builtin syntax works), and can then do some parsing (or decide not to).

We originally tried regexes but found the performance was indeed very slow, so we proceeded to implement a character-based triggering which helped significantly.  Our inline parsers provide a list of characters they are "interested in" - if we stop on one of those characters, we hand control over to them and that's when they'll attempt to run the slower regexes.
The other benefit to the inline parsers defining a list of characters is that you can dynamically build a regex that can quickly skip through plain text and stop where the next possible inline begins.
This overall approach works great in 99% of cases, but we did come across one situation recently where it fell a bit short: https://github.com/thephpleague/commonmark/issues/492#issuecomment-638206173  I'm leaning towards modifying the implementation to allow for both character-based and regex-based hints so we don't lose the performance optimizations.

I'm not sure about the naming yet. This seems more like a preprocessor thing, hmmm. Need to think about it more.

Yeah, it seems a preprocessor thing... I can rename following this concept. It makes more sense to me.

In parseInline, if a builtin syntax parses something and it overlaps with an extension, it looks like the builtin syntax wins, right? What happens to the extension node in that case? A test for that would be good. A good example would be if the extension matches something that is in code backticks.

Good catch. Yeah, I need to cover this behavior. I tend to assume that the extension should win in this case.

It seems potentially slow to let extensions parse over the whole inline structure. When I was last thinking about this I was thinking about being able to register extensions in parseInline that get activated on certain trigger characters (similar to the current way the builtin syntax works), and can then do some parsing (or decide not to).

Yeah, I thought about this trade-off performance/power so I came with this initial idea to give more power to the user side code. But yeah, it could be to much power with a serious performance impact.

It would be similar to custom delimiter processors, except without the constraints of those.  Have you considered this approach? What I like about it is that we could even make the bulitin syntax be implemented that way, similar to how the core block parsers implement the same interface as an extension does

I thought about this idea to have some character to trigger the extension but I thought that we could have a lot of false positives and that not always we do have some specific characteristics that can define the beginning of some specific text. For example, if from the extension it's considered \ that is also the trigger for parseBackslash() we would have some possible conflicts.

This overall approach works great in 99% of cases, but we did come across one situation recently where it fell a bit short: thephpleague/commonmark#492 (comment) I'm leaning towards modifying the implementation to allow for both character-based and regex-based hints so we don't lose the performance optimizations.

Yeah, I guess I came from the other direction first going by powerful then performance side. lol @colinodell But as you both said, it will have performance impact empowered by Number of Extensions. Kind of [line reads] x [Number of Extensions].
@colinodell gave one idea that could be nice which the client could inform one or character sequential, this could be one interesting idea. @robinst Do you think that could be helpful we keep this current approach in this PR where the extension can have the entire line to decide what to do? I will think about the approach to triggered by character/sequence too.

I will run the performance over this scenario to compare the usage of the extension as it is right now and without the extension.

I got interesting numbers here. I tried to build one simple performance test just to compare with/without extension. So, I did narrow: one regular image syntax and one extension node render and the results it looks almost the same.
Benchmark                                 Mode  Cnt   Score   Error  Units
ParseBenchmark.parseImageByNodeExtension    ss   50  33.225 ± 6.245  ms/op
ParseBenchmark.parseImageRegularUsage       ss   50  32.296 ± 4.497  ms/op

Benchmark                                 Mode  Cnt   Score   Error  Units
ParseBenchmark.parseImageByNodeExtension    ss   50  31.688 ± 4.664  ms/op
ParseBenchmark.parseImageRegularUsage       ss   50  35.466 ± 5.394  ms/op

Benchmark                                 Mode  Cnt   Score   Error  Units
ParseBenchmark.parseImageByNodeExtension    ss   50  42.611 ± 9.557  ms/op
ParseBenchmark.parseImageRegularUsage       ss   50  36.177 ± 5.366  ms/op

https://github.com/atlassian/commonmark-java/blob/067fcf111d15617f7bf7e3f062c8a1b2a4ec5424/commonmark-integration-test/src/test/java/org/commonmark/integration/ParseBenchmark.java#L58-L66

Adding a second extension the performance got significant impacted.
Benchmark                                    Mode  Cnt   Score   Error  Units
ParseBenchmark.parseImageByNodeExtension       ss   50  34.466 ± 5.621  ms/op
ParseBenchmark.parseImageByTwoNodeExtension    ss   50  52.019 ± 5.060  ms/op
ParseBenchmark.parseImageRegularUsage          ss   50  33.606 ± 4.941  ms/op

Benchmark                                    Mode  Cnt   Score   Error  Units
ParseBenchmark.parseImageByNodeExtension       ss   50  30.672 ± 4.996  ms/op
ParseBenchmark.parseImageByTwoNodeExtension    ss   50  55.305 ± 6.249  ms/op
ParseBenchmark.parseImageRegularUsage          ss   50  33.529 ± 4.429  ms/op

Given that we may need to prioritize the current nodes + the nodes extended, I'm studying a possible new design to support it given that we may need to put all nodes(configurations) in the same bucket to be able to prioritize accordingly. So the ideas that you both gave you be really helpful. The main points for doing this that I'm thinking is:

Trigger node creation by the start character;
Common bucket for nodes configuration;
One interaction to provide the nodes without the need to interact multiples times per node Extensions.

I hope to commit an idea in the next days to us discuss it and see how the performance is impacted @robinst / @colinodell

(I wrote this reply days ago, but I must have forgotten to submit it and lost it, sorry about that. Typed it again.)
@colinodell thanks for that detailed comment, very helpful!

We originally tried regexes but found the performance was indeed very slow, so we proceeded to implement a character-based triggering which helped significantly. Our inline parsers provide a list of characters they are "interested in" - if we stop on one of those characters, we hand control over to them and that's when they'll attempt to run the slower regexes.

Yes, that's what I was thinking about, as it very closely matches how the existing inline parsing works, see e.g.:
https://github.com/atlassian/commonmark-java/blob/b5d0f398a56ec4f20e02af978b1dd395f1551c99/commonmark/src/main/java/org/commonmark/internal/InlineParserImpl.java#L213-L218

The other benefit to the inline parsers defining a list of characters is that you can dynamically build a regex that can quickly skip through plain text and stop where the next possible inline begins.

Nice idea, yeah we could do something similar.

This overall approach works great in 99% of cases, but we did come across one situation recently where it fell a bit short: thephpleague/commonmark#492 (comment) I'm leaning towards modifying the implementation to allow for both character-based and regex-based hints so we don't lose the performance optimizations.

Our current autolink extension would have the same problem, as it runs after inline parsing on Text nodes too. But as a first step for making inline parsing customizable, I don't think we have to fix this yet.
@samukce replying to this bit:

I thought about this idea to have some character to trigger the extension but I thought that we could have a lot of false positives and that not always we do have some specific characteristics that can define the beginning of some specific text. For example, if from the extension it's considered \ that is also the trigger for parseBackslash() we would have some possible conflicts.

Yeah, the extension mechanism should be able to handle multiple inline parsers that register for the same trigger character. In the above example, the custom one would be allowed to run first (same as with custom block parsers), and decide whether it wants to handle it or not.
@samukce do you feel like working on that? It might seem a bit daunting because it will mean the entire inline parser will change, but it's gonna be a good change. In any case, I think we should do that before we add any regex-based extension mechanism because we'll have a better starting point with it.

Yes @robinst, I agree. I am doing a small POC to us discuss over given that this idea could mean some huge changes in our codebase. I hope until the weekend I commit the code so we can talk about the idea. :)

Hey @samukce! After the recent changes to inline parsing in #180, it should now be fairly simple to make inline parsing extensible. We will just need to add some methods to the builders and make some things public API.
I'll close this PR. Let me know if you're interested in doing that work.

Hey @samukce! After the recent changes to inline parsing in #180, it should now be fairly simple to make inline parsing extensible. We will just need to add some methods to the builders and make some things public API.
I'll close this PR. Let me know if you're interested in doing that work.

hello @robinst, sorry for so later answer...lately I have been really busy here =/ . I let you know if I have a chance to get back to this one 🤞


project scaffold changes

*Issue:*https://github.com/bcgov/entity/issues/
Description of changes:

ui changes
ui test changes

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the namex license (Apache 2.0).

/gcbrun

/gcbrun

Temporary Url for review: https://strr-ui-dev--pr-6-rbhzjchl.web.app

/gcbrun

Temporary Url for review: https://strr-ui-dev--pr-6-rbhzjchl.web.app


Hexpatch?

Hi, thanks you for this module.
I read inside in this module: sensitive-props-v<IP_ADDRESS>
Say this:
Undetectable property deletion:** Utilizes a hexpatch method for deleting properties, making it undetectable by SafetyNet. This method was necessary due to limitations in the magiskboot applet, and despite requests for improvement, the maintainer (topjohnwu on issue 8315) opted not to introduce a proper fix.
And because you know better, is a good feature?
Have any advantage, to put it in your module?
Or maybe you have some similar already.
Sorry if already have, and I didn't notice.

This module doesn't use magiskboot nor hexpatch.


Add "street_number" and "extra info"

For our project we need the street number as a separate field and users can add a comment related to the address.
Do you think it could be added ?

PRs are welcome 😉


Delegation issues in HTTP::Request::Caching

While investigating jruby/jruby#3151, a few issues with the way Caching does delegation came to light:

At least one place, in conditional_on_changes_to, an HTTP::Request object gets double-delegated. Both the self.class.new and .caching calls wrap the new HTTP::Request object in a delegating Caching instance.
The Caching class itself is created before HTTP::Request has completed loading, resulting in a DelegateClass that does most delegation through method_missing rather than through generated, direct delegation methods.

These issues are not strictly bugs, but they likely affect performance. In the case of jruby/jruby#3151, they also exposed an obscure bug in JRuby.

I'm not really happy with the quality of the caching code. It's caused a lot of sporadic test failures. Having a dependency on rack isn't really something I like either.
Perhaps we could remove it and add it back when/if it's in a better state?

I agree with removing the code until something better is done.

:+1: for wiping it out.

Created #240 to revert caching


Upgrade to new glslify

In order to get esprima-six out of the dependency tree (refs #149), we need to remove references to old versions of astw, which are found in the old versions of glslify, gl-compare, and gl-axes. The interface to glslify has changed since version 1, so these will need to be changed in all of these examples.
I can start sketching this out, and at least follow the migration steps in glslify. I'm not too familiar with modern best practices of browserify, and I don't have any experience working with GL, so I'll probably need help and lots of :eyes: for review.
cc/ @mikolalysenko @mattdesl @hughsk

@jakepruitt I started this tonight, actually - initial work in a couple of modules (glslify-live, gl-compare) are up, but there is quite a bit more work to do - especially in glslify-live

@jacob-meacham sweet! Yeah, I was working on this last night too, especially the bundling in glslify-live. I'll let you know if I get any solid progress.

Initial shader-school work is in #151 - all exercises now work, minus glslify-live