text:
Moveit error kinematics parameter double humble ursim

seems related to #265 and #278 but it is still not solved for me too
Discussed in https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver/discussions/592

Originally posted by NickBak08 February  7, 2023
Hello,
ROS2 version: humble
First I run this line of code: ros2 run ur_robot_driver start_ursim.sh ur_type:=ur5e
Then I start the drivers: ros2 launch ur_robot_driver ur_control.launch.py ur_type:=ur5e robot_ip:=192.168.56.101 launch_rviz:=true
The next step is too start the moveit example with the ursim but then I get this error. I says that I didn't define the kinematics.yaml. But I didn't change anything to the moveit launch file. What is going wrong?
ros2 launch ur_moveit_config ur_moveit.launch.py ur_type:=ur5e launch_rviz:=true description_pacakge:=ur_description moveit_config_package:=ur_moveit_config
[INFO] [launch]: All log files can be found below /home/nick/.ros/log/2023-02-07-16-01-45-674683-nick-OMEN-by-HP-Laptop-15-dc1xxx-15394
[INFO] [launch]: Default logging verbosity is set to INFO
[INFO] [move_group-1]: process started with pid [15402]
[INFO] [rviz2-2]: process started with pid [15404]
[INFO] [servo_node_main-3]: process started with pid [15406]
[servo_node_main-3] [WARN] [1675782106.823961856] [moveit_servo.servo_node]: Intra-process communication is disabled, consider enabling it by adding:
[servo_node_main-3] extra_arguments=[{'use_intra_process_comms' : True}]
[servo_node_main-3] to the Servo composable node in the launch file
[move_group-1] [WARN] [1675782106.833800588] [move_group.move_group]: Falling back to using the the move_group node namespace (deprecated behavior).
[move_group-1] [INFO] [1675782106.836516169] [moveit_rdf_loader.rdf_loader]: Loaded robot model in 0.00251814 seconds
[move_group-1] [INFO] [1675782106.836550493] [moveit_robot_model.robot_model]: Loading robot model 'ur'...
[move_group-1] [INFO] [1675782106.836562431] [moveit_robot_model.robot_model]: No root/virtual joint specified in SRDF. Assuming fixed joint
[servo_node_main-3] [INFO] [1675782106.836756183] [moveit_rdf_loader.rdf_loader]: Loaded robot model in 0.00496205 seconds
[servo_node_main-3] [INFO] [1675782106.836784917] [moveit_robot_model.robot_model]: Loading robot model 'ur'...
[servo_node_main-3] [INFO] [1675782106.836796940] [moveit_robot_model.robot_model]: No root/virtual joint specified in SRDF. Assuming fixed joint
[servo_node_main-3] [WARN] [1675782106.850179389] [moveit_ros.robot_model_loader]: No kinematics plugins defined. Fill and load kinematics.yaml!
[servo_node_main-3] [INFO] [1675782106.913356333] [moveit_ros.current_state_monitor]: Listening to joint states on topic '/joint_states'
[servo_node_main-3] [INFO] [1675782106.930023590] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Listening to '/attached_collision_object' for attached collision objects
[servo_node_main-3] [INFO] [1675782106.930054889] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Starting planning scene monitor
[move_group-1] [INFO] [1675782106.930262992] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Publishing maintained planning scene on 'monitored_planning_scene'
[move_group-1] [INFO] [1675782106.930444260] [moveit.ros_planning_interface.moveit_cpp]: Listening to 'joint_states' for joint states
[move_group-1] [INFO] [1675782106.932948826] [moveit_ros.current_state_monitor]: Listening to joint states on topic 'joint_states'
[servo_node_main-3] [INFO] [1675782106.933465861] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Listening to '/planning_scene'
[move_group-1] [INFO] [1675782106.933647565] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Listening to '/attached_collision_object' for attached collision objects
[move_group-1] [INFO] [1675782106.933668302] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Starting planning scene monitor
[move_group-1] [INFO] [1675782106.934278935] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Listening to '/planning_scene'
[move_group-1] [INFO] [1675782106.934298780] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Starting world geometry update monitor for collision objects, attached objects, octomap updates.
[servo_node_main-3] [INFO] [1675782106.934373708] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Publishing maintained planning scene on '/servo_node/publish_planning_scene'
[move_group-1] [INFO] [1675782106.934943376] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Listening to 'collision_object'
[move_group-1] [INFO] [1675782106.935472007] [moveit_ros.planning_scene_monitor.planning_scene_monitor]: Listening to 'planning_scene_world' for planning scene world geometry
[move_group-1] [WARN] [1675782106.935696615] [moveit.ros.occupancy_map_monitor.middleware_handle]: Resolution not specified for Octomap. Assuming resolution = 0.1 instead
[move_group-1] [ERROR] [1675782106.935714430] [moveit.ros.occupancy_map_monitor.middleware_handle]: No 3D sensor plugin(s) defined for octomap updates
[move_group-1] [INFO] [1675782106.942403682] [moveit.ros_planning_interface.moveit_cpp]: Loading planning pipeline 'move_group'
[servo_node_main-3] [WARN] [1675782106.948057681] [moveit_servo.servo_calcs]: No kinematics solver instantiated for group 'ur_manipulator'. Will use inverse Jacobian for servo calculations instead.
[servo_node_main-3] [WARN] [1675782106.948092604] [moveit_servo.collision_check]: Collision check rate is low, increase it in yaml file if CPU allows
[move_group-1] [INFO] [1675782106.959439692] [moveit.ros_planning.planning_pipeline]: Using planning interface 'OMPL'
[move_group-1] [INFO] [1675782106.962029381] [moveit_ros.add_time_optimal_parameterization]: Param 'move_group.path_tolerance' was not set. Using default value: 0.100000
[move_group-1] [INFO] [1675782106.962043832] [moveit_ros.add_time_optimal_parameterization]: Param 'move_group.resample_dt' was not set. Using default value: 0.100000
[move_group-1] [INFO] [1675782106.962048986] [moveit_ros.add_time_optimal_parameterization]: Param 'move_group.min_angle_change' was not set. Using default value: 0.001000
[move_group-1] [INFO] [1675782106.962061919] [moveit_ros.fix_workspace_bounds]: Param 'move_group.default_workspace_bounds' was not set. Using default value: 10.000000
[move_group-1] [INFO] [1675782106.962075849] [moveit_ros.fix_start_state_bounds]: Param 'move_group.start_state_max_bounds_error' was set to 0.100000
[move_group-1] [INFO] [1675782106.962081211] [moveit_ros.fix_start_state_bounds]: Param 'move_group.start_state_max_dt' was not set. Using default value: 0.500000
[move_group-1] [INFO] [1675782106.962092104] [moveit_ros.fix_start_state_collision]: Param 'move_group.start_state_max_dt' was not set. Using default value: 0.500000
[move_group-1] [INFO] [1675782106.962097350] [moveit_ros.fix_start_state_collision]: Param 'move_group.jiggle_fraction' was not set. Using default value: 0.020000
[move_group-1] [INFO] [1675782106.962102523] [moveit_ros.fix_start_state_collision]: Param 'move_group.max_sampling_attempts' was not set. Using default value: 100
[move_group-1] [INFO] [1675782106.962113469] [moveit.ros_planning.planning_pipeline]: Using planning request adapter 'Add Time Optimal Parameterization'
[move_group-1] [INFO] [1675782106.962118669] [moveit.ros_planning.planning_pipeline]: Using planning request adapter 'Fix Workspace Bounds'
[move_group-1] [INFO] [1675782106.962122708] [moveit.ros_planning.planning_pipeline]: Using planning request adapter 'Fix Start State Bounds'
[move_group-1] [INFO] [1675782106.962126401] [moveit.ros_planning.planning_pipeline]: Using planning request adapter 'Fix Start State In Collision'
[move_group-1] [INFO] [1675782106.962150331] [moveit.ros_planning.planning_pipeline]: Using planning request adapter 'Fix Start State Path Constraints'
[move_group-1] [INFO] [1675782107.002051818] [moveit.plugins.moveit_simple_controller_manager]: Added FollowJointTrajectory controller for scaled_joint_trajectory_controller
[move_group-1] [INFO] [1675782107.006957148] [moveit.plugins.moveit_simple_controller_manager]: Added FollowJointTrajectory controller for joint_trajectory_controller
[move_group-1] [INFO] [1675782107.007081920] [moveit.plugins.moveit_simple_controller_manager]: Returned 2 controllers in list
[move_group-1] [INFO] [1675782107.007114003] [moveit.plugins.moveit_simple_controller_manager]: Returned 2 controllers in list
[move_group-1] [INFO] [1675782107.008020679] [moveit_ros.trajectory_execution_manager]: Trajectory execution is not managing controllers
[move_group-1] [INFO] [1675782107.008038356] [move_group.move_group]: MoveGroup debug mode is ON
[move_group-1] [INFO] [1675782107.031294522] [move_group.move_group]:
[move_group-1]
[move_group-1] ********************************************************
[move_group-1] * MoveGroup using:
[move_group-1] *     - ApplyPlanningSceneService
[move_group-1] *     - ClearOctomapService
[move_group-1] *     - CartesianPathService
[move_group-1] *     - ExecuteTrajectoryAction
[move_group-1] *     - GetPlanningSceneService
[move_group-1] *     - KinematicsService
[move_group-1] *     - MoveAction
[move_group-1] *     - MotionPlanService
[move_group-1] *     - QueryPlannersService
[move_group-1] *     - StateValidationService
[move_group-1] ********************************************************
[move_group-1]
[move_group-1] [INFO] [1675782107.031331767] [moveit_move_group_capabilities_base.move_group_context]: MoveGroup context using planning plugin ompl_interface/OMPLPlanner
[move_group-1] [INFO] [1675782107.031345376] [moveit_move_group_capabilities_base.move_group_context]: MoveGroup context initialization complete
[move_group-1] Loading 'move_group/ApplyPlanningSceneService'...
[move_group-1] Loading 'move_group/ClearOctomapService'...
[move_group-1] Loading 'move_group/MoveGroupCartesianPathService'...
[move_group-1] Loading 'move_group/MoveGroupExecuteTrajectoryAction'...
[move_group-1] Loading 'move_group/MoveGroupGetPlanningSceneService'...
[move_group-1] Loading 'move_group/MoveGroupKinematicsService'...
[move_group-1] Loading 'move_group/MoveGroupMoveAction'...
[move_group-1] Loading 'move_group/MoveGroupPlanService'...
[move_group-1] Loading 'move_group/MoveGroupQueryPlannersService'...
[move_group-1] Loading 'move_group/MoveGroupStateValidationService'...
[move_group-1]
[move_group-1] You can start planning now!
[move_group-1]
[rviz2-2] [INFO] [1675782107.707477272] [rviz2]: Stereo is NOT SUPPORTED
[rviz2-2] [INFO] [1675782107.707537309] [rviz2]: OpenGl version: 4.6 (GLSL 4.6)
[rviz2-2] [INFO] [1675782107.811221885] [rviz2]: Stereo is NOT SUPPORTED
[rviz2-2] Warning: class_loader.impl: SEVERE WARNING!!! A namespace collision has occurred with plugin factory for class rviz_default_plugins::displays::InteractiveMarkerDisplay. New factory will OVERWRITE existing one. This situation occurs when libraries containing plugins are directly linked against an executable (the one running right now generating this message). Please separate plugins out into their own library or just don't link against the library and use either class_loader::ClassLoader/MultiLibraryClassLoader to open.
[rviz2-2]          at line 253 in /opt/ros/humble/include/class_loader/class_loader/class_loader_core.hpp
[rviz2-2] [ERROR] [1675782110.902594088] [moveit_ros_visualization.motion_planning_frame]: Action server: /recognize_objects not available
[rviz2-2] [INFO] [1675782110.934644009] [moveit_ros_visualization.motion_planning_frame]: MoveGroup namespace changed: / -> . Reloading params.
[rviz2-2] [INFO] [1675782110.999845910] [moveit_rdf_loader.rdf_loader]: Loaded robot model in 0.00395356 seconds
[rviz2-2] [INFO] [1675782110.999899779] [moveit_robot_model.robot_model]: Loading robot model 'ur'...
[rviz2-2] [INFO] [1675782110.999910081] [moveit_robot_model.robot_model]: No root/virtual joint specified in SRDF. Assuming fixed joint
[rviz2-2] [ERROR] [1675782111.014539914] [moveit_background_processing.background_processing]: Exception caught while processing action 'loadRobotModel': parameter 'robot_description_kinematics.ur_manipulator.kinematics_solver_timeout' has invalid type: Wrong parameter type, parameter {robot_description_kinematics.ur_manipulator.kinematics_solver_timeout} is of type {double}, setting it to {string} is not allowed.

