Could not retrieve requested transform from buffer. Pointcloud dropped

Hi,
I am trying to start  local_planner_aero  on Jetson Nano with :

Intel Realsense d435 camera
Pixhawk FMUv2  with firmware 1.9.0 or 1.9.2  ( I tried the built one from source or from QGC)
ROS Melodic
Mavros master -> 0.33.0
Mavlink  2019.10.10

roslaunch local_planner local_planner_aero.launch
SUMMARY
PARAMETERS

/local_planner_node/goal_x_param: 0
/local_planner_node/goal_y_param: 0
/local_planner_node/goal_z_param: 4
/local_planner_node/pointcloud_topics: ['/camera/depth/c...
/rosdistro: melodic
/rosversion: 1.14.3

NODES
/
local_planner_node (local_planner/local_planner_node)
tf_depth_camera (tf/static_transform_publisher)
ROS_MASTER_URI=localhost:11311
process[tf_depth_camera-1]: started with pid [14696]
process[local_planner_node-2]: started with pid [14697]
[ INFO] [1572023459.510298587]: Initializing nodelet with 4 worker threads.
[ WARN] [1572023459.876218953]: Could not retrieve requested transform from buffer. Pointcloud dropped
[ WARN] [1572023459.898790241]: Could not retrieve requested transform from buffer. Pointcloud dropped
I have modified the "local_planner_aero.launch"  file in this way , changing the topic to reflect the color pointcloud of the d435
arg name="pointcloud_topics" default="[/camera/depth/color/points]"
I rebuilt with many software version combinations and the result is always the same . Should be misconfiguration of mine , I use the following commands

roslaunch mavros px4.launch fcu_url:=/dev/ttyUSB0:921600
roslaunch realsense2_camera rs_camera.launch filters:=pointcloud
3)roslaunch local_planner local_planner_aero.launch

Please help , I am struggling from weeks with this issue and I really don't know how to proceed with furher tests.
Thanks in advance !

These are the logs from Mavros
roslaunch mavros px4.launch fcu_url:=/dev/ttyUSB0:92160
.
SUMMARY
CLEAR PARAMETERS

/mavros/

PARAMETERS

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

NODES
/
mavros (mavros/mavros_node)
auto-starting new master
process[master]: started with pid [14519]
ROS_MASTER_URI=http://localhost:11311
setting /run_id to d90e8d40-f749-11e9-8aa8-d6cee9c34fd1
process[rosout-1]: started with pid [14531]
started core service [/rosout]
process[mavros-2]: started with pid [14539]
[ INFO] [1572023218.559428658]: FCU URL: /dev/ttyUSB0:921600
[ INFO] [1572023218.567919642]: serial0: device: /dev/ttyUSB0 @ 921600 bps
[ INFO] [1572023218.604219087]: GCS bridge disabled
[ INFO] [1572023218.639132154]: Plugin 3dr_radio loaded
[ INFO] [1572023218.643739423]: Plugin 3dr_radio initialized
[ INFO] [1572023218.644026876]: Plugin actuator_control loaded
[ INFO] [1572023218.651635032]: Plugin actuator_control initialized
[ INFO] [1572023218.663705715]: Plugin adsb loaded
[ INFO] [1572023218.671914141]: Plugin adsb initialized
[ INFO] [1572023218.672572799]: Plugin altitude loaded
[ INFO] [1572023218.675476496]: Plugin altitude initialized
[ INFO] [1572023218.675871347]: Plugin cam_imu_sync loaded
[ INFO] [1572023218.678037844]: Plugin cam_imu_sync initialized
[ INFO] [1572023218.678474258]: Plugin command loaded
[ INFO] [1572023218.695927484]: Plugin command initialized
[ INFO] [1572023218.696337751]: Plugin companion_process_status loaded
[ INFO] [1572023218.702326503]: Plugin companion_process_status initialized
[ INFO] [1572023218.702688697]: Plugin debug_value loaded
[ INFO] [1572023218.713877437]: Plugin debug_value initialized
[ INFO] [1572023218.714029888]: Plugin distance_sensor blacklisted
[ INFO] [1572023218.714510521]: Plugin fake_gps loaded
[ INFO] [1572023218.741166671]: Plugin fake_gps initialized
[ INFO] [1572023218.741712774]: Plugin ftp loaded
[ INFO] [1572023218.765444601]: Plugin ftp initialized
[ INFO] [1572023218.766010392]: Plugin global_position loaded
[ INFO] [1572023218.800931740]: Plugin global_position initialized
[ INFO] [1572023218.801428676]: Plugin gps_rtk loaded
[ INFO] [1572023218.807083204]: Plugin gps_rtk initialized
[ INFO] [1572023218.807516388]: Plugin hil loaded
[ INFO] [1572023218.837304520]: Plugin hil initialized
[ INFO] [1572023218.838391727]: Plugin home_position loaded
[ INFO] [1572023218.847111257]: Plugin home_position initialized
[ INFO] [1572023218.847880072]: Plugin imu loaded
[ INFO] [1572023218.864697506]: Plugin imu initialized
[ INFO] [1572023218.865108190]: Plugin landing_target loaded
[ INFO] [1572023218.896029676]: Plugin landing_target initialized
[ INFO] [1572023218.896491976]: Plugin local_position loaded
[ INFO] [1572023218.912283922]: Plugin local_position initialized
[ INFO] [1572023218.912896433]: Plugin log_transfer loaded
[ INFO] [1572023218.921215851]: Plugin log_transfer initialized
[ INFO] [1572023218.921668620]: Plugin manual_control loaded
[ INFO] [1572023218.929207920]: Plugin manual_control initialized
[ INFO] [1572023218.929625740]: Plugin mocap_pose_estimate loaded
[ INFO] [1572023218.937841250]: Plugin mocap_pose_estimate initialized
[ INFO] [1572023218.938268654]: Plugin mount_control loaded
[ INFO] [1572023218.945450760]: Plugin mount_control initialized
[ INFO] [1572023218.945842382]: Plugin obstacle_distance loaded
[ INFO] [1572023218.954172373]: Plugin obstacle_distance initialized
[ INFO] [1572023218.954563630]: Plugin odom loaded
[ INFO] [1572023218.964961158]: Plugin odom initialized
[ INFO] [1572023218.965370436]: Plugin onboard_computer_status loaded
[ INFO] [1572023218.971114913]: Plugin onboard_computer_status initialized
[ INFO] [1572023218.971691381]: Plugin param loaded
[ INFO] [1572023218.980332264]: Plugin param initialized
[ INFO] [1572023218.980763625]: Plugin px4flow loaded
[ INFO] [1572023218.996733283]: Plugin px4flow initialized
[ INFO] [1572023218.996852244]: Plugin rangefinder blacklisted
[ INFO] [1572023218.997336315]: Plugin rc_io loaded
[ INFO] [1572023219.005980010]: Plugin rc_io initialized
[ INFO] [1572023219.006108866]: Plugin safety_area blacklisted
[ INFO] [1572023219.006558405]: Plugin setpoint_accel loaded
[ INFO] [1572023219.013601864]: Plugin setpoint_accel initialized
[ INFO] [1572023219.014428232]: Plugin setpoint_attitude loaded
[ INFO] [1572023219.038096308]: Plugin setpoint_attitude initialized
[ INFO] [1572023219.038661266]: Plugin setpoint_position loaded
[ INFO] [1572023219.071925188]: Plugin setpoint_position initialized
[ INFO] [1572023219.072435093]: Plugin setpoint_raw loaded
[ INFO] [1572023219.092291018]: Plugin setpoint_raw initialized
[ INFO] [1572023219.092766130]: Plugin setpoint_velocity loaded
[ INFO] [1572023219.105369478]: Plugin setpoint_velocity initialized
[ INFO] [1572023219.106229129]: Plugin sys_status loaded
[ INFO] [1572023219.133400756]: Plugin sys_status initialized
[ INFO] [1572023219.134019673]: Plugin sys_time loaded
[ INFO] [1572023219.146689481]: TM: Timesync mode: MAVLINK
[ INFO] [1572023219.149752035]: Plugin sys_time initialized
[ INFO] [1572023219.150231002]: Plugin trajectory loaded
[ INFO] [1572023219.163595718]: Plugin trajectory initialized
[ INFO] [1572023219.164055518]: Plugin vfr_hud loaded
[ INFO] [1572023219.166122950]: Plugin vfr_hud initialized
[ INFO] [1572023219.166224046]: Plugin vibration blacklisted
[ INFO] [1572023219.166558583]: Plugin vision_pose_estimate loaded
[ INFO] [1572023219.183457580]: Plugin vision_pose_estimate initialized
[ INFO] [1572023219.183820607]: Plugin vision_speed_estimate loaded
[ INFO] [1572023219.192755714]: Plugin vision_speed_estimate initialized
[ INFO] [1572023219.193361610]: Plugin waypoint loaded
[ INFO] [1572023219.205584899]: Plugin waypoint initialized
[ INFO] [1572023219.205743808]: Plugin wheel_odometry blacklisted
[ INFO] [1572023219.206233088]: Plugin wind_estimation loaded
[ INFO] [1572023219.209199026]: Plugin wind_estimation initialized
[ INFO] [1572023219.209343351]: Autostarting mavlink via USB on PX4
[ INFO] [1572023219.209667576]: Built-in SIMD instructions: ARM NEON
[ INFO] [1572023219.209752525]: Built-in MAVLink package version: 2019.10.10
[ INFO] [1572023219.209825339]: Known MAVLink dialects: common ardupilotmega ASLUAV autoquad icarous matrixpilot paparazzi slugs standard uAvionix ualberta
[ INFO] [1572023219.209967268]: MAVROS started. MY ID 1.240, TARGET ID 1.1
[ INFO] [1572023219.214008225]: IMU: Attitude quaternion IMU detected!
[ INFO] [1572023219.218692267]: IMU: High resolution IMU detected!
[ INFO] [1572023219.513291339]: CON: Got HEARTBEAT, connected. FCU: PX4 Autopilot
[ INFO] [1572023219.518579036]: IMU: High resolution IMU detected!
[ INFO] [1572023219.519635566]: IMU: Attitude quaternion IMU detected!
[ INFO] [1572023220.535565636]: VER: 1.1: Capabilities         0x000000000000e4ef
[ INFO] [1572023220.536016686]: VER: 1.1: Flight software:     010902ff (106905871d000000)
[ INFO] [1572023220.536612321]: VER: 1.1: Middleware software: 010902ff (106905871d000000)
[ INFO] [1572023220.536998422]: VER: 1.1: OS software:         071c00ff (423371c7d4012e72)
[ INFO] [1572023220.537279677]: VER: 1.1: Board hardware:      00000011
[ INFO] [1572023220.537734268]: VER: 1.1: VID/PID:             26ac:0011
[ INFO] [1572023220.538215787]: VER: 1.1: UID:                 3335510a38343732
[ WARN] [1572023220.538984030]: CMD: Unexpected command 520, result 0
[ INFO] [1572023229.517245503]: HP: requesting home position
[ INFO] [1572023234.532071685]: WP: item #0* F:3 C: 22 p: 15.000000 0.000000 0.000000 nan x: 38.740643 y: -9.302164 z: 20.000000
[ INFO] [1572023234.546613294]: WP: item #1  F:3 C: 16 p: 0.000000 0.000000 0.000000 nan x: 38.740627 y: -9.302159 z: 20.000000
[ INFO] [1572023234.549816996]: WP: item #2  F:3 C: 16 p: 0.000000 0.000000 0.000000 nan x: 38.740559 y: -9.302008 z: 20.000000
[ INFO] [1572023234.555305426]: WP: item #3  F:2 C: 20 p: 0.000000 0.000000 0.000000 nan x: 0.000000 y: -317498284827322163791582879838896128.000000 z: 20.000000
[ INFO] [1572023234.556385497]: WP: mission received
[ INFO] [1572023239.516156424]: HP: requesting home position
[ INFO] [1572023249.515614954]: HP: requesting home position
[ INFO] [1572023259.514650575]: HP: requesting home position

