[Snyk] Fix for 61 vulnerabilities

Snyk has created this PR to fix 61 vulnerabilities in the maven dependencies of this project.
Snyk changed the following file(s):

api/pacman-api-compliance/pom.xml

Vulnerabilities that will be fixed with an upgrade:

Issue
Score
Upgrade

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-608664
  780
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  Reachable Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-450917
  705
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found Mature

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-467015
  675
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found Mature

Denial of Service (DoS) SNYK-JAVA-COMFASTERXMLJACKSONCORE-3038426
  670
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  Reachable Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1054588
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056416
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056418
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056420
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056421
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056426
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056427
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-174736
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-548451
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-559094
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-559106
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-560762
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-561585
  630
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1009829
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1047324
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056414
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056417
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056419
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056424
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1056425
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-467016
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-560766
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-561362
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-561373
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-561586
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-561587
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-564887
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-564888
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-570625
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-572300
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-572314
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-572316
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-72448
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-72449
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-72450
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-72451
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-72882
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-72883
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-72884
  563
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

XML External Entity (XXE) Injection SNYK-JAVA-COMFASTERXMLJACKSONCORE-1048302
  560
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1052449
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1052450
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-1061931
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-455617
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-467014
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-469674
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-469676
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-471943
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-472980
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-540500
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-6056407
  555
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Denial of Service (DoS) SNYK-JAVA-ORGSPRINGFRAMEWORK-7687447
  545
No Path Found No Known Exploit

Denial of Service (DoS) SNYK-JAVA-COMFASTERXMLJACKSONCORE-2421244
  525
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Denial of Service (DoS) SNYK-JAVA-COMFASTERXMLJACKSONDATAFORMAT-1047329
  525
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Allocation of Resources Without Limits or Throttling SNYK-JAVA-SOFTWAREAMAZONION-6153869
  525
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found No Known Exploit

Denial of Service (DoS) SNYK-JAVA-COMFASTERXMLJACKSONCORE-3038424
  520
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found Proof of Concept

Deserialization of Untrusted Data SNYK-JAVA-COMFASTERXMLJACKSONCORE-450207
  520
com.amazonaws:aws-java-sdk-lambda:  1.11.264 -> 1.12.769  No Path Found Proof of Concept

Vulnerabilities that could not be fixed

Upgrade:

Could not upgrade<EMAIL_ADDRESS>to<EMAIL_ADDRESS>Reason could not apply upgrade, dependency is managed externally ; Location: provenance does not contain location

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Deserialization of Untrusted Data
🦉 XML External Entity (XXE) Injection
🦉 Denial of Service (DoS)
🦉 More lessons are available in Snyk Learn

Checkmarx One – Scan Summary & Details – 45dafbbf-46b4-4799-a7e1-6b72847bef99
New Issues

Severity
Issue
Source File / Package
Checkmarx Insight

CVE-2024-38996
Npm-ag-grid-community-29.3.5
Vulnerable Package

CVE-2023-34050
Maven-org.springframework.amqp:spring-amqp-2.0.5.RELEASE
Vulnerable Package

CVE-2024-23444
Maven-org.elasticsearch:elasticsearch-6.7.1
Vulnerable Package

CVE-2024-23444
Maven-org.elasticsearch:elasticsearch-6.8.17
Vulnerable Package

CVE-2024-29415
Npm-ip-1.1.9
Vulnerable Package

CVE-2024-29857
Maven-org.bouncycastle:bcprov-jdk15on-1.67
Vulnerable Package

CVE-2024-29857
Maven-org.bouncycastle:bcprov-jdk15on-1.56
Vulnerable Package

CVE-2024-30171
Maven-org.bouncycastle:bcprov-jdk15on-1.67
Vulnerable Package

CVE-2024-30171
Maven-org.bouncycastle:bcprov-jdk15on-1.56
Vulnerable Package

CVE-2024-30172
Maven-org.bouncycastle:bcprov-jdk15on-1.56
Vulnerable Package

CVE-2024-30172
Maven-org.bouncycastle:bcprov-jdk15on-1.67
Vulnerable Package

CVE-2024-37891
Python-urllib3-1.25.11
Vulnerable Package

CVE-2024-6484
Maven-org.webjars:bootstrap-3.3.2
Vulnerable Package

CVE-2024-6485
Maven-org.webjars:bootstrap-3.3.2
Vulnerable Package

Cleartext_Submission_of_Sensitive_Information
/lambda-functions/notification-es-logging-service/src/main/java/com/paladincloud/notification_log/config/AuthManager.java: 44
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/lambda-functions/notification-es-logging-service/src/main/java/com/paladincloud/notification_log/config/AuthManager.java: 44
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-rule-engine-2.0/src/main/java/com/tmobile/pacman/commons/autofix/manager/AuthManager.java: 41
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-aqua-enricher/src/main/java/com/tmobile/cso/pacman/aqua/jobs/AquaDataImporter.java: 37
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-rule-engine-2.0/src/main/java/com/tmobile/pacman/commons/autofix/manager/AuthManager.java: 41
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-rule-engine-2.0/src/main/java/com/tmobile/pacman/commons/autofix/manager/AuthManager.java: 41
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-asset/src/main/java/com/tmobile/pacman/api/asset/service/AssetServiceImpl.java: 856
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-rule-engine-2.0/src/main/java/com/tmobile/pacman/executor/PolicyExecutor.java: 141
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-rule-engine-2.0/src/main/java/com/tmobile/pacman/executor/PolicyExecutor.java: 141
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/gcp-discovery/src/main/java/com/tmobile/pacbot/gcp/inventory/auth/GCPCredentialsProvider.java: 281
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/azure-discovery/src/main/java/com/tmobile/pacbot/azure/inventory/auth/AzureCredentialProvider.java: 72
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/azure-discovery/src/main/java/com/tmobile/pacbot/azure/inventory/auth/AzureCredentialProvider.java: 67
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/gcp-discovery/src/main/java/com/tmobile/pacbot/gcp/inventory/auth/GCPCredentialsProvider.java: 281
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/azure-discovery/src/main/java/com/tmobile/pacbot/azure/inventory/auth/AzureCredentialProvider.java: 72
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/azure-discovery/src/main/java/com/tmobile/pacbot/azure/inventory/auth/AzureCredentialProvider.java: 67
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/service/AmazonCognitoConnector.java: 121
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-vulnerability/src/main/java/com/tmobile/pacman/api/vulnerability/service/VulnerabilityService.java: 973
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/gcp-discovery/src/main/java/com/tmobile/pacbot/gcp/inventory/auth/GCPCredentialsProvider.java: 281
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/azure-discovery/src/main/java/com/tmobile/pacbot/azure/inventory/auth/AzureCredentialProvider.java: 72
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/azure-discovery/src/main/java/com/tmobile/pacbot/azure/inventory/auth/AzureCredentialProvider.java: 67
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/gcp-discovery/src/main/java/com/tmobile/pacbot/gcp/inventory/auth/GCPCredentialsProvider.java: 143
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/gcp-discovery/src/main/java/com/tmobile/pacbot/gcp/inventory/auth/GCPCredentialsProvider.java: 144
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-data-shipper/src/main/java/com/tmobile/cso/pacman/datashipper/util/AssetGroupUtil.java: 391
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-data-shipper/src/main/java/com/tmobile/cso/pacman/datashipper/util/AssetGroupUtil.java: 373
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-data-shipper/src/main/java/com/tmobile/cso/pacman/datashipper/util/AssetGroupUtil.java: 391
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-data-shipper/src/main/java/com/tmobile/cso/pacman/datashipper/util/AssetGroupUtil.java: 373
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-data-shipper/src/main/java/com/tmobile/cso/pacman/datashipper/util/AssetGroupUtil.java: 391
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-data-shipper/src/main/java/com/tmobile/cso/pacman/datashipper/util/AssetGroupUtil.java: 373
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/controller/AccountsController.java: 59
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/controller/AccountsController.java: 59
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/controller/AccountsController.java: 59
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/controller/AccountsController.java: 59
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/controller/AccountsController.java: 59
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/lambda-functions/notification-template-formatter-service/src/main/java/com/paladincloud/HttpUtil.java: 154
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/lambda-functions/notification-send-email-service/src/main/java/com/paladincloud/utils/HttpUtil.java: 152
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/controller/AccountsController.java: 59
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/QualysAccountServiceImpl.java: 132
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/QualysAccountServiceImpl.java: 125
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/jobs/pacman-data-shipper/src/main/java/com/tmobile/cso/pacman/datashipper/util/AuthManager.java: 22
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 125
Attack Vector

Cleartext_Submission_of_Sensitive_Information
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/TenableAccountServiceImpl.java: 119
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 20540
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 20540
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 20540
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 20540
Attack Vector

Client_Potential_XSS
/webapp/src/app/shared/searchable-dropdown/searchable-dropdown.component.ts: 142
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 21841
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 21838
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 21831
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 21828
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 21825
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 21822
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger.js: 63
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 20550
Attack Vector

Client_Potential_XSS
/commons/pac-api-commons/src/main/resources/docs/v1/js/swagger-ui.js: 20547
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AbstractAccountServiceImpl.java: 111
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AbstractAccountServiceImpl.java: 106
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AbstractAccountServiceImpl.java: 111
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AbstractAccountServiceImpl.java: 106
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 151
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 154
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 151
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 154
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 151
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 154
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 151
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 154
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AbstractAccountServiceImpl.java: 111
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AbstractAccountServiceImpl.java: 106
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AbstractAccountServiceImpl.java: 111
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AbstractAccountServiceImpl.java: 106
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/controller/AccountsController.java: 59
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AbstractAccountServiceImpl.java: 89
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AwsAccountServiceImpl.java: 213
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AwsAccountServiceImpl.java: 216
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/QualysAccountServiceImpl.java: 155
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/QualysAccountServiceImpl.java: 158
Attack Vector