Thanks for bringing this up again, I'll look into this ...

I just checked again and this works fine for me. What version are you using?

Built from source? If yes, what are the commit IDs of the description and the driver repo?
From apt package? If yes, which versions of the description and driver are you running?

I had the same error with problem of the parameter type from kinematics.yaml with the binary version of ur_moveit_config package (2.2.10-1jammy.20240126.080424). However, I was trying to run it with use_mock_hardware parameter.
The logs I got were something like this:
ros2 launch ur_moveit_config ur_moveit.launch.py ur_type:=ur5e launch_rviz:=true use_mock_hardware:=true
[...]
[rviz2-2] [ERROR] [1706882016.433182311] [moveit_background_processing.background_processing]: Exception caught while processing action 'loadRobotModel': parameter 'robot_description_kinematics.ur_manipulator.kinematics_solver_timeout' has invalid type: Wrong parameter type, parameter {robot_description_kinematics.ur_manipulator.kinematics_solver_timeout} is of type {double}, setting it to {string} is not allowed.

I find out a simple solution mentioned in the issue #723 (which comes with references from here2022 and here2017 ): the problem (feature) lies in std:stod which parses input according to LC_NUMERIC locale parameter. Try to add LC_NUMERIC=en_US.UTF-8 before you command:
LC_NUMERIC=en_US.UTF-8 ros2 launch ur_moveit_config ur_moveit.launch.py ur_type:=ur5e launch_rviz:=true description_pacakge:=ur_description moveit_config_package:=ur_moveit_config

