multiple line output when execute script

script
const hyperxCloudFlight = require('hyperx-cloud-flight-wireless')()

hyperxCloudFlight.on('power', (power) => console.log(`power: ${power}`))
hyperxCloudFlight.on('muted', (status) => console.log(`muted: ${status}`))
hyperxCloudFlight.on('volume', (direction) => console.log(`volume: ${direction}`))
hyperxCloudFlight.on('charging', (charging) => console.log(`charging: ${charging}`))
hyperxCloudFlight.on('battery', (percentage) =>  console.log(`current battery: ${percentage}%`))
hyperxCloudFlight.on('unknown', (data) => console.log('unknown', data))
hyperxCloudFlight.on('error', (error) => console.error('error', error))

output:
└───╼  NODE_PATH=$(npm root -g) node cloud_flight.js
current battery: 100%
current battery: 100%
current battery: 100%
current battery: 100%
current battery: 100%
current battery: 100%
current battery: 100%
current battery: 100%
current battery: 100%
current battery: 100%
current battery: 100%
current battery: 100%
current battery: 100%
current battery: 100%
current battery: 100%
current battery: 100%
current battery: 100%
current battery: 100%
current battery: 100%

linux node 16.3.0
greetings
PS: the udev rule is wrong for me (archlinux). fixed with
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="0951", ATTRS{idProduct}=="16c4", MODE="0666", TAG+="uaccess"

Could you add the debug options when you call the module?
const hyperxCloudFlight = require('hyperx-cloud-flight-wireless')({ debug: true })

and check the logs again?

┌─┤[$]|[sl1pkn07]|[sL1pKn07]|[/run/media/sl1pkn07/COSAS/aplicaciones]|
└───╼  NODE_PATH=$(npm root -g) node cloud_flight.js
2021-06-15T14:34:26.072Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T14:34:26.080Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T14:34:26.081Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T14:34:26.082Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T14:34:26.083Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T14:34:26.084Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T14:34:26.085Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T14:34:26.086Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T14:34:26.087Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T14:34:26.088Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T14:34:26.088Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T14:34:26.090Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T14:34:26.091Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T14:34:26.091Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T14:34:26.092Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T14:34:26.093Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T14:34:26.094Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T14:34:26.095Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T14:34:26.096Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T14:34:26.108Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T14:34:26.109Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T14:34:26.109Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T14:34:26.109Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T14:34:26.109Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T14:34:26.110Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T14:34:26.110Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T14:34:26.110Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T14:34:26.110Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T14:34:26.111Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T14:34:26.111Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T14:34:26.111Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T14:34:26.111Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T14:34:26.111Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T14:34:26.112Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T14:34:26.112Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T14:34:26.112Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T14:34:26.112Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T14:34:26.112Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T14:34:26.131Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.132Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.133Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.133Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.134Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.135Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.135Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.136Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.137Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.138Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.138Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.139Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.140Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.140Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.142Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.142Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.143Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.143Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.144Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.167Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.168Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.169Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.169Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.170Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.171Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.171Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.172Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.173Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.173Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.174Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.174Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.175Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.176Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.176Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.177Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.177Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.178Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.179Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.185Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.186Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.187Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.187Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.188Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.188Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.189Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.190Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.190Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.191Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.191Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.192Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.193Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.193Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.194Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.194Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.197Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.198Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.198Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.203Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.204Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.205Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.205Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.206Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.206Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.207Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.208Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.208Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.209Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.209Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.210Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.210Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.211Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.212Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.212Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.213Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.213Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.214Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.221Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.222Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.222Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.223Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.223Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.224Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.225Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.225Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.226Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.226Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.227Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.227Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.228Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.228Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.229Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.229Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.230Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.231Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T14:34:26.231Z <Buffer 21 ff 05 0f e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
226
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%

Thanks. Something is definitely not right here. Could you remove the bootstrap() call inside the module and check again? https://github.com/srn/hyperx-cloud-flight-wireless/blob/main/index.js#L72
The device will usually send a 0xf or 0x14 report once every 5 minutes, so give it some time if the battery report doesn't show up right away.

without L72

┌─┤[$]|[sl1pkn07]|[sL1pKKn07]|[/run/media/sl1pkn07/COSAS/aplicaciones]|
└───╼  NODE_PATH=$(npm root -g) node cloud_flight.js
2021-06-15T20:26:43.682Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T20:26:43.690Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T20:26:43.692Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T20:26:43.693Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T20:26:43.694Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T20:26:43.695Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T20:26:43.696Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T20:26:43.697Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T20:26:43.698Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T20:26:43.698Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T20:26:43.699Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T20:26:43.700Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T20:26:43.701Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T20:26:43.702Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T20:26:43.703Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T20:26:43.703Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T20:26:43.704Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T20:26:43.705Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T20:26:43.706Z <Buffer 64 01> length: 2
100
1
power: on
2021-06-15T20:26:43.728Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T20:26:43.729Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T20:26:43.729Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T20:26:43.729Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T20:26:43.730Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T20:26:43.730Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T20:26:43.730Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T20:26:43.730Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T20:26:43.731Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T20:26:43.731Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T20:26:43.731Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T20:26:43.731Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T20:26:43.731Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T20:26:43.732Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T20:26:43.732Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T20:26:43.732Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T20:26:43.732Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T20:26:43.733Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T20:26:43.733Z <Buffer 65 00> length: 2
101
0
muted: false
2021-06-15T20:26:43.746Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.747Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.748Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.749Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.749Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.750Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.751Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.751Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.752Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.752Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.753Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.754Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.755Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.755Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.757Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.757Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.758Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.759Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.759Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.765Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.766Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.767Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.767Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.768Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.768Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.769Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.770Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.771Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.771Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.772Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.773Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.774Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.775Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.776Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.777Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.778Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.779Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.780Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.782Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.783Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.784Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.786Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.787Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.788Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.789Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.790Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.791Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.792Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.793Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.794Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.795Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.796Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.797Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.798Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.801Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.801Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.802Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.803Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.804Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.804Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.805Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.805Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.806Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.807Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.807Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.808Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.809Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.809Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.810Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.811Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.811Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.812Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.812Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.813Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.813Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.814Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.837Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.838Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.839Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.839Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.840Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.840Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.841Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.841Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.842Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.842Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.843Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.843Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.844Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.844Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.845Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.846Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.846Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.847Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%
2021-06-15T20:26:43.847Z <Buffer 21 ff 05 0f da 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00> length: 20
33
255
5
15
218
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
current battery: 100%

greetings


Add framerate information/examples

Nice!  I picked that default simply because it is the lowest generally acceptable value, but it might be worthwhile defaulting it to 30 since I'm guessing that's probably more common.  No need to change anything now, but we can keep it in mind.  Thanks for updating this!


Tests broken

From: http://build-eu-00.elastic.co/view/LS Plugins/view/LS Inputs/job/logstash-plugin-input-lumberjack-unit/14/
Using bundler 1.10.6
Bundle complete! 5 Gemfile dependencies, 39 gems now installed.
Use `bundle show [gemname]` to see where a bundled gem is installed.
Using Accessor#strict_set for specs
Run options: exclude {:redis=>true, :socket=>true, :performance=>true, :couchdb=>true, :elasticsearch=>true, :elasticsearch_secure=>true, :export_cypher=>true, :integration=>true, :windows=>true}
.......F.......

Failures:

  1) LogStash::Inputs::Lumberjack#processing of events #codecs clone the codec per connection
     Failure/Error: lumberjack.run(queue)
     NoMethodError:
       undefined method `shutdown' for #<LogStash::Inputs::Lumberjack:0x36edcdeb>
     # ./lib/logstash/inputs/lumberjack.rb:95:in `run'
     # ./spec/inputs/lumberjack_spec.rb:46:in `(root)'