Privacy_Violation
/api/pacman-api-admin/src/main/java/com/tmobile/pacman/api/admin/repository/service/AquaAccountServiceImpl.java: 151
Attack Vector

Privacy_Violation

More results are available on AST platform


parser: support DEFAULT for insert values

Issue #3032
Add DEFAULT as a valid construct for expressions. This will allow
one to use it for insert values. It will be treated as a 'complex
expression', which means that it cannot be used in places where
vitess needs to extract the value, like primary keys or vindex
columns.

LGTM


Coordinate transformation issue

Hello there,
I'm doing some projects on Azure Kinect. These days I'm testing the accuracy of body tracking. Here is the method I use:

We record some videos with fake body models. And extract pictures from videos to get joints labeled.
Using body tracking SDK to track the body, and get every joints XYZ coordinates.
We use the labeled pixel coordinates from RGB as input value, and then we use function k4a_transformation_depth_image_to_color_camera, and k4a_calibration_2d_to_3d  to transform the pixel coordinate into 3D coordinate. At last we can compare those values.

But the result we get it's not that good.
Here is the joints information from body tracking SDK:
Joint[0]: Position[mm]( -309.316, -55.1283, 1671.32 ), Confidence Level: 2
Joint[1]: Position[mm]( -118.537, -38.9546, 1654.44 ), Confidence Level: 2
Joint[2]: Position[mm]( 34.537, -27.0045, 1648.4 ), Confidence Level: 2
Joint[3]: Position[mm]( 265.414, -4.12863, 1618.72 ), Confidence Level: 2
Joint[4]: Position[mm]( 224.833, 27.8237, 1629.71 ), Confidence Level: 2
Joint[5]: Position[mm]( 179.943, 174.777, 1640.14 ), Confidence Level: 2
Joint[6]: Position[mm]( -80.5916, 316.022, 1668.55 ), Confidence Level: 2
Joint[7]: Position[mm]( -281.283, 300.754, 1520.47 ), Confidence Level: 2
Joint[8]: Position[mm]( -329.715, 298.246, 1428.76 ), Confidence Level: 2
Joint[9]: Position[mm]( -391.972, 278.401, 1332.42 ), Confidence Level: 2
Joint[10]: Position[mm]( -391.598, 295.947, 1460.87 ), Confidence Level: 2
Joint[11]: Position[mm]( 230.003, -43.8087, 1619.77 ), Confidence Level: 2
Joint[12]: Position[mm]( 221.758, -180.513, 1583.47 ), Confidence Level: 2
Joint[13]: Position[mm]( 43.188, -424.398, 1557.9 ), Confidence Level: 2
Joint[14]: Position[mm]( -171.535, -405.077, 1425.42 ), Confidence Level: 2
Joint[15]: Position[mm]( -264.369, -408.492, 1363.39 ), Confidence Level: 2
Joint[16]: Position[mm]( -318.712, -320.925, 1313.67 ), Confidence Level: 2
Joint[17]: Position[mm]( -269.369, -333.964, 1391.64 ), Confidence Level: 2
Joint[18]: Position[mm]( -316.369, 41.9458, 1684.62 ), Confidence Level: 2
Joint[19]: Position[mm]( -708.604, 58.7787, 1506.05 ), Confidence Level: 2
Joint[20]: Position[mm]( -1107.46, 11.7344, 1598.79 ), Confidence Level: 2
Joint[21]: Position[mm]( -1284.57, 36.9256, 1505.34 ), Confidence Level: 2
Joint[22]: Position[mm]( -302.956, -142.664, 1659.32 ), Confidence Level: 2
Joint[23]: Position[mm]( -680.931, -194.054, 1459.04 ), Confidence Level: 2
Joint[24]: Position[mm]( -1083.1, -236.503, 1558.78 ), Confidence Level: 2
Joint[25]: Position[mm]( -1246.95, -252.316, 1472.83 ), Confidence Level: 2
Joint[26]: Position[mm]( 349.1, 6.18479, 1593.51 ), Confidence Level: 2
Joint[27]: Position[mm]( 378.135, 48.3661, 1428.14 ), Confidence Level: 2
Joint[28]: Position[mm]( 413.125, 74.4936, 1469.73 ), Confidence Level: 2
Joint[29]: Position[mm]( 399.255, 106.994, 1601.65 ), Confidence Level: 2
Joint[30]: Position[mm]( 419.419, 20.894, 1453.59 ), Confidence Level: 2
Joint[31]: Position[mm]( 433.528, -64.5769, 1565.04 ), Confidence Level: 2
And here is the transformed labeled coordinates:
Joint[0]: Position[mm]( -274.596, -12.1681, 1451.54 )org_depth: 1449
Joint[1]: Position[mm]( -161.392, -17.9969, 1546.41 )org_depth: 1544
Joint[2]: Position[mm]( 47.4067, -1.64799, 2177.4 )org_depth: 2170
Joint[3]: Position[mm]( 31.8102, 2.37145, -3.81127 )org_depth: 0
Joint[4]: Position[mm]( 303.621, 171.127, 2752.21 )org_depth: 2724
Joint[5]: Position[mm]( 157.824, 213.137, 1800.51 )org_depth: 1773
Joint[6]: Position[mm]( -121.214, 578.309, 2785.5 )org_depth: 2715
Joint[7]: Position[mm]( -584.836, 571.443, 2781.91 )org_depth: 2712
Joint[8]: Position[mm]( 31.8102, 2.37145, -3.81127 )org_depth: 0
Joint[9]: Position[mm]( 31.8102, 2.37145, -3.81127 )org_depth: 0
Joint[10]: Position[mm]( -797.593, 509.78, 2810.77 )org_depth: 2747
Joint[11]: Position[mm]( 210.646, -66.7472, 1744.33 )org_depth: 1746
Joint[12]: Position[mm]( 200.744, -177.343, 1553.91 )org_depth: 1568
Joint[13]: Position[mm]( 99.0491, -401.744, 1433.16 )org_depth: 1471
Joint[14]: Position[mm]( -333.32, -790.917, 2644.61 )org_depth: 2716
Joint[15]: Position[mm]( -450.385, -751.596, 2587.39 )org_depth: 2655
Joint[16]: Position[mm]( -647.554, -758.225, 2648.09 )org_depth: 2716
Joint[17]: Position[mm]( 31.8102, 2.37145, -3.81127 )org_depth: 0
Joint[18]: Position[mm]( -263.283, 95.6607, 1387.31 )org_depth: 1374
Joint[19]: Position[mm]( -720.545, 38.9658, 1416.76 )org_depth: 1409
Joint[20]: Position[mm]( -1269.49, 50.1684, 1697.57 )org_depth: 1687
Joint[21]: Position[mm]( -1483.72, 63.2647, 1681.9 )org_depth: 1670
Joint[22]: Position[mm]( -272.131, -127.709, 1427.49 )org_depth: 1437
Joint[23]: Position[mm]( -743.452, -177.219, 1438.59 )org_depth: 1453
Joint[24]: Position[mm]( 31.8102, 2.37145, -3.81127 )org_depth: 0
Joint[25]: Position[mm]( -1539.91, -317.924, 1716.79 )org_depth: 1744
Joint[26]: Position[mm]( 331.147, 33.2645, 1467.13 )org_depth: 1460
Joint[27]: Position[mm]( 441.111, 47.377, 1552 )org_depth: 1543
Joint[28]: Position[mm]( 433.547, 78.0642, 1456.66 )org_depth: 1445
Joint[29]: Position[mm]( 31.8102, 2.37145, -3.81127 )org_depth: 0
Joint[30]: Position[mm]( 452.54, 15.1049, 1498.39 )org_depth: 1493
Joint[31]: Position[mm]( 475.026, -62.5779, 1701.45 )org_depth: 1703
The value 0 we can understand, maybe in that position, the depth value is invalided, but the value over 2000, we are really confused. So could you please give me some information about it, and the code we write is based on example fastpointcloud.
And the last question is about the Confidence Level, we want to know the details of confidence level, for instance, the relationship between mAP and confidence level.
Thanks!

I would need to see photos of your setup to comment on the values >2000 mm.
Confidence levels are
NONE - Joint is out of range. Only applies to hand joints.
LOW - Joint was not returned by the DNN. Human model fitting predicted the joint location.
MEDIUM - Joint was returned by the DNN.
HIGH - Reserved.
We are investigating algorithms to differentiate between to accuracy numbers across MEDIMUM and HIGH i.e. HIGH = error < X cm and MEDIUM > X cm.

We use k4arecorder to record the video, and the  set up is 720P, 15FPS,  WFOV unbined.
And we use MKVToolNix and FFMPEG to extract RGB video and RGB photos to get labeled.
I reviewed the documentation about coordinate system. And we get confused about 2D coordinate system. In fact, the coordinates we get are based on pixel coordinates, but the 2D coordinates of the camera seem to be different from pixel coordinates, because pixel coordinates are integers. If they are different, is there any way to convert them?

I would need to see photos of your setup to comment on the values >2000 mm.
Confidence levels are
NONE - Joint is out of range. Only applies to hand joints.
LOW - Joint was not returned by the DNN. Human model fitting predicted the joint location.
MEDIUM - Joint was returned by the DNN.
HIGH - Reserved.
We are investigating algorithms to differentiate between to accuracy numbers across MEDIMUM and HIGH i.e. HIGH = error < X cm and MEDIUM > X cm.