authors: fmauch gautz macmacal


text:
fix #7 don't wrap values containing parentheses in qoutes

fix for #7

closing due to this solution

source: gharchive/pull-request

repo: Updater/node-sass-json-importer

license: mit

license_type: permissive

license_source: bigquery


text:
Redis critical failure when using GraphQL field aliases (bug)

Describe the bug
When enabling mesh sdk caching using redis, or caching on any underlying service the mesh queries. If we alias a field then the Mesh SDK query itself fails with a null error for the particular aliased field.
GraphQL Mesh SDK Failed (1 errors): Cannot return null for non-nullable field component_configs_selector_field.selector_fields

The alias looks like this
selector {
  fields: selector_fields(order_by: { order_by: asc }) {
     type
     title
   }
}

After investigating it only seems to happen on Redis. The file and inmemory cache both seem to be working as expected with aliased fields returning no problem.
I confirmed it was an alias field issue by going into a Redis GUI and changing the cached response from something like
"selector":{
   "fields":[]
}

To the original unaliased name and that fixed the error (running into an error on the next aliased field though since we rely on aliases heavily.
"selector":{
   "selector_fields":[]
}

To Reproduce
Alias a GraphQL field and use a redis cache (in our case running on a docker pod inside kubernetes).
Expected behavior
Redis caching should work as expected when hooked up via the Mesh SDK Cache config, or when redis caching is enabled on the underlying service itself (i.e our underlyding federated ApolloServer pod)
Environment:

OS:
"@apollo/federation": "^0.14.1",
"@apollo/gateway": "^0.14.1",
"@graphql-mesh/cache-file": "^0.5.10",
"@graphql-mesh/cache-inmemory-lru": "^0.5.5",
"@graphql-mesh/cache-redis": "^0.5.10",
"@graphql-mesh/cli": "^0.2.15",
"@graphql-mesh/config": "^0.4.1",
"@graphql-mesh/graphql": "^0.2.15",
"@graphql-mesh/runtime": "^0.2.15",
"@graphql-mesh/transform-cache": "^0.9.0",
NodeJS: 13.14.0

Additional context
Pretty sure it's an issue directly related to aliases, it is working fine on all other tested caching solutions. Even though the cached response is exactly the same, for example I pulled this from the file cache
 {
  "selector":{
     "fields: [{... data ...}]
  }
]

I'm available to help fix the bug and support as required as this is a high priority issue for our company releasing GraphQL Mesh to production soon. I will just need to be pointed in the right direction, or if you are able to fix the issue no worries. Let me know if/how I can help.

Related https://github.com/Urigo/graphql-mesh/issues/1130

Expanded error:
Error: Cannot return null for non-nullable field component_configs_selector.selector_fields.
    at completeValue (/node_modules/graphql/execution/execute.js:560:13)
    at /node_modules/graphql/execution/execute.js:492:16
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async Promise.all (index 0)
    at async Promise.all (index 0)
    at async Promise.all (index 0)
    at async Promise.all (index 0)
    at localRequester (/dist/runtime/src/get-mesh.js:114:33) {
  locations: [],
  path: [ 'component_configs_vertical_config', 0, 'selector', 'fields' ]
}

@jackedgson Thank you for reporting this issue :)
Could you try with this alpha version?
@graphql-mesh/transform-cache@0.9.1-alpha-158b53d19.0