I also meet the same problem, and my drone can not plan a path. So will your planner work better?

Actually it doesn't work .The error seems to me indicating that the pointcloud coming from the Realsense camera has a format not suitable for the planner. Please help to understand .
Thanks a lot,
Germal

You need PX4 Firmware 1.10 beta to use latest avoidance. This might fix your issue.
Also, I have a potential bugfix in #520 around transforming the point cloud, but this isn't your issue I think.
I'm not sure if local_planner_aero has been used in a long time...

Hi
I tried with 1.10 beta but I found the same error.
I think too that it is an issue regarding TF transformation but in my case it is not performance related , because  the planner  doesn't work.

. I don't think local_planner_aero has been used in a long  time...

Do you mean that avoidance doesn't work anymore on an hardware platform ?
Thanks
Germal

I think that this point It is worth clarifying. Do Avoidance work on an hardware platform ?
Please reply
Thanks
Germal

Yes, we fly the local_planner regularly using both Intel and ARM companion computers.

With a Realsense Depth camera ?

Yes, and also with Structure Core.

Could you please provide the software version combination and the steps that you have followed with Realsense ?
I followed the readme and I have that issue on TF.
Thanks,
Germal


updated GUEST_CPU_NUM in start_civ.sh

Signed-off-by: Neeraj Solanki<EMAIL_ADDRESS>

Hi Yadong,
We had discussion at "https://github.com/projectceladon/vm_manager/pull/51".
I mistakenly created new commit there instead of amending.
I have created this new commit.
Kindly review and approve the same.

Approved.


Random videos came up when downloading videos from users

This bug cannot be consistently reproduced, but I have encountered this for several times.

However, I didn't find anything wrong as I went through the related code.
I would be greatly appreciated if you could solve this problem😭
Thanks a lot.
Best regards,

The screenshot says that your DNS cannot resolve miki.iwara.tv.
We should have a better error report, but for now, maybe you can try changing your DNS to <IP_ADDRESS> or <IP_ADDRESS>.


Add iter-ops

I wrote a library in TypeScript, for processing sync+async iterable objects (very high-performance, open protocol, many useful operators).

Looks great! Thank you @vitaly-t!


Investigate model groups performance issues

From a user-reported bug, I found that a relatively small model (85mb) is taking ages to convert see file (confidential).
This might be due to model groups since the model has plenty of them.
Partly related to: https://github.com/specklesystems/speckle-sharp/issues/2446

Closed with #2454


Set right var type acording to readme

/test all

Error creating DB Instance: InvalidParameterCombination: Cannot find version 5.7.17 for MySQL

Looks like the test is broken

@MaxymVlasov Our tests seem to be currently broken. You can wait a couple weeks and ping me again when they'll likely be fixed or take a crack at fixing it yourself since it should be fairly easy. Here is the error:
Error: Error creating DB Instance: InvalidParameterCombination: Cannot find version 5.7.17 for mysql
TestExamplesComplete 2022-05-12T20:28:35Z logger.go:66: 	status code: 400, request id: 564e06e5-098d-40ae-9102-9a92b2d65484

Tests are fixed. Please merge code from the default branch to your PR branch and we can rerun the tests.

/test all


Feature Request

Feature Request
Want to add Virtual Assistant Using Python
adding multiple futures with commend like saying jokes,time etc
A GSSOC 2022 Contributor CHARAN KUMAR UDAYGIRI

@UDAYAGIRICHARAN these features are already available. You can go through the project, may be you can find out something to contribute on.


[3.0] Make the package framework-agnostic

As the name of this repository might suggest, stats currently only works for Laravel applications.
Over the years I've received multiple questions, if stats could be made framework agnostics so it could be used in other frameworks too (for example Symfony applications).
With the work done in the release of 2.0 such a step should be easier now. The package basically consists of the following parts:

A Class Collector: Loops through folders in a path and finds all PHP classes
Value Objects to describe a Project: A Project-instance takes a collection of Classes and Classifies them.
A collection of Classifiers: These simple classes take a given class in a Laravel project and try to associate them with a "Component"
Laravel specific classes: Artisan Command, ServiceProvider, etc.

My idea to make stats framework agnostic, is to move the Class Collector and the Value Objects into a separate package. This package (laravel-stats) would require this new package as a dependency and would pass its list of Laravel specific Classifiers to the newly created "core"-package.
It would then be trivial to create separate packages for other frameworks like Symfony or Zend: Define your own list of Classifiers which describe components in each framework and pass them to the "core"-package.
To make this actually work, the Class Collector and Value Obejcts would have to be rewritten though. They currently rely heavily on Laravels Collections.
The new "core"-package probably shouldn't have illuminate/support as a dependency and these mentioned classes should then rather use plain older PHP arrays.
If you're interested in this idea, please share your comments, opinions and ideas below!

I think it'll be nice, so applications running other PHP frameworks can benefit. Let the core be framework-agnostic. Then we can create classifiers for various frameworks, grouped in folders, so it's easy to create classifiers for other frameworks or php applications


shell not launching

Version: 1.0.70
Platform: win32 10.0.17134
Plugins: none
No shell is loading when creating a new terminal.

same issue here

I'm also getting the same issue since upgrading from 69 to 70. Tried using various different shells (Git bash, PS etc). Reverted back to 69 until a fix is in place.

It looks like the detection(?) of when to use ConPTY is wrong (I have no clue what this all means but at least I managed to fix it on my system). I added useConPTY: false to the terminal element in my config file.
So my config looks like:
hotkeys:
  shell: {}
ssh: {}
terminal:
  environment: {}
  useConPTY: false

Could you try this and let me know if that works for you?

Could you try this and let me know if that works for you?

Thank you! Every shell works, except WSL/Ubuntu. But interestingly WSL/Default Distro does work, although I am pretty sure that i only have one WSL-distro installed on my laptop.

Could you try this and let me know if that works for you?

Thank you, that's worked for me as well.

Keep up the good work, this is easily the best terminal on Windows right now.

Sadly I'm not affiliated with this project whatsoever other than being a user ;) I'm glad I was able to help out though. This is indeed easily the best terminal around.

@dietervanhoof 's solution worked for me too.


How to Implement Graphical Nodes Similar to FastGPT in a Node Project

Hello,

Once again, I need to trouble you for some assistance. I am working on a Workflow project and have encountered some challenges that I hope you can help me with. The project involves implementing functionalities similar to graphical nodes in a flowchart, as shown in the attached image.

I have encountered an issue in Nodify.Shapes. I see that there are 4 connectors, but I am at a loss about how to create a new Out connector on the right side. Could you please provide some guidance on how to achieve this?

Thank you very much for your help!

I really enjoy this type of UI design, but I found it quite challenging when I started working on it. 😅

Hi,
You can use a StackPanel to add more connectors on any side.

<StackPanel DockPanel.Dock="Right" VerticalAlignment="Center">
    <nodify:Connector DataContext="{Binding RightConnector}"
                        Anchor="{Binding Anchor, Mode=OneWayToSource}"
                        HorizontalContentAlignment="Right"
                        Margin="0 0 -11 10"
                        Visibility="Hidden"
                        Height="Auto"
                        Width="25"
                        x:Name="RightConnector" />
    <nodify:Connector DataContext="{Binding RightConnector2}"
                        Anchor="{Binding Anchor, Mode=OneWayToSource}"
                        HorizontalContentAlignment="Right"
                        Margin="0 0 -11 0"
                        Visibility="Hidden"
                        Height="Auto"
                        Width="25"
                        x:Name="RightConnector2" />
</StackPanel>

Is this what you are having trouble with?

Thank you. Could you provide some insights or a detailed approach on how to implement a feature similar to a bird's-eye view?

Do you mean a minimap?

I created a PR that adds a Minimap control to the library #124

Thank you


Add Izumi Project monorepo

Once scala-steward finds an update it tries to apply it in all .sbt and .scala files. So if we're lucky it should get along with that scheme. We'll find out soon. :-)


android studio 运行rn一直报错

一直报安卓环境的错误是怎么回事
E:\PrivateProject\CloudPos>yarn android
yarn run v1.22.11
$ react-native run-android
info Running jetifier to migrate libraries to AndroidX. You can disable it using "--no-jetifier" flag.
Jetifier found 1287 file(s) to forward-jetify. Using 8 workers...
info JS server already running.
info Installing the app...

Task :app:processDebugResources FAILED

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.3/userguide/command_line_interface.html#sec:command_line_warnings
239 actionable tasks: 4 executed, 235 up-to-date
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':app:processDebugResources'.

A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade
Android resource linking failed
C:\Users\Administrator.gradle\caches\transforms-2\files-2.1\aaa1d65c708bd44ba1748eb3dfd7c0f0\core-1.7.0-alpha02\res\values\values.xml:105:5-114:25: AAPT: error: resource android:attr/lStar not found.

Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

Get more help at https://help.gradle.org

BUILD FAILED in 9s
error Failed to install the app. Make sure you have the Android development environment set up: https://reactnative.dev/docs/environment-setup. Run CLI with --verbose flag for more details.
Error: Command failed: gradlew.bat app:installDebug -PreactNativeDevServerPort=8081
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
请问各位大佬这是怎么解决呢，我已经检查了好几遍环境没问题和重启好几次了都不行

环境信息呢  npx react-native info

E:\PrivateProject\CloudPos>npx react-native info
info Fetching system and libraries information...
System:
    OS: Windows 7 6.1.7601
    CPU: (8) x64 Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz
    Memory: 7.77 GB / 15.89 GB
  Binaries:
    Node: 12.16.2 - E:\node-v12.16.2-win-x64\node.EXE
    Yarn: 1.22.11 - E:\node-v12.16.2-win-x64\yarn.CMD
    npm: 6.14.4 - E:\node-v12.16.2-win-x64\npm.CMD
    Watchman: Not Found
  SDKs:
    Android SDK:
      API Levels: 19, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30
      Build Tools: 23.0.2, 24.0.1, 24.0.2, 25.0.1, 27.0.3, 28.0.3, 29.0.0, 29.0.2, 29.0.3
      System Images: android-28 | Intel x86 Atom, android-28 | Google APIs Intel x86 Atom, android-28 | Google Play Intel x86 Atom_64, android-29 | Intel x86 Atom, android-29 | Intel x86 Atom_64, android-29 | Google APIs Intel x86 A
tom, android-29 | Google APIs Intel x86 Atom_64, android-29 | Google Play Intel x86 Atom, android-29 | Google Play Intel x86 Atom_64, android-Q | Android TV Intel x86 Atom
      Android NDK: Not Found
    Windows SDK: Not Found
  IDEs:
    Android Studio: Version  <IP_ADDRESS> AI-191.8<IP_ADDRESS>77832
    Visual Studio: 16.11.31624.102 (Visual Studio Community 2019)
  Languages:
    Java: 1.8.0_191
    Python: Not Found
  npmPackages:
    @react-native-community/cli: Not Found
    react: 16.13.1 => 16.13.1
    react-native: 0.63.3 => 0.63.3
    react-native-windows: Not Found
  npmGlobalPackages:
    react-native: Not Found