We use k4arecorder to record the video, and the set up is 720P, 15FPS, WFOV unbined.
And we use MKVToolNix and FFMPEG to extract RGB video and RGB photos to get labeled.
I reviewed the documentation about coordinate system. And we get confused about 2D coordinate system. In fact, the coordinates we get are based on pixel coordinates, but the 2D coordinates of the camera seem to be different from pixel coordinates, because pixel coordinates are integers. If they are different, is there any way to convert them?

I would need to see photos of your setup to comment on the values >2000 mm.
Confidence levels are
NONE - Joint is out of range. Only applies to hand joints.
LOW - Joint was not returned by the DNN. Human model fitting predicted the joint location.
MEDIUM - Joint was returned by the DNN.
HIGH - Reserved.
We are investigating algorithms to differentiate between to accuracy numbers across MEDIMUM and HIGH i.e. HIGH = error < X cm and MEDIUM > X cm.

Thanks for replying.
We use k4arecorder to record the video, and the set up is 720P, 15FPS, WFOV unbined.
And we use MKVToolNix and FFMPEG to extract RGB video and RGB photos to get labeled.
I reviewed the documentation about coordinate system. And we get confused about 2D coordinate system. In fact, the coordinates we get are based on pixel coordinates, but the 2D coordinates of the camera seem to be different from pixel coordinates, because pixel coordinates are integers. If they are different, is there any way to convert them?

@jean1zhou I am not fully understanding your issue and have some additional clarifying questions.
Are you recording both RGB and depth in the videos?
What do you mean by joint labels? Is that the skeleton joints?
By xyz coordinates are you referring to the skeleton joint coordinates as returned by body tracking SDK?
What do you mean by the labeled pixel coordinates from RGB?
k4a_transformation_depth_image_to_color_camera takes the depth map from the depth sensor and computes a depth map for the RGB sensor. That means for each RGB pixel, now you have a corresponding depth value. How does this RGB depth map compare to the depth map from the depth sensor?
k4a_calibration_2d_to_3d takes one RGB pixel and one RGB depth value from the depth map obtained above to map that pixel back to the XYZ in the depth camera space. The z value obtained would be within a few mm from the input depth.
Which RGB 2d pixels are transformed back to 3D? You do not mention using the reverse API: k4a_calibration_3d_to_2d to project the XYZ joints into RGB pixels. Are you choosing different pixels?
2d coordinates are in pixels as described here: https://docs.microsoft.com/en-us/azure/kinect-dk/coordinate-systems.

@jean1zhou I am not fully understanding your issue and have some additional clarifying questions.
Are you recording both RGB and depth in the videos?
What do you mean by joint labels? Is that the skeleton joints?
By xyz coordinates are you referring to the skeleton joint coordinates as returned by body tracking SDK?
What do you mean by the labeled pixel coordinates from RGB?
k4a_transformation_depth_image_to_color_camera takes the depth map from the depth sensor and computes a depth map for the RGB sensor. That means for each RGB pixel, now you have a corresponding depth value. How does this RGB depth map compare to the depth map from the depth sensor?
k4a_calibration_2d_to_3d takes one RGB pixel and one RGB depth value from the depth map obtained above to map that pixel back to the XYZ in the depth camera space. The z value obtained would be within a few mm from the input depth.
Which RGB 2d pixels are transformed back to 3D? You do not mention using the reverse API: k4a_calibration_3d_to_2d to project the XYZ joints into RGB pixels. Are you choosing different pixels?
2d coordinates are in pixels as described here: https://docs.microsoft.com/en-us/azure/kinect-dk/coordinate-systems.

I'm sorry I didn't clarify the questions.

We recorded both RGB and depth in videos using k4arecorder. And we use play back function and Body Tracking SDK to track those videos. The output is every skeleton joint's xyz coordinates.

Then I use MKVToolNix to split RGB videos from original videos, because the original videos has both RGB videos and depth videos. After that I use FFMPEG to extract RGB pictures from RGB videos we just splited FPS by FPS.

To extract RGB pictures from RGB videos is to label 32 skeleton joints manually. Because we want to compare the skeleton joints' coordinates from body tracking SDK with the skeleton joints' coordinates we labeled manually, to check the precision.

To compare those coordinates we have to transform the coordinates we labeled manually to 3D because it's pixels coordinates. And the coordinates from Body Tracking SDK is 3D.

We use coordinates we labeled manually as input value, then we use k4a_transformation_depth_image_to_color_camera, and k4a_calibration_2d_to_3d functions to transform the 2D coordinates to 3D.

We successfully transformed the 2D coordinates into 3D, however the result is not that good. We have no ideas why it looks like that. You can refer to the coordinates information above.

At last we tried k4a_calibration_3d_to_2d to project the XYZ joints into RGB pixels. The result is way better than 3D. The gap between the skeleton joints' coordinates we labeled and the skeleton joints' coordinates we transformed from body tracking SDK is not that big. I will copy the information above.

The coordinates (x,y) we labeled manually from RGB Photo：
510.323915, 441.259191
553.108201, 439.053309
614.417643, 439.494485
677.415946, 432.958884
656.760855, 467.288603
648.821502, 503.465074
595.892488, 559.494485
576.485183, 598.759191
547.815300, 613.759191
515.616816, 600.965074
546.933150, 583.759191
657.201930, 398.465074
662.053756, 360.965074
681.461061, 275.376838
681.019986, 303.612132
663.376981, 314.200368
644.410751, 296.112132
644.410751, 318.612132
512.529290, 490.670956
307.870434, 470.376838
165.403170, 458.023897
104.975879, 469.494485
511.206065, 392.288603
302.136458, 406.847426
158.345968, 407.288603
88.912189, 388.688811
690.747051, 435.262238
723.460026, 432.325175
741.494102, 440.716783
729.750983, 458.758741
736.041940, 415.541958
723.879423, 392.465035
The coordinates (x,y) from Body Tracking SDK transformed to 2D:
477.577, 422.961
541.43, 423.25
593.115, 423.923
665.82, 426.89
653.569, 438.127
640.078, 486.232
577.384, 564.553
542.743, 605.35
519.904, 604.048
491.604, 604.738
495.665, 603.196
654.563, 414.718
653.344, 369.738
677.487, 275.428
727.215, 269.173
762.261, 262.714
773.116, 255.782
754.914, 292.675
475.657, 456.271
326.204, 459.947
194.823, 459.723
101.325, 466.773
479.209, 393.465
323.128, 391.36
194.864, 397.834
110.253, 395.488
693.244, 428.248
712.914, 427.319
724.93, 436.414
717, 456.322
722.744, 417.191
714.174, 398.882
The first problem is that we used k4a_transformation_depth_image_to_color_camera, which means that each pixel has a corresponding depth information. We want to extract the depth information of the pixels we interested, such as the depth information of (100, 100) pixels, but at present we have not found the corresponding function to directly extract or output the depth information of the corresponding pixels.
The second problem is that we used k4a_calibration_2d_to_3d to transform the coordinates of skeleton joints that we manually labeled into 3D coordinates, but it is very different from the skeleton joints coordinates detected by body tracking SDK, especially the depth information. But when we use k4a_calibration_3d_to_2d, the difference is not big. So we want to figure out where the problem is.
Thanks.

Hi @jean1zhou ,
I am having troubles transforming the images with k4a_transformation_depth_image_to_color_camera
I tried to convert the video in the playback mode but I couldn't do it.
My only goal is to get the transformed image
How did you exactly do it?
Can you contact me here or via mail<EMAIL_ADDRESS>I appreciate your help!

I'm sorry, I disturbed you
I use C# to develop the program.
Does k4a_calibration_2d_to_3d and k4a_calibration_3d_to_2d have the version used by C# or VB.net?

Hi i'm facing the same questions.
Have you made any progress recently?

@jean1zhou I am not fully understanding your issue and have some additional clarifying questions.
Are you recording both RGB and depth in the videos?
What do you mean by joint labels? Is that the skeleton joints?
By xyz coordinates are you referring to the skeleton joint coordinates as returned by body tracking SDK?
What do you mean by the labeled pixel coordinates from RGB?
k4a_transformation_depth_image_to_color_camera takes the depth map from the depth sensor and computes a depth map for the RGB sensor. That means for each RGB pixel, now you have a corresponding depth value. How does this RGB depth map compare to the depth map from the depth sensor?
k4a_calibration_2d_to_3d takes one RGB pixel and one RGB depth value from the depth map obtained above to map that pixel back to the XYZ in the depth camera space. The z value obtained would be within a few mm from the input depth.
Which RGB 2d pixels are transformed back to 3D? You do not mention using the reverse API: k4a_calibration_3d_to_2d to project the XYZ joints into RGB pixels. Are you choosing different pixels?
2d coordinates are in pixels as described here: https://docs.microsoft.com/en-us/azure/kinect-dk/coordinate-systems.

I'm sorry I didn't clarify the questions.

We recorded both RGB and depth in videos using k4arecorder. And we use play back function and Body Tracking SDK to track those videos. The output is every skeleton joint's xyz coordinates.
Then I use MKVToolNix to split RGB videos from original videos, because the original videos has both RGB videos and depth videos. After that I use FFMPEG to extract RGB pictures from RGB videos we just splited FPS by FPS.
To extract RGB pictures from RGB videos is to label 32 skeleton joints manually. Because we want to compare the skeleton joints' coordinates from body tracking SDK with the skeleton joints' coordinates we labeled manually, to check the precision.
To compare those coordinates we have to transform the coordinates we labeled manually to 3D because it's pixels coordinates. And the coordinates from Body Tracking SDK is 3D.
We use coordinates we labeled manually as input value, then we use k4a_transformation_depth_image_to_color_camera, and k4a_calibration_2d_to_3d functions to transform the 2D coordinates to 3D.
We successfully transformed the 2D coordinates into 3D, however the result is not that good. We have no ideas why it looks like that. You can refer to the coordinates information above.
At last we tried k4a_calibration_3d_to_2d to project the XYZ joints into RGB pixels. The result is way better than 3D. The gap between the skeleton joints' coordinates we labeled and the skeleton joints' coordinates we transformed from body tracking SDK is not that big. I will copy the information above.