@ardatan using the latest version, unfortunately still getting the same error.

@jackedgson I tried to fix the issue in this PR https://github.com/Urigo/graphql-mesh/pull/2293 and released the alpha version to let you try and see if it works for you. Does that make sense?

@ardatan yes sorry if I wasn't clear I updated to the latest canary alpha version you mentioned and retried.
I also double checked in the node modules on the kubernetes pod to make sure I was running the alpha version based on a review of the PR I had a look at and I was.
I didn't have luck unfortunately using the alpha version of the cache transform package.
Are there any possibilities you can think of other than this. It was the exact same error related to the ask error on the name of the aliased field.

@jackedgson I need to reproduce it first. If you can create a reproduction repo and even a failing test would be the best for us because I am not able to reproduce it.

Okay, I wonder if it's within the context of a kubernetes pod. Though I can't see why.
I'll aim to create a repo tomorrow.

@jackedgson That would be an awesome step! Thanks

Hey @ardatan, wasn't able to complete this today. We're using hasura under the hood and hasura doesn't play nicely with apollo-federation since it doesn't expose a federated schema.. we're doing a transform of old schema to federated schema however we can't include the actual resolver object in this..
Hasn't been an issue but it very well could be the cause of the problem.

@jackedgson Could you try this version as well?
@graphql-mesh/cache-redis@0.5.11-alpha-9cdc093bb.0

