Use Moveit with YuMI

Hi @gavanderhoorn, I followed your discussion here to set up the moveit package. The URDF file I use is from this repository which follows the non-standard joints order. When I ran the moveit_planning_execution.launch, The robot in RVIZ didn't match the pose of the robot shown in the robotstudio.
I guess the problem is from the published joint states, the name order in the message mismatch the order defined in URDF file.
header:
  seq: 91
  stamp:
    secs:<PHONE_NUMBER>
    nsecs: 466701072
  frame_id: ''
name: [yumi_robr_joint_1, yumi_robr_joint_2, yumi_robr_joint_3, yumi_robr_joint_4, yumi_robr_joint_5, yumi_robr_joint_6, yumi_robr_joint_7, yumi_robl_joint_1, yumi_robl_joint_2, yumi_robl_joint_3, yumi_robl_joint_4, yumi_robl_joint_5, yumi_robl_joint_6, yumi_robl_joint_7]
position: [0.0, -2.2689280275926285, -2.356194490192345, 0.5235987755982988, 0.0, 0.6981317007977318, 1.7303211408292425, 0.0, -2.2689280275926285, 2.356194490192345, 0.5235987755982988, 0.0, 0.6981317007977318, -1.7306115585461157]

and the correct order should be
[yumi_robr_joint_1, yumi_robr_joint_2, yumi_robr_joint_7, yumi_robr_joint_3, yumi_robr_joint_4, yumi_robr_joint_5, yumi_robr_joint_6, yumi_robl_joint_1, yumi_robl_joint_2, yumi_robl_joint_7, yumi_robl_joint_3, yumi_robl_joint_4, yumi_robl_joint_5, yumi_robl_joint_6]

I saw your reply to this question and understand there is no way to sort the joint order in the message. I also tried this method but it didn't work.
I'm wondering if there is a good way to keep the joint name match the published data for RVIZ to use?

and the correct order should be

As I was trying to explain in the ROS Answers Q&A you link, there is no correct order -- or more precisely: there is no incorrect order.
Consumers of JointState messages are expected to treat a message like a Python dict, with dict[str, float] as the type. Keys would be elements in the name field, values the elements in position. Lookups for joints would then be based on name, not on index.
Pseudo-code:
states = dict(zip(msg.name, msg.position))
right_joint2_pos = states['yumi_robr_joint_2']

I'm almost certain what you report is not because of any incorrect order, as the RobotModel display in RViz does not care about JointState messages. It uses TF, which is broadcast by the robot_state_publisher). And the RSP does what I wrote above (not exactly, but basically the same).
We're going to need more information in order to help you, as

the robot in RVIZ didn't match the pose of the robot shown in the robotstudio.

is not enough.

@gavanderhoorn I probably didn't make it clear in my first post. It's not about the name order, but the mapping from the name to position in the message. In position, the joint is given in the order joint 1,2,7,3,4,5,6 and doesn't match the above name.
From the pedant, the value for the right arm is

and because of the mismatch problem (I doubt), the robot in RIVZ looked like this

Besides, what else info do you need? Do I need to upload my moveit_planning_execution.launch, ex3_controllers.yaml and moveit_planning_execution.launch? These are all files that I modified

Could you please run abb_robot_bringup_examples/launch/ex3_rws_and_egm_yumi_robot.launch with debug:=true (and perhaps even with --screen appended to the roslaunch args)?
And of course make sure to update whatever parameters needed for your specific setup.
Then post the complete output here in a code block.

The output below is running with ex3_rws_and_egm_yumi_robot.launch using the default parameters. There are mismatch problems in standardized_joints.
SUMMARY
========

