Message filter dropping messages

Robot Model
Turtlebot4 Lite
ROS distro
Humble
Networking Configuration
Discovery Server
OS
Ubuntu 22.04
Built from source or installed?
Installed
Package version
$ dpkg -s ros-humble-turtlebot4-navigation
Package: ros-humble-turtlebot4-navigation
Status: install ok installed
Priority: optional
Section: misc
Installed-Size: 2470
Maintainer: rkreinin<EMAIL_ADDRESS>Architecture: arm64
Version: 1.0.4-1jammy.20240220.175556
Depends: ros-humble-nav2-bringup, ros-humble-nav2-simple-commander, ros-humble-slam-toolbox, ros-humble-ros-workspace
Description: Turtlebot4 Navigation
dpkg -l | grep turtlebot4
ii  ros-humble-turtlebot4-base                        1.0.2-1jammy.20240219.090534            arm64        Turtlebot4 Base Node
ii  ros-humble-turtlebot4-bringup                     1.0.2-1jammy.20240308.175126            arm64        Turtlebot4 Robot Bringup
ii  ros-humble-turtlebot4-description                 1.0.4-1jammy.20240220.151406            arm64        Turtlebot4 Description package
ii  ros-humble-turtlebot4-diagnostics                 1.0.2-1jammy.20240219.092405            arm64        Turtlebot4 Diagnostics
ii  ros-humble-turtlebot4-msgs                        1.0.4-1jammy.20240217.101439            arm64        Turtlebot4 Messages
ii  ros-humble-turtlebot4-navigation                  1.0.4-1jammy.20240220.175556            arm64        Turtlebot4 Navigation
ii  ros-humble-turtlebot4-node                        1.0.4-1jammy.20240219.090001            arm64        Turtlebot4 Node
ii  ros-humble-turtlebot4-robot                       1.0.2-1jammy.20240308.175711            arm64        Turtlebot4 Robot Metapackage
ii  ros-humble-turtlebot4-setup                       1.0.3-1jammy.20240217.102329            arm64        Turtlebot4 setup scripts
ii  ros-humble-turtlebot4-tests                       1.0.2-1jammy.20240217.102249            arm64        Turtlebot4 System Tests
Type of issue
Navigation (SLAM, Nav2 etc.)
Expected behaviour
I'm trying to simply follow the tutorial "generate a map" https://turtlebot.github.io/turtlebot4-user-manual/tutorials/generate_map.html
Actual behaviour
Running SLAM launch file or view_robot.launch.py according to the tutorials gives message filter dropping message error. No map or robot is shown on rviz. Teleop works just fine.
Error messages
ubuntu@pi5:~$ ros2 launch turtlebot4_navigation slam.launch.py
[INFO] [launch]: All log files can be found below /home/ubuntu/.ros/log/2024-04-05-03-10-49-883262-pi5-1475
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [sync_slam_toolbox_node-1]: process started with pid [1476]
[sync_slam_toolbox_node-1] [INFO] [1712286650.437134643] [slam_toolbox]: Node using stack size 40000000
[sync_slam_toolbox_node-1] [INFO] [1712286650.621515132] [slam_toolbox]: Using solver plugin solver_plugins::CeresSolver
[sync_slam_toolbox_node-1] [INFO] [1712286650.622153777] [slam_toolbox]: CeresSolver: Using SCHUR_JACOBI preconditioner.
[sync_slam_toolbox_node-1] [INFO] [1712286651.981918291] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.712 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286652.104942154] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.849 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286652.239699848] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.982 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286652.375322668] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.105 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286652.498658937] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.240 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286652.632892430] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.375 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286652.755463832] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.498 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286652.891049134] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.633 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286653.013859349] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.756 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286653.148605785] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.891 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286653.284359178] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.014 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286653.406621081] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.149 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286653.541880736] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.284 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286653.665104765] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.407 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286653.799904496] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.543 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286653.934617024] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.665 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286654.057556739] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.800 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286654.192761857] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.936 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286654.315469925] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.057 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286654.450474970] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.193 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286654.573876109] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.315 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286654.708634303] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.450 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286654.843685126] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.574 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286654.966429582] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.709 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286655.101847848] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.844 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286655.224518675] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.966 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286655.359416313] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.102 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286655.482752489] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.224 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286655.617862571] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.359 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286655.752666136] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.483 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286655.875470333] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.618 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286656.010847228] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.753 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286656.133194279] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.875 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286656.268405916] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.011 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286656.403458275] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.133 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286656.526542101] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.268 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286656.661313554] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.403 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286656.784371398] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.526 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286656.919480054] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.661 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286657.042729379] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.784 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286657.177004724] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.919 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286657.313214170] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.043 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286657.435285056] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.177 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286657.570599655] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.313 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286657.694272459] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.435 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286657.828771933] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.571 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286657.963455646] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.694 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286658.086264473] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.830 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286658.221239925] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.963 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286658.343949790] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.086 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286658.479208204] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.221 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286658.602040197] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.345 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286658.737254297] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.480 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286658.871978491] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.603 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286658.995152798] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.737 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286659.130314324] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.873 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286659.253267150] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.996 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286659.387960937] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.130 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286659.523427369] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.253 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286659.646424139] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.388 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286659.781266703] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.523 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286659.904193215] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.646 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286660.039345740] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.781 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286660.162101549] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.905 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286660.297393537] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.040 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286660.432635007] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.163 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286660.554818133] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.298 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286660.689933714] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.432 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286660.812896929] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.555 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286660.948131529] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.690 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286661.070608783] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.814 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286661.206311547] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.948 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286661.340768280] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.072 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286661.463624051] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.206 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286661.598843817] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.341 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286661.722111623] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.464 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286661.856679726] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.599 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286661.991966418] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.722 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286662.115284409] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.857 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286662.250261528] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.992 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286662.372711171] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.115 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286662.507575199] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.250 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286662.630788671] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.373 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286662.765480033] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.508 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286662.900763706] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.631 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286663.024156086] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.766 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286663.158974280] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.901 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286663.281519367] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.024 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286663.416871188] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.159 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286663.552331953] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.282 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286663.674830393] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.417 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286663.809653031] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.552 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286663.932755690] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.675 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286664.067756883] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.810 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286664.190518747] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.933 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286664.326404381] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.068 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286664.460836280] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.190 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286664.583626626] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.327 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286664.719195112] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.461 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286664.841249165] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.584 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286664.976800689] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.719 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286665.177407599] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.841 for reason 'the timestamp on the message is earlier than all the data in the transform cache'
[sync_slam_toolbox_node-1] [INFO] [1712286665.369593532] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.977 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286665.492042897] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.235 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286665.627861253] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.369 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286665.750312897] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.493 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286665.885321127] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.629 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286666.007988676] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.750 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286666.143438367] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.885 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286666.278409487] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.008 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286666.401397665] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.143 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286666.536461024] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.278 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286666.659330906] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.402 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286666.794667227] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.537 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286666.929595402] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.659 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286667.052206786] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.795 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286667.187135368] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.929 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286667.310411119] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.052 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286667.445391145] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.188 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286667.568646414] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.311 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286667.703101573] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.445 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286667.838432672] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.568 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286667.961285906] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.703 for reason 'discarding message because the queue is full'
[sync_slam_toolbox_node-1] [INFO] [1712286668.096689801] [slam_toolbox]: Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.839 for reason 'discarding message because the queue is full'
^C[WARNING] [launch]: user interrupted with ctrl-c (SIGINT)
[sync_slam_toolbox_node-1] [INFO] [1712286668.128783200] [rclcpp]: signal_handler(signum=2)
[INFO] [sync_slam_toolbox_node-1]: process has finished cleanly [pid 1476]

To Reproduce
Fresh install of humble & turtlebot4 setup on RPI, updated H.2.6 firmware.
Follow discovery server steps. https://turtlebot.github.io/turtlebot4-user-manual/setup/discovery_server.html
Edit ntp.conf as follows & restart ntpd.
# Use RPi4 as preferred server
# Minpoll 2^4 = 16s
# Maxpoll 2^6 = 64s
server <IP_ADDRESS> prefer iburst minpoll 4 maxpoll 6

Both PC and RPi system clocks synchronized according to timedatectl status command
create3_log_messages.txt
logs_terminal.txt
Other notes
My /etc/chrony/chrony.conf file is different from the default file mentioned in this comment: https://github.com/turtlebot/turtlebot4/issues/379#issuecomment-2004064383
Changing it didn't seem to fix anything though, so I reverted back to how it was.
chrony.conf.txt

I think I solved part of it.

My /etc/chrony/chrony.conf file is different from the default file...