The coordinates (x,y) we labeled manually from RGB Photo：
510.323915, 441.259191 553.108201, 439.053309 614.417643, 439.494485 677.415946, 432.958884 656.760855, 467.288603 648.821502, 503.465074 595.892488, 559.494485 576.485183, 598.759191 547.815300, 613.759191 515.616816, 600.965074 546.933150, 583.759191 657.201930, 398.465074 662.053756, 360.965074 681.461061, 275.376838 681.019986, 303.612132 663.376981, 314.200368 644.410751, 296.112132 644.410751, 318.612132 512.529290, 490.670956 307.870434, 470.376838 165.403170, 458.023897 104.975879, 469.494485 511.206065, 392.288603 302.136458, 406.847426 158.345968, 407.288603 88.912189, 388.688811 690.747051, 435.262238 723.460026, 432.325175 741.494102, 440.716783 729.750983, 458.758741 736.041940, 415.541958 723.879423, 392.465035
The coordinates (x,y) from Body Tracking SDK transformed to 2D:
477.577, 422.961 541.43, 423.25 593.115, 423.923 665.82, 426.89 653.569, 438.127 640.078, 486.232 577.384, 564.553 542.743, 605.35 519.904, 604.048 491.604, 604.738 495.665, 603.196 654.563, 414.718 653.344, 369.738 677.487, 275.428 727.215, 269.173 762.261, 262.714 773.116, 255.782 754.914, 292.675 475.657, 456.271 326.204, 459.947 194.823, 459.723 101.325, 466.773 479.209, 393.465 323.128, 391.36 194.864, 397.834 110.253, 395.488 693.244, 428.248 712.914, 427.319 724.93, 436.414 717, 456.322 722.744, 417.191 714.174, 398.882
The first problem is that we used k4a_transformation_depth_image_to_color_camera, which means that each pixel has a corresponding depth information. We want to extract the depth information of the pixels we interested, such as the depth information of (100, 100) pixels, but at present we have not found the corresponding function to directly extract or output the depth information of the corresponding pixels.
The second problem is that we used k4a_calibration_2d_to_3d to transform the coordinates of skeleton joints that we manually labeled into 3D coordinates, but it is very different from the skeleton joints coordinates detected by body tracking SDK, especially the depth information. But when we use k4a_calibration_3d_to_2d, the difference is not big. So we want to figure out where the problem is.
Thanks.

Hello,  I have the same problem recently. Could you tell me how you finally solved it?


Cannot read property 'config' of null

I upgraded a project to postcss-loader 1.0.0 and during the build, I've noticed this error:
TypeError: Cannot read property 'config' of null
    at /Users/tleunen/dev/xxxx/node_modules/postcss-load-config/index.js:50:22

OS
Node
npm
PostCSS

MacOS 10.12
6.9.1
3.10.8
1.0.0

Duplicate of #26 and already fixed. nvm. Thanks :)


VSCode intellisense — TypeScript type Promise<> displays its contents as if awaited

Does this issue occur when all extensions are disabled?: Yes — Tested with browser incognito at https://vscode.dev

VS Code Version: 1.70.1
OS Version: Windows 11 Pro 64-bit

I must admit that I cannot fathom the core of this problem. A Promise in TypeScript is displayed in VSCode's intellisense, as if its awaited like seen on these images:
In TypeScript Playground I get following result:

However inside VSCode, the promise is as if its awaited:

I cannot replicate a simple version of my issue, but you can experience same phenomenon by following the reproduction
Because of the Promise being displayed correctly in the TypeScript Playground, I add this issue @ VSCode
Steps to Reproduce:

Open an incognito browser and visit https://vscode.dev/ and open a new tab
Visit my reproduction from TypeScript Playground
Copy the contents of the playground into the VSCode tab
At the bottom of the file (at line 187), add a period and use VSCode intellisense to get results - which should display as the image above

I apologize for the complexity of the situation, for I am not exactly sure what causes the bug.

ig this is working as intended. Vscode shows properties that'll be available after u resolve the promise. If you accept the IntelliSense, vscode will add await automatically for you.

I also remember this as a feature. Properties of Promise (.then, .catch and .finally) are still there if you need.

ig this is working as intended. Vscode shows properties that'll be available after u resolve the promise. If you accept the IntelliSense, vscode will add await automatically for you.

The statement is not awaited at all. Hence Promise<> — so if I were to actually use one of the suggested options from the VSCode intellisense, I would get an error — because the Promise is not fulfilled; it has not been awaited.
If this is feature of VSCode, can you perhaps tell me how to turn it off, to avoid confusion of unfulfilled promises?

This is the behaviour I am expecting (from TS Playground)
Here's what I would've expected; the promise is not fulfilled, and will not suggest unavailable properties:

Notice that it does not show properties that would be undefined, from an unawaited/unfulfilled promise.
Here's an awaited statement

The reason this is important to me, is to not confuse new developers to the API, and to throw intellisense errors to avoid having to debug after compile-time.

As mentioned above - accepting this suggestion should add (await promiseExpr).acceptedProperty and not just promiseExpr.acceptedProperty (which would be an error).
Do you see some other behavior when you accept these suggestions in async functions?

As mentioned above - accepting this suggestion should add (await promiseExpr).acceptedProperty and not just promiseExpr.acceptedProperty (which would be an error).
Do you see some other behavior when you accept these suggestions in async functions?

I don't — but as you mention, it seems to be a bug within async function or async () =>
Works as expected:

Combines Promise<T> with T:

* When I say combine, notice that it shows then, catch, finally, but also the result of the promise; T
Awaiting the promise (await promise). works as expected

And with that said, the issue seems to be, that it combines the Promise<T> with T inside async function's when they're not awaited:

Back to "this is a feature", if it was a feature, then shouldn't foo be undefined (and not true), since the promise has not been fulfilled?

shouldn't foo be undefined (and not true), since the promise has not been fulfilled?

Not sure how what do you mean under "has not been fulfilled" here? At code edit time there are no pendings/fullilled/rejected promises, but there are are code and types.
t has declared promise type and  foo should be true according to declaration for awaited promise. It's inside of async function therefore showed in suggestions with it's supposed type (when awaited, because suggestion is for awaited type, otherwise all these suggestions would be undefined).
See https://github.com/microsoft/TypeScript/issues/31450 tracking issue that was implemented in TS 3.7

shouldn't foo be undefined (and not true), since the promise has not been fulfilled?

Not sure how what do you mean under "has not been fulfilled" here? At code edit time there are no pending/fullilled/rejected promises, but there are are code and types.
t has declared promise type and foo should be true according to declaration for awaited promise. It's inside of async function therefore showed in suggestions with it's supposed type (when awaited, because suggestion is for awaited type, otherwise all these suggestions would be undefined).
See microsoft/TypeScript#31450 tracking issue that was implemented in TS 3.7

My bad, I overread the "automatically adds await"
Now I know this goes from bug to opinion — it seems to act more of a distraction and diminishes fast interpretation of the type:

The type in my case is K & Promise<T>, and so there will be more properties than external to what can be awaited. In the picture above you see 2× ok, where one is a function derived from said type K, and another is a boolean found in the Response type from the Promise.
The types describe what status-codes are returned from from a backend which is generated locally.
Unfortunately, I don't see any way to turn this off at the moment. And I cannot use a utility type like Omit to get rid of the extra suggestions. Maybe an option where it will only suggests to auto-await if it only consists of a Promise type, and no intersection/union.
Thanks for the clarification


Fix/31863: Don't allow member to edit task in room

Details

Don't allow member to edit task in room
Fixed Issues

$ https://github.com/Expensify/App/issues/31863
PROPOSAL: https://github.com/Expensify/App/issues/31863#issuecomment-1826371354
Tests

Create a workspace
Go to settings > workspace > members
Add userB as member
Go to #annoince
Click on + icon and select assign task
Enter title and description
Assign it to yourself and create a task
Sign in as userB
Go to task report screen
Edit the task details
Verify that user B can't edit task

[x] Verify that no errors appear in the JS console

Offline tests

same above
QA Steps

Create a workspace
Go to settings > workspace > members
Add userB as member
Go to #annoince
Click on + icon and select assign task
Enter title and description
Assign it to yourself and create a task
Sign in as userB
Go to task report screen
Edit the task details
Verify that user B can't edit task

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[x] MacOS: Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native
https://github.com/Expensify/App/assets/141406735/d4d59c81-6c5e-4d5e-a401-b555c1039d51

Android: mWeb Chrome
https://github.com/Expensify/App/assets/141406735/25ebe7b6-d691-427d-8cc3-dbbdfea34ac4

iOS: Native
https://github.com/Expensify/App/assets/141406735/a2de4b15-2bee-45c0-af09-a089a55789c5

iOS: mWeb Safari

https://github.com/Expensify/App/assets/141406735/098e0a70-b987-4e84-8639-884aba09f776

MacOS: Chrome / Safari

https://github.com/Expensify/App/assets/141406735/26426c87-6b61-410d-a05b-5cc6004e2ffb

MacOS: Desktop

https://github.com/Expensify/App/assets/141406735/ea5734af-03e3-4e3f-a3b3-9d33c85b3ee2

@Ollyws Updated to cover policy expense chat. Thanks

@aldo-expensify @Ollyws I updated as this comment

