Very high CPU usage

I mentioned this on Slack as well, anyway I thought I'd open an issue about it. I am testing many things at the moment, including various things concerning Longhorn. I really like Longhorn, but I am having a big issue with CPU usage when using volumes with actual data. One of my tests is copying around 25 GB of mixed data (small files, large videos) to a volume used by a Nextcloud installation, so I can test things with real data. I am downloading this data from another server with SSH+tar, and each time I do this test load average climbs to the 10s (right now it's at around 30). I have tried also restoring the same data from a Velero/Restic backup, and again the load goes up quite a lot quite quickly.
I am evaluating storage options while I learn Kubernetes for a project I had started to work on, but while like I said I like Longhorn a lot (especially the built in backups and the great UI), this problem makes it difficult for me to actually use it. So my question is, is it just me or does it happen to others?
At the moment I am testing with Hetzner Cloud servers with 4 cores and 16 GB of ram, but I have tested also with UpCloud servers which are the fastest I have found (especially storage), so I don't think it's an issue with the performance of the servers even though of course there are differences between providers.
Any idea on what could cause this high CPU issue and how to solve it? Exactly the same tests work fine without particular problems if I use OpenEBS - in this case the load doesn't go above 5-10 max even when copying large files).
Thanks in advance!

We have some fixes for it but wasn’t able to make into v0.5.0 release. Some performance improvement and lower CPU utilization should be in the v0.6.0 release. And we will have ability to QOS the volume later as well. So you can control how much CPU/how much IOPS you want to assign to the volume.

Thanks, looking forward to these fixes.

I still have very high CPU Loads after updating to 0.6.1 ...
OS: Ubuntu Server 18.04
Docker: 19.03.2
If I shutdown the longhorn docker ressources the load is coming down immediately.
In the OS you see a lot of Context Switches and Interrupts made by longhorn and calico.
Will you have a look on that? Do you need additional informations?

@sybnex Yeah, we're looking into it. We're tracking v0.6.1 CPU utilization at https://github.com/longhorn/longhorn/issues/767
Can you provide us the result of
kubectl top node
kubectl -n longhorn-system top pods

And ideally, the docker stats and top output from each node you have.

Here are the first results:
`~$ kubectl top node
NAME           CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
<IP_ADDRESS>   3472m        86%    5712Mi          36%
<IP_ADDRESS>   1980m        99%    1687Mi          21%
~$ kubectl -n longhorn-system top pods
NAME                                        CPU(cores)   MEMORY(bytes)
csi-attacher-5b788cc68-4bslg                4m           7Mi
csi-attacher-5b788cc68-vjjxk                1m           6Mi
csi-provisioner-7b5cc54875-sb9pg            1m           5Mi
csi-provisioner-7b5cc54875-tx92h            4m           8Mi
engine-image-ei-7c102650-frhc6              10m          16Mi
engine-image-ei-7c102650-t9dwr              9m           16Mi
instance-manager-e-8c2cf8c2                 46m          7Mi
instance-manager-e-8f0a01fb                 73m          36Mi
instance-manager-r-183e3e28                 81m          56Mi
instance-manager-r-523854ed                 52m          45Mi
longhorn-csi-plugin-l9t9p                   1m           10Mi
longhorn-csi-plugin-p9fs5                   1m           10Mi
longhorn-driver-deployer-5546f4f466-w7swb   0m           7Mi
longhorn-manager-gd6pm                      61m          40Mi
longhorn-manager-xs862                      20m          31Mi
longhorn-ui-c8cd878-468b5                   0m           3Mi
`

After removing longhorn ... especially the intance-managers:
~$ kubectl top node
NAME           CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
<IP_ADDRESS>   1037m        25%    5398Mi          34%
<IP_ADDRESS>   335m         16%    1549Mi          19%

@sybnex For the issue of v0.6.1 release, check #767 . We found the culprit and fixing it in 0.6.2 release. Leave this issue open for the CPU utilization with the load.

/unstale

Hi,
I forgot to answer .... As soon as I had updated to the latest version ... The CPU load has normalized.
Thx guys!