I set up this pi (with incorrect chrony.conf file) using https://github.com/turtlebot/turtlebot4_setup/
in which I installed Ubuntu 22.04 then ran the new image setup script with this command:
wget -qO - https://raw.githubusercontent.com/turtlebot/turtlebot4_setup/humble/scripts/turtlebot4_setup.sh | bash
This procedure seems to not have set up the /etc/chrony/chrony.conf file. It could also be missing other files, I'm not sure.
(Partial fix) I have another pi that I set up by downloading and installing the latest available humble image (1.0.0) from http://download.ros.org/downloads/turtlebot4/, then updating those packages to the actual latest humble version with sudo apt update && sudo apt upgrade. This second pi has the correct /etc/chrony/chrony.conf file in it.
After giving pi#2 some time to sync with the create, it successfully maps for a little while with only a few "message filter dropping messages" (still following the same tutorial).
(New Issue)
After a few minutes it gives messages like these:
[sync_slam_toolbox_node-1] [WARN] [1712336405.868042655] [slam_toolbox]: Queue size has grown to: 109. Recommend stopping until message is gone if online mapping.
Then a few minutes later it gave messages like these:
[sync_slam_toolbox_node-1] [ERROR] [1712336406.776605582] [slam_toolbox]: Transform from base_link to odom failed: Lookup would require extrapolation into the past.  Requested time<PHONE_NUMBER>.494601 but the earliest data is at time<PHONE_NUMBER>.833029, when looking up transform from frame [base_link] to frame [odom]
When these are popping up, the mapping seems less reliable.

