Issues deploying with custom docker images

Summary
Deploying with custom docker images fails on routemgmt : install route management actions.
Steps to reproduce
Modify configuration to use new images:

ansible-kube/environments/kube/files/nginx.yml34       containers:
35       - name: nginx
36         imagePullPolicy: Always
37         image: [account_name]/whisk_nginx
38         ports:

configure/configure_whisk.yml17       containers:
18       - name: configure-openwhisk
19         image: [account_name]/whisk_config:v1.5.6-dev
20         imagePullPolicy: Always

Log snippet
Verbose logging enabled for ansible
TASK [routemgmt : install route management actions] ****************************
task path: /incubator-openwhisk-deploy-kube/ansible/roles/routemgmt/tasks/deploy.yml:3
Monday 19 June 2017  21:16:38 +0000 (0:00:08.756)       0:05:33.797 ***********
fatal: [ansible]: FAILED! => {
    "failed": true,
    "msg": "the field 'args' has an invalid value, which appears to include a variable that is undefined. The error was: 'cli_path' is undefined\n\nThe error appears to have been in '/incubator-openwhisk-deploy-kube/ansible/roles/routemgmt/tasks/deploy.yml': line 3, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n# Install the API Gateway route management actions.\n- name: install route management actions\n  ^ here\n"
}