Finished in 6.3 seconds (files took 1.37 seconds to load)
15 examples, 1 failure

Failed examples:

rspec ./spec/inputs/lumberjack_spec.rb:43 # LogStash::Inputs::Lumberjack#processing of events #codecs clone the codec per connection

Randomized with seed 12389

Related to: #53 , but should not be the case, right?

Thanks for bringing this up, #53 fix this by removing the shutdown.
The problematic test wasn't gracefully shutting down the plugin and since plugins doesn't have a shutdown anymore it made the test crash, I have changed the test a bit to make sure it stop the plugin once the test ran.

#53 is merged


Support specific branch for OSX test execution

As of now we clone develop and run the tests on it.
We want to be able to support a specific commit or specified branch.

Closing this out as $(Build.SourceBranchName) is supported.


[SPARK-45827] Refactor supportsDataType

What changes were proposed in this pull request?
This is a follow-up to https://github.com/apache/spark/pull/45409. It refactors supportsDataType to use a non-recursive supportsScalarDataType method. This allows subclasses that just want to include or exclude one or two types to override with something like the following, rather than having to make a full copy of the recursive supportsDataType function, and risk getting out of sync as other types are changed in the base trait.
override def supportsScalarDataType(dt: DataType): Boolean = {
    dt.isInstanceOf[VariantType] || super.supportsScalarDataType(dt)
}

Why are the changes needed?
Allows subclasses to override the list of supported types with less duplicated code, and less risk of bugs.
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Existing tests.
Was this patch authored or co-authored using generative AI tooling?
No.

I realized that the example I gave in the PR description works just as well if we override supportsDataType, since the call to super.supportsScalarDataType will eventually call back into the subclass when it hits a scalar type recursively. So I don't think this PR really adds value.


[Version] Update main repo version to V0.4

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Can we take the chance to update GSP as well? Might be good to have version updates in one commit.
Then we need to create a separate PR for GSP to create new Dockerfiles for 0.4, to start we just copy the 0.3.1 ones.


Convert porter/skeletor to GitHub Actions

Pipeline migrated from Azure DevOps :tada:
Manual steps
Perform the following steps to complete the migration:
porter/skeletor

[ ] Ensure secret is available: ${{ secrets.GITHUB_TOKEN }}

This was implemented in https://github.com/getporter/skeletor/pull/51


[QE] azure.sh terraform destroy failed

Describe the bug
This issue happened twice in azure.sh job. It failed to delete subnet because the NIC hasn't be deleted.

Use this issue to track if it happens again.

Here is a discussion: https://discuss.hashicorp.com/t/azure-destroy-error-shows-in-use-and-will-not-complete-destory/4801/4


Significant Slowdown when Upgrading from 0.13.0 to 0.20.0

While working on the upgrade from redb 0.13.0 to redb 0.20.0 for ord in https://github.com/ordinals/ord/pull/2141, we have encountered a very significant slowdown on our workload. Indexing signet with --index-sats takes about 19 minutes on my Mac with 0.13.0 and takes 6 hours and 45 minutes with 0.20.0. Process sys time goes up by a factor of 400. Details of what we changed for the upgrade are in the PR. We also tried with redb::Durability::Eventual - still running, but does not seem significantly better.
Before (0.13.0):
time target/release/ord --signet --index-sats index
1095.31s user 35.47s system 99% cpu 18:53.03 total

After (0.20.0):
time target/release/ord --signet --index-sats index
5543.28s user 14072.40s system 80% cpu 6:45:53.23 total

These are just our initial findings, will do more investigation. We suspect this is due to the change in https://github.com/cberner/redb/blob/master/CHANGELOG.md#0140---2023-03-26 removing mmap. Any ideas for how to get back to old speed would be much appreciated. As it stands, this would be prohibitively slow to index mainnet - takes good 12 hours currently, and would go up to more than a week if we see the same slowdown.

Uh oh, well that's not good. Have you tried adjusting Builder::set_cache_size()? Try setting that to as much memory as you can afford to give redb.
I'll take a look too. How many blocks do I need to run the indexing for to reproduce the slowdown?

I tried indexing up to block 150k (kinda low, I know) and got the following:

03f6867755c246cf4ea64b9d85134558ce06b9b5 (redb 0.13.0): 1m 17sec
113086b27c4587c11af8baa50bf9ed61de378ae7 (redb 0.20.0): 1m 2sec

Have you tried running the indexing on Linux? This might be a MacOS specific issue. Casey & I found that MacOS has very poor performance with sync'ing changes to mmap'ed files, so possibly a similar issue is happening again.

I tried indexing up to block 150k (kinda low, I know) and got the following:

03f6867755c246cf4ea64b9d85134558ce06b9b5 (redb 0.13.0): 1m 17sec
113086b27c4587c11af8baa50bf9ed61de378ae7 (redb 0.20.0): 1m 2sec

Have you tried running the indexing on Linux? This might be a MacOS specific issue. Casey & I found that MacOS has very poor performance with sync'ing changes to mmap'ed files, so possibly a similar issue is happening again.

Thanks, will give it a try on Linux. We're just getting a benchmarking server set up for such purposes. So far my tests were on Mac. I am running the tests on signet, and with --index-sats, then the slowdown happens after a few minutes once it reaches the first blocks with inscriptions (I believe around block 60k).

Uh oh, well that's not good. Have you tried adjusting Builder::set_cache_size()? Try setting that to as much memory as you can afford to give redb.
I'll take a look too. How many blocks do I need to run the indexing for to reproduce the slowdown?

Will give this a try on my Mac.

We also tried with redb::Durability::Eventual - still running, but does not seem significantly better.

Here is the result from that run (same Mac, also signet):
time target/release/ord --data-dir data-signet-full-eventual --signet --index-sats index
4993.21s user 12776.52s system 99% cpu 4:57:22.76 total

@cberner Unfortunately, neither setting 8 GB of cache nor running on Linux seems to make a significant difference - both runs seem to similarly slow (and will likely need a few more hours to finish). Will post numbers here when done.

I'm able to reproduce it on my Linux desktop using signet. Will dig in shortly!

Uh oh, well that's not good. Have you tried adjusting Builder::set_cache_size()? Try setting that to as much memory as you can afford to give redb.
I'll take a look too. How many blocks do I need to run the indexing for to reproduce the slowdown?

Will give this a try on my Mac.

Setting an 8GB cache helps somewhat:
time target/release/ord --signet --index-sats index
3665.50s user 2513.52s system 99% cpu 1:43:01.65 total

This is also with redb::Durability::Eventual
Glad to hear you could reproduce it and looking forward to hear what you find!

Some findings: it looks like this is mainly a perf regression switching from mmap to the pure userspace backend. Which is rather unfortunate, because that was required to make redb safe. Hopefully, I can optimize this to get that performance back.
Findings below:
Indexed up to block 100k on signet:
0.13.0 mmap + 2PC: 16m 21sec
0.13.0 mmap + 1PC+C: 23m 36sec
0.13.0 no-mmap + 2PC: 53m
0.13.0 no-mmap + 1PC+C: 116m 10sec
0.20.0 (implicitly no-mmap + 1PC+C): 115m 32sec