Hello @mbergman257
Thank you for reaching out on the Turtlebot 4 Github. Glad to hear that you were able to make progress on this matter. From the two error messages you have shared it appears that there is a time sync issue. For a discovery server setup, as long as your network is connected to the internet then all you should need to do is to make sure that your laptop is also syncing time with the internet ((for default ubuntu you can check using timedatectl status - this also works on the raspberry pi) AND redirect the create3 drive base to sync time with the raspberry pi (instructions https://github.com/turtlebot/turtlebot4/issues/216)
If your system is not connected to the internet then you will need to modify the timesyncing on both the create3 and raspberry pi. Since you are using discovery server then still point the create3 at the raspberry pi (instructions https://github.com/turtlebot/turtlebot4/issues/216) and then point the raspberry pi at an NTP server on your PC.
Let me know how this recommendation works for you. Looking forward to hearing from you soon.
Best Regards,
Saif

Hi @smatarCPR,
I appreciate your response. I had followed those recommended steps already, as noted in my issue description and comment above. I'm looking for more help on the new issue I ran into after resolving the ntp sync issue, as noted in my comment. Do you have recommendations for that issue?
Thank you!

Additionally, if there is any extra information I can provide to help debug, or any extra clarification I can provide, please let me know!
Thank you!

This is information that hopefully will help you understand much of what is happening (80% information, 20% directions on what you can do to help improve operation) as well as helping anyone else who might come across this ticket and not completely understand what is going on here:

Message Filter dropping message: frame 'rplidar_link' at time<PHONE_NUMBER>.008 for reason 'discarding message because the queue is full' This is not a time sync error in itself. This is just a notification that the queue is full and seeing this message is normal while bringing up the system. This message will always show up when nothing is taking the messages out of the queue, so they are just being accumulated. Examples of when you will see this is after you launch localization before you set up your initial position, essentially any in between time before the system is fully set up / fully communicating. Seeing this message can tell you something about your system's current operating state but it in itself is not the error nor would it alone be enough for us to tell what the actual error is. With SLAM, this would mean that slam is either not up and running yet, crashed or is not able to use those messages for some reason.

I am glad you were able to find the chrony issue. This shows us that the issue was that SLAM was not able to use the messages because of the time sync issue. That being said, this issue would have been that the odom information from the create3 was not time synced. So even though the data from the raspberry pi was likely properly time synced and thus the lidar data was being queued properly, SLAM was not able to run properly. We will take a look at the setup instructions to see where the gap is that this chrony file was not set up properly.

[sync_slam_toolbox_node-1] [WARN] [1712336405.868042655] [slam_toolbox]: Queue size has grown to: 109. Recommend stopping until message is gone if online mapping. This message means that slam is not able to process the messages quickly enough and the queue is growing in length. Messages are being added quicker than they are being removed. This will happen when mapping large environments, especially if you have lower computational power on your PC that is running the SLAM (or if you are attempting to run SLAM onboard). By default SLAM will run continuously irrelevant of if the robot is moving or not. This tends to be the most intuitive for absolute beginners. This is generally only a problem when you try to map larger facilities. You will need to adjust how often the map is updating to fit your application. To do so, you will need to launch slam with a custom config file. This will allow you to update the map less often for a lighter map and/or allow you to stop the mapping when you stop the robot to allow for the system to catch up. Make a copy of the config file and update the minimum travel distance and heading for what makes sense for your use case and then pass it when you launch slam.
ros2 launch turtlebot4_navigation slam.launch.py params:=/full/path/to/slam.yaml
Try different numbers and see how it impacts your map.

[sync_slam_toolbox_node-1] [ERROR] [1712336406.776605582] [slam_toolbox]: Transform from base_link to odom failed: Lookup would require extrapolation into the past. Requested time<PHONE_NUMBER>.494601 but the earliest data is at time<PHONE_NUMBER>.833029, when looking up transform from frame [base_link] to frame [odom] This is a result of not heeding the previous warning. SLAM is so far behind in processing the messages that by the time it processes a given message, it can no longer access the transform information so far in the past from when the lidar message was received. As a result, it will be unable to add that scan into the map.  This is an error that can definitely cause issues with your map.

Hopefully this clears things up and gives you the information to move forward. Feel free to ask any more question.

Thank you! This was very helpful.

Hi, I'm having a similar issue on my Turtlebot4 Standard. I have Simple Discovery set up because I eventually want to connect a second Turtlebot. How would I fix the time-sync issue with Simple Discovery? I was able to correct the time on the Create3, but not on the Pi.

Hi, I'm having a similar issue on my Turtlebot4 Standard. I have Simple Discovery set up because I eventually want to connect a second Turtlebot. How would I fix the time-sync issue with Simple Discovery? I was able to correct the time on the Create3, but not on the Pi.

I believe a new version of the turtlebot packages is out now or will be out soon, and they address the ntp issue. You can see which ros packages will be available here: https://discourse.ros.org/t/preparing-for-humble-sync-and-patch-release-2024-08-06/38909
So update those when theyre available. If you have any other issues you should make a new issue thread with all the requested information.

Got it, I'll look into updating that thank you. In the meantime, I followed this article's instructions to sync the time: https://robofoundry.medium.com/how-to-sync-time-between-robot-and-host-machine-for-ros2-ecbcff8aadc4
For some reason, the time is around 45 seconds off (as observed when I run timedatectl on the Pi and desktop computer within 2 seconds of each other). I'll start a new issue because I was not able to resolve the issue of "Message Filter dropping message: frame 'rplidar_link'..." when I try to run $ros2 launch turtlebot4_viz view_robot.launch.py

for people facing this in turtlebot3, this can be sorted by,
open opt/ros/humble/share/turtlebot3_navigation2/param/{turtlebot3_model}.yaml
in the yaml file, change the robot_model_type in the line 29;
from:
robot_model_type: "differential"
change that line to :
robot_model_type: "nav2_amcl::DifferentialMotionModel"
after this try cartographer slam with sim time argument set to true,
ros2 launch turtlebot3_cartographer cartographer.launch.py use_sim_time:=True


Update binaryCalculator.js

The PR got conflict after I merge some PR, can you solve the conflict ?

The PR got conflict after I merge some PR, can you solve the conflict ?

I have reviewed the code, and I believe I have resolved the merging issues. However, please double-check to be 100% certain, as two heads are better than one.

@Pedrop19 my pr is also having a conflict as well. Could you please wait while I sort that out. Otherwise we would have more and more conflicts.

@Pedrop19 my pr is also having a conflict as well. Could you please wait while I sort that out. Otherwise we would have more and more conflicts.
Of course


improvement prune hash join output slot ids list

Proposed changes
Issue Number: close #xxx

prune hash join output slot ids list based on slot ids in required project and other conjunctions, to reduce the be side effort.
support pruning for semi/anti also

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall

run buildall

run buildall

run buildall

run buildall

run buildall

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 42.19 seconds
stream load tsv:          468 seconds loaded<PHONE_NUMBER>9 Bytes, about 152 MB/s
stream load json:         20 seconds loaded<PHONE_NUMBER> Bytes, about 112 MB/s
stream load orc:          58 seconds loaded<PHONE_NUMBER> Bytes, about 18 MB/s
stream load parquet:          31 seconds loaded 861443392 Bytes, about 26 MB/s
insert into select:          69.5 seconds inserted 10000000 Rows, about 143K ops/s
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230628082921_clickbench_pr_169191.html


[ENH] Server-side validation

Description of changes
Summarize the changes made by this PR.

Improvements & Bug fixes

...

New functionality

...

Test plan
How are these changes tested?

[ ] Tests pass locally with pytest for python, yarn test for js, cargo test for rust

Documentation Changes
Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the docs repository?

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#3168  👈 (View in Graphite)
#3158
main

This stack of pull requests is managed by Graphite. Learn more about stacking.


[Bug]:

/mv version -p output
https://paste.gg/d1cc03ec2b5649dda5ae668f6908360b
Server logs
https://paste.gg/p/anonymous/c1e5b5aa45fc4ee988b0e33558c30153
Server Version
version
[21:15:03 INFO]: This server is running Paper version 1.21-39-master@aa8d38d (2024-06-29T09:10:10Z) (Implementing API version 1.21-R0.1-SNAPSHOT)
You are 72 version(s) behind
Download the new version at: https://papermc.io/downloads/paper
Previous version: 1.21-109-5a5035b (MC: 1.21)

Bug Description
[21:05:52 WARN]: [Multiverse-Core] "Multiverse-Core v4.3.1-b861" has registered a listener for org.bukkit.event.entity.EntityCreatePortalEvent on method "public void com.onarandombox.MultiverseCore.listeners.MVPortalListener.entityPortalCreate(org.bukkit.event.entity.EntityCreatePortalEvent)", but the event is Deprecated. "Server performance will be affected"; please notify the authors [dumptruckman, Rigby, fernferret, lithium3141, main--]
Steps to reproduce
look console
Agreements

[X] I have searched for and ensured there isn't already an open or resolved issue(s) regarding this.
[X] I was able to reproduce my issue on a freshly setup and up-to-date server with the latest version of Multiverse plugins with no other plugins and with no kinds of other server or client mods.

its a known issue lol

Duplicate of #2000


Linux

Please paste the output of the following command here: sudo edit-chroot -all

Please describe your issue:The code i used to download crouton did not work. the code is sudo install -Dt /usr/local/bin -m 755 ~/Downloads/crouton. Im new to this and i don't know what to do and neither do i understand. Im here to download java minecraft. Everytime i enter that code it says     install: cannot stat '/home/chronos/user/Downloads/crouton': No such file or directory
If known, describe the steps to reproduce the issue:

Can you find a file named crouton in your downloads folder? If not download it from https://goo.gl/fd3zc.

Can you find a file named crouton in your downloads folder? If not download it from https://goo.gl/fd3zc.

I have the crouton file thingy and i opened it. Thats when i entered the
codes in to download linux and it didn't work
On Fri, Jan 22, 2021, 12:16 PM Mr. Hallway<EMAIL_ADDRESS>wrote:

Can you find a file named crouton in your downloads folder? If not
download it from https://goo.gl/fd3zc.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dnschneid/crouton/issues/4400#issuecomment-765563287,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASRWOYCAMDR22B3DRNATZFLS3GXFZANCNFSM4WNZNU5A
.

I have the crouton file thingy and i opened it. Thats when i entered the
codes in to download linux and it didn't work
On Fri, Jan 22, 2021, 12:16 PM Mr. Hallway<EMAIL_ADDRESS>wrote:

Can you find a file named crouton in your downloads folder? If not
download it from https://goo.gl/fd3zc.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dnschneid/crouton/issues/4400#issuecomment-765563287,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASRWOYCAMDR22B3DRNATZFLS3GXFZANCNFSM4WNZNU5A
.

OMG thanks man that file worked!!

OMG thanks man that file worked!!


Issue with  go get github.com/adnanh/webhook

When I tried getting the webhook according to this  tutorial, with the code  go get github.com/adnanh/webhook I get the error
github.com/adnanh/webhook/internal/pidfile
go/src/github.com/adnanh/webhook/internal/pidfile/pidfile.go:38:54: syntax error: unexpected o755, expecting comma or )
go/src/github.com/adnanh/webhook/internal/pidfile/pidfile.go:41:76: syntax error: unexpected o600, expecting comma or )

webhook requires Go 1.14.


A JavaScript error occurred in the main process - Apple M1

Describe the bug
Monokle is not able to start on MacBookPro with Apple Silicon M1, presenting following error:
A JavaScript error occurred in the main process

Uncaught Exception:
Error: Command failed with ENOENT: /usr/local/bin/zsh -ilc echo -n "_SHELL_ENV_DELIMITER_"; env; echo -n "_SHELL_ENV_DELIMITER_"; exit
spawnSync /usr/local/bin/zsh ENOENT
at Object.spawnSync (node:internal/child_process:1111:20)
at Object.spawnSync (node:child_process:823:24)
at module.exports.sync (/Applications/Monokle.app/Contents/Resources/app.asar/node_modules/execa/index.js:174:25)
at shellEnvSync (/Applications/Monokle.app/Contents/Resources/app.asar/build/src/utils/env.js:45:44)
at getMainProcessEnv (/Applications/Monokle.app/Contents/Resources/app.asar/build/src/utils/env.js:61:26)
at getStaticResourcePath (/Applications/Monokle.app/Contents/Resources/app.asar/build/src/redux/services/index.js:14:56)
at loadResource (/Applications/Monokle.app/Contents/Resources/app.asar/build/src/redux/services/index.js:27:32)
at Object.<anonymous> (/Applications/Monokle.app/Contents/Resources/app.asar/build/src/redux/services/schema.js:41:69)
at Module._compile (node:internal/modules/cjs/loader:1118:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1173:10)

To Reproduce
Steps to reproduce the behavior:

Download Monokle from official website or from GitHub official repo
Open dmg or extract zip file
Move Monokle.app to Applicatons folder
Open Monokle as every other mac app

Expected behavior
Monokle to start properly.
Screenshots

Desktop (please complete the following information):

OS: MacOS Monterey
Version 12.6
Apple Silicon M1
Monokle versions tested: 1.12.0, 1.11.1

hey @bygui86 thank you for reporting this bug. I just wonder if you are using zsh on your system. Can you provide information, please?

@erdkse yes I use zsh, here some info:
$ zsh --version
zsh 5.9 (arm-apple-darwin21.3.0)

do you need further info?

Any news here?

hey @bygui86, we investigated the issue but couldn't find a reason to cause it, If you have time could you please have a video meeting with me so I can see what is going on easier? This is my discord id, please contact to me erdkse#6364

@erdkse I can find the time but I don't use Discord, what about Slack or scheduling an event in Google Calendar?

Certo! I just invited you to a meeting! Please feel free to redefine the date and time.

it is working for me and @devcatalin  and we both have M1, let me know if I need to jump into the call with you

I have M1 and it is working well for me too, I invited you both @chargio

thanks guys


Changes required for Polyester and ReactNativeHost

Please select one of the following

[ ] I am removing an existing difference between facebook/react-native and microsoft/react-native :thumbsup:
[ ] I am cherry-picking a change from Facebook's react-native into microsoft/react-native :thumbsup:
[ ] I am making a fix / change for the macOS implementation of react-native
[x] I am making a change required for Microsoft usage of react-native

Changes required for Polyester and ReactNativeHost
Microsoft Reviewers: Open in CodeFlow

Obviously stale...


Improve fastfile finder for local and remote repo

Hello, this PR fixes #638.
Two main changes:

the local search of a Fastlane file is done recursively using Dir["**/Fastfile"]. we will return fastlane/Fastfile if exists, otherwise the first found.
the remote search has been done using the Tree API, which returns recursively all folder and files (there is probably a limit of nodes that can be returned, but it is not specified in GitHub API, anyway if it fails we will still relying on cloning and searching locally). As above, we will return fastlane/Fastfile if exists, otherwise the first found.

A note: I preferred to use the Tree API over requesting for the root directory and making requests for each directory because it is far more efficient (i.e. one request vs one request per directory)

Done @taquitos, have a look when you can 🍷  Thanks 😄


[AJ-676] address comments in follow-up PR

Follow up PR addressing comments in https://github.com/DataBiosphere/terra-ui/pull/3569. This PR completes some minor refactoring:

move the proxyUrl call inside of the WDS provider
move the getUrl method to the WDS provider class
move WDS schema call outside of the async promise context from the proxyUrl request

In practice, I think there's something not quite right with the this.proxyUrlPromise. I think the ajax call to Leo is being executed repeatedly. When I load the Data tab of the UI, I see the call to /apps/v2 roughly 10 times in the network tab of dev tools.

Yes. That's because a new instance of the WDSDataTableProvider is being created each time the Data component renders.
https://github.com/DataBiosphere/terra-ui/blob/7abc5d3d5bdeab1fff23e3b7539ca9e78f97c3ae/src/pages/workspaces/workspace/Data.js#L513
To prevent this, you could use useInstance or useMemo / use-memo-one to preserve the instance across renders / for the lifetime of the component.


update to 2018 edition

I'm chipping away at creating a branch of reqwest which makes use of futures-0.3 + async/await syntax.
In order to do this, i've had to first port reqwest to 2018 edition (in order to use 'async' context). Would you be open to a pull request with this change? No API changes, so i'm assuming its just a patch update
I've been very very (very) tempted to run rustfmt over the whole thing too, but have so far managed to restrain myself

#589

This may be closed now that #589 has been merged.


feat(ci): enable cache in setup-python

https://github.com/actions/setup-python/blob/main/docs/advanced-usage.md#caching-packages
This may speed up the test slightly. (although it will take longer to install poetry anyway)

This is useful in the rare case of a library that takes an inordinate amount of time to install. However I'm also not sure if it should be in the template. (How about commenting it out?)
I would appreciate it if you could take a look at other PRs.

Thanks for the effort and your patience!


Change pyusb version specifier

I changed the pyusb version specifier to allow for the latest installable verison from pip, 1.0.0.rc1.
Version compatible:
root@3faee96ee964:/tmp/pyminicircuits# python -c 'import usb; print usb.version_info'
(1, 0, 0, 'rc1')
root@3faee96ee964:/tmp/pyminicircuits# sudo python mini-attenuator get
30.0
root@3faee96ee964:/tmp/pyminicircuits#

Version specifier transcripts:
root@5b6e9dfd2f4d:/py# pip install pyusb==1.0.0rc1
Downloading/unpacking pyusb==1.0.0rc1
  Downloading pyusb-1.0.0rc1.tar.gz (53Kb): 53Kb downloaded
  Running setup.py egg_info for package pyusb

Installing collected packages: pyusb
  Running setup.py install for pyusb

Successfully installed pyusb
Cleaning up...
root@5b6e9dfd2f4d:/py# pip install .
Unpacking /py
  Running setup.py egg_info for package from file:///py

Requirement already satisfied (use --upgrade to upgrade): pyusb>=1.0.rc1 in /usr/local/lib/python2.7/dist-packages (from pyMiniCircuits==0.1)
Downloading/unpacking blinkstick (from pyMiniCircuits==0.1)
  Downloading BlinkStick-1.1.8.tar.gz
  Running setup.py egg_info for package blinkstick

Installing collected packages: blinkstick, pyMiniCircuits
  Running setup.py install for blinkstick
    changing mode of build/scripts-2.7/blinkstick from 644 to 755

    changing mode of /usr/local/bin/blinkstick to 755
  Running setup.py install for pyMiniCircuits
    changing mode of build/scripts-2.7/mini-attenuator from 644 to 755

    changing mode of /usr/local/bin/mini-attenuator to 755
Successfully installed blinkstick pyMiniCircuits
Cleaning up...
root@5b6e9dfd2f4d:/py#

LGTM


Additions to make (huge spoilers so don't look!)

[ ] Add nomai gravity platform to Riebeck platform (easier landing)
[ ] Replace Prisoner near the third totem after the vision (also torch, footprints, dream world versions)
[ ] Add socket to the hole inside the Prison
[ ] Fix Arkose and Moraine dialogue range
[ ] Fix Hornfels dialogue focal point

Is it a little too difficult to invite a Prisoner? Here I'm stuck (maybe I'm not smart.), and I'm struggling with how to unlock the third lock without dying. Eventually, after watching a YouTube promotional video where you interacted with the player, I learned how to properly unlock the third lock. Is the guidance too weak here.

Well, I thought there would be a related optimization schedule. This place stuck me all afternoon!! Ha ha!!

Yes, there will be some optimisation to this, but not sure if I'll do all stuff this week.


cdl: Don't report support for VK_EXT_debug_marker

Reporting that the layer supports this extension appears to cause a bad interaction with the loader. We still intercept calls if they occur because the driver supports it.

CI CrashDiagnosticLayer build queued with queue ID 253091.

CI CrashDiagnosticLayer build # 242 running.

CI CrashDiagnosticLayer build # 242 passed.


UseGlimpse not recongnized in ASP.NET Core RC2

I am using Glimpse 2.0 Beta 1 with ASP.NET Core RC2 and the UseGlimpse extension is not recongnized in:
applicationBuilder.UseGlimple();

I have:
using Glimpse;

Any idea why?

Hello,
Try adding this on "ConfigureServices":
services.AddGlimpse();
Cheers.

@rpaschoal If I add Glimpse to services I get the error:
System.TypeLoadException
Could not load type 'Microsoft.Extensions.PlatformAbstractions.ILibraryManager' from assembly 'Microsoft.Extensions.PlatformAbstractions, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=adb9793829ddae60'.

And I am not able to add UseGlimpse because it is not recognized.
I think there might be a problem with Glimpse 2.0 Beta 1 and ASP.NET Core RC2.
I had this working with ASP.NET Core RC1. Have you tried it with RC2?

Yes I have the same problem!!
with Glimpse 2.0 Beta 1 and ASP.NET Core RC2.

Same problem...

I think we have to wait until Glimpse 2.0 Beta 2...

https://github.com/Glimpse/Glimpse.Prototype/issues/123

Any ETA for beta 2?

Ping @avanderhoorn this is taking a little too long ;)