The file that is causing the issue is ansible-kube/roles/routemgmt/tasks/deploy.yml, which calls cli_path (a variable which doesn't seem to be getting set anywhere). The correlating file in apache/incubator-openwhisk uses cli.path instead.
Changing the variable from cli_path to cli.path does not resolve the issue, but it does change the failure message. I'm rerunning with the changed variable name and will post logs after the test completes.

Seems like there are some changes since I built the last images. This is that TODO section in my travis builds... having some way of automating this so it stays up to date, but think the entire build process is working towards making things not need Ansible. I can create new images and fix the new configure issues.

So I just built everything on a Ubuntu VM from scratch and ran through the deployment just fine. I think there is an issue if you build the images from scratch on a MAC. What i think is happening is that when the CLI is built, the process mounts in a number of files from the Host machine. Golang must then think it is being built for MAC and so it builds the wrong executable type. I will submit something to the docs to address this.

Just left a comment on apache/incubator-openwhisk-deploy-kube#19. I also will verify that I am able to deploy as expected via images built on Linux.

@DanLavine, I just ran a test where I built my docker images on an Ubuntu 16.04 machine, and reproduced the issue.
Output from git diff master:
diff --git a/ansible-kube/environments/kube/files/nginx.yml b/ansible-kube/environments/kube/files/nginx.yml
index d9780b2..c12e10b 100644
--- a/ansible-kube/environments/kube/files/nginx.yml
+++ b/ansible-kube/environments/kube/files/nginx.yml
@@ -34,7 +34,7 @@ spec:
       containers:
       - name: nginx
         imagePullPolicy: Always
-        image: danlavine/whisk_nginx
+        image: eventingmonkey/whisk_nginx
         ports:
         - name: http
           containerPort: 80
diff --git a/configure/configure_whisk.yml b/configure/configure_whisk.yml
index 4306f95..2f4a1b5 100644
--- a/configure/configure_whisk.yml
+++ b/configure/configure_whisk.yml
@@ -16,6 +16,6 @@ spec:
       restartPolicy: Never
       containers:
       - name: configure-openwhisk
-        image: danlavine/whisk_config:v1.5.6
+        image: eventingmonkey/whisk_config:v1.5.6-dev
         imagePullPolicy: Always
         command: [ "/incubator-openwhisk-deploy-kube/configure/configure.sh" ]

Here is the error from the deploy:
TASK [routemgmt : install route management actions] ****************************
Tuesday 20 June 2017  20:59:52 +0000 (0:00:08.592)       0:05:32.825 **********
fatal: [ansible]: FAILED! => {"failed": true, "msg": "the field 'args' has an invalid value, which appears to include a variable that is undefined. The error was: 'cli_path' is undefined\n\nThe error appears to have been in '/incubator-openwhisk-deploy-kube/ansible/roles/routemgmt/tasks/deploy.yml': line 3, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n# Install the API Gateway route management actions.\n- name: install route management actions\n  ^ here\n"}

@mlangbehn This failure is because tof the reason pointed out above - cli_path was renamed to cli.path in OpenWhisk master - and the ansible-kube scripts just need to be updated to reflect that.
Because the whisk_config Docker image clones OpenWhisk master when it gets built, it's easy to run into issues like this where rebuilding the Docker image fails (because it pulls in a newer OpenWhisk) compared to just running the existing published image. For reproducible builds, we may want to look into either pinning the git clone to a specific commit or removing the need to clone the main OpenWhisk repo in the Dockerfile.
Otherwise we'll run into issues like this where a build succeeds at some point in time but the exact same build fails at a future date.

Hmm. idk what happened when I built my image, I updated the OpenWhisk repo and everything, then rebuilt. Looking at the diff though it is still using the last commit I pulled. Will update the property. Think that other issue was resolved though if you change the property to the correct value?

@bbrowning @mlangbehn I update the Docker images and should have the newest version of OpenWhisk built into it. Made it a part of pr #19

Starting yesterday, my testing has been failing with an issue connecting to the controller. I'm working on debugging it now, but here is the log:
% kubectl -n openwhisk logs -f $(kubectl -n openwhisk get pods | awk '/controller/ { print $1 }')                                            master=
[2017-06-23T14:28:59.951Z] [INFO] Slf4jLogger started
[2017-06-23T14:29:00.669Z] [INFO] [??] [Config] environment set value for consulserver.host
[2017-06-23T14:29:00.679Z] [INFO] [??] [Config] environment set value for whisk.version.date
[2017-06-23T14:29:00.681Z] [INFO] [??] [Config] environment set value for whisk.version.buildno
[2017-06-23T14:29:00.682Z] [INFO] [??] [Config] environment set value for consul.host.port4
[2017-06-23T14:29:00.683Z] [INFO] [??] [Config] environment set value for port
[2017-06-23T14:29:00.686Z] [INFO] [??] [WhiskConfig] reading properties from consul at consul.openwhisk:8500
Exception in thread "main" java.lang.IllegalArgumentException: requirement failed: controller instance required
	at scala.Predef$.require(Predef.scala:224)
	at whisk.core.controller.Controller$.main(Controller.scala:193)
	at whisk.core.controller.Controller.main(Controller.scala)

This is a bigger issue. The HA Controller code was pulled in which breaks the controller. Have a fix. Just need to rebase it over all the current PRs and test it.

@DanLavine: Fabulous. I'd be happy to test and/or review change requests.

@mlangbehn Just pushed the code. Was just a number of config changes that had to go in.  Everything should be green now.

@DanLavine: Thanks, this issue is resolved.


🐛 Bug Report: Azure Devops Repo Picker doesn't work with user credentials

📜 Description
The repo picker doesn't work out of the box with Azure devops due to the scopes in the default ScmAuthApi implementation not fully qualifying the scope names.  As the scopes aren't fully qualified, backstage tries to request the scopes from the Microsoft Graph API rather than Azure Devops, which then fails as the requested scopes don't exist in Microsoft Graph.
You can see the kubernetes auth provider as an example of one that fully qualifies its scopes -
https://github.com/backstage/backstage/blob/f600aa87a3b3f7700544653b8560c86cba3cd479/plugins/kubernetes-react/src/kubernetes-auth-provider/AksKubernetesAuthProvider.ts#L35-L37
I see two possible solutions to this problem

Fully qualify the azure devops scopes in the default ScmAuth implementation.   (i.e. vso.code --> 499b84ac-1321-427f-aa17-267ca6975798/vso.code)
https://github.com/backstage/backstage/blob/f600aa87a3b3f7700544653b8560c86cba3cd479/packages/integration-react/src/api/ScmAuth.ts#L202-L208
For the Microsoft Auth API, change the getAccessToken method to accept a resource as well as scopes argument.  When this resource is provided, it can be used for resourceForScopes, as well as be prepended to all requested scopes.

👍 Expected behavior
Should get an Azure Devops scoped token from the Microsoft authentication apis.
👎 Actual Behavior with Screenshots
Authentication failed, AADSTS650053: The application REDACTED' asked for scope 'vso.build' that doesn't exist on the resource '00000003-0000-0000-c000-000000000000'. Contact the app vendor. Trace ID: 7a2bdb5f-c0cc-4856-af8a-e3594b4d6900 Correlation ID: 65074d10-81f8-4da5-8843-5c1338e3a900 Timestamp: 2024-02-01 15:35:08Z

(00000003-0000-0000-c000-000000000000 is the clientId for Microsoft Graph.
👟 Reproduction steps

Configure the microsoft auth provider ( https://backstage.io/docs/auth/microsoft/provider/ )
Configure a software template with a repo picker (see example below)
Fill in the required details for the repo picker, and follow the auth prompt

parameters:
  - title: Fill in some steps
    properties:
      repoUrl:
        title: Repository Location
        type: string
        ui:field: RepoUrlPicker
        ui:options:
          allowedHosts:
            - dev.azure.com
          requestUserCredentials:
            secretsKey: USER_OAUTH_TOKEN
            additionalScopes:
              azure: []
steps:
  - id: fetch-base
    name: Fetch Base
    action: fetch:template
    input:
      url: ./template
      values:
        name: ${{parameters.name}}

📃 Provide the context for the Bug.
No response
🖥 Your Environment
OS:   Linux <IP_ADDRESS>-microsoft-standard-WSL2 - linux/x64
node: v20.10.0
yarn: 1.22.21
cli:  0.25.0 (installed)
backstage:  1.21.1
Dependencies:
@backstage/app-defaults                                          1.4.6
@backstage/backend-app-api                                       0.5.10, 0.5.9
@backstage/backend-common                                        0.20.0, 0.20.1
@backstage/backend-dev-utils                                     0.1.2, 0.1.3
@backstage/backend-openapi-utils                                 0.1.1
@backstage/backend-plugin-api                                    0.6.8, 0.6.9
@backstage/backend-tasks                                         0.5.13, 0.5.14
@backstage/catalog-client                                        1.5.1, 1.5.2
@backstage/catalog-model                                         1.4.3
@backstage/cli-common                                            0.1.13
@backstage/cli-node                                              0.2.1, 0.2.2
@backstage/cli                                                   0.25.0
@backstage/config-loader                                         1.6.0, 1.6.1
@backstage/config                                                1.1.1
@backstage/core-app-api                                          1.11.2
@backstage/core-compat-api                                       0.1.0
@backstage/core-components                                       0.13.9
@backstage/core-plugin-api                                       1.8.1
@backstage/e2e-test-utils                                        0.1.0
@backstage/errors                                                1.2.3
@backstage/eslint-plugin                                         0.1.4
@backstage/frontend-plugin-api                                   0.4.0
@backstage/integration-aws-node                                  0.1.8
@backstage/integration-react                                     1.1.22
@backstage/integration                                           1.8.0
@backstage/plugin-api-docs                                       0.10.2
@backstage/plugin-app-backend                                    0.3.56
@backstage/plugin-app-node                                       0.1.8
@backstage/plugin-auth-backend-module-atlassian-provider         0.1.0
@backstage/plugin-auth-backend-module-gcp-iap-provider           0.2.2
@backstage/plugin-auth-backend-module-github-provider            0.1.5
@backstage/plugin-auth-backend-module-gitlab-provider            0.1.5
@backstage/plugin-auth-backend-module-google-provider            0.1.5
@backstage/plugin-auth-backend-module-oauth2-provider            0.1.5
@backstage/plugin-auth-backend-module-oauth2-proxy-provider      0.1.0
@backstage/plugin-auth-backend-module-okta-provider              0.0.1
@backstage/plugin-auth-backend                                   0.20.2
@backstage/plugin-auth-node                                      0.4.2, 0.4.3
@backstage/plugin-azure-devops-backend                           0.5.0
@backstage/plugin-azure-devops-common                            0.3.2
@backstage/plugin-azure-devops                                   0.3.10
@backstage/plugin-catalog-backend-module-azure                   0.1.27
@backstage/plugin-catalog-backend-module-msgraph                 0.5.15
@backstage/plugin-catalog-backend-module-scaffolder-entity-model 0.1.5
@backstage/plugin-catalog-backend                                1.16.0
@backstage/plugin-catalog-common                                 1.0.19
@backstage/plugin-catalog-graph                                  0.3.2
@backstage/plugin-catalog-node                                   1.6.0
@backstage/plugin-catalog-react                                  1.9.2
@backstage/plugin-catalog                                        1.16.0
@backstage/plugin-entity-validation                              0.1.13
@backstage/plugin-events-node                                    0.2.17
@backstage/plugin-explore-backend                                0.0.18
@backstage/plugin-explore-common                                 0.0.2
@backstage/plugin-explore-react                                  0.0.34
@backstage/plugin-explore                                        0.4.14
@backstage/plugin-github-actions                                 0.6.9
@backstage/plugin-home-react                                     0.1.6
@backstage/plugin-home                                           0.6.0
@backstage/plugin-org                                            0.6.18
@backstage/plugin-permission-common                              0.7.11, 0.7.12
@backstage/plugin-permission-node                                0.7.19, 0.7.20
@backstage/plugin-permission-react                               0.4.18
@backstage/plugin-proxy-backend                                  0.4.6
@backstage/plugin-scaffolder-backend-module-azure                0.1.0
@backstage/plugin-scaffolder-backend-module-bitbucket            0.1.0
@backstage/plugin-scaffolder-backend-module-gerrit               0.1.0
@backstage/plugin-scaffolder-backend-module-github               0.1.0
@backstage/plugin-scaffolder-backend-module-gitlab               0.2.11
@backstage/plugin-scaffolder-backend                             1.19.2
@backstage/plugin-scaffolder-common                              1.4.4
@backstage/plugin-scaffolder-node                                0.2.9
@backstage/plugin-scaffolder-react                               1.7.0
@backstage/plugin-scaffolder                                     1.17.0
@backstage/plugin-search-backend-module-catalog                  0.1.12
@backstage/plugin-search-backend-module-explore                  0.1.13
@backstage/plugin-search-backend-module-pg                       0.5.17
@backstage/plugin-search-backend-module-techdocs                 0.1.12
@backstage/plugin-search-backend-node                            1.2.12, 1.2.13
@backstage/plugin-search-backend                                 1.4.8
@backstage/plugin-search-common                                  1.2.10, 1.2.9
@backstage/plugin-search-react                                   1.7.4
@backstage/plugin-search                                         1.4.4
@backstage/plugin-tech-radar                                     0.6.11
@backstage/plugin-techdocs-backend                               1.9.1
@backstage/plugin-techdocs-module-addons-contrib                 1.1.3
@backstage/plugin-techdocs-node                                  1.11.0
@backstage/plugin-techdocs-react                                 1.1.14
@backstage/plugin-techdocs                                       1.9.2
@backstage/plugin-user-settings                                  0.7.14
@backstage/release-manifests                                     0.0.11
@backstage/test-utils                                            1.4.6
@backstage/theme                                                 0.5.0
@backstage/types                                                 1.1.1
@backstage/version-bridge                                        1.0.7
👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
Yes I am willing to submit a PR!

@jamieklassen any chance there's something you spot here at a glance? 😅

Thanks everyone, we're looking for contributions.
I was wondering if you had any suggestions, @awanlin?

I'm going to give it a go today, as it might also solve another issue I have!
It feels hacky but I think a simple of statement should do the trick

@Phiph, not sure what you mean? Would not just running with option 1 be the easy solution - adding the GUID to each scope?

Would those GUID scopes work with Azure DevOps server (self hosted) too?

OAuth authentication isn't available on Azure Devops Server, so this integration is specific to Azure Devops Services - https://learn.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/oauth?view=azure-devops .

Awesome, thanks @afscrome, that's what I was going to say but will much less certainty!

Great thanks team I've got enough information to make sure I get it right.
I think once this work has been complete I may be able to continue where I left off with this PR: https://github.com/backstage/backstage/pull/20923

Okay, I've had a go - and got some code here https://github.com/Phiph/backstage/tree/bug/ado-scopes
While testing the change I get the following:

I don't suppose you've got any ideas on what it could be.

To test I have created an App registration with the above api's available to it.
I then run the following:
 export AUTH_MICROSOFT_CLIENT_ID=<My-Id>
 export AUTH_MICROSOFT_CLIENT_SECRET=<My-Secret>
 export AUTH_MICROSOFT_TENANT_ID=<My-Tenant>

I then include a template that uses requestUserCredentials then yarn dev

I’ve been encountering this same issue - it broke around the time I upgraded to the new backend.  I’ve worked around this for now by reverting to the old with backend - using the old auth.ts file from the old back end, and registering that with useLegacyPlugin.  Haven’t found time to debug the root cause in the new backend.

Oh cool cheers I'll try that now - thanks Alex.
Is the new backend system ready for general use yet? If not any objections to raising the PR?

Okay looks like I'm using the old backend to develop with anyway yarn dev I'm going to spend a bit of time tonight and tomorrow to figure out what it is.

Added the auth label to this too as it looks like we've got some form of bug to do with the microsoftAuthProvider too right in the new backend system?
Just wanna clarify what's happening:

legacyPlugin() with the new backend system works
using the microsoftAuthProvider module directly using the new backend system throws `cannot read property of undefined 'emails'?

I've logged the auth issue as #23032.  Can discuss that issue further on that issue.
@benjdlambert - can you remove the auth label from this issue, and add it to #23032


ImportError: dlopen: cannot load any more object with static TLS

When I run the code, the error appears:
ImportError: dlopen: cannot load any more object with static TLS
It seems that scikit-learn has not been built correctly.
If you have installed scikit-learn from source, please do not forget
to build the package before using it: run python setup.py install or
make in the source directory.
If you have used an installer, please check that it is suited for your
Python version, your operating system and your platform.
So, what version of the library do you use to run your code? Can you give me a requirements.txt file? Thank you so much

Hi Gao,
I think most dependencies work fine for the code. For my sklearn, my environment shows I am using:
scikit-learn              1.0.2
I reuse the environment and update a few packages and cannot remember the previous version. Maybe you can try to correctly install the package and see if it works?


Possible mutations

[ ] C*02:10:01:? in 128964

@rleonid could you say more about what you're tracking with this issue?

I need an issue to keep track of potential samples where I think there is evidence of a mutation. In this cases there are 9 reads which I think would align much better with an insert.


Adds a case for error "Type 'key' cannot be used as an index type." in Typing wiki

Adds a case for error "Type 'key' cannot be used as an index type." in Typing wiki

@seanlip PTAL


⚠ Bofrost.es has degraded performance

In 3dbfb7d, Bofrost.es (https://www.bofrost.es) experienced degraded performance:

HTTP code: 200
Response time: 1863 ms

Resolved: Bofrost.es performance has improved in 4e92135 after 6 minutes.


FAILED! => {"argument_errors": ["Invalid type dict for option '{'cert_file':

Dear community,
Migrating from cloudalchemy.node_exporter and a previous ansible version, my playbook fails to validate node_exporter_tls_server_config.
Regards
Olivier
ogrosjeanne@bastion:~/ansible$ ansible --version
ansible [core 2.14.3]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/ogrosjeanne/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  ansible collection location = /home/ogrosjeanne/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/bin/ansible
  python version = 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] (/usr/bin/python3)
  jinja version = 3.0.3
  libyaml = True

ogrosjeanne@bastion:~/ansible$ more prometheus-test.yml
- hosts: localhost
  connection: local
  roles:
    - prometheus.prometheus.node_exporter
  vars:
    node_exporter_tls_server_config:
      cert_file: /etc/node_exporter/certificate.cer
      key_file: /etc/node_exporter/privateKey.pem

ogrosjeanne@bastion:~/ansible$ ansible-playbook prometheus-test.yml

PLAY [localhost] *********************************************************************************************************************************************************************************************************

TASK [Gathering Facts] ***************************************************************************************************************************************************************************************************
ok: [localhost]

TASK [prometheus.prometheus.node_exporter : Validating arguments against arg spec 'main' - Prometheus Node Exporter] *****************************************************************************************************
fatal: [localhost]: FAILED! => {"argument_errors": ["Invalid type dict for option '{'cert_file': '/etc/node_exporter/certificate.cer', 'key_file': '/etc/node_exporter/privateKey.pem'}', elements value check is supported only with 'list' type", "Invalid type dict for option '{}', elements value check is supported only with 'list' type", "Invalid type dict for option '{}', elements value check is supported only with 'list' type"], "argument_spec_data": {"node_exporter_basic_auth_users": {"description": "Dictionary of users and password for basic authentication. Passwords are automatically hashed with bcrypt.", "elements": "str", "type": "dict"}, "node_exporter_binary_local_dir": {"description": ["Enables the use of local packages instead of those distributed on github.", "The parameter may be set to a directory where the C(node_exporter) binary is stored on the host where ansible is run.", "This overrides the I(node_exporter_version) parameter"]}, "node_exporter_disabled_collectors": {"description": ["List of disabled collectors.", "By default node_exporter disables collectors listed L(here,https://github.com/prometheus/node_exporter#disabled-by-default)."], "elements": "str", "type": "list"}, "node_exporter_enabled_collectors": {"default": ["systemd", {"textfile": {"directory": "/var/lib/node_exporter"}}], "description": ["List of dicts defining additionally enabled collectors and their configuration.", "It adds collectors to L(those enabled by default,https://github.com/prometheus/node_exporter#enabled-by-default)."], "type": "list"}, "node_exporter_http_server_config": {"description": ["Config for HTTP/2 support.", "Keys and values are the same as in L(node_exporter docs,https://github.com/prometheus/node_exporter/blob/master/https/README.md#sample-config)."], "elements": "str", "type": "dict"}, "node_exporter_textfile_dir": {"default": "/var/lib/node_exporter", "description": ["Directory used by the L(Textfile Collector,https://github.com/prometheus/node_exporter#textfile-collector).", "To get permissions to write metrics in this directory, users must be in C(node-exp) system group.", "B(Note:) More information in TROUBLESHOOTING.md guide."]}, "node_exporter_tls_server_config": {"description": ["Configuration for TLS authentication.", "Keys and values are the same as in L(node_exporter docs,https://github.com/prometheus/node_exporter/blob/master/https/README.md#sample-config)."], "elements": "str", "type": "dict"}, "node_exporter_version": {"default": "1.1.2", "description": "Node exporter package version. Also accepts latest as parameter."}, "node_exporter_web_listen_address": {"default": "<IP_ADDRESS>:9100", "description": "Address on which node exporter will listen"}, "node_exporter_web_telemetry_path": {"default": "/metrics", "description": "Path under which to expose metrics"}}, "changed": false, "msg": "Validation of arguments failed:\nInvalid type dict for option '{'cert_file': '/etc/node_exporter/certificate.cer', 'key_file': '/etc/node_exporter/privateKey.pem'}', elements value check is supported only with 'list' type\nInvalid type dict for option '{}', elements value check is supported only with 'list' type\nInvalid type dict for option '{}', elements value check is supported only with 'list' type", "validate_args_context": {"argument_spec_name": "main", "name": "node_exporter", "path": "/home/ogrosjeanne/.ansible/collections/ansible_collections/prometheus/prometheus/roles/node_exporter", "type": "role"}}

PLAY RECAP ***************************************************************************************************************************************************************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

Released a new version of the collection with a fix actually just this minute, please try version 0.1.5

You patched argument_specs.yml, so i will not propose my PR... ;-)
Thanks
Olivier


chore: try out the "do not eliminate possible out of bounds errors" PR

This PR applies the changes from https://github.com/noir-lang/noir/pull/5610 to see how benchmarks behave.

Benchmark results
Metrics with a significant change:

proof_construction_time_poseidon_hash_ms (4): 48.0 (+41%)
protocol_circuit_simulation_time_in_ms (private-kernel-reset-tiny): 235 (+21%)
protocol_circuit_simulation_time_in_ms (private-kernel-tail-to-public): 2,826 (-43%)
avm_simulation_time_ms (Token:_increase_public_balance): 60.2 (+546%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Proof generation
Each column represents the number of threads used in proof generation.

Metric
1 threads
4 threads
16 threads
32 threads
64 threads

proof_construction_time_sha256_ms
5,715
1,544
707 (+1%)
763 (+2%)
771 (+1%)

proof_construction_time_sha256_30_ms
11,718
3,154 (+1%)
1,413 (+1%)
1,439 (+1%)
1,480 (+1%)

proof_construction_time_sha256_100_ms
43,905
12,455
5,716 (+1%)
5,599 (+1%)
5,514

proof_construction_time_poseidon_hash_ms
78.0
:warning: 48.0 (+41%)
34.0
58.0
88.0

proof_construction_time_poseidon_hash_30_ms
1,519
417
201
222 (-1%)
266 (-1%)

proof_construction_time_poseidon_hash_100_ms
5,605
1,513
672
730 (-1%)
754 (+1%)

L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
4 txs
8 txs
16 txs

l1_rollup_calldata_size_in_bytes
740
740
740

l1_rollup_calldata_gas
6,716
6,718
6,704

l1_rollup_execution_gas
611,983
612,136
612,273

l2_block_processing_time_in_ms
262 (+8%)
445 (+1%)
794 (+3%)

l2_block_building_time_in_ms
9,368 (+1%)
18,320
36,279

l2_block_rollup_simulation_time_in_ms
9,368 (+1%)
18,320
36,279

l2_block_public_tx_process_time_in_ms
7,780 (+1%)
16,537
34,457

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 8 txs.

Metric
3 blocks
5 blocks

node_history_sync_time_in_ms
2,792 (+3%)
3,676 (+2%)

node_database_size_in_bytes
12,709,968
16,937,040

pxe_database_size_in_bytes
16,254
26,813

Circuits stats
Stats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.

Function
time_ms
bytecode_size_in_bytes

GasToken:_increase_public_balance
92.2 (-1%)
8,139

GasToken:set_portal
10.1 (+3%)
2,362

Token:constructor
117 (-1%)
31,107

FPC:constructor
91.6 (-2%)
24,011

GasToken:mint_public
79.4 (+1%)
6,150

Token:mint_public
86.4 (-2%)
11,720

Token:assert_minter_and_mint
76.5 (-12%)
8,028

AuthRegistry:set_authorized
9.64 (+18%)
4,537

FPC:prepare_fee
291 (+5%)
8,812

Token:transfer_public
40.0 (-17%)
47,374

FPC:pay_refund
76.6 (+17%)
12,114

Benchmarking:increment_balance
977
7,450

Token:_increase_public_balance
:warning: 60.2 (+546%)
8,960

FPC:pay_refund_with_shielded_rebate
139 (+1%)
12,663

Public DB Access
Time to access various public DBs.

Function
time_ms

get-nullifier-index
0.157 (+5%)

Tree insertion stats
The duration to insert a fixed batch of leaves into each tree type.

Metric
1 leaves
16 leaves
64 leaves
128 leaves
256 leaves
512 leaves
1024 leaves

batch_insert_into_append_only_tree_16_depth_ms
2.16 (+1%)
3.78 (-2%)
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_count
16.8
31.7
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_ms
0.112
0.107 (-3%)
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_32_depth_ms
N/A
N/A
11.0 (-1%)
18.1 (+3%)
30.4 (+1%)
60.8 (+1%)
110 (+2%)

batch_insert_into_append_only_tree_32_depth_hash_count
N/A
N/A
95.9
159
287
543
1,055

batch_insert_into_append_only_tree_32_depth_hash_ms
N/A
N/A
0.106 (-1%)
0.106 (+3%)
0.0990 (+1%)
0.105 (+2%)
0.0997 (+2%)

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
13.8 (-2%)
25.4 (-2%)
43.0 (+3%)
81.6 (-2%)
159 (+5%)

batch_insert_into_indexed_tree_20_depth_hash_count
N/A
N/A
109
207
355
691
1,363

batch_insert_into_indexed_tree_20_depth_hash_ms
N/A
N/A
0.104 (-2%)
0.103 (-2%)
0.105 (+3%)
0.101 (-1%)
0.102 (+6%)

batch_insert_into_indexed_tree_40_depth_ms
N/A
N/A
16.3 (-1%)
N/A
N/A
N/A
N/A

batch_insert_into_indexed_tree_40_depth_hash_count
N/A
N/A
133
N/A
N/A
N/A
N/A

batch_insert_into_indexed_tree_40_depth_hash_ms
N/A
N/A
0.105 (-1%)
N/A
N/A
N/A
N/A

Miscellaneous
Transaction sizes based on how many contract classes are registered in the tx.

Metric
0 registered classes
1 registered classes

tx_size_in_bytes
62,729
664,455

Transaction size based on fee payment method
| Metric |  |
| - |  |


fix test for geth 1.10 upgrade

upgrade go-quorum from 2.5.0 to 21.10.0 then to the latest develop version

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Add file filters and search

Added

FileFilters wrappers
CoreFileType, BioFileType, GenestackPermission and SortOrder enums (needed for file filters)
find_files method in FilesUtil
MetainfoScalarValue wrappers, needed for KeyValueFileFilter
tests and documentation for file search and metainfo scalar values

This PR requires this one to be merged first.
The following tests have been added: test/test_file_import.py and test/test_file_filters.py

CoreFileType, BioFileType are super confusing. They looks like enums form the core, but have nothing common with them.
Lets create file: 'file_types.py'  and put there constant with Interfaces
# core files
AUXILIARY_FILE = 'com.genestack.api.files.IAuxilaryFile'
FOLDER = 'com.genestack.api.files.IFolder'
....
# bio files
....

Same for other Enums

I decided to keep classes for file types and permissions because Sphinx cannot autodocument module-level attributes. It would be impractical to list all the file types manually in the documentation.
I also find it more practical for users: if you want the list of file types, you type the name of the corresponding class and you get all the possible types via autocomplete, whereas otherwise it is less easy to find out.


relationship between short telomeres terms and telomere maintenece

https://github.com/pombase/fypo/issues/3747
Stephane used
"FYPO:0000122 abnormal telomere maintenance" and I  was just about to request a descendant when I found
FYPO:0006511 | shortened telomeres during G0
I'm assuming this should be some sort of descendant  of FYPO:0000122
?

FYPO:0000122 is defined as vegetative, which means it would be neither a subclass nor a superclass of any G0 phenotype. I'll rename it to make that explicit.
I can also check for places where we could add "output" links.

We probably need a superclass  too though.
Also when people refer to "telomere maintenance" aren't they really only talking about length maintenance ? (I see the def says or structure, but I haven't seen it used in this context. I guess you have annotated more telomere papers than I have, do people use this phrase to describe defects in telomere organization?)

We probably need a superclass too though.

Which new term(s) do you want?
Length is by far the most commonly assayed aspect of telomere structure but the G-quartets and the ssDNA overhang come up occasionally.

my question was, is "telomere maintenance" ever used in the context of structure.
For everything I have ever seen,
telomere maintenance ==telomere length maintenance
but either way we need a generic "telomere maintenance" as a superclass of  a vegetative and G0 term...

my question was, is "telomere maintenance" ever used in the context of structure

my answer was: yes

see #3747 for list of new terms and other changes


Open Modal with Service

Hello,
I have a problem. I would like to have an AuthService with function to open a modal. Is this possible? How can this be done?
Thanks for help!
Simon

Hi,
I suppose you want to open your modal from the service.
I suggest you use a route guard instead, then redirect to an appropriate page.

Yes, I want to open modal from service. But I don't want to redirect the user. I want to open a modal with sign in form and if everything is OK than I pass the user to next page.

Well, you could use auxiliary routes.
This way you can open a modal from any route with your service just by redirecting the user to the aux route url.
Have a look here : https://angular-2-training-book.rangle.io/handout/routing/aux-routes.html
Honestly, I think it might be the best approach.
Else, you would want to use some nasty ways like direct dom manipulations, which is not intended.


Delete web.config from AngularJSSample

This one can go, too.
There are two more out there in the wild; however, they're part of PJ-based projects that require a full-on upgrade, so there isn't much point in deleting those two right now.

@guardrex,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot


Add more resources

Codecov Report

Merging #370 into master will decrease coverage by 1.15%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #370      +/-   ##
==========================================
- Coverage   98.06%   96.91%   -1.16%
==========================================
  Files           7        7
  Lines         259      259
  Branches       42       42
==========================================
- Hits          254      251       -3
- Misses          2        5       +3
  Partials        3        3

Impacted Files
Coverage Δ

src/Session.ts
95.83% <0%> (-3.13%)
:arrow_down:

Continue to review full report at Codecov.

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


config.json: parallelRequests: invalid key

You are probably already aware of this, but as of 0.13.2, I am getting a warning from Homebridge config.json: parallelRequests: invalid key
As I understand from your release notes, you haven't yet migrated to dynamic platform, so this key should still be valid

My bad, made a typo in the code; it’s looking for parallelrequests.
The key has nothing to do with static vs dynamic accessories platform plugin.

Ahh, I assumed since you're adding dynamic accessories, parallelRequests might not be necessary anymore.
Thank you for continuing to maintain this plugin

In v0.13.3.


Melnichenka's pull request

You added a landscape background image, but did not fix any of the issues I brought up. Please see the TAs or me if you are confused.

Ready for review


Confusion around use/guarantees of grpc.RpcError in Python

Modifying the Python helloworld example to add exception handling produces some confusing results.
Changing modifying the run() function from https://github.com/grpc/grpc/blob/master/examples/python/helloworld/greeter_client.py to
def run():
  channel = grpc.insecure_channel('localhost:50051')
  stub = helloworld_pb2_grpc.GreeterStub(channel)
  try:
    response = stub.SayHello(helloworld_pb2.HelloRequest(name='you'))
  except grpc.RpcError as err:
    print('Type:', type(err))
    print('Attributes:', dir(err))
  print("Greeter client received: " + response.message)

and then running the above client while the server is not running produces the following output:
Type: <class 'grpc._channel._Rendezvous'>
Attributes: ['__abstractmethods__', '__cause__', '__class__', '__context__', '__del__', '__delattr__',
'__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__',
'__init__', '__init_subclass__', '__iter__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__next__',
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__setstate__', '__sizeof__', '__str__',
'__subclasshook__', '__suppress_context__', '__traceback__', '__weakref__', '_abc_cache',
'_abc_negative_cache', '_abc_negative_cache_version', '_abc_registry', '_call', '_deadline', '_next',
'_repr', '_response_deserializer', '_state', 'add_callback', 'add_done_callback', 'args', 'cancel',
'cancelled', 'code', 'details', 'done', 'exception', 'initial_metadata', 'is_active', 'next', 'result', 'running',
'time_remaining', 'traceback', 'trailing_metadata', 'with_traceback']

Looking at the source code for RpcError, it's defined as:
class RpcError(Exception):
    """Raised by the gRPC library to indicate non-OK-status RPC termination."""

So I'm wondering a few things:

What is this _Rendezvous class, and where is it defined? It doesn't appear in the package documentation (http://www.grpc.io/grpc/python/search.html?q=Rendezvous). A lot of its attributes potentially look very useful, but I'm just guessing as to what they actually do or represent.

Are there any guarantees about which of these attributes will always be available when RpcError is caught? E.g. if I start relying on using err.code() to get the error type, are there other RpcError subclasses that can be raised which don't contain this attribute?

Is there a list of all the possible subclasses of RpcError that can be raised? (i.e. in case I'd want different exception handling for each).

I couldn't see anything in the examples or documentation, but basically, I'd like to use something like:
try:
   # ... some gRPC call ...
except grpc.RpcError as err:
    if err.code() == grpc.StatusCode.UNAVAILABLE:
        print('Service unavailable')
   # ... handling for different codes here ...

but this looks unsafe, since RpcError doesn't define any attributes (beyond those inherited from Exception). Currently I'm using the following code, but I'm hoping there's a better option:
try:
    # ...some gRPC call ...
except grpc.RpcError as err:
    code = err.code() if hasattr(err, 'code') else None
    if code == grpc.StatusCode.UNAVAILABLE:
        print('Service unavailable')
   # ... handling for different codes here ...

It's true that grpc.RpcError specifies no useful data or behavior, but what you're missing in the documentation is that the exception raised out of an RPC invocation isn't just a grpc.RpcError; it's also a grpc.Call. Therefore it is legitimate (and part of the intended use case) to use the object raised out of an RPC invocation according to the grpc.Call interface that it implements. You may notice that the object presents a few other attributes that don't fit grpc.RpcError or grpc.Call as well - because these are not guaranteed by the system that raised the object to your system, they are not legitimate to call.
A much simpler example of this kind of specification-implementation would be a function that is specified to return a sequence and that has an implementation that returns a list. Callers of the function can call the method, introspect the returned value, see that it's a list, wonder why it wasn't documented as a list, use it according to the list type rather than the sequence type... and then see their code break when they update the function's library and the function's implementation changes from returning a list to returning some other sequence implementation. Proper implementation of a system that calls that function uses objects returned by the function only according to the sequence type that the objects are specified and guaranteed to implement.

Perfect, thank you, knowing it's also a grpc.Call make things very clear.


TECH-1658: Use JDK 11 image in the workflows

JIRA

https://jira.jahia.org/browse/TECH-1658
Description
Everything is in the title

The version on the master branch is still compatible with Jahia 8.1 which is still compatible with JDK 8 so we cannot update the build to use JDK 11 in this case. So we might need to focus on the run part (Sonar and Tests)


CFE does not support instantiation of function .call tearoff

The following code is accepted by the analyzer but rejected by the CFE:
main() {
  S Function(S) specialize<S>(T Function<T>(T) f) => f.call;
  X id<X>(X value) => value;
  int Function(int) intId = specialize(id);
  X defaulter<X>(X? value, [X? defaultValue]) => value ?? defaultValue ?? (throw ArgumentError("no default"));
  intId = specialize(defaulter);
  print(intId.runtimeType);
}

The CFE says:
../../tmp/proj/test.dart:3:57: Error: A value of type 'T Function<T>(T)' can't be returned from a function with return type 'int Function(int)'.
  int Function(int) specialize(T Function<T>(T) f) => f.call;

After experimenting a bit, I think that the CFE only allows generic instantiation of .call if .call resolves to a method on an actual class; if it resolves to the implicit .call of a function type, that's not supported.
The language team is currently having a discussion about related topics at https://github.com/dart-lang/language/issues/1604, and it's not yet clear to me what the best fix is.  So for now I'm assigning this issue to area-language.  We can re-assign it to area-front-end or area-analyzer once we decide what we want the correct behavior to be.

Duplicate of #45936


Ability to change wrapping tag.

I apologize if this is out-of-scope or context, but I am new to using markdown to render content. I noticed that my links are wrapped in a paragraph tag by default and am wondering if there was a way to override this behavior or skip it entirely?
It may also be possible that I've missed something or am writing my markdown in some incompatible manner -- you can see my example below:
Example:
This:

Compiles to this:

Thanks in advance for any feedback!

I believe the new functionality introduced in v7.1 is exactly what you're looking for https://github.com/probablyup/markdown-to-jsx/pull/268


Cannot convert undefined value to object (Error on Android only)

Description
i am using this component library in my expo react native app and keep getting this error on Android only, but works fine on iOS.
Cannot convert undefined value to object
[Description of the bug]
TypeError: Cannot convert undefined value to object

This error is located at:
in LottieAnimationView (at createAnimatedComponent.js:54)
in Unknown (at LottieView.js:178)
in RCTView (at View.js:116)
in View (at LottieView.js:177)
in LottieView (at Mentor.tsx:24)
in RCTView (at View.js:116)
in View (at createAnimatedComponent.tsx:579)
in AnimatedComponent(View) (at createAnimatedComponent.tsx:596)
in Unknown (at Mentor.tsx:19)
in RCTView (at View.js:116)
in View
......
Steps to Reproduce
import LottieView from 'lottie-react-native';

style:
lottieWrapper: {
flex: 1,
width: width * 0.9,
height: 290,
},
i expect the animation to work fine on android just as it did on iOS
React Native Environment
 "react": "18.2.0",     "react-dom": "^18.2.0",     "react-native": "0.72.6",     "expo": "~50.0.6",  "lottie-react-native": "^5.1.6",
`
System:
OS: macOS 12.7.2
CPU: (8) x64 Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
Memory: 25.24 MB / 16.00 GB
Shell:
version: 5.8.1
path: /bin/zsh
Binaries:
Node:
version: 20.11.0
path: /usr/local/bin/node
Yarn: Not Found
npm:
version: 10.3.0
path: /usr/local/bin/npm
Watchman: Not Found
Managers:
CocoaPods:
version: 1.14.3
path: /Users/nubiaville/.rbenv/shims/pod
SDKs:
iOS SDK:
Platforms:
- DriverKit 21.2
- iOS 15.2
- macOS 12.1
- tvOS 15.2
- watchOS 8.3
Android SDK: Not Found
IDEs:
Android Studio: 2023.1 AI-231.9392.1.2311.11255304
Xcode:
version: 13.2.1/13C100
path: /usr/bin/xcodebuild
Languages:
Java: Not Found
Ruby:
version: 3.0.3
path: /Users/nubiaville/.rbenv/shims/ruby
npmPackages:
"@react-native-community/cli": Not Found
react:
installed: 18.2.0
wanted: 18.2.0
react-native:
installed: 0.73.4
wanted: 0.73.4
react-native-macos: Not Found
npmGlobalPackages:
"react-native": Not Found
Android:
hermesEnabled: Not found
newArchEnabled: Not found
iOS:
hermesEnabled: Not found
newArchEnabled: Not found
`
I am using Expo Go
Lottie Version
Version:  5.1.6,

Hi @Elue-dev,
I haven't had time to check this issue specifically yet (Will probably fall to the weekend when I get some free time) but I can tell from the get-go that your Lottie React Native package is mismatched with the Expo Go client and Expo 50. The latest Expo Go is running Lottie 6, And we do highly recommend moving away from V5, as it is no longer maintained.
If you need help with the migration, please read this migration guide

Hi @Elue-dev,
I haven't had time to check this issue specifically yet (Will probably fall to the weekend when I get some free time) but I can tell from the get-go that your Lottie React Native package is mismatched with the Expo Go client and Expo 50. The latest Expo Go is running Lottie 6, And we do highly recommend moving away from V5, as it is no longer maintained.
If you need help with the migration, please read this migration guide

yes, thanks, did that, i upgraded to version 6 and everything works fine now, I installed version 6 initially but when i used the lottie component, it appeared blank, that was why i had to downgrade to version 5. I later realized that the issue was simply because i didn't give it a height and width of 100%

Sounds good then. Closing the issue. Let me know if there are any more problems.


Support ts v5

???
Can you please provide some information about what issues you're currently experiencing when trying to use this loader with ts5? Example repo? Specific errors? Throw me a bone here

Sorry the issue seems not belong to this package, closing.


right-click copy in SQL pane ignores selection

in the SQL pane, create a new sql statement:
select * from foo where id = 1234

highlight "1234" and right click.  Choose "copy"
Instead of copying the highlighted text, it seems to copy the entire contents of the SQL pane, not just the highlighted text.  It also brings up a modal dialog box containing the copied SQL which must be dismissed.
FWIW, ctrl-c and ctrl-v work as expected.
BONUS ISSUE:   the right-click does not offer you a "paste" option.
I'm running Firefox in Ubuntu Mate, if that makes any difference.

Hello,
Thank you for opening the issue. Adding this to the discussion in the roadmap.
Regards


Fixing the order of links.

@laurenhughes : PR passed checklist review. Please review changes and merge if appropriate.


Routine load can't create consumer

I created a routine load task and assigned a "group.id".The task state is RUNNING,but I can't see the corresponding consumer in kafka manager. This cause a problem that the real time data can't be written into the doris table.After about one minute, the consumer was created and the data was inserted into the table.
Is that a bug or just I set wrong properties?

http://doris.incubator.apache.org/master/zh-CN/administrator-guide/load-data/routine-load-manual.html#其他说明


Baseline correction

Often microscopy images have a problem with the baseline and I wonder how we could easily fix it.
I'm thinking about a gaussian filter followed by canny edge with a clear border or something like that in order to detect all the surfaces that are connected to the border.
And then sampling somehow the background and make a fit using a function. (Paraboloid ?)
Here is a non confidential image that could be use to test. Maybe it can easily be done with the current version and it is a simple application that could move in the documentation.

I have tried running the matlab example on the above image and get a black image with a radius 12 stucturing element. However I did obtain a lot better results by increasing the radius to 50 (result below). I have also observed that the bigger the structuring element, the slower the algorithm.

I also tried out with a 101x101 square structural element:

Here is what I obtained by running the following script in image-js. I have tried a circular kernel which seemed very slow. In the end I am using a 101x101 square kernel. Running time is 5-10s. The result is very similar to matlab.
https://github.com/image-js/image-js-typescript/blob/da23765f76f914df1428aaa0e757ba8489e66847/scripts/tophatTest.ts

This might be interesting: correcting non-uniform illumination in Matlab
https://de.mathworks.com/help/images/correcting-nonuniform-illumination.html


Node6 -> Node10 upgrade

Hello, we're currently getting a lot of node6 warnings relating to https://github.com/microsoft/azure-pipelines-tasks/issues/15493 we'd be interested to know if this extension will be updated and if so what's the timeline?
Thanks for any correspondence :)

+1, @yahavi @jfrog-ecosystem
If you could please follow up with an update regarding support of Node 10.
Thank you,

Hi @concentralukecollier , @HugoVeillette ,
Thanks for raising this request.
We added the upgrade task to our work plan and will update this issue once it is done.

We are seeing this warnings as well on all our pipelines for ArtifactoryDotnetCore, ArtifactoryGenericUpload, ArtifactoryPublishBuildInfo tasks and would be great if you could provide us the approximate timeline. TIA.

Hi all,
We just released extension version 1.13.3 which migrates to node 10.
Looking forward to your feedback, thanks.

Thanks @RobiNino - i see the latest version of Artifactory Generic Download task is still version 3 - does this have the update from her on in or will there be a new version of all the tasks published?

Hi @andydkelly-ig ,
It includes the update. The migration warnings should disappear without further action.

brilliant thanks for this - and thanks for the speed in which this was resolved.

Thank you so much for quick turnaround on releasing the update @RobiNino. Not seeing the warnings anymore.


Building from source will not terminate even if Gradle build has failed

Description

When building the project from source with cargo xtask build-alxr-pico (or any HMD client for that matter), should the Gradle fail to build (either because CMake was not of exact version 3.22.1, or Ninja was not in the path, or there is any network connection issue that failed the dependency resolution, or any other uncovered failing condition), the build process does not panic or report any issue. It will just stuck at Compiling alxr-engine-sys v0.11.0 and hang indefinitely.
Attached is the Gradle daemon output. daemon-5472.out.log
General Troubleshooting

[x] I carefully followed the instructions in the README and successfully completed the setup wizard
[x] I read the ALVR Wikis here and here

Environement
Hardware
Note: for Linux, an upload to the hw-probe database is preferred: hw-probe -all -upload
CPU: Intel Core i5-7500
GPU: Nvidia RTX 2060
Audio: (Built-in Realtek driver)
Installation
ALVR Version: master@d366dd5
SteamVR Version: (not related)
Install Type:

[ ] Packaged (exe, deb, rpm, etc)
[ ] Portable (zip)
[x] Source

OS Name and Version (winver on Windows or grep PRETTY_NAME /etc/os-release on most Linux distributions): Windows 10 22H2 (19045.3208)

After fiddling around watching the daemon output, the Gradle build is now successful. However, the cargo side is still stuck at alxr-engine-sys(build). It seems that the cargo side never received anything from Gradle. I am not familiar with Rust so I am not sure what to do next (besides learning Rust).

For anyone encountering this issue, here is a workaround that can at least yield an apk file in the final output.

Figure out where your Gradle is. Check GRADLE_HOME. Your Gradle daemon output is at ${GRADLE_HOME}/daemon/7.3.3/daemon-${GRADLE_PID}.out.log. This log is being actively written on. Use tail -f or an editor that can automatically reload as the file is being changed.
Watch the log file output. You should wait until you see BUILD SUCCESSFUL. If you see BUILD FAILED, then you will have to resolve the issues raised by Gradle and try again. Note that in the current version (d366dd5, submitted on 2023-08-03), you will need to use CMake==3.22.1. Using the latest CMake WILL NOT WORK. You can, however, use the latest ninja.
Kill the java.exe in the task manager. The Java process should have the same PID with ${GRADLE_PID}. You can also use taskkill /f /pid ${GRADLE_PID}
The compilation procedure will now continue.

I am not sure if this is the intended way of building ALXR Android Client on Windows. But at least it would produce an apk file.


Add initia configuration for  CLAIR_DB.

When the harbor is deloyed in k8s cluster, the adminserver is not started  due to the lack of clair_db infomation in adminserver.cm.yaml.
Please refer  to issue 4543 for related error description.

@rootdeep  thanks for this PR however the manual deployment kind for k8s will be deprecated and we'll focus on helm chart for deploying Harbor onto k8s.

Coverage decreased (-0.3%) to 62.359% when pulling 0dff2ed3c572a4c307c5f71c742c32b3aeb60eea on rootdeep:4543-description into 73e32d17354352b6f8ef5e7a975316d52f1518e5 on vmware:master.

@reasonerjt   The problem exists.

Per discussion the doc will be supporting 1.2.x version of Harbor only, so no need further change to support later version of images, we'll only recommend deploying the Chart if user wants to use later versions of Harbor on top of K8S.
Closing this PR.


Payment Receipt API

Create Payment Receipt.

Send  receipt to the client as HTTP response.
Email taxpayer a receipt after a successful transaction.
Get taxpayer Receipt by taxPayerID and paymentDate.

GET:  https://paytax-app.herokuapp.com/api/v1/payments/receipt/
accepts two query parameters:
const { taxPayerID, paymentDate } = req.query;
fixes: #28

I don't understand codacy errors with my markdown.
i'm using a markdown linter in my Vscode. it shouldnt give me errors :(


UART causes a crash

with tinypico-idf3-20200110-v1.12-45-gbfbd94401.bin (or with the idf4 version), UARTs cannot be used:
from machine import UART
u = UART(1)
=> crash, reboot loop (when in program code)
From REPL:

MPY: soft reboot
MicroPython v1.12 on 2019-12-20; TinyPICO with ESP32-PICO-D4
Type "help()" for more information.
from machine import UART
u = UART(1)
I (36410) uart: ALREADY NULL

That's correct behaviour on the ESP32-PICO-D4 as the default pins for UART 2 and 3 that Espressif chose are not available on the D4 - They are instead reserved for Flash and RAM.
You need to specify the pins you want to use in the constructor (not afterwards) and then it works correctly.

I didn't know that - it works now!
Thanks for the prompt reply!


Avoid wasm_engine_t singleton in C API implementation

This patch allows safer (note: safer, not safe) embedding in a plugin
environment where multiple instances of the engine could be needed.
Original code initializes and tears down the full runtime during
wasm_engine_new() and wasm_engine_delete() respectively. After this
update the C API implementation keeps track of engine instances count
and inits/deinits the runtime only when needed.
This allows for example to call wasm_engine_new() twice and then call
wasm_engine_delete() once without rendering the first engine instance
invalid.

Additional note absent from commit message: unmodified wasmer's C API implementation already allows to safely create and destroy multiple engine instances.

This allows for example to call wasm_engine_new() twice and then call wasm_engine_delete() once without rendering the first engine instance invalid.

I am worried that unpaired wasm_engine_new() and wasm_engine_delete() calling is not a right and expected behavior. Callers should guarantee they will call wasm_XXX_delete() after wasm_XXX_new() just like they should free() every piece memory fragment allocated by malloc()

Thanks for reviewing!
I agree new/delete calls should be paired otherwise memory leaks can occur. This patch basically allows this:
/* AABB */

wasm_engine_t* a = wasm_engine_new();
wasm_engine_t* b = wasm_engine_new();
wasm_engine_delete(b);
wasm_engine_delete(a);

Right now any attempts to do the above result in unexpected behavior because:
wasm_engine_t* b = wasm_engine_new();  // makes both a and b invalid

The C API is enforcing the following implicit convention:
/* ABAB */

wasm_engine_t* a = wasm_engine_new();
wasm_engine_delete(a);
wasm_engine_t* b = wasm_engine_new();
wasm_engine_delete(b);

In other words in the current implementation the engine new/delete calls are not balanced, hence  it is only possible to have a single engine instance at a given time. (maybe this is a requirement of the WASM C API standard I am not aware of).
The patch makes sure the runtime is not destroyed until the last call to wasm_engine_delete() has been performed.

I made some edits to the examples above to correct errors and make it more explicit

Thanks. It does make sense. And it leaves us another problem.
Although there is no accurate concept of an engine, it tends to be a logical object to represent runtime, or wasm_runtime. So engine should be at the top level, above store. In other words, wasm_store_t should not include wasm_engine_t to avoid bio-direction association (wasm_engine_t <-> wasm_store_t). The question here is how to store and keep tracing all-created engines.
Maybe a global engine list (wasm_engine_vec_t) will work. Let me know your idea.

There are two different issues here actually:

Who calls and when to call wasm_runtime_full_init() and wasm_runtime_destroy().
Current wasm_store_delete() implementation requires access to the engine to remove itself from the list of the stores in the engine

I thought of a somehow pragmatic approach for addressing #1 which is decoupling the library itself from the engine/runtime at a code level. Treat the former as a WAMR implementation detail, and engine as a  standard entity which is already represented by wasm_engine_t.
That would require two WAMR custom functions like wamr_init() and wamr_deinit(). The architecture looks more explicit this way, wamr_* deal with library things that not necessarily have to do with WebAssembly (setting OS handlers, etc). Then there would not be need for global/static data I think.
I must be honest here in the sense that I pursue the implementation with the least global data as possible since it is a requirement in my context. It sounds like a desirable concept anyways unless it makes the implementation over-complicated.
As a bonus wasm_engine_new() and wasm_engine_delete() would behave exactly the same any time they are called no matter the number of existing engines. But this is really a cosmetic detail, and pragmatism goes out of the window :)
A global engine list also works, and I've already seen lists implemented internally for keeping track of created stores.
For #2 I agree the reference cycle does not look very clean but having multiple engine instances instead of the current singleton means there is no other way for accessing the engine stores list from wasm_store_delete(). Unless you scan the global engines vector until hitting the correct engine though it sounds too complex.
Less invasive option could be leaving things as they are now (singleton included) and add a reference counter to know when to call wasm_runtime_full_init() and wasm_runtime_full_destroy(). That would be similar to this proposed patch, but leaving the singleton to avoid the engine<->store double reference. Total globals:  one wasm_engine_t* and one int.
Please take all this with a grain of salt as my experience with WASM and WAMR is scarce.

wasm_engine_t is a representation of wasm_runtime and an entry of the library. And it is why it is a singleton at the very beginning. And the problem here is when users choose to call wasm_engine_new and wasm_engine_delete multiple times in a form like "ABAB", the first wasm_engine_delete releases the singleton and cause all secondary releasing failed. It looks good to land a count but it may be a little be confused to create multiple engines since there is actually one wasm_runtime and one entry logically.  So how about using a reference count instead of an instance count?
struct wasm_engine_t {
  // ...
  uint32_t reference_counts;
};

wasm_engine_t is a representation of wasm_runtime and an entry of the library. And it is why it is a singleton at the very beginning.

This is clear now, thanks.

And the problem here is when users choose to call wasm_engine_new and wasm_engine_delete multiple times in a form like "ABAB", the first wasm_engine_delete releases the singleton and cause all secondary releasing failed. It looks good to land a count but it may be a little be confused to create multiple engines since there is actually one wasm_runtime and one entry logically. So how about using a reference count instead of an instance count?
struct wasm_engine_t {
  // ...
  uint32_t reference_counts;
};

Looks elegant and solves the problem!
I think we have a similar issue with wasm_store_new(), calling this function twice causes this to be executed twice:
https://github.com/bytecodealliance/wasm-micro-runtime/blob/c94e7525327b275c396ed4394e1d5e7848972616/core/iwasm/common/wasm_c_api.c#L385
I recall having to disable OS_ENABLE_HW_BOUND_CHECK on macOS to avoid crashing on the second call.  I think the crash was on os_thread_signal_init(), sorry for the vagueness I'd need to create a test. Anyways, the store can be also refcounted to avoid calling single-time things more than once. Or probably move all runtime lifecycle calls (like wasm_runtime_init_thread_env()) to the  wasm_engine_new() and wasm_engine_delete() functions?

Nice catch. The big assumption about one engine and one store has been broken. And we will see some crashing related to that. Maybe ref-counters can help them. But let me do some investigation first.
Since it needs some tough work to fix all those, I am super curious about scenarios of multiple calling. Is it a multiple threads case?

It is an audio plugin architecture where each plugin holds its own WASM engine. A plugin can be loaded multiple times into the same process (the DAW). The plugins are packaged into shared libraries with a standard interface (VST, LV2, etc).  The goal is to run DSP modules precompiled from AssemblyScript.
So if I correctly understand what is going on, loading two instances of a plugin results in calling wasm_store_new() twice during the host process lifetime,  causing trouble on some platforms.
This setup also reveals my previous concern with global/static data :)
There is some threading involved. The host can call the plugin from multiple threads, including realtime. These native calls result in wasm_func_call() and are currently protected by a lock.
If there is some obvious downside in doing this or recommendations, I'd be happy to know about them!

I'd like to remove the possibility of "thread-unsafe bh_vector", please try the crash with a patch and see where it goes.
In wasm-c-api, we tend to follow the thread model.

an wasm_engine_t instance may only be created once per process
Every wasm_store_t and its objects must only be accessed in a single thread

I'd like to remove the possibility of "thread-unsafe bh_vector", please try the crash with a patch and see where it goes.
In wasm-c-api, we tend to follow the thread model.

an wasm_engine_t instance may only be created once per process

Thanks for that link... wish I had seen it earlier :) . That statement is pretty clear and explains the singleton. Still https://github.com/bytecodealliance/wasm-micro-runtime/pull/1001#issuecomment-1038487860 sounds good to have.

Every wasm_store_t and its objects must only be accessed in a single thread

Mm I think I accidentally made things worse for my specific setup. The patch contains new os_mutex_* calls. Unfortunately these sound like a no-go in a realtime context. Doesn't it make more sense to leave threading mgmt to the application? or make it optional.
Also note the crashes weren't related to concurrency, access to WAMR was already synchronized using a spin lock. The crash happens when calling wasm_store_new() twice during the process lifetime and WAMR_DISABLE_HW_BOUND_CHECK=0. wasm_store_new() is doing some global initialization that causes a crash (macOS at least) on the second call.  The C API link above says _ Multiple stores can be created_ so it looks like an issue.

-DWAMR_BUILD_LIBC_WASI=0 -DWAMR_BUILD_AOT=1 -DWAMR_BUILD_JIT=0 DWAMR_BUILD_INTERP=1 -DWAMR_DISABLE_HW_BOUND_CHECK=0
(lldb) bt
warning: could not execute support code to read Objective-C class data in the process. This may reduce the quality of type information available.
* thread #1, name = 'reaper', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7ff7bf703ea0)
  * frame #0: 0x00000001109c22d0 d_jitdrum`touch_pages + 112
    frame #1: 0x00000001109c1f80 d_jitdrum`os_thread_signal_init + 192
    frame #2: 0x00000001109e94f0 d_jitdrum`aot_signal_init + 16
    frame #3: 0x00000001109c708f d_jitdrum`wasm_store_new + 47
    frame #4: 0x00000001109a9ae6 d_jitdrum`DISTRHO::WasmRuntime::WasmRuntime(this=0x0000600003071200) at WasmRuntime.cpp:46:14 [opt]

Well, it is an interesting call stack. I am afraid I am going to ask for more details.

is there any output log when crashing? I believe you noticed there are os_printf for every failed branch in os_thread_signal_init. hope one of them was triggered.
is calling wasm_store_new() twice in one thread the only condition to trigger the crashing? I have a test case to new/delete in the main thread and 10 spawned threads multiple times and only catch the concurrence problem.
it's better to check some stack related stuff:

parameters of touch_page. they are stack_min_addr and page_size

Here is my test code, please take a look

Well, it is an interesting call stack. I am afraid I am going to ask for more details.

Sure, very eager to contribute on this. I managed to create a minimal project that simulates the host/plugin environment and recreates the exact issue experienced on a real DAW with my VST plugin, more on that below.

is there any output log when crashing? I believe you noticed there are os_printf for every failed branch in os_thread_signal_init. hope one of them was triggered.

No error messages printed. I think this is expected because WAMR does not even have a chance to test for failure in this case. The crashing call is alloca().  I determined this with the help of lldb + adding custom log lines. More on this below.

is calling wasm_store_new() twice in one thread the only condition to trigger the crashing?

Made this specific test and no, calling it twice from the same thread works without issues.

I have a test case to new/delete in the main thread and 10 spawned threads multiple times and only catch the concurrence problem.

I tried threads.c and crashes maybe 1 out of 10 times. The crash happens in a different place compared to my project's, in wasm_store_delete() and not wasm_store_new():
(lldb) run
Process 16356 launched: '/Users/luciano/src/hiphop/a.out' (x86_64)
touch_pages(stack_min_addr=0x7ff7bf701000 page_size=4096)
> Test wasm_store ABCDABCD! in main
Initializing thread 0...
Initializing thread 1...
Initializing thread 2...
Initializing thread 3...
Initializing thread 4...
touch_pages(stack_min_addr=0x70000d89b000 page_size=4096)
touch_pages(stack_min_addr=0x70000d91e000 page_size=4096)
Initializing thread 5...
touch_pages(stack_min_addr=0x70000da24000 page_size=4096)
touch_pages(stack_min_addr=0x70000daa7000 page_size=4096)
Initializing thread 6...
touch_pages(stack_min_addr=0x70000d9a1000 page_size=4096)
Initializing thread 7...
Initializing thread 8...
touch_pages(stack_min_addr=0x70000db2a000 page_size=4096)
Initializing thread 9...
Waiting for thread: 0
touch_pages(stack_min_addr=0x70000dbad000 page_size=4096)
> Test wasm_store ABCDABCD! in the thread
touch_pages(stack_min_addr=0x70000dc30000 page_size=4096)
touch_pages(stack_min_addr=0x70000dd36000 page_size=4096)
> Test wasm_store ABCDABCD! in the thread
touch_pages(stack_min_addr=0x70000dcb3000 page_size=4096)
> Test wasm_store ABCDABCD! in the thread
Waiting for thread: 1
> Test wasm_store ABCDABCD! in the thread
> Test wasm_store ABCDABCD! in the thread
> Test wasm_store ABCDABCD! in the thread
Waiting for thread: 2
> Test wasm_store ABCDABCD! in the thread
Waiting for thread: 3
Waiting for thread: 4
Waiting for thread: 5
Waiting for thread: 6
Waiting for thread: 7
> Test wasm_store ABCDABCD! in the thread
> Test wasm_store ABCDABCD! in the thread
Waiting for thread: 8
> Test wasm_store ABCDABCD! in the thread
Waiting for thread: 9
Process 16356 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x000000010000ad87 a.out`wasm_store_delete + 119
a.out`wasm_store_delete:
->  0x10000ad87 <+119>: movq   0x10(%r15), %rax
    0x10000ad8b <+123>: testq  %rax, %rax
    0x10000ad8e <+126>: je     0x10000adfc               ; <+236>
    0x10000ad90 <+128>: xorl   %ebx, %ebx
Target 0: (a.out) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x000000010000ad87 a.out`wasm_store_delete + 119
    frame #1: 0x000000010000b43d a.out`wasm_engine_delete + 61
    frame #2: 0x0000000100002ff7 a.out`main(argc=1, argv=0x00007ff7bfeff918) at threads.c:81:5
    frame #3: 0x00000001000394fe dyld`start + 462
(lldb)

Note: threads.c ends gracefully most of the times.

it's better to check some stack related stuff:

parameters of touch_page. they are stack_min_addr and page_size

stack_min_addr is always non-NULL and page_size 4096 on my system (macOS 12.2.1 x86_64)
The alloca() crash (the "original" issue in my project) happens when code loaded from two different shared library files attempts to call wasm_store_new(). My knowledge of how runtime linking and the stack work is limited so frankly I don't know where to start looking. Note that creating multiple instances from the same .dylib does not produce a crash, only when a second .dylib is loaded. Both libraries contain identical code. Everything is commented in the source files:
wamr_test_macos-x86_64.zip
To run:
make && ./host

libvmlib.a compiled with -DWAMR_BUILD_LIBC_WASI=0 -DWAMR_DISABLE_HW_BOUND_CHECK=1  -DWAMR_BUILD_AOT=1 -DWAMR_BUILD_INTERP=0
Note: host.c ALWAYS crashes
The issue on MinGW looks totally different, more on that later.

Thanks a lot for exposing that wired problem. It is about a restriction about TLS and dynamic libraries loading on MacOS. I've updated some test code on gist. It includes CMakeLists.txt, main.c and plugin.c.
I will keep you posted when I learne more or figure out how to fix that.

Great. Some more evidence:

Cannot reproduce the issue on Linux using the test attached before your CMake version (slightly modified to let it compile). But I do experience some other glitches in my "real" project, not crashes but unexpected behavior. These issues are also gone with DWAMR_DISABLE_HW_BOUND_CHECK=0. I'll hold on until there's something new to check on Mac, maybe that fixes Linux too.

On MinGW the scenario looks different, my project crashes at invokeNative() when AOT is enabled. libvm is statically linked to my project. I temporarily solved the issue by loading a MSVC-built DLL during runtime instead. Worth mentioning the MinGW libvmlib.a uses the C version of invokeNative() because I've been lazy to find out how to compile the ASM version on MinGW. The MSVC DLL uses ASM, it was built following the official instructions on Windows.

Generally speaking, I found workarounds for everything in my specific use case. The performance gains using AOT are huge.

A simple answer is: Every plugin should link with a dynamic library libiwasm.so instead of a static library libvmlib.a.
More details:
Those are observations from a simple test case. The case includes an executable main.c, a shared librariey plugin.c(will be dlopen() by main.c), a third library third.c(will be linked with plugin.c in two ways). The third.c mimics the libiwasm.so and libvmlib.a in this little story.
The test case creates two shared libraries with plugin.c, they are lib_a_xx and lib_b_xx. After loading both plugin libraries, main.c will compare:

the tls variable address in lib_a and lib_b
the normal variable address in lib_a and lib_b
the external tls variable in lib_a and lib_b. It is defined in the dependency of the plugin
the initialize value of local and external tls variables in lib_a and lib_b
set and get local and external tls variables in lib_a and lib_b

The test case will run twice with two different conditions:

plugin links third staticlly
plugin links third dynamically

Run the test case on Ubuntu and MacOS and get observations:

On both Ubuntu and MacOS, local variables(include tls variables and normal variables) in lib_a and lib_b are in different addresses. So can be operated separately.
On Ubuntu, external tls variables(from third.c) in lib_a and lib_b are always in the same addresses. They can not be operated separately. Even they are from different libraries.
On MacOS, if external tls variables are from a statically linked library, lib_a and lib_b have different symbol addresses for tls variables. They will be operated separately. This is the root cause of the crashing.
On MacOS, if external tls variables are from a dynamic linked library, lib_a and lib_b have same symbol addresses for tls variables. They will be not operated separately. This is the right mode we are expecting.

In you are still interested, here are some thoughts:

In third-library-dynamic-link mode, on both Ubuntu and MacOS, the loader will only load lib_third.so once and assign one module id to lib_third.so. A module in glibc can refer to either an executable or a dynamically shared object, a module ID, therefore, is an index number for a loaded ELF object in a process. In this case, external TLS variables of lib_a and lib_b are from the same TLS blocks for dynamically-loaded modules(please refer to https://uclibc.org/docs/tls.pdf). Because lib_third.so is loaded after main() execution.

In third-library-static-link mode, it seems MacOS acts in the right way. Because under the static-linking, external TLS variables of lib_a and lib_b should be treated like their private own variables and they should have different addresses.

On Ubuntu, if we take a close look at the assemble code of lib_a or lib_b, we will see:
tls_get_addr is used to retrieve the address of a tls variable
0000000000001260 <get_tls>:
   1260:   55                      push   %rbp
   1261:   48 89 e5                mov    %rsp,%rbp
   1264:   48 8d 3d 65 2d 00 00    lea    0x2d65(%rip),%rdi        # 3fd0 <.got>
   126b:   e8 d0 fd ff ff          callq  1040 <__tls_get_addr@plt>
   1270:   8b 80 04 00 00 00       mov    0x4(%rax),%eax
   1276:   5d                      pop    %rbp
   1277:   c3                      retq

3fd0 is the address of a R_X86_64_DTPMOD64 relocation.
DYNAMIC RELOCATION RECORDS
OFFSET           TYPE              VALUE
0000000000003de0 R_X86_64_RELATIVE  *ABS*+0x0000000000001130
0000000000003de8 R_X86_64_RELATIVE  *ABS*+0x00000000000010f0
0000000000004038 R_X86_64_RELATIVE  *ABS*+0x0000000000004038
0000000000003fd0 R_X86_64_DTPMOD64  *ABS*
0000000000003fe0 R_X86_64_GLOB_DAT  _ITM_deregisterTMCloneTable
0000000000003fe8 R_X86_64_GLOB_DAT  __gmon_start__
0000000000003ff0 R_X86_64_GLOB_DAT  _ITM_registerTMCloneTable
0000000000003ff8 R_X86_64_GLOB_DAT<EMAIL_ADDRESS>0000000000004018 R_X86_64_JUMP_SLOT  set_tls_third@@Base
0000000000004020 R_X86_64_JUMP_SLOT<EMAIL_ADDRESS>0000000000004028 R_X86_64_JUMP_SLOT  get_tls_third@@Base
0000000000004030 R_X86_64_JUMP_SLOT  get_tls_addr_third@@Base

__tls_get_addr will return the tls variable address and depends on its first input argument which is the content of the R_X86_64_DTPMOD64 relocation entry.
By tracing the code, I realize the dynamic linker will put a l_tls_modid in it.
  case R_X86_64_DTPMOD64:
    /* Get the information from the link map returned by the
       resolve function.  */
    if (sym_map != NULL)
      *reloc_addr = sym_map->l_tls_modid;
    break;

That leaves us the finally problem, why "those tls variables from different libraries (although from the same static library)" have the same l_tls_modid? I am still looking for a answer for that.

Thanks for the detailed analysis. I don't see a lot deeper than the tip of the iceberg here and unfortunately there is not much more I can contribute other than testing and reporting back. This also confirms my initial thought that it is not a trivial issue to solve.
Since mine is a somehow edge case, thinking practically, the first simple answer is already satisfying  (do not link static). In fact I'm already doing this on Windows (my MinGW libiwasm.a build just does not work when AOT is enabled). Approach could be easily replicated on Linux and Mac.  Fixing everything on every platform combination might be possible but I'm unsure about the need other than curiosity.   I'm really repeating a mantra (prefer static for plugins), dynamic linking could come with its own side effects but I have to see those yet. That should be really studied on a case by case basis. Also it is a good opportunity to dig into OS internals.
Not sure this can be "fixed" or just regarded as part of the operating conditions, at any case this is already great documentation for other projects with similar setups.
Does it make sense that DWAMR_DISABLE_HW_BOUND_CHECK=1 fixes the issue, or is it just a coincidence and should not rely on it?

bool
wasm_runtime_init_thread_env(void)
{
#ifdef BH_PLATFORM_WINDOWS
    if (os_thread_env_init() != 0)
        return false;
#endif

#if WASM_ENABLE_AOT != 0
#ifdef OS_ENABLE_HW_BOUND_CHECK   // => all from here
    if (!aot_signal_init()) {
#ifdef BH_PLATFORM_WINDOWS
        os_thread_env_destroy();
#endif
        return false;
    }
#endif
#endif
    return true;
}

WAMR_DISABLE_HW_BOUND_CHECK=1 will undefined OS_ENABLE_HW_BOUND_CHECK and will not call aot_signal_init() and will not call os_thread_signal_init () and touch_pages and will not trigger the EXC_BAD_ACCESS stop.

Thank you, yes that is right. I wasn't sure about other implications -- so far things work smoothly with that setting.

Hi, there. May I ask if this patch is still necessary for your current solution? If yes, does it target the singleton wasm_engine_t?

Hi, my project does not depend on this very same patch but includes a different workaround .
So far the best solution seems to be what you proposed above, which has the same effect as my workaround but allows to embed WAMR without special care:

wasm_engine_t is a representation of wasm_runtime and an entry of the library. And it is why it is a singleton at the very beginning. And the problem here is when users choose to call wasm_engine_new and wasm_engine_delete multiple times in a form like "ABAB", the first wasm_engine_delete releases the singleton and cause all secondary releasing failed. It looks good to land a count but it may be a little be confused to create multiple engines since there is actually one wasm_runtime and one entry logically. So how about using a reference count instead of an instance count?
struct wasm_engine_t {
  // ...
  uint32_t reference_counts;
};

Maybe I should close this PR and eventually start a new one?  the title is now misleading too.

I would prefer to update this PR with the new patch and change the title.

Just force-pushed a commit that adds a reference counter to wasm_engine_t that is used for deciding whether wasm_engine_delete() must tear down the full WAMR runtime or not.  Reflects the new title of this PR.


No provider for Dispatcher

Hello!
i am getting follow error:
Error in ./StoreLogMonitorComponent class StoreLogMonitorComponent - inline template:1:4 caused by : No provider for Dispatcher
i'm using angular-cli with:
"@ngrx/core": "^1.2.0",
"@ngrx/effects": "^2.0.0",
"@ngrx/router-store": "^1.2.4",
"@ngrx/store": "^2.2.1",
"@ngrx/store-devtools": "^3.1.0",
"@ngrx/store-log-monitor": "^3.0.2",
same error have i already seen : https://github.com/ngrx/store-log-monitor/issues/10

Are you still experiencing this issue? What version of the CLI are you using?

I'm getting this error when turning on --aot for ng serve now :(

Any news on this one ?
ng -v
angular-cli: 1.0.0-beta.24
node: 7.4.0
os: linux x64
@angular/common: 2.3.1
@angular/compiler: 2.3.1
@angular/core: 2.3.1
@angular/flex-layout: 2.0.0-beta.1
@angular/forms: 2.3.1
@angular/http: 2.3.1
@angular/material: 2.0.0-beta.1
@angular/platform-browser: 2.3.1
@angular/platform-browser-dynamic: 2.3.1
@angular/router: 3.3.1
@angular/compiler-cli: 2.3.1

And for ngrx :
"@ngrx/core": "1.2.0",
"@ngrx/effects": "2.0.0",
"@ngrx/store": "2.2.1",

As @photostu said it breaks with AOT :+1:


fix update modify backend's cluster name

Proposed changes
Issue Number: close #xxx

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

run buildall

run buildall


lookup component UX improvement

make changes to current lookup input component, see Astrid's design below.
here is a list of the changes that are significant, when comparing to current look and behavior:

Change "Lookup" button to magnifying glass icon button
@astridu QUESTION: we currently display the instruction "Enter lookup query". Now we just have the magnifying glass icon as clue that this is a lookup. Do we need the instruction somewhere?
when user selects a value from a lookup, add a Label field and display the result in the URI and Label fields (currently it gets "entered" and only the label is displayed below the box)
if field is repeatable, show "+Add another" button, which when clicked gives user another "row" to do another lookup
when there are multiple lookup sources for a field, display the name of each source in the same "row" (vs. wrapping as we do now)
when there are multiple lookup sources, display the name of the one the user is looking at as a button (vs. current display that is underlined and hard to distinguish which one is the one you are viewing)
add clickable option "Enter your own URI and label". when user clicks this, display changes to empty URI and Label field
if user selects or enters more than one value, add Trash can to right of field name (to remove all entered values)
"Language..." button moves to right of input box, to right of diacritic button
add trash can to right of Language button on each "row". when user clicks the trash can it removes the row. there will always be at least one row (i.e., when you delete the first and only row, it is replaced with a blank row)
background is white (vs current dark beige / light beige)
add carat to left of field name to allow user to collapse (see #3011 for mockup of collapsed field)

note: we are NOT changing the current behavior of:
-after user enters text to do a lookup, we show "Add new literal: x" (where x is user's search term) option; @justinlittman if user selects "Add new literal: x" then do we display a URI and label row with only the label filled in?
-required fields get an asterisk and must be completed before Saving
-fields with default value are pre-filled but editable
-fields with a remark or remark URI get tooltip with "i" icon or help link respectively

Implementation note: This should follow the patterns of the InputLiteral and InputURI component.


Create catalog-info.yaml

Terrazzo currently uses the data defined in https://github.com/elastic/ci/blob/main/terrazzo/manifests/prod/buildkite/ to define the BK pipeline. Moving forward, teams should store this information in the affected repo so this PR converts the existing data into an RRE and stores it here.

Hi @LikeTheSalad ! Could you also merge the PR. I don't think I can. Thanks!

Hi @LikeTheSalad ! Could you also merge the PR. I don't think I can. Thanks!

Hi! Sure np 👍


Auto-loading module in Required Modules fails in PowerShell 5.1

When you use Mailozaurr and do Import-Module Mailozaurr everything works fine.
When you add Mailozaurr as part of RequiredModules like below Mailozaurr will fail auto-load if you try to import that module. Otherwise it works fine
@{
    AliasesToExport      = @()
    Author               = 'Przemyslaw Klys'
    CmdletsToExport      = @()
    CompanyName          = 'Evotec'
    CompatiblePSEditions = @('Desktop', 'Core')
    Copyright            = '(c) 2011 - 2021 Przemyslaw Klys @ Evotec. All rights reserved.'
    Description          = 'This module allows creation of password expiry emails for users, managers, administrators and security according to defined templates. It''s able to work with different rules allowing to fully customize who gets the email and when.'
    FunctionsToExport    = @('Find-Password', 'Find-PasswordNotification', 'Send-PasswordEmail', 'Start-PasswordSolution')
    GUID                 = 'c58ff818-1de6-4500-961c-a243c2043255'
    ModuleVersion        = '0.0.14'
    PowerShellVersion    = '5.1'
    PrivateData          = @{
        PSData = @{
            Tags                       = @('password', 'passwordexpiry', 'activedirectory', 'windows')
            ProjectUri                 = 'https://github.com/EvotecIT/PasswordSolution'
            ExternalModuleDependencies = @('ActiveDirectory')
        }
    }
    RequiredModules      = @(@{
            ModuleVersion = '0.0.207'
            ModuleName    = 'PSSharedGoods'
            Guid          = 'ee272aa8-baaa-4edf-9f45-b6d6f7d844fe'
        }, @{
            ModuleVersion = '0.0.15'
            ModuleName    = 'Mailozaurr'
            Guid          = '2b0ea9f1-3ff1-4300-b939-106d5da608fa'
        }, @{
            ModuleVersion = '0.0.156'
            ModuleName    = 'PSWriteHTML'
            Guid          = 'a7bdf640-f5cb-4acf-9de0-365b322d245c'
        }, 'ActiveDirectory')
    RootModule           = 'PasswordSolution.psm1'
}

You need to explicitly import Mailozaurr before importing it. This seems to be related to how classes are parsed during runtime.
I've tried putting classes into a separate files, loading them via ScriptsToProcess, putting classes at the beginning and end of the file. Nothing seems to work.
Please note this affects only PowerShell 5.1 and may not be fixable as classes are a bit special in PowerShell.

Hopefully fixed in 0.0.16


C bindings for other languages?

Hi,
I'm keeping various C# .net bindings, for example vulkan, d3d12, d3d11 etc.
Would be possible to generate C bindings into dll/so/dylib so I can bridge the API?
Feel free to close the issue if not appropriate for the project.
Thanks in advance

That is an interesting idea and some base work here is done for as we do generate a C ABI to talk between the Rust and C++ code.
But would say it is out of scope for this project specifically as its goals is to just use PhysX inside Rust, but would be cool if someone uses the same binding mechanisms we used here to create a pure C binding for other languages to use

I see, are the generated C files under repo and compilable?

They are in the repo under https://github.com/EmbarkStudios/physx-rs/tree/main/physx-sys/src, and compilable by Cargo's build.rs mechanism at https://github.com/EmbarkStudios/physx-rs/blob/main/physx-sys/build.rs

Thanks for info's, will try and report back.

I have started using physx-rs(physx-sys) in C# for the purpose of utilizing a physics engine.
With my csbindgen project, I was able to automatically generate complete bindings.
https://github.com/Cysharp/csbindgen/blob/main/dotnet-sandbox/libphysx_csbindgen.cs
Thank you for sharing this wonderful project.


feat: slider component base

Description
working with slider component

[x] : feat: slider component base
[x] : test: add test file and playground
[ ] : wip: slider direction support. Currently, only horizontal sliders from left to right are supported.😀

Linked Issues
close #21

I'm sorry, I forgot to submit the pnpm-lock. 😶🌫

@Mushrr Hi, useRef and more change, can you take a look at the new structure and other components and update your codes here?

The new structure may cause you to change your tests, you should change your tests again according to the new structure.

@productdevbook OK, I will change my code in this weekend. The structures and components  I used currently  can not cover all scenarios, I am thinking how to fix this. Thanks😊

I'll be here to help you soon.

@Mushr I think you did the merge wrong, you better undo the last commit.

Wait one more day, I'll come to your place. Because many structures have been improved. Thanks for your effort :heart:

that couldn't be better for me. The sturture of current slider component also need resturct. thanks 🥺

I am currently fixing it.


Comment on Comment and Like on Comment

Sending Pull Request for Events Page.
Following objectives are satisfied:
*Backend added
*Template added
*Timeline fixed
*Initial layout fixed
Following issues are there:
*Slider not adjusted
*Mobile View not made

Sending Pull Request for Events Page.
Following objectives are satisfied:

Backend added
Template added
*Timeline fixed
*Initial layout fixed

Following issues are there:
*Slider not adjusted
*Mobile View not made

Reference for Slider: here


Physical model assumptions

A nice-to-have feature would be listing the assumptions that go into the models of the reservoir (e.g. is there fluid originating outside the stimulated volume?). Most people that use this package would probably be familiar, but it would be helpful for someone new who hasn't read the source papers which define these equations.
This is in not something that needs to be solved, but it could be helpful to others.

This is an excellent suggestion. Thank you for the idea.


INABILITY TO QUERY TESTNET FOR EVENT LOGS

I am unable to fetch event logs with code below
 const getNotifications = async () => {     const provider = new ethers.providers.JsonRpcProvider(       "https://api.hyperspace.node.glif.io/rpc/v1"     );     const contract = new ethers.Contract(       contract_address,       contract_abi,       provider     );     const events = await contract.queryFilter(       contract.filters.CommentCreated()     );     setNotifications(events);   };
the error message returned is
Uncaught (in promise) Error: processing response error (body="{\"jsonrpc\":\"2.0\",\"id\":44,\"error\":{\"code\":1,\"message\":\"invalid epoch range: from block is too far in the past (maximum: 60480)\"}}\n", error={"code":1}, requestBody="{\"method\":\"eth_getLogs\",\"params\":[{\"fromBlock\":\"0x0\",\"toBlock\":\"latest\",\"address\":\"0xf6705499de6819b71013f856c5b11e501c5308bd\",\"topics\":[\"0x6ea9605d0243d968938ab0ecdf8178e72bb9141e4b90fe04ac0cc06d4d400b99\"]}],\"id\":44,\"jsonrpc\":\"2.0\"}", requestMethod="POST", url="https://api.hyperspace.node.glif.io/rpc/v1", code=SERVER_ERROR, version=web/5.7.1)

As the message indicates:

invalid epoch range: from block is too far in the past (maximum: 60480)

It's commonplace for hosted RPC nodes to have limits in place. The glif endpoint is configured to support a lookback for at most 2000 epochs. For example, Infura's Ethereum endpoint has a limit of 10000 entries returned:
⟩ curl --url https://mainnet.infura.io/v3/<token> \
      -X POST \
      -H "Content-Type: application/json" \
      -d '{"jsonrpc":"2.0","method":"eth_getLogs","params":[ { "fromBlock": "0x01" }],"id":1}'
{"jsonrpc":"2.0","id":1,"error":{"code":-32005,"data":{"from":"0xCB3D","limit":10000,"to":"0x7B737"},"message":"query returned more than 10000 results. Try with this block range [0xCB3D, 0x7B737]."}}⏎

If node operators want to propose alternative limiting policies, they can raise this as a Lotus discussion.

Actually, the Infura policy allows users to look back up to genesis in windows of 10000 entries max. And the response provides useful hints to aid paging into the past. Ethereum devs will probably expect similar behavior, so Lotus should allow these kinds of configurations.


[REFACTOR] combine Document and Note

No need for them to be separate.
Define Note where Document is currently implemented
use pub(crate) to protect id (https://doc.rust-lang.org/reference/visibility-and-privacy.html)

This is resolved


[Bug]: CDSwitcher fonts characters spacing are too wide

Tweaks version
outrun2006tweaks-4a97d98339fe8b698905bb41b7a9f435435a4ca9
Describe your issue here (please attach the OutRun2006Tweaks.log file with your report, you can drag+drop it into the text area)

OutRun2006Tweaks.log

It's using a full-width font, you'd have to replace it.

the same font isnt that wide if compare to this image. notice the credits display.
https://media.discordapp.net/attachments/1259784325394858061/1267784383272583188/Screenshot_2024-07-30-18-02-11-25_f9ee0578fe1cc94de7482bd41accb329.jpg?ex=66aa0bb7&is=66a8ba37&hm=bb3c0e309cc1f38f442f2126061eae7dd2f13532f094a51b1ca6a1ea9372a2d5&=&format=webp&width=345&height=759

Does changing the SwitcherTitleFontSizeX / SwitcherTitleFontSizeY settings help at all? IIRC I had to play around with those to get the default cdswitcher font to look right.

Does changing the SwitcherTitleFontSizeX / SwitcherTitleFontSizeY settings help at all? IIRC I had to play around with those to get the default cdswitcher font to look right.
not at all.

New idea: use Dynamic Text renderer for CDSwitcher title. This way you can not only render English letters but also accented letters (é, ç, etc.). Font should be customizable, along with the edges, drop shadows, etc.


Make the file parsing process a public function.

Describe the solution you'd like
I want to incorporate the file parse process into the library as a public function

I can make a draft PR when i get off work, but I'm going to take a crack at multiline values as well. That will probably require a bit of refactoring in parsing.

Just to clarify, by this: "incorporate the file parse process", you mean like the function from the link in the other issue (https://github.com/bkeepers/dotenv#parsing)?

Yes, that's right

Ok then it should be covered in what I've got so far. Only change would probably occur when multiline is implemented

Multiline is not yet implemented in my perception.

Correct, i was saying that multiline would affect parsing when it was implemented. I'm working on multiline as well. I've got it basically working [w/ parsing], but it may take a bit of more work.

@nyx-litenite
I'm sorry for the late reply.

I'm working on multiline as well. I've got it basically working [w/ parsing], but it may take a bit of more work.
How much progress are you currently making?
I haven't worked on multiline yet...

No worries. I wasn't going to tackle it, but comments and parsing were kind of related to multi line, so i started taking a peek. I have a good bit of it finished, but I got a little busy over the last couple days. I was going to look into it  a bit more now that I've got a bit more time

Parsing should be fully implemented here (at least my understanding of the hash; let me know if something else is prefered). Multiline isn't implemented, but I don't think it will actually affect the public parsing as much as I once thought.

Parsing should be fully implemented here (at least my understanding of the hash; let me know if something else is prefered). Multiline isn't implemented, but I don't think it will actually affect the public parsing as much as I once thought.

I think this implementation is probably fine.

I think this implementation is probably fine.


Could anybody suggest newer version of this library?

Cause this repo is dead - no closed issued, no new closed PRs - suggest newer version of this library.
Maybe someone took a lead & made better, stronger, newer (compatible with 8.1)?

Let me know if you found one.


Update Documentations

Update README
Make relevant documentation for repository scripts

Working on internal TESTING documentation  on branch #22


feat: framer added

framer added #133

@gabrysia694  any suggestions you want to give related to animation ?