I still investigate how to import lodash correctly to fix lint

@aldo-expensify Updated. please check again

@Ollyws @aldo-expensify Fixed lint. All yours

@Ollyws @aldo-expensify Bump on this one

@Ollyws please retest, web may be enough?

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/aldo-expensify in version: 1.4.14-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/aldo-expensify in version: 1.4.14-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/jasperhuangg in version: 1.4.14-6 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


Instruction of building the module

Hi, I am on the latest FW, 4.32.* and I think because of that I cannot make to work my bt keyboard. Can you provide instruction for building the module? :)
btw. SUPER COOL WORK, thanks :)

I use the concept of  below site to build the uhid.ko.
https://blukat.me/2017/12/cross-compile-arm-kernel-module/
Just remember to copy /proc/config.gz from your device.
By the way, I use Windows 10 WSL + Docker Desktop to build the uhid.ko.
https://youtu.be/eSjBcCf5axo
If you need more steps, please let me know.

what's the easiest way to copy /proc/config.gz ? :)

There is no easy way to copy /proc/config.gz. However, I use NickelMenu to telnet into the device.
menu_item :main    :Telnet (toggle)          :cmd_output         :500:quiet :/usr/bin/pkill -f "^/usr/bin/tcpsvd -E <IP_ADDRESS> 1023"
  chain_success:skip:5
  chain_failure                              :cmd_spawn          :quiet :/bin/mount -t devpts | /bin/grep -q /dev/pts || { /bin/mkdir -p /dev/pts && /bin/mount -t devpts devpts /dev/pts; }
  chain_success                              :cmd_spawn          :quiet :exec /usr/bin/tcpsvd -E <IP_ADDRESS> 1023 /usr/sbin/telnetd -i -l /bin/login
  chain_success                              :dbg_toast          :Started Telnet server on port 1023
  chain_failure                              :dbg_toast          :Error starting Telnet server on port 1023
  chain_always:skip:-1
  chain_success                              :dbg_toast          :Stopped Telnet server on port 1023

The user name is "root". The password is empty.
When you telnet into the device, you can use cp command to copy the config.gz.
cp /proc/config.gz /mnt/onboard/

Then you can use PC to get the file.
By the way, I use oldconfig parameter to build kernel so I use text editor to edit the extracted config (from config.gz) to add uhid module support.
CONFIG_UHID=m

I don't try this yet, However, make can support the ko target rule (from Makefile) in theory.
make ARCH=arm CROSS_COMPILE=<TOOLCHAIN_DIR>/bin/arm-linux-gnueabihf- drivers/hid/uhid.ko

I add steps to build the kernel, you could refer to README.md.