PARAMETERS
 * /rosdistro: melodic
 * /rosversion: 1.14.10
 * /yumi/egm/egm_state_controller/publish_rate: 250
 * /yumi/egm/egm_state_controller/type: abb_egm_state_con...
 * /yumi/egm/joint_group_velocity_controller/joints: ['yumi_robl_joint...
 * /yumi/egm/joint_group_velocity_controller/type: velocity_controll...
 * /yumi/egm/joint_position_trajectory_controller/joints: ['yumi_robl_joint...
 * /yumi/egm/joint_position_trajectory_controller/type: position_controll...
 * /yumi/egm/joint_state_controller/publish_rate: 250
 * /yumi/egm/joint_state_controller/type: joint_state_contr...
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_1/d: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_1/i: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_1/i_clamp: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_1/p: 100
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_2/d: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_2/i: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_2/i_clamp: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_2/p: 100
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_3/d: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_3/i: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_3/i_clamp: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_3/p: 100
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_4/d: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_4/i: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_4/i_clamp: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_4/p: 100
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_5/d: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_5/i: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_5/i_clamp: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_5/p: 100
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_6/d: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_6/i: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_6/i_clamp: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_6/p: 100
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_7/d: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_7/i: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_7/i_clamp: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robl_joint_7/p: 100
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_1/d: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_1/i: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_1/i_clamp: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_1/p: 100
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_2/d: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_2/i: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_2/i_clamp: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_2/p: 100
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_3/d: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_3/i: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_3/i_clamp: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_3/p: 100
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_4/d: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_4/i: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_4/i_clamp: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_4/p: 100
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_5/d: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_5/i: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_5/i_clamp: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_5/p: 100
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_6/d: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_6/i: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_6/i_clamp: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_6/p: 100
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_7/d: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_7/i: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_7/i_clamp: 1
 * /yumi/egm/joint_velocity_trajectory_controller/gains/yumi_robr_joint_7/p: 100
 * /yumi/egm/joint_velocity_trajectory_controller/joints: ['yumi_robl_joint...
 * /yumi/egm/joint_velocity_trajectory_controller/type: velocity_controll...
 * /yumi/egm_controller_stopper/no_service_timeout: False
 * /yumi/egm_controller_stopper/ros_control/controllers/always_ok_to_start: ['egm_state_contr...
 * /yumi/egm_controller_stopper/ros_control/controllers/ok_to_keep_running: ['egm_state_contr...
 * /yumi/egm_hardware_interface/egm/channel_1/mech_unit_group: rob_l
 * /yumi/egm_hardware_interface/egm/channel_1/port_number: 6511
 * /yumi/egm_hardware_interface/egm/channel_2/mech_unit_group: rob_r
 * /yumi/egm_hardware_interface/egm/channel_2/port_number: 6512
 * /yumi/egm_hardware_interface/joint_limits/yumi_robl_joint_1/has_velocity_limits: True
 * /yumi/egm_hardware_interface/joint_limits/yumi_robl_joint_1/max_velocity: 0.2
 * /yumi/egm_hardware_interface/joint_limits/yumi_robl_joint_2/has_velocity_limits: True
 * /yumi/egm_hardware_interface/joint_limits/yumi_robl_joint_2/max_velocity: 0.2
 * /yumi/egm_hardware_interface/joint_limits/yumi_robl_joint_3/has_velocity_limits: True
 * /yumi/egm_hardware_interface/joint_limits/yumi_robl_joint_3/max_velocity: 0.2
 * /yumi/egm_hardware_interface/joint_limits/yumi_robl_joint_4/has_velocity_limits: True
 * /yumi/egm_hardware_interface/joint_limits/yumi_robl_joint_4/max_velocity: 0.2
 * /yumi/egm_hardware_interface/joint_limits/yumi_robl_joint_5/has_velocity_limits: True
 * /yumi/egm_hardware_interface/joint_limits/yumi_robl_joint_5/max_velocity: 0.2
 * /yumi/egm_hardware_interface/joint_limits/yumi_robl_joint_6/has_velocity_limits: True
 * /yumi/egm_hardware_interface/joint_limits/yumi_robl_joint_6/max_velocity: 0.2
 * /yumi/egm_hardware_interface/joint_limits/yumi_robl_joint_7/has_velocity_limits: True
 * /yumi/egm_hardware_interface/joint_limits/yumi_robl_joint_7/max_velocity: 0.2
 * /yumi/egm_hardware_interface/joint_limits/yumi_robr_joint_1/has_velocity_limits: True
 * /yumi/egm_hardware_interface/joint_limits/yumi_robr_joint_1/max_velocity: 0.2
 * /yumi/egm_hardware_interface/joint_limits/yumi_robr_joint_2/has_velocity_limits: True
 * /yumi/egm_hardware_interface/joint_limits/yumi_robr_joint_2/max_velocity: 0.2
 * /yumi/egm_hardware_interface/joint_limits/yumi_robr_joint_3/has_velocity_limits: True
 * /yumi/egm_hardware_interface/joint_limits/yumi_robr_joint_3/max_velocity: 0.2
 * /yumi/egm_hardware_interface/joint_limits/yumi_robr_joint_4/has_velocity_limits: True
 * /yumi/egm_hardware_interface/joint_limits/yumi_robr_joint_4/max_velocity: 0.2
 * /yumi/egm_hardware_interface/joint_limits/yumi_robr_joint_5/has_velocity_limits: True
 * /yumi/egm_hardware_interface/joint_limits/yumi_robr_joint_5/max_velocity: 0.2
 * /yumi/egm_hardware_interface/joint_limits/yumi_robr_joint_6/has_velocity_limits: True
 * /yumi/egm_hardware_interface/joint_limits/yumi_robr_joint_6/max_velocity: 0.2
 * /yumi/egm_hardware_interface/joint_limits/yumi_robr_joint_7/has_velocity_limits: True
 * /yumi/egm_hardware_interface/joint_limits/yumi_robr_joint_7/max_velocity: 0.2
 * /yumi/egm_hardware_interface/no_service_timeout: False
 * /yumi/egm_hardware_interface/ros_control/controllers/always_ok_to_start: ['egm_state_contr...
 * /yumi/egm_hardware_interface/ros_control/controllers/ok_to_keep_running: ['egm_state_contr...
 * /yumi/rws_service_provider/no_connection_timeout: False
 * /yumi/rws_service_provider/robot_ip: <IP_ADDRESS>
 * /yumi/rws_service_provider/robot_nickname: yumi
 * /yumi/rws_service_provider/robot_port: 80
 * /yumi/rws_state_publisher/no_connection_timeout: False
 * /yumi/rws_state_publisher/polling_rate: 5
 * /yumi/rws_state_publisher/robot_ip: <IP_ADDRESS>
 * /yumi/rws_state_publisher/robot_nickname: yumi
 * /yumi/rws_state_publisher/robot_port: 80

NODES
  /yumi/
    egm_controller_stopper (abb_egm_hardware_interface/egm_controller_stopper)
    egm_hardware_interface (abb_egm_hardware_interface/egm_hardware_interface)
    rws_service_provider (abb_rws_service_provider/rws_service_provider)
    rws_state_publisher (abb_rws_state_publisher/rws_state_publisher)
  /yumi/egm/
    started (controller_manager/spawner)
    stopped (controller_manager/spawner)

auto-starting new master
process[master]: started with pid [2833]
ROS_MASTER_URI=http://localhost:11311

setting /run_id to 6e9926d2-7aab-11eb-a515-000c29d23b0d
process[rosout-1]: started with pid [2844]
started core service [/rosout]
process[yumi/rws_state_publisher-2]: started with pid [2851]
process[yumi/rws_service_provider-3]: started with pid [2852]
process[yumi/egm_hardware_interface-4]: started with pid [2853]
[DEBUG] [1614616228.654920657]: Get ROS parameters (namespace '/yumi/rws_state_publisher')
[DEBUG] [1614616228.655614511]: Check for (optional) parameter 'robot_ip'
[DEBUG] [1614616228.656555995]: Found parameter 'robot_ip'='<IP_ADDRESS>'
[DEBUG] [1614616228.656601785]: Check for (optional) parameter 'robot_port'
[DEBUG] [1614616228.659537513]: Found parameter 'robot_port'='80'
[DEBUG] [1614616228.659610210]: Check for (optional) parameter 'robot_nickname'
process[yumi/egm_controller_stopper-5]: started with pid [2859]
[DEBUG] [1614616228.662343709]: Get ROS parameters (namespace '/yumi/rws_service_provider')
[DEBUG] [1614616228.662807952]: Found parameter 'robot_nickname'='yumi'
[DEBUG] [1614616228.662849417]: Check for (optional) parameter 'no_connection_timeout'
[DEBUG] [1614616228.665142960]: Found parameter 'no_connection_timeout'='0'
[DEBUG] [1614616228.665183526]: Check for (optional) parameter 'polling_rate'
[DEBUG] [1614616228.666488097]: Found parameter 'polling_rate'='5'
[ INFO] [1614616228.666566974]: Initializing...
[DEBUG] [1614616228.667490105]: Check for (optional) parameter 'robot_ip'
[DEBUG] [1614616228.668908842]: Check for (optional) parameter 'no_service_timeout'
process[yumi/egm/started-6]: started with pid [2866]
[DEBUG] [1614616228.670126941]: Found parameter 'no_service_timeout'='0'
[DEBUG] [1614616228.670162024]: Wait for ROS service 'rws/get_robot_controller_description'
[ INFO] [1614616228.670991917]: waitForService: Service [/yumi/rws/get_robot_controller_description] has not been advertised, waiting...
[DEBUG] [1614616228.671905171]: Found parameter 'robot_ip'='<IP_ADDRESS>'
[DEBUG] [1614616228.671970804]: Check for (optional) parameter 'robot_port'
[DEBUG] [1614616228.673464449]: Found parameter 'robot_port'='80'
[DEBUG] [1614616228.673510429]: Check for (optional) parameter 'robot_nickname'
[DEBUG] [1614616228.673940823]: Found parameter 'robot_nickname'='yumi'
[DEBUG] [1614616228.673992128]: Check for (optional) parameter 'no_connection_timeout'
[DEBUG] [1614616228.674894015]: Get ROS parameters (namespace '/yumi/egm_controller_stopper')
[DEBUG] [1614616228.675061083]: Found parameter 'no_connection_timeout'='0'
[ INFO] [1614616228.675135773]: Initializing...
process[yumi/egm/stopped-7]: started with pid [2879]
[DEBUG] [1614616228.678846431]: Check for (optional) parameter 'no_service_timeout'
[DEBUG] [1614616228.679667446]: Found parameter 'no_service_timeout'='0'
[DEBUG] [1614616228.679715369]: Check for (optional) parameter 'ros_control/controllers/ok_to_keep_running'
[DEBUG] [1614616228.680554987]: Found parameter 'ros_control/controllers/ok_to_keep_running'='[egm_state_controller, joint_state_controller]'
[ INFO] [1614616228.683584488]: Initializing...
[ INFO] [1614616228.683991697]: waitForService: Service [/yumi/egm/controller_manager/list_controllers] has not been advertised, waiting...
[DEBUG] [1614616228.987244096]: Robot controller description:
============================================================
= Summary of robot controller at '<IP_ADDRESS>:80'
============================================================
# General Information:
  |- RobotWare version: <IP_ADDRESS>
  |- System name: StateMachineSystem
  |- System type: Virtual Controller
  |- Options:
     |- UDPUC Driver
     |- Contact L
     |- Leadthrough
     |- YuMi AbsAcc Recovery
     |- English
     |- 613-1 Collision Detection
     |- 709-1 DeviceNet Master/Slave
     |- 689-1 Externally Guided Motion (EGM)
     |- 604-1 MultiMove Coordinated
     |- 623-1 Multitasking
     |- 616-1 PC Interface
     |- RobotWare Base
     |- Hall Sensor Calibration
     |- Drive System IRB 14000
     |- IRB 14000-0.5/0.5
     |- IRB 14000-0.5/0.5
     |- IRB 14000-0.5/0.5
     |- StateMachine Core

# Mechanical Units:
  |- Unit: ROB_R
  |- Unit: ROB_R_7
  |- Unit: ROB_L
  |- Unit: ROB_L_7

# Mechanical Unit Groups:
  |- Group: rob_r
  |- Group: rob_l
============================================================
[DEBUG] [1614616228.989714578]: Robot controller description:
============================================================
= Summary of robot controller at '<IP_ADDRESS>:80'
============================================================
# General Information:
  |- RobotWare version: <IP_ADDRESS>
  |- System name: StateMachineSystem
  |- System type: Virtual Controller
  |- Options:
     |- UDPUC Driver
     |- Contact L
     |- Leadthrough
     |- YuMi AbsAcc Recovery
     |- English
     |- 613-1 Collision Detection
     |- 709-1 DeviceNet Master/Slave
     |- 689-1 Externally Guided Motion (EGM)
     |- 604-1 MultiMove Coordinated
     |- 623-1 Multitasking
     |- 616-1 PC Interface
     |- RobotWare Base
     |- Hall Sensor Calibration
     |- Drive System IRB 14000
     |- IRB 14000-0.5/0.5
     |- IRB 14000-0.5/0.5
     |- IRB 14000-0.5/0.5
     |- StateMachine Core

# Mechanical Units:
  |- Unit: ROB_R
  |- Unit: ROB_R_7
  |- Unit: ROB_L
  |- Unit: ROB_L_7

# Mechanical Unit Groups:
  |- Group: rob_r
  |- Group: rob_l
============================================================
[ INFO] [1614616228.990816393]: Initialization succeeded, and the node is ready for use
[INFO] [1614616228.993589]: Controller Spawner: Waiting for service controller_manager/load_controller
[DEBUG] [1614616228.996973924]: Adding basic services
[ INFO] [1614616229.001946243]: waitForService: Service [/yumi/rws/get_robot_controller_description] is now available.
[DEBUG] [1614616229.007354634]: StateMachine Add-In 1.1 detected, adding additional services
[ INFO] [1614616229.010278387]: Initialization succeeded, and the node is ready for use
[ INFO] [1614616229.012306545]: Initializing...
[DEBUG] [1614616229.012348732]: Check for (mandatory) parameter 'robot_controller_description'
[DEBUG] [1614616229.012902889]: Found parameter 'robot_controller_description'='header {
  ip_address: "<IP_ADDRESS>"
  rws_port_number: 80
  robot_ware_version {
    name: "<IP_ADDRESS>"
    major_number: 6
    minor_number: 11
    patch_number: 3
  }
  system_name: "StateMachineSystem"
  system_type: "Virtual Controller"
  options: "UDPUC Driver"
  options: "Contact L"
  options: "Leadthrough"
  options: "YuMi AbsAcc Recovery"
  options: "English"
  options: "613-1 Collision Detection"
  options: "709-1 DeviceNet Master/Slave"
  options: "689-1 Externally Guided Motion (EGM)"
  options: "604-1 MultiMove Coordinated"
  options: "623-1 Multitasking"
  options: "616-1 PC Interface"
  options: "RobotWare Base"
  options: "Hall Sensor Calibration"
  options: "Drive System IRB 14000"
  options: "IRB 14000-0.5/0.5"
  options: "IRB 14000-0.5/0.5"
  options: "IRB 14000-0.5/0.5"
  options: "StateMachine Core"
}
system_indicators {
  robots {
    irb14000: true
  }
  options {
    egm: true
    leadthrough: true
    multimove: true
  }
  addins {
    state_machine_1_1: true
  }
}
mechanical_units_groups {
  name: "rob_r"
  robot {
    name: "ROB_R"
    robot {
      name: "ROB_R"
      type: "ROB_R_14000_05_05"
      joints {
        name: "rob_R_1"
        logical_axis: 1
        kinematic_axis_number: 1
        arm {
          name: "rob_R_1"
          lower_joint_bound: -2.9408801
          upper_joint_bound: 2.9408801
        }
        transmission {
          name: "rob_R_1"
          rotating_move: true
        }
      }
      joints {
        name: "rob_R_2"
        logical_axis: 2
        kinematic_axis_number: 2
        arm {
          name: "rob_R_2"
          lower_joint_bound: -2.50455
          upper_joint_bound: 0.75921798
        }
        transmission {
          name: "rob_R_2"
          rotating_move: true
        }
      }
      joints {
        name: "rob_R_3"
        logical_axis: 3
        kinematic_axis_number: 4
        arm {
          name: "rob_R_3"
          lower_joint_bound: -2.1554799
          upper_joint_bound: 1.39626
        }
        transmission {
          name: "rob_R_3"
          rotating_move: true
        }
      }
      joints {
        name: "rob_R_4"
        logical_axis: 4
        kinematic_axis_number: 5
        arm {
          name: "rob_R_4"
          lower_joint_bound: -5.06145
          upper_joint_bound: 5.06145
        }
        transmission {
          name: "rob_R_4"
          rotating_move: true
        }
      }
      joints {
        name: "rob_R_5"
        logical_axis: 5
        kinematic_axis_number: 6
        arm {
          name: "rob_R_5"
          lower_joint_bound: -1.53589
          upper_joint_bound: 2.40855
        }
        transmission {
          name: "rob_R_5"
          rotating_move: true
        }
      }
      joints {
        name: "rob_R_6"
        logical_axis: 6
        kinematic_axis_number: 7
        arm {
          name: "rob_R_6"
          lower_joint_bound: -3.9967999
          upper_joint_bound: 3.9967999
        }
        transmission {
          name: "rob_R_6"
          rotating_move: true
        }
      }
      base_frame {
        position {
          x: 0
          y: 0
          z: 0
        }
        rotation {
          q1: 1
          q2: 0
          q3: 0
          q4: 0
        }
      }
      base_frame_moved_by: ""
    }
    type: TCP_ROBOT
    task_name: "T_ROB_R"
    axes: 6
    axes_total: 7
    is_integrated_unit: "NoIntegratedUnit"
    has_integrated_unit: "ROB_R_7"
    status: "Synchronized"
    mode: ACTIVATED
    standardized_joints {
      original_name: "rob_R_1"
      standardized_name: "yumi_robr_joint_1"
      rotating_move: true
      lower_joint_bound: -2.9408801
      upper_joint_bound: 2.9408801
    }
    standardized_joints {
      original_name: "rob_R_2"
      standardized_name: "yumi_robr_joint_2"
      rotating_move: true
      lower_joint_bound: -2.50455
      upper_joint_bound: 0.75921798
    }
    standardized_joints {
      original_name: "rob_R_7"
      standardized_name: "yumi_robr_joint_3"
      rotating_move: true
      lower_joint_bound: -2.9408801
      upper_joint_bound: 2.9408801
    }
    standardized_joints {
      original_name: "rob_R_3"
      standardized_name: "yumi_robr_joint_4"
      rotating_move: true
      lower_joint_bound: -2.1554799
      upper_joint_bound: 1.39626
    }
    standardized_joints {
      original_name: "rob_R_4"
      standardized_name: "yumi_robr_joint_5"
      rotating_move: true
      lower_joint_bound: -5.06145
      upper_joint_bound: 5.06145
    }
    standardized_joints {
      original_name: "rob_R_5"
      standardized_name: "yumi_robr_joint_6"
      rotating_move: true
      lower_joint_bound: -1.53589
      upper_joint_bound: 2.40855
    }
    standardized_joints {
      original_name: "rob_R_6"
      standardized_name: "yumi_robr_joint_7"
      rotating_move: true
      lower_joint_bound: -3.9967999
      upper_joint_bound: 3.9967999
    }
  }
  mechanical_units {
    name: "ROB_R_7"
    singles {
      name: "ROB_R_7"
      type: "ROB_R_7"
      joint {
        name: "rob_R_7"
        logical_axis: 7
        kinematic_axis_number: 3
        arm {
          name: "rob_R_7"
          lower_joint_bound: -2.9408801
          upper_joint_bound: 2.9408801
        }
        transmission {
          name: "rob_R_7"
          rotating_move: true
        }
      }
      base_frame {
        position {
          x: 0
          y: 0
          z: 0
        }
        rotation {
          q1: 1
          q2: 0
          q3: 0
          q4: 0
        }
      }
      base_frame_moved_by: ""
    }
    type: SINGLE
    task_name: "T_ROB_R"
    axes: 1
    axes_total: 1
    is_integrated_unit: "ROB_R"
    has_integrated_unit: "NoIntegratedUnit"
    status: "Synchronized"
    mode: ACTIVATED
  }
}
mechanical_units_groups {
  name: "rob_l"
  robot {
    name: "ROB_L"
    robot {
      name: "ROB_L"
      type: "ROB_L_14000_05_05"
      joints {
        name: "rob_L_1"
        logical_axis: 1
        kinematic_axis_number: 1
        arm {
          name: "rob_L_1"
          lower_joint_bound: -2.9408801
          upper_joint_bound: 2.9408801
        }
        transmission {
          name: "rob_L_1"
          rotating_move: true
        }
      }
      joints {
        name: "rob_L_2"
        logical_axis: 2
        kinematic_axis_number: 2
        arm {
          name: "rob_L_2"
          lower_joint_bound: -2.50455
          upper_joint_bound: 0.75921798
        }
        transmission {
          name: "rob_L_2"
          rotating_move: true
        }
      }
      joints {
        name: "rob_L_3"
        logical_axis: 3
        kinematic_axis_number: 4
        arm {
          name: "rob_L_3"
          lower_joint_bound: -2.1554799
          upper_joint_bound: 1.39626
        }
        transmission {
          name: "rob_L_3"
          rotating_move: true
        }
      }
      joints {
        name: "rob_L_4"
        logical_axis: 4
        kinematic_axis_number: 5
        arm {
          name: "rob_L_4"
          lower_joint_bound: -5.06145
          upper_joint_bound: 5.06145
        }
        transmission {
          name: "rob_L_4"
          rotating_move: true
        }
      }
      joints {
        name: "rob_L_5"
        logical_axis: 5
        kinematic_axis_number: 6
        arm {
          name: "rob_L_5"
          lower_joint_bound: -1.53589
          upper_joint_bound: 2.40855
        }
        transmission {
          name: "rob_L_5"
          rotating_move: true
        }
      }
      joints {
        name: "rob_L_6"
        logical_axis: 6
        kinematic_axis_number: 7
        arm {
          name: "rob_L_6"
          lower_joint_bound: -3.9967999
          upper_joint_bound: 3.9967999
        }
        transmission {
          name: "rob_L_6"
          rotating_move: true
        }
      }
      base_frame {
        position {
          x: 0
          y: 0
          z: 0
        }
        rotation {
          q1: 1
          q2: 0
          q3: 0
          q4: 0
        }
      }
      base_frame_moved_by: ""
    }
    type: TCP_ROBOT
    task_name: "T_ROB_L"
    axes: 6
    axes_total: 7
    is_integrated_unit: "NoIntegratedUnit"
    has_integrated_unit: "ROB_L_7"
    status: "Synchronized"
    mode: ACTIVATED
    standardized_joints {
      original_name: "rob_L_1"
      standardized_name: "yumi_robl_joint_1"
      rotating_move: true
      lower_joint_bound: -2.9408801
      upper_joint_bound: 2.9408801
    }
    standardized_joints {
      original_name: "rob_L_2"
      standardized_name: "yumi_robl_joint_2"
      rotating_move: true
      lower_joint_bound: -2.50455
      upper_joint_bound: 0.75921798
    }
    standardized_joints {
      original_name: "rob_L_7"
      standardized_name: "yumi_robl_joint_3"
      rotating_move: true
      lower_joint_bound: -2.9408801
      upper_joint_bound: 2.9408801
    }
    standardized_joints {
      original_name: "rob_L_3"
      standardized_name: "yumi_robl_joint_4"
      rotating_move: true
      lower_joint_bound: -2.1554799
      upper_joint_bound: 1.39626
    }
    standardized_joints {
      original_name: "rob_L_4"
      standardized_name: "yumi_robl_joint_5"
      rotating_move: true
      lower_joint_bound: -5.06145
      upper_joint_bound: 5.06145
    }
    standardized_joints {
      original_name: "rob_L_5"
      standardized_name: "yumi_robl_joint_6"
      rotating_move: true
      lower_joint_bound: -1.53589
      upper_joint_bound: 2.40855
    }
    standardized_joints {
      original_name: "rob_L_6"
      standardized_name: "yumi_robl_joint_7"
      rotating_move: true
      lower_joint_bound: -3.9967999
      upper_joint_bound: 3.9967999
    }
  }
  mechanical_units {
    name: "ROB_L_7"
    singles {
      name: "ROB_L_7"
      type: "ROB_L_7"
      joint {
        name: "rob_L_7"
        logical_axis: 7
        kinematic_axis_number: 3
        arm {
          name: "rob_L_7"
          lower_joint_bound: -2.9408801
          upper_joint_bound: 2.9408801
        }
        transmission {
          name: "rob_L_7"
          rotating_move: true
        }
      }
      base_frame {
        position {
          x: 0
          y: 0
          z: 0
        }
        rotation {
          q1: 1
          q2: 0
          q3: 0
          q4: 0
        }
      }
      base_frame_moved_by: ""
    }
    type: SINGLE
    task_name: "T_ROB_L"
    axes: 1
    axes_total: 1
    is_integrated_unit: "ROB_L"
    has_integrated_unit: "NoIntegratedUnit"
    status: "Synchronized"
    mode: ACTIVATED
  }
}
rapid_tasks {
  name: "T_ROB_R"
  is_motion_task: true
  is_active: true
  execution_state: STOPPED
  modules {
    name: "TRobRAPID"
    type: "ProgMod"
  }
  modules {
    name: "TRobSystem"
    type: "SysMod"
  }
  modules {
    name: "user"
    type: "SysMod"
  }
  modules {
    name: "BASE"
    type: "SysMod"
  }
  modules {
    name: "TRobEGM"
    type: "ProgMod"
  }
  modules {
    name: "TRobSystemExample"
    type: "SysMod"
  }
  modules {
    name: "TRobMain"
    type: "ProgMod"
  }
  modules {
    name: "TRobUtility"
    type: "ProgMod"
  }
}
rapid_tasks {
  name: "T_ROB_L"
  is_motion_task: true
  is_active: true
  execution_state: STOPPED
  modules {
    name: "TRobRAPID"
    type: "ProgMod"
  }
  modules {
    name: "TRobSystem"
    type: "SysMod"
  }
  modules {
    name: "user"
    type: "SysMod"
  }
  modules {
    name: "BASE"
    type: "SysMod"
  }
  modules {
    name: "TRobEGM"
    type: "ProgMod"
  }
  modules {
    name: "TRobSystemExample"
    type: "SysMod"
  }
  modules {
    name: "TRobMain"
    type: "ProgMod"
  }
  modules {
    name: "TRobUtility"
    type: "ProgMod"
  }
}
'
[DEBUG] [1614616229.014125074]: Robot controller description:
============================================================
= Summary of robot controller at '<IP_ADDRESS>:80'
============================================================
# General Information:
  |- RobotWare version: <IP_ADDRESS>
  |- System name: StateMachineSystem
  |- System type: Virtual Controller
  |- Options:
     |- UDPUC Driver
     |- Contact L
     |- Leadthrough
     |- YuMi AbsAcc Recovery
     |- English
     |- 613-1 Collision Detection
     |- 709-1 DeviceNet Master/Slave
     |- 689-1 Externally Guided Motion (EGM)
     |- 604-1 MultiMove Coordinated
     |- 623-1 Multitasking
     |- 616-1 PC Interface
     |- RobotWare Base
     |- Hall Sensor Calibration
     |- Drive System IRB 14000
     |- IRB 14000-0.5/0.5
     |- IRB 14000-0.5/0.5
     |- IRB 14000-0.5/0.5
     |- StateMachine Core

# Mechanical Units:
  |- Unit: ROB_R
  |- Unit: ROB_R_7
  |- Unit: ROB_L
  |- Unit: ROB_L_7

# Mechanical Unit Groups:
  |- Group: rob_r
  |- Group: rob_l
============================================================
[DEBUG] [1614616229.014213100]: Get ROS parameters (namespace: '/yumi/egm_hardware_interface/egm')
[DEBUG] [1614616229.014233826]: Check for 'channel_1' parameter
[DEBUG] [1614616229.015410702]: Found 'channel_1' parameter
[DEBUG] [1614616229.015467884]: Check for (optional) parameter 'egm/channel_1/mech_unit_group'
[DEBUG] [1614616229.016149707]: Found parameter 'egm/channel_1/mech_unit_group'='rob_l'
[DEBUG] [1614616229.016222026]: Check for (mandatory) parameter 'egm/channel_1/port_number'
[DEBUG] [1614616229.016661273]: Found parameter 'egm/channel_1/port_number'='6511'
[DEBUG] [1614616229.016710387]: Port number parameter '6511' found
[DEBUG] [1614616229.016726195]: Check for 'channel_2' parameter
[DEBUG] [1614616229.017229420]: Found 'channel_2' parameter
[DEBUG] [1614616229.017282368]: Check for (optional) parameter 'egm/channel_2/mech_unit_group'
[DEBUG] [1614616229.018054478]: Found parameter 'egm/channel_2/mech_unit_group'='rob_r'
[DEBUG] [1614616229.018105106]: Check for (mandatory) parameter 'egm/channel_2/port_number'
[DEBUG] [1614616229.018582211]: Found parameter 'egm/channel_2/port_number'='6512'
[DEBUG] [1614616229.018631680]: Port number parameter '6512' found
[DEBUG] [1614616229.018646807]: Check for 'channel_3' parameter
[DEBUG] [1614616229.019100705]: Initializing EGM manager
[DEBUG] [1614616229.019152524]: Verifying ROS parameters against the RWS robot controller description
[DEBUG] [1614616229.019232821]: Verified '2' EGM channel configuration(s) against the RWS robot controller description
[DEBUG] [1614616229.019600624]: Check for (optional) parameter 'ros_control/controllers/always_ok_to_start'
[DEBUG] [1614616229.020648453]: Found parameter 'ros_control/controllers/always_ok_to_start'='[egm_state_controller, joint_state_controller]'
[ WARN] [1614616229.025677409]: Configured default soft limits for 'yumi_robr_joint_1': position [-2.91147; 2.91147], k: 1
[ WARN] [1614616229.029176090]: Configured default soft limits for 'yumi_robr_joint_2': position [-2.4795; 0.751626], k: 1
[ WARN] [1614616229.033149706]: Configured default soft limits for 'yumi_robr_joint_3': position [-2.91147; 2.91147], k: 1
[ WARN] [1614616229.036824925]: Configured default soft limits for 'yumi_robr_joint_4': position [-2.13393; 1.3823], k: 1
[ WARN] [1614616229.039883593]: Configured default soft limits for 'yumi_robr_joint_5': position [-5.01084; 5.01084], k: 1
[ WARN] [1614616229.043374950]: Configured default soft limits for 'yumi_robr_joint_6': position [-1.52053; 2.38446], k: 1
[ WARN] [1614616229.047251510]: Configured default soft limits for 'yumi_robr_joint_7': position [-3.95683; 3.95683], k: 1
[ WARN] [1614616229.050440404]: Configured default soft limits for 'yumi_robl_joint_1': position [-2.91147; 2.91147], k: 1
[ WARN] [1614616229.053743285]: Configured default soft limits for 'yumi_robl_joint_2': position [-2.4795; 0.751626], k: 1
[ WARN] [1614616229.056734907]: Configured default soft limits for 'yumi_robl_joint_3': position [-2.91147; 2.91147], k: 1
[ WARN] [1614616229.060592637]: Configured default soft limits for 'yumi_robl_joint_4': position [-2.13393; 1.3823], k: 1
[ WARN] [1614616229.064493245]: Configured default soft limits for 'yumi_robl_joint_5': position [-5.01084; 5.01084], k: 1
[ WARN] [1614616229.067435998]: Configured default soft limits for 'yumi_robl_joint_6': position [-1.52053; 2.38446], k: 1
[ WARN] [1614616229.070995191]: Configured default soft limits for 'yumi_robl_joint_7': position [-3.95683; 3.95683], k: 1
[ INFO] [1614616229.071086677]: Initialization succeeded, and the node is ready for use
[INFO] [1614616229.092674]: Controller Spawner: Waiting for service controller_manager/load_controller
[INFO] [1614616229.095405]: Controller Spawner: Waiting for service controller_manager/switch_controller
[INFO] [1614616229.097242]: Controller Spawner: Waiting for service controller_manager/unload_controller
[INFO] [1614616229.099036]: Loading controller: joint_group_velocity_controller
[ INFO] [1614616229.104008143]: waitForService: Service [/yumi/egm/controller_manager/list_controllers] is now available.
[ INFO] [1614616229.104468399]: Initialization succeeded, and the node is ready for use
[INFO] [1614616229.108686]: Controller Spawner: Loaded controllers: joint_group_velocity_controller
[INFO] [1614616229.298619]: Controller Spawner: Waiting for service controller_manager/switch_controller
[INFO] [1614616229.301790]: Controller Spawner: Waiting for service controller_manager/unload_controller
[INFO] [1614616229.304072]: Loading controller: egm_state_controller
[DEBUG] [1614616229.308028912]: Check for (optional) parameter 'publish_rate'
[DEBUG] [1614616229.308604361]: Found parameter 'publish_rate'='250'
[INFO] [1614616229.347622]: Loading controller: joint_state_controller
[INFO] [1614616229.397656]: Controller Spawner: Loaded controllers: egm_state_controller, joint_state_controller
[ WARN] [1614616229.447331393]: Timed out while waiting for EGM feedback (did the EGM session end on the robot controller?)
[INFO] [1614616229.448553]: Started controllers: egm_state_controller, joint_state_controller
[ WARN] [1614616239.473463225]: Timed out while waiting for EGM feedback (did the EGM session end on the robot controller?)
[ WARN] [1614616249.479388508]: Timed out while waiting for EGM feedback (did the EGM session end on the robot controller?)
[ WARN] [1614616259.494818493]: Timed out while waiting for EGM feedback (did the EGM session end on the robot controller?)
[ WARN] [1614616269.533046412]: Timed out while waiting for EGM feedback (did the EGM session end on the robot controller?)
[ WARN] [1614616279.553165908]: Timed out while waiting for EGM feedback (did the EGM session end on the robot controller?)
[ INFO] [1614616285.314560518]: EGM session state changed: ros_control controllers will be reset
[ INFO] [1614616285.339179074]: Controller has resumed EGM feedback
[ INFO] [1614616296.856430594]: EGM session state changed: ros_control controllers will be reset
[ INFO] [1614616345.878285079]: EGM session state changed: ros_control controllers will be reset
[ WARN] [1614616348.271562105]: Timed out while waiting for EGM feedback (did the EGM session end on the robot controller?)
[ WARN] [1614616348.324430500]: EGM became inactive, stopping controllers not allowed to keep running: [joint_group_velocity_controller]
[ WARN] [1614616358.278322143]: Timed out while waiting for EGM feedback (did the EGM session end on the robot controller?)
^C[yumi/egm/stopped-7] killing on exit
[yumi/egm/started-6] killing on exit
[INFO] [1614616364.955807]: Shutting down spawner. Stopping and unloading controllers...
[INFO] [1614616364.956964]: Stopping all controllers...
[ERROR] [1614616364.959605880]: Could not stop controller 'joint_group_velocity_controller' since it is not running
[INFO] [1614616364.959810]: Unloading all loaded controllers...
 Stopping and unloading controllers...
[INFO] [1614616364.969455]: Stopping all controllers...
[WARN] [1614616364.991742]: Controller Spawner error while taking down controllers: unable to connect to service: connection from sender terminated before handshake header received. 0 bytes were received. Please check sender for additional details.
[WARN] [1614616364.992110]: Controller Spawner error while taking down controllers: unable to connect to service: [Errno 104] Connection reset by peer
[rosout-1] killing on exit
[master] killing on exit
shutting down processing monitor...
... shutting down processing monitor complete
done

Edit 2: ah, I think I may know what's going wrong. You/we're confusing the joint value at index 3 (which is how the ABB controller internally maps things) to what we see/use on the ROS side.
As soon as we're working with JointStates or URDFs, we don't care any more about what the controller does. The abb_robot_driver node does the right thing, and converts whatever internal representation is used to a "normal one" (ie: the 7th joint is in the 7th location, as you'd expect).
joint_7 is the seventh joint in the kinematic chain of each arm, not the third one.
I believe @robberthofmanfm changed the order of joints in this commit in his fork, but that is most likely not needed -- or it should not be needed.

Indeed, the configuration in that commit did not work correctly. In the meantime, we modified the urdf itself because xacro was producing very weird results. https://github.com/robberthofmanfm/yumi/blob/egm_modifications/yumi_description/urdf/yumi.urdf works for us - at least for representing the current joint states of the robot.

There are mismatch problems in standardized_joints.

what makes you conclude this?
As I mentioned in https://github.com/ros-industrial/abb_robot_driver/issues/15#issuecomment-788079236: on the ROS side we don't care about what the ABB controller internally does. The 7th joint is the joint in the 7th position of the kinematic chain.
For the ABB controller, that would be joint_6. But again, that's not important "outside" the driver.
And I believe the driver does what it's supposed to:
standardized_joints {
  original_name: "rob_R_7"
  standardized_name: "yumi_robr_joint_3"
  [..]
}
[..]
standardized_joints {
  original_name: "rob_L_6"
  standardized_name: "yumi_robl_joint_7"
  rotating_move: true
  lower_joint_bound: -3.9967999
  upper_joint_bound: 3.9967999
}

notice how it's re-named things such that rob_R_7 is now the 3rd joint, while rob_R_6 is now the 7th joint.
As I wrote in https://github.com/ros-industrial/abb_robot_driver/issues/15#issuecomment-788079236: I believe the urdf/xacro you are using has been edited incorrectly by @robberthofmanfm: yumi_robl_joint_7 should link yumi_link_6_r and yumi_link_7_r, but instead yumi_robr_joint_6 does that.

@robberthofmanfm wrote:

we modified the urdf itself because xacro was producing very weird results. https://github.com/robberthofmanfm/yumi/blob/egm_modifications/yumi_description/urdf/yumi.urdf works for us - at least for representing the current joint states of the robot.

as long as you're aware plain URDF cannot be combined with any other URDFs.
It would be better to use xacro.

@yanjunyangmonash: I'm going to close this issue assuming your problem has been solved -- or at least: we've identified the root cause.
It would seem @robberthofmanfm has already fixed his fork, so the incorrect order of joints in his .urdf should no longer be a problem.
As I don't believe abb_robot_driver does anything wrong, there is nothing for us to fix here.
Please feel free to keep commenting on the issue of course.

Hello @gavanderhoorn. I followed your tutorial about the use of the abb_robot_driver library in order to simulate the movement of a 6-joint robot (IRB2400) with Robotstudio. I followed all the installation points as well as applied a previous simulation of the abb_driver library with Robotstudio and moveit, which worked. I installed the ABB Server as found in http://wiki.ros.org/abb_driver/Tutorials/InstallServer in order to control the FlexPendant from RobotStudio.
Now, when I try to run your second example I get this error:
[FATAL] [1622463556.209463331]: Runtime error: 'Failed to call ROS service 'rws/get_robot_controller_description''
The controller IP is set as default and I think that it is not a problem about the connection between my ROS and the RobotStudio.  Do you know where could be the problem?
Thank you very much.

@pferfer: please post new problems in new issues.
This is not a forum, but an issue tracker.

The Joints are reordered here actually, so the old URDF has to be modified accordingly.


Add catalog serialize method

Some Intake drivers provide a Catalog.serialize() method that allows the user to cache their catalog. It would be useful if this was possible with intake-esm to allow users to document exactly which datasets were available at the time of an analysis.
col = intake.open_esm_datastore(...)
col.search(experiment_id=['historical', 'ssp585'], source_id=models, table_id='Ofx', grid_label='gn')
cat_fx.serialize('yaml_or_json_file')

For reference, intake-dcat does this here: https://github.com/CityOfLosAngeles/intake-dcat/blob/master/intake_dcat/catalog.py#L74-L85

Needs to be revisited once https://github.com/NCAR/esm-collection-spec/issues/13 is addressed.

@bonnland implemented this a few months ago: https://github.com/NCAR/intake-esm/pull/195. It was released as part of v2020.03.16.
Thank you @jhamman & @bonnland! Closing...


enh: Turn project into MIRTK Package providing evaluate-slice-dice

I've turned your project into a MIRTK Package which adds your binary as "mirtk evaluate-slice-dice" command. I run into some CMake error (when package has no lib DEPENDS specified in BasisProject.cmake as yours) and a compilation issue with Clang vs GCC on OS X. Will push a fix to MIRTK master soon. This MIRTK SliceDice package should build just fine then.
CC: @ghisvail

PS: I took the liberty and added the Apache 2 license file here. Feel free to replace it with whichever compatible license you prefer (pretty much any other license).

Mentioned fixes of MIRTK master for this package to build merged, see:

https://github.com/BioMedIA/MIRTK/pull/559
https://github.com/BioMedIA/MIRTK/pull/560

@drkarim You're ready to give this one a shot.

BTW If you want to create further MIRTK Packages which also include libraries with dependencies, have a look at these projects as reference regarding the CMake configs:

https://github.com/MIRTK/Deformable
https://github.com/MIRTK/Mapping


Add flag for enclosing edge voxels?

Currently the mesher doesn't generate meshes for the edge voxel. It is an easy change to make the code mesh the outside edges of the voxel chunks? Otherwise I can oversize the voxel data field before meshing (eg extend it to 34x34x34 with a 1 voxel empty border), but that's super inefficient.
See this block which is at z position 31 in a 32x32x32 field.

Hmm, doing that would break the ambient occlusion, I guess this change is a bit harder. Maybe I need to look at making the mesher look at surrounding voxels while calculating?


fix check warn

warning: derive helper attribute is used before it is introduced
  --> src/config.rs:27:3
   |
27 | #[serde(rename_all = "lowercase")]
   |   ^^^^^
28 | #[derive(Copy, Clone, Debug, Serialize, Deserialize, PartialEq, Eq, PartialOrd, Ord)]
   |                              --------- the attribute is introduced here
   |
   = note: `#[warn(legacy_derive_helpers)]` on by default
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #79202 <https://github.com/rust-lang/rust/issues/79202>

Thanks! Wasn't aware of this.


about using gumbel_distribution to transform discrete space

In the code you provided, the DDPG algorithm supports continuous and discrete action spaces by using the Gumbel_distribution. Maddpg is a DDPG-based extension, and whether it is suitable for discrete action spaces by using Gumbel_distribution. when i employ Gumbel in MADDPG, i can not obtain appropriate results. the version of tensorflow i used is 1.14, i don't use the tensorflow_probability module, could you give me some code exmples of Gumbel in TF, or give me some instructions? sorry to bother you.

I'm not sure about whether Gumble is suitable for MADDPG.
Actually, maddpg in my repo does not work well for now, and I'll fix it next.
You can find something related to Gumble distribution at here
I'm not family with how to use Gumble with TF1.x, maybe you could find related answers in others' repo.

thanks for your replying. in the MADDPG code supplied by OpenAI (https://github.com/openai/maddpg/), they use Gumbel sample in distributons.py as follows:
def sample(self):
u = tf.random_uniform(tf.shape(self.logits))
return U.argmax(self.logits - tf.log(-tf.log(u)), axis=1)
may be the MADDPG is able to address the discrete action spaces...

yes, Gumbel softmax is a good trick in solving gradient conduction discrete problem gradients.
Since you have found the solution, this issue will now be closed, feel free to re-open it.

when you employ Gumbel softmax in DDPG solving discrete action spaces problem, did you get the desired outcome?

@tanxiangtj  yes, it works well with gym

您好！您在上海？您这个工作很不错，方便给个微信联系方式吗，向您请教请教

您好！您在上海？您这个工作很不错，方便给个微信联系方式吗，向您请教请教

如果您有什么问题，可以通过email或者在issue中联系我。

好的。谢谢！


Add Seasonality to CLV Models

Section 6 in https://www.brucehardie.com/notes/040/time-varying_covariates_in_BGNBD.pdf describes how BetaGeoModel can be extended to account for seasonality. I'm pretty sure this same methodology can be applied to the ParetoNBDModel and other models. Not gonna lie though - this will be involved and span multiple PRs.
Expanding clv.utils.clv_summary() for seasonality periods (and transactions within those periods) demands considerable pandas knowledge and will be the hardest part of this. Prophet might be a useful codebase for ideas. For the models themselves, hopefully logp can be wrapped in a pytensor.switch() statement to go back & forth between the high/low/etc. seasons.

Nice idea! I have not gone into the details, but we already have a function to generate Fourier modes a la Prophet https://github.com/pymc-labs/pymc-marketing/blob/main/pymc_marketing/mmm/utils.py#L6-#L35 ;)
I plan to incorporate seasonality for the current mmm class.


fix(weaver): #696 detect .mystruct = new MyStruct() changes with syncvars

fixes issue #696
when you initialize a syncvar field with .mystruct = new MyStruct() or .mystruct = default was not calling the property setter.  Because of this,  synvars were not being marked dirty and were not synchronized.
Who knows how many people are affected by this bug and don't know it. This bug goes all the way back to HLAPI
Please squash it,   the first commit fails the test (on purpose)
Closed this by accident before

testing this now

:tada: This PR is included in version 3.4.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


MB2 missing partition table

Hi!
I'm not sure if this is a bug with meta-tegra or something hardware related but you seem quite knowledgeable, so I figured you might have an idea. Or know if it is a bug with meta-tegra.
We have some xavier nx devices running dunfell and meta-tegra @ fd63b94. Some of them, 4 so far, have suddenly stopped booting. As far as we can tell they have been running fine and then suddenly on reboot we get the included error log and they wont start. We tried flashing one of them again and it has been working fine for weeks now, so it does not seem that there is any permanent hardware damage/fault to explain it.
We have now idea what's causing it so it is hard to reproduce, and we are wondering how it can happen at all? It seems this is referring to the QSPI flash but our assumption was that it would be mostly read-only? Since it is four devices (out of 50) it does not seem to be a one off fluke.
[0000.438] I> Welcome to MB2(TBoot-BPMP) (version: 00.00.2018.32-mobile-6fc80c72)

[...]

[0000.473] I> Boot-device: QSPI

[0000.476] I> Boot_device: QSPI_FLASH instance: 0

[0000.481] I> QSPI Flash Size = 32 MB

[0000.486] I> Qspi initialized successfully

[0000.487] I> qspi flash-0 params source = boot args

[0000.493] W> Cannot find any partition table for 00030000

[0000.498] I> Active Boot chain : 0

[0000.501] E> Cannot find partition bpmp-fw

[0000.505] E> Partition bpmp-fw not found

[0000.508] I> load/auth: execution failed

[0000.512] E> Top caller module: LOADER, error module: PARTITION_MANAGER, reason: 0x0d, aux_info: 0x00

[0000.521] I> AB warm reset

Hey @oscarthorn
Are you sure the flashing process went well ? Please share the host and target (serial uarl) logs.
I'm seeing the following logs:
[0000.501] E> Cannot find partition bpmp-fw
[0000.505] E> Partition bpmp-fw not found
[0000.508] I> load/auth: execution failed

BPMP  is key component.
Also, Is secure boot enabled with your device ?

Please make sure that you are using the right keys SBK and PKC

@oscarthorn Is this a new hardware ? if so, please check the FAB and BoardSKU

Would the keys being wrong not manifest immediately on first boot? How would I verify the keys on a system like this that does not boot? I think the keys are correct, according to our logs it was flashed with the correct keys (and flashing it again is fine).
Thanks, though I'm not sure you will get any error, we have several dozen more units that all work fine and even the faulty units have worked fine after flashing and only latter ended up in this state, after 1-8 weeks of use roughly.
I don't think so, I would have to check which one it is exactly but it would be one of these. The board is another developer right now so I'll ask him to check.
TEGRA_BUPGEN_SPECS ?= " \
                fab=100;boardsku=0000;boardrev= \
                fab=200;boardsku=0000;boardrev= \
                fab=300;boardsku=0000;boardrev= \
                fab=301;boardsku=0000;boardrev= \
                fab=100;boardsku=0001;boardrev= \
                fab=200;boardsku=0001;boardrev= \
                fab=300;boardsku=0001;boardrev= \
                fab=301;boardsku=0001;boardrev= \
                fab=200;boardsku=0003;boardrev= \
                fab=300;boardsku=0003;boardrev= \
                fab=301;boardsku=0003;boardrev= \
"

I don't think so, I would have to check which one it is exactly but it would be one of these. The board is another developer right now so I'll ask him to check.
TEGRA_BUPGEN_SPECS ?= " \
                fab=100;boardsku=0000;boardrev= \
                fab=200;boardsku=0000;boardrev= \
                fab=300;boardsku=0000;boardrev= \
                fab=301;boardsku=0000;boardrev= \
                fab=100;boardsku=0001;boardrev= \
                fab=200;boardsku=0001;boardrev= \
                fab=300;boardsku=0001;boardrev= \
                fab=301;boardsku=0001;boardrev= \
                fab=200;boardsku=0003;boardrev= \
                fab=300;boardsku=0003;boardrev= \
                fab=301;boardsku=0003;boardrev= \
"

Yes, please do and let me know

Thanks, will do! I'll get back in a couple of days, he was not at home (we have a long weekend in sweden)

@ichergui This is the boardspec for one of the faulty modules: 3668-301-0003-B.0-1-2

@oscarthorn Did you figure this out?


harfbuzz: 7.0.0 -> 7.0.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/harfbuzz/harfbuzz/releases.
meta.description for harfbuzz is: An OpenType text shaping engine
meta.homepage for harfbuzz is: https://harfbuzz.github.io/
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
Warning: a test defined in passthru.tests did not pass
found 7.0.1 with grep in /nix/store/lbj5yfzsm7lsfyw8kfvvzkjcwi2qg70d-harfbuzz-7.0.1
found 7.0.1 in filename of file in /nix/store/lbj5yfzsm7lsfyw8kfvvzkjcwi2qg70d-harfbuzz-7.0.1

Rebuild report (if merged into master) (click to expand)

15493 total rebuild path(s)

15493 package rebuild(s)

First fifty rebuilds by attrpath

AusweisApp2
CHOWTapeModel
ChowCentaur
ChowKick
ChowPhaser
CuboCore.coreaction
CuboCore.corearchiver
CuboCore.corefm
CuboCore.coregarage
CuboCore.corehunt
CuboCore.coreimage
CuboCore.coreinfo
CuboCore.corekeyboard
CuboCore.corepad
CuboCore.corepaint
CuboCore.corepdf
CuboCore.corepins
CuboCore.corerenamer
CuboCore.coreshot
CuboCore.corestats
CuboCore.corestuff
CuboCore.coreterminal
CuboCore.coretime
CuboCore.coretoppings
CuboCore.coreuniverse
CuboCore.libcprime
CuboCore.libcsys
DisnixWebService
EmptyEpsilon
HentaiAtHome
LibreArp
LibreArp-lv2
MIDIVisualizer
MMA
OSCAR
OVMF
OVMFFull
PageEdit
R
SDL
SDL2
SDL2_gfx
SDL2_image
SDL2_image_2_0_5
SDL2_mixer
SDL2_mixer_2_0
SDL2_net
SDL2_sound
SDL2_ttf

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/lbj5yfzsm7lsfyw8kfvvzkjcwi2qg70d-harfbuzz-7.0.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A harfbuzz https://github.com/r-ryantm/nixpkgs/archive/be702986e11e1c1d99099e7bd0af988248170995.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/lbj5yfzsm7lsfyw8kfvvzkjcwi2qg70d-harfbuzz-7.0.1
ls -la /nix/store/lbj5yfzsm7lsfyw8kfvvzkjcwi2qg70d-harfbuzz-7.0.1/bin

Pre-merge build results
NixPkgs review skipped

Maintainer pings
cc @edolstra for testing.

Builds on aarch64 (darwin & linux)l as well as x86_64-linux.


Dependency on "window" breaks server-side rendered applications

One could make the argument that history.js ought not to be bundled in the server-rendered js (as it will not work); but I think there is value to keeping things simple and having identical js on the server side and client side.

Also document


ZAP Bitcoin wallet ERROR - Lnd has unexpectedly quit! Error code: 1 Error signal: Unknown Error message: Shutting down because error in main method: error creating wallet config: unable to initialize neutrino backend: unable to create neutrino light client: unable to read header: EOF  Ok

Hi, I have a ZAP Bitcoin Wallet that I run on Mainet Network.  I am using v7.2 and I cannot open my wallet as I keep getting the following error:
Lnd has unexpectedly quit!
Error code:
1
Error signal:
Unknown
Error message:
Shutting down because error in main method: error creating wallet config: unable to initialize neutrino backend: unable to create neutrino light client: unable to read header: EOF
I tried to download ZAP v7.7 but it does not do anything...can you please help me open my wallet??

Can someone help me with this issue please!?!?!


Zhaoyu/disable cleaner

disable cleaner on build deploy

Coverage increased (+0.01%) to 51.627% when pulling 2fea03af478e73a4784844ce29ead89847331ac0 on zhaoyu/disable_cleaner into 67b6b549bda9fb78c8cd8b22bce2cf953351e10c on pai-0.8.y.

Coverage increased (+0.01%) to 51.627% when pulling 2fea03af478e73a4784844ce29ead89847331ac0 on zhaoyu/disable_cleaner into 67b6b549bda9fb78c8cd8b22bce2cf953351e10c on pai-0.8.y.


Use the full request url in case it includes url variables.

Test case: https://gist.github.com/bmfs/ba27868115055c3c093e
In Flash it works properly
In HTML5, the Loader class strips the request url from any URL variables.
(In the native target, the test case won't work. However that is due to the curl request no having the followlocation flag set to true)

Thanks! I've fixed this for the HTML5 case (native needs this to not fail in loading local files) though I found an issue that's Neko-specific (Loader regression) that I'm looking into, using your test. Hope to have that ready soon :smile:

I realized that my problem was I needed a clean build on this machine, Neko is running great, though the second image doesn't appear. If you don't mind checking it out, it seems it receives output like:
Found.
Rather than the image. Is this to do with the user agent of desktop versus HTML5, or is there some other issue? Thanks!

The second image doesn't work in native or neko for another reason. This result of the url is a 302 HTTP Code meaning the resource. For the second image to work in native at least we need to add a allowlocation flag to curl options.
curl -i "http://avatars.miniclip.com/players/en/resize.php?uid=1&w=200&h=200"
HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Date: Mon, 12 Oct 2015 19:11:56 GMT
Location: https://mc-avatars.miniclipcdn.com/1-200.png?v=04cdc35d0f02c763729905a115840d81
Server: nginx/1.6.2
Content-Length: 102
Connection: keep-alive

Found.

I just added FOLLOWLOCATION to our cURL code in OpenFL. Now it properly redirects, but I get an SSL error when it tries to load the image. When I try to manually load the image using the given URL, I get the same result, unless I do so an HTTP address, then it works.
Perhaps the server does not allow a connection unless we include SSL certificates?


Add support for QR code sharing

Adds a simple QR code option to allow sharing via QR code, see screenshot (this is displayed in a modal). I used https://github.com/nimiq/qr-creator. However, this is the first time I'm contributing to your amazing project, and I'm not really familiar with the two-repo-approach.
Closes https://github.com/LycheeOrg/Lychee/issues/35

I have a question about the sample QR code? Why do the the corners and edges of the QR code look so smooth and chamfered? According the QR specs the QR code should use square black/white pixels. Is this a limitation of the used library? I fear that some receivers with bad error correction might get confused.

This is something the used library does, it can be disabled. Should I disable it?

That's how it looks now.

@qwerty287 You need to run ./npm run format and commit again. Otherwise the checks above will fail.

Ready for merge IMHO.

Sorry for a late feedback; I haven't actually tried this branch until now. Two comments/questions; both relatively minor, but still...

Wouldn't it make more sense for this feature to be placed in the "Share" context menu rather than under "..."?
Shouldn't it be available for albums as well?

While I'm at it, isn't it remarkable that the first PR from user @qwerty287 has number 287?! :wink:

I have merged consistent_json_api into master and rebased your branch querty287/qrcode-35 as qrcode-35_rebased onto the new master. To update your PR, I believe the following commands should be the the right ones.
Attention:

I haven't tested them.
I assume that the default remote origin points to your own repository git@github.com:qwerty287/Lychee-front.git.

Commands:
git checkout master                                                  # Checkout the current master of Lychee-front, the only important thing is that your are not on the branch `qrcode-35`
git remote add lychee-org git@github.com:LycheeOrg/Lychee-front.git  # Add the LycheeOrg-Repo as a remote unless you haven't yet
git branch -D qrcode-35                                              # Delete your local branch `sass`
git checkout -b qrcode-35 --track lychee-org/qrcode-35_rebased       # Checkout a new local branch `sass` from `sass_rebased`
git pull                                                             # Pull it
git branch -u origin/qrcode-35                                       # Change to upstream to your repository, this assumes `origin` points to `qwerty287`
git push                                                             # Try to push it, this is expected to fail, but make sure that GIT tries to push to the correct remote
git push --force                                                     # Now push forcefully

sorry guys to jump in but I cannot understand how to use QR code sharing, can you please explain?

Enable share button visible on the said album
Refresh (to make the button appear in the header)
Open the share button menu and click on the QR code.


Generate and build the workflow stubs

The current .NET client implementation dynamically generates and compiles the workflow stubs on demand, when stubs are created.  The problem is that the C# compiler libraries take about 1.8 seconds to initialize and then compile source code for the first time.  Subsequent compiles are much faster, taking about 200ms.
The concern here is that 1.8 seconds is nearly 1/5th of the default decision task timeout of 10 seconds which means there's a substantial chance that this time plus whatever else a workflow is doing, may exceed this timeout.
The current code mitigates this by performing a dummy compile when the first Cadence connection is established.  This means that it'll take only about 200ms to generate subsequent stubs.  This isn't too bad and should work most of the time.
The problem is that even these 200ms compilation delays might add up.  A workflow that creates about 50 stubs in a workflow decision task would be right at the decision task timeout.  I suspect that most users won't expect stub creation to take significant time so this could cause unexpected problems for complex workflows.
Here are some potential solutions:

Pre-generate and cache workflow stubs as we're registering workflows and activities from assemblies.

Add client methods that a specified assembly and automatically generate stubs for all interfaces that implement IActivity and IWorkflow.

I think I like option 2 better because it's cleaner but this will mean that we'll need to educate developers to add these calls.  This is a bit of a downside, but considering that the 200ms delay probably won't impact most users, this isn't that big of a deal; we'd only need to educate the advanced users.
I'm putting this on the backlog for now since we can ship without it.

Here's the list of stubs we need to generate:
Workflow:

[ ] IWorkflowStub CadenceClient.NewUntypedWorkflowStub(string workflowId, string runId = null, string workflowTypeName = null, string domain = null)
[ ] WorkflowStub CadenceClient.NewUntypedWorkflowStub(string workflowTypeName, WorkflowOptions options = null)
[ ] TWorkflowInterface CadenceClient.NewWorkflowStub<TWorkflowInterface>(string workflowId, string runId = null, string workflowTypeName = null, string domain = null)
[ ] TWorkflowInterface CadenceClient.NewWorkflowStub<TWorkflowInterface>(string workflowId, string runId = null, string workflowTypeName = null, string domain = null)
[x] TWorkflowInterface CadenceClient.NewWorkflowStub<TWorkflowInterface>(WorkflowOptions options = null, string workflowTypeName = null)
[ ] ExternalWorkflowStub
[ ] Task<WorkflowExecution> Workflow.GetWorkflowExecutionAsync(object stub)
[ ] Task<TWorkflowInterface> Workflow.NewContinueAsNewStub<TWorkflowInterface>(ContinueAsNewOptions options = null)
[ ] TWorkflowInterface Workflow.NewExternalWorkflowStub<TWorkflowInterface>(WorkflowExecution execution, string domain = null)
[ ] TWorkflowInterface Workflow.NewExternalWorkflowStub<TWorkflowInterface>(WorkflowExecution execution, string domain = null)
[ ] TWorkflowInterface Workflow.NewExternalWorkflowStub<TWorkflowInterface>(string workflowId, string domain = null)
[ ] ``

Activity:

[ ] Task ActivityStub.ExecuteAsync(string activityTypeName, params object[] args)
[ ] Task<TResult> ActivityStub.ExecuteAsync<TResult>(string activityTypeName, params object[] args)
[ ] Task<object> ActivityStub.ExecuteAsync(Type activityType, string activityTypeName, params object[] args)
[x] TActivityInterface Workflow.NewLocalActivityStub<TActivityInterface, TActivityImplementation>(LocalActivityOptions options = null)
[ ] IActivityStub Workflow.NewUntypedActivityStub(ActivityOptions options = null)
[ ] IChildWorkflowStub Workflow.NewUntypedChildWorkflowStub(string workflowTypeName, ChildWorkflowOptions options = null)
[ ] IExternalWorkflowStub Workflow.NewUntypedExternalWorkflowStub(WorkflowExecution execution, string domain = null)
[ ] IExternalWorkflowStub Workflow.NewUntypedExternalWorkflowStub(string workflowId, string domain = null)
[ ] ``

NOTE: I'm not sure about the use case for the two NewExternalWorkflowStub() methods and there are some implementation complexities, so I'm going to leave these partially implemented and commented out for now.


Basic Authentication not working

Hello everybody, I'm trying to implement a connection to Elastic (7) on AWS but I don't understand how to do it using basic authentication credential instead of IAM.
This is my code, but when I try to do a search I have got the error "Elasticsearch.Net.UnexpectedElasticsearchClientException: Unable to retrieve credentials required to sign the request. ---> System.Exception: Unable to retrieve credentials required to sign the request. ---> Amazon.Runtime.AmazonServiceException: Unable to get IAM security credentials from EC2 Instance Metadata Service."
var httpConnection = new AwsHttpConnection(Amazon.RegionEndpoint.EUWest3.ToString()); var pool = new SingleNodeConnectionPool(host); settings = new ConnectionSettings(pool, httpConnection).BasicAuthentication(_user, _password).ServerCertificateValidationCallback( 							delegate ( 								object sender, 								System.Security.Cryptography.X509Certificates.X509Certificate certificate, 								System.Security.Cryptography.X509Certificates.X509Chain chain, 								System.Net.Security.SslPolicyErrors sslPolicyErrors 							) 							{ 								return true; // Always accept 							});
NEST v. 7.12.1
Elasticsearch.Net.Aws 7.1.0
ElasticSearch v. 7
Can anyone help me?

Hi @denisecastagna. I'm going to close this as it doesn't look like it relates to a supported feature of this library. Please let me know if you have further information and we can review re-opening.


Implement 'Edit CRDT Map' object view

If an object is in a Map data type bucket, allow users to edit the individual fields

Flags as radio buttons
Registers as text boxes
Sets using the Edit Set component (#46)
Counters using the Edit Counter component (#45)

Moving to the gui repo: https://github.com/basho-labs/riak-explorer-gui/issues/64


Allow splits to be resized

Horizontal splits should have resizable widths, and vertical splits resizable heights.
This will be really useful with terminal support coming soon (I'll likely always have splits open going forward once this is supported.)

I mentioned this in the other issue in the private repo, but being able to snap splits back to being evenly divided, with a double click, is a nice feature to have, once resizing is available.

Now that the terminal is out, this would be great. I created a new modal tab, splitted down, and closed the first one. But dedicating 50% of screen real estate for the terminal is a bit too much.

Yes hopefully resizing tabs is on the roadmap.  As far as the terminal, while resizing would help and is the reason I was looking to create an enhancement about pane resizing, I feel like a dedicated bottom view would be a better place for the terminal and possibly other future view tools, e.g. git log, db, debug, etc.

This is the main issue, that keeps me from using Zed more often. Not being able to resize panes is just hurts.

I can't wait until this is added. I'm with you, @AlexW00 - I would make Zed my go-to editor even in its early stages right now if it weren't for this missing feature.

I just got into the private alpha for Zed and this is also a deal breaker for me to continue using it seriously

If it's mostly for the terminal, perhaps using the dock could help a little bit?

This is open for half a year now, and I suppose no work is being done, because for me, it looks like it should be easy to make, especially having implemented Dock already. That being said, why is it still open?

It isn't as easy as you'd expect. We use a tree of flex rows and columns to lay out panes today. It's not obvious how that should interact with resizable panes in a way that preserves the benefits you get from automatic layout of tabs.
This is still a high priority for me personally and is something we have discussed off and on over the last 6 months and even before this issue was created.
To put my mod hat on, this issue will get prioritized but saying it should be closed because clearly nothing is happening is not acceptable under the code of conduct. We would have closed it if we decided we weren't going to address it.

This is open for half a year now, and I suppose no work is being done, because for me, it looks like it should be easy to make, especially having implemented Dock already. That being said, why is it still open?

There and hundreds of features everyone wants, each having users expressing how much they want it as badly as you do.  We're a small team and this product is still in private alpha, we'll
Just a reminder - we are a small team (< 10) and this product is still in private alpha.  We recognize that this is a popular issue, but the implication behind signing up for a product in private alpha is that the product may not be developed enough to perfectly pleases everyone - quite the opposite, there is almost a guarantee that it will be missing things.
We have hundreds of feature requests, each one having passionate users expressing how badly they want it.  As Kay said, we're not closing it because it's a feature we intend to add, but it will happen when we can find time to slide it in.  It's simply not done because there are technical challenges associated with it.

If you open source, the community can help you add it.
Just a note to the employees.

This should be released by v0.97 :)


implement varx by Lucas Parra

I just stumbled over this awesome paper:
https://arxiv.org/pdf/2404.10834
with code here: https://github.com/lcparra/varx (check license)
I think we should explore this method - it looks really cool :)

if I understood correctly - this should be straight forward:
simply add a 1-lagged continuous TRF predictor to the model.
This will be much more interesting, once we got group-lasso integrated somehow... :S


Possibility to add Create action Button for any entity  and fixes Bug

This adds the option, to add a button which allows to specify the entity for which the create view should be done.
If this functionality isnt useful for a broader audience this still fixes a bug where attrs.entityName is called when it should be attrs.entity.

I don't understand. This directive already allows you to set the target entity either using an Entity object (entity="entity"), or using an entity name (entityName="myEntity"). So you can already do what you ask.
Also, about your bug, when does it occur?

I added this button to the listView listactions
'<ma-create-button "entity="price" default-values="{}" size="xs">'
same with
''
When clicking on it I am just getting a 404 not found page.
I guess this is because the entity is already in the scope and therefore the custom one is not used.
Regarding the bug, that was just a misunderstanding on my side.

No, <ma-create-button> has isolated scope. What if you try:
<ma-create-button entity="entity" default-values="{}" size="xs"></ma-create-button>
or
<ma-create-button entity-name="price" default-values="{}" size="xs"></ma-create-button>

The latter one works.
On a side note:
Is there a possibility to access the entry in the defaultvalues to pass its identifierValue?
like
default-values="{'item' : entry().identifierValue }"


Aca-py not recording revoked status correctly

Aca-py no longer records the internal credential "revoked" state correctly.
Steps to reproduce:

run local von-network and tails server
start faber ./run_demo faber --revocation
start alice ./run_demo alice
accept invitation in alice agent
issue credential(s) from faber to alice
revoke a credential
check credential status using GET http://localhost:8021/api/doc#/revocation/<rev_reg_id>/issued/details

Expected - revoked credential will have revoked state
Actual - still in issued state
This breaks the new "revocation fix" endpoints
Also see integration tests @T002-TAA and @T003-TAA which fail against the latest release
e.g. run von-network as ./manage start --taa-sample --logs and then ./run_bdd -t @T002-TAA

@ianco , some questions.
First, can you tell when this change was made? Was it part of 0.7.4?
Second, it should (at least in some/most cases) be the controller that tracks the revocations. I assume we’ll need too provide a way to support a fix for that model, right? Where we have to rationalize the controller set of revocations with the ledger set?
@andrewwhitehead - can you please look at this as a top priority?

First, can you tell when this change was made? Was it part of 0.7.4?

This changed in this PR:  https://github.com/hyperledger/aries-cloudagent-python/pull/1804  (I tested an early version of the PR and it worked ok so these was a change later on that broke this feature)

Second, it should (at least in some/most cases) be the controller that tracks the revocations. I assume we’ll need too provide a way to support a fix for that model, right? Where we have to rationalize the controller set of revocations with the ledger set?

Yes we should rationalize these calls.  Right now the revocation status is tracked in both the indy-sdk wallet records as well as aca-py (as well the controller needs to track issue and revocation status vs its own "business" database).  aca-py needs enough information to be able to verify the wallet/ledger consistency (unless we want to push this down to the controller as well).

I'm wondering if we should be tracking revocation status in the RevReg object in ACA-Py. If the credential object has been removed, we still need a way to batch update the RevReg, so I think this might be necessary.  For example, could we have arrays pending_activation and pending_revocation that get added to when a credential is activated/revoked, and on successful publication, we move those to IDs to activated and revoked arrays, respectively.

@andrewwhitehead -- can you please take a look at #1804 again to see how it impacted this?  Good to get RC4 or the final 0.7.4 out sooner than later.


[Snyk] Upgrade @graphprotocol/graph-cli from 0.64.0 to 0.64.1

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade @graphprotocol/graph-cli from 0.64.0 to 0.64.1.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 17 versions ahead of your current version.
The recommended version was released 23 days ago, on 2023-12-21.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (8ec6a6a) 77.83% compared to head (bf06bb1) 77.83%.

:exclamation: Current head bf06bb1 differs from pull request most recent head 404f07e. Consider uploading reports for the commit 404f07e to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2035   +/-   ##
=======================================
  Coverage   77.83%   77.83%
=======================================
  Files          40       40
  Lines        3086     3086
  Branches      625      625
=======================================
  Hits         2402     2402
  Misses        479      479
  Partials      205      205

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


Negative temperature calculation error

Node translate negative temperature incorrectly.
800a calculates to 3277.8 degree, should be -1
from Rflink protocol http://www.rflink.nl/blog2/protref

TEMP=9999 => Temperature celcius (hexadecimal), high bit contains negative sign, needs division by 10 (0xC0 = 192 decimal = 19.2 degrees)
=> (example negative temperature value: 0x80DC, high bit indicates negative temperature 0xDC=220 decimal the client side needs to divide by 10 to get -22.0 degrees

Exampel
RFlink message:

20;ED;DKW2012;ID=002c;TEMP=800a;HUM=99;WINSP=0000;WINGS=0018;RAIN=007b;WINDIR=0008;BAT=OK;

After rflink node

msg.payload : Object
object
name: "DKW2012"
id: "002c"
temp: 3277.8
hum: 99
winsp: 0
wings: 24
rain: 12.3
windir: 8
bat: "OK"

Hi, I believe the recent change done by fab33 has fixed this issue.

Hello @pointbre , That recent change was not committed or at least has not made it's way to npm.
When loading the node through node-red, the negative temps are returned as '0'
The current npm code doesn't have the changes done by @fab33


Allow for rudimentary handling of non-text html parts.

Caeml currently assumes that seeing the text/plain part is what you want. It does not provide any information about the existence of other message parts, nor is it obvious from the output whether the message is empty or whether it did not contain a text/plain part (some people might only send text/html).
Some thoughts about improvement:

[ ] print a warning, if there's no text/plain part found
[ ] allow a commandline override to output a different part other than text/plain
[ ] somehow print an enumeration of all the message parts (maybe as a special "header"?)

You could DIY a simple HTML parser which basically turns <b>, <i>, <em>, <a> and so on into ANSI escape codes and strips anything else. Plus maybe a wrapper.  I wouldn't personally bother with CSS parsing and the likes.
Would at least make the HTML experience more bearable :D

I think printing the structure and allowing for dumping different parts could be a good solution.
Thanks for the work!

Hmm, I don't think I want to get into html parsing. On the other hand we could make a filter interface, similar to aerc. In that case it would make sense to fall back to first text/markdown and if that doesn't exist to text/html and if even that doesn't exist to any text/*. Or something like this. Shouldn't be very complicated.

https://todo.sr.ht/~rjarry/aerc/224 Actually, what I proposed here might make caeml largely obsolete.


change influxql DataType from string to int

Besides the iota, lgtm.

Makes sense to me. The warning from @benbjohnson is so serious perhaps it warrants a comment. If we someone assigned different values (for aesthetic ordering) reasons, and the release got out, it would be bad.

+1


{databricks} HTML tags are rendering as empty parameter values in reference

Describe the bug
Problem to solve:
HTML tags in source code are causing build warnings in MicrosoftDocs/azure-docs-cli. More importantly, customer-facing reference docs are not instantiating properly -- parameter values formatted with `<>` are missing. Here's an example:

Requested solution:
These values should be escaped with a backtick. Here's an example from az webpubsub.

Published reference guidelines
Guidelines for Parameters used in examples
Related GitHub issues:
This is the same issue as these GitHub issues.
List of HTML tag instances that need update:

File name
Build error

latest/docs-ref-autogen/databricks/access-connector.yml
HTML tag 'indexToRemove' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/databricks/access-connector.yml
HTML tag 'value' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/databricks/workspace.yml
HTML tag 'indexToRemove' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/databricks/workspace.yml
HTML tag 'value' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/databricks/workspace/private-endpoint-connection.yml
HTML tag 'indexToRemove' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/databricks/workspace/private-endpoint-connection.yml
HTML tag 'value' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/databricks/workspace/vnet-peering.yml
HTML tag 'indexToRemove' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

latest/docs-ref-autogen/databricks/workspace/vnet-peering.yml
HTML tag 'value' isn't allowed.  Replace it with approved Markdown or escape the brackets if the content is a placeholder.

Related command
az databricks
Errors
n/a
Issue script & Debug output
n/a
Expected behavior
n/a
Environment Summary
Azure CLI 2.62.0
Additional context
No response

Thank you for opening this issue, we will look into it.


WIP master <- develop

Merge the develop branch into the master branch and deploy

Build log
Preview build with this PR (commit): https://204-280922552-gh.circle-artifacts.com/0/index.html


404 page not found using router

I'm trying to build a very small example application to learn the framework. I'm thinking the below code (taken from router_test.go) is registering one handler. When it try the following url I get 404 errors. I'm running gophers serve in the directory
http://localhost:8080/com.home/testgopherjs/ - I don't get a 404 error here but I get the following in the console
2016/12/21 21:25:54 Could not find route to match: /com.home/testgopherjs/     printToConsole — syscall.go:43
http://localhost:8080/com.home/testgopherjs/greet/alex - returns 404
http://localhost:8080/com.home/testgopherjs/#/greet/alex - returns all coroutines are asleep

How do I access the handler appropriately here?
package main

import (
	"fmt"
	"github.com/go-humble/router"
)

func main() {
	// Create a new Router object
	r := router.New()
	// Use HandleFunc to add routes.
	r.HandleFunc("/greet/{name}", func(context *router.Context) {
		// The handler for this route simply grabs the name parameter
		// from the map of params and says hello.
		fmt.Printf("Hello, %s\n", context.Params["name"])
	})
	// You must call Start in order to start listening for changes
	// in the url and trigger the appropriate handler function.
	r.Start()
}

Firstly, I'm sorry for this poor example. The example code does work, but not without some additional code. I don't feel that the example code does a good job of explaining the context and would like to improve it.

http://localhost:8080/com.home/testgopherjs/greet/alex - returns 404

This is because of the way HTTP works. When you type in that URL, your browser asks your server for the page at http://localhost:8080/com.home/testgopherjs/greet/alex and the server returns a 404 because it does not exist.
While History.pushState enables you to avoid using the # for routes in single page applications, you still have to start by visiting a URL that actually has the content you need. If you want URLs like this to work you will need to modify your server and either use server-side rendering (where the server renders the page on every first page load and then the client takes over after that) or a wild card route (where the server always returns the same content regardless of the URL and the client handles all routing and rendering). Again, this has nothing to do with GopherJS or go-humble/router and is just how browsers and web servers work.

http://localhost:8080/com.home/testgopherjs/#/greet/alex - returns all coroutines are asleep

I'm not exactly sure why the all goroutines asleep error is coming up, but the reason this route does not work is that by default, go-humble/router will detect whether the History API is supported and use it instead of anchor URLS (i.e. "the hash trick") if it is. If you are using a browser which supports the History API, routes like this will not work by default.
You can either change your server so that regular URLs are supported (either with server-side rendering or wild-card routing) or simply force the router to use the hash trick. Here is what the latter would look like:
package main

import (
	"fmt"

	"github.com/go-humble/router"
)

func main() {
	// Create a new Router object
	r := router.New()
  // Force the router to use hash-based URLs for the purposes of
  // this example. Usually you want the default behavior of using
  // the History API if available.
	r.ForceHashURL = true
	// Use HandleFunc to add routes.
	r.HandleFunc("/greet/{name}", func(context *router.Context) {
		// The handler for this route simply grabs the name parameter
		// from the map of params and says hello.
		fmt.Printf("Hello, %s\n", context.Params["name"])
	})
	// You must call Start in order to start listening for changes
	// in the url and trigger the appropriate handler function.
	r.Start()
}

I have just tested this example locally and it works for me.

@beatscode hopefully this helped you resolve your issue. I'm going to close this since it's been a while.


Replace player.js with custom-build version, and move script tag to last

Link to related issue (if applicable)
https://github.com/Selz/plyr/issues/420
Sumary of proposed changes

Add a custom-built version of Vimeo's player.js. The only change is to change the rollup config's format to umd from iife

Insert the <script> tag as the last <script>, rather than the first. I did this as part of my bugfixing, but it seemed like a good option anyway.

Task list

[ ] Tested on supported browsers
[ ] Gulp build completed

Can this not be fixed in the Vimeo lib itself? I'd rather not modify their code and then host that modified file in your repo.

I'm not sure how this can be fixed in Vimeo's lib. My suggestion would be to take the rebuilt player.js and host it via the CND that you used to use for Froogaloop.
You can build your own version from https://github.com/vimeo/player.js/

When you say CND do you mean CDN?
OK maybe we can build it into the gulp build somehow. I'll take a look.

Had a look at this yet? It's needed to have vimeo playback work when loading plyr with requirejs, as described in this GitHub issue from vimeos player.js: https://github.com/vimeo/player.js/issues/79

I'm going to close this since it's very outdated and can't be merged, wasn't a sustainable solution to begin with. The link was to a private repo which didn't update and which we didn't have control over. Also: vimeo now supports amd (in case they didn't before).
Example of how to import vimeo in require.js:
http://jsbin.com/filogakaqu/edit?js,console
If someone needs to make alterations to the code to support this use case (I think it is still the case, but I don't use require.js, so I wouldn't know), please create a new pull request to the develop branch. 👍
And thanks for the effort!


Please allow unused variables / parameters starting with an '_'

Old eslint allowed to mark parameters and exception paramaters to be named _xxx to avoid unused paramaters error.
Please reenable this featiure as otherwise either many repos must use modified local rules or code changes will be required.
Feature should be able with the following modification:
    {
        rules: {
            "@typescript-eslint/no-unused-vars": [
            "error", {
                "argsIgnorePattern": "^_",
                "varsIgnorePattern": "^_",
                "caughtErrorsIgnorePattern": "^_"
                }
            ]
        },
    },

Please check and add to standard rules.
NOTE: eventually unused variables starting with an underscore are not really needed, but at least unused paramaters are often present to show the complete set of parameters passed to the routine.

Hmm - das diable steht in den ts rules schon drinnen:
https://github.com/ioBroker/ioBroker.eslint-config/blob/9bdcbd31d044a7cd55dae5223bca09ea63f64d76/eslint.config.mjs#L64
Das scheint nur für *.js fiels nicht zu ziehen.
Ev. ziehen da auch andere Dinge nicht für js ?

fixed with v1.0.0

Its working as expected - conformed at nsclient adapter.


[FEATURE]: Support for Selecting Users from Multiple IDs

Describe what you want
Hello,
I want to select a user from multiple IDs, but I can't find the select option for multiple IDs in the Drizzle documentation (https://orm.drizzle.team/docs/select). So, for example, if I want to request user data from IDs 10, 15, and 20, the return is going to be an array of 3 user data with IDs 10, 15, and 20. Is it possible to implement this feature, or am I missing something?
Thank you Drizzle Team

db.select().from(table).where(inArray(table.column, [1, 2, 3, 4]));

db.select().from(table).where(inArray(table.column, [1, 2, 3, 4]));

Dude, thank you so much! I've been struggling for like 3 days trying to solve this lol

db.select().from(table).where(inArray(table.column, [1, 2, 3, 4]));

For everyone wondering where "inArray" is coming from, it's from Drizzle.
You can import it like this: import { inArray } from 'drizzle-orm';


Please update package.json to latest

JavaScript-obfuscator is now on 0.17.x , while your package.JSON is at ^0.10.0.
Please update it to "latest" so it remains up-to-date.

I don't think that using "latest" is the best option, as each future install of this plugin will possibility install different versions of javascript-obfuscator, and those might have a different API and break this plugin.
Ideally the user installing grunt-contrib-obfuscator might add a different version of javascript-obfuscatorto their package.json and this plugin would use that version. I'm not sure if that's possible or not.

Done.


Test issue for notification

Creating a test issue to verify email notification.

Getting it now. But need to check and see how I can reduce the traffic from other sites I follow :-)


UART2 Address

Hey there! First of all, thanks for this port, this is enabling some real learning processes here :)
Secondly, this is not an issue perse.
But, because it didn't work out of the box for me, I started code browsing to understand what is going on.
And I found that here you define the base address of the UART2.
However, checking the RPi4's Periherals Document, p147, I noticed that the UART2 address is offset by 0x80000000 on the code.
So, what would be the rationale here? Is it supposed to be 0xFE201400 or 0x7E201400? I know that somehow this is correct, otherwise, people would complain that it is not working =)
Again, thank you so very much for the port.
Kind regards, Paulo.

Hi Paulo,
The UART2 address (0x7e201400) on P.147 is a memory address for Legacy Master view. Check the section 1.2.4. "Legacy master addresses" on P.6. You can find a sentence describing "The peripheral addresses specified in this document are legacy master addresses".
On the other hand, Ubuntu Linux utilizes ARM view with Low Peripheral mode by default rather than Legacy Master view. In that case, the UART2 address starts at 0xfe201400.
You can find memory mapping between Legacy Master view and ARM view with Low Peripheral mode in Figure 1 on P.5.

Hello Takayuki,
Thanks for the prompt answer! That completely makes sense.
After adding arm_64bit=1 to the config.txt file, it worked! Thanks a lot, for sharing here and for the support =D


Clarify the license for the project

I want to use your source code on a commercial project, but I found that the project does not have a clear source license. Please clarify the source license.

My intention was to write the code as learning experience for web3, react, node, etc. As such my intention was to put the code under ISC license https://opensource.org/licenses/ISC. Shortly I'll push a commit to clearly state the license.