Thanks for the analysis - we suspected that as well. The cache size insight is helpful, but relying on that would make this unusable for a large group of users - people run this on 16GB or 32GB machines. Hope there's other optimization potential. Would also be interested if there's anything in how we use redb that makes our load particularly challenging from a performance perspective? In the Changelog you had stated a maximum slowdown of a factor or 2, but here we see more than 5 - so curious if we're maybe doing anything particularly inefficient?

Ya, I'm hopeful that implementing a better cache heuristic will allow a similar benefit with a smaller cache size.
I don't think there's anything ord is doing inefficiently, although haven't looked through the code in a while. I think it's just that the ord file size is much bigger than most of the benchmarks that I ran, so I didn't see these cache effects

I fixed the added overhead from removing WriteStrategy in https://github.com/cberner/redb/pull/609
This brings it down to:

0.20.0 w/ unlimited (100GB) cache + deferred checksums: 29m 22sec

Next I'm going to work on the caching heuristic, which will hopefully remove the need to use a 100GB cache size

The cache size insight is helpful, but relying on that would make this unusable for a large group of users - people run this on 16GB or 32GB machines.

Running ord with --index-sats has always required at least 64GB. I remember buying a new M1 with 32GB and I couldn't index so I had to buy the 64GB version. But if we could get that down to 32GB with some cache magic that would be great!

https://github.com/cberner/redb/pull/611 should make this much better. I just indexed signet up to 100k with the default 1GB cache size, and it was as fast as setting it to 8GB: 30min. I'm testing indexing mainnet now

@veryordinally , so I noticed one thing that ord may be doing inefficiently. This value_cache is a HashMap so the insertion order will be arbitrary. If you can insert them in the same order that they are sorted in redb you'll get better cache hits when updating the file, because values are stored sorted on disk

I created a branch which uses a BTreeMap for both the value cache and the range cache. I didn't benchmark because I'm on a different machine, so it wouldn't be apples to apples, so try it and see if it makes a difference: https://github.com/casey/ord/tree/ordered-insertion

@veryordinally , so I noticed one thing that ord may be doing inefficiently. This value_cache is a HashMap so the insertion order will be arbitrary. If you can insert them in the same order that they are sorted in redb you'll get better cache hits when updating the file, because values are stored sorted on disk

I created a branch which uses a BTreeMap for both the value cache and the range cache. I didn't benchmark because I'm on a different machine, so it wouldn't be apples to apples, so try it and see if it makes a difference: https://github.com/casey/ord/tree/ordered-insertion
One downside is that unlike a HashMap, BTreeMap storage can't be drained and reused, so this will reallocate the caches when they're committed, which might degrade performance.

Thanks, this is great. I will compare on my machine.

Ok, redb 0.22.0 should be much faster. I was able to index mainnet up to height 790k using an 8GB cache in 31hrs 42min

I just ran with redb 0.13.0 for comparison and it took 20hr 47min, so it looks like this is now within the expected performance delta! I'm going to close this, but feel free to re-open if you still encounter a regression


Gitflow not working on version 8.34 in Mac OS

The issue might be due to the change on how PATH enviroment variable are obtained in Mac OS.
SO: MacOS Sonoma
SourceGit Version: 8.34
Hardware: Macbook Pro - 2020 (intel x64)
-- With 8.33 I have no problem using gitflow.
Message:
"git: 'flow' is not a git command. See 'git --help'.
The most similar commands are
reflog
show"

did you try the latest ci build from github action？

https://github.com/sourcegit-scm/sourcegit/actions/runs/11337556020

#539


Animation is on fast forward.

Hello, I just tried this demo, https://threejs.org/examples/webgl_animation_cloth.html, and the cloth animates very very fast.
Is that expected on that demo? Is it perhaps relying on the fact that regular browsers limit the frame rate to 60fps?