Just a note to say that building just drivers/hid/uhid.ko appeared to work for me, but the resulting file failed when I ran insmod on it on the kobo. Building the whole tree produced a uhid.ko that inserted ok (now I just need to figure out what /other/ config setting I need to get the bluetooth device I've got working....)


Clone occupation standard endpoint

closes #99
This PR includes some changes in prep for editing a skill. I ended up using the join table ids (for occupation_standard_work_processes and occupation_standard_skills) as the main ids in the URLs. Wasn't that wild about doing it, but it seems to work the best for the JSON API specifications.
Changes

Flesh out complete occupation standard response so it includes work_process and skills relationships.
Add clone occupation standard endpoint.
Add Pundit gem in prep for edit authorization.

QA

[x] Sign in and view documentation<EMAIL_ADDRESS>[ ] View occupation standard per specs
[ ] Verify you can follow the relationship and related links in the response
[ ] Clone occupation standard per specs

@littleforest is this duplication expected for the api's occupation standard show response?
...
      "relationships": {
            "work_processes": {
                "data": [
                    {
                        "id": "1",
                        "type": "work_process"
                    },
                    {
                        "id": "1",
                        "type": "work_process"
                    },
                    {
                        "id": "2",
                        "type": "work_process"
                    },
                    {
                        "id": "2",
                        "type": "work_process"
                    },
...

@Pcushing I'm returning it per the Compound Documents spec, but it is optional, so I can remove it if needed.  But I think Jake will need that data for the front-end so he doesn't have to make multiple requests.

@littleforest good to go!


Supremum inheritance between layers fails

We would actually like to do this properly (#136), but that seems to be to complicated currently.
So here we track the bugs with our current approach.
The example from #136:
julia> typecheck_hs_from_string_detailed("module F
        function test()
          a = 3
          b = 5
          function f(a,b)
            a1 = 7
            function g(ff)
              (a,b) -> ff(a,b)
            end
            function h(a,b)
              b1 = 3
              a + b1
            end
            g(h)(a1,b)
          end
          y = b + 12
          b2 = 9
          x = a
          a2 = 12
          f(x,y)
        end
         end

       ")

We now get:
---------------------------------------------------------------------------
Type:
{
  --------------------------
   -> Int[10.0 ©]

}
---------------------------------------------------------------------------
Monad state:

State:
- watcher: IsChanged
- messages: (hidden)

Meta:
- sens vars: []
- type vars: [τ_20 : *, τ_19 : *, τ_13 : *, τ_12 : *]
- name vars: []
- sens subs:   s_10 := ∑∅, s_5 := ∑∅, s_0 := ∑∅, η_9 := ∑∅, η_2 := ∑∅, s_7 := ∑∅, s_4 := 1, η_3 := ∑∅, s_6 := ∑∅, η_8 := ∑∅, s_1 := ∑∅
- type subs:   τa_16 := Num(IR Int[12.0 ©]), τ_8 := NoFun(Num(IR Int[17.0 ©])), τ_10 := NoFun(Num(IR Int[17.0 ©])), τr_6 := Num(IR Int[10.0 ©]), τa_5 := Num(IR Int[3.0 ©]), τ_3 := NoFun(Num(IR Int[10.0 ©])), τ_22 := IR Int, τ_25 := Int, τ_28 := Int, τ_1 := NoFun(Num(IR Int[7.0 ©])), τr_17 := Num(IR Int[17.0 ©]), τ_30 := Int, τ_27 := Int, τ_11 := NoFun(Num(IR Int[10.0 ©])), τ_2 := NoFun(Num(IR Int[17.0 ©])), τ_9 := Fun([([NoFun(Num(IR Int[7.0 ©])) @ s_5,NoFun(Num(IR Int[17.0 ©])) @ s_6] -> NoFun(Num(IR Int[10.0 ©]))) @ Nothing]), τ_21 := IR Int, τ_24 := Int, τa_15 := Num(IR Int[5.0 ©]), τ_14 := NoFun(Num(IR Int[3.0 ©])), τa_4 := Num(IR Int[7.0 ©]), τ_0 := Fun([([NoFun(Num(IR Int[7.0 ©])) @ s_0,NoFun(Num(IR Int[17.0 ©])) @ s_1] -> NoFun(Num(IR Int[10.0 ©]))) @ Nothing]), τ_7 := NoFun(Num(IR Int[7.0 ©])), τ_18 := NoFun(Num(IR Int[10.0 ©])), τ_23 := Int, τ_26 := Int, τ_29 := Int
- fixed TVars:
- constraints:
   - top:

   - others:
[]

Types:
Left

All (relevant) tests now pass again.


Allow force-triggering xDS updates in linear cache for a specific stream

Signed-off-by: Sergey Matyukevich<EMAIL_ADDRESS>

I'm not sure you will be able to drive this from the cache itself, as the delta server takes strong assumptions that a watch can fire at most once


error: when using  torch(1.8.0+cu111)

Traceback (most recent call last):

  File "translate_test.py", line 66, in <module>

    translate_test()

  File "translate_test.py", line 30, in translate_test

    rest = mt.predict(texts, _from = 'en',batch_size = size)

  File "/mnt/eclipse-glority/receipt/deploy/branches/dev/ms_deploy/util/translate_util.py", line 29, in predict

    rest = self.mt.translate(texts, source=_from, target=_to, batch_size = batch_size)

  File "/home/hyj/anaconda3/envs/tf25/lib/python3.7/site-packages/dl_translate/_translation_model.py", line 197, in translate

    **encoded, **generation_options

  File "/home/hyj/anaconda3/envs/tf25/lib/python3.7/site-packages/torch/autograd/grad_mode.py", line 27, in decorate_context

    return func(*args, **kwargs)

  File "/home/hyj/anaconda3/envs/tf25/lib/python3.7/site-packages/transformers/generation_utils.py", line 927, in generate

    model_kwargs = self._prepare_encoder_decoder_kwargs_for_generation(input_ids, model_kwargs)

  File "/home/hyj/anaconda3/envs/tf25/lib/python3.7/site-packages/transformers/generation_utils.py", line 412, in _prepare_encoder_decoder_kwargs_for_generation

    model_kwargs["encoder_outputs"]: ModelOutput = encoder(input_ids, return_dict=True, **encoder_kwargs)

  File "/home/hyj/anaconda3/envs/tf25/lib/python3.7/site-packages/torch/nn/modules/module.py", line 889, in _call_impl

    result = self.forward(*input, **kwargs)

  File "/home/hyj/anaconda3/envs/tf25/lib/python3.7/site-packages/transformers/models/m2m_100/modeling_m2m_100.py", line 780, in forward

    output_attentions=output_attentions,

  File "/home/hyj/anaconda3/envs/tf25/lib/python3.7/site-packages/torch/nn/modules/module.py", line 889, in _call_impl

    result = self.forward(*input, **kwargs)

  File "/home/hyj/anaconda3/envs/tf25/lib/python3.7/site-packages/transformers/models/m2m_100/modeling_m2m_100.py", line 388, in forward

    hidden_states = self.activation_fn(self.fc1(hidden_states))

  File "/home/hyj/anaconda3/envs/tf25/lib/python3.7/site-packages/torch/nn/modules/module.py", line 889, in _call_impl

    result = self.forward(*input, **kwargs)

  File "/home/hyj/anaconda3/envs/tf25/lib/python3.7/site-packages/torch/nn/modules/linear.py", line 94, in forward

    return F.linear(input, self.weight, self.bias)

  File "/home/hyj/anaconda3/envs/tf25/lib/python3.7/site-packages/torch/nn/functional.py", line 1753, in linear

    return torch._C._nn.linear(input, weight, bias)

RuntimeError: CUDA error: CUBLAS_STATUS_EXECUTION_FAILED when calling `cublasSgemm( handle, opa, opb, m, n, k, &alpha, a, lda, b, ldb, &beta, c, ldc)`

torch                            1.8.0+cu111

torchvision                      0.9.0+cu111

it is ok, when
torch                            1.7.1+cu101
how to fix ?

I just tried installing and running dl-translate on Colab (torch 1.10 + cu111) and it works fine: https://colab.research.google.com/drive/14LzNXeGx4eFO0YyjGgRrVj7E3tVSQPUP?usp=sharing
Could you try creating a virtualenv and upgrading torch? Also I suggest testing Huggingface models directly (see M2M100 docs) and if the error happens again then you could try to open an issue in their repo.

done!  It is ok...
thanks...


Litecoind LND start failure -8: Block height out of range

Background
LND fails to start on Litecoind testnet
Your environment

lnd version 0.5.0-beta commit=baee07ef480c15a731e0c87dc98d27269c5a80fa
Linux 3.16.0-6-amd64 #1 SMP Debian 3.16.56-1+deb8u1 (2018-05-08) x86_64 GNU/Linux
Litecoin Core Daemon version v0.16.2  eba0e1ca3fb4088998461b02ec6831858cc24144

~/.litecoin/litecoin.conf
testnet=1
txindex=1
server=1
; daemon=1
debug=1
discardfee=0.00000001
mintxfee=0.00000001
minrelaytxfee=0.00000001
rpcuser=jason
rpcpassword=litecoin
zmqpubrawblock=tcp://<IP_ADDRESS>:28332
zmqpubrawtx=tcp://<IP_ADDRESS>:28333

tail -n1000 ~/.litecoin/testnet4/debug.log |grep UpdateTip   | awk '{print $1, $2, $6, $10, $11, $12}'
2018-09-06 03:38:31 height=724100 date='2018-09-06 03:38:17' progress=1.000000
2018-09-06 03:40:34 height=724101 date='2018-09-06 03:40:21' progress=1.000000
2018-09-06 03:41:07 height=724102 date='2018-09-06 03:40:34' progress=1.000000
2018-09-06 03:50:05 height=724103 date='2018-09-06 03:49:48' progress=1.000000
2018-09-06 03:54:18 height=724104 date='2018-09-06 03:54:05' progress=1.000000

Steps to reproduce
lnd --externalip=$(dig +short myip.opendns.com @resolver1.opendns.com)

Expected behaviour
Start normal
Actual behaviour
2018-09-05 20:51:18.488 [INF] LTND: Version 0.5.0-beta commit=baee07ef480c15a731e0c87dc98d27269c5a80fa
2018-09-05 20:51:18.489 [INF] LTND: Active chain: Litecoin (network=testnet)
2018-09-05 20:51:18.489 [INF] CHDB: Checking for schema update: latest_version=6, db_version=6
2018-09-05 20:51:18.506 [INF] RPCS: password gRPC proxy started at <IP_ADDRESS>:8080
2018-09-05 20:51:18.507 [INF] RPCS: password RPC server listening on <IP_ADDRESS>:10009
2018-09-05 20:51:18.507 [INF] LTND: Waiting for wallet encryption password. Use `lncli create` to create a wallet, `lncli unlock` to unlock an existing wallet, o
r `lncli changepassword` to change the password of an existing wallet and unlock it.
2018-09-05 20:51:28.192 [INF] LTND: Primary chain is set to: litecoin
2018-09-05 20:51:28.205 [INF] LTND: Initializing litecoind backed fee estimator
2018-09-05 20:51:29.411 [INF] LTND: LightningWallet opened
2018-09-05 20:51:29.419 [INF] HSWC: Restoring in-memory circuit state from disk
2018-09-05 20:51:29.420 [INF] HSWC: Payment circuits loaded: num_pending=0, num_open=0
2018-09-05 20:51:29.439 [INF] RPCS: gRPC proxy started at <IP_ADDRESS>:8080
2018-09-05 20:51:29.439 [INF] RPCS: RPC server listening on <IP_ADDRESS>:10009
2018-09-05 20:51:29.446 [INF] LTND: Waiting for chain backend to finish sync, start_height=724103
2018-09-05 20:51:30.457 [INF] LTND: Chain backend is fully synced (end_height=724103)!
2018-09-05 20:51:30.464 [INF] HSWC: Starting HTLC Switch
2018-09-05 20:51:30.464 [INF] NTFN: New block epoch subscription
2018-09-05 20:51:30.464 [INF] NTFN: New block epoch subscription
2018-09-05 20:51:30.464 [INF] NTFN: New block epoch subscription
2018-09-05 20:51:30.467 [INF] DISC: Authenticated Gossiper is starting
2018-09-05 20:51:30.467 [INF] BRAR: Starting contract observer, watching for breaches.
2018-09-05 20:51:30.467 [INF] NTFN: New block epoch subscription
2018-09-05 20:51:30.614 [ERR] SRVR: unable to start server: -8: Block height out of range

2018-09-05 20:51:30.615 [INF] LTND: Shutdown complete
-8: Block height out of range

very similar issue with ltcd
ltcd version 0.12.0-beta https://github.com/ltcsuite/ltcd/commit/cdab10132e8c6e4a3ffd112dba54791946d28906
2018-09-06 13:23:26.341 [INF] NTFN: New block epoch subscription
2018-09-06 13:23:30.546 [ERR] SRVR: unable to start server: -1: Block number out of range

2018-09-06 13:23:30.547 [INF] LTND: Shutdown complete
-1: Block number out of range

@alevchuk i've seen this issue before and i think it has to do with LND having tx information that doesn't match your ltcd/litecoind nodes. You can find the offending code for ltcd here.
Reproduction case:
Start a new testnet node (not synced) w/ LND after LND had already been indexed with an up-to-date testnet node


Quick, Non-Data-Driven Quantization

ExLlamaV2 is undoubtedly one of the most popular and efficient backends for running LLMs locally. However, the current data-driven quantization method, while producing highly accurate models, can be quite time-consuming due to the numerous forward passes required. This can make it difficult to quickly assess new models through quantization.
I'd like to propose adding a quick, non-data-driven quantization method to ExLlamaV2. This would allow users to gain a rapid understanding of a new model's capabilities before potentially opting for a more comprehensive, data-driven quantization process.
This initial, faster method could serve as an excellent starting point for evaluating models, while the existing data-driven approach would remain available for those seeking the highest levels of accuracy.
Thank you for considering this feature request!

There is a load_in_q4 param that can be passed in ExLlamaV2Config that allows on-the-fly Q4 quant of an fp16 model, although it is slow and poor quality compared to the regular quants.

There is load_in_q4, yes, but that's mostly for testing purposes, so I can verify that a new architecture works before I move on to fixing any issues with quantizing it, for models that I can't load in full precision.
A strictly RTN quantization isn't a terrible idea, but I'm not sure it's worth the added complexity and the confusion it would cause when people fail to understand that the RTN models aren't just a faster way to make EXL2 models and start distributing them. Probably the way to go would be to add support for AWQ or some other simple format.
Not really where my priorities are at the moment though.


fix(gateway template): patch gateway to include same env var as sidecar

supersedes https://github.com/istio/istio/pull/16358 since doug is ooo.

/cherrypick release-1.3

@bianpengyuan: new pull request created: #16469

In response to this:

/cherrypick release-1.3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


ERROR: tensorflow

System information
tf version =2.3.0-rc
System- colab-gpu
Reproduce error
y=tf.TensorArray(tf.float32,size=1,dynamic_size=True)
y.write(0,[[20,1,10]])
y.write(1,[[22,1,10]])
y.write(2,[[23,1,10]])
y.write(3,[[24,1,10]])

ERROR
ERROR:tensorflow:==================================
Object was never used (type <class 'tensorflow.python.ops.tensor_array_ops.TensorArray'>):
<tensorflow.python.ops.tensor_array_ops.TensorArray object at 0x7f6e013e9d68>
If you want to mark it as used call its "mark_used()" method.
It was originally created here:
  File "/usr/local/lib/python3.6/dist-packages/IPython/core/interactiveshell.py", line 2718, in run_cell
    interactivity=interactivity, compiler=compiler, result=result)  File "/usr/local/lib/python3.6/dist-packages/IPython/core/interactiveshell.py", line 2822, in run_ast_nodes
    if self.run_code(code, result):  File "/usr/local/lib/python3.6/dist-packages/IPython/core/interactiveshell.py", line 2882, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)  File "<ipython-input-38-cf79ca55289e>", line 1, in <module>
    y.write(0,[[20,1,10]])  File "/usr/local/lib/python3.6/dist-packages/tensorflow/python/util/tf_should_use.py", line 249, in wrapped
    error_in_function=error_in_function)
==================================
ERROR:tensorflow:==================================
Object was never used (type <class 'tensorflow.python.ops.tensor_array_ops.TensorArray'>):
<tensorflow.python.ops.tensor_array_ops.TensorArray object at 0x7f6e013e9d68>
If you want to mark it as used call its "mark_used()" method.
It was originally created here:
  File "/usr/local/lib/python3.6/dist-packages/IPython/core/interactiveshell.py", line 2718, in run_cell
    interactivity=interactivity, compiler=compiler, result=result)  File "/usr/local/lib/python3.6/dist-packages/IPython/core/interactiveshell.py", line 2822, in run_ast_nodes
    if self.run_code(code, result):  File "/usr/local/lib/python3.6/dist-packages/IPython/core/interactiveshell.py", line 2882, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)  File "<ipython-input-38-cf79ca55289e>", line 2, in <module>
    y.write(1,[[22,1,10]])  File "/usr/local/lib/python3.6/dist-packages/tensorflow/python/util/tf_should_use.py", line 249, in wrapped
    error_in_function=error_in_function)