Hi,
I have Rancher 2.3.5 and installed the longhorn-system Rancher chart with version 0.7.0 of the template. I did this installation on 3 days ago and I have three volumes configured (5, 10 and 50 GB). I initially had 2 replicas for each volume, but then I deleted 1 replica as I thought the high CPU usage was coming from the replica management. The following image shows the CPU usage increase over time on the longhorn-manager pod (:

The only things currently running on this cluster is the Rancher cluster monitoring based on Prometheus (which has its storage on the 50 GB volume).
Is that the CPU usage expected for such a setup? And why does it always increase without changing anything?

@guylabs So the graph is only for the longhorn manager pod? That's interesting. We will expect a higher  CPU on the instance manager pods since it's transferring the data, but not the longhorn-manager pod. Can you show me the result of kubectl -n longhorn-system top pods?

@yasker This is the output of kubectl -n longhorn-system top pods:
❯ kubectl -n longhorn-system top pods
NAME                                        CPU(cores)   MEMORY(bytes)
compatible-csi-attacher-d8bc66556-8k5sg     1m           11Mi
csi-attacher-76876c69cf-4c9gv               1m           11Mi
csi-attacher-76876c69cf-5wnph               1m           9Mi
csi-attacher-76876c69cf-k7xhq               1m           8Mi
csi-provisioner-586d7867bb-626tv            1m           9Mi
csi-provisioner-586d7867bb-j9cw4            1m           13Mi
csi-provisioner-586d7867bb-wbgfp            1m           9Mi
engine-image-ei-ec95b5ad-d76wr              3m           18Mi
instance-manager-e-7b81a471                 10m          87Mi
instance-manager-r-0b6dc4e3                 9m           146Mi
longhorn-csi-plugin-n2bzc                   1m           36Mi
longhorn-driver-deployer-5558df9859-m4drd   1m           10Mi
longhorn-manager-zspvs                      232m         39Mi
longhorn-ui-7fd87bdf76-pkrvk                0m           3Mi

When it reached 70% CPU usage I redeployed the manager and since then the CPU usage dropped. But when looking at the graph, it increases steadily. The blue line was the old manager that reached 70% and the orange line is the new manager averaging at around 15%. It started at 12% and now its already at 17% again after 8 hours. I will monitor it further.

This is the output of kubectl -n longhorn-system top pods:
❯ kubectl -n longhorn-system top pods
NAME                                        CPU(cores)   MEMORY(bytes)
compatible-csi-attacher-d8bc66556-8k5sg     2m           11Mi
csi-attacher-76876c69cf-4c9gv               1m           11Mi
csi-attacher-76876c69cf-5wnph               1m           9Mi
csi-attacher-76876c69cf-k7xhq               1m           8Mi
csi-provisioner-586d7867bb-626tv            1m           9Mi
csi-provisioner-586d7867bb-j9cw4            2m           13Mi
csi-provisioner-586d7867bb-wbgfp            1m           9Mi
engine-image-ei-ec95b5ad-d76wr              3m           19Mi
instance-manager-e-7b81a471                 14m          88Mi
instance-manager-r-0b6dc4e3                 9m           148Mi
longhorn-csi-plugin-n2bzc                   1m           36Mi
longhorn-driver-deployer-5558df9859-m4drd   1m           10Mi
longhorn-manager-v2kmf                      55m          35Mi
longhorn-ui-7fd87bdf76-pkrvk                1m           3Mi

Do you have any update on your side on this?

@yasker The issue is still not resolved in 0.8.0. I still get this high CPU values on the longhorn-manager. Any update on this?

Using 0.8.0, I also have a high CPU usage problem (almost 200% for all Longhorn's processes!)
Note I do have 76 pods and 13 volumes (we're going to have a lot more like around 300), if that matter.

Same error with version 0.7.0 and dropped when pod longhorn-manager redeployed

very critical

We've recently fixed a ticker leak in the master. @meldafrawi can you check if there is a way we can reproduce the issue that long-running manager process taking more and more CPUs over the time?

Still happens in 1.0.0

Im facing same problem, one of longhorn-manager have high CPU usage for a long time, and doesn't see it decrease.
Also provides the output of kubectl -n longhorn-system top pods
[root@izt4n4k5dvd9o0zq2qqj54z ~]# kubectl -n longhorn-system top pods
NAME                                       CPU(cores)   MEMORY(bytes)
csi-attacher-5cc849c8dd-2m47j              1m           9Mi
csi-attacher-5cc849c8dd-8mgt5              2m           15Mi
csi-attacher-5cc849c8dd-fr945              1m           9Mi
csi-provisioner-74557755-56zw5             1m           16Mi
csi-provisioner-74557755-kv7gk             1m           8Mi
csi-provisioner-74557755-zn6xc             1m           7Mi
csi-resizer-686bd4b6d7-686b8               2m           9Mi
csi-resizer-686bd4b6d7-758dg               1m           10Mi
csi-resizer-686bd4b6d7-gjkkz               1m           13Mi
engine-image-ei-eee5f438-k4579             1m           10Mi
engine-image-ei-eee5f438-s57sg             2m           3Mi
engine-image-ei-eee5f438-z7xpl             1m           3Mi
instance-manager-e-47df2e30                5m           43Mi
instance-manager-e-545b093c                10m          45Mi
instance-manager-e-7807de6f                963m         49Mi
instance-manager-r-2e35103c                47m          93Mi
instance-manager-r-9c1f9a82                33m          67Mi
instance-manager-r-c184d5aa                7m           64Mi
longhorn-csi-plugin-5bdbn                  1m           29Mi
longhorn-csi-plugin-cwrzc                  1m           23Mi
longhorn-csi-plugin-dbtmp                  2m           25Mi
longhorn-driver-deployer-cd74cb75b-wrzvl   1m           10Mi
longhorn-manager-5nw2l                     14m          73Mi
longhorn-manager-6phrd                     2m           67Mi
longhorn-manager-xt7kd                     21m          92Mi
longhorn-ui-8486987944-66wjp               1m           3Mi

And a part of logs of Pod instance-manager-e-7807de6f
Jul 10 16:12:47.728560: -><IP_ADDRESS>:10031 P[  0kB]    36980us
Jul 10 16:12:47.948435: -><IP_ADDRESS>:10031 P[  0kB]      379us
Jul 10 16:12:24.732872: -><IP_ADDRESS>:10001 P[  0kB] 24000990us failed
Jul 10 16:12:32.733303: -><IP_ADDRESS>:10001 P[  0kB] 16000564us failed
Jul 10 16:12:40.733502: -><IP_ADDRESS>:10001 P[  0kB]  8000365us failed
Jul 10 16:12:40.733502: -><IP_ADDRESS>:10001 P[  0kB] pending
Jul 10 16:12:24.732872: -><IP_ADDRESS>:10001 P[  0kB] pending
Jul 10 16:12:32.733303: -><IP_ADDRESS>:10001 P[  0kB] pending
[pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa] time="2020-07-10T16:12:53Z" level=error msg="Error reading from wire: EOF"
[longhorn-instance-manager] time="2020-07-10T16:12:53Z" level=debug msg="Process Manager: start getting logs for process pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa"
[longhorn-instance-manager] time="2020-07-10T16:12:53Z" level=debug msg="Process Manager: got logs for process pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa"
[longhorn-instance-manager] time="2020-07-10T16:12:55Z" level=debug msg="Process Manager: start getting logs for process pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa"
[longhorn-instance-manager] time="2020-07-10T16:12:55Z" level=debug msg="Process Manager: got logs for process pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa"
[longhorn-instance-manager] time="2020-07-10T16:12:56Z" level=debug msg="Process Manager: start getting logs for process pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa"
[longhorn-instance-manager] time="2020-07-10T16:12:57Z" level=debug msg="Process Manager: got logs for process pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa"
[pvc-0d3a8007-5f40-4ab8-a26d-ac2e3167480f-e-1d87f72d] time="2020-07-10T16:12:58Z" level=error msg="Error reading from wire: EOF"
[longhorn-instance-manager] time="2020-07-10T16:13:00Z" level=debug msg="Process Manager: start getting logs for process pvc-0d3a8007-5f40-4ab8-a26d-ac2e3167480f-e-1d87f72d"
[longhorn-instance-manager] time="2020-07-10T16:13:01Z" level=debug msg="Process Manager: got logs for process pvc-0d3a8007-5f40-4ab8-a26d-ac2e3167480f-e-1d87f72d"
[longhorn-instance-manager] time="2020-07-10T16:13:01Z" level=debug msg="Process Manager: start getting logs for process pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa"
[longhorn-instance-manager] time="2020-07-10T16:13:01Z" level=debug msg="Process Manager: got logs for process pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa"
[pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa] time="2020-07-10T16:13:06Z" level=info msg="Removing backend: tcp://<IP_ADDRESS>:10030"
time="2020-07-10T16:13:06Z" level=info msg="Closing: <IP_ADDRESS>:10030"
[pvc-0d3a8007-5f40-4ab8-a26d-ac2e3167480f-e-1d87f72d] time="2020-07-10T16:13:06Z" level=info msg="Removing backend: tcp://<IP_ADDRESS>:10000"
time="2020-07-10T16:13:06Z" level=info msg="Closing: <IP_ADDRESS>:10000"
[pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c] time="2020-07-10T16:13:13Z" level=error msg="Error reading from wire: EOF"
[longhorn-instance-manager] time="2020-07-10T16:13:14Z" level=debug msg="Process Manager: start getting logs for process pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c"
[longhorn-instance-manager] time="2020-07-10T16:13:14Z" level=debug msg="Process Manager: got logs for process pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c"
[pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa] time="2020-07-10T16:13:14Z" level=info msg="Connecting to remote: <IP_ADDRESS>:10000"
[longhorn-instance-manager] time="2020-07-10T16:13:15Z" level=debug msg="Process Manager: start getting logs for process pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c"
[longhorn-instance-manager] time="2020-07-10T16:13:15Z" level=debug msg="Process Manager: got logs for process pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c"
[pvc-0d3a8007-5f40-4ab8-a26d-ac2e3167480f-e-1d87f72d] time="2020-07-10T16:13:16Z" level=info msg="Connecting to remote: <IP_ADDRESS>:10030"
[longhorn-instance-manager] time="2020-07-10T16:13:17Z" level=debug msg="Process Manager: start getting logs for process pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c"
[longhorn-instance-manager] time="2020-07-10T16:13:17Z" level=debug msg="Process Manager: got logs for process pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c"
[pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c] time="2020-07-10T16:13:19Z" level=info msg="Removing backend: tcp://<IP_ADDRESS>:10045"
time="2020-07-10T16:13:19Z" level=info msg="Closing: <IP_ADDRESS>:10045"
[pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa] time="2020-07-10T16:13:30Z" level=info msg="Opening: <IP_ADDRESS>:10000"
[pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa] time="2020-07-10T16:13:31Z" level=info msg="Snapshot: <IP_ADDRESS>:10000 2b319147-751a-4c76-b550-dac9cd2f9fe7 UserCreated false Created at 2020-07-10T16:13:31Z, Labels map[]"
time="2020-07-10T16:13:31Z" level=info msg="Snapshot: <IP_ADDRESS>:10060 2b319147-751a-4c76-b550-dac9cd2f9fe7 UserCreated false Created at 2020-07-10T16:13:31Z, Labels map[]"
[pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa] time="2020-07-10T16:13:32Z" level=info msg="Snapshot: <IP_ADDRESS>:10000 2b319147-751a-4c76-b550-dac9cd2f9fe7 UserCreated false Created at 2020-07-10T16:13:31Z, Labels map[]"
[pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa] time="2020-07-10T16:13:34Z" level=info msg="Adding backend: tcp://<IP_ADDRESS>:10000"
time="2020-07-10T16:13:34Z" level=info msg="Start monitoring tcp://<IP_ADDRESS>:10000"
[pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa] time="2020-07-10T16:13:34Z" level=info msg="Set revision counter of <IP_ADDRESS>:10000 to : 0"
[pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa] time="2020-07-10T16:13:34Z" level=info msg="Set backend tcp://<IP_ADDRESS>:10000 revision counter to 0"
[pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c] time="2020-07-10T16:13:34Z" level=info msg="Connecting to remote: <IP_ADDRESS>:10045"
[pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa] panic: runtime error: index out of range [0] with length 0

goroutine 2781167 [running]:
github.com/longhorn/longhorn-engine/pkg/controller.getReplicaDisksAndHead(0xc0004336a0, 0x16, 0xc0004614a0, 0xc000433b60, 0x13, 0x0, 0x0)
	/go/src/github.com/longhorn/longhorn-engine/pkg/controller/rebuild.go:28 +0x4dc
github.com/longhorn/longhorn-engine/pkg/controller.(*Controller).PrepareRebuildReplica(0xc0001c9560, 0xc0004336a0, 0x16, 0x0, 0x0, 0x0, 0x0, 0x0)
	/go/src/github.com/longhorn/longhorn-engine/pkg/controller/rebuild.go:179 +0x3d6
github.com/longhorn/longhorn-engine/pkg/controller/rpc.(*ControllerServer).ReplicaPrepareRebuild(0xc000010158, 0x10a8240, 0xc0007bc1b0, 0xc0007bc1e0, 0xc000010158, 0xc0007bc1b0, 0xc0004d5a58)
	/go/src/github.com/longhorn/longhorn-engine/pkg/controller/rpc/server.go:222 +0x4e
github.com/longhorn/longhorn-engine/proto/ptypes._ControllerService_ReplicaPrepareRebuild_Handler(0xe79940, 0xc000010158, 0x10a8240, 0xc0007bc1b0, 0xc0003a24b0, 0x0, 0x10a8240, 0xc0007bc1b0, 0xc000433680, 0x18)
	/go/src/github.com/longhorn/longhorn-engine/proto/ptypes/controller.pb.go:1774 +0x217
google.golang.org/grpc.(*Server).processUnaryRPC(0xc000001980, 0x10b0680, 0xc0005f6780, 0xc000013200, 0xc0000f0660, 0x189e438, 0x0, 0x0, 0x0)
	/go/src/github.com/longhorn/longhorn-engine/vendor/google.golang.org/grpc/server.go:998 +0x46a
google.golang.org/grpc.(*Server).handleStream(0xc000001980, 0x10b0680, 0xc0005f6780, 0xc000013200, 0x0)
	/go/src/github.com/longhorn/longhorn-engine/vendor/google.golang.org/grpc/server.go:1278 +0xd97
google.golang.org/grpc.(*Server).serveStreams.func1.1(0xc0004dd2a0, 0xc000001980, 0x10b0680, 0xc0005f6780, 0xc000013200)
	/go/src/github.com/longhorn/longhorn-engine/vendor/google.golang.org/grpc/server.go:717 +0xbb
created by google.golang.org/grpc.(*Server).serveStreams.func1
	/go/src/github.com/longhorn/longhorn-engine/vendor/google.golang.org/grpc/server.go:715 +0xa1
[longhorn-instance-manager] time="2020-07-10T16:13:35Z" level=info msg="Process Manager: process pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa error out, error msg: exit status 2"
[longhorn-instance-manager] time="2020-07-10T16:13:35Z" level=debug msg="Process update: pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa: state error: Error: exit status 2"
[pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c] time="2020-07-10T16:13:35Z" level=info msg="Opening: <IP_ADDRESS>:10045"
[pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c] time="2020-07-10T16:13:36Z" level=info msg="Snapshot: <IP_ADDRESS>:10045 1ce403a8-61fa-44ec-baae-12535a8fd551 UserCreated false Created at 2020-07-10T16:13:35Z, Labels map[]"
time="2020-07-10T16:13:36Z" level=info msg="Snapshot: <IP_ADDRESS>:10075 1ce403a8-61fa-44ec-baae-12535a8fd551 UserCreated false Created at 2020-07-10T16:13:35Z, Labels map[]"
[pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c] time="2020-07-10T16:13:36Z" level=info msg="Snapshot: <IP_ADDRESS>:10045 1ce403a8-61fa-44ec-baae-12535a8fd551 UserCreated false Created at 2020-07-10T16:13:35Z, Labels map[]"
[pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c] time="2020-07-10T16:13:36Z" level=info msg="Adding backend: tcp://<IP_ADDRESS>:10045"
time="2020-07-10T16:13:36Z" level=info msg="Start monitoring tcp://<IP_ADDRESS>:10045"
send_msg: fail to write magic version
tgtd: bs_longhorn_request(91) fail to write at 557707264 for 28672
tgtd: bs_longhorn_request(150) io error 0x55b38e32c940 2a -22 28672 557707264, Broken pipe
send_msg: fail to write magic version
tgtd: bs_longhorn_request(91) fail to write at 536870912 for 4096
tgtd: bs_longhorn_request(150) io error 0x55b38e32c940 2a -22 4096 536870912, Broken pipe
[pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c] time="2020-07-10T16:13:45Z" level=info msg="Set revision counter of <IP_ADDRESS>:10045 to : 0"
[pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c] time="2020-07-10T16:13:45Z" level=info msg="Set backend tcp://<IP_ADDRESS>:10045 revision counter to 0"
[pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c] time="2020-07-10T16:13:45Z" level=info msg="Synchronizing volume-head-003.img.meta to volume-head-001.img.meta@<IP_ADDRESS>:10048"
[pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c] time="2020-07-10T16:13:45Z" level=info msg="Done synchronizing volume-head-003.img.meta to volume-head-001.img.meta@<IP_ADDRESS>:10048"
timeout_handler: Timeout request 41667 due to disconnection
tgtd: bs_longhorn_request(91) fail to write at 328925184 for 20480
tgtd: bs_longhorn_request(150) io error 0x55b38e358a10 2a -14 20480 328925184, Success
send_msg: fail to write magic version
tgtd: bs_longhorn_request(91) fail to write at 0 for 4096
tgtd: bs_longhorn_request(150) io error 0x55b38e358a10 2a -22 4096 0, Broken pipe
[pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c] time="2020-07-10T16:16:31Z" level=info msg="Get backend tcp://<IP_ADDRESS>:10045 revision counter 395"
time="2020-07-10T16:16:31Z" level=info msg="Set revision counter of <IP_ADDRESS>:10045 to : 395"
[pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c] time="2020-07-10T16:16:31Z" level=info msg="Set backend tcp://<IP_ADDRESS>:10045 revision counter to 395"
time="2020-07-10T16:16:31Z" level=info msg="WO replica tcp://<IP_ADDRESS>:10045's chain verified, update mode to RW"
time="2020-07-10T16:16:31Z" level=info msg="Set replica tcp://<IP_ADDRESS>:10045 to mode RW"
[pvc-0d3a8007-5f40-4ab8-a26d-ac2e3167480f-e-1d87f72d] time="2020-07-10T16:22:26Z" level=info msg="Connecting to remote: <IP_ADDRESS>:10030"
[pvc-0d3a8007-5f40-4ab8-a26d-ac2e3167480f-e-1d87f72d] time="2020-07-10T16:22:26Z" level=info msg="Opening: <IP_ADDRESS>:10030"
[pvc-0d3a8007-5f40-4ab8-a26d-ac2e3167480f-e-1d87f72d] time="2020-07-10T16:22:26Z" level=info msg="Snapshot: <IP_ADDRESS>:10030 9811450c-60bf-4316-95c6-ccc086d3f507 UserCreated false Created at 2020-07-10T16:22:26Z, Labels map[]"
time="2020-07-10T16:22:26Z" level=info msg="Snapshot: <IP_ADDRESS>:10030 9811450c-60bf-4316-95c6-ccc086d3f507 UserCreated false Created at 2020-07-10T16:22:26Z, Labels map[]"
[pvc-0d3a8007-5f40-4ab8-a26d-ac2e3167480f-e-1d87f72d] time="2020-07-10T16:22:26Z" level=info msg="Snapshot: <IP_ADDRESS>:10030 9811450c-60bf-4316-95c6-ccc086d3f507 UserCreated false Created at 2020-07-10T16:22:26Z, Labels map[]"
[pvc-0d3a8007-5f40-4ab8-a26d-ac2e3167480f-e-1d87f72d] time="2020-07-10T16:22:26Z" level=info msg="Adding backend: tcp://<IP_ADDRESS>:10030"
time="2020-07-10T16:22:26Z" level=info msg="Start monitoring tcp://<IP_ADDRESS>:10030"
[pvc-0d3a8007-5f40-4ab8-a26d-ac2e3167480f-e-1d87f72d] time="2020-07-10T16:22:29Z" level=info msg="Set revision counter of <IP_ADDRESS>:10030 to : 0"
[pvc-0d3a8007-5f40-4ab8-a26d-ac2e3167480f-e-1d87f72d] time="2020-07-10T16:22:29Z" level=info msg="Set backend tcp://<IP_ADDRESS>:10030 revision counter to 0"
[pvc-0d3a8007-5f40-4ab8-a26d-ac2e3167480f-e-1d87f72d] time="2020-07-10T16:22:29Z" level=info msg="Synchronizing volume-head-002.img.meta to volume-head-001.img.meta@<IP_ADDRESS>:10033"
[pvc-0d3a8007-5f40-4ab8-a26d-ac2e3167480f-e-1d87f72d] time="2020-07-10T16:22:29Z" level=info msg="Done synchronizing volume-head-002.img.meta to volume-head-001.img.meta@<IP_ADDRESS>:10033"
[pvc-0d3a8007-5f40-4ab8-a26d-ac2e3167480f-e-1d87f72d] time="2020-07-10T16:23:20Z" level=info msg="Get backend tcp://<IP_ADDRESS>:10030 revision counter 62"
time="2020-07-10T16:23:20Z" level=info msg="Set revision counter of <IP_ADDRESS>:10030 to : 62"
[pvc-0d3a8007-5f40-4ab8-a26d-ac2e3167480f-e-1d87f72d] time="2020-07-10T16:23:20Z" level=info msg="Set backend tcp://<IP_ADDRESS>:10030 revision counter to 62"
time="2020-07-10T16:23:20Z" level=info msg="WO replica tcp://<IP_ADDRESS>:10030's chain verified, update mode to RW"
time="2020-07-10T16:23:20Z" level=info msg="Set replica tcp://<IP_ADDRESS>:10030 to mode RW"
[longhorn-instance-manager] time="2020-07-10T16:28:18Z" level=debug msg="Process update: pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa: state error: Error: exit status 2"
[longhorn-instance-manager] time="2020-07-10T16:29:31Z" level=debug msg="Process Manager: start getting logs for process pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa"
[longhorn-instance-manager] time="2020-07-10T16:30:32Z" level=debug msg="Process update: pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa: state error: Error: exit status 2"
[longhorn-instance-manager] time="2020-07-10T16:34:59Z" level=debug msg="Process Manager: start getting logs for process pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa"
[longhorn-instance-manager] time="2020-07-10T16:35:16Z" level=debug msg="Process update: pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa: state error: Error: exit status 2"
[longhorn-instance-manager] time="2020-07-10T16:37:11Z" level=debug msg="Process update: pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa: state error: Error: exit status 2"
[longhorn-instance-manager] time="2020-07-10T16:40:02Z" level=debug msg="Process Manager: prepare to delete process pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa"
[longhorn-instance-manager] time="2020-07-10T16:40:02Z" level=debug msg="Process update: pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa: state error: Error: exit status 2"
[longhorn-instance-manager] time="2020-07-10T16:40:02Z" level=debug msg="Process Manager: deleted process pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa"
[longhorn-instance-manager] time="2020-07-10T16:40:02Z" level=info msg="Process Manager: successfully unregistered process pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa"
[longhorn-instance-manager] time="2020-07-10T16:40:02Z" level=debug msg="Process update: pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa: state error: Error: exit status 2"
[longhorn-instance-manager] time="2020-07-10T16:40:15Z" level=debug msg="Process Manager: start getting logs for process pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa"
[pvc-0d3a8007-5f40-4ab8-a26d-ac2e3167480f-e-1d87f72d] time="2020-07-11T04:08:09Z" level=error msg="Ping timeout on replica <IP_ADDRESS>:10031 seq= 28022"
time="2020-07-11T04:08:09Z" level=error msg="Retry  1 on replica <IP_ADDRESS>:10031 seq= 28022 size= 0 (kB)"
[pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c] time="2020-07-11T04:08:10Z" level=error msg="Ping timeout on replica <IP_ADDRESS>:10046 seq= 27913"
time="2020-07-11T04:08:10Z" level=error msg="Retry  1 on replica <IP_ADDRESS>:10046 seq= 27913 size= 0 (kB)"
[pvc-2702aa10-4795-4d39-916d-72c50866ea6d-e-795fd18c] time="2020-07-11T04:36:54Z" level=error msg="Ping timeout on replica <IP_ADDRESS>:10046 seq= 28763"
time="2020-07-11T04:36:54Z" level=error msg="Retry  1 on replica <IP_ADDRESS>:10046 seq= 28763 size= 0 (kB)"
[pvc-0d3a8007-5f40-4ab8-a26d-ac2e3167480f-e-1d87f72d] time="2020-07-11T14:05:13Z" level=error msg="Ping timeout on replica <IP_ADDRESS>:10031 seq= 45917"
time="2020-07-11T14:05:13Z" level=error msg="Retry  1 on replica <IP_ADDRESS>:10031 seq= 45917 size= 0 (kB)"

Hope this can help you guys to solve this problem, thanks, and sorry for my bad English.

One of the engine has a panic in this log:
[pvc-e9ad8ad5-cd6e-4cfc-9192-60bb939f5c21-e-114210fa] panic: runtime error: index out of range [0] with length 0

goroutine 2781167 [running]:
github.com/longhorn/longhorn-engine/pkg/controller.getReplicaDisksAndHead(0xc0004336a0, 0x16, 0xc0004614a0, 0xc000433b60, 0x13, 0x0, 0x0)
	/go/src/github.com/longhorn/longhorn-engine/pkg/controller/rebuild.go:28 +0x4dc
github.com/longhorn/longhorn-engine/pkg/controller.(*Controller).PrepareRebuildReplica(0xc0001c9560, 0xc0004336a0, 0x16, 0x0, 0x0, 0x0, 0x0, 0x0)
	/go/src/github.com/longhorn/longhorn-engine/pkg/controller/rebuild.go:179 +0x3d6
github.com/longhorn/longhorn-engine/pkg/controller/rpc.(*ControllerServer).ReplicaPrepareRebuild(0xc000010158, 0x10a8240, 0xc0007bc1b0, 0xc0007bc1e0, 0xc000010158, 0xc0007bc1b0, 0xc0004d5a58)
	/go/src/github.com/longhorn/longhorn-engine/pkg/controller/rpc/server.go:222 +0x4e
github.com/longhorn/longhorn-engine/proto/ptypes._ControllerService_ReplicaPrepareRebuild_Handler(0xe79940, 0xc000010158, 0x10a8240, 0xc0007bc1b0, 0xc0003a24b0, 0x0, 0x10a8240, 0xc0007bc1b0, 0xc000433680, 0x18)
	/go/src/github.com/longhorn/longhorn-engine/proto/ptypes/controller.pb.go:1774 +0x217
google.golang.org/grpc.(*Server).processUnaryRPC(0xc000001980, 0x10b0680, 0xc0005f6780, 0xc000013200, 0xc0000f0660, 0x189e438, 0x0, 0x0, 0x0)
	/go/src/github.com/longhorn/longhorn-engine/vendor/google.golang.org/grpc/server.go:998 +0x46a
google.golang.org/grpc.(*Server).handleStream(0xc000001980, 0x10b0680, 0xc0005f6780, 0xc000013200, 0x0)
	/go/src/github.com/longhorn/longhorn-engine/vendor/google.golang.org/grpc/server.go:1278 +0xd97
google.golang.org/grpc.(*Server).serveStreams.func1.1(0xc0004dd2a0, 0xc000001980, 0x10b0680, 0xc0005f6780, 0xc000013200)
	/go/src/github.com/longhorn/longhorn-engine/vendor/google.golang.org/grpc/server.go:717 +0xbb
created by google.golang.org/grpc.(*Server).serveStreams.func1
	/go/src/github.com/longhorn/longhorn-engine/vendor/google.golang.org/grpc/server.go:715 +0xa1

How many volumes are being attached and used on this node?

Having same problem on LH 1.0

We currently have 3 nodes, and about 20 volumes.
container (1).log

Seeing high CPU usage on longhorn-manager here on 1.0.2 too.

Same problem here on 1.0.2 top process: tgtd.

Same problem too

longhorn-manager is going up to our set limit of 200m and stays there.  Only seems to increase on nodes that are running pods with PVs. If we let it it would eat up to 600m cpu... not sure what to do.

longhorn-manager is going up to our set limit of 200m and stays there.  Only seems to increase on nodes that are running pods with PVs. If we let it it would eat up to 600m cpu... not sure what to do.

@aarlint I guess you want to set a limit for the pod but actually set a request. If you want to limit the max cpu the worload will use, you need to set spec.containers[].resources.limits.cpu.
https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits

@aarlint I guess you want to set a limit for the pod but actually set a request. If you want to limit the max cpu the worload will use, you need to set spec.containers[].resources.limits.cpu.
https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits

I think I was unclear. I am setting a cpu limit and that works... but I’m not sure what I’m throttling when I do.
The default cpu request for longhorn manager is 20m but in our case the longhorn manager takes 500m if/when we don’t set a cpu limit.  Is that normal? What is the longhorn manager doing?

I think I was unclear. I am setting a cpu limit and that works... but I’m not sure what I’m throttling when I do.
The default cpu request for longhorn manager is 20m but in our case the longhorn manager takes 500m if/when we don’t set a cpu limit.  Is that normal? What is the longhorn manager doing?

How many CPU resources the longhorn manager will eat depends on how many volumes and replica in your system. Typically, longhorn managers are responsible for:

Create/Update/Delete the custom resources (CRs. e.g., Longhorn volumes) defined by Longhorn.
Dynamically Launching some Longhorn workloads
Handling volume recurring jobs
......

https://longhorn.io/docs/1.1.0/concepts/#11-the-longhorn-manager-and-the-longhorn-engine
BTW, is there any reason that you need to put a hard CPU limit on longhorn managers?

How many CPU resources the longhorn manager will eat depends on how many volumes and replica in your system. Typically, longhorn managers are responsible for:

Create/Update/Delete the custom resources (CRs. e.g., Longhorn volumes) defined by Longhorn.
Dynamically Launching some Longhorn workloads
Handling volume recurring jobs
......

https://longhorn.io/docs/1.1.0/concepts/#11-the-longhorn-manager-and-the-longhorn-engine
BTW, is there any reason that you need to put a hard CPU limit on longhorn managers?

If I don’t put a hard limit their cpu usage goes up to over 500m which really impacts node performance.  The requested cpu is 20m in the standard install, so I thought they should use much less than 500cpu constantly.

If I don’t put a hard limit their cpu usage goes up to over 500m which really impacts node performance.  The requested cpu is 20m in the standard install, so I thought they should use much less than 500cpu constantly.

20m is the minimum requirement. As I said, the actual resource it will use depends on the volume numbers. I just tried to attach 30 volumes to a node, then the longhorn manager pod on the node eats 300m CPU while other longhorn manager pods use 10m~50m CPU only.
onghorn-manager-2kz6p                      2m           32Mi
longhorn-manager-fx4qq                      297m         33Mi
longhorn-manager-jmdht                      3m           29Mi

But if there is a limited amount of volumes attached to the node, and the longhorn manager pod on the node eats 500m CPU, then something may be wrong. In this scenario, you can generate a support bundle then send it to us.

If this is normal/expected behavior then there isn’t a problem. We weren’t aware longhorn manager’s cpu was tied directly to volume count.

Thanks for your help!

Hi, I still facing this issue, where longhorn manager takes up quite a bit of CPU. Is the current workaround to put a CPU limit?

Hi, I still facing this issue, where longhorn manager takes up quite a bit of CPU. Is the current workaround to put a CPU limit?

No. Longhorn manager pods will eat some CPUs temporarily if there are some operations like attach/detaching coming. Are the longhorn manager pods keeping taking up high CPU? If YES, there may be something wrong.

On node with 10 attachments (no local disk), I'm seeing 600m longhorn-manager usage and 100m instance-manager usage.So a total of 700m or ~70m per attachment. This is on arm64 at 2GHz clock rate.
Is ~70m per attachment about what should be expected? I have to say it does seam rather high since most of the pods which require this attachment use much less than ~70m, so longhorn ends up being the biggest CPU user for my applications.

On node with 10 attachments (no local disk), I'm seeing 600m longhorn-manager usage and 100m instance-manager usage.So a total of 700m or ~70m per attachment. This is on arm64 at 2GHz clock rate.
Is ~70m per attachment about what should be expected? I have to say it does seam rather high since most of the pods which require this attachment use much less than ~70m, so longhorn ends up being the biggest CPU user for my applications.

The processes in the instance manager are the essentials of volume io, 100m for 10 volumes is definitely not enough. Considering the total CPU is 2000m and the further upgrade, 300~400m might be the choice. And as I mentioned, you don't need to set a limit for longhorn managers since most of the time they won't eat lots of CPUs.
The resource requirement investigation (for instance manager):  https://github.com/longhorn/longhorn/issues/1691

In my situation most volumes are pretty much idle, and longhorn-manager uses 6x more CPU than instance-manager on the given node. I don't have either limited. Are you suggesting that longhorn-manager can be limited, and instance-manager should not be? I'm ok with 100m usage, but when longhorn is the majority CPU user cumulatively using almost a core with mostly 0 i, I'm starting to worry about headroom as I add more volumes.

@vaskozl mind sharing a support bundle with us, you can attach it here or send an email to<EMAIL_ADDRESS>with reference to this thread and your cluster environment (cpu, mem, disk type, network, etc, dedicated control plane)

With around 250Mbps read on a volume, we see Longhorn engine using a good full 12 cores of a Xeon E-2288G

Message from syslogd@ns31354176 at Jul 15 18:21:28 ...                                                                                "ns31354176" 18:21 15-Jul-21
 kernel:[2920835.996469] watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [longhorn:1771918]

Transferring the contents of a volume, we're getting system locking by longhorn

@ChipWolf are there replica rebuilds running at the time of the above message?
Can you include the full kernel call trace that was printed after the
 kernel:[2920835.996469] watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [longhorn:1771918]
Should look something like this:
kernel: BUG: soft lockup - CPU#X stuck for Ys! [longhorn:...]
... ...
kernel: Call Trace:
kernel: [...] :
kernel: [...] :
kernel: [...] :

@ChipWolf are there replica rebuilds running at the time of the above message?
Can you include the full kernel call trace that was printed after the
 kernel:[2920835.996469] watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [longhorn:1771918]
Should look something like this:
kernel: BUG: soft lockup - CPU#X stuck for Ys! [longhorn:...]
... ...
kernel: Call Trace:
kernel: [...] :
kernel: [...] :
kernel: [...] :

If I witness it again, I'll grab the logs, we don't aggregate syslog right now. Thanks


Problem with Do While loop in VS Code, but not in Visual Studio, for example

VS Code Version: 1.78.0
OS Version: Windows 10 22H2

Steps to Reproduce:

Just a program that takes user input to add numbers to a vector or display the numbers, amongst others. The function to display the options is called in a do while loop, as well as the switch for the input, which in of itself calls other functions depending on the input.
In VS Code, the display function just keeps going, even if I call the function that ends the program, meanwhile in Visual Studio it just works perfectly.

I'd love to get to the bottom of this, because I really prefer VS Code.
Here's a print of the main function.
Thanks!

VS Code doesn't run your code- this sounds like an issue with your code or your project/system configuration


GPU usage

I'm using a few generated scripts on an EC2 instance of type g4dn.xlarge, with Tesla T4 GPU
When running the workflow from the ComfyUI interface, I see traced in logs:
Device: cuda:0 Tesla T4 : cudaMallocAsync
while if I run the generated python script I see:
Device: cuda:0 Tesla T4 : native
The script produces similar result, but it's a lot slower. I tryied to add --cuda-malloc to the command line, but nothing changes. Any clue?
btw: great extension!

Found a solution: in the python script generated by this extension you need to add import cuda_malloc at the beginning (with some code to verify if it is supported) and move the import torch statement from the beginning to the first line after def main():
It would be useful to generate code already in this form

Found a solution: in the python script generated by this extension you need to add import cuda_malloc at the beginning (with some code to verify if it is supported) and move the import torch statement from the beginning to the first line after def main():
It would be useful to generate code already in this form

i add the code,but the cost time is same with not add


[BUG] Tarkov ground zero url is wrong

Describe the bug
Ground zero map resolves to wrong url.
To Reproduce
Steps to reproduce the behavior:

Go to https://mapgenie.io/tarkov
Click on Ground Zero
It opens https://mapgenie.io/tarkov/maps/factory?map=ground+zero

Expected behavior
Url should be https://mapgenie.io/tarkov/maps/factory?map=ground-zero.
Screenshots

Desktop (please complete the following information):

OS Windows
Browser Firefox
Version 122.0b5

Issue should be fixed in the latest release.
If something does not seem right or isn't working you can always reopen this or post a new issue.


Adapt pandas Copy-on-Write functionality for modin

https://pandas.pydata.org/docs/whatsnew/v2.0.0.html#copy-on-write-improvements
It should be interesting in terms of performance.
The main problem is to enable this option for all processes. At the moment, none of the options can be changed in Modin processes.

Not sure we are able to support all this functionality because Modin treats partitions as immutable objects and we create a new partition in a remote function every time.

Not sure we are able to support all this functionality because Modin treats partitions as immutable objects and we create a new partition in a remote function every time.

For some Modin functions that use several pandas operations in a row in their implementation, this could be useful.

At the moment, none of the options can be changed in Modin processes.

There is a (somewhat peculiar) way, as I said in the pandas 2.0 PR: https://github.com/modin-project/modin/pull/5995#issuecomment-1576166040

At the moment, none of the options can be changed in Modin processes.

There is a (somewhat peculiar) way, as I said in the pandas 2.0 PR: #5995 (comment)

It seems to me that you are talking about a situation where we need to change the value of some option when starting Modin. What if the user needs to change the value after the start? (in the middle of the workload for example)


Retired Garmin activity download endpoints

It looks like the GPX/TCX download endpoints have been deprecated in favor of the “modern” endpoints.
Previously they were:
https://connect.garmin.com/proxy/activity-service-1.0/tcx/activity/%d?full=true
https://connect.garmin.com/proxy/activity-service-1.1/gpx/activity/%s?full=true

But it looks like now they might be:
https://connect.garmin.com/modern/proxy/download-service/export/tcx/activity/%d
https://connect.garmin.com/modern/proxy/download-service/export/gpx/activity/%s

I've the same problem with:
https://connect.garmin.com/proxy/activity-service-1.3/json/activity/XXXXXXXXXXX
but can't find the new modern version


Add script for scalability test

longhorn/longhorn#2598

@meldafrawi please help review this one, and we will plan to have this automated in the future.

This one is ready for merging


Opening of wrong link

I added a post, then clicked on it. Redirected to browser with the respective link. Then I added another post with different link using random, now when I click on this new post it opens in browser with its link,  but now when clicked on previous post it still redirects to the recently added post rather the link of previous post.

@asifali22 I'll check it asap.

Sure, I'm busy these days , if not fixed by next month I'll definitely try to contribute by fixing small bug.

@asifali22 even i found this issue on the demo app but i dont know if its a bug in app or library! Did you implement this lib already? Did you face the issue?

Just solved it.. Here goes my first github full request. LOL

@srujan7 how do you solved it sir? can you explain the logic, or even maybe the code. hehe.

@gregijc It's been merged to the master branch.

@gregijc  Sure! would you like to try it your self? i'll give you a hint.
There is only one src file in java dir. Open it and go to line 202 (If I remember it well). There is an onClickListener. Put a "Toast" inside that method and run the code. See we you get the toast. Click on the various links and again check the toast. Pretty simple.
( p.s. do not call me sir! I'm your age :D )

@LeonardoCardoso how can i get the master branch? i am already using these two:
compile 'org.jsoup:jsoup:1.8.3' // required
compile 'com.leocardz:link-preview:1.2.1@aar'
@srujan7 how do i open file in java dir? i am using android studio..
i'm sorry if i asked some obvious question. i only learned mobile from udacity,and still new in mobile.
thank you before.

No problem
Here is the fine I told you about: https://github.com/LeonardoCardoso/Android-Link-Preview/blob/master/app/src/main/java/com/leocardz/link/preview/Main.java
You can find this file under java dir once you open the project in studio.
Happy learning

@gregijc Yes, it's on the main branch, but I didn't create a new version yet. I'll do it tonight!

@srujan7 i see, thank you so much.
@LeonardoCardoso okay thanks. i'll be waiting for the update. thank you so much once again.

@LeonardoCardoso  Ah please cross check the compiled code when you create the new version. I had no time to create a repo and push the changes so I edited the code in the github editor. Just in case I did a typo.

@srujan7 ok
@gregijc ok

Done!

@LeonardoCardoso  hello i'm using this library recently and i got this issue again. i'm using in chat like whatsapp so when i sent one link it works perfect, when i sent second link then first link also shows preview of second link, i'm not quite sure about if its library or my logic but i find this issue and its already exist here so i thought it might be library. i'm trying to solve this if i will able to do it i'll update here but in case if you can check this issue it will be helpful. thank you.


reset channel message offset in admin

set offset option in admin to allow rewind message consume offset from admin

done


Update e2e-testing.md

Discussed the use of the term 'should' at the start of test names.  Using 'should' at the start of test names is a long standing and accepted standard.  Our guidelines should be more aligned with the tools and frameworks guidelines and recommendations that we use.
Even repeated test names within a test file using 'should' at the start of test names should be considered valid.
The test framework we use implies all test names start with 'it' which makes 'should' coming after 'it' a more readable, expressive, and consistent practice.

This was a deliberate choice to make test descriptions more concise. By re-framing the description to say what a test does, rather than what it should do, you convey the same information with fewer words.
e.g.
it('should show a warning when a malicious transaction is suggested')

versus
it('shows a warning when a malicious transaction is suggested')


when streaming, the connection can time out

I have a very large table in postgres, and if I consume it slowly enough it will time out, reproduce with
var knex = require('knex');
var stream = require('stream');// if on node replace with io-stream
var i = 0;
knex({
  client: 'pg',
  connection: {}
}).raw('select * from generate_series(0, 1000000, 1)').pipe(new stream.Writable({
  objectMode: true,
  write: function(chunk, _, next) {
    console.log(++i);
    setTimeout(next, 10);
  }
}));

If I run that with DEBUG=* then eventually I get
5941
5942
  pool2 reap (cur=3, av=3) +10s
  pool2 Attempting to gracefully remove resource (id=0) +1ms
  pool2 Shrinking pool: destroying 1 idle connections +0ms
5943
  pool2 Ungracefully destroying resource (id=0) +7ms
5944
5945
5946
5947
5948
5949
5950
5951
5952
5953
events.js:141
      throw er; // Unhandled 'error' event
            ^
Error: Connection terminated
    at null.<anonymous> (/Users/me/projects/project/node_modules/pg/lib/client.js:184:29)
    at g (events.js:260:16)
    at emitNone (events.js:67:13)
    at emit (events.js:166:7)
    at Socket.<anonymous> (/Users/me/projects/project/node_modules/pg/lib/connection.js:66:10)
    at emitOne (events.js:77:13)
    at Socket.emit (events.js:169:7)

Looking at the node-postgres code, it is clear that this error is the result of a connection explicitly ending: https://github.com/brianc/node-postgres/blob/v4.3.0/lib/client.js#L175-L189
This would not be something under the purview of knex or pool2; you will likely need to investigate your network or database configuration, and/or verify there's no separate process potentially killing connections (pg_terminate_backend, for example)
It does look like we're missing an error binding; pg's code apparently moves emitted errors to the query object when they happen on an active query, so we'll need to bind a handler there to prevent crashes when checking a resource out.

Apparently node-postgres emits errors on the query object when there is a query active, so the error binding on the client object is insufficient. Thanks pg. I'm not even sure where to bind that handler after reading the docs.

So I suspect though that connection is being closed by knex or pool2, notice earlier around 5942 where pool2 attempts to reclaim the connection, i belive the unhangled error is just a symptom

I rewrote my comments above a few times but that is already ruled out; pool2 cannot reclaim a connection that's "checked out" / idle; the log messages above are just routine cleanup of other resources that had been allocated and were cleaned out of the pool while the above was happening.

brianc set me straight about pg's behavior: https://github.com/brianc/node-postgres/issues/795#issuecomment-106837842
So it appears that the "stream mode" call to pg is missing an error handler somewhere. Presumably it's not using the callback interface, since then it wouldn't be streaming. I do notice here: https://github.com/tgriesser/knex/blob/master/lib/dialects/postgres/index.js#L107-L115
The 'error' event is bound to the stream that gets passed, not directly to the PGQueryStream object, but I thought errors propagated along pipes?

To the matter at hand, another look shows me this: pool2 reap (cur=3, av=3) +10s
Which seems to be indicating that 3/3 resources in the pool are available. Significantly, this includes the resource that should be checked out, because you're using it. Another oversight in the stream handling perhaps?

Think I found the culprit:
https://github.com/tgriesser/knex/blob/master/lib/runner.js#L84-L95
The stream-promise is being returned after the call to Promise.using, meaning that the connection is being cleaned up before the stream query is executed. It should be returning the runner.client.stream call inside of line 93, I think. I'll push a tweak to master shortly and hopefully you can verify that it behaves correctly.

If you could, try this branch and see if it solves your problem? I don't quite want to merge to master since I have no idea where or how to write a test for this in the current structure...

To the other problem, the crash, it does not appear that pipes propagate errors, so we should definitely be binding an error event on the created query object, not on the proxy-stream, but I'm having trouble wrapping my head around all aspects of the flow here so I'm far from certain about how this should be handled.

fix looks good, solves my problem, also as to errers and streams, you are correct they don't propagate errors, usual response is something like
var destStream = getDestStream();
stream.on('error', function(e) {destStream.emit('error, e)}).pipe(destStream);

Glad to hear it. I'm gonna leave this issue open until @tgriesser or someone with fuller knowledge of knex can address the dangling bits.


Issue with connectivity check: DeepL blocking connection when UA isn't specified

Hi Davide, first and foremost, thank you for this beautiful plugin, it's very useful to me.
I've been using this for a while now, and for the past several months I've found that whatever query I was writing, I always had "Invalid Notation or No Internet Connection!" message.
I've troubleshooted the problem and turns out that the call you make here returns "HTTP Error 403: Forbidden".
To temporarely solve this, I've added the same user agent you are using for the translation, by replacing this
urllib.request.urlopen("https://www.deepl.com/translator")

with this
headers = {'User-Agent': "Edge, Brave, Firefox, Chrome, Opera"}
url = "https://www.deepl.com/translator"
req = urllib.request.Request(url, headers=headers)
urllib.request.urlopen(req)

Hi Davide, first and foremost, thank you for this beautiful plugin, it's very useful to me. I've been using this for a while now, and for the past several months I've found that whatever query I was writing, I always had "Invalid Notation or No Internet Connection!" message.
I've troubleshooted the problem and turns out that the call you make here returns "HTTP Error 403: Forbidden". To temporarely solve this, I've added the same user agent you are using for the translation, by replacing this
urllib.request.urlopen("https://www.deepl.com/translator")

with this
headers = {'User-Agent': "Edge, Brave, Firefox, Chrome, Opera"}
url = "https://www.deepl.com/translator"
req = urllib.request.Request(url, headers=headers)
urllib.request.urlopen(req)

Hey bro! thank you so much for this code. I've been looking for this.

Hi Marco, thank you so much for your support :)
It’s important to always specify a User Agent when a request is made, it was my oversight. As soon as I have time, I will apply the fix and update the release.
Leave the issuee open, I will close it once resolved.

Hi, sorry again for the delay. I updated the plugin, it seems to work now, could you try it?

Hi, sorry again for the delay. I updated the plugin, it seems to work now, could you try it?

Hi Davide, I've just tried the new version, and it worked fine. Thank you for the support and the effort. 👏


empty types when repeating merlin-type-enclosing on Emacs

I sometimes (and I still couldn't find the exact pattern) get empty types when repeating merlin-type-enclosing (C-c C-t) on my Emacs, i.e. it works the first time, but when trying to further expand them, it displays a few empty lines.
I'd like to understand if this is expected (due to some currently lacking feature), or a bug with which I could help. The codebase in question is quite large so it might have to do with that. Also, there are modules and functors inside the file defining the type.
First of all, is there some debugging mode which I could activate to try and obtain more detailed information? Currently I only have an empty merlin-types buffer in my Emacs, and Messages does not display anything either.
Below are two screenshots illustrating it, showing the first and second calls to merlin-type-enclosing on the same expression (I moved the cursor between the screenshots, but it happens even when I don't).

I can provide the code + instructions to reproduce it if useful, but I believe it would be simpler if I just try to reduce the problem to a small set of files beforehand.

This seems to have been fixed in Merlin 2.3, I'm no longer able to reproduce it.


Update binding-value-converters.md

Just a few grammar edits to improve readability. Thanks for the great documentation!

@dlo83  Thank you for contributing this pull request! We're truly excited and honored to have you as a member of our community. We look forward to working together with you to further build the Aurelia platform.
We noticed that you haven't yet signed our CLA. We would appreciate it if you would consider doing that for us. Before signing, please take a few minutes to read our contributing guidelines. These guidelines will help get you up to speed on how our community likes to operate and how the pull request process works. Once you have read that, assuming you are in agreement, simply sign our online CLA.
After you've signed, please ping this issue to let us know and we'll get your improvements to the docs merged in.
Thank you again!
The Aurelia Team

@EisenbergEffect Signed the CLA

Excellent. Thank you!


chore: [WIP] View layer based titling and breadcrumbing

TBD
Briefly:
Removes titling and breadcrumbing out of the routing layer and into the view layer.

Every "Route/View Component" should be wrapped in a RouteView (similar to RouterView being a 'marker' for a child route)
Every "application page" should be wrapped in an AppView, here you can add breadcrumbs or not (or specify that you shouldn't have breadcrumbs at all with [])
Anything that amends the title should use AppTitle, which along with RouteView provides HTML titling and a11y route announcing.

The current PR only implements this in Meshes, Services and a bit of Zones for PoC purposes.
Overall this means that titling and breadcrumb are no longer tied to the top parent App.vue in a large nested routing structure, and means that App.vue doesn't necessarily need to be at the absolute top level of the routing structure in order to be able to add titles and breadcrumbs. It's almost an inheritance vs composition shift.
There's possibly a good little bit I would tweak before PRing this properly, but putting it up for initial 👀 and for folks to try out, and I'll probably rewrite this desc at that point.

As I understand it, there are two primary motivations flowing into this PR:

Detaching logic from App.vue (i.e. the component rendered via app.mount) and moving it into a top-level place of our routing structure where we can have better control over what stuff we initialize by that routing structure being in play or not

Changing the handling of breadcrumbs and document titles

I think these two things should’ve been kept separate. We need the first aspect to get a better handle on when we run certain code without that happening in App.vue. And I think that first aspect is very much more important than the second. While it’s perhaps not ideal how we currently handle breadcrumbs and the setting of document titles (the latter of which I believe is adequately covered by https://github.com/kumahq/kuma-gui/pull/950), I don’t think aspect 2 is currently important enough to warrant attaching it to the process of addressing aspect 1.
Now, my main question regarding the overall approach in this PR is this: Wouldn’t it be much, much simpler to have AppView be a component with a router-view element at the top of our routing structure? In this place, it could become responsible for things that are specific to Kuma GUI like the initializing logic currently in the bootstrap function while providing us with the freedom of not running such logic by having routes outside the structure holding AppView.
The changes in this PR would force us to always wrap view components in that RouteView/AppView structure and the title and breadcrumbing logic there. This is a lot of overhead compared to the current approach and wouldn’t be necessary if AppView was a component rendered via a top-level route.
In addition the logic for handling route titles and breadcrumbs looks to be significantly more complex compared to the current approach. Does handling titles and breadcrumbs really need this significant of a change? Besides some caveats with breadcrumbs, this logic works pretty well and with https://github.com/kumahq/kuma-gui/pull/950, document titles should work robustly without any caveats.
I can see a potential advantage in the approach in this PR: Breadcrumbs can be customized more individually. One view could have 10 breadcrumb items while a very similar view might have none. This is only possible to some degree with the declarative route record approach. Then again, I don’t recall a unique enough use case that wouldn’t be satisfied by the current approach. So I do wonder whether we will ever need that flexibility.

i. Detaching logic from App.vue (i.e. the component rendered via app.mount) and moving it into a top-level place of our routing structure where we can have better control over what stuff we initialize by that routing structure being in play or not

Can I just confirm this ^ a little. The problem we are solving is removing things from App.vue so it doesn't have to be at a top-level place - it can be for Kuma, but not for other things.
Elsewhere it will have other routes above it, and if breadcrumbs and titling is dealt with in Kuma's App.vue as a child, then the parent routes don't have access to the same breadcrumbing and titling utils (which leads to us writing problematic code that doubles up the logic and means things like setting the title is happening twice via code in 2 different parts of the application)
Can I just confirm that you follow that we are making it so Kuma's App.vue doesn't have to be at the top-level place of our routing structure as your first point says (or maybe I misunderstood what you were saying?)

Can I just confirm this ^ a little. One of the problems we are solving is removing things from App.vue so it doesn't have to be at a top-level place - it can be for Kuma, but not for other things.
Elsewhere it will have other routes above it, and if breadcrumbs and titling is dealt with in Kuma's App.vue as a child, then the parent routes don't have access to the same breadcrumbing and titling utils (which leads to us writing problematic code that doubles up the logic and means things like setting the title is happening twice via code in 2 different parts of the application)
Can I just confirm that you follow that we are making it so Kuma's App.vue doesn't have to be at the top-level place of our routing structure as your first point says (or maybe I misunderstood what you were saying?)

That was not what I took away from our previous conversations. Rather it was this:
A new component (AppView, AppPage, something like that) is created which forms the top level route record of our current routes (having most of our current routes as children). That component would then isolate things that are specific to Kuma GUI from components rendered above it. App would remain in its place and would also remain responsible for breadcrumbs and similar duties as they’re always needed, not just for things specific to Kuma GUI. AppView however, being more specific and deeper in the route tree, could take on responsibilities like fetching data that only is necessary in a specific Kuma GUI context.

🤔
The first line of the issue for this says:

Moving Kuma's App.vue to be a child

So that is the opposite of what you said in your last comment:

App would remain in its place

I also noticed the same issue says:

an AppPage.vue component with breadcrumbing functionality would mean we can wrap View/Route components with the same AppPage.vue component without relying on App.vue.

I think we need to get on the same page here, shall we catch up for a chat?

Ok so I'm picking this back up again, and whilst it could help us achieve:

Detaching logic from App.vue (i.e. the component rendered via app.mount) and moving it into a top-level place of our routing structure where we can have better control over what stuff we initialize by that routing structure being in play or not

..this PR should be seen solely as

Changing the handling of breadcrumbs and document titles

I've already done Zones here, but I'm going to wait until https://github.com/kumahq/kuma-gui/pull/1017 has gone in and rebase this and redo zones following the changes in https://github.com/kumahq/kuma-gui/pull/1017
I may add some further comments here, or edit the description following the latest updates here, just wanted to note that this is continuing to be worked on.

@kleinfreund just thought, is the change in #1025 (the extra div) still necessary if we are wrapping everything in a <RouteView> now? I wasn't quite sure what that fix was for?

What matters is that the root element of the application has a single node. How that is achieved doesn’t matter. So is RouteView ensures there is one node, App.vue doesn’t need another one.

So is RouteView ensures there is one node, App.vue doesn’t need another one.

Awesome, I'm glad wrapping all our Route components in an additional component solves more problems than just this one.
I'm gonna add a commit to remove this div then

Ok @kleinfreund I think all your comments are addressed, I'm just waiting for green incase, but let me know if there are any other comments here ty!

I just added 2 more things here for reasons, should be fine but wanted to ping incase @kleinfreund see last 2 commits (plus snapshot commit)
Waiting for things to go green again


 I was unable to reproduce this issue using the master branch or npm version 0.8.6.
My config for comparison.
.podrc
{
    "root": "/path/to/pod",
    "node_env": "development",
    "default_script": "app.js",
    "apps": {
        "microservice": {
            "port": 4000,
            "PORT": 4000,
            "script": "/path/to/pod/apps/microservice/index.js"
        }
    },
    "web": {
        "username": "username",
        "password": "password"
    }
}

index.js
var http = require('http')

console.log("listening to http requests @ port "+process.env.PORT)
console.dir(process.env)
var router = function(req,res) {
  res.end()
}

http.createServer(router).listen(process.env.PORT)

output
// bunch of sensitive info.
// It does include PORT: '4000'

Environment:
node --version => v5.1.0
pod => 0.8.6 (or master)
pm2 --version => 0.12.16

Update: I was also able to run this environment using your alpine docker image. With the only change being replacing /srv/apps/microservice/index.js with the index.js of my previous post.

listening to http requests @ port 4000

Interesting: this morning i restarted the docker again, and now it works.
Either this is human error, or maybe a pm2 state-related error (because technically pm2 is using the config to start the process right?).
I'll re-open this issue whenever this occurs again.


Add multi-gpu GNN link pred example

Hi @Kh4L, thanks for this. However, for similar reasons as described in https://github.com/snap-stanford/relbench/pull/138#issuecomment-2254249651, I am closing the PR.


[catalog-backend-module-okta] Export extensions

Exports plugin extension points in catalog-backend-module-okta. Also added imports to the example in the README.md
Unless I was missing an export somewhere else, these are needed for examples and I believe intended to be exported?
:heavy_check_mark: Checklist

[ ] Added tests for new functionality and regression tests for bug fixes
[x] Added changeset (run yarn changeset in the root)
[ ] Screenshots of before and after attached (for UI changes)
[x] Added or updated documentation (if applicable)

Missed the export under new-backend that was made more apparent here


Get Sleep Data crashes application

Hello, I noticed there is a new version (0.11.0) which includes support for getting google fit sleep data. I am trying to get it working, but did not manage yet. Nevertheless, I am successfully using getDailyStepCount, for instance.
I tried simply
const options = {
    endDate: new Date().toISOString(),
    startDate: moment(new Date()).subtract(2, 'day').toISOString(),
  };

  const sleepPromise = GoogleFit.getSleepData(options);

  if (!sleepPromise) {
    return;
  }

  sleepPromise.then((res) => console.log(res));
	.catch((error) => { console.warn(error); });

And also using the callback parameter
const options = {
    endDate: new Date().toISOString(),
    startDate: moment(new Date()).subtract(2, 'day').toISOString(),
  };

  const sleepPromise = GoogleFit.getSleepData(options, (isError, result) => {
    console.log('sleep result', isError, result);
  });

The following exception appears in logs:
FATAL EXCEPTION: main
    com.facebook.react.bridge.ObjectAlreadyConsumedException: Map already consumed
        at com.facebook.react.bridge.WritableNativeMap.putString(Native Method)
        at com.reactnative.googlefit.SleepHistory.processDataSet(SleepHistory.java:132)
        at com.reactnative.googlefit.SleepHistory.access$000(SleepHistory.java:67)
        at com.reactnative.googlefit.SleepHistory$2.onSuccess(SleepHistory.java:110)
        at com.reactnative.googlefit.SleepHistory$2.onSuccess(SleepHistory.java:90)
        at com.google.android.gms.tasks.zzn.run(Unknown Source:4)

Could you please guide me to successfully use this functionality? Appreciate any suggestion.

I will take a look at the sleep data crashes and see what is happening. The "map already consumed" exception should only occur if we invoke the success or error callback and then after invocation we try to put something to the map. I don't see that being able to happen in the code, but I'll go through it again and see.

I have created a PR (https://github.com/StasDoskalenko/react-native-google-fit/pull/166) that fixes this issue.

@eszlerbianca If you need to get sleep hours working before the above PR is merged you'll just need a two line fix to SleepHistory.java which you can see in the above PR. This line:
WritableMap sleepMap = Arguments.createMap();
Needs to be moved inside the for loop in processDataSet.

Excellent, thanks for the suggestion @dethell. Tried it today, the app it's not crashing anymore and it seems to retrieve correctly the sleep data.

This issue can be closed now that PR 166 has merged.


Call hierarchy

add call hierarchy
This can use from https://github.com/ayame113/call-hierarchy .

I will merge this once, but eventually move the implementation to the atom-language client.
Release this will help we implement call-hierarchy in atom-ide-outline.


Android App failed to commission lighting app - Connect hands hake timed out

Problem
On test-event-4 branch, I was testing android example app to commission lighting app and it failed with BLE     : connect handshake timed out, closing ep 0x7a059745f0.
Setup:

Tested with test-event-4 branch.
Android example app was deployed to Pixel XL with Android 8.1.0.
Lighting app was built and ran on Raspberry-PI with ubuntu server.
QR code (to scan with chip android app):

./out/host/obj/src/qrcodetool/bin/qrcodetool generate-qr-code -f a.txt
CHIP:TOO: Executing cmd generate-qr-code

CHIP:TOO: setup_payload_operation_generate_qr_code

CHIP:SPL: Loaded vendorID: 9050
CHIP:SPL: Loaded productID: 65279
CHIP:SPL: Loaded discriminator: 3840
CHIP:SPL: Loaded setupPinCode: 20202021
CHIP:TOO: QR Code: MT:YNJV7PF100KA0648G00

Relevant output from Android example app:
Full log see: device_log.txt
08-03 17:34:40.412   956   956 D CTL     : newDeviceController() called
08-03 17:34:40.412   956   956 D TOO     : KVS: Getting key ExampleOpCredsCAKey
08-03 17:34:40.412   956   956 D TOO     : KVS: Getting key afeng ExampleOpCredsCAKey
08-03 17:34:40.412   956   956 D TOO     : KVS: Getting key error 0
08-03 17:34:40.412   956   956 D TOO     : KVS: Getting key ExampleOpCredsICAKey
08-03 17:34:40.412   956   956 D TOO     : KVS: Getting key afeng ExampleOpCredsICAKey
08-03 17:34:40.412   956   956 D TOO     : KVS: Getting key error 0
08-03 17:34:40.413   956   956 D IN      : TransportMgr initialized
08-03 17:34:40.413   956   956 D DIS     : Init admin pairing table with server storage
08-03 17:34:40.413   956   956 D TOO     : KVS: Getting key CHIPAdmin0
08-03 17:34:40.413   956   956 D TOO     : KVS: Getting key afeng CHIPAdmin0
08-03 17:34:40.413   956   956 D TOO     : KVS: Getting key error 0
08-03 17:34:40.413   956   956 D IN      : Loading certs from KVS
08-03 17:34:40.413   956   956 D IN      : local node id is 0x000000000001B669
08-03 17:34:40.413   956   956 D ZCL     : Using ZAP configuration...
08-03 17:34:40.413   956   956 D ZCL     : deactivate report event
08-03 17:34:40.413   956   956 D CTL     : Getting operational keys
08-03 17:34:40.413   956   956 D CTL     : Generating credentials
08-03 17:34:40.413   956   956 D CTL     : Loaded credentials successfully
08-03 17:34:40.413   956   956 D TOO     : KVS: Getting key StartKeyID
08-03 17:34:40.413   956   956 D TOO     : KVS: Getting key afeng StartKeyID
08-03 17:34:40.413   956   956 D TOO     : KVS: Getting key error 0

...

08-03 17:34:44.337   956  1024 D BluetoothGatt: onClientConnectionState() - status=0 clientIf=8 device=DC:A6:32:EC:31:F1
08-03 17:34:44.338   956  1024 I chip.BluetoothManager|onConnectionStateChange: Discovering Services...
08-03 17:34:44.338   956  1024 D BluetoothGatt: discoverServices() - device: DC:A6:32:EC:31:F1

...

08-03 17:34:45.800   956  1024 D BluetoothGatt: onConfigureMTU() - Device=DC:A6:32:EC:31:F1 mtu=131 status=0
08-03 17:34:45.800   956  1024 D chip.BluetoothManager: MTU changed: connecting to CHIP device
08-03 17:34:45.819   956   956 D ChipDeviceController: Bluetooth connection added with ID: 1
08-03 17:34:45.820   956   956 D ChipDeviceController: Pairing device with ID: 2
08-03 17:34:45.820   956   956 D CTL     : pairDevice() called with device ID, connection object, and pincode
08-03 17:34:45.820   956   956 D TOO     : KVS: Getting key ListPairedDevices0
08-03 17:34:45.820   956   956 D TOO     : KVS: Getting key afeng ListPairedDevices0
08-03 17:34:45.820   956   956 D KeyValueStoreManager: Key 'ListPairedDevices0' not found in shared preferences
08-03 17:34:45.820   956   956 D TOO     : KVS: Getting key error 4016
08-03 17:34:45.822   956   956 D IN      : BleConnectionComplete: endPoint 0x7a059745f0
08-03 17:34:45.822   956   956 D CTL     : Received GetMTU
08-03 17:34:45.822   956   956 D CTL     : Calling Java onGetMTU
08-03 17:34:45.822   956   956 D AndroidChipStack: Android Manufacturer: (Google)
08-03 17:34:45.822   956   956 D AndroidChipStack: Android Model: (Pixel XL)
08-03 17:34:45.822   956   956 D CTL     : Received SendCharacteristic
08-03 17:34:45.822   956   956 D CTL     : Calling Java SendCharacteristic
08-03 17:34:45.824   956   956 D SC      : Assigned local session key ID 3
08-03 17:34:45.824   956   956 D IN      : Message appended to BLE send queue
08-03 17:34:45.824   956   956 D SC      : Sent PBKDF param request
08-03 17:34:45.824   956   956 D TOO     : KVS: Setting key StartKeyID
08-03 17:34:45.846   956  1024 D chip.BluetoothManager: MATTER-3840.onCharacteristicWrite: 18ee2ef5-263d-4559-959f-4f9c429f9d11 -> 0
08-03 17:34:45.846   956  1024 D CTL     : Received SubscribeCharacteristic
08-03 17:34:45.846   956  1024 D CTL     : Calling Java SubscribeCharacteristic
08-03 17:34:45.846   956  1024 D BluetoothGatt: setCharacteristicNotification() - uuid: 18ee2ef5-263d-4559-959f-4f9c429f9d12 enable: true
08-03 17:34:45.875   956   986 D chip.BluetoothManager: MATTER-3840.onDescriptorWrite: 00002902-0000-1000-8000-00805f9b34fb -> 253
08-03 17:34:45.876   956   986 E AndroidChipStack: onDescriptorWrite for 00002902-0000-1000-8000-00805f9b34fb failed with status: 253
08-03 17:34:45.876   956   986 D BLE     : subscribe complete, ep = 0x7a059745f0

08-03 17:35:00.823   956  1019 E BLE     : connect handshake timed out, closing ep 0x7a059745f0
08-03 17:35:00.823   956  1019 E IN      : Failed to establish BLE connection: Ble Error 6021 (0x00001785): Connect handshake timed out
08-03 17:35:00.823   956  1019 D IN      : Clearing BLE pending packets.
08-03 17:35:00.823   956  1019 D CTL     : Received UnsubscribeCharacteristic
08-03 17:35:00.824   956  1019 D CTL     : Calling Java UnsubscribeCharacteristic
08-03 17:35:00.826   956  1019 D BluetoothGatt: setCharacteristicNotification() - uuid: 18ee2ef5-263d-4559-959f-4f9c429f9d12 enable: false
08-03 17:35:00.914   671   865 I nanohub : osLog: [AR_CHRE] still: 49
08-03 17:35:00.915   671   865 I nanohub : osLog: [AR_CHRE] ON => IDLE
08-03 17:35:00.920   671   865 I nanohub : osLog: [AR_CHRE] IDLE => ON
08-03 17:35:01.070   956   986 D chip.BluetoothManager: MATTER-3840.onDescriptorWrite: 00002902-0000-1000-8000-00805f9b34fb -> 0
08-03 17:35:01.070   956   986 D BLE     : Auto-closing end point's BLE connection.
08-03 17:35:01.071   956   986 D CTL     : Received CloseConnection
08-03 17:35:01.071   956   986 D CTL     : Calling Java CloseConnection
08-03 17:35:01.071   956   986 D ChipDeviceController: Closing GATT and removing connection for 1
08-03 17:35:01.071   956   986 D BluetoothGatt: close()
08-03 17:35:01.071   956   986 D BluetoothGatt: unregisterApp() - mClientIf=8
08-03 17:35:01.075   956   986 D ChipDeviceController: Calling onCloseBleComplete()

Relevant output from lighting app
[1628028783.418380][107509:107512] CHIP:DL: Device 7C:A2:E7:D1:DA:A8 (Path: /org/bluez/hci0/dev_7C_A2_E7_D1_DA_A8) Connected
[1628028785.956335][107509:107512] CHIP:DL: BluezCharacteristicAcquireWrite is called, conn: 0xffff8002fb90
[1628028785.958532][107509:107512] CHIP:DL: c1 BluezCharacteristicWriteFD mtu, 517
[1628028785.958747][107509:107512] CHIP:BLE: Write request received debug 0xffff8002fb90
[1628028785.958990][107509:107509] CHIP:BLE: local and remote recv window sizes = 3
[1628028785.959062][107509:107509] CHIP:BLE: selected BTP version 3
[1628028785.959107][107509:107509] CHIP:BLE: using BTP fragment sizes rx 128 / tx 20.
[1628028800.961313][107509:107509] CHIP:BLE: receive handshake timed out, closing ep 0xaaaacf09a318
[1628028800.961407][107509:107509] CHIP:IN: Clearing BLE pending packets.
[1628028800.961458][107509:107509] CHIP:BLE: Releasing end point's BLE connection back to application.
[1628028800.961510][107509:107509] CHIP:BLE: Got notification regarding chip connection closure
[1628028802.336948][107509:107512] CHIP:DL: Bluez disconnected
[1628028802.337035][107509:107512] CHIP:DL: Bluez notify CHIPoBluez connection disconnected

Notes
Tested also with chip-tool running on macbook and lighting-app on Raspberry-PI, the commission succeeded.
Proposed Solution
N/A

This is the same as #7078, but for Linux (Bluez).
08-03 17:34:45.875   956   986 D chip.BluetoothManager: MATTER-3840.onDescriptorWrite: 00002902-0000-1000-8000-00805f9b34fb -> 253
08-03 17:34:45.876   956   986 E AndroidChipStack: onDescriptorWrite for 00002902-0000-1000-8000-00805f9b34fb failed with status: 253

253 = 0xFD. In the bluedroid source we can see that this represents Client Characteristic Configuration Descriptor Improperly Configured. I guess we need some Linux platform changes?

Android chip-tool was not working with efr32 at the time of TE4 branch.
#8666 fixed it on master. For TE4 use python controller or chip-tool on your computer

@jmartinez-silabs will the fix for EFR32 also fix lighting-app on Linux? I saw there's some platform specific change for EFR32 in the fix for #8666

@fengli the fix i linked only applies to efr32. I do not know if it is the same issue with linux app

Looking at the code now. Unfortunately I don't have a Linux machine to test on; I ordered a raspberry pi but it will take a couple days to arrive.

Hi, is there any progress with this issue?
I see this still not fixed on Aug 30's master tree.
Thanks.

@Damian-Nordic Do you have any update here?

I meet the same issue, any update on this?

Hi, I tried the following changes yesterday to support BLE notifications on the Linux peripheral side:
diff --git a/src/platform/Linux/bluez/Helper.cpp b/src/platform/Linux/bluez/Helper.cpp
index f784eb56c..8929f12b7 100644
--- a/src/platform/Linux/bluez/Helper.cpp
+++ b/src/platform/Linux/bluez/Helper.cpp
@@ -1227,8 +1227,8 @@ exit:
 static void BluezPeripheralObjectsSetup(gpointer apClosure)
 {

-    static const char * const c1_flags[] = { "write", nullptr };
-    static const char * const c2_flags[] = { "read", "indicate", nullptr };
+    static const char * const c1_flags[] = { "write", "write-without-response", nullptr };
+    static const char * const c2_flags[] = { "read", "indicate", "notify", nullptr };
     static const char * const c3_flags[] = { "read", nullptr };

     BluezEndpoint * endpoint = static_cast<BluezEndpoint *>(apClosure);

Unfortunately, it's not enough and although the processing goes a little bit further, Bluez somehow doesn't deliver the second message to the app. I'm afraid I won't have time to investigate it further this week, but I'm pasting the diff in case someone else has spare time to take a look into that.

not reproduced


Automatically refresh SSL certs before they expire, part 2

For issue #94, Follow up of https://github.com/GoogleCloudPlatform/cloudsql-proxy/pull/142 which was reverted due to some unaddressed comments.

@jellybeanfiend Are you planning on continuing work on this PR?

jellybeanfiend has mentioned they will not be continuing to work on this. I'll find someone internally to pick this back up.


Implement remote computation

To enable remote computation we need to:

[x] select remote file
[x] download it
[x] start a session on the downloaded files
[x] Save pointcloud and DVC run configuration to file and transfer it to the remote
[x] Start computation on remote
[x] Retrieve the results

The first 2 items are implemented in https://github.com/paskino/CIL-work/blob/master/RemoteViewer/TwoLinkedViewersCentralWidgetCompare.py
Last item is done for SLURM remotes in https://github.com/paskino/brem/blob/main/examples/run_dvc_gui.py

Once this is done we should downsample the data on the remote, and only transfer the downsampled version.

[ ] resample file remotely (requires CILViewer to be installed remotely)
[ ] requires https://github.com/vais-ral/CILViewer/issues/162
[ ] save the downsampled data on the session and use it to start a session

[ ] need to crop the file remotely - for registration


Clojure

This was recently released. It adds Clojure support:
https://github.com/arcadia-unity/ArcadiaGodot | http://selfsamegames.com/pages/posts/arcadia-godot.html

Thanks a lot @ryliejamesthomas
We will use this thread for future updates on it.
Great contribution 🥳

@willnationsdev This implements another .Net language - is this some approach that F# could do as well - and it is less tedious and slow, as rewriting all of the current implementation?
@Vivraan Could you please add your famous emoticons? It is 7am here and I dont feel ready for that xD
Thanks 😚

Depending on how it's done, it could be a "surfing" but I'm not sure.
Seems like they use a framework which has also been tested in Unity.

👥🔌🏄🏽♀

Hello yes I can answer some questions:
ClojureCLR is hosted on mono/C# so yes 'surfing'
no plugin/editor enhancements it's just some dlls
feature complete and I don't expect the api to change, but we're missing export to webGL/iOS (expect that to be working in the near future)


Proposal for a text on how we make decisions

After some discussion in the mailing list (see [1] [2] for conclusions, and whole thread [3] [4] for context), I've drafted this proposal which hopefully captures the result of that discussion.
Any feedback is welcome.
[1] https://lists.linuxfoundation.org/pipermail/chaoss/2018-November/000173.html
[2] https://lists.linuxfoundation.org/pipermail/chaoss/2018-November/000186.html
[4] https://lists.linuxfoundation.org/pipermail/chaoss/2018-November/000157.html
[3] https://lists.linuxfoundation.org/pipermail/chaoss/2018-November/000169.html

This is still a bit ambiguous. I would prefer to make it clear that discussions happen in the calls, but that decisions are made on the mailing list.
Maybe a few edits:

(line 69)The basic decision making mechanism for CHAOSS is lazy consensus, which occurs on the relevant mailing list. Each of the software projects or working groups will try to reach consensus on their decisions, after giving a reasonable opportunity to people contributing in them to express their opinion. When a discussion about a decision happens outside of the mailing list in the periodic calls or other communication channels, a proposal for a decision will be sent to the appropriate mailing list(s). The decision should be finalized on the mailing list using lazy consensus after giving people who were not in the discussion time to review, comment, and participate.
(line 71) When the issues under discussion are perceived to be of importance to the whole CHAOSS community, the same process will be carried on at the CHAOSS level, using the general periodic calls and other communication means for discussion with the final decision being made on the mailing list using lazy consensus.

Thanks, Dawn. I fully agree, your redaction is much better. I've added it to the pull request.
I've just added a note about lazy consensus, taking the wording from Apache, just to avoid problems if the link stop working for some reason.

This looks great, thank you!

@GeorgLink, let's thank Apache, I just copied and pasted from their definition, which includes the time frame. And yes, I also think it is a very good idea to specify a reasonable time frame.


Unable to build RHEL9.2 based BareMetal node images using image-builder from RHEL 9.2 host

What happened: Following the Documentation https://anywhere.eks.amazonaws.com/docs/osmgmt/artifacts/#build-bare-metal-node-images, I tried to build node RHEL-based BareMetal node images using image-builder from RHEL 9.2
What you expected to happen: Successfully build the images
How to reproduce it (as minimally and precisely as possible): Follow the documentation and try to build RHEL-based node image from RHEL9.2-based admin host
Anything else we need to know?:

run:

image-builder build --os redhat --hypervisor baremetal --release-channel 1-29 --baremetal-config redhat/bm_rhel9.json --os-version 9 --force

run:

image-builder build --os redhat --hypervisor baremetal --release-channel 1-29 --baremetal-config redhat/bm_rhel9.json --os-version 9 --force --firmware efi

after two weeks of digging, I compiled qemu v6.20 and OVMF.fd from source and got some progress:

image-builder build --os redhat --hypervisor baremetal --release-channel 1-29 --baremetal-config redhat/bm_rhel9.json --os-version 9 --force

Question: Is it ok for ansible-playbook parameters to exist ubuntu_repo=http://us.archive.ubuntu.com/ubuntu ubuntu_security_repo=http://security.ubuntu.com/ubuntu
more detailed log with --ansible-verbosity 6 flag:

Environment:

EKS Anywhere Release: EKS A - 0.20.3
EKS Distro Release: 1-29
image-buider: 0.5.0
host os RHEL 9.2

Thanks for reporting this issue! This issue has been fixed in https://github.com/aws/eks-anywhere/releases/tag/v0.20.7. Kindly download and use the corresponding image-builder CLI. Feel free to re-open this issue if the error persists.

I finally had the time to test the process with the fixed version and can confirm that only the part with --firmware efi was fixed.
Unfortunately, the other points stayed the same. The error again is:

Probably the error is related to the default OpenSSH behavior in RHEL9: https://www.redhat.com/en/blog/openssh-scp-deprecation-rhel-9-what-you-need-know

@pdamianov Yes, this indeed looks like the OpenSSH 9.0+ version incompatibility. OpenSSH 9.0 switched the default mode for scp from legacy mode to sftp mode, and the SSH proxy set up by the Packer Ansible plugin does not handle this correctly.
Can you try running export ANSIBLE_SCP_EXTRA_ARGS="-O" and then retry the image build? This option activates the legacy mode in scp for OpenSSH >= 9
-O Use the legacy SCP protocol for file transfers instead of the
   SFTP protocol. Forcing the use of the SCP protocol may be
   necessary for servers that do not implement SFTP, for
   backwards-compatibility for particular filename wildcard
   patterns and for expanding paths with a ‘~’ prefix for older
   SFTP servers.

@abhay-krishna Thanks a lot for the fast answer. RHEL9.4 comes with the OpenSSH 8.7

Using the env variable:
export ANSIBLE_SCP_EXTRA_ARGS="'-O'"
did the trick.
I can confirm that I successfully built an RHEL9-based image on the RHEL9-based admin machine. To summarize what I did to succeed:

built Qemu 6.2.0 from source and install it (installed missing dependencies):
tar xvJf qemu-6.2.0.tar.xz cd qemu-6.2.0 ./configure make make install
built OVMF.fd from source (installed all missing dependencies):
git clone https://github.com/tianocore/edk2.git cd edk2 git submodule update --init make -C BaseTools OvmfPkg/build.sh sudo cp ./Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd /usr/share/OVMF sudo ln -s /usr/share/OVMF/OVMF.fd /usr/local/share/qemu
added env variable:
export ANSIBLE_SCP_EXTRA_ARGS="'-O'"

@pdamianov Awesome, glad to know that worked. We will add this workaround in the image-building documentation. Also thanks for sharing the steps to build the qemu binary and OVMF from source. Will be helpful to others who face this issue.
May I go ahead and close out this issue now that your image build failures have been resolved?


The argument type 'NyTextField Function(NyTextField)' can't be assigned to the parameter type 'String?'

Trying to use the style parameter of Field to perform an inline style override, I copied the below from the docs:
@override
    fields() => [
        Field("Name",
            style: (NyTextField nyTextField) => nyTextField.copyWith(
                decoration: InputDecoration(
                    labelText: "Name",
                    hintText: "Enter your name",
                ),
            ),
        ),

but get the error:
The argument type 'NyTextField Function(NyTextField)' can't be assigned to the parameter type 'String?'.
I'm new to Flutter and Nylo, so maybe I'm missing something obvious?
I can see that style needs to be a string in ny_form.dart though.. so perhaps your docs are for a future version?? I'm on nylo version 5.32.7
My full form file:
import 'package:flutter/material.dart';
import 'package:nylo_framework/nylo_framework.dart';

class ReminderForm extends NyFormData {
  ReminderForm({String? name}) : super(name ?? "reminder");

  @override
  fields() => [
        Field(
          "Name",
          style: (NyTextField nyTextField) => nyTextField.copyWith(
            decoration: InputDecoration(
              labelText: "Name",
              hintText: "Enter your name",
            ),
          ),
        ),
        Field(
          "datetime",
          cast: FormCast.datetime(
            dateFormat: DateFormat.Hm(),
            initialPickerDateTime: DateTime.now(),
            mode: DateTimeFieldPickerMode.time,
          ),
          dummyData: null,
          style: "compact",
        ),
        Field("notes", cast: FormCast.textArea(), style: "compact"),
      ];
}

Thanks in advance for any advice, and as a dev coming from Laravel - this framework is very cool!

Hey @jeremyj11,
Thanks for the feedback :)
With Nylo v6 around the corner, I've been busy with development but I'll take a look at this when I get chance.

Hey @jeremyj11,
Thanks for the feedback :)
With Nylo v6 around the corner, I've been busy with development but I'll take a look at this when I get chance.

hi @agordn52 , any update about v6 release date ?

Hey @jeremyj11,
Thanks for the feedback :)
With Nylo v6 around the corner, I've been busy with development but I'll take a look at this when I get chance.

hi @agordn52 , any update about v6 release date ?

Live now 🎉🎉

Reopen this if you're still having issues


add japanese localization

localization provided by tonishi

thanks for this contribution! I'll get this out in the next release!


Question: where is System.Media and SystemSounds?

Using WinUI 3 preview and VS preview , I created a project with the "Class Library (WinUI in Desktop)" template and tried to access SystemSounds. But, there does not seem to be any System.Media namespace linked in. For example on the using statement, intellisense did not find Media as a namespace within System. What package do I need to include?

@Austin-Lamb  or maybe @alwu-msft fyi

@Austin-Lamb  or maybe @alwu-msft fyi

Another similar question, again in a "Class Library (WInUI in Desktop)" project:
I have "using Microsoft.UI.Xaml.Input" and the compiler allows the use of the KeyboardAccelerator class; however the ICommand interface is not found. I get CS0246, the type is not found. Yet the docs clearly say it is in Microsoft.UI.Xaml.Input. Again, it looks like I am missing a library or NuGet package, but which one?
What am I missing? Also curious how am I supposed to figure out what package is missing --

Another similar question, again in a "Class Library (WInUI in Desktop)" project:
I have "using Microsoft.UI.Xaml.Input" and the compiler allows the use of the KeyboardAccelerator class; however the ICommand interface is not found. I get CS0246, the type is not found. Yet the docs clearly say it is in Microsoft.UI.Xaml.Input. Again, it looks like I am missing a library or NuGet package, but which one?
What am I missing? Also curious how am I supposed to figure out what package is missing --

Maybe ICommand was not moved from System.Windows.Input to Microsoft.UI.Xaml.Input as the documents claim it was -- ?
Still missing SystemSounds.

Maybe ICommand was not moved from System.Windows.Input to Microsoft.UI.Xaml.Input as the documents claim it was -- ?
Still missing SystemSounds.

See the doc: it's available as platform extension in .NET Core.
You can add the nuget package System.Windows.Extensions.

See the doc: it's available as platform extension in .NET Core.
You can add the nuget package System.Windows.Extensions.

Hmmm, RTFM ... OK so what I take from this is that if the Version dropdown on the class documentation says .NET Platform Extensions 5.0 then I should load the NuGet package whose name matches the DLL shown next to "Assembly". Easy as pie.
Seems to all be linking now. Admittedly I did also upgrade VS, install a new .NET 5 version, and update the projects to 19041 (the templates seem to put in 18362).

Hmmm, RTFM ... OK so what I take from this is that if the Version dropdown on the class documentation says .NET Platform Extensions 5.0 then I should load the NuGet package whose name matches the DLL shown next to "Assembly". Easy as pie.
Seems to all be linking now. Admittedly I did also upgrade VS, install a new .NET 5 version, and update the projects to 19041 (the templates seem to put in 18362).

@sjb-sjb did you solved the issue? If so, can you close this issue, please?

See also #4065.
Thanks for all the help!


How to run unittest on gpu?

I built the project following the guide in ndk on an android devices.(with opencl and neon)
While running the unittest, I found my phone's cpu usage climes while GPU keeps 0%, how to run the code on the gpu of my phone?
my phone's arm: qualcomm snapdragon 835 with opencl.
thanks!

Hi @peteryang1 every phone is different, even those with the same chip, and it may be that OpenCL is not usable in your case.
To run just the GPU tests, and produce a lot of logging messages, so that you can be sure it is running the right test cases, try : ./UnitTests -t Compute_ArmComputeCl -l all
In any case, the Unit Tests will not stress the GPU very much, so it is possible everything is working correctly.

I ran the ./UnitTests -t Compute_ArmComputeCl command, I got
Test setup error: no test cases matching filter or all test cases were disabled
Seems all the unittest are executed in the neon mode.

then I build the unittest only in opencl mode, then I run the convolution test in a long loop, I found all the cpu becomes 100% while gpu stay less than 10% and sometimes turns 0%.
that's why I assume that opencl only runs on cpu.
another reason is that I got a pixel2(also has a chip of qualcomm snapdragon 835) without opencl, the speed of the same conv operation is even faster than the phone with opencl.
looking forward to your help!

Hi @peteryang1 when the OpenCL tests are active, you will get:
./UnitTests -t Compute_ArmComputeCl -l all
Running 290 test cases...
Entering test module "UnitTests"
/home/matben01/gits/devenv/armnn/src/backends/cl/test/ClLayerTests.cpp(28): Entering test suite "Compute_ArmComputeCl"
/home/matben01/gits/devenv/armnn/src/backends/cl/test/ClLayerTests.cpp(35): Entering test case "ConstantLinearActivation"
/home/matben01/gits/devenv/armnn/src/armnn/test/UnitTests.hpp(41): info: check 'The test name does not match the supportedness it is reporting' has passed
/home/matben01/gits/devenv/armnn/src/armnn/test/UnitTests.hpp(44): info: check CompareTensors(testResult.output, testResult.outputExpected, testResult.compareBoolean) has passed

(etc.)
If you are getting "no test cases matching filter", then ArmNN is not configured to support OpenCL.  In this case, check the output from when you run cmake to see if there are any warnings about OpenCL.
Hope this helps,
Matthew

I do get a warning in cmake , but it seems irreverent to opencl, I put my cmake output below:

-- The C compiler identification is Clang 5.0.300080
-- The CXX compiler identification is Clang 5.0.300080
-- Check for working C compiler: /mnt/d/code/armnn-devenv/toolchains/aarch64-android-r16b/bin/aarch64-linux-android-clang
-- Check for working C compiler: /mnt/d/code/armnn-devenv/toolchains/aarch64-android-r16b/bin/aarch64-linux-android-clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /mnt/d/code/armnn-devenv/toolchains/aarch64-android-r16b/bin/aarch64-linux-android-clang++
-- Check for working CXX compiler: /mnt/d/code/armnn-devenv/toolchains/aarch64-android-r16b/bin/aarch64-linux-android-clang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE
-- Boost version: 1.64.0
-- Found the following Boost libraries:
--   unit_test_framework
--   system
--   filesystem
--   log
--   program_options
--   date_time
--   log_setup
--   thread
--   regex
--   chrono
--   atomic
-- Looking for valgrind/memcheck.h
-- Looking for valgrind/memcheck.h - not found
-- Caffe parser support is disabled
-- Tensorflow Lite parser support is disabled
Including backend common library into the build: /mnt/d/code/armnn-devenv/armnn/src/backends/aclCommon/common.cmake
Including backend common library into the build: /mnt/d/code/armnn-devenv/armnn/src/backends/backendsCommon/common.cmake
Including backend into the build: /mnt/d/code/armnn-devenv/armnn/src/backends/cl/backend.cmake
Including backend into the build: /mnt/d/code/armnn-devenv/armnn/src/backends/neon/backend.cmake
NEON backend is disabled
Including backend into the build: /mnt/d/code/armnn-devenv/armnn/src/backends/reference/backend.cmake
Adding object library dependency to armnn: armnnAclCommon
Adding object library dependency to armnn: armnnBackendsCommon
Adding object library dependency to armnn: armnnClBackend
Adding object library dependency to armnn: armnnClBackendWorkloads
Adding object library dependency to armnn: armnnNeonBackend
Adding object library dependency to armnn: armnnRefBackend
Adding object library dependency to armnn: armnnRefBackendWorkloads
Adding object library dependency to UnitTests: armnnAclCommonUnitTests
Adding object library dependency to UnitTests: armnnBackendsCommonUnitTests
Adding object library dependency to UnitTests: armnnClBackendUnitTests
Adding object library dependency to UnitTests: armnnRefBackendUnitTests
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_ANDROID_ARCH_ABI
    CMAKE_ANDROID_STANDALONE_TOOLCHAIN

-- Build files have been written to: /mnt/d/code/armnn-devenv/armnn/build-cl

Hope you can help me find which part I got wrong, thanks!

It seems tf parser's test only uses ref backend, I checked the cl tests, they seems fine.
I'm closing the issue, still thanks @MatthewARM for you help!


doc: type hinting enforcing

This PR enforces type-hinting, as introduced in issue #39 , ensuring that all functions are correctly typed.

Thanks for the PR @GHCamille that's awesome 😃 , it looks good to me there only a few changes to make with respect to the code quality standards! No worry these issues were introduced before you refactored the functions but they fall under the scope of this PR!

Thanks, I honestly didn't understand those errors like it's not even stuff I changed so how come it's not valid 😅 Thank youuu

Coming back to it later - Apparent problem with GHCN data that doesn't seem related to the PR


Drop PHP EOL version support

Update the required PHP version i.e. 8.0 in composer.json and make a new release i.e. v3.1.0.

Fixed with b39bd6e1bd31810a6ced31446331f94bf2f6817c.