Bug: JVM is crashing on startup

Kùzu version
version 0.7.0,0.6.0
What operating system are you using?
Windows 10
What happened?
Hi, I am using
Java: Zulu 11
Windows 10
JVM is crashing on database initialisation call, with msvcp140.dll error
EXCEPTION_ACCESS_VIOLATION
Are there known steps to reproduce?
No response

This seems to be a known OpenJDK issue due to that OpenJDK comes with a different version of msvcp140.dll from the one used to build Kùzu. https://github.com/adoptium/temurin-build/issues/3927
Despite this issue is for Termurin, it seems to also exist in other variants of JDKs such as OpenJDK and Oracle JDK. The workaround is to rename the  msvcp140.dll under JDK directory to something like _msvcp140.dll to prevent it from being used.

This seems to be a known OpenJDK issue due to that OpenJDK comes with a different version of msvcp140.dll from the one used to build Kùzu. adoptium/temurin-build#3927 Despite this issue is for Termurin, it seems to also exist in other variants of JDKs such as OpenJDK and Oracle JDK. The workaround is to rename the msvcp140.dll under JDK directory to something like _msvcp140.dll to prevent it from being used.

@mewim tried, but no luck. Any possibility we can release new version which can work on azul jdk 11

This seems to be a known OpenJDK issue due to that OpenJDK comes with a different version of msvcp140.dll from the one used to build Kùzu. adoptium/temurin-build#3927 Despite this issue is for Termurin, it seems to also exist in other variants of JDKs such as OpenJDK and Oracle JDK. The workaround is to rename the msvcp140.dll under JDK directory to something like _msvcp140.dll to prevent it from being used.

@mewim tried, but no luck. Any possibility we can release new version which can work on azul jdk 11

I do not have a Windows setup right now. Will look into it later.

I have the same problem.

We tried to reproduce the issue on our Windows 11 machine. The issue was reproducible, but the renaming workaround fixed it at our side for both Zulu and Temurin. Our guess is that the operating system you are using also comes with an older version of msvcp140.dll. Can you try to install the latest version here: https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist?view=msvc-170#latest-microsoft-visual-c-redistributable-version and try again with the workaround?

The renaming worked.
It was my mistake. I have multiple Java versions installed and renamed the wrong file.  😅
Is it planned to support the old version of the dll?
The average user of the resulting application usually doesn’t feel comfortable editing dll files.
And it's not so easy to assess what impact this might have on other applications.