==================================
ERROR:tensorflow:==================================
Object was never used (type <class 'tensorflow.python.ops.tensor_array_ops.TensorArray'>):
<tensorflow.python.ops.tensor_array_ops.TensorArray object at 0x7f6e013e9d68>
If you want to mark it as used call its "mark_used()" method.
It was originally created here:
  File "/usr/local/lib/python3.6/dist-packages/IPython/core/interactiveshell.py", line 2718, in run_cell
    interactivity=interactivity, compiler=compiler, result=result)  File "/usr/local/lib/python3.6/dist-packages/IPython/core/interactiveshell.py", line 2822, in run_ast_nodes
    if self.run_code(code, result):  File "/usr/local/lib/python3.6/dist-packages/IPython/core/interactiveshell.py", line 2882, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)  File "<ipython-input-38-cf79ca55289e>", line 3, in <module>
    y.write(2,[[23,1,10]])  File "/usr/local/lib/python3.6/dist-packages/tensorflow/python/util/tf_should_use.py", line 249, in wrapped
    error_in_function=error_in_function)
==================================
<tensorflow.python.ops.tensor_array_ops.TensorArray at 0x7f6e011c99e8>

I have tried in colab with TF version 2.2, 2.3 and nightly version(2.5.0-dev20201116) and was able to reproduce the issue. Please, find the gist here. Thanks!

@maxkaustav,
As per the Example of TensorArray, it should be
y = y.write(0,[[20,1,10]]) instead of y.write(0,[[20,1,10]])
because it will not modify the Tensor in Place.
Please find the Gist of Working Code. Thanks!

@maxkaustav,
Can you please respond to the above comment. Thanks!

Automatically closing due to lack of recent activity. Please update the issue when new information becomes available, and we will reopen the issue. Thanks!

Reopening as there's a comment that this still reproduces

Hi @Arregator @maxkaustav ! I could not replicate this issue in 2.7 version though .Attaching Gist for reference . Thanks!

@maxkaustav,
Given code works with Tf v 2.8.0. Please take a look at gist.
import tensorflow as tf
import numpy as np
print(tf.__version__)
images = np.array([[122_222]])
images_array = tf.TensorArray(tf.uint16, size=0, dynamic_size=True, clear_after_read=False)
images_array = images_array.write(0, images)

@maxkaustav,
Closing this issue, since its resolved .
Please feel free to reopen if issue still persists. Thanks!


Entrance/exit from collection not supported by SectionList

Description
Entrance/exit from collection not supported by SectionList. No components can be set as any collection role. With support for "List" or "Grid" roles would these would likely work as expected.
This issue is covered in-depth by parent issue #30861, please check there for more details.
React Native version:
0.63

Hi @amarlette, I'd like to give this a try. Could you assign it to me? Thanks!

@amarlette I believe https://github.com/facebook/react-native/pull/31630 fixed this, can we close this issue?

I think this issue. Can be closed cause #31630 it added to examples.

video test case included here https://github.com/facebook/react-native/pull/34267

TalkBack support for ScrollView accessibility announcements (list and grid)
#33180 https://github.com/facebook/react-native/pull/33180 initially
landed on 20th April 2022. Java API relanded with commit a7bb9664009
https://github.com/facebook/react-native/commit/105a2397b6b187a9669ba1c028508a7bb9664009.
JavaScript API relanded with commit cbf53bcaf0c
https://github.com/facebook/react-native/commit/463af237539b98289c88e5b491c85cbf53bcaf0c,
but reverted with commit c2169c776e271ea
https://github.com/facebook/react-native/commit/3f8071d638d7c9cd25c0eb7f6c2169c776e271ea
.
On Wed, Jan 11, 2023 at 9:21 PM fabriziobertoglio1987 <
@.***> wrote:

Closed #30965 https://github.com/facebook/react-native/issues/30965 as
completed.
—
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/30965#event-8205167327,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A44YFRHZ4NKY72CASO3T67LWR4I4TANCNFSM4XNSTRIA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


feat: support ssz response for validators endpoint

Motivation

https://github.com/ethereum/beacon-APIs/issues/333

Description
Support SSZ response for validators endpoint. This is an initial step to systematically support returning ssz-encoded responses throughout all/most API endpoints (https://github.com/ChainSafe/lodestar/issues/5128).
This PR also gives good insights on what it required to support SSZ response for a single API, this is not acceptable and needs to be addressed if we want broader SSZ support with low maintenance cost and an easy way to add new APIs.

Depends on https://github.com/ChainSafe/lodestar/pull/6059

Closed in favor of https://github.com/ChainSafe/lodestar/pull/6080


Windows quickstart results in failing kubelet

After running through the Windows Quickstart documentation, attempting to launch the kubelet results in errors. The quickstart just doesn't seem to work out of the box on Windows.
E0413 13:08:10.312301   26404 run.go:74] "command failed" err="failed to parse kubelet flag: unknown flag: --logtostderr"

E0413 13:04:30.849556   66952 run.go:74] "command failed" err="failed to validate kubelet configuration, error: [invalid configuration: enforceNodeAllocatable (--enforce-node-allocatable) is not supported unless cgroupsPerQOS (--cgroups-per-qos) is set to true, invalid configuration: EnforceNodeAllocatable (--enforce-node-allocatable) [pods] is not supported on Windows], path: &TypeMeta{Kind:,APIVersion:,}"

Expected Behavior
Kubelet to start after performing Quickstart steps.
Current Behavior
Kubelet doesn't start after performing Quickstart steps.
Possible Solution

Steps to Reproduce (for bugs)

C:\install-calico-windows.ps1 -KubeVersion 1.26.3 -CalicoBackend "vxlan"
Start Kubelet service
Observe error(s) in kubelet.err.log

Context
Attempting to stand up a Windows node to join existing microk8s-based Linux cluster.
Your Environment

Calico version: 3.25.1
Orchestrator version (e.g. kubernetes, mesos, rkt): 1.26.3
Operating System and version: Windows Server 2022 20348.1668
Link to your project (optional): N/A

I know the --logtostderr was cleaned up by this but I'm not familiar with the other one. Perhaps @coutinhop could chime in if he's ever seen that before.

Invoke-WebRequest https://github.com/projectcalico/calico/releases/download/v3.25.1/install-calico-windows.ps1 -OutFile c:\install-calico-windows.ps1
c:\install-calico-windows.ps1 -KubeVersion 1.26.4
...
C:\CalicoWindows\kubernetes\install-kube-services.ps1

In a similar scenario, I used the BGP path, and after executing the script, I could see the Kubelet service constantly restarting. After querying, I obtained the following logs:
E0510 09:40:05.213985    3568 run.go:74] "command failed" err="failed to parse kubelet flag: unknown flag: --logtostderr"
Flag --resolv-conf has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.
Flag --enable-debugging-handlers has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.
Flag --cluster-dns has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.
Flag --cluster-domain has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.
Flag --hairpin-mode has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.
Flag --cgroups-per-qos has been deprecated, This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.

How can I solve it?

yes, it is still present in https://docs.tigera.io/calico/3.26/scripts/PrepareNode.ps1
/reopen


Passing own function to library function breaks visualization

To reproduce this problem set up a directory structure like this:
.
├── app
│   └── example.py
├── libs
│   └── factorial
│       ├── __init__.py
...

example.py:
import factorial

def mul(a, b):
    return a * b

result = factorial.factorial(3, mul)
print(result)

init.py:
def factorial(n, op):
    if n <= 1:
        return 1
    prev = factorial(n - 1, op)
    a = op(n, prev)
    return a

Run the trace generator with something like PYTHONPATH=libs python3 main.py app/example.py and you should get an error.
The question remaining is: how should this situation be visualized?
Option 1: We can skip everything that is executed through the library. In the example, executing factorial.factorial would just be one step.
Option 2: We can somehow visualize the steps again once we reach code that is non-library code. In this latter case, do we omit the stack frames generated by the library and have the visualization "randomly" jump to some non-library code again?
Option 3: (Is there another one?)
Option 2 would probably require more effort to realize as we always need to keep track of all the steps that are happening inside of a library to get a correct visualization (even if we don't visualize them). This would very likely also decrease the performance quite a bit.

I think option 1 is good here. The visualization is targeted towards beginners. When teaching advanced features such as higher-order functions, we still can use the debugger.


ci: restore docker-runner workflow

Somehow it got removed..
Signed-off-by: Ettore Di Giacinto<EMAIL_ADDRESS>

Merging, as it just restores what was added before.. and adds docker to the runner image, so can be used during actions


Be more clear what dynamic ADA does

What this PR does / why we need it:
This PR improves the ADA stage log so that we can see how dynamic ADA works.
Which issue(s) this PR fixes:
Fixes #
Does this PR introduce a user-facing change?:

NONE

Fixed! PTAL

/lgtm

@khanhtc1202 PTAL :-)

🚀
/approve


Imlement stream output

Stream output is a rarely used feature. There are more efficient ways to implement the same functionality using compute shaders.


Update actions