@ardatan Ahh, tried that thank you. I also migrated to make sure we were using the latest version of ioredis.
Unfortunately was seeing the same error, it's such an odd error to me and doesn't make sense no matter what way I look at it. I'm going to spend some more time creating a reproduction if I can of the issue, at the moment just heavy workload so hoping to have the reproduction done sometime this week.
The Mesh is awesome though by the way... kinda unrelated feedback just looking for an opinion.

So in our company we sometimes have 5+ devs working actively on development of the underlying graphql services and the graphql queries the mesh generates from... and there can be multiple changes done on different branches which when all are PRd leads to a bunch of confusing MESH SDK conflicts.

Have you got any ideas for how we can work around this or use the mesh more effectively in a large team environment? If not all good, I'll be spending some time to investigate this for our dev efficiency and am happy to report solutions here that may be able to help future users or mesh development

@ardatan We're currently going to use InMemoryCache as a workaround... We will circle back around to using redis cach and I'll work to create a reproduction branch probably sometimes in the next 3 - 4 weeks. It's in our company backlog and will be addressed, just been deprioritised for the next few weeks :+1:
thanks for all the assistance so far

I don't think this is related to just the cache feature.  I see the same issue with just the gateway and an underlying graphql service.  Any aliased field is coming back as null.

source: gharchive/issue

authors: ardatan aylesm jackedgson jaggad

repo: Urigo/graphql-mesh

license: MIT

license_source: github-api


text:
[Bug]: Service integration broken - Equity bank

Description
Getting above named error when trying to add Equity to accounts
Steps to reproduce
steps:

Open stax app
select add account
search and select equity
add account number
edit equity name
tap refresh balance

Expected result

on click refresh balance icon
get pin prompt
get balce

Actual result
sorry, this service integration is broken
Link to screenshots/screen recordings
https://drive.google.com/file/d/1cseDwLzIql6NXfcHchUZXUeBtTGvGJ0z/view?usp=sharing
Device name
Gionee s8s
Android OS
9.0
Is your phone dual SIM or single SIM?
Dual SIM
Which telco are you using for this test?
Safaricom
Stax device ID or email address
c074faae6ae398cd

This has been fixed with the new release that we will be putting out early next week.

authors: Murithijoshua johnswekenyi

repo: UseHover/Stax


text:
Notice undefined index in the behavior line 84

There is a possibility that for a notice:
        if (empty($data[$field])) {
            unset($data[$field]); // line 84
        }

This will fix it.
        if (isset($data[$field]) && empty($data[$field])) {
            unset($data[$field]);
        }

I'll do a PR if you agree.

Agreed.

authors: burzum jadb

repo: UseMuffin/Tags


text:
GDScript to Wasm compiler (copy approach from Erlang)

https://blog.erlang.org/the-road-to-the-jit/
https://github.com/erlang/otp/pull/2745

Track in godot engine proposal.


text:
Referees Expire