It seems that kuzu does not work correctly with VS 2019 (see #4181) so we have to use VS2022, which uses the newest vc-redist package. If we are able to fix #4181 later, we can consider downgrading the toolchain on Windows. But note that Temurin has already included the newer version of DLLs that comes with JDK, and I’d expect other JDK variants to do the same some time, so the problem might be fixed by itself later.

I contacted Azul's support.
They were able to reproduce the issue and are investigating an update for the DLL.
Currently, I am using "Temurin," but even here, the JDK occasionally crashes, e.g., when I want to use the keyword 'IN' in a query.
Example:
conn.query("CREATE NODE TABLE IF NOT EXISTS Person  (" +
        "id STRING PRIMARY KEY, " +
        "name STRING)");

var nameList = new ArrayList<String>();
nameList.add("John Doe");
nameList.add("Jane Doe");

for(var name : nameList) {
    Map<String, Value> params = new HashMap<>();
    params.put("id", new Value(UUID.randomUUID().toString()));
    params.put("name", new Value(name));

    conn.execute("CREATE (p:Person {id: $id, name: $name})", params);
}

Map<String, Value> params = new HashMap<>();
params.put("names", new Value(nameList));

conn.execute("MATCH  (p:Person) WHERE p.name IN $names RETURN p.name", params);

Report:
hs_err_pid212340.log
The JDK also crashes when I use UUID as an attribute type. As soon as I try to create a node with a UUID. (But this is not as important as the issue with 'IN').

I contacted Azul's support. They were able to reproduce the issue and are investigating an update for the DLL.
Currently, I am using "Temurin (jdk-11.0.25+9)" but even here, the JDK occasionally crashes, e.g., when I want to use the keyword 'IN' in a query.
Example:
conn.query("CREATE NODE TABLE IF NOT EXISTS Person  (" +
        "id STRING PRIMARY KEY, " +
        "name STRING)");

var nameList = new ArrayList<String>();
nameList.add("John Doe");
nameList.add("Jane Doe");

for(var name : nameList) {
    Map<String, Value> params = new HashMap<>();
    params.put("id", new Value(UUID.randomUUID().toString()));
    params.put("name", new Value(name));

    conn.execute("CREATE (p:Person {id: $id, name: $name})", params);
}

Map<String, Value> params = new HashMap<>();
params.put("names", new Value(nameList));

conn.execute("MATCH  (p:Person) WHERE p.name IN $names RETURN p.name", params);

Report: hs_err_pid212340.log
The JDK also crashes when I use UUID as an attribute type. As soon as I try to create a node with a UUID. (But this is not as important as the issue with 'IN').

The crash due to use IN keyword and UUID type may be different from the JDK issue and likely due to a bug in kuzu core or the JNI binding. We will look into it.


Use session for requests if multiple requests are made.

Check for multiple requests.
If True then use session.

Fixed with #8


Resource status is not updated when an instance contains lots of resources

Version: main
UI: dev-d9108b4
Commit ID: 9d116c8f71ae63b0724a36fb066284c3817ad5f8
Env:
seal server :  aws EC2 c5.2xlarge (8C16G) Ubuntu 22.04 amd64
kubernetes node server :  aws  EC2 c5.2xlarge (8C16G) Ubuntu 22.04 amd64
Test Steps:

Create an app and add 10 webservice modules.
Create about 8 instances.
Check the resource status.

Test Result:

The resource status were not updated.

Check whether task.resource-status-sync is executed.

2023-04-28T05:07:00.098Z	D	task.resource-status-sync	processed in 97.797389ms
2023-04-28T05:08:00.002Z	I	task.resource-status-sync	cannot get operator of connector<PHONE_NUMBER>92077826: unknown operator: Github
2023-04-28T05:08:00.107Z	D	task.resource-status-sync	processed in 106.9004ms
2023-04-28T05:09:00.002Z	I	task.resource-status-sync	cannot get operator of connector<PHONE_NUMBER>92077826: unknown operator: Github
2023-04-28T05:09:00.094Z	D	task.resource-status-sync	processed in 93.36797ms

Information about the Kubernetes cluster.  AppArmor enabled
Addresses:
  InternalIP:  <IP_ADDRESS>
  Hostname:    node-10
Capacity:
  cpu:                8
  ephemeral-storage:  40458684Ki
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             15908992Ki
  pods:               110
Allocatable:
  cpu:                7800m
  ephemeral-storage:<PHONE_NUMBER>3
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             15282304Ki
  pods:               110
System Info:
  Machine ID:                 ec2da094d58b2e286db1da4fe5ae0898
  System UUID:                ec2da094-d58b-2e28-6db1-da4fe5ae0898
  Boot ID:                    97085a97-d16c-4da2-9772-396390d7c4df
  Kernel Version:             5.19.0-1023-aws
  OS Image:                   Ubuntu 22.04.1 LTS
  Operating System:           linux
  Architecture:               amd64
  Container Runtime Version:  containerd://1.6.8
  Kubelet Version:            v1.25.3
  Kube-Proxy Version:         v1.25.3
PodCIDR:                      <IP_ADDRESS>/23
PodCIDRs:                     <IP_ADDRESS>/23
Non-terminated Pods:          (89 in total)
  Namespace                   Name                                                   CPU Requests  CPU Limits  Memory Requests  Memory Limits  Age
  ---------                   ----                                                   ------------  ----------  ---------------  -------------  ---
  default-myapp-test          ng-59cc69656d-pkfp9                                    100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         9d
  default                     example-deployment-59fc9ccdd-qf6jb                     0 (0%)        0 (0%)      0 (0%)           0 (0%)         21d
  default                     example-deployment-59fc9ccdd-vjlcv                     0 (0%)        0 (0%)      0 (0%)           0 (0%)         21d
  default                     netchecker-agent-hostnet-wm8n8                         15m (0%)      30m (0%)    64M (0%)         100M (0%)      172d
  default                     netchecker-agent-lhjlf                                 15m (0%)      30m (0%)    64M (0%)         100M (0%)      172d
  default                     validate-6fbdfb85f4-sr2zw                              0 (0%)        0 (0%)      0 (0%)           0 (0%)         10d
  kube-system                 calico-node-zrkdc                                      150m (1%)     300m (3%)   64M (0%)         500M (3%)      172d
  kube-system                 coredns-744467c8c7-46vtn                               100m (1%)     0 (0%)      70Mi (0%)        300Mi (2%)     172d
  kube-system                 dns-autoscaler-68d4dbc7b-fmwh2                         20m (0%)      0 (0%)      10Mi (0%)        0 (0%)         172d
  kube-system                 fluentd-elasticsearch-6p8vx                            100m (1%)     0 (0%)      200Mi (1%)       200Mi (1%)     172d
  kube-system                 kube-apiserver-node-10                                 250m (3%)     0 (0%)      0 (0%)           0 (0%)         172d
  kube-system                 kube-controller-manager-node-10                        200m (2%)     0 (0%)      0 (0%)           0 (0%)         172d
  kube-system                 kube-proxy-h54bq                                       0 (0%)        0 (0%)      0 (0%)           0 (0%)         172d
  kube-system                 kube-scheduler-node-10                                 100m (1%)     0 (0%)      0 (0%)           0 (0%)         172d
  kube-system                 metrics-server-6746dc4669-r4nm9                        100m (1%)     100m (1%)   200Mi (1%)       200Mi (1%)     40d
  kube-system                 nodelocaldns-5tt4l                                     100m (1%)     0 (0%)      70Mi (0%)        200Mi (1%)     172d
  kuboard                     kuboard-etcd-r9p6f                                     0 (0%)        0 (0%)      0 (0%)           0 (0%)         52d
  kuboard                     kuboard-v3-664cc56698-vlc99                            0 (0%)        0 (0%)      0 (0%)           0 (0%)         52d
  kuboard                     kuboard-v3-node-10                                     0 (0%)        0 (0%)      0 (0%)           0 (0%)         172d
  local-path-storage          local-path-provisioner-69945974f5-kdhkr                0 (0%)        0 (0%)      0 (0%)           0 (0%)         21d
  seal-system                 seal-opencost-5c89c49475-s68rg                         10m (0%)      999m (12%)  55M (0%)         1G (6%)        52d
  seal-system                 seal-prometheus-kube-state-metrics-6b688468bd-pw6zq    0 (0%)        0 (0%)      0 (0%)           0 (0%)         37d
  seal-system                 seal-prometheus-prometheus-node-exporter-skb5n         0 (0%)        0 (0%)      0 (0%)           0 (0%)         38d
  seal-system                 seal-prometheus-server-5954d54c79-j5w9b                0 (0%)        0 (0%)      0 (0%)           0 (0%)         37d
  sealtest-nginx-ng           n1-bc8774696-dh99l                                     100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         104m
  sealtest-nginx-ng           n10-57d45b8b8d-qrdgh                                   100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         104m
  sealtest-nginx-ng           n11-86d6b8849b-xmgdc                                   100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         104m
  sealtest-nginx-ng           n12-84fbd7d78d-4cwj7                                   100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         104m
  sealtest-nginx-ng           n13-7fdd998664-ds5wr                                   100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         104m
  sealtest-nginx-ng           n14-5f68df7788-m652n                                   100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         104m
  sealtest-nginx-ng           n15-69f65d8dd4-d9s88                                   100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         104m
  sealtest-nginx-ng           n2-5785b676d6-x2kjs                                    100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         104m
  sealtest-nginx-ng           n3-7b6b6995f6-bxn58                                    100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         104m
  sealtest-nginx-ng           n4-688f87857d-mlrrf                                    100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         104m
  sealtest-nginx-ng           n5-764fb7f696-x6v24                                    100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         104m
  sealtest-nginx-ng           n6-77cf95bd5d-bfvns                                    100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         104m
  sealtest-nginx-ng           n7-7bcb5959cb-pd87d                                    100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         104m
  sealtest-nginx-ng           n8-7878c9dd86-6bnw4                                    100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         104m
  sealtest-nginx-ng           n9-57f76dc688-2jt5c                                    100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         104m
  sealtest-testapp-test       nginx-749dc754dd-7kszl                                 100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         17h
  sealtest-websvc-a1          df-6957699757-thf9b                                    100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         65m
  sealtest-websvc-a1          ertwr-64498f7487-h4pcn                                 100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         65m
  sealtest-websvc-a1          et-c548ffc68-wln59                                     100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         65m
  sealtest-websvc-a1          nginx-749dc754dd-bxtcd                                 100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         65m
  sealtest-websvc-a1          sdf-d6c88d7bc-n5w9n                                    100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         65m
  sealtest-websvc-a1          sdfa-744dd488f7-f5ngc                                  100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         65m
  sealtest-websvc-a1          sdfaewt-7676cc559d-dffd2                               100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         65m
  sealtest-websvc-a1          sdfe-6f847d554f-x9c7p                                  100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         65m
  sealtest-websvc-a1          wert-5dc7f8c99b-twwdt                                  100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         65m
  sealtest-websvc-a1          werytr-6b587bcd47-t7j55                                100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         65m
  sealtest-websvc-a2          et-c548ffc68-k7588                                     100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         65m
  sealtest-websvc-a2          nginx-749dc754dd-p5ggs                                 100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         65m
  sealtest-websvc-a2          sdf-d6c88d7bc-fkflz                                    100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         65m
  sealtest-websvc-a2          sdfa-744dd488f7-9md7r                                  100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         65m
  sealtest-websvc-a2          sdfaewt-7676cc559d-5bdkb                               100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         65m
  sealtest-websvc-a2          sdfe-6f847d554f-74rf5                                  100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         65m
  sealtest-websvc-a2          wert-5dc7f8c99b-5hfgx                                  100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         65m
  sealtest-websvc-a2          werytr-6b587bcd47-ngvg2                                100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         65m
  sealtest-websvc-etwt        df-6957699757-wzt99                                    100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-etwt        ertwr-64498f7487-x2j5n                                 100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-etwt        et-c548ffc68-5jgcn                                     100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-etwt        nginx-749dc754dd-xcwln                                 100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-etwt        sdf-d6c88d7bc-xmrcf                                    100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-etwt        sdfa-744dd488f7-hjhnx                                  100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-etwt        sdfaewt-7676cc559d-k9fbr                               100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-etwt        sdfe-6f847d554f-fvfq2                                  100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-etwt        wert-5dc7f8c99b-qgjhs                                  100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-etwt        werytr-6b587bcd47-8nrmh                                100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-test3       nginx-749dc754dd-sbj96                                 100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         16h
  sealtest-websvc-wertq       df-6957699757-8smx4                                    100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-wertq       ertwr-64498f7487-lkp7s                                 100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-wertq       et-c548ffc68-frwkc                                     100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-wertq       nginx-749dc754dd-hctz7                                 100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-wertq       sdf-d6c88d7bc-gwmtd                                    100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-wertq       sdfa-744dd488f7-gjvh8                                  100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-wertq       sdfaewt-7676cc559d-2tvlb                               100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-wertq       sdfe-6f847d554f-7bk4d                                  100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-wertq       wert-5dc7f8c99b-9zx5q                                  100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-wertq       werytr-6b587bcd47-9c29v                                100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-wtyu        df-6957699757-fhwk5                                    100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-wtyu        ertwr-64498f7487-wwwvs                                 100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-wtyu        et-c548ffc68-z6klj                                     100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-wtyu        nginx-749dc754dd-vfvpq                                 100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-wtyu        sdf-d6c88d7bc-fbggt                                    100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-wtyu        sdfa-744dd488f7-gdgvp                                  100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-wtyu        sdfaewt-7676cc559d-54hsg                               100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-wtyu        sdfe-6f847d554f-rpdjm                                  100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-wtyu        wert-5dc7f8c99b-mw2xj                                  100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
  sealtest-websvc-wtyu        werytr-6b587bcd47-c42xb                                100m (1%)     0 (0%)      128Mi (0%)       0 (0%)         143m
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests          Limits
  --------           --------          ------
  cpu                7760m (99%)       1459m (18%)
  memory<PHONE_NUMBER> (61%)<PHONE_NUMBER> (16%)
  ephemeral-storage  0 (0%)            0 (0%)
  hugepages-1Gi      0 (0%)            0 (0%)
  hugepages-2Mi      0 (0%)            0 (0%)
Events:              <none>

Delete some resources. The resource status in seal is not updated until the CPU request is less than 80%.

Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests          Limits
  --------           --------          ------
  cpu                5960m (76%)       1459m (18%)
  memory<PHONE_NUMBER> (46%)<PHONE_NUMBER> (16%)
  ephemeral-storage  0 (0%)            0 (0%)
  hugepages-1Gi      0 (0%)            0 (0%)
  hugepages-2Mi      0 (0%)            0 (0%)

No more valid in the latest version


[NETBEANS-2029] Better handling of installing Gradle Distribution.

Well, this is really needed for the Out of the Box Gradle Experience. Merging now. If someone has issues with this he can still report that later.


[Help wanted] Translate 'welcome-email' function from NodeJS to PHP 🐘

Translate 'welcome-email' function from NodeJS to PHP 🎯
We use Appwrite Cloud Functions demos as a good way to show how Cloud Functions can be used with Appwrite, and also as a good starting point for developers wanting to write their new functions. ☁
Help us translate the cloud function 'welcome-email' from NodeJS to PHP
Requirements 🔎

For testing your code, you need a running Appwrite instance with cloud functions enabled. You’ll need to setup Appwrite from source using the 0.7.x branch and Docker. 🐳
Clone the appwrite/appwrite 0.7.x branch. More instruction about how to start your Appwrite server from source are available here.
 📈

If this is your first PR for Appwrite, it is best to read some of our contributions guidelines.
 ♥

For each target language we provide with a template for starting a new function. For PHP you can use this template as your starting point.

I would like to contribute. Can you brief what all I need to do and is there any resources I can follow to get this done.

Can I work on this?


The app cannot be completely closed

Hi,  after i  used the Vitvov.Maui.PDFView(1.0.6) in my MAUI app，I have found that my app can't be completely closed in Windows 11.
And, I have found the example project have the same problem after you change the pdf page.
Can you give me some help？
Thanks.

Hi,
Can you try 1.0.5 version?

Hi,
I have tried version 1.0.5, but the same issue still persists.

Hi @DavidLiu642874264
I couldn't reproduce the error on my test application on Windows 10. I suspect that this behavior might be related to the unsubscription of resources or subscriptions on the platform side.
To address this, I’ve created a new code branch where I’ve modified the component's behavior. Additionally, I've released a new 1.0.7-alpha version of the package.
Please try the following:
Install the alpha version from the release.
Call DisconnectHandler as demonstrated in the example View and the example code-behind.
<ContentPage
    Unloaded="ContentPage_Unloaded">

    <pdf:PdfView
            x:Name="pdfView"

private void ContentPage_Unloaded(object sender, EventArgs e)
{
   pdfView.Handler?.DisconnectHandler();
}

Unfortunately I can't call this callback myself because of the .Net MAUI architecture, so follow the example from the branch above.
I also recommend cloning the branch and debugging the code on your side if possible. You may be able to pinpoint the cause of the issue. I can't devote too much time to Windows development at the moment, and your help would be really appreciated.
Let me know if this resolves the issue or if the problem persists!

@DavidLiu642874264 any updates?


optimize segment highlighting

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

5 of 5 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 99.546%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
11499

Relevant Lines:
11502

💛  - Coveralls


[bug] crash with symbol lookup error in deb linux package

Describe the bug
$ npx tauri build
✓ built in 2.02s
   Compiling vibe-desktop v0.0.6 (/home/user/Documents/vibe/desktop/src-tauri)
    Finished release [optimized] target(s) in 30.26s
    Bundling vibe_0.0.7_amd64.deb (/home/user/Documents/vibe/target/release/bundle/deb/vibe_0.0.7_amd64.deb)
    Warn The updater bundle target exists but couldn't find any updater-enabled target, so the updater artifacts won't be generated. Please add one of these targets as well: app, appimage, msi, nsis
    Finished 1 bundle at:
        /home/user/Documents/vibe/target/release/bundle/deb/vibe_0.0.7_amd64.deb

$ sudo dpkg -i  /home/user/Documents/vibe/target/release/bundle/deb/vibe_0.0.7_amd64.deb
$ vibe
/usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/WebKitWebProcess: symbol lookup error: /snap/core20/current/lib/x86_64-linux-gnu/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE

Reproduction
Build on linux, install deb file, and start it.
Expected behavior
It should start the app without crash
Full tauri info output
[✔] Environment
    - OS: Ubuntu 22.04 X64
    ✔ webkit2gtk-4.1: 2.42.5
    ✔ rsvg2: 2.52.5
    ✔ rustc: 1.75.0 (82e1608df 2023-12-21)
    ✔ cargo: 1.75.0 (1d8b05cdd 2023-11-20)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (overridden by '/home/user/Documents/vibe/rust-toolchain.toml')
    - node: 20.7.0
    - npm: 10.1.0
    - bun: 1.0.3

[-] Packages
    - tauri [RUST]: 2.0.0-beta.13
    - tauri-build [RUST]: 2.0.0-beta.10
    - wry [RUST]: 0.37.0
    - tao [RUST]: 0.26.2
    - tauri-cli [RUST]: 1.5.9
    - @tauri-apps/api [NPM]: 2.0.0-beta.6
    - @tauri-apps/cli [NPM]: 2.0.0-beta.11

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - framework: React
    - bundler: Vite

Stack trace
No response
Additional context
Source code: https://github.com/thewh1teagle/vibe

Try starting the app from inside a "normal" terminal outside of vscode (I assume that's what's using snap here).
If that doesn't work, try building it outside of it too.
Afaik we can't fix this as long as we're using webkitgtk (or maybe it's more general than that idk)


Only one method per path

Hey @nelsongomes, thank you for the pretty awsome package. It saves a lot of time when defining an open api. The only thing I didn't get is why it isnt possible to define more than one http method per path. Like, why can I have a post and put to the same endpoint?
Thank you

Yes you can,
but the implementation only handles one declaration at the time. So you can
declare a post, and then declare a put.
But not both at the same time, in the same function call.
Maybe that is a thing that needs improvement.
Thanks,
Nelson Gomes
joaovq @.***> escreveu no dia terça, 6/04/2021 à(s)
20:35:

Hey @nelsongomes https://github.com/nelsongomes, thank you for the
pretty awsome package. It saves a lot of time when defining an open api.
The only thing I didn't get is why it isnt possible to define more than one
http method per path. Like, why can I have a post and put to the same
endpoint?
Thank you
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nelsongomes/ts-openapi/issues/9, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAITSRFN2YBBF6VSKC3FLXTTHNPANANCNFSM42PLVVKQ
.

Hey,
I gave it a look and did a fix for it, I was not aware of this bug.
You can have it fixed on package v0.2.11
Give me any feedback you may find.
Thank you for your comment.
Nelson Gomes
joaovq @.***> escreveu no dia terça, 6/04/2021 à(s)
20:35:

Hey @nelsongomes https://github.com/nelsongomes, thank you for the
pretty awsome package. It saves a lot of time when defining an open api.
The only thing I didn't get is why it isnt possible to define more than one
http method per path. Like, why can I have a post and put to the same
endpoint?
Thank you
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nelsongomes/ts-openapi/issues/9, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAITSRFN2YBBF6VSKC3FLXTTHNPANANCNFSM42PLVVKQ
.

@nelsongomes thank you so much for the fix. I will use it right now

It is fixed, can I close this issue?


 Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
File "/usr/local/bin/youtube-dl/youtube_dl/extractor/common.py", line 275, in extract
return self._real_extract(url)
File "/usr/local/bin/youtube-dl/youtube_dl/extractor/eighttracks.py", line 146, in _real_extract
'id': compat_str(track_data['id']),
KeyError: u'id'
Traceback (most recent call last):
File "/usr/local/bin/youtube-dl/youtube_dl/YoutubeDL.py", line 654, in extract_info
ie_result = ie.extract(url)
File "/usr/local/bin/youtube-dl/youtube_dl/extractor/common.py", line 281, in extract
raise ExtractorError('An extractor error has occured.', cause=e)
ExtractorError: An extractor error has occured. (caused by KeyError(u'id',)); please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; type  youtube-dl -U  to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

Duplicate of #5029.


Linux system monitoring, SSH private key problem

Question
测试连接失败
Peer ssh connection failed: No more authentication methods available

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑🤝🧑👫🧑🏿🤝🧑🏻👩🏾🤝👨🏿👬🏿

Question
Test connection failed
Peer ssh connection failed: No more authentication methods available

way1:
flow this url
https://help.aliyun.com/zh/ecs/support/the-disconnected-no-supported-authentication-methods-available-error-occurs-when-you-log-on-to-a-linux-instance-by-ssh
way2:
try to update openssh version


'extends' isn't not a keyword in JSON-schema spec

Currently extends is used for models inheritance in Plank schema.
Pros:

Support of inheritance in schema just makes it easier.

Cons:

It is really "allOf" other than having a base class.

In the generated models, for common methods, it may confuses the complier. I.e,
`Class A :

aStandardMethodWith:(ClassA)obj

Class B : ClassA

aStandardMethodWith:(ClassB)obj
`
This pattern is either explicitly not allowed or behaving unexpectedly in most programing languages.

Its not a standard keyword thus most existing JSON schema validators don't support that, or we have to make/use Plank's own validator tools on both provider-consumer sides.

It may encourages 'polymorphicTypeIdentifier' or similar kind of field in the schema to tell real type of model.

AFAIK, Inheritance isn't supported in most popular model-gen(GraphQL, protoBuf, and etc) tools. I guess the main reasons is that IDL is more for defining constraints on model, not primarily on OOP.
Possible solutions:

support allOf then deprecate extends
This shouldn't lose any property or method from the base class but base class itself.

A new build option to treat extends as allOf
For existing extends  users, they may assume base class of the models, this is a breaking change in that case. A possible workaround is to specify a base class in the build option mentioned above? And users of "extend" would take care of the base class and its compliance in their code base.

I created this issue to capture what @jparise and me discussed a while go.
Your thoughts are appreciated.

I think there are two distinct points here:

The extends keyword is not documented in JSON Schema making Plank divergent from the open specification. Should this be changed and should we enforce its aligned with the open specification?

Plank occasionally has taken liberties with the schema syntax to make our migration to immutable models earlier. The extends keyword was added as well as a few others like polymorphicTypeIdentifier to support ADT types. I don't have a strong opinion around switching to allOf but it likely will open it up to more of a mix-in style schema where you could "inherit" from multiple types which can be powerful but also will change how we consider code generation.
Additionally, there are missing attributes of JSON schema outside of allOfand we should figure out if we should attempt to support these as well. Alternatively, we could also use JSON schema to write a schema definition for what Plank accepts which could be another path forward here.

How should code generation handle cases like allOf or extends? Should inheritance be supported at all or should we migrate towards composing models?

The ObjC generation is the only one I'm aware of that actually uses inheritance. The Java output from what I remember actually flattens the inherited set of properties and I think we can do the same on the ObjC side. We should consider generating protocols for the specific properties on each type (unflattened) though to allow for APIs to be migrated where they specified a base class type.

Thanks @rahul-malik! Very good points.
#1, yep, either subset of or full json-schema spec is a good idea;
#2, I don't think we need inheritance in Plank at all. JSON is not primarily designed for that. I like the idea of flattening properties, as that's what allOf is supposed to do: look up properties till root and flatten them.
allOf is slightly different than extends, which will be flatten and is useful for in abstracting common data without a base class or protocol.
Also, I may misunderstood and i don't think polymorphicTypeIdentifier /ADT has to do with extends or 'allOf'. I thought it is a solution to union(doesn't seem to be valid keyword in json-schema) or oneOf. I don't have strong opinion around that and I think they should continue to work after flattened.
Yeah, migration is always the most difficult part. Usually NSObject should be good enough unless their codebase replies on properties of base class like we do (PIModel 😄 ). I like the idea of generating protocol for extended type but:

that might be overhead in code generating if there're many immediate protocols. Unlikely in real word though.
once we support that, we can't get rid of that.

Having said that, this seems to be the best path moving forward. To summarize:

Support allOfkeyword
Add build option to treat extends as allOf' and also generate protocol for extended` type
Deprecate methods in generated protocols to expedite migration
Remove 'extends` support from Plank and the build option.

I've not looked into source code or java implementation yet. I am more than happy to spend some time on this. Very interesting stuff!


SpeechRecognizer crashes UWP in example app.

When executing the Speech Synthesis sample app and another app I created based on this one, the SpeechRecognizer.RecognizeAsync and RecognizeAsyncWithUI methods cause the app to crash or to return an empty result with 0 seconds duration.
Using: Raspberry Pi 2 with Sabrent USB audio input (only usb audio input on Win 10 IOT Core compatibility list).

I've asked the feature team to investigate.

The feature team reports that they are unable to reproduce the problem on a Dragonboard running the latest Inside build.


Secret must be entire query string of SAS

The current example implies just the 'sig' query param is needed.
In fact the entire query string including expiry dates etc is needed.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 1b7a6124-86bc-bd57-88c6-7c4334c49cd5
Version Independent ID: 1598c673-fb85-3cf7-4ff9-8fdc0e384c68
Content: Examples of Bulk Access to Data in Azure Blob Storage - SQL Server
Content Source: docs/relational-databases/import-export/examples-of-bulk-access-to-data-in-azure-blob-storage.md
Product: sql
Technology: data-movement
GitHub Login: @MashaMSFT
Microsoft Alias: mathoma

@MashaMSFT Hi Masha, Can you please process this Issue 2579. CastleArg believes a code example is incorrect.

Hi @CastleArg ,
Thank you for contacting Microsoft and providing your feedback to our documentation! We'll need some time to look into this further. Depending on the complexity, the turnaround time for this may vary anywhere from a few business days to a few business weeks. We'll reply via comment should we need anything further in the meantime, and please feel free to do the same.
If you're suggesting a simple change to the documentation, it may be faster for you to submit the edit yourself via a Pull Request (PR). You can do so by following these steps:

Navigate to the page of interest
Select the "Edit" button at the top right of the page
Select the "Pencil" icon on the right
Modify the text within the text box in markdown format
Name your file change and copy the link to your Git Issue into the "extended description" box
Select "Propose file change"
Select "Create pull request" on the 'Comparing changes' page
Select "Create pull request" on the 'Open a pull request' page
Wait for an author to review and approve the change request - this can take a bit depending on the complexity

Doing so will allow authors to directly add your text to the documentation. This also displays your github image on the page of authors, and list you as a contributor to the documentation.
Otherwise, we'll continue to research your suggestion, and get back to you as soon as we have more information for you.
Thanks again for your submission, and hope you have a wonderful rest of your day!
Masha from SQL Docs team

Hi @CastleArg , Thanks again for contacting Microsoft!  We've submitted a documentation change based on your suggestion, and it should be live at this point. Please let us know if there is anything more we can do for you? If not, we'll proceed with closing out this Git Issue in a few business days.
Thanks again and hope you have a great weekend!
Masha from SQL Docs team


OpenCL GPU acceleration for mxnetOnACL

When trying mxnetOnACL and caffeOnACL on my ARM64 Linux box, I found that OpenCL was actually not used in the classification demo following the instructions at:
https://github.com/OAID/mxnetOnACL/tree/master/acl_openailab
https://github.com/OAID/caffeOnACL/tree/master/acl_openailab
Did I miss something?
PS: I asked same question in ACL project, but I was redirected here. Hope this is the correct place.

Hmm, after digging further, I found the way to enable GPU acceleration now by setting dev_type=2 in image-classification-predict.cc, although I ran into the failure below.
image-classification-predict: tools/intern/llvmufgen/HalfSupport.cpp:163: llvm::Value* {anonymous}::HalfSupportPass::getValueAs(llvm::Value*) [with bool ToHalf = false]: Assertion `(isa<Constant>(val) || is<Half>(val) != 0) && "Requested value isn't half."' failed.
Stack dump:
0.	Running pass 'HalfSupportPass' on module 'BuildGroup_2'.
Aborted

It looks like cl_khr_fp16 extension is required by ARM Compute Library for OpenCL acceleration, but my ARM platform doesn't support this OpenCL extension.


feat(irs-api):[#199] register policy definition for certain bpnls

story: https://github.com/eclipse-tractusx/item-relationship-service/issues/199

Hi @ds-psosnowski , in the concept in the story there is a "PUT /irs/policy/{policyId}" but I cannot find this in the implementation. We just have PUT "/irs/policies/{policyId}" (plural). Is the concept just inconsistent here or is anything missing in the implementation / incorrectly implemented?!

Hi @ds-psosnowski , another thing I am wondering about:
the concept says "API GET /irs/policies" (with a request parameter). But the implementation has "API GET /irs/policies/{bpns}", meaning that the BPNs are passed as path parameter. Never seen an array being passed as path parameter before. Is this correct?
I meant it would be an URL in the following form:
GET /irs/policies/BPN1,BPN2,BPN3
intended?

Hey, please comment out code so I can reply in relevant topics. According to:

list of bpns in path param - this is get request so you cannot have body for it also array is perfectly fine as parameter. If for some reason we don't want that this method need to be converted to post for example.
There is business partner number when you query for all policies. If you are not (you are passing the bpn as param) then there is no need to return it since you are returning polices for given bnps right?
About return type - original get was returning whole policy not just an id, I don't think it would make sense to return only id's for policies that are for some bpns and whole policy when we use getAll, I believe this is mistake in story definition, but we can confirm it.
../policy/... or .../policies/... - do you really think that it was intended to use singular only for one request? I would rather think that this is just typo

merged main again because of new conflict


Updating tower-check-replication playbook

Updating playbook for more flexibility
Using postgresql_query module for queries
Replacing python script with awx-manage to run on both RHEL7 and RHEL8

I do like this change.  My only issue with it is that it requires installing additional python modules (pyscopg2) that aren't present by default.  I'm still debating on whether or not to include the change and add a step which will pip install the needed module.


backup_stop needs a timeout

When doing a backup, after completing the data directory copy, backrest will:

issue a pg_stop_backup()
wait for the corresponding WAL file to appear in the archive

The latter has a timeout of 600 seconds which is a good choice since it prevents "stuck" backups.
The former can wait indefinitely if the archive_command causes errors.
It would be a good thing to either

have the same 600 second timeout for pg_stop_backup or
even err out immediately after encountering the wait message, since this indicates that there's an issue with the archive_command and we most likely won't get the stop point in finite time.

This is related (but not the same as) issue #25.  In fact, if pg_stop_backup() never returns, the backrest timer will never start.  If it were run asynchronously then the connection could be killed.
It's a problem, though - because if pg_stop_backup() does not return then the next backup with likely fail as well without some intervention.  I'm not completely sure what the solution is here.

It's a problem, though - because if pg_stop_backup() does not return then the next backup with likely fail as well without some intervention.

That's what stumped me as well for a bit but if you check do_pg_stop_backup in xlog.c  the CleanupBackupHistory() call is right above the wait and the only relevant thing happening after the wait is the return of the stoppoint.
pg_stop_backup in xlogfuncs.c itself is just a thin wrapper around do_pg_stop_backup
I verified that by checking pg_is_in_backup() during the run, postgres is no longer in backup mode while backrest is waiting, so you don't leave the db in an unsafe state.
So in my opinion it's safe to just abort after issuing the pg_stop_backup() call and encountering the error message.

Right - that sounds correct and should be doable.  I've been planning to move the Db module over to DBI instead of exec'ing psql.  Any thoughts on that?

Implemented in e82afac.
Add db-timeout option for this feature.


sending urls in tags is not working

When errors occur we want to log third party library session urls in sentry. So we have no choice but to partial url and reconstruct it from the logged data. Is there a legitimate way of logging urls in tags.

What is the tag name you are using?

fullstory_url
On Mar 22, 2016 2:57 AM, "Ben Vinegar"<EMAIL_ADDRESS>wrote:

What is the tag name you are using?
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/getsentry/raven-js/issues/509#issuecomment-199493362

Hey @sagiavinash – you're going to have to give me an example where it's not working.
Here's an example JSBin where I've set tags using the fullstory_url, then thrown an exception: http://jsbin.com/pakonewuwe/1/edit?html,js,output
The url appears as a tag inside the Sentry UI just fine:

Closing for now, but I'll re-open if you have a reproducible example I can look at.


fix test names

Fix Issue # .
Build server test tasks use the wildcard expecting test dlls to end in ".Tests.dll"
Changing name here to fix build
Notes for reviewers:

We support comment build triggers

/AzurePipelines run will queue all builds
/AzurePipelines run <pipeline-name> will queue a specific build

/AzurePipelines run AI-DotNetSDK-Gated+REORG(Everything)

/AzurePipelines run AI-DotNetSDK-Gated+REORG(Everything)

/AzurePipelines run AI-DotNetSDK-Gated+REORG(Everything)

This is ready for review now

@cijothomas Can you review, please?


Strange DVR on latest build if VTX is on before goggles

i think i've narrowed this down to only when the VTX is powered up before the goggles (or before the goggles have fully booted). If i have the VTX powered on first the DVR files come out where the image is in the top left of the frame and the rest is bright green.

#434 should fix this I think, unless this isn't caused by #433

Didnt seem to fix it for me

You're right, the issue you raised is from before #433 so the issue is in something else. I have the same issue, if the goggles are booted and you start recording without opening the menu first, the recording is not properly scaled

Does this happen only when wifi is turned on?

This is a questionable place. It may be a problem of execution order.

I have never used the wifi option on my goggles, so if the default setting for the wifi interface is OFF, then it also happens when wifi is turned off.
I have been able to reproduce the behavior, my goggles are set to boot to 'last' source. If I start the recording, it does not scale the DVR. After going to the menu, and back to the source, the DVR is scaled. So perhaps if 'last' option is used for source, it skips the DVR scaling?

@SumolX Maybe it is related to https://github.com/hd-zero/hdzero-goggle/pull/425 page_wifi_update_settings() is postponed but may be run in video mode.

@alfonsogordon and @sanderpuh could you verify with the WiFi setting enabled option set to off if you can still reproduce this issue?

I have been experiencing this issue for quite a while. Just turned wifi to OFF and rebooted the goggles, first 2 test videos are recording correctly now (eco vtx) Goggles on last commit to master and vtx 1.6.0

I have been experiencing this issue for quite a while.   If not could you post the version reported in firmware and include the git commit id as well.

Are you running latest 9.4 firmware? If not could you post the version reported in firmware and include the git commit id as well.

75-191-9.3.0-406ad54 (file name of the download)
I assume this is 9.3.0

I will submit a PR which will automatically generate a new bin.  Would you mind trying it out to see if it fixes the issue.

Are you running latest 9.4 firmware? If not could you post the version reported in firmware and include the git commit id as well.

75-191-9.3.0-406ad54 (file name of the download)
I assume this is 9.3.0

I will submit a PR which will automatically generate a new bin. Would you mind trying it out to see if it fixes the issue.

HDZERO_GOGGLE-75-191-9.3.0-9f45d04.bin.zip
Please try this build and see if it resolves the issue.

@sanderpuh @chaotixtech @alfonsogordon
Please try this build and let me know if its fixed.
HDZERO_GOGGLE-75-191-9.3.0-9f45d04.bin.zip

I will submit a PR which will automatically generate a new bin. Would you mind trying it out to see if it fixes the issue.

Flashing and testing this now.

@alfonsogordon @chaotixtech @sanderpuh Please try this new build.  It should now be properly fixed.
HDZERO_GOGGLE-75-191-9.3.0-c09cd8b.bin.zip

Tried, and was not able to reproduce the behavior as I've described before. No more scaling issues on my end! Note, I have only tested analog.


HBASE-23787: TestSyncTimeRangeTracker fails quite easily and allocate…

…s a very expensive array.
Here is a first pass, says it can't merge for some reason so I will be back for draft 2.

Your branch up-to-date Mr. Miller?

@markrmiller See comments above?

Sorry, been chasing a local clean test run.
The AtomicLongArray was need for these tests to pass more regularly for me to ensure we always look at an up to date value.
The memory issue seemed wasteful and a bit off given the goals of the test and also counter productive to running test like this in parallel.
I've updated my pr.

No response on above. Closing this out.


Unifiy application and microservice architectures

It would be really awesome if we could choose to expose our applications over both HTTP, TCP, or both without code modifications. This would be ideal as you could still expose your application to end users over HTTP, but also to backend consumers over TCP. The .NET framework ServiceStack is a great example of this sort of architecture. It encourages you to design your API in a way that can be consumed over arbitrary transports.
After briefly reading through the code, I think there are just a few overarching things standing in the way of this:
Returning values directly from controller methods
This would help unify the application and microservice interfaces (since microservices already expect you to return Observables).
Taking this example from the docs:
@Get('/:id')
public async getUser(@Response() res, @Param('id') id) {
  const user = await this.usersService.getUser(id);
  res.status(HttpStatus.OK).json(user);
}

It would be nice if it could optionally be written as:
@Get('/:id')
public getUser(@Param('id') id): Promise<User> {
  return this.usersService.getUser(id);
}

Controller methods should support returning HttpException, Promise<T>, Observable<T>, and T. All these types will automatically be serialized to the response independent of the underlying transport.
Class-based request definitions
We will need a unified way of deserializing request parameters and passing them to controller methods that agnostic to the transport mechanism. To work around this I propose that we support class-based request definitions with sane, interoperable behavior by default that also allows the user to override the deserialization behavior across transports.
Continuing with our previous example from the docs, a controller might look something like this:
@Message()
class GetUserRequest {
  @Param('id') // for HTTP use `req.params.id`
  @MessageData('id') // for TCP use `data.id`
  id: number;

  // when no decorators are specified, the default behavior might be:
  // HTTP: `req.params[key] || req.body[key] || req.query[key]`
  // TCP: `data[key]`
  group: string;
}

@Controller()
export class UsersController {
  @Get('users/:id')
  @MessagePattern({ cmd: 'get-user' })
  public getUser(request: GetUserRequest): Promise<User> {
    return this.usersService.getUser(request.id);
  }
}

Unified Exception Filters, Pipes, and Middleware
These require some more thinking, especially if we want to do it in a backwards-compatible way.

Hi @marshall007,
I think the big part of your ideas covers the new v4 release. I'm happy to share this with you finally. :cat:
Thanks!

Hey @kamilmysliwiec, the new v4 API looks great! Have you considered the second part of my proposal concerning class-based request DTOs?
export class CreateCatDto {
  readonly name: string;
  readonly age: number;
  readonly breed: string;
}

Hey @kamilmysliwiec, the new v4 API looks great! Have you considered the second part of my proposal concerning class-based request DTOs? Taking this example from the docs:
// dto/create-cat.dto.ts

export class CreateCatDto {
  readonly name: string;
  readonly age: number;
  readonly breed: string;
}

// cats.controller.ts

@Post()
async create(@Body() createCatDto: CreateCatDto) {
  // TODO: Add some logic here
}

I would like to see support for using the request decorators on class properties like so:
// dto/create-cat.dto.ts

export class CreateUpdateCatDto {
  @Param('cat_id')
  readonly id?: string; // req.params.cat_id

  @Body()
  readonly name: string; // req.body.name
  @Body()
  readonly age: number; // req.body.age
  @Body()
  readonly breed: string; // req.body.breed

  @Query('api_key')
  @Header('X-Auth-Api-Key')
  readonly apiKey: string; // req.query.api_key || req.headers['X-Auth-Api-Key']
}

Note how this allows us to specify fallbacks for plucking out various request options. In this case if the API key is not specified as a query param, we can still grab it from the header.
More importantly, these fallbacks would allow us to map incoming TCP and HTTP requests to the same DTO, which paves the way for totally transport-agnostic controller definitions.
// cats.controller.ts
@Post()
async create(@Message(CreateUpdateCatDto) req: CreateUpdateCatDto) {
  // TODO: Add some logic here
}

@Put('/:cat_id')
async create(@Message(CreateUpdateCatDto) req: CreateUpdateCatDto) {
  // TODO: Add some logic here
}


Add default jasper template for dynamic table processor

In order to simplify configuration of TableProcessor in dynamic mode I have added a default jasper report that will be used if one is not specified.
There are also a couple minor fixes to the tests.

Yes it is just for the styles it does not restrict the number of columns.

Yes it is just for the styles it does not restrict the number of columns.

Ok, cool.
Just one more minor issue about the styling of the table cells. Even rows have a border at the bottom, odd rows don't. And in even rows there is no border between the second and the third cell. Could we make this consistent? Maybe no borders at all? Only below the header row?

I have updated the styling so it is a bit better.  What do you think?

Great, thanks Jesse! :) Feel free to merge.

Thanks for the review.


Oracle support

It would be great if Oracle could be used as database. I've tried it but there are at least these issues that prevent it:

there is more than one primary key with name "PRIMARY"
"user" as tablename must be escaped in generated SQLs
"level" as columnname must be escaped in generated SQLs
some generated SQLs don't work because of Oracle is case-sensitiv

Are you using the correct dialect for your database? e.g.
spring.jpa.database-platform=org.hibernate.dialect.Oracle12cDialect

I would expect hibernate to automatically handle escaping if the correct dialect is used.

Yes I'm quite sure with the dialect. Did you managed to run the liquibase updates on an empty oracle DB?

No, I don't have oracle db installed. Will check in the coming days.

Thank you! I'm using this image https://hub.docker.com/r/sath89/oracle-12c/

Unfortunately, oracle support is blocked by a hibernate issue. It is unlikely that this issue is resolved before the bug in hibernate is fixed.

After some consideration I've changed my mind on this: mysql will be the only dialect 1.0.0 supports officially. Others might or might not work. Oracle doesn't work and probably won't ever, unless someone else comes and does the work.


[Bug]: this.. uhh.. thing

All of the following criteria must be met

[X] All Requirements must be installed.
[ ] Full Latest.log file included. If no file exists then leave this unchecked and state so.

All of the following are optional to answer

[ ] Tried reinstalling the Game.
[ ] Tried reinstalling MelonLoader.
[ ] Tried restarting PC.
[ ] Was able to see the Start Screen.

Describe the issue.
System.UnauthorizedAccessException: Access to the path 'C:\Program Files (x86)\Steam\steamapps\common\Fall Guys\dobby.dll' is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access)
at MelonLoader.OperationHandler.Automated_Install(String destination, String selected_version, Boolean is_x86, Boolean legacy_version)
Did you attach your log file?

[ ] Yes, I attached my log file to the text box above.
[X] No, I could not find a log file at {Game_Directory}\MelonLoader\Latest.log

sorry to waste ur time

Fall guys, unsupported, stop trying to mod that game.

ok


Deltas are not updated when report isn't being displayed such that when you return to the report a large delta is introduced which creates a max.

Fixed in Dev branch.


debt - is IContextViewService just hot air?

I see we have a IContextViewService and I see it being injected but somehow I don't anyone actually using it in the sense of calling methods except for the content menu service.

unsure if this is @joaomoreno or @bpasero

It used to be used by more UI contributions...
Now, if I'm not mistaken, it is used by menus and the feedback widget, although the use in the latter does have a bit of a type mess...
What do you suggest?

nuke it

Do you have any suggestion how?

Yeah, by removing all references that actually do nothing and then see what's left. It seems like nothing talks about that service interface but if they talk about this abstraction in browser/ui/contextview. I am not saying it must be removed but the existence of the service seems somewhat artificial

Actually it is also used by the InputBox down in base: for when the user types an invalid regex for example. It is hidden away an identical interface ContextViewProvider since services don't exist down there.


Improved more PHPDoc comments

This resolves inline @see tags not getting linked in PHPDoc blocks, and various styling issues where the summary line wasn't properly separated from the description section. This makes every (I hope) docblock look good in phpDocumentor.
Also includes grammar improvements.
Hmm, should the two "improve" PRs be in the Changed section of the changelog, instead?

Hmm, should the two "improve" PRs be in the Changed section of the changelog, instead?

Nah, they do fix (documentation) issues — they're not particularly serious, as they don't affect the behavior of the software itself, but they were corrections nevertheless. I'd say we keep them in the "Fixed" section.


Update titles on employee-wellbeing.md

Closes https://github.com/MicrosoftDocs/Viva/issues/463.

@lilyolason
PR has been copyedited and is ready for final review, could you please check and merge? Thanks!


Update homework_5.sql

What changes are you trying to make? (e.g. Adding or removing code, refactoring existing code, adding reports)
added sql to the homework questions
What did you learn from the changes you have made?
cross join, insert, update, delete, alter queries, window functions, temp table
Was there another approach you were thinking about making? If so, what approach(es) were you thinking of?
no
Were there any challenges? If so, what issue(s) did you face? How did you overcome it?
complexity of the queries, breaking down into smaller units of problem as mentioned in the hints helped.
How were these changes tested?
in sqllite db browser
A reference to a related issue in your repository (if applicable)
NA
Checklist

[  Y ] I can confirm that my changes are working as intended

HW5 is passed.


User defined types - sealed decorator not working in bicep parameters files

Bicep version
Bicep CLI version 0.21.1 (d4acbd2a9f)
Describe the bug
If I understand correctly the sealed decorator when you have it on an object if you define property in bicep parameters files that is not defined in the type of that object the deployment will fail as it will not allow you to pass any properties that are not defined in the type. But shouldn't bicep parameters file signal that as an issue before deployment (in VSC UI)?
To Reproduce
Steps to reproduce the behavior:
Additional context
Add any other context about the problem here.

Looks like parameter assignment statements in .bicepparam files are only performing a shallow type check. I'll open a PR to update that check to validate object properties as well.


Question about user side variables

Helllo,
I have noticed that the templates used variables that weren't sent down via render e.g:
export let getAccount = (req: Request, res: Response) => {
  res.render("account/profile", {
    title: "Account Management"
  });
};

but user info is used in the pug template:    user.profile.name
    .form-group
      label.col-sm-3.control-label(for='name') Name
      .col-sm-7
        input.form-control(type='text', name='name', id='name', value=**_## user.profile.name_**)
    .form-group

How did that variable apear on the client side?
Thank you for the answer!
Laci

Ok, it was my mistake, I did not notice the res.locals in the "Express configuration" section


getCluster kubeconfig

Unfortunately the files changed here are auto-generated, so this approach won't work (it'll get overwritten any time we update the provider).
cc @jen20 or @pgavlin to suggest an alternate approach for incorporating this functionality in.


Bump framework version

$subject

PR builder started
Link: https://github.com/wso2/product-is/actions/runs/981738250

PR builder completed
Link: https://github.com/wso2/product-is/actions/runs/981738250
Status: success


ElseExpression explanation needs an update

Currently it says:

An if expression with an else branch is never necessary.

True, this proposition is correct in most cases. But there are cases, especially in generators, where else is unavoidable. Here's a primer:
$example = [
    [1, 1, 1],
    2,
];

var_dump(iterator_to_array((function () use($example) {
    foreach ($example as $element) {
        if (is_array($element)) {
            yield from $element;
        } else {
            yield $element;
        }
    }
})()));

var_dump(iterator_to_array((function () use($example) {
    foreach ($example as $element) {
        if (is_array($element)) {
            yield from $element;
            return;
        }
        // Notice no else here

        yield $element;
    }
})()));

If you would run this primer, you would see that these two snippets give different results:
array(3) {
  [0]=>
  int(2)
  [1]=>
  int(1)
  [2]=>
  int(1)
}
array(3) {
  [0]=>
  int(1)
  [1]=>
  int(1)
  [2]=>
  int(1)
}

Possible solution would be to update the documentation to either read:

An if expression with an else branch is almost never necessary.

Or to update the rule to ignore else in generators.

 :( Or it could be my OCD that kicks in when I have codebases that will always have warnings unless I convolute my code. Though #288  doesn't give my any hope.

True, this proposition is correct in most cases. But there are cases, especially in generators, where else is unavoidable
Not unavoidable, you just need to replace return with continue in your example to get the same output without using else.

All right then, let me think of another example.

Half a hour later I still can't think of any. So I guess you're right. Thanks for the wisdom,
@kylekatarnls.
Closing for now.


Add api for stats all containers

Fixes #22052
Add a new API for docker stats all containers, and refactored docker
client to make use of new API.
There're some obvious benefits from this commit:

it saves lots of TCP connections when stats bundles of containers.
the client side is expected to gain higher performance due to less goroutine.
client codes are simpler and easier to maintain.

Signed-off-by: Zhang Wei<EMAIL_ADDRESS>ping @runcom @thaJeztah
/cc @vincentwoo @jeanpralo Is this what you want?
TODO:

[x] api-tests and integration tests
[ ] docs

nice!!

Thanks for the work @WeiZhang555 :) Much appreciated that will save a bit of cpu on those servers with 100+ containers :)
I was wondering if we could potentially add the names of the containers in the response, I guess id is fine but it is just more convenient if you have a script pulling this endpoint regularly rather than having to rely on  some other external mapping or have to do a second api call to /containers/json.
I guess for most people the usage of that API endpoint is to get metrics in order to present them nicely, since a container in itself has a short lifetime you most likely graph the name of your container rather than its id.

@rileysaurus if you have some time can you kick the tires on this PR?

@jeanpralo
I think it's inappropriate to put names in response, there's no space for docker client showing the container names, and ID is already a unique key for identifying a container.
But I can change my idea if maintainers thinks it's good, technically it's not hard to add a new "name" field.

@WeiZhang555 there's an open pull request to add --format to stats. I haven't yet looked how that will conflict with this PR, but that PR adds a name field, so that it can be used as a custom format; https://github.com/docker/docker/pull/24987

ping @bfirsh; this adds a /containers/stats endpoint; does that fit in your API suggestions? https://github.com/docker/docker/issues/25015; guess that makes stats a reserved keyword for container names?

@WeiZhang555 @thaJeztah this PR is interesting (#24987)  but it looks like it is doing the formatting on the client side,  not as a response to the API call though.
So if I will still need to do an extra call to match the id with the name.

@jeanpralo correct; both PR's solve a different issue; this PR implements the current stats (all containers) server side, but doesn't change the output; I think that changing the output belongs in https://github.com/docker/docker/pull/24987, which could build on top of this PR (and add extra fields to the API response. I think having both merged / implemented could be realistic for the next release (famous last words)

@jeanpralo Just as @thaJeztah said, these two PRs are solving different issues. Combining these two will give what you want, but need to solve the code conflict, I believe there will be lots of.

Yes, this would conflict with #25015.
If there is a valid reason for doing this instead of multiple calls in parallel (which this does seem to be), then we need to figure out a good way of doing batching. There is no agreed upon way of doing batch operations with a REST API, and it's often a bit messy. See also #24724 where I explain in some more detail.
Having more endpoints at /object/X is going to paint our URL design into a corner, so I think that is a bad idea. But – I think there are some good ways we can do it:

Build a generic batch operation API. Facebook have a good example of how to do this, but it's also an example of how complicated it can get...
Have a special name to represent all containers, perhaps using a special character that can't be in a container name. e.g. /containers/.all/stats

(1) sounds like a big chunk of work, but (2) seems workable. Anybody got any other ideas?

Also /allcontainers (or a nicer name) could be at the top level? Maybe thats all thats needed, stats is its inspect?

I tested this PR out with 250 containers. I see only a negligible change in CPU usage, and just a slight shifting of the CPU usage from dockerd to docker-containerd.
I've testing with both requesting a stream of stats and just a single sample of the stats.
I'm running a ubuntu 14.04 VM on a mid 2015 Macbook Pro.
Here is the output of docker info for both versions I've tested.
12.0:
 Running: 250
 Paused: 0
 Stopped: 0
Images: 123
Server Version: 1.12.0
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: none
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host bridge null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor
Kernel Version: 4.2.0-27-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 1.937 GiB
Name: coderpad
ID: QC3J:K2Q5:B6PQ:36IH:IAKK:BH4T:G6G4:3OUK:6YRC:CCC2:LIU5:AZ46
Docker Root Dir: /data/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
 <IP_ADDRESS>/8

13.0-dev
Containers: 250
 Running: 0
 Paused: 0
 Stopped: 250
Images: 123
Server Version: 1.13.0-dev
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: none
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: overlay null bridge host
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor seccomp
Kernel Version: 4.2.0-27-generic
Operating System: Ubuntu 14.04.5 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 1.937 GiB
Name: coderpad
ID: QC3J:K2Q5:B6PQ:36IH:IAKK:BH4T:G6G4:3OUK:6YRC:CCC2:LIU5:AZ46
Docker Root Dir: /data/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
 <IP_ADDRESS>/8
Live Restore Enabled: false

I tested this PR out with 250 containers. I see only a negligible change in CPU usage, and just a slight shifting of the CPU usage from dockerd to docker-containerd.

@rileysaurus I just tested this with 1000 containers, I agree with you that the CPU usage didn't change much on daemon side, but I didn't see the shifting of the CPU usage from dockerd to docker-containerd.
Interestingly, I noticed that the client CPU usage is much more lower with this PR.
hardware for client:  12 CPU, 125G Mem
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
client1 (generated with this PR):
Client:
 Version:      1.13.0-dev
 API version:  1.25
 Go version:   go1.6.3
 Git commit:   95d0c31
 Built:        Wed Aug 10 08:59:39 2016
 OS/Arch:      linux/amd64
 Experimental: true

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
client2(from upstream master):
Client:
 Version:      1.13.0-dev
 API version:  1.25
 Go version:   go1.6.3
 Git commit:   fa06908
 Built:        Tue Aug  9 10:02:46 2016
 OS/Arch:      linux/amd64
 Experimental: true

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
This is the performance
1.deducation of CPU usage on Client side
client1(from this PR):
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.3 us,  1.1 sy,  0.0 ni, 98.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 13170728+total, 17432720 free,   967036 used, 11330752+buff/cache
KiB Swap:        0 total,        0 free,        0 used. 13031072+avail Mem

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 75537 root      20   0  753024  26964  11796 S   6.0  0.0   0:01.67 docker-1.13.0-d

client2(from upstream):
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.6 us,  1.9 sy,  0.0 ni, 97.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 13170728+total, 17372616 free,  1025468 used, 11330920+buff/cache
KiB Swap:        0 total,        0 free,        0 used. 13025072+avail Mem

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 75559 root      20   0  671868  86280  12292 S  13.5  0.1   0:05.04 docker-client

2.less resource consumption on daemon side
This PR will save TCP connections, File descriptors and Goroutines, which all will influence numbers of clients it can serve.
client1(from this PR):
# docker info
...
Debug Mode (server): true
 File Descriptors: 4017
 Goroutines: 6026
 System Time: 2016-08-11T10:16:22.361121791+08:00
 EventsListeners: 0

client2(from upstream):
Debug Mode (server): true
 File Descriptors: 5017
 Goroutines: 9026
 System Time: 2016-08-11T10:18:43.145383775+08:00
 EventsListeners: 0

This PR can save 999 TCP connections, 3000 Goroutines and 1000 File Descriptors when stats 1000 containers!
3.this PR guarantee client always get all stats numbers.
client1: (from this PR)
# docker stats
<part of results...>
2cb984ad9837        0.00%               52 KiB / 15.57 GiB    0.00%               0 B / 0 B           0 B / 0 B           1
2cd3f12491c7        0.00%               52 KiB / 15.57 GiB    0.00%               0 B / 0 B           0 B / 0 B           1
2cf77cf17545        0.00%               52 KiB / 15.57 GiB    0.00%               0 B / 0 B           0 B / 0 B           1
2d7fb0aa0aa4        0.00%               56 KiB / 15.57 GiB    0.00%               0 B / 0 B           0 B / 0 B           1
2db85a985917        0.00%               52 KiB / 15.57 GiB    0.00%               0 B / 0 B           0 B / 0 B           1

client2:(from upstream)
# docker stats
<part of result...>
543b3823e24c        0.00%               56 KiB / 15.57 GiB   0.00%               0 B / 0 B           0 B / 0 B           1
0330db77418f        0.00%               60 KiB / 15.57 GiB   0.00%               0 B / 0 B           0 B / 0 B           1
5550702b0eef        --                  -- / --              --                  -- / --             -- / --             --
5f5b6429d7ca        --                  -- / --              --                  -- / --             -- / --             --
20b200f2ddf6        --                  -- / --              --                  -- / --             -- / --             --

This is because old client trys to get data of containers one by one but can't guarantee it get correct numbers while displaying, but client from this PR will only make one request, and daemon will batch all data and send it to client once, which will guarantee client can always get all the data without care of  synchronization.
That's all my point, correct me if I'm wrong @rileysaurus :smile:
Also ping @docker-maintainers, please tell me what do you think of this change.

In general, I'm +1 for this PR; I think this would also make it easier to (for example) implement a --filter for stats to only show a limited set of containers, without introducing a race between client obtaining containers to filter, and requesting those containers (but that's another topic)
w.r.t. design, I think we need to have a look at the endpoint (https://github.com/docker/docker/pull/25361#issuecomment-237893834), to prevent future conflicts, all of /containers/-/stats, /containers/.all/stats or /stats/containers/ could work, but no real preference at this moment, so better suggestions are welcome.

ping @bfirsh @WeiZhang555 any preference for one of those options?

I vote to get /allcontainers/stats or get /all/containers/stats, then if we need another consolidate API for (say) images, we can add /allimages/xxx or /all/images/xxx.
I'm not quite used to format with special name of /containers/-/stats /containers/.all/stats, does any popular website apply this rule/format widely?
what do you think? @thaJeztah @bfirsh @justincormack

I can't think of any examples of this off the top of my head, but we do have some pretty clear conventions in place that we can follow.
I am -1 on /all/containers/stats because it breaks the /resource/id/verb convention.
I am -0 about /allcontainers/stats because it also breaks that convention, but it is not as bad.
I prefer /containers/SOMETHING/stats. No strong feelings about what SOMETHING is, but I think a character that can't be in a container name is better than having reserved container names.

@bfirsh Sound reasonable.  Then it looks like GET /containers/.all/stats is the right option.
Any more suggestions from any one?

I don't expect multiple entities to be included in a single stats stream (e.g. containers, and services in the same stream), so having it under /containers (for now) seems like the best thing to do.
I can't really put my finger on it why but not fond of .all. Perhaps it's because .all may put too much meaning in it; - may be slightly clearer to indicate "url component omitted", so if at some point we have "deeper" URL structures, the same can be used, e.g. (just for illustration);
/services/-/tasks/-/stats
/services/*/tasks/*/stats

It looks like * is actually allowed in URLs, see http://www.w3.org/2002/11/dbooth-names/rfc2396-numbered_clean.htm (line 460), so could be a candidate. (unless we're worried about people using it on the command-line, and getting issues with the shell trying to expand it

The reason I picked GET /containers/stats is that it's consistent with existing APIs, for example, we have /images/json and also /images/{name: .*}/json, as we still don't have an agreeable plan on how to make a cleaner API for consolidated stats data. I would say we keep using /containers/stats for consistency.
I've looked into https://github.com/docker/docker/issues/25015, the suggestion is good, but there's some hard problems on the backward compatibility, so I don't expect it will take place soon. Considering this, I'll re-propose the /containers/stats
Involve @calavera for API name, I think we need his approval to merge the new API into engine-api, so I'd like to hear your suggestion earlier. ping @calavera

I don't think a new endpoint at /container/stats is a good idea.

@cpuguy83 what API name would you suggest? I have no special leaning and not good at naming....

Either /services/-/stats or /services/*/stats sound reasonable to me. Slight leaning towards - because * implies some kind of clever globbing is being done. E.g. I might expect /services/foo*/stats would work.

@bfirsh I guess you mean /containers/-/stats? I'm fine with it, maybe we should move forward first with this name?

Yep. If @thaJeztah is happy with it, I guess we can move forward. :)

Sorry for the delay, I was on vacation, listening to bagpipes in Scotland 😜.

Slight leaning towards - because * implies some kind of clever globbing is being done.

Oh, yes, didn't think of that, and I agree
I'm definitely good with /containers/-/stats, so let me move this forward - @WeiZhang555 can you update the code to use /containers/-/stats ?

@thaJeztah @cpuguy83 rebased.
After latest rebase, I found I met a big problem. Windows now supports docker stats now, stats API response header has a server field to indicated daemon OS Type, the awful part is Windows has different calculation method with Linux.
So I think this consolidated API can't work on Swarm, suppose we have a swarm cluster with mixed use of Windows machine and Linux machine, the single one API can't classify daemon type and can't calculate correctly on client side.
What do you suggest? Also ping @jhowardmsft

@WeiZhang555 I think a mixed windows/linux swarm should not yet be a problem here, given that docker stats is always for a single node. We will have that challenge if (at some point), a docker service stats command is created, and if that accepts multiple services to be shown

Rebased and all test cases passed. Anyone please take a look :smile:

@thaJeztah Any new information?

@WeiZhang555 can you rebase again? I'll try to get this PR moving again!

@thaJeztah rebased. Thanks for your help! :bouquet:

Discussing this; perhaps you can make the endpoint for a single container use the new "all stats" function, but filter on container name/id?

@thaJeztah

Discussing this; perhaps you can make the endpoint for a single container use the new "all stats" function, but filter on container name/id?

I love this idea, I think it won't bring more overhead to server. I'll do some evaluation and try to bring it to reality.

I would think docker stats --all would do a filter based on status.

I would think docker stats --all would do a filter based on status.

Correct. Basically --all would remove filtering (without it, only "status=running" is shown)

So here is my understanding:

abandon old API /containers/{name:.*}/stats(indeed we need to keep it for backward compatibility), all stats operation(no matter docker stats contA contB or docker stats) will go though new consolidate API /containers/-/stats
docker stats --all will map to API /containers/-/stats
docker stats will map to API /containers/-/stats?filter={status=running}
docker stats contA contB will map to API /containers/-/stats?filter={id=[contA,contB]}

Is that correct? @cpuguy83 @thaJeztah

I think @cpuguy83 had in mind to keep the same endpoints in the API, but call the getContainersStatsAll method in all cases
ping @cpuguy83 correct?

@thaJeztah Yes, I agree. My plan is:
1.For newer client:
In all cases, all stats operations go through /containers/-/stats with different filters, so later client will never call /containers/{name:*}/stats.
2.For old client, to keep compatibility:
We keep old API /containers/{name:*}/stats, but the handler for this API will change to getContainersStatsAll, and its behavior will be same with /containers/-/stats?filter={id=[name]}
3.For new server:
We provide new API /containers/-/stats with different filters.
Old API /containers/{name:*}/stats will be handled by getContainersStatsAll as step 2 said.

To keep the API "restful(ish)", keeping newer clients to use /containers/(id or name)/stats would have my preference

@thaJeztah if client keeps using old API, there will be one issue that will never be resolved.
After we start a bunch of containers, then run docker stats \docker ps -aq``, we often get weird result.
# docker stats `docker ps -q`
<part of result...>
543b3823e24c        0.00%               56 KiB / 15.57 GiB   0.00%               0 B / 0 B           0 B / 0 B           1
0330db77418f        0.00%               60 KiB / 15.57 GiB   0.00%               0 B / 0 B           0 B / 0 B           1
5550702b0eef        --                  -- / --              --                  -- / --             -- / --             --
5f5b6429d7ca        --                  -- / --              --                  -- / --             -- / --             --
20b200f2ddf6        --                  -- / --              --                  -- / --             -- / --             --

That's because we fetch stats data one by one, and at the time client print the result, some stats result are not ready yet.
But if we use one API, we can guarantee all the stats data are fetched at the same time and this mess won't happen any more.

@WeiZhang555 sorry, I meant;

docker stats <container> should keep using /containers/(id or name)/stats, but that endpoint would run getContainersStatsAll with a filter set for "id or name" (or possibly call getContainersStats, but that is changed to be a "wrapper" for getContainersStats
docker stats should use /containers/-/stats and also use getContainersStatsAll

@cpuguy83  - did I explain it like you head in mind?

That was a whole week ago, I don't know :)

@WeiZhang555 I see you updated the PR, can you let us know when it's ready for another review?

@thaJeztah It's almost done, this is implemented exactly per your suggestion. Except that there is a weird test case failure that shows one Windows test case hangs, I temporarily disabled that one and are still investigating, see the last commit 9a022dac187b0f6aa68811f477c454a0b1672d3b.
I think it's ready for another review now, at the same time I'll find why windows behaves abnormally. Actually Windows shares same logic with Linux platform, so I don't expect there will be special stuff for Windows, still investigating.

@thaJeztah Windows test case failure is fixed, it's a test case issue, but not related to the implementation itself.  So everything is done, and it's ready for another review now :smile:
PS: experimental test failed of unrelated problem.

@thaJeztah @cpuguy83 Could you take a quick scan of this? I'd like to know if the design/implementation is good or not. I think this would be a helpful feature as I said in https://github.com/docker/docker/pull/25361#issuecomment-239081943

So any feedback on this?   @docker/maintainers
PS: There are some conflicts, but I'd prefer to do another rebase after we finish design review and basic implementation review first, or I have to do too many rebases and it's painful to follow latest patches. :-)

@WeiZhang555 Just to be sure: if there are new containers coming, or existing containers removed, this endpoint would reflect the change correct? I believe that's what users would expect from this endpoint.
As far as /containers/-/stats is concerned, we don't have a better idea so you have the maintainers' green light.

Just to be sure: if there are new containers coming, or existing containers removed, this endpoint would reflect the change correct? I believe that's what users would expect from this endpoint.

Yes, absolutely.

As far as /containers/-/stats is concerned, we don't have a better idea so you have the maintainers' green light.

Oh, thank you! :laughing:

ping @WeiZhang555 can you rebase?

@thaJeztah Yep, I'll do it. Since there're some new functions introduced, it will cost me some time to follow latest functions. But I'll do it as quickly as I can :smile:

@thaJeztah Rebased. Windows tests failed of unrelated problem, I will re-trigger it later, other tests are all green :fireworks:
I believe this PR could bring lots of benefits as listed in https://github.com/docker/docker/pull/25361#issuecomment-239081943, the most obvious advantage is that it simplifies client code quite a lot which will lead to easier maintenance, if you look at the current client codes of docker stats, you will come back to agree with me.
This PR is in big lack of review, in quite a long time, it's only @thaJeztah pushing this towards the merging, I know we have lots of other important features needing more  focus and work, besides this is a large PR and not very friendly to reviewers, but I still hope to get more quick and useful feedbacks.
ping @docker-maintainers :smile:

Overall it seems good. One question, if you look at the output you've shown (e.g. https://github.com/docker/docker/pull/25361#issuecomment-256704105 ) you'll see that some containers have -- instead of 0 for the data.  Before this PR it was 0 so this will break existing clients.  Was this change discussed?

@duglin Thanks :smile:
I don't think it's what you said. -- indicates "error" or "time out when fetching stat", before this PR, you often get -- results when stating bunches of containers, but after applying these commits, you can get right data or 0.  You can see https://github.com/docker/docker/pull/25361#issuecomment-239081943 for client compare.
Note: only part of client changed, docker stats is using new API but docker stats `docker ps -q`  is using old API. I hope to move latter part to new API too, but that requires also more discussion, I can do that later after this is accepted in a follow up PR.
I'll do another rebase to resolve conflicts.

When i run the old stuff i don't see any --'s but with this pr i get a lot of them. That doesn't seem right.

@duglin Weird, I get the opposite result. How did you test it, maybe I miss something...
This is my test result with 1000 running containers (run top in busybox):
Test with master branch:

Test with this PR:

This is what I expected. docker stats `docker ps -aq` looks like a mess, maybe you are testing with this command? I need I need to do some fix for this.

Perhaps its related to the stopped containers. For me, the old stuff shows me:
# docker stats -a --no-stream
CONTAINER           CPU %               MEM USAGE / LIMIT   MEM %               NET I/O             BLOCK I/O
056af2957acb        0.00%               0 B / 0 B           0.00%               0 B / 0 B           0 B / 0 B
059f67920fa9        0.00%               0 B / 0 B           0.00%               0 B / 0 B           0 B / 0 B
1b012c67dd16        0.00%               0 B / 0 B           0.00%               0 B / 0 B           0 B / 0 B
...

and the new stuff shows me:
# docker stats -a --no-stream
CONTAINER           CPU %               MEM USAGE / LIMIT   MEM %               NET I/O             BLOCK I/O           PIDS
20005af60f0d        --                  -- / --             --                  --                  --                  --
f5648bd8d226        --                  -- / --             --                  --                  --                  --
91ab3be3134a        --                  -- / --             --                  --                  --                  --
829d1821d0b9        --                  -- / --             --                  --                  --                  --
...

All zeros vs all --'s

@duglin I see, you are right :+1: I'll fix it during the rebasing~

@WeiZhang555 one thing I just realised we should take into account is that, starting with docker 1.13, the client is able to talk to older daemon versions; that means that when talking to a daemon that not supports the "all" stats endpoint, it should still use the old approach

@duglin Your issue is addressed.
@thaJeztah Dammit, this is really a terrible problem. I can fix it, but it requires lots of work, and lots of duplicate code. I'm afraid I need to refactor again and the client implementation will be ugly afterwards. :cry:

Ok, so I have to say I've pretty much never been +1 for this, just a -0.... basically I see the need but, don't like the design but can't see anything better.
Is this solving a real, urgent problem? I think stats in general has a ton of room for improvement as even the stats collection is extremely inefficient. So is this really improving things?
At some point we'll have container stats exposed in the metrics API, which I think is much more suitable for this kind of thing.
I think adding this will lead to tremendous regret later (even for reasons beyond the metrics API).
Because of that I would have to say I'm pretty firmly -1 on this.

I'm against expanding the scope of the stats API. It is very inefficient and I am not sure it could be streamlined. I'd prefer we focus our efforts on expanding prometheus support.

I see that overall decision is -1 now. Bringing a lot of complexity doesn't sound very cool(for stats in particular). Let's start from refactoring and maybe return to this later.
@WeiZhang555 Thanks for your work! We appreciate it.


AttributeError: 'NoneType' object has no attribute 'enumerate'

I must be particularly dense this morning but I'm having an issue with running HWI.
I followed the install instructions in the README but when I run the ./hwi.py enumerate command I get:
❯ ./hwi.py enumerate
Traceback (most recent call last):
  File "./hwi.py", line 7, in <module>
    main()
  File "/tmp/HWI/hwilib/cli.py", line 296, in main
    result = process_commands(sys.argv[1:])
  File "/tmp/HWI/hwilib/cli.py", line 260, in process_commands
    return args.func(args)
  File "/tmp/HWI/hwilib/cli.py", line 60, in enumerate_handler
    return enumerate(password=args.password)
  File "/tmp/HWI/hwilib/commands.py", line 74, in enumerate
    result.extend(imported_dev.enumerate(password)) # type: ignore
  File "/tmp/HWI/hwilib/devices/trezor.py", line 677, in enumerate
    devs = hid.HidTransport.enumerate()
  File "/tmp/HWI/hwilib/devices/trezorlib/transport/hid.py", line 135, in enumerate
    for dev in hid.enumerate(0, 0):
AttributeError: 'NoneType' object has no attribute 'enumerate'

It seems that hid is None. But I can't seem to resolve the issue. I've just cloned that latest master.  Release 1.2.1 works as expected.

How have you installed the dependencies?

I have the same issue with the master branch.
# hwi --debug enumerate
INFO:hwilib.devices.trezorlib.transport.hid:HID transport is disabled: /usr/lib/python3.9/site-packages/hid.cpython-39-x86_64-linux-gnu.so: undefined symbol: hid_get_input_report
Traceback (most recent call last):
  File "/usr/lib/python-exec/python3.9/hwi", line 8, in <module>
    sys.exit(main())
  File "/usr/lib/python3.9/site-packages/hwilib/_cli.py", line 304, in main
    result = process_commands(sys.argv[1:])
  File "/usr/lib/python3.9/site-packages/hwilib/_cli.py", line 270, in process_commands
    return args.func(args)
  File "/usr/lib/python3.9/site-packages/hwilib/_cli.py", line 63, in enumerate_handler
    return enumerate(password=args.password)
  File "/usr/lib/python3.9/site-packages/hwilib/commands.py", line 117, in enumerate
    result.extend(imported_dev.enumerate(password)) # type: ignore
  File "/usr/lib/python3.9/site-packages/hwilib/devices/trezor.py", line 823, in enumerate
    devs = hid.HidTransport.enumerate()
  File "/usr/lib/python3.9/site-packages/hwilib/devices/trezorlib/transport/hid.py", line 135, in enumerate
    for dev in hid.enumerate(0, 0):
AttributeError: 'NoneType' object has no attribute 'enumerate'

This is on Gentoo with dev-python/libusb1 2.0.1

https://github.com/trezor/cython-hidapi/issues/90
https://github.com/liquidctl/liquidctl/issues/144
https://bugs.archlinux.org/task/67103?dev=25983

@jjakob what is the version of python3-hidapi installed on your system?

dev-python/hidapi <IP_ADDRESS> from the "guru" overlay. The only other available version is 0.10.1.
I forgot to mention, this issue is also present with the latest HWI release 2.0.2 (also from the "guru" overlay).

@jjakob I would take this to package maintainers of hidapi in Arch Linux. It seems there is a clash between hidapi and python-hidapi. (My hunch is they update hidapi and dev-python/hidapi not in sync). Anyway, I don't think there is anything we can do here.

Thank you for that hint, it was indeed because of dev-libs/hidapi 0.8.0 being installed. Updating to 0.11.0 (marked unstable) fixed the issue. I think the relevant Gentoo bug is https://bugs.gentoo.org/696482


AD Service data is reversed in iOS

Please check all of the platforms you are having the issue on (if platform is not listed, it is not supported)

[x] iOS
[] Android
[] tvOS
[] macOS
[] .NET Standard
UWP IS NOT SUPPORTED DURING THE BETA PERIOD - ONLY PRs ARE WELCOME FOR NOW

Version of OS(s) listed above with issue
iOS 11.2
Version of Library
5.3.4
Expected Behaviour
IScanResult.AdvertisementData.ServiceData[0] contains the first service data field defined in the ADV packet
Actual Behavior
IScanResult.AdvertisementData.ServiceData[1] contains the last service data field defined in the ADV packet. Actually I've tested with an ADV with two service data fields only, so maybe it's the second and not the last, but the last makes more sense.
Code of Conduct

No Library Update Requests
No Timeline Requests
Please read through the documentation and FAQs
Please be respectful of my time. I put a lot of effort into my libraries.  I try to support the issue requests within a day.  I'm not psychic, so please take the time to fill out the above form as complete as possible

Behavior on Android is actually correct. Therefore abstraction is problematic.

I don't see an issue with what you're describing here.  I'm not doing anything to reverse the order of the packets here.  Please send a PR if you feel otherwise.