@shanselman: maybe they are waiting for ASP. NET Core RTM due at the end of June?  :-)

We are in fact working on RTM support right now. 😄
There's another issue tracking this very thing over at https://github.com/Glimpse/Glimpse.Prototype/issues/123, so I'm going to close this issue in favor of that one.


Fix stack overflow where window resize would constantly emit the restore event

Summary
There seems to be a case on some Linux installs where the restore event will be emitted every time the window is resized. In the resizeScreen function, this was causing a stack overflow. This PR stops the handler from being called more than once unless explicitly needed.
Ticket Link
Fixes #2098
NONE

@amyblais This will need to go into v5.1, do we need a JIRA ticket?

Opened a ticket: https://mattermost.atlassian.net/browse/MM-44117.

Cherry pick is scheduled.


ruff: Use --output-format=json

Switch to JSON format for ruff, which should - ideally - be easier to work with and have less breaking changes.
One new 'feature' is that SyntaxErrors are now reported correctly (they don't have a rule code, which makes them special).
ruff check --output-format=json is supported since ruff v0.2.0

This one maybe needs some testing. It works for me so far, tested a bit with lint.select = ["ALL"] to stress test it.

Now rebased

Nice, thanks :)


smart edgebug???

this is possible?
you jump and cheat autostrafe you to edge
or cheat  automatic ducking or standing for you
not frame skiping or something like this
i just want to know this is possible or not?
this goes to the "question" labels

@oxiKKK  how u thinking this is possible ?

Hi. Well, this would be quite complicated to implement however, I think that it's possible.. At least help you to duck/stand up automatically in order to hit the edge. Maybe even speed up a little bit, as you said. Yeah, that would be possible but complicated to implement.
Also, depending on your velocity, ping, fps, etc - this would affect greatly the accuracy of the resulted approximation.
Having said that, I will consider implementing this sometime in the future.

Hi. Well, this would be quite complicated to implement however, I think that it's possible.. At least help you to duck/stand up automatically in order to hit the edge. Maybe even speed up a little bit, as you said. Yeah, that would be possible but complicated to implement.
Also, depending on your velocity, ping, fps, etc - this would affect greatly the accuracy of the resulted approximation.
Having said that, I will consider implementing this sometime in the future.

oh , If it's really possible to implement it, I'm really looking forward to it.

Hi. Well, this would be quite complicated to implement however, I think that it's possible.. At least help you to duck/stand up automatically in order to hit the edge. Maybe even speed up a little bit, as you said. Yeah, that would be possible but complicated to implement.
Also, depending on your velocity, ping, fps, etc - this would affect greatly the accuracy of the resulted approximation.
Having said that, I will consider implementing this sometime in the future.

can I find out how it will be implemented (even if approximately)

Hi. Well, this would be quite complicated to implement however, I think that it's possible.. At least help you to duck/stand up automatically in order to hit the edge. Maybe even speed up a little bit, as you said. Yeah, that would be possible but complicated to implement.
Also, depending on your velocity, ping, fps, etc - this would affect greatly the accuracy of the resulted approximation.
Having said that, I will consider implementing this sometime in the future.

can I find out how it will be implemented? (even if approximately)

never.


Setup React framework

This issue tracks setting up React for our project. The end goal is to implement a dummy page (e.g. hello world) and deploy it. Front end prototype will be tracked separately.

Done via #41


[Docs] Improve legibility of supported platforms in Meshery README

Description
The table  in the Meshery README.md containing supported platforms has a hyphen to indent each type of platform under its respective category. The hyphens are slightly distracting, making the table less legible.
Expected Behavior
Platforms listed under each category should be indented, but using whitespace ( ) or tabs (	) not hyphens.
Screenshots

I'll like to take this up

Sure @Kennygrace . It has been assigned to you