Set an expires_at date for all referees. This should be +7 days from the date that the V/T application was submitted_at by the member.
If a referee fails to reply within 7 days, the application should be cancelled (perhaps create a new status as it doesn't fit into either Withdrawn, Rejected or Expired Automatically).
Emails to referees should be updated to ensure it is clear that they have 7 days.

It might make more sense to allow the candidate to choose another referee or send a reminder to the current referee, rather than cancelling their application and making them go through the process of submitting another application again.
If, after 3 attempts to get the reference (where the candidate has chosen a new referee or chosen to remind the current one), there is still no reference, the application would then be cancelled to free up the training space.
If a candidate does not choose an option within 7 days of the reference expiring, the application is then cancelled.

Agreed. Let's go ahead with that.

authors: CalumTowers NFarrington

repo: VATSIM-UK/core


text:
Unable to determine origin of action from state msg

It seems to me like it is not possible to know whether an action was transmitted to the agv/amr as an instant action or as an node or edge action based on the information provided via the state message.
If i want to get that information just based on the available messages i would have to traverse through all node and edge actions and subtract them from the action states.
Is this an oversight or is there a reason for that ambiguity?

I think there was / is the assumption that the fleet management, which sends both (orders and instant actions), is clever enough to distinguish between (their own) order actions and instant actions by choosing appropriate actions identifiers or has internally another mechanism. Distinguishing between instant actions and order actions inside the state duplicates information which should be already available inside the fleet management.

Then what is the point of having node or edge states? All the fleet manager needs is the last node id, order id and orderupdateid.
The given representation makes it hard for tools that just use the data provided by the defined topics.
I am not under the impression that data size was a concern (e.g. every edge has both nodeids and a sequenzid).

If the fleet management looks only on lastNodeId, lastNodeSequenceId, orderId and orderUpdateId (and actions state array), it cannot determine if the order is still running (maybe yes, but only by observing more than one state message). There is no flag "order finished/failed".
(But in the end, I was not part of the panel when the format was defined. My very personal opinion is, that some fleet management systems have a problem to get all possible information from a single state message (but It's easy for me to talk, I'm on the AGV side). Therefore some information are inside the state which should be already available at the fleet management, to makes life easier. Yes I agree, that makes writing tools harder.)

Why is the fleet manager not able to determine that the order is finished based on lastNodeSequenceId, orderId, orderUpdateId and actions state array?
I am not against adding redundant information. I would like to have all relevant information in the state. The choosen representation is somewhat inconsistent in that regard.
Given the qos 0 of all channels it is impossible to write a tool that displays a somewhat complete state of the robot without another dependency to the fleet manager. The current state message is neither minimal nor consists of the necessary information to reason about why a vehicle does a certain action.

Sorry, little correction: the fleet management system is able to determine if the vehicle has reached the decision point (using the state message as information). Because the fleet management is the source of the order, it should have the information whether the order is finished or not and which actions are parts of the order and which actions (listed inside action state array) are instant actions and not part of the order.
The vehicle itself or third party observer doesn't know if the "order" is finished. The fleet management may or may not send a new order update after the vehicle has reached the decision point. Also a third party observer cannot distinguish if actions inside the action state are actions of an order or instant actions (without observing the order and / or instant action topic).

So given that there is no reason to send edge or node states? i suggest to mark them either as optional to reduce the amount of data transmitted or to extend the action states accordingly. The current design seems to be inefficient and does nothing really well (neither minimal nor consists of all necessary information for third party observer):

authors: Mehno collani-bosch


text:
Full screen map: implement "subsetting mode" for when there is no overlay variable

Requires: https://github.com/VEuPathDB/web-components/issues/421
Extend the useMapMarkers hook to perform filtered and unfiltered calls to map-markers and construct DonutMarkers (cumulative mode) or ChartMarkers in the standard pink/grey colour scheme.
At some point there will be a legend with a radio selector for donut/chart markers.

No longer needed in SAM land

repo: VEuPathDB/web-eda


text:
Network viz: When nodes clicked, their labels should show regardless of if the label is visible

In the network viz, we added the ability to remove node labels from normal view. But, if we click on the nodes, we should override this hidden-label feature and show the node label so that the node label of the highlighted (clicked) node is visible. Clicking the node would not turn on the visibility of the label if it was off, and if the user unclicks a node that node's label should disappear if it's not supposed to be shown (hopefully that all made sense!).
Screenshot of current behavior:
https://github.com/VEuPathDB/web-monorepo/assets/11710234/af03f693-357c-4f88-aeee-a313c3207804

Also in the select/search box, the "All 9 selected" should be "All 9 labels shown" (Danica's suggestion)

Sorry @moontrip the description is confusing 😄 ! Let me try another way:
Right now the label is shown if that node is listed in the Visible Node Labels box, or if the cursor is hovering over the node. However, if we click on a node that is not listed in the VIsible Node Labels box, then its label is not shown. This last part is the part we should flip. So if a node is clicked, the label is shown in the plot, just like on hover. But, (this is the part that gets confusing i think), clicking the node and thus showing the label should not add that node to the Visible Node Labels box if it wasn't already there.
In other words, we should always show the node label when we click on a node. Does that help to clarify? Let me know if there's anything else that doesn't make sense!

@asizemore Thank you for your information. 👍 Now I understand the meaning but I am not quite sure if it is doable without handling the node control (e.g., adding/removing the node label to the list of visible node labels). Is there any specific reason why it should not be added to the Visible Node Labels box?
Another question is the last sentence in the ticket's description, citing "if the user unclicks a node that node's label should disappear if it's not supposed to be shown" Does it mean "if a user clicks the highlighted node again, it should hide the node label" ?  (assuming that highlighted node already showed its node label due to the clicking node action)
I still think that those behaviors are better to be related to Node Lable Control so that UI/UX become consistent for user perspective and it is more doable for implementation aspect (😄). Though I will try your intention at first.

@asizemore I think I made the click event as you described: I was overthinking and spent time too much with complicated logics but I realized that there was a simpler solution later. Please take a look at https://github.com/VEuPathDB/web-monorepo/pull/1130. As far as I know backend servers are not working so I just tested with storybook. I guess it would work with network Viz but will confirm it when the server is ready.
p.s. I also tested the approach I mentioned, i.e., using node control (e.g., adding/removing clicked node label), just in case and I think I found the solution for that too, though it seems that you prefer your suggestions 😅

authors: asizemore bobular moontrip

repo: VEuPathDB/web-monorepo


text:
🛑 b2b MarketingServices is down

In 4965ca2, b2b MarketingServices (https://b2b-marketingservices.de/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: b2b MarketingServices is back up in b636500 after 8 minutes.


text:
🛑 b2b MarketingServices is down

In e89daa7, b2b MarketingServices (https://b2b-marketingservices.de/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: b2b MarketingServices is back up in 6d794a8 after 8 minutes.


text:
Feat/algorithman/console command split quotes

Proper splitting of argument string for console commands, quotes are taken into account as well.

was already open chain

Recreating this one from dev

repo: Valheim-Modding/Jotunn


text:
[ENHANCEMENT] Railtie for configuration

Hello,
I work at a company that has been consuming the validic api directly through our current application. We are starting a new Rails app and would like to continue validic integration.
Currently, this gem supports being setup via an initializer. For all of our service client gems, we build them with Railties and support loading configurations from yml files instead. This allows us to maintain different access tokens per environment, and also allows us to store these secrets in a secret chef repo, and then our chef deployment cook books can write to the yml file (where writing to an intializer ruby file is can be less of a standard format and therefore harder). We also allow the railtie to provide configuration hooks for rails specific things such as configuring your Rails Cache method.
Let me know if you have any suggestions, better ideas, or if this seems like a Pull Request you would be interested in accepting.
Thanks for your time,
Alex

Hi Alex,
Thanks for writing us and for the enhancement request.  What you're asking for makes sense but it might make more sense as a validic-rails specific gem, that way we don't have to couple Rails to this library.
We'd be interested to see what a PR for this would look like though so feel free to submit it here and we can port it over to a new repository if that's the direction we decide to go.
Anthony

Hello,
Thanks for the response. To avoid coupling our ruby service client gems with Rails, we typically add a Rails folder which contains a railtie, and then in your primary file (such as client.rb in this gem's case since it requires all the other files)  you require the railtie if in the context of a rails app using
require 'validic/rails/railtie.rb' if defined? ::Rails
For a simple case like this, the railtie would load a validic.yml config file, and use the values to call the initializer this gem has outlined in the readme. We usually try to use the rails .config_for method or something similar that parses ERB so we can inject our secrets/keys via environment variables (working towards containerized deployments).
This could all still be pulled out into its own validic-rails gem if that still sounds like the best idea.
Thanks,
Alex Bezek

authors: alex-bezek allcentury

repo: Validic/validic


text:
[utils/bugfixes] Added lines for copying missing files and Avoiding downloading the zip file If it's already downloaded (otherwise, It throws an exception.)

Hi SteamAudio / Phonon Team,
Trying to compile Steam Audio (For FMOD) via git submodules (with some Junction Directory linking),
Despite using the setup.py script file, The UAT is reporting some missing files. (Similar behaviour when not copying FMOD libraries, but not related to this problem).
I have fixed this problem by adding some lines related to the missing files and also I fixed some problems when I tried re-running the script (when downloading an existing file, it throws an exception).
I hope these changes are merged or at least A re-implementation for your side
Greetings!

This PR/Branch is deprecated because the changes made in https://github.com/ValveSoftware/steam-audio/pull/259

repo: ValveSoftware/steam-audio


text:
High RAM usage until Crash

Binary Ninja Version: 1.1.1666-dev, f37efedc
Platform: openSUSE Tumbleweed
When analyzing a file (11.5kb in size) with BinaryNinja, RAM usage grows until a crash.  In my use cases, it went as high as 20gb until the OS intervened.
Analysis mode: full
Malware is attached (password: infected)
fef0d99aac2ec06961cf92a14e128e74e513084949b5a5b96c5e2d3a98570fb8.zip
If there is any more information needed please let me know.  Thanks!

Looks like the opaque predicate method this sample is using to insert garbage jumps into the disassembly is causing some worst-case performance problems. Unfortunately, our generic plugin (https://binary.ninja/2017/10/01/automated-opaque-predicate-removal.html) likely won't help a ton because some of the flag setting happens via function calls. That said, it does clean up some of them.
While general improvements to our analysis engine might help, there's unfortunately lots of tricks that bad-performing malware can do to trigger pathological cases in all analysis tools. The good news is there are several work-arounds.
The first and easiest is to simply use the triage plugin (if you're on the latest dev, it's already included in your install but just needs to be copied into your plugin folder to be enabled) and open it in a basic analysis mode. That limits the amount of analysis that attempts to run and makes BN not only much faster, but much more resistant to pathological cases at the cost of not lifting all functions to our higher levels of IL.
The second method would be to open up the binary and enable some analysis limits on functions you'll find that you can keep BN from OOM'ing and crashing during analysis though, again, you won't have complete analysis for the worst behaving functions.
Once you've done that, you could probably write a quick script to scan for conditional branches and NOP them out in trivial cases where the destination is an obvious string (as was the case for a bunch when I just happened to look at it) and then you can save and re-open with the more full featured analysis enabled.
So the short summary is unfortunately there are lots of ways to create worst-case analysis patterns and you can either include stricter limits on our analysis, modify the binary to remove the bad behaving functions.
Hope that helps.

Actually, after poking at this a bit more I think there's something else going on causing our analysis to fail more than it should. Re-opening while I look a bit at it.

Thanks for providing an interesting binary. You can analyze this binary starting with 1.1.1775-dev, and in conjunction with a new setting: 'analysis.conservative.disallowBranchToString'. This adds some bumper guards which prevent analysis from spending too much time down wrong paths.
I have some thoughts for a more generic solution, which centers around prioritizing some of the initial analysis, however that will take some more thinking.

Thanks for looking into this issue, I downloaded the latest version and tried out the option.
Just confirming that it did work and I can now disassemble the sample.

authors: bpotchik psifertex securitykitten


text:
Opening fat Mach-O picks wrong architecture

Version and Platform (required):

Binary Ninja Version: 3.1.3740-dev
OS: macOS
OS Version: 12.5.1
CPU Architecture: M1

Bug Description:
Possibly a dupe of #3500; I didn't investigate the cause.
If I try to open the arm64 slice of a Mach-O containing x86_64 and arm64 slices, it opens the x86_64 one and disassembles it as arm64.
Steps To Reproduce:
Please provide all steps required to reproduce the behavior:

File -> Open; pick libbinaryninjacore.1.dylib from the same Binary Ninja version being run.
At the top of the resulting 'Open with Options' window, where it says "Universal binary detected. Select an object to load", switch from the default "Mach-O 64-bit executable x86_64" to "Mach-O 64-bit executable arm64".
Press Open without changing any other settings.
In the disassembly view, notice that __macho_header at the beginning of the file shows CPU_TYPE_X86_64, and all the function disassemblies are nonsense arm64 instructions, seemingly indicating that the wrong slice was opened.

Additional Information:
Something I noticed which is probably unrelated: At the bottom of the 'Open with Options' window is "* Note: Previously modified settings automatically applied for this file. Show modified settings."  But after clicking "Show modified settings", no settings are displayed (the list of settings goes blank).

As a temporary workaround, you can disable the ui.files.restore.viewOptions setting which obviates the bug I'll push a fix shortly and update.

Fixed in 3.1.3747-dev.
Also, the ui.files.restore.viewOptions setting is now disabled by default.

authors: bpotchik comex


text:
Symbols do not refresh when filtered

Version and Platform (required):

Binary Ninja Version: 4.0.4836-dev, df4290fd
OS: macos
OS Version: 14.3
CPU Architecture: arm64

Steps To Reproduce:

Open any binary
Filter in the symbols view by entering "test"
Rename a function with a name that includes the string "test"
Observe that the function does not appear in the filtered list of symbols

Expected Behavior:
I expect BN to display the newly renamed function in the filtered view.

Fixed in 4.0.4840-dev.