This PR updates the Github actions, switches to julia-actions/cache and adds proper versioning to all actions (with dependabot we don't have to worry about outdated actions but rather about breaking updates IMO).
Closes #90. Closes #92. Closes #91.

Code coverage doesn't work with the updates here. See the error logged for the codecov-action in e.g. https://github.com/JuliaMath/AbstractFFTs.jl/actions/runs/4428264794/jobs/7767085981

Doesn't look obviously related to me. Open source repositories don't require a token for submitting coverage information to Codecov so if it's having trouble with the GitHub API then that's either on Codecov's end or GitHub's (or both).

Also it seems codecov was already updated on the master branch before this PR: #90 And there the action ran successfully, eg in https://github.com/JuliaMath/AbstractFFTs.jl/actions/runs/4428612759/jobs/7767949971

I see, perhaps it's independent then. https://github.com/codecov/codecov-action/issues/557 <- thought it might be related because this issue mentions that upgrading caused sporadic failures

Based on this issue it seems intermittent issues occur quite regularly but possibly one could avoid them by adding the CODECOV_TOKEN as a secret (and to the action, of course), even though it should not be needed for public repos according to the docs.

As an additional datapoint, the action did also succeed on the master branch when this PR was merged: https://github.com/JuliaMath/AbstractFFTs.jl/actions/runs/4438818860/jobs/7790407281


Center icons in overview cells.

This should resolve the last item in b/339649450: Center the information icon for the JavaScript tests.
I am using the same CSS classes that I use to center the --- text, and it seems to work with sl-tooltip.

LGTM after fixing the screenshot. Currently, the newly available logo is missing in the updated screenshot.

I think that none of these icons show up in the playwright snapshots.  I got some visual diffs only because of the broken icon.  Now that that is fixed, my updated snapshots are == to the original, so they dropped out of the PR.   Of course, the proof will be whether it passes CI.


chore(deps): upgrade xstream to 1.4.18

Checklist

[x] the contributor license agreement is signed
[x] commit message follows commit guidelines
[ ] tests are included
[ ] screenshots are included showing significant UI changes
[ ] documentation is changed or added

Description of change

Upgrades to latest XStream, while also tidying up some places it's not used (or kind of used - BiRT) and attempting to ensure the same version is used everywhere (even with the Hibernate module) through vals in CommonSettings.
Undertook local manual testing of most things. But will first place the PR in draft while I await a full CI run to pick up things - e.g. I've not done a automated install etc.
(Note the move to a new MXParser - they why is in the README here: https://github.com/x-stream/mxparser )
Hopefully resolves #2998

Nope, the automated install is still have issues with some kind of ForbiddenClassException from XStream.
Will investigate on Monday.

CI fail is on known flaky: 'LDAPTest'. Should be fine.


Request analysis of PRJNA681234

@nekrut this is the simplest way to request analysis of Illumina PE data :)

Thanks for the contribution. The processing will start in a few minutes.


Main Menu Login Info

Immediately lets the user know that the game is attempting to login and then lets them know if it's successful or failed. It'll now attempt to login again if failed. A few other errors such as failing to start or find a server when logged in.

Merged into #43


Add enocean to latest

Please add my adapter ioBroker.enocean to latest.
This pull request was created by https://www.iobroker.dev 79ffd9b.

Hi, some review feedback:

Please check for state.ack===false in onCHange ... i miss this in most places - or is there a reason for it? (in fact the check for the from namespace shoudl be changed into this (unless you know that your code would set ack=false himself and you not want to react on it ;-)

Rest looks fine so far

@Jey-Cee Any status update?

Code is updated and there where no issues reported since 26 days.
So it is ok to publish.

Yes code looks good, but there was no new version released with these changes, so please do that. Thank you


Introduced HTTPS, private sp ContactPerson nodes on metadata, fix for /error without 200 http code

In order to reach the certification for a private service provider, here a set of feature that I've implemented:

HTTP/HTTPS via environment variables
for private service provider (via environment variables) the metadata contains ContactPerson nodes (other and billing)
fix for /error response without 200 http code

There are still some problems as before this pull request.
Here below a list of errors found with spid-sp-test v.0.6.3 ( thanks to @peppelinux for the support)

Authnrequest strict [SpidSpAuthnReqCheck]

29
failure
RelayState is missing - TR pag. 14 or pag. 15
Missing RelayState

31
failure
AuthnRequest Signature validation failed
Verification Failure

42
failure
The ForceAuthn attribute MUST be present because of minimum/SpidL1
{'ID': '_727023c5dd22a8f92fa0', 'Version':  '2.0', 'IssueInstant': '2021-06-02T14:27:56.935Z', 'ProtocolBinding':  'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST', 'Destination':  'https://domainspidtestenv2/sso', 'AssertionConsumerServiceURL':  'https://domainspidexpress/acs',  'AttributeConsumingServiceIndex': '0'}

43
failure
The ForceAuthn attribute MUST be True because of minimum/SpidL1
{'ID': '_727023c5dd22a8f92fa0', 'Version':  '2.0', 'IssueInstant': '2021-06-02T14:27:56.935Z', 'ProtocolBinding':  'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST', 'Destination':  'https://domainspidtestenv2/sso', 'AssertionConsumerServiceURL':  'https://domainspidexpress/acs',  'AttributeConsumingServiceIndex': '0'}

Response [SpidSpResponseCheck]

1
failure
Test [1] Response corretta. Risultato atteso: Ok: [http status_code: 500]

27
failure
Test [31] L'attributo Format di Issuer deve  essere omesso o assumere valore  urn:oasis:names:tc:SAML:2.0:nameid-format:entity. In questo test il  valore è omesso. Risultato atteso: Ok: [http status_code: 500]

86
failure
Test [94] Elemento AuthContextClassRef  impostato su https://www.spid.gov.it/SpidL1. Risultato atteso: fare  attenzione al livello richiesto sulla request.: [http status_code: 500]

87
failure
Test [95] Elemento AuthContextClassRef  impostato su https://www.spid.gov.it/SpidL2. Risultato atteso: fare  attenzione al livello richiesto sulla request.: [http status_code: 500]

88
failure
Test [96] Elemento AuthContextClassRef  impostato su https://www.spid.gov.it/SpidL3. Risultato atteso: fare  attenzione al livello richiesto sulla request.: [http status_code: 500]

99
failure
Test [109] Response corretta. Risultato atteso: Ok: [http status_code: 500]

100
failure
Test [110] Attributo IssueInstant specificato con millisecondi. Risultato atteso: Ok: [http status_code: 500]

Authn test related to forceauthn probably are wrong, forceauthn Is needed only with GTE L2
Relaystate should be trivial to be implemented ...
Regarding response tests ... The First test, Number 1, MUST return 200, It hot instead 500 😶
Thank you @matfur92, this Is a good starting point

@matfur92 CI fails, that's something that must be investigated before considering these commit ready to be merged
@bfabio Is there any hint on this?

@peppelinux yarn.lock needs to be updated in the PR (with yarn install)
@matfur92 thanks for the PR! In general we are trying to be as close to upstream as possible by merging their changes and upstreaming ours. I haven't managed to compare the repos yet, but AFAIU https://github.com/pagopa/io-spid-commons/pull/81 is implementing part of the changes in this PR and I think we should pull that first.


RFC: Use-able module

When using elixir-thrift, I found myself doing a lot of this:
defmodule UsingThrift do
  alias Thrift.Service.MyEnum
  alias Thrift.Service.MyOtherEnum
  require MyEnum
  require MyOtherEnum
end

I was thinking that it would be nice if we'd have something that would do the require of all the enums for us so I could do
defmodule ThriftUser do
  use Thrift.Service
  alias Thrift.Service.{MyEnum, MyOtherEnum}
end

or
defmodule ThriftUser do
  use Thrift.Service
end

I don't have opinions about much here, I just want to spur conversations and improve the ergonomics of our enums.
@pguillory @jparise @dantswain

It could be nice to support just use Thrift.Service. I like being explicit about the aliases, but we could perhaps extend to use statement to make that shorter:
use Thrift.Service,
  aliases: [MyEnum, MyOtherEnum]

I'm not sure that really gets us anything that the explicit aliases don't already provide though.

I think controlling aliases has to be up to the user; and I think it should be a passthrough to the normal alias params.
I really am most concerned about eliminating the requires.

Thrift.Service in this example is a namespace, right? As if there's a whatever.thrift like:
namespace elixir Thrift.Service
enum MyEnum {}
enum MyOtherEnum {}

We don't currently generate a module that corresponds to a namespace like that. There would be a couple of edge cases to consider if we wanted to do so. First, things can go in the root namespace, which is another discussion but that's the current behavior. Second, different IDL files can specify the same namespace, so this would introduce a kind of name collision that otherwise doesn't exist.
I don't find require to be that onerous. When writing code, the Elixir compiler tells you when you need one, then you add it, done. It's a small fixed cost. The difficulty of reading code is a much more important consideration generally, and in that respect a require costs basically nothing. You just page down past boilerplate like that. So it's hard to justify much complexity or abstraction around reducing that cost.

@pguillory, I couldn't disagree more, in using our event thrift, I grew very tired of aliasing and requiring a half-dozen or so enums in every file.
In the above example, you'd simply do
"""elixir
use Thrift.Service.Enums
"""
And you're done.


Make DOM EventDelegator an xstream Producer

Currently, a stream obtained from sources.DOM.select(selector).events(type) isn't lazy: a DOM event listener is attached right after .events() call

ok, I'm wrong and

But it still would be good if DOM listeners would remove themselves when there's no destinations left

Nice catch! Thank you for the example, and I totally agree.

Raised the priority of this issue.

Not relevant any more