Gasp! Oh, no. I created this issue not realizing that it is a duplicate of #1436. Another contributor previously took up that issue, and is toiling on it now.
@Kennygrace, could I ask that we get you into another issue so as to avoid overlapping effort?

Okay then

@leecalcote how about we close this issue? Just so it doesn't cause any distractions for new contributors

Sounds real good, @KarenEfereyan.


Question: Why does dep generate two manifests?

Hello.
Why does dep generate manifest.json and lock.json? I'm not a packaging expert, but as a user I'm a little confused because they seem to have very similar information.
manifest.json
{
    "dependencies": {
        "github.com/spf13/cobra": {
            "branch": "master"
        },
        "golang.org/x/crypto": {
            "branch": "master"
        }
    }
}

lock.json
{
    "memo": "172eceebfb9fff13752877d5b1e646fa25d4fd908dd139d9d06de55efa6a539e",
    "projects": [
        {
            "name": "github.com/inconshreveable/mousetrap",
            "branch": "master",
            "revision": "76626ae9c91c4f2a10f34cad8ce83ea42c93bb75",
            "packages": [
                "."
            ]
        },
        {
            "name": "github.com/spf13/cobra",
            "branch": "master",
            "revision": "dc208f4211e7f6df7ec8cb62640f57d3e154910d",
            "packages": [
                "."
            ]
        },
        {
            "name": "github.com/spf13/pflag",
            "branch": "master",
            "revision": "a232f6d9f87afaaa08bafaff5da685f974b83313",
            "packages": [
                "."
            ]
        },
        {
            "name": "golang.org/x/crypto",
            "branch": "master",
            "revision": "40541ccb1c6e64c947ed6f606b8a6cb4b67d7436",
            "packages": [
                "ssh/terminal"
            ]
        },
        {
            "name": "golang.org/x/sys",
            "branch": "master",
            "revision": "d75a52659825e75fff6158388dddc6a5b04f9ba5",
            "packages": [
                "unix"
            ]
        }
    ]
}

It seems like lock.json contains all the information that manifest.json has, and then some. I can definitely see why we don't want to manually edit lock.json, but are we supposed to manually edit manifest.json? Is that why it was pulled out into its own file?
I skimmed through some of the Context documents in the readme, but I didn't see anything that explained this design. Unless I missed something, which totally could have happened.
Anyway, thank you!

Hi - totally reasonable question. Briefly - manifest.json describes user intent, and lock.json describes computed outputs. There's flexibility in manifests that isn't present in locks - not super-obvious in yours, but still there, as the "branch": "master" constraint will match whatever revision master HAPPENS to be at right now, whereas the lock is nailed down to a specific revision.
This flexibility is important because it allows us to provide easy commands (e.g. dep ensure -update) that can manage an update process for you, within the constraints you specify, AND because it allows your project, when imported by someone else, to collaboratively specify the constraints for your own dependencies.
There's some more mechanical information in the gps wiki, or a massively discursive explanation in the article I wrote.


Info Tooltips

Hello Timothy,
It's been awhile since I have mess with macros and I think a great idea to improve the user experience is to add tooltips with info on what each section does within GSE.
The reason is cause I forgot what some of these things do like a simple "keypress" or "premacro" (I have an idea but it could be more clear) and a bunch others instead of going back and forth trying to find the definition of each on the site or online, it can be there in a tooltip.
Like for example mouse over "Step Function" and brief info tooltip comes up explaining each what they do in the simplest form. Or if it can't be done by mouse over, then a small "?" question mark beside or some sort of info icon to click or mouse over to get the tooltip.
I wanted to even suggest like a small intro tutorial on how to create your first macro if no macros are found: It either highlights new or import, etc... But I don't think is as important as having info tooltips everywhere.
Like I said it has been awhile since I actually play, I apologize if maybe you already have had this and I might of overlooked.

There are better video creators who have made how to use GSE but the tooltips I can do - it will be a bit of work but will get it done.

That appears when you hover your mouse over all the elements.

It makes sense to put them at the top always on the same location rather than floating all over the place. You made it even better!
Awesome, thanks again Timo!

In GSE 2.6.52, I have noticed that some tooltips are displayed at the top while others are at the bottom (anda also: tooltips on the Options window follow the mouse cursor).  I don't know if this difference is on purpose, but it's not really annoying.
Timothy, have you planned (for GSE 3) to make all tooltips appear next to the mouse cursor?

The tooltip anchor to the position of the box and the field within the box and are positioned by WoW based on where the window is and the realestate about it. They are not something I have a great deal of control over.  The choice I have is to either have them or not.
TimothyLuke

On 25 May 2021, at 3:02 am, xan2622 @.***> wrote:

In GSE 2.6.52, I have noticed that some tooltips are displayed at the top while others are at the bottom (anda also: tooltips on the Options window follow the mouse cursor). I don't know if this difference is on purpose, but it's not really annoying.
Timothy, have you planned (for GSE 3) to make all tooltips appear next to the mouse cursor?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or unsubscribe.

The other part to this is that if the tooltip is tied to the mouse it means you can’t see what you are typing as the tooltip appears over the box.


Find some way to prioritize newly added welcome messages

The current system of selecting a welcome message when someone is inducted into the CSS Discord server is a random pick from the list of messages in the welcome_messages.json file. It has been discussed to allow members to add their own custom welcome messages. However, because these would just be added to the list of possible welcome messages, there is no guarantee that theirs will be shown.
Therefore, there should be a way to prioritise newly added welcome messages until after a certain time period has elapsed, at which point the selection process would return to being random. This could possibly be done by loading the welcome messages into a database?

All of that said - instead of using a database, what about altering the messages.json schema to be like this?
{
    "welcome_messages":
        "<User> just joined. Everyone, look busy!",
        ["<User> joined the CSS party.", "2023-08-22"],
    ]
}

In this example, the normal messages are just strings, but the prioritised messages are an array with a message and a date added. This way, you could then weight those messages higher for a certain amount of time (eg. 30 days) until dropping back down to normal like the rest.

This is unnecessary & the list will just be updated to have higher quality messages

This is unnecessary & the list will just be updated to have higher quality messages


The TypeScript language service died

Issue Type: Bug
Getting error message saying, "The TypeScript language service died unexpectedly 5 times in the last 5 Minutes."
VS Code version: Code 1.66.2 (Universal) (dfd34e8260c270da74b5c2d86d61aee4b6d56977, 2022-04-11T07:49:20.994Z)
OS version: Darwin x64 20.6.0
Restricted Mode: No
Extensions (27)

Extension
Author (truncated)
Version

aessoft-class-autocomplete
AES
0.1.0

vscode-angular2-files
ale
1.6.4

ng-template
Ang
13.3.2

gitstash
art
5.1.0

atlascode
atl
2.10.12

codestream
Cod
12.16.0

gitignore
cod
0.7.0

bracket-pair-colorizer
Coe
1.0.62

vscode-eslint
dba
2.2.2

githistory
don
0.6.19

gitlens
eam
12.0.6

prettier-vscode
esb
9.5.0

auto-close-tag
for
0.5.14

auto-complete-tag
for
0.1.0

auto-rename-tag
for
0.1.10

beautify
Hoo
1.5.0

githd
hui
2.2.4

angular2-switcher
inf
0.3.4

vscode-docker
ms-
1.22.0

vscode-typescript-tslint-plugin
ms-
1.3.4

debugger-for-chrome
msj
4.13.0

tsimporter
pmn
2.0.1

vscode-commons
red
0.0.6

vscode-yaml
red
1.7.0

vscode-sort-json
ric
1.20.0

autoimport
ste
1.5.4

gitblame
wad
8.1.0

Does this reproduce in the latest VS Code insiders build with all extensions disabled?

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


[to be discussed] Epic: improving the home page

Epic
Improving the home page
Navigation and context for home page

[ ] #1193
[ ] #1195
[ ] #1209
[ ] #1217

Workflows

[ ] #1196
[ ] #1197
[later] Add block "Activity" to home page
[later] Add block "Import suggestions" to home page

Sketches

For now it will be these badges. In the future we will introduce other statuses, so prepare for scalability in your code. We'll make sure it does not look cluttered.


build: remove python-semantic-release as project dependency

✨ Context
We use python-semantic-release for releasing the python package as part of our CI/CD. However, there is no reason why this package is a project dependency. As suggested by @project-defiant we could just remove it from the poetry TOML.
🛠 What does this PR implement
Updates poetry TOML and poetry lock to remove python-semantic-release as a project dependency.
🚦 Before submitting

[x] Do these changes cover one single feature (one change at a time)?
[x] Did you read the contributor guideline?
[x] Did you make sure to update the documentation with your changes?
[x] Did you make sure there is no commented out code in this PR?
[x] Did you follow conventional commits standards in PR title and commit messages?
[x] Did you make sure the branch is up-to-date with the dev branch?
[x] Did you write any new necessary tests?
[x] Did you make sure the changes pass local tests (make test)?
[x] Did you make sure the changes pass pre-commit rules (e.g poetry run pre-commit run --all-files)?