------------------ 原始邮件 ------------------
发件人:                                                                                "reactnativecn/react-native-website"                                                                                @.>;
发送时间: 2021年9月15日(星期三) 中午12:07
@.>;
<EMAIL_ADDRESS>主题: Re: [reactnativecn/react-native-website] android studio 运行rn一直报错 (#504)
环境信息呢  npx react-native info
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

我搜了下，很多人说跟netinfo这个包有关，你有用这个吗？package.json贴出来看下
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

这是由某个第三方模块引起的问题：
https://stackoverflow.com/questions/69019631/android-resource-linking-fails-on-test-execution-even-when-nothing-has-been-cha/69020629#69020629
简而言之，某个第三方模块引用了androidx.core:core-ktx:+这个安卓依赖，但这个月初core-ktx官方更新到了1.7版本，最低sdk版本要求为31，否则就会报这个错。所以解决方案是把项目的compilesdkversion升级到31，或者找到依赖了core-ktx的组件（这个很难找），锁死其版本为1.6

另外你的组件依赖很混乱，导航器有多个重复版本，可能引发更多冲突。

解决了 谢谢大佬
------------------ 原始邮件 ------------------
发件人:                                                                                "reactnativecn/react-native-website"                                                                                @.>;
发送时间: 2021年9月15日(星期三) 下午2:32
@.>;
<EMAIL_ADDRESS>主题: Re: [reactnativecn/react-native-website] android studio 运行rn一直报错 (#504)
这是由某个第三方模块引起的问题：
https://stackoverflow.com/questions/69019631/android-resource-linking-fails-on-test-execution-even-when-nothing-has-been-cha/69020629#69020629
简而言之，某个第三方模块引用了androidx.core:core-ktx:+这个安卓依赖，但这个月初core-ktx官方更新到了1.7版本，最低sdk版本要求为31，否则就会报这个错。所以解决方案是把项目的compilesdkversion升级到31，或者找到依赖了core-ktx的组件（这个很难找），锁死其版本为1.6
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.


Documentation and other questions...

Thank u for a great work!!!
ur plugin is amazing, but there are not enough documentation
i didn't found description of methods and due it i have to searching information by analyse of page source.
Moreover ur website is nonworking
https://cdn.rah-emil.ru/angry-cart.js/demo/#
I deem that a lot of people would be grateful if u did documentation like this one
http://kenwheeler.github.io/slick/
P.S.
Thanks again and good luck with ur project!

Thanks for your feedback!
I will definitely do some normal documentation and more examples soon :)


Add a hal for Nuclei RISC-V core and SoCs

This PR adds support for GigaDevice GD32V SoC and SiPeed Longan Nano board that is use the SoC.
Currently, the west module dependency points to https://github.com/soburi/hal_nuclei.
Support:
GPIO
UART (UART0 only, pins are fixed)
WIP:
Support pinctrl.
Add SPI and other drivers.
Origin
Nuclei Software Development Kit
https://github.com/Nuclei-Software/nuclei-sdk
Fork and modifying to work with ZephyrRTOS
https://github.com/soburi/hal_nuclei
Purpose
Driver and Board Support Package for Nuclie RISCV core and SoC
Mode of integration
As External Module.
Same as other HAL modules are so.
Pull Request
https://github.com/zephyrproject-rtos/zephyr/pull/34970
(As a part of GigaDevice GD32V support PR)
Description
It is a BSP that is needed to support Nuclei's RISC-V core based SoCs.
I sent another PR to support GigaDevice GD32V SoCs.
This package is used by the PR.
Dependencies
No other module needs to work on this.
Revision
https://github.com/soburi/hal_nuclei
ce2159a6320d9b72ed52a609bcce0fb0e2dd5261
License
Apache-2.0

I noted that hal_nuclei/SoC  is, in fact, GD32VF103 Firmware Library. On my view, a hal_gigadevice  should be created. That could aggregate all GigaDevice MCUs at same place, including ARM and RISC-V devices.
GigaDevice uses same peripheral on both ARM and RISC-V (some exceptions like interrupt controller) and all drivers developed to GD32 should be shared between both architectures always possible.
@soburi ,
What do you need from hal_nuclei that is not on hal_nuclei/SoC?

I noted that hal_nuclei/SoC is, in fact, GD32VF103 Firmware Library. On my view, a hal_gigadevice should be created. That could aggregate all GigaDevice MCUs at same place, including ARM and RISC-V devices.

Previously, https://github.com/riscv-mcu/GD32VF103_Firmware_Library is distributed by GigaDevice as SDKs.
The repository's README references https://github.com/Nuclei-Software/nuclei-sdk that provides more good support for the SoC.
nuclei-sdk seems newer,  I select it.

GigaDevice uses same peripheral on both ARM and RISC-V (some exceptions like interrupt controller) and all drivers developed to GD32 should be shared between both architectures always possible.

I agree it.

@soburi ,
What do you need from hal_nuclei that is not on hal_nuclei/SoC?

nuclei/NMSIS/Core contains header files for CPU core related defines such as registers etc.
Any other files are not included from CMakeLists.txt.

The module repo contains various .a files that should not be allowed.

@soburi thanks for the submission.
This was discussed in today's Technical Steering Committee meeting, and we had a couple of additional questions for you:

Are you employed by GigaDevices? If not, do you have contact with them? Being employed by the silicon vendor is not a requirement.
Are you willing to maintain the port for the foreseeable future? This means reacting to GitHub issues being filed, updating the HAL repo and board support when required and other maintainer-related tasks.
We noticed that the original HAL repo contains files that are not Apache v2 licensed. Could you run a tool like scancode toolkit and post a summary of the licenses found?
As @galak mentioned, precompiled libraries are not allowed, so please remove those

@carlescufi,
Thanks for checking this PR.

Are you employed by GigaDevices? If not, do you have contact with them? Being employed by the silicon vendor is not a requirement.

I'm not an employee of GigaDevice. and not in contact with them so well.
(I'm just a user of their board and chip. and I want to run Zephyr on it.
This chip is released a past year ago but has not to do support Zephyr yet.
To me, it looks like GigaDevice has not much attention to Zephyr.
So I added to support this chip to Zephyr.
I want GigaDevice to contribute to Zephyr!)

Are you willing to maintain the port for the foreseeable future? This means reacting to GitHub issues being filed, updating the HAL repo and board support when required and other maintainer-related tasks.

Yes, I can handle problems and maintain this ports.

We noticed that the original HAL repo contains files that are not Apache v2 licensed. Could you run a tool like scancode toolkit and post a summary of the licenses found?
As @galak mentioned, precompiled libraries are not allowed, so please remove those

Correct the problems and pushed. (https://github.com/soburi/hal_nuclei/commit/7b31adc247673bf12fd655361c479a0d4b551787)
Remove static link libraries and files that do not explicitly mention licenses.
I attach to this PR the result of scancode (gziped html).
(run scancode -clpeu --classify --summary --verbose --html scancode.html [dir])
scancode.html.gz

@soburi thank you very much for the clarifications, the attached scan report and the modifications to the PR. Would you mind removing the doc/ folder from the HAL repo so we avoid the GPL licenses? I do not think we need that in Zephyr. Please attach another report after doing that, and hopefully there will only be Apache and BSD after that.

@fanghuaqi thank you for your comment in the PR. Can you state, on behalf of GigaDevice, that you intend to help @soburi maintain this port in the future?

@carlescufi

Would you mind removing the doc/ folder from the HAL repo so we avoid the GPL licenses?

I forgot.
I correct it and re-pushed. (https://github.com/soburi/hal_nuclei/commit/b22713f28040fd42be0f533eb444678b9933b9d6)
The result of scancode is here.
Only Apache2 and BSD3-Clause are remain.
scancode2.html.gz

@fanghuaqi thank you for your comment in the PR. Can you state, on behalf of GigaDevice, that you intend to help @soburi maintain this port in the future?

Hi @carlescufi ， I am the maintainer from Nuclei System Technology, not on behalf of GigaDevice, by the way, our doc under doc/ folder are also apache 2.0 license.
If you would like to maintain a HAL for nuclei, I would prefer to maintain it in nuclei-sdk directly, we can discuss which files we need to add?
Thanks
Huaqi

I am not sure I understand why we are bringing in full SoCs as HALs + external sources like this now. There are native drivers in Zephyr for lots of SoCs, why does this one need to use out-of-tree drivers like this? They don't integrate into Zephyr natively this way, and just makes it awkward.
It would be a lot easier if you did lightweight ports of the peripherals as native Zephyr drivers. I'd expect that at least some of the peripherals are standard ones, they might even already have working drivers in Zephyr.

@olofj
Thank you for your mention.
Please tell me about your concerns.
Is it concern about the overall policy about zephyr?
Or is it a problem with this PR?
I wrote the code regarding the existing implementation of other SoCs. If my code violates zephyr's manner, I will correct it.
If it is problem with zephyr overall, it is a bit difficult for me to answer shortly.
I want to discuss.
Regards.

I would like suggest a structure to accommodate both ARM and RISC-V:

Add a hal_gigadevice
This will have all SoC related code, something like this proposal
Instead add hal_nuclei or even a sdk_nuclei, I believe the relevant part is NMSIS. NMSIS is pretty close to ARM CMSIS. I think this will better scale since NMSIS is supposed to be used by any other new manufacturer than GigaDevices.
sdk_nuclei can use hal_gigadevice as submodule, same with NMSIS.
Once all gigadevices are at same repository, as consequence it is possible share any gd32 zephyr drivers between ARM and RISC-V.

This ARM+RISC-V build for both ARM and RISC-V. It can be a prove of concept related to the structure proposed above. The gd32f403z_eval was tested on HW and works. RISC-V part implements the structure but don't have a working code yet. It should be reworked using NMSIS to have a functional code. Docs should be Ignored since it is just a structure proposal.
This is just a structure proposal that, I think, can inspire some ideas and help to move forward.

@nandojve
Thanks for the comments.
I was worried about how source code structure is good for this SoC in coding.
The suggestion is sound good.
I pushed sources to hal_nuclei which is a single repository.
and after, remove files that are licensed unclearly.
As a result, now it contains only NMSIS (headers about Nuclei core) and GigaDevice peripheral driver.
I think splitting Nuclei's source and GigaDevice's source will make it easy to maintain.
NMSIS is like an ARM's CMSIS, I think it may good for creating that own directory.
GigaDevice peripherals are also used by other GigaDevice's ARM SoCs. It was maybe good to split into hal_gigadevice.
As so result of the above, I think the directory structure will be like this.
modules
|- hal
|- nuclei
|- NMSIS
|- gigadevice
|- GD32VF103_Firmware_Library
|- (other GigaDevice SoC's driver add in future...)
I'll try to it. (https://github.com/soburi/hal_gigadevice)

Hi， I think a hal for NMSIS is a good idea, we can follow https://github.com/zephyrproject-rtos/cmsis to have a  https://github.com/zephyrproject-rtos/nmsis to track https://github.com/Nuclei-Software/NMSIS/

For https://github.com/soburi/hal_gigadevice, I think you can split the https://github.com/Nuclei-Software/nuclei-sdk/tree/master/SoC/gd32vf103 as part of hal_gigadevice HAL since it used APIs defined in NMSIS, and follow similar projects like https://github.com/zephyrproject-rtos/hal_nxp.
Thanks
Huaqi

@fanghuaqi
I think this bit complex situation caused by GD32VF103_Firmware_Library not using NMSIS.
So, I modify that library to use NMSIS, and sent PR to GD's repos.
https://github.com/GigaDevice-Semiconductor/GD32VF103_Firmware_Library/pull/2
Once this patch is merged, "hal_gigadevice" will make it easy to separate gd32vf103 drivers, I think.
Until so, We need to modify gd32vf103 driver to fit with NMSIS.
(Their account seem to be a sleeping. I wonder they can notice this PR...)

I splitting modules by referred to advice from  @nandojve, @carlescufi and @fanghuaqi.
https://github.com/soburi/hal_nuclei/tree/nmsis
https://github.com/soburi/hal_gigadevice/tree/nmsis
(This is in another branch, not push to the PR branch yet.)
It well-separating CPU core-related header and SoC-specific drivers.
It is better than my first commit, I think.
Also, I updating the zephyr code along with module changes.
https://github.com/soburi/zephyr/tree/add_basic_support_gd32v_update
(It also in another branch, not push to the PR branch yet.)
ScanCode results of the two modules are attached.
scancode.zip

@katsuster @cfriedt would you please weigh in on the NMSIS question here?

@katsuster @cfriedt would you please weigh in on the NMSIS question here?

I think @nandojve has the right idea. Components seem to be re-usable and are already used with a few SoCs / SoC families, then separate hal_gigadevices and nmsis out and have the nuclei_sdk use those.
However, I also do agree with @olofj 's thoughts as well. Will there be a fair amount of code reuse with these modules? Will more SoC's / boards be coming down the pipes that will make it worth the effort? Otherwise, lightweight drivers may be more desirable.

@katsuster @cfriedt would you please weigh in on the NMSIS question here?

I agree with adding NMSIS and HAL for gigadevice separately.

However, I do agree with @olofj 's thoughts as well. Will there be a fair amount of code reuse with these modules? Will more SoC's / boards be coming down the pipes that will make it worth the effort? Otherwise, lightweight drivers may be more desirable.

HALs as a separate repository are fully supported in our current policy. Those are for drivers and potentially some SoC-specific files that are to be shared with bare-metal projects. Major silicon vendors are currently using this model, which has additional benefits for both the vendor and the user.
Note that this only includes drivers and SoC-specific code. In no case this includes common architecture code, which belongs in the main zephyr tree under arch/.
In the particular case of Arm, we also reuse the CMSIS layer as a module because that is provided by the architecture vendor (Arm itself). This was not the case in earlier versions of Zephyr, but we adopted this model because many of the HALs from vendors were themselves bundling or requiring CMSIS, so we decided to settle on a common version for all those HALs.
In the case of NMSIS, I would make the following statements:

If it contains generic RISC-V architecture code that applies to all SoCs from all vendors that use RISC-V as an ISA, we shouldn't pull it in, and instead the code should be added to the main tree, under arch/.
If it contains architecture code that overlaps with what is today in arch/riscv, then we should not pull this in and instead extend arch/riscv
If it contains non-arch, SoC-specific code that applies only to Nuclei, then I would suggest we pull this together with the HAL, because hal_gigadevices is a repository for everything GD-specific. We do the same in other HALs.

Hi @carlescufi , about the statements you have made, I need to explain as follows:

Nuclei is a company which provide RISC-V Processor IP to customer, Gigadevice use Nuclei's Bumblebee Core(aka N205) RISC-V IP as gd32vf103 SoC's processor core
NMSIS was developed by Nuclei, currently only support Nuclei RISC-V processor, it was used to provide Nuclei RISC-V Core HAL such as CSR Registers, TIMER, ECLIC, PMP Registers, DSP Registers(RISC-V P Extension), FPU registers, and Core Access Functions.
Previous GD32VF103_Firmware_Library was released before NMSIS, so we have modified the firmware library directly in our Nuclei SDK project https://github.com/Nuclei-Software/nuclei-sdk/tree/master/SoC/gd32vf103, which seperate the RISC-V Core HAL and SoC firmware library
Our customer using Nuclei RISC-V Processors now are following the NMSIS standard now, if in future they need to support Zephyr, they may also need to include NMSIS-Core headers, and we are also planning to adding support for our demosoc(fpga based) to Zephyr project, and we are also depending on NMSIS.

Thanks
Huaqi

@carlescufi , @fanghuaqi

Previous GD32VF103_Firmware_Library was released before NMSIS,

GD32VF103_Firmware_Library contains files with unclear licenses.
(n200_... files in GD32VF103_Firmware_Library)
NMSIS has no files with unclear licenses.
These files can be replaced by NMSIS's one.
I think need to use NMSIS's files from this viewpoint.
This means combining sources from different providers, Nuclei and GigaDevice.
Of cource, it can do put into the same directory, but I think a separate directory by each provider easier to maintain. (e.g. hal/nuclei and hal/gigadevice)
Also I think, Nuclei provides real hardware to abstract such as interrupt controller, and more. That's a good reason to create a hal / nuclei directory.
(This may disagree from a perspective. Difficult ....)
@fanghuaqi,
I think NMSIS files no need (or must not) customize by the SoC vendor.
Is my understanding is correct?
If not so, we need to use these files provided by the SoC vendor.

Hi @soburi,
I took a deeper look at the NMSIS and hal_gigadevices and I have some comments and questions:
It looks as though what NMSIS provides mostly either duplicates what's already directly included in Zephyr e.g. CSR access convenience macros - for example https://github.com/soburi/hal_nuclei/blob/nmsis/NMSIS/Core/Include/core_feature_base.h#L303-L311 vs https://github.com/zephyrproject-rtos/zephyr/blob/d109805cb2f31d17f4d9a9f8062d746afb038074/include/arch/riscv/csr.h#L183-L189 or convenience macros with various wrappers for many custom CPU instructions - those in turn seem not to be required by the new board port you are adding. Is that correct? Is there anything specific in NMSIS that requires it? Wouldn't it be easier to use what's already included in Zephyr and maybe even extend it if there's indeed something missing?
hal_gigadevice in turn seems to include multiple drivers which are indeed not present in Zephyr at the moment. However they will require proper Zephyr wrappers so maybe it makes sense to port the code to write actual drivers instead (as already suggested in the previous posts)?

Hi @kgugala
Thank you for inspecting the PR.

those in turn seem not to be required by the new board port you are adding. Is that correct? Is there anything specific in NMSIS that requires it? Wouldn't it be easier to use what's already included in Zephyr and maybe even extend it if there's indeed something missing?

NMSIS contains a Nuclei-specific register defines such as an interrupt controller. These are referenced from hal_gigadevice.
In this PR, we tried not to change the vendor-supplied code as much as possible.
I think sources under the zephyr directory should use already exists zephyr's definition. If not is so I must correct it.
Make to use zephyr's define in hal_gigadevice need work to modify vendor-supplied code. (It maybe undesirable.)

However they will require proper Zephyr wrappers so maybe it makes sense to port the code to write actual drivers instead (as already suggested in the previous posts)?

The short answer is that using vendor-supplied code was the easiest way to get this SoC to work.
Many devices import external open-sourced codes provided by the vendor.
It has seemed to me that is a usual method in zephyr.
And one more reason, GigaDevice peripherals, and their driver are mostly compatible with STM32.
So I mimicked the source code (and external driver) of the STM32 driver to implements the GigaDevice peripherals driver.
I think it is follows zephyr's external project policy.
https://docs.zephyrproject.org/latest/guides/modules.html#modules-external-projects
But I have no strong reason to use vendor-provided sources.
If Zephyr prefer to be independent of external sources, so I rewrite the PR.

@carlescufi , @fanghuaqi

Previous GD32VF103_Firmware_Library was released before NMSIS,

GD32VF103_Firmware_Library contains files with unclear licenses.
(n200_... files in GD32VF103_Firmware_Library)
NMSIS has no files with unclear licenses.
These files can be replaced by NMSIS's one.
I think need to use NMSIS's files from this viewpoint.
This means combining sources from different providers, Nuclei and GigaDevice.
Of cource, it can do put into the same directory, but I think a separate directory by each provider easier to maintain. (e.g. hal/nuclei and hal/gigadevice)
Also I think, Nuclei provides real hardware to abstract such as interrupt controller, and more. That's a good reason to create a hal / nuclei directory.
(This may disagree from a perspective. Difficult ....)
@fanghuaqi,
I think NMSIS files no need (or must not) customize by the SoC vendor.
Is my understanding is correct?
If not so, we need to use these files provided by the SoC vendor.

No need to be customized by SoC vendor, especially the header files, the only thing need to be customized are the startup/interrupt/exception handing code and link script, which we also provide template files.
If our customer find bugs or need new features, they can open issue or PR to us, and let us improve it, so they can also use the latest version if we provided.
Thanks
Huaqi

Hi @soburi,
I took a deeper look at the NMSIS and hal_gigadevices and I have some comments and questions:
It looks as though what NMSIS provides mostly either duplicates what's already directly included in Zephyr e.g. CSR access convenience macros - for example https://github.com/soburi/hal_nuclei/blob/nmsis/NMSIS/Core/Include/core_feature_base.h#L303-L311 vs
https://github.com/zephyrproject-rtos/zephyr/blob/d109805cb2f31d17f4d9a9f8062d746afb038074/include/arch/riscv/csr.h#L183-L189
or convenience macros with various wrappers for many custom CPU instructions - those in turn seem not to be required by the new board port you are adding. Is that correct? Is there anything specific in NMSIS that requires it? Wouldn't it be easier to use what's already included in Zephyr and maybe even extend it if there's indeed something missing?
hal_gigadevice in turn seems to include multiple drivers which are indeed not present in Zephyr at the moment. However they will require proper Zephyr wrappers so maybe it makes sense to port the code to write actual drivers instead (as already suggested in the previous posts)?

Hi @kgugala , NMSIS-Core is a Nuclei RISC-V Core header files defined for our SoC customer to easily to access the cpu features supported by our RISC-V Core, so we need to define the CSR access APIs, of course you can find csr access in Zephyr existing RISC-V supporting code, it might cause some confusions, but maybe customer can include the files they need maybe zephyr one or NMSIS one.
Thanks
Huaqi

I think it is clear that we have two things here:

hal_gigadevice
NMSIS

In case of [1]

hal_gigadevice in turn seems to include multiple drivers which are indeed not present in Zephyr at the moment. However they will require proper Zephyr wrappers so maybe it makes sense to port the code to write actual drivers instead (as already suggested in the previous posts)?

I would said that we should create a hal_gigadevices. The majority of manufacturers that are supported on Zephyr have their own hal to help. Native drivers are ideal and requires a deep knowledge about both side ( manufacturer IPs and Zephyr driver model ) and HW to test. A driver that manufacturer provide is already well tested and it is easy to create a wrap for it. Because of that I prefer a hal_gigadevice.
About [2]
On my view, it is necessary more talking to understand Zephyr RISC-V shared code vs NMSIS specifics vs NMSIS vendor templates.
@carlescufi Do you think is already possible take a decision about create a hal_gigadevice?

Hi all,
I got some suggestions, so I created and pushed a version that doesn't depend on external modules.
(It is prototyping for proceeding with this discussion. I will undo depending on the result of the discussion )
https://github.com/soburi/zephyr/commits/add_basic_support_gd32v
previous push: https://github.com/soburi/zephyr/tree/99c5643d4cb4cf73d3b66644d6489ae6f4173da9

GigaDevice Driver can remove by reimplementing register access functions.
Pros: No dependence on an external module.
Cons: Reimplementing vendor-supplied code may not be good for the quality aspect.
Nuclei's Driver also able to remove, but these definitions are needed.
It needs to Incorporate their files or import them as external modules.
(It is preferred to import as an external module)
In actuality, most of GigaDevice drivers are simple register access functions.
It can be replaced by defining the register structure.
GigaDevice driver is a thin layer to wrap resigter access, but it is useful to clarify meaning by the function name.
The difference between SoCs is the address of the register, but this could be handled well by the DTS mechanism, I think.
As @nandojve says, the vendor-supplied code has been vendor-tested, I think it's preferred to use it from a quality aspect.
The Nuclei's code was an Apache2 license, so I've incorporated the necessary parts.
I've omitted unnecessary parts, but I think it's easier to maintain import whole modules or as an external
(It has file dependency in modules. It is not preferred to pick only some files.  And As @fanghuaqi says, It is no modification for each SoC.)

It seems we have a second proposal for a gigadevices set of ICs that are proposed in this PR and that requires its own HAL. We need to decide if we create a single repo for both, or one for each of those.

@carlescufi @fanghuaqi @feilongfl
https://github.com/feilongfl/hal_gd32 stores to separate directory the source for each SOC.
It is the preferable structure.
I think it can add gd32vf103's firmware well to it with a bit of modification for coexistence with other SoC's firmware.
It will be like this. (It is similar to proposed by @nanojove)
modules
|- hal
   |- gigadevice (hal_gd32)
       |- devices
             |- gd32e1xx
             |    |- GD32E10x_Firmware_Library_V1.0.3
             |
             | - gd32vf103
             |    |- GD32VF103_Firmware_Library
             |
             |- ( add new device future...)

Nuclei's module can separetly discuss from GigaDevice's hal.
It is no necessary at this time.
But I think it is prefer to create separate hal module.
(It is useful but not fully follows zephyr's coding conventions.
Therefore, it is more convenient to use an external module than to import it.)

Hi, for hal_gd32, it currently contains SoC firmware using ARM core, it we put gd32vf103 library into it, it means this hal will contains firmware for different cpu arch? Is it ok for this case, and of course it will depend on different arch hal such as CMSIS or NMSIS.
Thanks
Huaqi

@fanghuaqi @carlescufi
Zephyr's guide has no description about the case which is HAL directory contains various architectures.
(From what I saw, it looks like there is no such case so far.)
https://docs.zephyrproject.org/latest/guides/modules.html
In the GigaDevice case, splitting directories with CMakeLists.txt should work well.
CMake can easily exclude unused SoC code because the firmware is divided into directories for each SoC.
Zephyr seems to prefer to create modules per vendor.
STM32 HAL is splitting from ST HAL, but it seems an unusual case.
I think a good way is for every GigaDevice SoC's firmware put into a single external module.
@carlescufi
Is there are a convention for the case that is HAL module contains code for various architectures? (or is it acceptable?)

@soburi

Is there are a convention for the case that is HAL module contains code for various architectures? (or is it acceptable?)

No, I don't see why that is a problem at all. I think a hal_gigadevice would probably make sense, we already have HALs that cover more than one arch. I have mentioned that here as well.

@carlescufi
Thanks for your opinion and advice.
I understand.
I thinks the proposal #38657 to make single hal_gigadevice from @nandojve  is looks good.

After a lengthy discussion, we have come to the following conclusions:

We will not integrate the NMSIS codebase with Zephyr as a module
Instead, support for Nuclei cores will be added natively in the main tree, in soc/riscv/

This request for an external HAL is therefore no longer needed.


Activate ComposableNaming twitter/compose-rules

Issue

close #517

Overview (Required)

Activate ComposableNaming twitter/compose-rules.

./gradlew composeLint runs successfully.

Links

https://twitter.github.io/compose-rules/rules/#naming-composable-functions-properly

Thanks!


August RC1 testing: strange behavior attempting to deploy before auth

Trying to run a deploy before signing into GCP causes this (not seen before by me) modal to show up:

Any subsequent action leads to an IDE crash:

thanks to detective work by @nkibler:

Start fresh with everything (no user, no deployment config, etc.)
Create a deployment config and make it valid. (Type some nonsense into the project field but don't login)
Save the config and login via other means (like the widget in the top right)
Once logged in, press the run button

@etanshaul I don't think this is a problem anymore since you can select an invalid GCP project with the new project selector. I tried to reproduce the bug but couldn't, which is a good thing :)


Remove multibuilder in favor of a uniform builder interface

Description of Changes
To simplify the process of building a pipeline config, this PR removes the MultiBuilder concept and unifies the interface under Builder. This means that each config must implement a Build method that returns a slice of operators rather than a single operator so that behavior can be uniform between plugins and operators.
Please check that the PR fulfills these requirements

[x] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)
[x] Add a changelog entry (for non-trivial bug fixes / features)
[x] CI passes

Log Files
Logs / Second
CPU Avg (%)
CPU Avg Δ (%)
Memory Avg (MB)
Memory Avg Δ (MB)

1
1000
1.91387
-0.086189866
131.91164
+3.7549896

1
5000
6.2242756
+0.10344601
132.5858
-4.3562775

1
10000
12.2071
-0.5518074
141.36961
-2.2570038

1
50000
60.191093
+0.4518547
177.42497
+5.975357

1
100000
120.238495
+4.079773
242.59361
+13.524506

10
100
2.5000384
+0.103405714
130.3952
-1.9185028

10
500
6.8277183
-0.034448624
137.08675
-1.8193665

10
1000
13.758977
-0.53457355
147.03368
+0.14143372

10
5000
64.10165
-1.1927948
181.67699
+0.34320068

10
10000
127.31322
+0.33232117
229.94342
+7.204605

Log Files
Logs / Second
CPU Avg (%)
CPU Avg Δ (%)
Memory Avg (MB)
Memory Avg Δ (MB)

1
1000
1.7759763
-0.22408354
126.61099
-1.5456543

1
5000
6.051826
-0.06900358
136.95111
+0.009033203

1
10000
12.552013
-0.20689392
145.35829
+1.7316742

1
50000
60.328773
+0.58953476
175.34322
+3.8936005

1
100000
117.01955
+0.8608246
230.55415
+1.4850464

10
100
2.4310782
+0.034445524
131.22266
-1.0910492

10
500
6.8790984
+0.016931534
135.70421
-3.2019043

10
1000
13.845151
-0.44839954
147.87648
+0.9842377

10
5000
65.689766
+0.3953247
180.71188
-0.62190247

10
10000
126.487495
-0.49340057
231.74084
+9.002029


Drop incomplete implementation for virtlogd wrapper

... because we no longer used the wrapper service. The current implementation does not work completely mainly because it still depends on puppet.

@kajinamit can you fix the patch according to new layout? Thanks!


puppet: Update nagios check_postgres_replication_lag to be on DB hosts

7d4a370a57 attempted to move the replication check to on the
PostgreSQL hosts.  While it updated the check to assume it was
running and talking to a local PostgreSQL instance, the configuration
and installation for the check were not updated.  As such, the check
ran on the nagios host for each DB host, and produced no output.
Start distributing the check to all apopdb hosts, and configure nagios
to use the SSH tunnel to get there.

Merged, thanks @alexmv!


Add "unsubscribe" functionality to remove subscriptions from Nakadi

With the current version of "fahrschein" library it is possibly to create a subscription. Would be nice to have an "unsubscribe" method to programmatically manage subscriptions. It also enhances a bit a symmetry of a programming interface of this library.
Example use case: having this feature one can remove active subscriptions on shutdown of an application.

Fixed by #165


Add "mruby developers" into some gems; Resolve #4709

It is writing side by side with the original authors.

Although it is redundant, it is the simplest description.
For your reference, list the added commits.

gem name
year
release
commit

mruby-io
2017
1.4.0
d75266dd1bade53255044460a9cd74596addaa84

mruby-pack
2017
1.4.0
a5412d48fd1bb55288cb168a92efd0f2045781c1

mruby-socket
2017
1.4.0
73ef548c6386a1101b5d95654bcb142ab83149c7

mruby-sleep
2018
2.0.0
44fdd53f2e5bac6fe1cbc2ceb653aa5f2de965e6

@tsahara @matsumotory Are you OK with this change?

OK.  And thank you for the effort maintaining the gems in the core.

OK!!!

Thank you! @tsahara and @matsumotory

@tsahara @matsumotory @matz Thanks!


HIP DMA: no path found

I'm seeing the following error in the Regent HIP test suite. Relevant portion seems to be FATAL: no path found from 1e00000000000002 to 1e00000000000002 (redop=101). I am a little confused, this seems to be the same memory. Do we not have GPU reductions implemented?
[FAIL] (run_pass) (return code 1) tests/cuda/run_pass/region_reduce_array1.rg
region_reduce_array1.rg -ll:gpu 1 -fgpu hip -level runtime=5,threads=5
terra: /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/runtime/realm/transfer/transfer.cc:3755: void Realm::TransferDesc::perform_analysis(): Assertion `0' failed.
ld.lld -shared -plugin-opt=mcpu=gfx90a -plugin-opt=-amdgpu-internalize-symbols -plugin-opt=O3 -plugin-opt=-amdgpu-early-inline-all=true -plugin-opt=-amdgpu-function-calls=false -o /tmp/lua_JDCI6b /tmp/lua_0sNLda  /opt/rocm-4.5.0/amdgcn/bitcode/oclc_finite_only_off.bc /opt/rocm-4.5.0/amdgcn/bitcode/ocml.bc /opt/rocm-4.5.0/amdgcn/bitcode/oclc_daz_opt_off.bc /opt/rocm-4.5.0/amdgcn/bitcode/oclc_wavefrontsize64_on.bc /opt/rocm-4.5.0/amdgcn/bitcode/oclc_isa_version_90a.bc /opt/rocm-4.5.0/amdgcn/bitcode/oclc_unsafe_math_off.bc /opt/rocm-4.5.0/amdgcn/bitcode/oclc_correctly_rounded_sqrt_on.bc
clang-offload-bundler --inputs=/dev/null,/tmp/lua_JDCI6b --type=o --outputs=/tmp/lua_5xVLda --targets=host-x86_64-unknown-linux-gnu,hipv4-amdgcn-amd-amdhsa--gfx90a
set device 0
hipmalloc 0x7f3160000000, size 268435456
ib hipmalloc 0x7f3150000000, size 134217728
[0 - 7f3401cf6780]    0.062258 {4}{hip}: HIP hijack code not active - device synchronizations required after every GPU task!
[0 - 7f3401cf6780]    0.073544 {4}{hip}: HIP hijack is active - device synchronizations not required after every GPU task!
[0 - 7f3403b5c780]    0.073925 {6}{new_dma}: FATAL: no path found from 1e00000000000002 to 1e00000000000002 (redop=101)
Signal 6 received by node 0, process 81954 (thread 7f3403b5c780) - obtaining backtrace
Signal 6 received by process 81954 (thread 7f3403b5c780) at: stack trace: 23 frames
  [0] = /lib64/libpthread.so.0(+0x168c0) [0x7f3426ad98c0]
  [1] = /lib64/libc.so.6(gsignal+0x10d) [0x7f3425a39cdb]
  [2] = /lib64/libc.so.6(abort+0x177) [0x7f3425a3b375]
  [3] = /lib64/libc.so.6(+0x42cda) [0x7f3425a31cda]
  [4] = /lib64/libc.so.6(+0x42d62) [0x7f3425a31d62]
  [5] = /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/bindings/regent/libregent.so(+0xa2f9fc) [0x7f342456a9fc]
  [6] = /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/bindings/regent/libregent.so(+0xa30efa) [0x7f342456befa]
  [7] = /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/bindings/regent/libregent.so(+0xa9fe94) [0x7f34245dae94]
  [8] = /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/bindings/regent/libregent.so(Realm::IndexSpace<2, long long>::copy(std::vector<Realm::CopySrcDstField, std::allocator<Realm::CopySrcDstField> > const&, std::vector<Realm::CopySrcDstField, std::allocator<Realm::CopySrcDstField> > const&, std::vector<Realm::CopyIndirection<2, long long>::Base const*, std::allocator<Realm::CopyIndirection<2, long long>::Base const*> > const&, Realm::ProfilingRequestSet const&, Realm::Event) const+0x73) [0x7f34245dc953]
  [9] = /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/bindings/regent/libregent.so(Realm::IndexSpace<2, long long>::copy(std::vector<Realm::CopySrcDstField, std::allocator<Realm::CopySrcDstField> > const&, std::vector<Realm::CopySrcDstField, std::allocator<Realm::CopySrcDstField> > const&, Realm::ProfilingRequestSet const&, Realm::Event, int, bool) const+0x211) [0x7f3424352651]
  [10] = /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/bindings/regent/libregent.so(Legion::Internal::ApEvent Legion::Internal::IndexSpaceExpression::issue_copy_internal<2, long long>(Legion::Internal::RegionTreeForest*, Realm::IndexSpace<2, long long> const&, Legion::Internal::PhysicalTraceInfo const&, std::vector<Realm::CopySrcDstField, std::allocator<Realm::CopySrcDstField> > const&, std::vector<Realm::CopySrcDstField, std::allocator<Realm::CopySrcDstField> > const&, Legion::Internal::ApEvent, Legion::Internal::PredEvent, int, bool)+0x164) [0x7f3424352914]
  [11] = /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/bindings/regent/libregent.so(Legion::Internal::IndexSpaceNodeT<2, long long>::issue_copy(Legion::Internal::PhysicalTraceInfo const&, std::vector<Realm::CopySrcDstField, std::allocator<Realm::CopySrcDstField> > const&, std::vector<Realm::CopySrcDstField, std::allocator<Realm::CopySrcDstField> > const&, Legion::Internal::ApEvent, Legion::Internal::PredEvent, int, bool)+0xb2) [0x7f34243529f2]
  [12] = /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/bindings/regent/libregent.so(Legion::Internal::IndividualManager::copy_from(Legion::Internal::PhysicalManager*, Legion::Internal::ApEvent, Legion::Internal::PredEvent, int, Legion::Internal::IndexSpaceExpression*, AVXBitMask<256u> const&, Legion::Internal::PhysicalTraceInfo const&, Legion::Internal::FieldMaskSet<Legion::Internal::InstanceView, (Legion::Internal::AllocationType)106> const*, Legion::Internal::FieldMaskSet<Legion::Internal::InstanceView, (Legion::Internal::AllocationType)106> const*, std::set<Legion::Internal::RtEvent, std::less<Legion::Internal::RtEvent>, std::allocator<Legion::Internal::RtEvent> >&, Legion::Internal::CopyAcrossHelper*)+0xb1) [0x7f342410f281]
  [13] = /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/bindings/regent/libregent.so(Legion::Internal::CopyFillAggregator::issue_copies(Legion::Internal::InstanceView*, std::map<Legion::Internal::InstanceView*, std::vector<Legion::Internal::CopyFillAggregator::CopyUpdate*, std::allocator<Legion::Internal::CopyFillAggregator::CopyUpdate*> >, std::less<Legion::Internal::InstanceView*>, std::allocator<std::pair<Legion::Internal::InstanceView* const, std::vector<Legion::Internal::CopyFillAggregator::CopyUpdate*, std::allocator<Legion::Internal::CopyFillAggregator::CopyUpdate*> > > > > const&, Legion::Internal::ApEvent, AVXBitMask<256u> const&, Legion::Internal::PhysicalTraceInfo const&, bool)+0x250) [0x7f342415ae90]
  [14] = /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/bindings/regent/libregent.so(Legion::Internal::CopyFillAggregator::perform_updates(std::map<Legion::Internal::InstanceView*, Legion::Internal::FieldMaskSet<Legion::Internal::CopyFillAggregator::Update, (Legion::Internal::AllocationType)106>, std::less<Legion::Internal::InstanceView*>, Legion::Internal::LegionAllocator<std::pair<Legion::Internal::InstanceView* const, Legion::Internal::FieldMaskSet<Legion::Internal::CopyFillAggregator::Update, (Legion::Internal::AllocationType)106> >, (Legion::Internal::AllocationType)106> > const&, Legion::Internal::PhysicalTraceInfo const&, Legion::Internal::ApEvent, int, bool, bool, bool)+0x125c) [0x7f3424160bfc]
  [15] = /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/bindings/regent/libregent.so(Legion::Internal::CopyFillAggregator::issue_updates(Legion::Internal::PhysicalTraceInfo const&, Legion::Internal::ApEvent, bool, bool, bool, unsigned int, bool)+0x110) [0x7f3424161bc0]
  [16] = /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/bindings/regent/libregent.so(Legion::Internal::CopyFillAggregator::handle_aggregation(void const*)+0x2a) [0x7f342416211a]
  [17] = /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/bindings/regent/libregent.so(Legion::Internal::Runtime::legion_runtime_task(void const*, unsigned long, void const*, unsigned long, Realm::Processor)+0x8eb) [0x7f342427962b]
  [18] = /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/bindings/regent/libregent.so(+0xb06d59) [0x7f3424641d59]
  [19] = /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/bindings/regent/libregent.so(+0xb06df6) [0x7f3424641df6]
  [20] = /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/bindings/regent/libregent.so(+0xb05db8) [0x7f3424640db8]
  [21] = /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/bindings/regent/libregent.so(+0xae7297) [0x7f3424622297]
  [22] = /lib64/libc.so.6(+0x61620) [0x7f3425a50620]

This might actually be the result of bullet (2) in #1035.

The reduction for hip has been merged into master. I have just tested the circuit and simple_reduce with HIP_TARGET=CUDA, which have reductions, and they both work. Looks like 1e00000000000002 is not a GPU process?

The way to check if a path is existed is https://gitlab.com/StanfordLegion/legion/-/blob/master/runtime/realm/hip/hip_internal.cc#L1515-1519
If the reduction kernels are available, then it calls the normal realm code to check the path, which is outside my knowledge.

In theory at least, both CUDA and HIP modules in Realm should be supporting direct reduction application on the GPU.

What do I need to do to debug this?

I'd set a breakpoint here:
https://gitlab.com/StanfordLegion/legion/-/blob/master/runtime/realm/runtime_impl.cc#L514
and verify that the 4 hip_..._fn pointers are non-null for the reduction op(s) you care about.

If they're NULL then you can break here to check that the GPU reductions are being registered:
https://gitlab.com/StanfordLegion/legion/-/blob/master/runtime/legion/legion_redop.cu#L110

At @streichler 's breakpoint, all the HIP functions are NULL:
Thread 1 "terra" hit Breakpoint 1, Realm::Runtime::register_reduction (this=0x7fffffff5b08, redop_id=101, redop=0xaae5520) at /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/runtime/realm/runtime_impl.cc:514
514	      assert(impl != 0);
(gdb) p redop
$1 = (const Realm::ReductionOpUntyped *) 0xaae5520
(gdb) p *redop
$2 = {
  sizeof_this = 136,
  sizeof_lhs = 20,
  sizeof_rhs = 20,
  sizeof_userdata = 4,
  identity = 0xaae5594,
  userdata = 0xaae5590,
  cpu_apply_excl_fn = 0x7fffe9a2d067
     <Realm::ReductionKernels::cpu_apply_wrapper<ArrayReduction<Legion::SumReduction<int> >, true>(void*, unsigned long, void const*, unsigned long, unsigned long, void const*)>,
  cpu_apply_nonexcl_fn = 0x7fffe9a2d0d2 <Realm::ReductionKernels::cpu_apply_wrapper<ArrayReduction<Legion::SumReduction<int> >, false>(void*, unsigned long, void const*, unsigned long, unsigned long, void const*)>,
  cpu_fold_excl_fn = 0x7fffe9a2d13d <Realm::ReductionKernels::cpu_fold_wrapper<ArrayReduction<Legion::SumReduction<int> >, true>(void*, unsigned long, void const*, unsigned long, unsigned long, void const*)>,
  cpu_fold_nonexcl_fn = 0x7fffe9a2d1a8 <Realm::ReductionKernels::cpu_fold_wrapper<ArrayReduction<Legion::SumReduction<int> >, false>(void*, unsigned long, void const*, unsigned long, unsigned long, void const*)>,
  hip_apply_excl_fn = 0x0,
  hip_apply_nonexcl_fn = 0x0,
  hip_fold_excl_fn = 0x0,
  hip_fold_nonexcl_fn = 0x0
}

At @lightsighter 's breakpoint, they don't look NULL:
Thread 1 "terra" hit Breakpoint 2, Legion::Internal::register_builtin_reduction_operators_hip () at /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/runtime/legion/legion_redop.cu:110
110	      LEGION_REDOP_LIST(REGISTER_BUILTIN_REDOP_HIP)
(gdb) s
Legion::Internal::runtime_register_reduction_op (redop_id=1048577, redop=0xb08d2c0, init_fnptr=0x0, fold_fnptr=0x0, permit_duplicates=false, has_lock=false) at /autofs/nccs-svm1_home1/eslaught/crusher/amd-gpu-test/legion/runtime/legion/runtime.cc:23511
23511	      Runtime::register_reduction_op(redop_id, redop, init_fnptr, fold_fnptr,
(gdb) p redop
$3 = (Legion::ReductionOp *) 0xb08d2c0
(gdb) p *redop
$4 = {
  sizeof_this = 120,
  sizeof_lhs = 1,
  sizeof_rhs = 1,
  sizeof_userdata = 1,
  identity = 0xb08d330,
  userdata = 0xb08d331,
  cpu_apply_excl_fn = 0x7fffea07e0e0 <Realm::ReductionKernels::cpu_apply_wrapper<Legion::Internal::AddHipReductions<Legion::SumReduction<signed char> >, true>(void*, unsigned long, void const*, unsigned long, unsigned long, void const*)>,
  cpu_apply_nonexcl_fn = 0x7fffea07e160 <Realm::ReductionKernels::cpu_apply_wrapper<Legion::Internal::AddHipReductions<Legion::SumReduction<signed char> >, false>(void*, unsigned long, void const*, unsigned long, unsigned long, void const*)>,
  cpu_fold_excl_fn = 0x7fffea07e230 <Realm::ReductionKernels::cpu_fold_wrapper<Legion::Internal::AddHipReductions<Legion::SumReduction<signed char> >, true>(void*, unsigned long, void const*, unsigned long, unsigned long, void const*)>,
  cpu_fold_nonexcl_fn = 0x7fffea07e2b0 <Realm::ReductionKernels::cpu_fold_wrapper<Legion::Internal::AddHipReductions<Legion::SumReduction<signed char> >, false>(void*, unsigned long, void const*, unsigned long, unsigned long, void const*)>,
  hip_apply_excl_fn = 0x7fffeba61980 <void Realm::Hip::ReductionKernels::apply_hip_kernel<Legion::Internal::AddHipReductions<Legion::SumReduction<signed char> >, true>(unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, Legion::Internal::AddHipReductions<Legion::SumReduction<signed char> >)>,
  hip_apply_nonexcl_fn = 0x7fffeba61988 <void Realm::Hip::ReductionKernels::apply_hip_kernel<Legion::Internal::AddHipReductions<Legion::SumReduction<signed char> >, false>(unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, Legion::Internal::AddHipReductions<Legion::SumReduction<signed char> >)>,
  hip_fold_excl_fn = 0x7fffeba61990 <void Realm::Hip::ReductionKernels::fold_hip_kernel<Legion::Internal::AddHipReductions<Legion::SumReduction<signed char> >, true>(unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, Legion::Internal::AddHipReductions<Legion::SumReduction<signed char> >)>,
  hip_fold_nonexcl_fn = 0x7fffeba61998 <void Realm::Hip::ReductionKernels::fold_hip_kernel<Legion::Internal::AddHipReductions<Legion::SumReduction<signed char> >, false>(unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, Legion::Internal::AddHipReductions<Legion::SumReduction<signed char> >)>
}

What gives?

Oh, the missing reductions are Regent's array reductions. I can fix this on my end.


Padchat was logout-ed and stucked after the PadchatRpc initWebSocket()

We lost the control to the padchat puppet after PadchatRpc initWebSocket()
Message#Url[🗣Contact<王彦博>@👥Room<私企企业家联盟会>]
Message discarded because it does not match ding/ping/bing/code
15:29:12 SILL PadchatRpc initHeartbeat() debounceQueue.subscribe(ws.on(message))
15:29:12 SILL PadchatRpc rpcCall(WXHeartBeat, [])
15:29:12 SILL PadchatRpc pre login rpcCall(WXHeartBeat, [])
15:29:17 SILL PadchatRpc initWebSocket() ws.on(message): {"apiName":"WXHeartBeat","data":"%7B%22status%22%3A0%2C%22message%22%3A%22ok%22%7D","msgId":"-900719
15:29:17 SILL PadchatRpc initHeartbeat() throttleQueue.subscribe(ws.on(message))
15:29:17 SILL PuppetPadchat startWatchdog() padchatManager.on(heartbeat)
15:29:17 SILL Wechaty memoryCheck() free: 4252 MB, require: 4 MB
15:29:17 SILL PadchatRpc WXHeartBeat result: {"status":0,"message":"ok"}
15:29:37 SILL PadchatRpc initHeartbeat() debounceQueue.subscribe(ws.on(message))
15:29:37 SILL PadchatRpc rpcCall(WXHeartBeat, [])
15:29:37 SILL PadchatRpc pre login rpcCall(WXHeartBeat, [])
15:29:55 SILL PadchatRpc initWebSocket() ws.on(message): {"apiName":"","data":"%5B%7B%22continue%22%3A0%2C%22msg_type%22%3A32768%2C%22status%22%3A1%2C%22uin%
15:29:55 SILL PadchatRpc onSocketTencent() discard empty message msg_id payoad: {"continue":0,"msg_type":32768,"status":1,"uin":1211516682}
15:29:55 SILL PadchatRpc initHeartbeat() throttleQueue.subscribe(ws.on(message))
15:29:55 SILL PuppetPadchat startWatchdog() padchatManager.on(heartbeat)
15:29:55 SILL Wechaty memoryCheck() free: 4250 MB, require: 4 MB
15:29:55 SILL PadchatRpc initWebSocket() ws.on(pong)
15:29:55 SILL PadchatRpc initWebSocket() ws.on(pong)
15:30:15 SILL PadchatRpc initHeartbeat() debounceQueue.subscribe(pong: #2596 from debounceQueue)
15:30:15 SILL PadchatRpc rpcCall(WXHeartBeat, [])
15:30:15 SILL PadchatRpc pre login rpcCall(WXHeartBeat, [])
15:33:55 SILL Puppet constructor() watchdog.on(reset) reason: {"data":"ws.on(message)","timeout":240000}
15:33:55 SILL Puppet constructor() this.on(reset) reason: {"data":"ws.on(message)","timeout":240000}
15:33:55 SILL Puppet constructor() resetThrottleQueue.subscribe() reason: {"data":"ws.on(message)","timeout":240000}
15:33:55 VERB Puppet reset({"data":"ws.on(message)","timeout":240000})
15:33:55 SILL StateSwitch <PuppetPadchat> off() is false
15:33:55 VERB PuppetPadchat stop()
15:33:55 SILL StateSwitch <PuppetPadchat> off() is false
15:33:55 SILL StateSwitch <PuppetPadchat> off() is false
15:33:55 VERB StateSwitch <PuppetPadchat> off(pending) <- (false)
15:33:55 VERB PuppetPadchat logout()
15:33:55 SILL Contact ready() @ Puppet#0<PuppetPadchat>(ding-dong-bot)/PuppetPadchat#0
15:33:55 SILL Contact ready() isReady() true
15:33:55 VERB PuppetPadchatManager logout()
15:33:55 VERB PuppetPadchatManager releaseCache()
15:33:55 SILL PuppetPadchatManager releaseCache() closing caches ...
15:33:55 VERB ContactSelf name()
李卓桓 logouted
15:33:55 SILL PuppetPadchatManager releaseCache() cache closed.
15:33:55 VERB PuppetPadchatManager startCheckScan()
15:33:55 SILL PuppetPadchatManager startCheckScan() checkScanInternalLoop()
15:33:55 SILL PadchatRpc rpcCall(WXCheckQRCode, [])
15:33:55 SILL PadchatRpc pre login rpcCall(WXCheckQRCode, [])
15:33:55 SILL PuppetPadchatManager startCheckScan() checkScanInternalLoop() set
15:33:55 VERB PuppetPadchatManager stop()
15:33:55 WARN PuppetPadchatManager stop() subscript not exist
15:33:55 VERB PuppetPadchatManager stopCheckScan()
15:33:55 VERB PadchatRpc stop()
15:33:55 VERB PadchatRpc stopQueues()
15:33:55 VERB PuppetPadchatManager releaseCache()
15:33:55 VERB PuppetPadchatManager releaseCache() cache not exist.
15:33:55 SILL StateSwitch <PuppetPadchat> off() is pending
15:33:55 VERB StateSwitch <PuppetPadchat> off(true) <- (pending)
15:33:55 VERB PuppetPadchat start() with ding-dong-bot
15:33:55 SILL StateSwitch <PuppetPadchat> on() is false
15:33:55 SILL StateSwitch <PuppetPadchat> on() is false
15:33:55 VERB StateSwitch <PuppetPadchat> on(pending) <- (false)
15:33:55 VERB PadchatRpc constructor(ws://padchat.botorange.com/wx, puppet_padchat_xxxxxxxxxxxxxxx)
15:33:55 VERB PuppetPadchatManager constructor()
15:33:55 VERB PuppetPadchat startManager()
15:33:55 SILL StateSwitch <PuppetPadchat> off() is false
15:33:55 VERB PuppetPadchatManager start()
15:33:55 VERB PadchatRpc start()
15:33:55 VERB PadchatRpc initWebSocket()
16:11:19 SILL Wechaty start() setInterval() this timer is to keep Wechaty running...
17:11:19 SILL Wechaty start() setInterval() this timer is to keep Wechaty running...
18:11:20 SILL Wechaty start() setInterval() this timer is to keep Wechaty running...
19:11:20 SILL Wechaty start() setInterval() this timer is to keep Wechaty running...
20:11:20 SILL Wechaty start() setInterval() this timer is to keep Wechaty running...
21:11:20 SILL Wechaty start() setInterval() this timer is to keep Wechaty running...
22:11:20 SILL Wechaty start() setInterval() this timer is to keep Wechaty running...
23:11:20 SILL Wechaty start() setInterval() this timer is to keep Wechaty running...
00:11:20 SILL Wechaty start() setInterval() this timer is to keep Wechaty running...

Please move to wechaty-puppet-padpro
padchat always stuck after running for a period for not known reason, padpro now has a more stable version.

Does that mean that we should deprecated the padchat and only keep promoting the padpro because we are not going to maintain the padchat version?

Yes, you are right, we should do that.


Update manage-reserved-vm-instance.md

Changes for Billing Admin managing and viewing RIs (feature change)

@mittalpri : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Hi @mittalpri - This content has a private repository that PMs typically work in. We can leave this pull request here for author review, but would you make future content updates in the private repo? Thanks!

This PR is now in conflict.  Priyanshi already copied the change into the private repo via PR MicrosoftDocs/azure-docs-pr#156720
#please-close


feat: Add filelog.mtimeSortType feature flag

Proposed Change

Adds the filelog.mtimeSortType feature flag, which enables using the mtime sort type in the filelog's ordering_criteria section.

Checklist

[ ] Changes are tested
[ ] CI has passed

This won't work with v0.88.0, we need to wait until v0.89.0 (I missed that the release cycle was skipped for kubecon, I think)


Ian Campbell: Watch atariarchives.org/iad

Ian Campbell requests the watch of the watch_keyword atariarchives\.org\/iad. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

atariarchives\.org\/iad has been seen in 0 true positives, 0 false positives, and 0 NAAs.

Watch due to this unreported post: https://stackoverflow.com/a/68355991/ by now destroyed user with similar name.

Approved by Jeff Schaller in Charcoal HQ


Provide Package.swift?

Should CocoaLumberJack provide a Package.swift so it can be imported by those using the swift package manager, or is there a better alternative for them to use it?
I got "swift package build" kind of working with:
import PackageDescription

let package = Package(
    name: "CocoaLumberjack",
    exclude: ["Classes/CocoaLumberjack.swift", "Documentation", "Framework", "Benchmarking", "Demos", "Classes/Extensions"]
)

but excluding the swift header from a swift package seems odd but required due to https://github.com/apple/swift-package-manager/blob/master/Sources/PackageLoading/PackageBuilder.swift#L563

This is tracked in #869.

We need somebody with some experience with SPM to do this. I played a bit with it and got to (need to exclude DDAssert.swift
import PackageDescription

let package = Package(
    name: "CocoaLumberjack",
    exclude: ["Classes/CocoaLumberjack.swift", "Classes/DDAssert.swift", "Documentation", "Framework", "Benchmarking", "Demos", "Classes/Extensions", "Tests"]
)

but when running swift build I get
warning: PackageDescription API v3 is deprecated and will be removed in the future; used by package(s): CocoaLumberjack
warning: no include directory found for target 'Classes'; libraries cannot be imported without public headers

so I guess SPM needs the folder structure in a certain way.
More details: http://ankit.im/swift/2016/05/21/creating-objc-cpp-packages-with-swift-package-manager/

I see. Maybe symlinks could work.
Also, I think we still need to build 2 modules: CocoaLumberjack (contains only the Obj-C part) and CocoaLumberjackSwift that links against the 1st one.

Definitively needs to modules, yea. Also I don't think it'll currently work on Linux, since AFAIK it's not possible to compile ObjC code on Linux.

I think Linux support is out of the question, at least for now. ObjC is not supported and even Swift is limited, Foundation is still being ported to Linux, so I don't think our code can run there at this point.
SPM support is for people using that on MacOS targeting the 4 Apple platforms, more like a parity to CocoaPods and Carthage.

Totally agree as long as ObjC is used.
With Swift however, I think Linux support should already be possible. At least for the core features of CocoaLumberjack. Of course some loggers would be unavailable (like ASLLogger), but that‘s nothing unexpected.
But yea, it‘s probably an easier short term goal to add SwiftPM support for what exists today (limited to macOS).
Sent with GitHawk


[ci] fix windows docker

Use curl instead of wget to download docker binary
Test:

CI

not sure if it is going to be better..


scheduler: create threads per-component requests

This PR is not yet fully completed. Pay attention and provide comments:

How many threads each component needs. Pay attention on VPP, encoders and FEI - these components create 2 tasks (Submit & Query) - this part was moved away from this pr to #911.
Scheduler internal API altered - are we ok with that?

First 5 cleanup commits extracted to separate pr #903, please, review them there.

@mgonchar, @dmitry-gurulev : can you, please, take a look once more time?
@onabiull : can we, please, schedule some validation for this PR? We need functional one at the first place.


An error occurred when clicking on a wallet

[###] |-->  Null check operator used on a null value
[###] |-->  #0      _WalletConnectModalState._onWalletDataSelected
walletconnect_modal.dart:344
#1      GridList._buildGridList.<anonymous closure>.<anonymous closure>.<anonymous closure>
grid_list.dart:121
#2      _InkResponseState.handleTap
ink_well.dart:1154
#3      GestureRecognizer.invokeCallback
recognizer.dart:275
#4      TapGestureRecognizer.handleTapUp
tap.dart:654
#5      BaseTapGestureRecognizer._checkUp
tap.dart:311
#6      BaseTapGestureRecognizer.acceptGesture
tap.dart:281
#7      GestureArenaManager.sweep
arena.dart:167
#8      GestureBinding.handleEvent
binding.dart:469
#9      GestureBinding.dispatchEvent
binding.dart:445
#10     RendererBinding.dispatchEvent
binding.dart:331
#11     GestureBinding._handlePointerEventImmediately
binding.dart:400
#12     GestureBinding.handlePointerEvent
binding.dart:363
#13     GestureBinding._flushPointerEventQueue
binding.dart:320
#14     GestureBinding._handlePointerDataPacket
binding.dart:293
#15     _rootRunUnary (dart:async/zone.dart:1415:13)
#16     _CustomZone.runUnary (dart:async/zone.dart:1308:19)
#17     _CustomZone.runUnaryGuarded (dart:async/zone.dart:1217:7)
#18     _invoke1 (dart:ui/hooks.dart:160:10)
#19     PlatformDispatcher._dispatchPointerDataPacket (dart:ui/platform_dispatcher.dart:382:7)
#20     _dispatchPointerDataPacket (dart:ui/hooks.dart:91:31)

Multiple updates have been made to the library in the past two weeks.
I am not sure if this issue have been resolved, but I have personally not run into it.
I will close this issue, if it happens to you again, reopen it.

25 of July, encountered this issue. Using walletconnect_modal_flutter: ^1.1.2
My assumption is that if a wallet was connected before, the issue occurs. After ending the session in MetaMask, started working pretty fine.


pump line style

changing pump line style doesn't reflect in the legend!

maybe there are some other issues like this?

there's a black line under the pump that shows up even when we change the line style

Aha, the black line under the pump is probably because the link is still being drawn when draw_base_elements is called. I never noticed before because we didn't have a line style option until very recently.
On the topic of the line style not being reflected on the legend is because patches are being used because the lines were very thin without them, however it seems necessary now to drop the patches.


a few typos and clarifications in the changes doc

Not sure if I fully understand these, but I sensed inconsistency

enter nodes are not defined anywhere, but placeholders are mentioned
everywhere
catmull-rom changes described restoring the old behavior, but showed
the new behavior
sentence fragment when describing invert/rescale
random fixes

(Just little stuff, but this is probably a document people will be reading again and again.)

Thanks! I will take a look at this soon.


Update sbt-wartremover, wartremover to 3.2.4

About this PR
📦 Updates

org.wartremover:sbt-wartremover
org.wartremover:wartremover

from 3.2.2 to 3.2.4
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.wartremover" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.wartremover" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #395.


Using -parameters in the terminal doesn't show them

When using the built in terminal, running a program with arguments using a dash makes the text become invisible.

Please provide more information:

OS
VS Code version
What command are you running?
What other commands have you tried?
Can I get a screenshot of the error?
Can you open devtools (Help > Toggle Developer Tools) and check the console for errors?

Just tested a bit and it turns out that it's an issue with the color theme I'm using. Apparently the color for the parameters is the same color as the terminal background because hovering over the invisible letters shows them.


Compilation of µWebSockets has failed and there is no pre-compiled binary available for your system

[Error] Error: Compilation of µWebSockets has failed and there is no pre-compiled binary available for your system. Please install a supported C++11 compiler and reinstall the module 'uws'.

I can't seem to get SocketCluster to work, I always get the above error message, even after I changed wsEngine to ws.
I tried it on Node 6 and 7, Ubuntu 16.04.
I couldn't find anymore information about this issue online, can you please direct me on how to figure out what is causing this issue?
Thanks

@iMoses Is this happening when you do npm install?
It works fine on my Ubuntu 15.10 machine with Node 6.4.0. It sounds like it doesn't like your compiler for some reason... @alexhultman do you know what the issue could be?
Worst case, you can try running SC inside Docker (if you have Docker installed)... See https://blog.baasil.io/framework-in-a-container-6105d3275d61#.nrqmc559j

No, npm install goes smoothly.
I get this message on a loop when trying to run a worker, it keeps crashing.
What information can I provide that will assist?
I need to get it working as part of an electron application, so docker is not really an option.

Alex said that it can happen if you have an unusual setup like maybe 32-bit machine instead of 64-bit or maybe you have an old compiler - Or something happened to it... I'm trying to find a workaround now.

It's weird that you can't just use ws.

@iMoses When I delete the uws module and set the wsEngine to ws (http://socketcluster.io/#!/docs/api-socketcluster), it still works for me - Maybe try deleting uws from node_modules directory.

64-bit, on two different PCs with Ubuntu 16.04
Both were bought in the last 18 months, both are strong PCs
It seems that the worker crashes just by trying to import uws
1479419902894 - Origin: Worker (PID 5931)
   [Error] Error: Compilation of µWebSockets has failed and there is no pre-compiled binary available for your system. Please install a supported C++11 compiler and reinstall the module 'uws'.
    at e (/home/imoses/repos/tools_client/app/node_modules/uws/uws.js:25:19)
    at Object.<anonymous> (/home/imoses/repos/tools_client/app/node_modules/uws/uws.js:29:3)
    at Module._compile (module.js:556:32)
    at Object.Module._extensions..js (module.js:565:10)
    at Module.load (module.js:473:32)
    at tryModuleLoad (module.js:432:12)
    at Function.Module._load (module.js:424:3)
    at Module.require (module.js:483:17)
    at require (internal/module.js:20:19)
    at EventEmitter.SCServer (/home/imoses/repos/tools_client/app/node_modules/socketcluster-server/scserver.js:83:18)
1479419902896 - Worker 0 exited - Exit code: 1
1479419903031 - Origin: Worker (PID 5936)
   [Error] Error: Compilation of µWebSockets has failed and there is no pre-compiled binary available for your system. Please install a supported C++11 compiler and reinstall the module 'uws'.
    at e (/home/imoses/repos/tools_client/app/node_modules/uws/uws.js:25:19)
    at Object.<anonymous> (/home/imoses/repos/tools_client/app/node_modules/uws/uws.js:29:3)
    at Module._compile (module.js:556:32)
    at Object.Module._extensions..js (module.js:565:10)
    at Module.load (module.js:473:32)
    at tryModuleLoad (module.js:432:12)
    at Function.Module._load (module.js:424:3)
    at Module.require (module.js:483:17)
    at require (internal/module.js:20:19)
    at EventEmitter.SCServer (/home/imoses/repos/tools_client/app/node_modules/socketcluster-server/scserver.js:83:18)
1479419903033 - Worker 0 exited - Exit code: 1

This goes on and on and on...

I tried deleting node_modules several times already.. no luck

Did you try doing npm cache clean before reinstalling?

@iMoses What is your uname -a?

Linux imoses-pc 4.4.0-45-generic #66-Ubuntu SMP Wed Oct 19 14:12:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
I haven't tried npm cache clean until now, it does seem to have changed something.
I think I have a bigger bug here that may not belong to you.
For some reason, SocketCluster still ignores my wsEngine: 'ws' but it does seem to work:
   [Busy] Launching SocketCluster
   >> Worker PID: 8426
   [Active] SocketCluster started
            Version: 5.0.24
            Environment: dev
            WebSocket engine: uws
            Port: 8000
            Master PID: 8407
            Worker count: 1
            Broker count: 1

But when I try to run it as part of an electron application I still get the same error messages.

Did you use npm link to link SC into your project?

No, it was installed as a regular dependency.

The part about wsEngine was my bad, I was indeed loading configuration from the wrong place.
Thanks a lot for you help

As a workaround I run cd node_modules/uws and node-gyp rebuild commands.
(This module is used by socket cluster server in my react-native project).
Consider that your python binary has version is > 2.5 and < 3.0.0, node-gyp uses python for it.

Command
Value

uname -a
Darwin here's my name 16.7.0 Darwin Kernel Version 16.7.0: Mon Nov 13 21:56:25 PST 2017; root:xnu-3789.72.11~1/RELEASE_X86_64 x86_64

node -v
v8.9.4

npm -v
5.6.0

python --version
Python 2.7.10

Had this same problem. And I got it solved by
Delete node_modules folder then npm install which download everything again didn't solve
Delete node_modules\uws folder then npm install which only re download uws solved

I was able to fix this on a mac by doing:
cd node_modules/uws
npm install

@cjmling's solution works!

Using node 10, npm 5.6 and python 2.7.14, I have tried from cjmling but there is a built error. "make" failed during built of uws. in node_modules/uws/build_log.txt
Does it mean the issue is related to the uws package?
make: *** [Release/obj.target/uws/src/addon.o] Error 1
make: Leaving directory `/root/seoserverdev2/node_modules/uws/build'
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/usr/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:258:23)
gyp ERR! stack     at ChildProcess.emit (events.js:182:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:225:12)
gyp ERR! System Linux 3.10.0-514.el7.x86_64
gyp ERR! command "/usr/bin/node" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /root/seoserverdev2/node_modules/uws
gyp ERR! node -v v10.0.0
gyp ERR! node-gyp -v v3.6.2
gyp ERR! not ok

The file is really long so it is attached
build_log.txt

had the same problem

I don't use the alpine ,fix it

still cannot fix

Here is what I did as a workaround to fix the issue, I added SOCKETCLUSTER_WS_ENGINE='ws' to the .env file in the main root path.
So, rather than using uws, i use ws. I also discovered that ws was maintained by many more people than uws.

tried all of the above no luck

@cryptoking117 i have updated my answer.

In my case installing latest nodejs and npm on Ubuntu with PPA, solved this problem.
Earlier version
node - v6.14.3
npm - 3.10.10

Latest version which solved the problem-
node - v10.6.0
npm - 6.1.0

Refer - How to Install Latest Node.js and NPM on Ubuntu with PPA

For me the program was node 10.
When downgrading to node 9 it worked.
nvm use 9
rm -rf node_modules/
npm install

For me the program was node 10.
When downgrading to node 9 it worked.
nvm use 9
rm -rf node_modules/
npm install

I downgraded to node 8 and it worked thanks 👍

@pbassut thank you

Thanks @vickylance , I downgraded to 9 and that worked for me too.

uws will never ever work with nodejs10.  That is because uws does not support openssl 1.1.1.
That is the reason uws works when downgrading to node 8 (openssl 1.0.2).
Since the author has pulled his source out of nodejs repository I doubt there will ever be any support.