I see the same thing, and this is expected judging from the simulation implementation, which is dependent on the tick rate (https://threejs.org/examples/js/Cloth.js).
Any example that does a constant thing every frame without diffing timestamps would be subject to this (similar problems with VR).
Closing this as I don't think it's an Exokit issue.

I wonder if it would make sense to cap to 60 to do something that's more expected from a browser though...


repl_expect unable to find location of error

When a repl expectation fails, the test runner is unable to find the source file of the failed assertion. This is likely due to the path being relative instead of absolute. Hard-coding an absolute path fixes the problem.
https://github.com/roc-lang/roc/blob/4022b44ff92883a7eeab304706b1f1487b39636e/crates/repl_expect/src/run.rs#L260-L267
Error: thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', /home/user/roc/crates/repl_expect/src/run.rs:264:52
Steps to reproduce

Edit one of the expect assertions in crates/compiler/builtins/roc/List.roc so it should fail
Run cargo run --locked --release -- test crates/compiler/builtins/roc/Str.roc

To see the correct error
Do the steps to reproduce then replace line 262 of crates/repl_expect/src/run.rs with
let path = format!("crates/compiler/builtins/roc{}", &data.path.display());

This should print the correct error message when step 2 is run again.

hmm, I cannot reproduce this error any more
── EXPECT FAILED ──────────────────────── crates/compiler/builtins/roc/Str.roc ─

This expectation failed:

803│  expect Bool.false
      ^^^^^^^^^^^^^^^^^

1 failed and 21 passed in 379 ms.

so it seems to have fixed itself? (please re-open if I'm missing something)


chore: add class for ipfs daemon fixture

Proposed changes
This PR adds a class for IPFS fixture.
Types of changes
What types of changes does your code introduce? (A breaking change is a fix or feature that would cause existing functionality and APIs to not work as expected.)
Put an x in the box that applies

[ ] Non-breaking fix (non-breaking change which fixes an issue)
[ ] Breaking fix (breaking change which fixes an issue)
[x] Non-breaking feature (non-breaking change which adds functionality)
[ ] Breaking feature (breaking change which adds functionality)
[ ] Refactor (non-breaking change which changes implementation)
[ ] Messy (mixture of the above - requires explanation!)

Checklist
Put an x in the boxes that apply.

[x] I have read the CONTRIBUTING doc
[x] I am making a pull request against the main branch (left side). Also you should start your branch off our main.
[x] Lint and unit tests pass locally with my changes
[x] I have added tests that prove my fix is effective or that my feature works
[x] I have locally run services that could be impacted and they do not present failures derived from my changes

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

The macOS failure is known to be flaky, and the e2e failure is not related.


error in running evaluation function

i'm getting this error when trying to use summarize function , can you please help ??
thanks in advance

Hi, @mohamedelbeih!
I was facing the same problem, so i rewrote the code
document = document.apply(lambda x: "<go> " + x + "<stop>") document.head()
manually (insted of copy and past) and executed its dependent cells.  This solved the problem for me.

Hi, @mohamedelbeih!
I was facing the same problem, so i rewrote the code
document = document.apply(lambda x: "<go> " + x + "<stop>")
document.head()
manually (insted of copy and past) and executed its dependent cells.
This solved the problem for me.

Yes, I suppose this could be a formatting issue.

in the code this is done for summary ( summary = summary.apply(lambda x: " " + x + "")).
So we should do this for both document and summary or only document or only summary

in the code this is done for summary ( summary = summary.apply(lambda x: " " + x + "")). So we should do this for both document and summary or only document or only summary everything is running error free, but not getting expected results atleast near to you. please help My notebook: https://colab.research.google.com/drive/1JR7bZb5gsmC9zphD-z8oX1gwJVmPk2jm?usp=share_link

Hi,
You just need to apply this to the decoder inputs (summary). The idea behind this is, the decoder inputs are something that we wouldn't know during inference. For instance, while training we know the expected summary, hence we simply use it with an offset 1. But during inference, we need to give the model some indication that it needs to use the original document and generate a word for the summary. So it uses your document and the word "<go>" and generates the first word (say "the"). Then it takes the document and the context for the words "<go>" and "the" and generates the next word and so on. We know where to stop given by the "<stop>" keyword.
As far as the results are concerned, if you notice I have trained the model for 20 epochs, not 10 which is not clear in the notebook. I had to train it twice due to the runtime restrictions of colab. Maybe that is the reason for your issue.

Thanks for answering, now i started running it applying only for decoder inputs, its still running but my loss started with 10.5 very farther from yours. Few differences I observed are following
In Tokenizing the texts into integer tokens, your encoder_vocab_size, decoder_vocab_size are (76362, 29661), mine are (76362, 29661).
There are other small diffreneces in summary_lenghts properties (.describe()).
Am i doing something wrong or is all ok, thank you and please help.
collab link: https://colab.research.google.com/drive/1JR7bZb5gsmC9zphD-z8oX1gwJVmPk2jm?usp=share_link

Thanks for answering, now i started running it applying only for decoder inputs, its still running but my loss started with 10.5 very farther from yours. Few differences I observed are following In Tokenizing the texts into integer tokens, your encoder_vocab_size, decoder_vocab_size are (76362, 29661), mine are (76362, 37307) There are other small diffreneces in summary_lenghts properties (.describe()). Am i doing something wrong or is all ok, thank you and please help. collab link: https://colab.research.google.com/drive/1JR7bZb5gsmC9zphD-z8oX1gwJVmPk2jm?usp=share_link

As I said earlier, I had trained the model earlier on top of which I trained it for the results displayer. I mean,
Epoch 1 Loss 2.5077

is after 10-20 epochs. I trained in the background, but it cannot be seen there.

ok I will continue the training.
is it possible to store or somehow pause training and again resume it with stored weights on the same notebook or on a different machine.
really Thank you for answering, and thank you for being active and continue being active

See model checkpointing. I have already used it in the notebook:
checkpoint_path = "checkpoints"

ckpt = tf.train.Checkpoint(transformer=transformer, optimizer=optimizer)

ckpt_manager = tf.train.CheckpointManager(ckpt, checkpoint_path, max_to_keep=5)

if ckpt_manager.latest_checkpoint:
    ckpt.restore(ckpt_manager.latest_checkpoint)
    print ('Latest checkpoint restored!!')

Just load the last saved checkpoint and fit the model for the next set of epochs.
Ref: https://www.tensorflow.org/api_docs/python/tf/train/Checkpoint

After 40 epochs loss is down to 2.2, but the output summaries are filled with . as below
to sell 1st selling house stake in b 39 desh firm firm fund ceo ceo ceo ceo ceo ceo  fund fund       fund fund fund  fund ceo............
Do you think something is wrong or it just needs more learning?
collab link: https://colab.research.google.com/drive/1JR7bZb5gsmC9zphD-z8oX1gwJVmPk2jm?usp=share_link


Debug console sends evalution to parent session which fails

Create two js debug sessions
Open debug console, manually change the dropdown to the other session
try to evaluate something in the debug console -> vs code sends it against the parent session gets an error and no evaluation is shown

If the session is merged with the parent session we  should always send to the child session.
It seems like the drop down incorrectly chooses the parent session

@isidorn you said
"If the session is merged with the parent session..."
But in the initial comment I do not see how two unrelated sessions could have a parent/child relation?
The initial problem does not occur if two sessions run in two debug consoles, right?

@isidorn you said
"If the session is merged with the parent session..."
But in the initial comment I do not see how two unrelated sessions could have a parent/child relation?
The initial problem does not occur if two sessions run in two debug consoles, right?

The two unrelated session do not have a parent/child relation between them.
However each of those two sessions has a parent child relationship with it's wrapper session (since this is using js-debug).
So yes the initial problem was ocurring when those two sessions are running in two debug consoles.

The two unrelated session do not have a parent/child relation between them.
However each of those two sessions has a parent child relationship with it's wrapper session (since this is using js-debug).
So yes the initial problem was ocurring when those two sessions are running in two debug consoles.

Thanks, now I understand. And since we hide the parent now in one-child cases, I was not seeing the parent/child relation anymore...

Thanks, now I understand. And since we hide the parent now in one-child cases, I was not seeing the parent/child relation anymore...

Correct, sorry for not including the details in the original comment.

Correct, sorry for not including the details in the original comment.


Add detekt-hint to integrations

Simply adding my plugin as an integration to detekt, see #2437.

Codecov Report

Merging #2441 into master will not change coverage by %.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #2441   +/-   ##
=========================================
  Coverage     82.93%   82.93%
  Complexity     2177     2177
=========================================
  Files           359      359
  Lines          6206     6206
  Branches       1133     1133
=========================================
  Hits           5147     5147
  Misses          480      480
  Partials        579      579

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7ac6cc8...c94f1d2. Read the comment docs.


Use SQLite optimisations for batch loading

This page describes a number of SQLite optimisations that can be used to speed up our batch loading. Specifically, it suggests setting the following:
PRAGMA journal_mode = OFF;
PRAGMA synchronous = 0;
PRAGMA cache_size = 1000000;
PRAGMA locking_mode = EXCLUSIVE;
PRAGMA temp_store = MEMORY;

This issue is to have valve issue these directives right before loading the database. Note that these commands should only be used for bulk loading. They are unsafe when using valve as a library or for any other purpose.

For Postgres, see this stack overflow post and Postgres's guide for populating a db.


fix: volumeMount create error

Signed-off-by: wanglei4687<EMAIL_ADDRESS>What type of PR is this?

[ ] API-change
[x] BUG
[ ] Improvement
[ ] Documentation
[ ] Feature
[ ] Test and CI
[ ] Code Refactoring

Which issue(s) this PR fixes:
Fixes #207
What this PR does / why we need it:
Not Available
Special notes for your reviewer:
Not Available
Additional documentation (e.g. design docs, usage docs, etc.):
Not Available

@mergify update


[Bug]: Lack of transactionality mechanics in create_collection

What happened?
Creating a collection in Chroma involves several steps:

Create the collection in sysdb
Create segments (metadata + Vector)
Create a Vector segment in sysdb
Create metadata segment in sysdb

If any of steps 2-3 fails, Chroma is left in an inconsistent state, with the collection in sysdb. A subsequent delete_collection or get_or_create_collection may fix the problem. However, a simple create_collection will return a UniqueConstraint error.
This is not a critical issue, as there are ways to work around it. However, it highlights the need for robust error handling, including but not limited to rollback.
Versions
Chroma 0.4.x and 0.5.x (single-node), Any OS or Python version
Relevant log output
Python 3.11.7 (main, Dec 30 2023, 14:03:09) [Clang 15.0.0 (clang-15<IP_ADDRESS>.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import chromadb
>>> client = chromadb.Client()
>>> try:
...     client.create_collection("test",metadata={"hnsw:batch_size":100})
... except Exception as e:
...     print(e)
...
Unknown HNSW parameter: hnsw:batch_size
>>> client.create_collection("test")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/tazarov/experiments/chroma/taz-sprint-14/chromadb/api/client.py", line 198, in create_collection
    return self._server.create_collection(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/tazarov/experiments/chroma/taz-sprint-14/chromadb/telemetry/opentelemetry/__init__.py", line 143, in wrapper
    return f(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^
  File "/Users/tazarov/experiments/chroma/taz-sprint-14/chromadb/api/segment.py", line 173, in create_collection
    coll, created = self._sysdb.create_collection(
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/tazarov/experiments/chroma/taz-sprint-14/chromadb/telemetry/opentelemetry/__init__.py", line 143, in wrapper
    return f(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^
  File "/Users/tazarov/experiments/chroma/taz-sprint-14/chromadb/db/mixins/sysdb.py", line 220, in create_collection
    raise UniqueConstraintError(f"Collection {name} already exists")
chromadb.db.base.UniqueConstraintError: Collection test already exists

Note: The above issue is reproducible for in-memory chroma single-node local or server (distributed not tested)

delete_collection has a similar sequence.

what is the workaround for this?


Default Locale Slug is emptied, when another Locale has the same value

When creating a document with a localized title and slug based off of this title, if only the english locale value is set first, and then another locale is set with the same value - the english slug value is removed.
This is very similar to an older issue #153 however the flow that surfaces it is.
page = PageSlugLocalized.create!(title:"Title On English")
# page["_slugs"] returns {"en" => ["title-on-english"]}

# Switch Locales
I18n.locale = "nl"
page.update_attributes(title:"Title On English")

# page["_slugs"] now returns {"en" => [], "nl" => ["title-on-english"]}

Some environment versions:
Rails 4.2.0
Ruby  2.1.1p76
mongoid-slug (4.0.0)

+1

Care to write a spec for this, @wzowee or @onomated. Lets fix it.

Have created a spec based on my issue description above - it's passing :+1:  I should be back in the code base where I was having this issue originally this week so will check in see if it's still a problem and if the spec correctly covers the issue I'm seeing there.

Ok I can reproduce the error now - I have I18n Fallbacks enabled and this is causing the issue.
See my recent commit where all I have done is added a require to "i18n/backend/fallbacks" this is enough to cause a number of specs to fail, in my actual app I also have the fallbacks properly mapped but adding the require here has been enough to cause the issue.
If I comment out the following line https://github.com/digitalplaywright/mongoid-slug/blob/master/lib/mongoid/slug.rb#L183 then the new spec passes but others of course fail.

This is helpful, @wzowee do you think you can turn this into a single failing spec in this project? I mean something we'll be able to commit with a fix?

I've broken this out into a seperate fallback_spec.rb spec in my fork. However there is an issue where the use of require "i18n/backend/fallbacks" in fallback_spec.rb is causing tests in slug_spec.rb to fail. I'm unsure of a way to correctly isolate the inclusion of I18n Fallbacks - have asked a question on stack overflow - http://stackoverflow.com/questions/32750536/isolate-a-required-class-within-the-scope-of-a-single-spec - but no response. Any thoughts?

I think there's no way to unload something easily without having intimate knowledge of it, but maybe there's a way to do two test runs in Rakefile?

Bump @wzowee I'd like a fix for this still, looks like you got pretty far.


Can’t change values on Tf2

I’ve been trying to change the values of time played on certain characters but it never works. It either says 0 achievements and 0 statistics changed when i click commit changes or it says “An error occurred  while setting the value for ...... aborting store.” Please can anyone help?

I would imagine at this point most achievements or statistics can only be granted/set by servers, so won't be available through SAM.

It sometimes changes it. For example, I was able to change it on engineer but not spy.


[Feature Request] Comment thread text search

I often want to search a comment thread to see if someone mentioned a topic. As is, I don't see any way to do that.

Good idea. I think we could either try to do this natively or pipe everything to less which has a built-in search function. One thing that might be a problem is that usually only the first 200ish comments are loaded and there would be no way to search all of the comments.

There's an account setting for the number of comments, which has a limit
increase with reddit gold. I don't know if rtv obeys that right now, but
that could end up being a separate feature request.
On 12/31/2016 03:55 PM, Michael Lazar wrote:

Good idea. I think we could either try to do this natively or pipe
everything to |less| which has a built-in search function. One thing
that might be a problem is that usually only the first 200ish comments
are loaded and there would be no way to search /all/ of the comments.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/michael-lazar/rtv/issues/335#issuecomment-269883226, or
mute the thread
https://github.com/notifications/unsubscribe-auth/AMvjmi3twohkB33c4-ngYIX427KAAzTmks5rNs9ggaJpZM4LYcH3.

Yea I believe that we don't specify the number of comments to fetch, which means that it falls back to the user's default setting.
https://github.com/praw-dev/praw/blob/praw3/praw/objects.py#L1131

Chiming in to say I really want this too, and I think it would be ideal if the same bind that's used to search across subreddits was used to search for words when you're inside a submission.


Why does it always report errors during training? And there's a situation where grad_norm equals NaN.

Why does it always report errors during training? And there's a situation where grad_norm equals NaN. This is my training log, how do I fix this problem?Uploading 20240807_094509.log…
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] 6019/6019, 9.7 task/s, elapsed: 617s, ETA:     0s
All Results write to ./work_dirs/sparsedrive_small_stage1/results.pkl
Formating bboxes of img_bbox
Start to convert detection format...
[>>>>>>>>>                                         ] 1098/6019, 51.0 task/s, elapsed: 22s, ETA:    97sTraceback (most recent call last):
File "./tools/train.py", line 321, in
main()
File "./tools/train.py", line 296, in main
custom_train_model(
File "/mnt/wxc/E2E_Planning_work/SparseDrive-main/projects/mmdet3d_plugin/apis/train.py", line 29, in custom_train_model
custom_train_detector(
File "/mnt/wxc/E2E_Planning_work/SparseDrive-main/projects/mmdet3d_plugin/apis/mmdet_train.py", line 219, in custom_train_detector
runner.run(data_loaders, cfg.workflow)
File "/home/echo/anaconda3/envs/sparsedrive/lib/python3.8/site-packages/mmcv/runner/iter_based_runner.py", line 144, in run
iter_runner(iter_loaders[i], **kwargs)
File "/home/echo/anaconda3/envs/sparsedrive/lib/python3.8/site-packages/mmcv/runner/iter_based_runner.py", line 70, in train
self.call_hook('after_train_iter')
File "/home/echo/anaconda3/envs/sparsedrive/lib/python3.8/site-packages/mmcv/runner/base_runner.py", line 317, in call_hook
getattr(hook, fn_name)(self)
File "/home/echo/anaconda3/envs/sparsedrive/lib/python3.8/site-packages/mmcv/runner/hooks/evaluation.py", line 266, in after_train_iter
self._do_evaluate(runner)
File "/mnt/wxc/E2E_Planning_work/SparseDrive-main/projects/mmdet3d_plugin/core/evaluation/eval_hooks.py", line 94, in _do_evaluate
key_score = self.evaluate(runner, results)
File "/home/echo/anaconda3/envs/sparsedrive/lib/python3.8/site-packages/mmcv/runner/hooks/evaluation.py", line 367, in evaluate
eval_res = self.dataloader.dataset.evaluate(
File "/mnt/wxc/E2E_Planning_work/SparseDrive-main/projects/mmdet3d_plugin/datasets/nuscenes_3d_dataset.py", line 843, in evaluate
result_files, tmp_dir = self.format_results(
File "/mnt/wxc/E2E_Planning_work/SparseDrive-main/projects/mmdet3d_plugin/datasets/nuscenes_3d_dataset.py", line 632, in format_results
name: self._format_bbox(
File "/mnt/wxc/E2E_Planning_work/SparseDrive-main/projects/mmdet3d_plugin/datasets/nuscenes_3d_dataset.py", line 444, in _format_bbox
boxes = output_to_nusc_box(
File "/mnt/wxc/E2E_Planning_work/SparseDrive-main/projects/mmdet3d_plugin/datasets/nuscenes_3d_dataset.py", line 1072, in output_to_nusc_box
box = NuScenesBox(
File "/home/echo/anaconda3/envs/sparsedrive/lib/python3.8/site-packages/nuscenes/utils/data_classes.py", line 543, in init
assert not np.any(np.isnan(center))
AssertionError
ERROR:torch.distributed.elastic.multiprocessing.api:failed (exitcode: 1) local_rank: 0 (pid: 725004) of binary: /home/echo/anaconda3/envs/sparsedrive/bin/python3
Traceback (most recent call last):
File "/home/echo/anaconda3/envs/sparsedrive/lib/python3.8/runpy.py", line 194, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/home/echo/anaconda3/envs/sparsedrive/lib/python3.8/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/home/echo/anaconda3/envs/sparsedrive/lib/python3.8/site-packages/torch/distributed/launch.py", line 195, in
main()
File "/home/echo/anaconda3/envs/sparsedrive/lib/python3.8/site-packages/torch/distributed/launch.py", line 191, in main
launch(args)
File "/home/echo/anaconda3/envs/sparsedrive/lib/python3.8/site-packages/torch/distributed/launch.py", line 176, in launch
run(args)
File "/home/echo/anaconda3/envs/sparsedrive/lib/python3.8/site-packages/torch/distributed/run.py", line 753, in run
elastic_launch(
File "/home/echo/anaconda3/envs/sparsedrive/lib/python3.8/site-packages/torch/distributed/launcher/api.py", line 132, in call
return launch_agent(self._config, self._entrypoint, list(args))
File "/home/echo/anaconda3/envs/sparsedrive/lib/python3.8/site-packages/torch/distributed/launcher/api.py", line 246, in launch_agent
raise ChildFailedError(
torch.distributed.elastic.multiprocessing.errors.ChildFailedError:
./tools/train.py FAILED
Failures:
<NO_OTHER_FAILURES>
Root Cause (first observed failure):
[0]:
time      : 2024-08-07_13:32:07
host      : xc
rank      : 0 (local_rank: 0)
exitcode  : 1 (pid: 725004)
error_file: <N/A>
traceback : To enable traceback see: https://pytorch.org/docs/stable/elastic/errors.html

Same problem.Have you solved it?

还没有，是不是只能使用多卡训练呀？
---- Replied Message ----
From @.> Date 08/07/2024 20:20 To @.> Cc @.>、State @.> Subject Re: [swc-17/SparseDrive] Why does it always report errors during training? And there's a situation where grad_norm equals NaN. (Issue #21)
Same problem.Have you solved it?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you modified the open/close state.Message ID: @.***>

@Wangxuecheng666 是用的单卡训练吗? 需要降低学习率

@swc-17 是用单卡训练的，需要降低到多少合适呢？另外，模型训练到一半时会中途报错是什么原因呢？谢谢

@Wangxuecheng666 可以从1/8开始尝试.这个报错看起来不是训练的问题,而是因为训练发散了,中途评测有nan值报错.

@swc-17 是用单卡训练的，需要降低到多少合适呢？另外，模型训练到一半时会中途报错是什么原因呢？谢谢

Hello, have you solved this problem?

是的，降低学习率能够解决此问题，但性能会下降很多，尤其是跟踪任务。
---- 回复的原邮件 ----
发件人 @.> 日期 2024年08月14日 17:20 收件人 @.> 抄送至<EMAIL_ADDRESS>主题 Re: [swc-17/SparseDrive] Why does it always report errors during training? And there's a situation where grad_norm equals NaN. (Issue #21)
@swc-17 是用单卡训练的，需要降低到多少合适呢？另外，模型训练到一半时会中途报错是什么原因呢？谢谢
Hello, have you solved this problem?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

是的，降低学习率能够解决此问题，但性能会下降很多，尤其是跟踪任务。 ---- 回复的原邮件 ---- 发件人 @.> 日期 2024年08月14日 17:20 收件人 @.> 抄送至<EMAIL_ADDRESS>主题 Re: [swc-17/SparseDrive] Why does it always report errors during training? And there's a situation where grad_norm equals NaN. (Issue #21) @swc-17 是用单卡训练的，需要降低到多少合适呢？另外，模型训练到一半时会中途报错是什么原因呢？谢谢 Hello, have you solved this problem? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

您是怎么降低的呀，我这边3张4090，学习率降低至1e-4，还是会有这个问题

我单张4090，降到0.5e-4和1e-4都可以正常训练
---- 回复的原邮件 ----
发件人 @.> 日期 2024年08月14日 17:45 收件人 @.> 抄送至<EMAIL_ADDRESS>主题 Re: [swc-17/SparseDrive] Why does it always report errors during training? And there's a situation where grad_norm equals NaN. (Issue #21)
是的，降低学习率能够解决此问题，但性能会下降很多，尤其是跟踪任务。 ---- 回复的原邮件 ---- 发件人 @.> 日期 2024年08月14日 17:20 收件人 @.> 抄送至<EMAIL_ADDRESS>主题 Re: [swc-17/SparseDrive] Why does it always report errors during training? And there's a situation where grad_norm equals NaN. (Issue #21) @swc-17 是用单卡训练的，需要降低到多少合适呢？另外，模型训练到一半时会中途报错是什么原因呢？谢谢 Hello, have you solved this problem? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.>
您是怎么降低的呀，我这边3张4090，学习率降低至1e-4，还是会有这个问题
image.png (view on web)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.>

我单张4090，降到0.5e-4和1e-4都可以正常训练 ---- 回复的原邮件 ---- 发件人 @.> 日期 2024年08月14日 17:45 收件人 @.> 抄送至<EMAIL_ADDRESS>主题 Re: [swc-17/SparseDrive] Why does it always report errors during training? And there's a situation where grad_norm equals NaN. (Issue #21) 是的，降低学习率能够解决此问题，但性能会下降很多，尤其是跟踪任务。 ---- 回复的原邮件 ---- 发件人 @.> 日期 2024年08月14日 17:20 收件人 @.> 抄送至<EMAIL_ADDRESS>主题 Re: [swc-17/SparseDrive] Why does it always report errors during training? And there's a situation where grad_norm equals NaN. (Issue #21) @swc-17 是用单卡训练的，需要降低到多少合适呢？另外，模型训练到一半时会中途报错是什么原因呢？谢谢 Hello, have you solved this problem? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.> 您是怎么降低的呀，我这边3张4090，学习率降低至1e-4，还是会有这个问题 image.png (view on web) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.>

您是将初始学习率lr和min_lr_ratio都调小了嘛

只调了lr
---- 回复的原邮件 ----
发件人 @.> 日期 2024年08月14日 18:11 收件人 @.> 抄送至<EMAIL_ADDRESS>主题 Re: [swc-17/SparseDrive] Why does it always report errors during training? And there's a situation where grad_norm equals NaN. (Issue #21)
我单张4090，降到0.5e-4和1e-4都可以正常训练 ---- 回复的原邮件 ---- 发件人 @.> 日期 2024年08月14日 17:45 收件人 @.> 抄送至<EMAIL_ADDRESS>主题 Re: [swc-17/SparseDrive] Why does it always report errors during training? And there's a situation where grad_norm equals NaN. (Issue #21) 是的，降低学习率能够解决此问题，但性能会下降很多，尤其是跟踪任务。 ---- 回复的原邮件 ---- 发件人 @.> 日期 2024年08月14日 17:20 收件人 @.> 抄送至<EMAIL_ADDRESS>主题 Re: [swc-17/SparseDrive] Why does it always report errors during training? And there's a situation where grad_norm equals NaN. (Issue #21) @swc-17 是用单卡训练的，需要降低到多少合适呢？另外，模型训练到一半时会中途报错是什么原因呢？谢谢 Hello, have you solved this problem? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.> 您是怎么降低的呀，我这边3张4090，学习率降低至1e-4，还是会有这个问题 image.png (view on web) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.>
您是将初始学习率lr和min_lr_ratio都调小了嘛
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

只调了lr ---- 回复的原邮件 ---- 发件人 @.> 日期 2024年08月14日 18:11 收件人 @.> 抄送至<EMAIL_ADDRESS>主题 Re: [swc-17/SparseDrive] Why does it always report errors during training? And there's a situation where grad_norm equals NaN. (Issue #21) 我单张4090，降到0.5e-4和1e-4都可以正常训练 ---- 回复的原邮件 ---- 发件人 @.> 日期 2024年08月14日 17:45 收件人 @.> 抄送至<EMAIL_ADDRESS>主题 Re: [swc-17/SparseDrive] Why does it always report errors during training? And there's a situation where grad_norm equals NaN. (Issue #21) 是的，降低学习率能够解决此问题，但性能会下降很多，尤其是跟踪任务。 ---- 回复的原邮件 ---- 发件人 @.> 日期 2024年08月14日 17:20 收件人 @.> 抄送至<EMAIL_ADDRESS>主题 Re: [swc-17/SparseDrive] Why does it always report errors during training? And there's a situation where grad_norm equals NaN. (Issue #21) @swc-17 是用单卡训练的，需要降低到多少合适呢？另外，模型训练到一半时会中途报错是什么原因呢？谢谢 Hello, have you solved this problem? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.> 您是怎么降低的呀，我这边3张4090，学习率降低至1e-4，还是会有这个问题 image.png (view on web) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.> 您是将初始学习率lr和min_lr_ratio都调小了嘛 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
感谢~我去试一下


New configuration annotations

With #34 merged, we have a new configuration annotation (controller.autoneg.dev/neg) that exposes the full configuration surface as json.
I've been considering a simpler interface for those who don't need that full flexibility, specifically targeting (what I assume is) the basic case of a single-port service, needing only two configuration options:
controller.autoneg.dev/backend-service:<name> (optional, defaulting to the name of the k8s service)
controller.autoneg.dev/max-rate-per-endpoint:<number> OR controller.autoneg.dev/max-connections-per-endpoint:<integer>
Thoughts?

@fdfzcq Do you and/or Fabric have thoughts here? With the new service name defaulting, I think you would need only a single annotation.

@soellman Sorry I totally missed this question :sweat_smile: We will discuss in the team and get back to you!

I think there is an opportunity here to make the setup even cleaner. Today, a full setup for a single port would look something like this:
apiVersion: v1
kind: Service
metadata:
  name: fabric-test
  namespace: fabric
  annotations:
    cloud.google.com/neg: '{"exposed_ports":{"5990":{}}}'
    controller.autoneg.dev/neg: '{"backend_services":{"5990":[{"max_rate_per_endpoint":800}]}}'
  labels:
    app: fabric-test
spec:
  selector:
    app: fabric-test
  type: ClusterIP
  clusterIP: None
  ports:
  - name: http
    port: 8080
    protocol: TCP
  - name: grpc
    port: 5990
    protocol: TCP

And it's for example not great that we need to specify the port number 5990 in three different places to make it work.
For our use-case, we usually also have multiple ports listed while we only care about one being exposed (for now at least).
One possible simplification might be if autoneg also could help with setting the cloud.google.com/neg annotation on the service.
So the flow would look something like:

autoneg sees some controller.autoneg.dev annotation(s)
autoneg sets the cloud.google.com/neg annotation accordingly
ingress-gce sees the cloud.google.com/neg annotation and creates the NEGs and sets cloud.google.com/neg-status
autoneg sees the cloud.google.com/neg-status and finally can add the NEGs to the backend service accordingly

This flow together with utilization of named ports can probably simplify things all the way down to something like this:
apiVersion: v1
kind: Service
metadata:
  name: fabric-test
  namespace: fabric
  annotations:
    controller.autoneg.dev/port-name: grpc
    controller.autoneg.dev/max-rate-per-endpoint: 800
  labels:
    app: fabric-test
spec:
  selector:
    app: fabric-test
  type: ClusterIP
  clusterIP: None
  ports:
  - name: http
    port: 8080
    protocol: TCP
  - name: grpc
    port: 5990
    protocol: TCP

And for other cases we could have options like for example:
controller.autoneg.dev/port-names: grpc,http, controller.autoneg.dev/port-names: '["grpc","http"']
controller.autoneg.dev/port: 5990, controller.autoneg.dev/ports: '["5990","8080"']

Erik I think that's a great idea! Users can still manually set the cloud.google.com/neg and controller.autoneg.dev/neg annotations as they like.


Helm Chart

Thanks for creating this project!
It would be helpful to have a helm chart to make this easy to install. I've created a first pass at one in the kubernetes/charts repo as an incubator project: https://github.com/kubernetes/charts/pull/2708
Just creating this issue for your visibility.

Good idea, thanks!

I subscribed to the other ticket.


remove CounterpartyHops function, add GetChannelConnection

Description
In order complete 640, ChanOpenTry needs to remove setting of the channel. This will occur after the application callback in the message server. CounterpartyHops takes in the channel as an argument, but this is unnecessary. In general the CounterpartyHops function was unnecessary, so I removed it and replaced it with direct calls to the counterparty connection ID.
ICS27 needs access to both connection IDs and it was using CounterpartyHops so I added a function which returns the connection ID and connection state associated with a channel. I'm surprised we didn't have this function before
ref: #640

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md)
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards.
[ ] Wrote unit and integration tests
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added relevant godoc comments.
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer
[ ] Review Codecov Report in the comment section below once CI passes

Codecov Report

Merging #644 (e31c84d) into main (2273ef3) will increase coverage by 0.02%.
The diff coverage is 47.22%.

@@            Coverage Diff             @@
##             main     #644      +/-   ##
==========================================
+ Coverage   79.51%   79.54%   +0.02%
==========================================
  Files         146      146
  Lines       10668    10653      -15
==========================================
- Hits         8483     8474       -9
  Misses       1762     1762
+ Partials      423      417       -6

Impacted Files
Coverage Δ

modules/core/04-channel/keeper/keeper.go
86.38% <0.00%> (-4.24%)
:arrow_down:

modules/core/04-channel/keeper/handshake.go
90.72% <66.66%> (+3.31%)
:arrow_up:

...interchain-accounts/controller/keeper/handshake.go
82.08% <71.42%> (-1.01%)
:arrow_down:

...ps/27-interchain-accounts/host/keeper/handshake.go
82.35% <71.42%> (-0.99%)
:arrow_down:

modules/core/04-channel/keeper/timeout.go
93.04% <100.00%> (+1.51%)
:arrow_up:


Error in $: key "tx" not present

In the last commit 87b8d4c xrtd crushes with the error
Error] Error in $: key "tx" not present @(robonomics-tools-<IP_ADDRESS>-KbiD1JtHv6FQGuxvRWSFI:Network.Robonomics.InfoChan src/Network/Robonomics/InfoChan.hs:55:28)

on every demand or offer message

@Vourhey Could you try again with latest commit?

On incoming Demand and Offer there are the following errors
[Warn] Unable to parse msg: "{\"model\": \"Qmf9CdcoCb7Z1NCnKSE8jtJtZpudKY8d57EepKbc4eVcH9\", \"objective\": \"QmcbZrAzymM5xaNR8skt7nz6j9fuPo8mttJ2HRKkMUbzb6\", \"token\": \"0x5822dA6c600c1762568a0697FAc51D5F41038BF7\", \"cost\": 0, \"validator\": \"0x0000000000000000000000000000000000000000\", \"lighthouse\": \"0xD40AC7F1e5401e03D00F5aeC1779D8e5Af4CF9f1\", \"lighthouseFee\": 0, \"deadline\": 9000000, \"sender\": \"0x185d6DE7c6F6b63b935C6316f2a079f5B9bB0fF3\", \"signature\": \"844f6d1d62a3b8f6d72a0ac85cd02b839e51f5fd38c62a90d70dd8ba9cc553c134aa039ac6f9eda92af74a5360123c4a71047c8c7614faa1535b03205025e0bc1c\"}" : Error in $: key "liability" not present @(robonomics-tools-<IP_ADDRESS>-KbiD1JtHv6FQGuxvRWSFI:Network.Robonomics.InfoChan src/Network/Robonomics/InfoChan.hs:53:28)
[Warn] Unable to parse msg: "{\"model\": \"Qmf9CdcoCb7Z1NCnKSE8jtJtZpudKY8d57EepKbc4eVcH9\", \"objective\": \"QmcbZrAzymM5xaNR8skt7nz6j9fuPo8mttJ2HRKkMUbzb6\", \"token\": \"0x5822dA6c600c1762568a0697FAc51D5F41038BF7\", \"cost\": 0, \"lighthouse\": \"0xD40AC7F1e5401e03D00F5aeC1779D8e5Af4CF9f1\", \"validator\": \"0x0000000000000000000000000000000000000000\", \"validatorFee\": 0, \"deadline\": 9000000, \"sender\": \"0x185d6DE7c6F6b63b935C6316f2a079f5B9bB0fF3\", \"signature\": \"dbc3d0a27ad434db506bd672e639f4821079457e6899fa8e33e76bdda980846175d4860686291c9d05d9b36cf97b272169d93576d1a745e403b6f3d4e9a65e741c\"}" : Error in $: key "liability" not present @(robonomics-tools-<IP_ADDRESS>-KbiD1JtHv6FQGuxvRWSFI:Network.Robonomics.InfoChan src/Network/Robonomics/InfoChan.hs:53:28)

robonomics_comm 1.0.0

For supporting feedback feature into robonomics_comm should be added update, described at https://github.com/airalab/aira/commit/d7525ab98bcbce33e135696215e484fa312b12f6
@Vourney could you do it?

I can't test liability being created since on the airalab lighthouse there is a sleeping provider https://dapp.robonomics.network/#/lighthouse/airalab.lighthouse.5.robonomics.eth all the time
But I see no more [Warn] messages


⚠ ClamAV has degraded performance

In 264489f, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 63 ms

Resolved: ClamAV performance has improved in 2d8d26a.


Stirling PDF 0.30.1: uncorrect visualization on firefox (latest version)

Installation Method
Local Installation
The Problem
I tried to launch Stirlin PDF 0.30.1on 3 different browser (all at their latest version) under Win 11 24H2 and the result is reported in the attached images.
As you can see: Google Chrome & MS Edge are OK, while an uncorrect visualizazion is present in Mozilla Firefox
Google Chrome

Mozilla Firefox

Microsoft Edge

Regards,
Leopoldo Saggin aka Topoldo
Version of Stirling-PDF
0.30.1
Last Working Version of Stirling-PDF
0.29.3
Page Where the Problem Occurred
No response
Docker Configuration
No response
Relevant Log Output
No response
Additional Information
No response
Browsers Affected
Firefox
No Duplicate of the Issue

[X] I have verified that there are no existing issues raised related to my problem.

Works fine for me, are you sure this is not a cache issue? can you do a hard reload?