closes #643


[Bug] PDF does not download, no response after clicking

Is there an existing issue for this?

[X] Yes, I have searched the existing issues and none of them match my problem.

Product Variant
Self-Hosted
Current Behavior
Clicking on Download PDF or export PDF has it do the circle loading animation, then just stops.
Expected Behavior
Downloads the PDF
Steps To Reproduce
No response
What browsers are you seeing the problem on?
Chrome, Microsoft Edge
What template are you using?
None
Anything else?
Using this docker compose. Both domains are using cloudflared, the public url points to the ip :5160, Storageurl checks the url with the /default then sends it to ip:5140
version: "3.8"

# In this Docker Compose example, it assumes that you maintain a reverse proxy externally (or chose not to).
# The only two exposed ports here are from minio (:9000) and the app itself (:3000).
# If these ports are changed, ensure that the env vars passed to the app are also changed accordingly.

services:
  # Database (Postgres)
  postgres:
    image: postgres:15-alpine
    restart: unless-stopped
    volumes:
      - /mnt/user/appdata/ReactiveResume/db:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: postgres
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -d postgres"]
      interval: 10s
      timeout: 5s
      retries: 5

  # Storage (for image uploads)
  minio:
    image: minio/minio
    restart: unless-stopped
    command: server /data
    ports:
      - 5140:9000
    volumes:
      - /mnt/user/appdata/ReactiveResume/minio:/data
    environment:
      MINIO_ROOT_USER: minioadmin
      MINIO_ROOT_PASSWORD: minioadmin

  # Chrome Browser (for printing and previews)
  chrome:
    image: ghcr.io/browserless/chromium:latest
    restart: unless-stopped
    extra_hosts:
      - host.docker.internal:host-gateway
    environment:
      TIMEOUT: 10000
      CONCURRENT: 10
      TOKEN: chrome_token
      EXIT_ON_HEALTH_FAILURE: true
      PRE_REQUEST_HEALTH_CHECK: true

  # Redis (for cache & server session management)
  redis:
    image: redis:alpine
    restart: unless-stopped
    command: redis-server --requirepass password

  app:
    image: amruthpillai/reactive-resume:latest
    restart: unless-stopped
    ports:
      - 5160:3000
    depends_on:
      - postgres
      - minio
      - redis
      - chrome
    environment:
      # -- Environment Variables --
      PORT: 3000
      NODE_ENV: production

      # -- URLs --
      PUBLIC_URL: https://resume.xxxx
      STORAGE_URL: http://resume.xxxx/default

      # -- Printer (Chrome) --
      CHROME_TOKEN: chrome_token
      CHROME_URL: ws://chrome:3000

      # -- Database (Postgres) --
      DATABASE_URL: postgresql://postgres:postgres@postgres:5432/postgres

      # -- Auth --
      ACCESS_TOKEN_SECRET: xxx
      REFRESH_TOKEN_SECRET: xxx

      # -- Emails --
      MAIL_FROM: xxx
      # SMTP_URL: smtp://user:pass@smtp:587 # Optional

      # -- Storage (Minio) --
      STORAGE_ENDPOINT: minio
      STORAGE_PORT: 9000
      STORAGE_REGION: us-east-1 # Optional
      STORAGE_BUCKET: default
      STORAGE_ACCESS_KEY: minioadmin
      STORAGE_SECRET_KEY: minioadmin
      STORAGE_USE_SSL: false

      # -- Cache (Redis) --
      REDIS_URL: redis://default:password@redis:6379

Looking at the app logs I'm getting
Trace: TargetCloseError: Protocol error (IO.read): Target closed
    at CallbackRegistry.clear (/app/node_modules/.pnpm/puppeteer-core@22.6.1/node_modules/puppeteer-core/lib/cjs/puppeteer/common/CallbackRegistry.js:72:36)
    at CdpCDPSession._onClosed (/app/node_modules/.pnpm/puppeteer-core@22.6.1/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/CDPSession.js:101:25)
    at #onClose (/app/node_modules/.pnpm/puppeteer-core@22.6.1/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/Connection.js:157:21)
    at WebSocket.<anonymous> (/app/node_modules/.pnpm/puppeteer-core@22.6.1/node_modules/puppeteer-core/lib/cjs/puppeteer/node/NodeWebSocketTransport.js:47:30)
    at callListener (/app/node_modules/.pnpm/ws@8.16.0/node_modules/ws/lib/event-target.js:290:14)
    at WebSocket.onClose (/app/node_modules/.pnpm/ws@8.16.0/node_modules/ws/lib/event-target.js:220:9)
    at WebSocket.emit (node:events:518:28)
    at WebSocket.emit (node:domain:488:12)
    at WebSocket.emitClose (/app/node_modules/.pnpm/ws@8.16.0/node_modules/ws/lib/websocket.js:265:10)
    at Socket.socketOnClose (/app/node_modules/.pnpm/ws@8.16.0/node_modules/ws/lib/websocket.js:1289:15) {
  cause: ProtocolError
      at <instance_members_initializer> (/app/node_modules/.pnpm/puppeteer-core@22.6.1/node_modules/puppeteer-core/lib/cjs/puppeteer/common/CallbackRegistry.js:93:14)
      at new Callback (/app/node_modules/.pnpm/puppeteer-core@22.6.1/node_modules/puppeteer-core/lib/cjs/puppeteer/common/CallbackRegistry.js:97:16)
      at CallbackRegistry.create (/app/node_modules/.pnpm/puppeteer-core@22.6.1/node_modules/puppeteer-core/lib/cjs/puppeteer/common/CallbackRegistry.js:22:26)
      at Connection._rawSend (/app/node_modules/.pnpm/puppeteer-core@22.6.1/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/Connection.js:80:26)
      at CdpCDPSession.send (/app/node_modules/.pnpm/puppeteer-core@22.6.1/node_modules/puppeteer-core/lib/cjs/puppeteer/cdp/CDPSession.js:66:33)
      at Object.pull (/app/node_modules/.pnpm/puppeteer-core@22.6.1/node_modules/puppeteer-core/lib/cjs/puppeteer/common/util.js:252:63)
      at ensureIsPromise (node:internal/webstreams/util:185:19)
      at readableStreamDefaultControllerCallPullIfNeeded (node:internal/webstreams/readablestream:2354:5)
      at node:internal/webstreams/readablestream:2359:9
      at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
}
    at PrinterService.generateResume (/app/dist/apps/server/main.js:13261:21)
    at async PrinterService.printResume (/app/dist/apps/server/main.js:13158:21)
    at async ResumeService.printResume (/app/dist/apps/server/main.js:13993:21)
    at async ResumeController.printResume (/app/dist/apps/server/main.js:13615:25)

I've looked at similar issues but it seems to still happen anyways

Would suggest trying the suggestions I placed in this comment ( https://github.com/AmruthPillai/Reactive-Resume/issues/1828#issuecomment-2017239665 ) - it appears to have worked for a number of other people, and it may work for you as well.


How I can use it with objc?

Hi! Sorry, Parchment only works with Swift. It relies pretty heavily on generics, so it would require a substantial rewrite to get it working for Objective-C. I don't have any plans to support objc at the moment, but I might consider that in the future.

@rechsteiner thanks. Thank you btw. It's a great library.

Thanks 🙌


Make Naming Consistent Again!

Current Capabilities:

"Import" - Opens a file of some format which adds data to the analysis.
"Export" - Saves some portion of the analysis as the appropriate format (Image, Fasta, Newick, etc.)

Future Capabilities:

"Open" - Open a save file.
"Save" - Saves the entire analytical session (including data and configurations).

Accomplished this in the last few weeks.


Fix main window maximizing from splash

The code checks whether the initial window starts maximized, if so, prevents the splash from starting maximized and leaves the main window maximized.

I get your idea, I will just propose a few changes


prepare viewModel

Add skeleton code in viewModel to main branch for easier collaboration between GUI and Backend branches.

[x] Change viewModel class to public
[ ] Make it able to notify view when variables change
[ ] Create variable string inputExpression which implements onpropertychanged
[ ] Create variable string calculationResult implements onpropertychanged
[x] function named calculator() exists

The commit 35ab440 solved parts of the checklist

Implemented with:
ef8b9bdda2207764734b0b04d658d7293beb9c9a
ffc35146eeb045525179a261d970b259e385d601
a13982ef36eff1fda89203c019b85c22215c7ca0


Add help text to argparse

Small PR that adds help text to rotop, making it a bit simpler to understand the options for new users.
You can also adapt the text if you want. I just think giving some more information is helpful. Otherwise some things are not clear, e.g. "--csv" could also expect a file name afterwards.
Current output:
➜  python3 main.py --help
usage: main.py [-h] [--interval INTERVAL] [--filter FILTER] [--csv] [--gui]
               [--num_process NUM_PROCESS] [--only_ros]

rotop: top for ROS 2, version 0.0.0

options:
  -h, --help            show this help message and exit
  --interval INTERVAL   Update interval in seconds. Similar to the -d option of top.
  --filter FILTER       Only show processes fitting to this regular expression.
  --csv                 Activate saving data to csv file.
  --gui                 Use GUI including plotting of CPU loads.
  --num_process NUM_PROCESS
                        Maximum number of processes that will be shown.
  --only_ros            List only ROS 2 node processes.

Thank you for your contribution!


MountedTraversal.pathToNode() potentially returns descendants

Please correct me if I'm wrong, but I think the implementation of the MountedTraversal.js:pathToNode() function is flawed.
Consider this slice of a DOM:

        First Root

          First Child

            Second Child

              First Grand Child

              Second Grand Child

      Second Root

If I call pathToNode() like so:
const node = document.querySelector('div[data-name="firstChild"]');
const root = document.querySelector('div[data-name="reactRoot"]');

const result = pathToNode(node, root);

...then I get the div[data-name="secondChildChildren"] element as the last element in the result array, yet that is not a parent/ancestor of the node, it is a descendant.
Am I missing something, or is this a legitimate problem?

This is what I come up with as a "trace" for the execution of the above problematic case:
# Loop 0
current  = reactRoot
children = [irrelevant1, irrelevant2, wrapper]
path     = [reactRoot]
queue    = [irrelevant1, irrelevant2, wrapper]

# Loop 1
current  = wrapper
children = [firstRootWrapper, secondRoot]
path     = [reactRoot, wrapper]
queue    = [irrelevant1, irrelevant2, firstRootWrapper, secondRoot]

# Loop 2
current  = secondRoot
children = []
path     = [reactRoot, wrapper]
queue    = [irrelevant1, irrelevant2, firstRootWrapper]

# Loop 3
current  = firstRootWrapper
children = [firstRoot, firstRoot-children]
path     = [reactRoot, wrapper, firstRootWrapper]
queue    = [irrelevant1, irrelevant2, firstRoot, firstRoot-children]

# Loop 4
current  = firstRoot-children
children = [firstChild, secondChild-children]
path     = [reactRoot, wrapper, firstRootWrapper]
queue    = [irrelevant1, irrelevant2, firstRoot, firstChild, secondChild-children]

# Loop 5
current  = secondChild-children
children = [firstGrandChild, secondGrandChild]
path     = [reactRoot, wrapper, firstRootWrapper, secondChild-children]
queue    = [irrelevant1, irrelevant2, firstRoot, firstChild, firstGrandChild, secondGrandChild]

# Loop 6
current  = secondGrandChild
children = []
path     = [reactRoot, wrapper, firstRootWrapper, secondChild-children]
queue    = [irrelevant1, irrelevant2, firstRoot, firstChild, firstGrandChild]

# Loop 7
current  = firstGrandChild
children = []
path     = [reactRoot, wrapper, firstRootWrapper, secondChild-children]
queue    = [irrelevant1, irrelevant2, firstRoot, firstChild]

# Loop 8
current  = firstChild
children = []
path     = [reactRoot, wrapper, firstRootWrapper, secondChild-children]
queue    = [irrelevant1, irrelevant2, firstRoot]

That manual trace is consistent with the results I actually get when calling the function.
So the problem is that secondChild-children is returned in the path result, when it is a descendent of the input node.
...I just realised that the version of Enzyme I have been using differs from the one in master and it looks as if the master version has fixed the problem, but I need to confirm that.

Which version of enzyme are you using?

2.6.0
Updated the original post to reflect that, sorry.

Can you try on v2.7.1? I think this might have been fixed by any or all of #713, #691, #677.

@ljharb Yep, that's done the trick.
Thank you for your help.


Remove upperbound for torch version

I just figured out the solution for the previously failed tests. Let's see if we can pass all the tests now.
cc @haifeng-jin

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

Project coverage is 57.28%. Comparing base (aff01af) to head (dc4c518).

Files
Patch %
Lines

keras/src/backend/torch/core.py
0.00%
4 Missing :warning:

:exclamation:  There is a different number of reports uploaded between BASE (aff01af) and HEAD (dc4c518). Click for more details.
HEAD has 6 uploads less than BASE

Flag
BASE (aff01af)
HEAD (dc4c518)

keras
4
1

keras-torch
1
0

keras-tensorflow
1
0

keras-jax
1
0

Additional details and impacted files
@@             Coverage Diff             @@
##           master   #19956       +/-   ##
===========================================
- Coverage   79.07%   57.28%   -21.79%
===========================================
  Files         499      499
  Lines       46725    46727        +2
  Branches     8622     8623        +1
===========================================
- Hits        36946    26767    -10179
- Misses       8047    18308    +10261
+ Partials     1732     1652       -80

Flag
Coverage Δ

keras
57.28% <0.00%> (-21.65%)
:arrow_down:

keras-jax
?

keras-numpy
57.28% <0.00%> (-0.01%)
:arrow_down:

keras-tensorflow
?

keras-torch
?

Flags with carried forward coverage won't be shown. Click here to find out more.

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


Add Expectation Maximisation style herd-refine method

No literature on this. We have to decide whether this algorithm is even a sensible idea.

Due to the refactor we can now do this very easily by doing recursive calls to reduce and refine:

Set up a solver to reduce the dataset to coreset size = 1
Expand coreset to size 2 with zero (or -1) valued indices (depending on method)
Call refine
Expand coreset to size 3 with zero (or -1) valued indices (depending on method)
Call refine
.....

#870 should fix the behaviour of refine for greedy kernel selection solvers (currently, Kernel Herding and Stein Thinning) as follows: when refine is run on an existing coreset (defined by non-zero weights), it goes through the elements and checks if replacing them with another data point improves the greedy metric.
With this fix, calling refine iteratively seems to converge to a local minimum quickly. For instance, this is what we get with KH, n=10_000, m=1000 and starting from a random coreset:

However, some initial randomisations lead to a slightly better coreset (in terms of MMD). I think experimenting with randomisation can be a good way forward for now.


File not staged after precommit fix modified it

Sometimes it does work, though. I'm not sure how to reliably reproduce the problem.

I'm closing this as I haven't observed it in a while.


Show 22.1 as "stable" in version switcher

Also remove 20.2, which is EOL, from local builds.

This change is


Versioned Inventory Tracker from Forge Patch E not working

Describe the Bug
Hey there, updated to the most recent version of Create fabric (0.5.1f) and noticed the performance of interacting with item vaults was bad with chutes and extracting funnels.
In terms of the belt lag in the following profile the original changes in Patch E only targeted extracting funnels so I guess ignore the BeltInventory.tick() call for the Fabric version, I'll probably make an issue on the Forge version about this. Chutes however still attempt insertion/extraction into full item vaults causing lag. This also applies to extracting item vaults.
Feel free to ask if you need more information. Also thanks for the rapid fix with the other issue I reported earlier about train schedules.
https://spark.lucko.me/g7nZiOcBZd
Reproduction Steps

Fill an item vault (lag seems to be more the larger the vault)
Either extract from or or input into it using chutes. Make sure the items cannot go anywhere.
Profile

Expected Result
Performance optimisations from Patch E to work.
Screenshots and Videos
Chutes without overlay (so you can see)

Chutes with performance overlay provided by Observable

Crash Report or Log
No response
Operating System
Windows 10
Mod Version
0.5.1f
Minecraft Version
1.20.1
Other Mods
Lots, seems to be only Create's issue though, based on profile.
Additional Context
No response

I expected this, but getting the release out was priority.
fabric's transfer API has versioning built in, but nothing implements it, and it has an insane default (just calling getVersion increments the version, so it's always different).
I'll need to look deep into how this is used.

I know it's probably not ideal as you'll want to use the transfer API, but could a possible solution for now be to track the version and id just in an integer, like how Create Forge does it:
https://github.com/Creators-of-Create/Create/blob/mc1.18/dev/src/main/java/com/simibubi/create/foundation/blockEntity/behaviour/inventory/VersionedInventoryWrapper.java
If this would work (and if it will be a while until the proper fix is implemented) I may build it for myself with this change, as item vaults perform terribly without this.

That might be viable, but I need to look into it.

ended up doing that. If you want, testing the latest dev build would be helpful.

Okay. Thanks for the fix, this seems to have done it, performance is much better on my world now. Everything seems to work as expected also. I'm gonna close this as issue seems resolved.


Optimize screen refresh

At this moment everything (view contets, frames, intersections) is re-drawed with every event. Only those views that have been modified should be refreshed, unless a resize event is detected.

Closing the issue until we really have this need.


Project ID not set when using emulator (MissingProjectIdError)

Environment details

OS: macOS 10.13.6
Node.js version: 10.15.3
npm version: 6.4.1
@google-cloud/pubsub version: 0.28.1

Steps to reproduce

export PUBSUB_EMULATOR_HOST="..."
export GOOGLE_CLOUD_PROJECT="..."

const {PubSub} = require('@google-cloud/pubsub')

const pubsub = new PubSub()
const [topics] = await pubsub.getTopics()

Expected
List of topics for the project specified in the environment variable for the local emulated Pub/Sub.
Actual
node_modules/@google-cloud/projectify/build/src/index.js:45
            throw new MissingProjectIdError();
            ^

Error: Sorry, we cannot connect to Cloud Services without a project
 ID. You may specify one with an environment variable named
 "GOOGLE_CLOUD_PROJECT".
    at replaceProjectIdToken (node_modules/@google-cloud/projectify/build/src/index.js:45:19)
    at Object.replaceProjectIdToken (node_modules/@google-cloud/projectify/build/src/index.js:38:30)
    at getClient_ (node_modules/@google-cloud/pubsub/build/src/pubsub.js:644:36)
    at PubSub.getClient_ (node_modules/@google-cloud/pubsub/build/src/pubsub.js:623:9)
    at PubSub.request (node_modules/@google-cloud/pubsub/build/src/pubsub.js:638:14)
    at PubSub.getTopics [as getTopics_] (node_modules/@google-cloud/pubsub/build/src/pubsub.js:567:14)
    at makeRequest (node_modules/@google-cloud/paginator/build/src/index.js:240:13)
    at Object.makeRequest (node_modules/@google-cloud/paginator/build/src/index.js:52:27)
    at Transform.stream.once (node_modules/@google-cloud/paginator/build/src/index.js:237:21)
    at Object.onceWrapper (events.js:277:13)

Project ID is not read from the environment variables if the emulator mode is on:
https://github.com/googleapis/nodejs-pubsub/blob/3388fb735b87a8ac817c604cf777a5d8d4e7f833/src/pubsub.ts#L818)
Therefore, it stays equal to placeholder ({{projectId}}) and trouble happens here:
https://github.com/googleapis/nodejs-pubsub/blob/3388fb735b87a8ac817c604cf777a5d8d4e7f833/src/pubsub.ts#L858

What is the solution to this? I am having the same problem

Can you set an explicit projectId?

new PubSub({ projectId: process.env. GOOGLE_CLOUD_PROJECT }) is an obvious workaround.
Still, would be nice to fix the bug. For example, I wanted to use /samples as a quick CLI tool to publish some messages into my local PubSub. Couldn't do it without first modifying the code.

@osrecki Thanks for the work around. I didn't think that was necessary, I am new to pub/sub

new PubSub({ projectId: process.env.GOOGLE_CLOUD_PROJECT }) is an obvious workaround.
Still, would be nice to fix the bug. For example, I wanted to use /samples as a quick CLI tool to publish some messages into my local PubSub. Couldn't do it without first modifying the code.

Is this work?
I'm still getting
{ Error: Sorry, we cannot connect to Cloud Services without a project  ID. You may specify one with an environment variable named  "GOOGLE_CLOUD_PROJECT"}
With this workaround

@osrecki I'm going ahead and closing this issue, since it sounds like you're unblocked.
I've gone ahead and opened this issue, since it does sound like this is a confusing sharp corner on the library.

@guyiluz my guess is that GOOGLE_CLOUD_PROJECT might not be populated in your case, try adding console.info(process.env.GOOGLE_CLOUD_PROJECT) just before executing your library.
If you're continuing to bump into problems, please go ahead and open a new issue with a reproduction.


add button to reset attempt count

sometimes there was an issue with a job. want to retry it after the fix but the attempts are too high and it goes to failed again instead of delayed.
would be nice to be able to reset the attempts count.

Hi @jaroslaw-weber
This sounds like a duplicate job issue, (you want to create a new job with the same data & config) (#426) once implemented, You will be able to add a new job with predefined (duplicated) data & options.
Closing this in favor of #426.
Feel free to reopen if this won't solves your issue.


Fix make build-all

When running make build-all the following is returned:
$ make build-all
Building /home/senzing/senzing.git/go-common/target/darwin-amd64/go-common
Building /home/senzing/senzing.git/go-common/target/linux-amd64/go-common
Building /home/senzing/senzing.git/go-common/target/windows-amd64/go-common
# github.com/senzing/go-common/g2engineconfigurationjson
g2engineconfigurationjson/g2engineconfigurationjson_windows.go:56:47: undefined: context
make: *** [Makefile:73: windows/amd64] Error 1

Pull requests:

https://github.com/Senzing/go-common/pull/85


dev: speed up docker build time of RPC docker image

Currently, building locally the docker/rpc/Dockerfile is WAY too long (~1400s for me locally)
Exploration task of 1 day:
### Tasks
- [ ] identify bottlenecks in the dockerfile build time
- [ ] reduce build time drastically

Fixed by @greged93 the giga chad boss in #849


Model not found locally, downloading from HuggingFace...

Model not found locally, downloading from HuggingFace... Running the COMFYUI, it's taking up VRAM for a long time, pulling COMFYUI up to 50s/it Running the COMFYUI
运行时出现Model not found locally, downloading from HuggingFace...，长时间占用VRAM，把COMFYUI的速度拉到50s/it

Are you using custom nodes that are downloading models from Hugging Face?

model not found! you did not say where to put the models you also do not gave link to download why?

what models? you need to have ollama server running, ollama manages the models etc...
you can pull and work with with any model you like
https://ollama.com/library

model not found! you did not say where to put the models you also do not gave link to download why?

Just make sure you run the Ollama server prior to opening ComfyUI. If it is already running , simple reneter the IP address of the Ollama server and it will refresh the models list


Better handling of sorting values

For example, when the field value is null it would give the following error on this line: unorderable types: NoneType() < str(). In my case I'm using DateTimeField type as the sorting field, which can contain None sometimes.
Also, it would be very useful once it has a support for specifying multiple sorting fields.

Hey @MikiSoft--
Sorry for a delayed response  -- this answer is probably months too late, but I didn't have a chance to do much maintenance work on this package.  Hopefully there will be something helpful here.
The problem with None results in Python 3 is that there's no real generalized way to handle them -- this StackOverflow answer gives a pretty good explanation of the problem.  The solution provided can't really be generalized, though -- if you return an empty string instead of None, that will cause the same type error if a user is sorting a numeric field with None (rather than a string-based field with None).
However, the MultipleModelAPIView allows the user to override the queryList_sort function to implement custom sorting.  Here's a simplified example that would address the None issue -- you'd probably need to tailor it more (for example: I didn't replicate the sort_descending functionality of the original sorting function -- you can look at the MultipleModeMixin source to figure out how to implement that if you need to):
class CustomSortingView(MultipleModelAPIView):
    queryList = (
        ...
    )
    flat = True
    sorting_field = 'my_field_with_nulls'

    def queryList_sort(self, results):
          field = self.sorting_field
          return sorted(results, key=lambda x: x[field] if x[field] else "")


Nit fix: Updated OpenBookQA Readme

The Readme still had the template headline. This was changed to the task name.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


time series - multiple measures to multiple graphs

For something like wheather data it would be nice to have some kind of feature that allows us to see different measures (cloudiness, sunshine, temperature etc) all together.
but since the units of the measures all differ, it doesn't make much sense to show them all in the same graph - rather, you'd want one graph per measure (or rather, per unit) and show these all together on the same page.

Actually it's really annoying that XML/A hs no proper support for the concept of "units" -https://docs.microsoft.com/en-us/sql/analysis-services/schema-rowsets/ole-db-olap/mdschema-measures-rowset That would already help a lot.


2D array datasource in charts

Using a 2D array as a chart dataSource doesn't seem to be supported as of now because I see this error:

E2001 - Invalid data source. See:
http://js.devexpress.com/error/17_2/E2001

Usecase: I'm trying to display cluster data in a scatter chart. It makes sense to represent each cluster as an array and the dataset as an array of clusters, which gives me a 2D array.
data: SampleVM[][]

<dx-chart
    [dataSource]="data">
    <dxi-series *ngFor="let d of data"
                 argumentField="d.male" valueField="d.female">
    </dxi-series>

    <!-- Everything else follows -->
</dx-chart>

Could we have support for 2D arrays please?

Version Info
devexteme version: 17.2.5
devextreme-angular version: 17.2.5

Type of Issue
[ ] Bug Report
[x] Feature Request
[ ] support inquiry

No, our charts don't support 2D arrays. I suggest you open a new support center ticket and describe in great detail why you need to use such arrays.