1 ms sleep loop

when I start the hack-manager.js it just sleeps for 1 ms in an endless loop.

It seems that ns.hackAnalyzeSecurity(hack_threads) returns infinity causing an infinite loop.
Not sure how to fix it.

I looked into it, and what SleepyPrince commented is a potential point of infinite looping. Because there are a couple loops that could cause this, I added a condition that will throw an error and tell us which line it is, if it loops for longer than two minutes. I also changed the increment size of the most common overly long loop that will hopefully speed it up if that was the problem as well. Please try running it with the new commits and let me know what the log says if the problem arises again.

Hey, thanks for the info. There is also an error when no money on the server is that the script is hacking, simply fixed by growing it manually but maybe this can be fixed within the script.
Sent from the moon

On 3. Apr 2022, at 22:58, Riley-H-99 @.***> wrote:

I looked into it, and what SleepyPrince commented is a potential point of infinite looping. Because there are a couple loops that could cause this, I added a condition that will throw an error and tell us which line it is, if it loops for longer than two minutes. I also changed the increment size of the most common overly long loop that will hopefully speed it up if that was the problem as well. Please try running it with the new commits and let me know what the log says if the problem arises again.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.

There was another issue that I addressed by changing the script so it no longer adds servers with zero money to be targeted. As far as I know once a server has zero money it can't grow to have any without using the debug console which is why there are so many calculations in the script to ensure that it's impossible to drain a server completely.
Also well done sending that comment from the moon.

Seems to be a sleep issue, initializing grow and weakens on one server then sleeping for 30+ minutes before moving on:
exec: 'targeted-grow.js' on 'pserv-0' with 10333 threads and args: [10333.704137923358, 0, "catalyst"].
exec: 'targeted-weaken.js' on 'pserv-0' with 1727 threads and args: [1727, "catalyst"].
sleep: Sleeping for 2065473.399201595 milliseconds

syburris that's intended, it's sleeping for the duration of the targeted-weaken and targeted-grow scripts before continuing to the next part of a series of grows, weakens, and hacks meant to maximize the money made through hacking. As the security level of the targeted server decreases, and as you get a higher hacking level and augments, the overall time for everything will decrease. 30 minutes is within reason and should be the most time efficient method of hacking for your current stats.

Seems to be a sleep issue, initializing grow and weakens on one server then sleeping for 30+ minutes before moving on:
exec: 'targeted-grow.js' on 'pserv-0' with 10333 threads and args: [10333.704137923358, 0, "catalyst"].
exec: 'targeted-weaken.js' on 'pserv-0' with 1727 threads and args: [1727, "catalyst"].
sleep: Sleeping for 2065473.399201595 milliseconds
looking into it

understood, just found this yesterday and haven't read through everything yet, seemed like different behavior from previous commit so I thought it was an accidental loop, sorry!


Boo who - add test cases

Added two tests that return false for the string literals "true" and "false".
Closes #5349

Great work, thanks!  :+1:


Bump doozer

Pretty sure this will be covered with https://github.com/openshift/aos-cd-jobs/pull/2444


Support for optional Basic Realm for Www-Authenticate header

If you want the browser to show a login popup, and allow the client to store the credentials for a realm, a 401 response needs to come with a WWW-Authenticate: Basic realm="the basic realm" header.
This patch should add support for this. See the README for the syntax.

awesome! 👍

maybe we can use lazy property here?
lazy var accessDenied: Void -> Response = {
    if let realm = realm {
        return Response(status: .Unauthorized, headers: ["WWW-Authenticate": "Basic realm=\"\(realm)\""])
    } else {
        return Response(status: .Unauthorized)
    }
}

The sounds like a good idea, as the normal situation would be chain.proceed


az deployment list missing filter which exists in REST API

Is your feature request related to a problem? Please describe.
CSS reported. Customer wants to use filter to query deployments.
REST API supports filter parameter to filter on ProvisionState
https://docs.microsoft.com/en-us/rest/api/resources/deployments/listatsubscriptionscope
CLI does not support the same
https://docs.microsoft.com/en-us/cli/azure/deployment?view=azure-cli-latest#az-deployment-list
Describe the solution you'd like
CLI should have --filter in az deployment list.
Describe alternatives you've considered
Use --query or az rest as a workaround.
Additional context
Add any other context or screenshots about the feature request here.

@Juliehzl Please help implement this feature.

add to S163.

@zhoxing-ms Let's wait for Alex's feedback and then decide the next step to do. Please keep track of this.


Add support for deleting objectsusers on cloudscale.ch

Summary

Adds a pipeline that deletes objects users on cloudscale.ch, provided there are no more buckets attached to it.
Follows #11
Closes #2

Note: At this time of writing #2 requires that the error message contains the bucket names that may prevent deletion of objects users. If deletion fails in cloudscale when there are buckets, the error message from API reads detail: User can only be deleted if there are no buckets.. I've decided to not explicitly list the bucket names that are attached to the user, since that would require initializing an S3 client and listing the buckets using the credentials from the secret, and that's not worth the effort for an error message.
Checklist

[x] Categorize the PR by setting a good title and adding one of the labels:
bug, enhancement, documentation, change, breaking, dependency
as they show up in the changelog
[x] PR contains the label area:operator
[x] Link this PR to related issues
[x] I have not made any changes in the charts/ directory.

PR currently is based on #16 , but should eventually be rebased after merging


fix(changelog): Repair "Passing arbitrary data..." broken link

Repair a broken link in the changelog

Looks like it probably broke with https://github.com/rustwasm/wasm-bindgen/commit/2e7620e014ab53b450696529afd12e3c685221e1.
Fixes #337.
This is my first PR here; please let me know if I should tweak anything in this PR or in the related issue to be consistent with how things are done here. I'm excited about the WG-wasm roadmap and am looking forward to getting more involved!

our travis has some known issues, but i'm nearly 100% certain this PR is fine :) thank you so much for this (and filing an issue alongside!) i need to get a large PR in but i'll get this in right after that


Add versionIRI metadata to nmrCV.owl release file

This PR edits the nmrCV.owl release file living under https://github.com/nmrML/nmrML/blob/gh-pages/cv/v1.1.0/nmrCV.owl, which, I assume, was copied into the webspace of the nmrML.org website to this path http://nmrml.org/cv/v1.1.0/nmrCV.owl, from where nmrCV is served.
It adds an owl: versionIRI metadata assertion that points to http://nmrml.org/cv/v1.1.0/nmrCV.owl as the version IRI. This ensures that at least the version IRI within the nmrCV.owl is resolvable, once this PR is accepted and this file is overwritten on the nmrml.org server.
So this PR is a small step in the direction of addressing https://github.com/nmrML/nmrCV/issues/23.
It also fixes #189 partially.  Partially, because this addition should also be done on the source itself (https://github.com/nmrML/nmrML/blob/master/ontologies/nmrCV.owl) to ensure that this edit persists, once the automatic doc build pipeline (about which I know nothing) would be rerun, and its GH-pages output would be copied back onto the nmrml.org server.

Testing with curl:
C:\Users\stroemertp>curl -I http://nmrml.org/cv/v1.1.0/nmrCV.owl
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 457554
Server: GitHub.com
Content-Type: application/rdf+xml
Last-Modified: Wed, 07 Aug 2024 18:45:50 GMT
Access-Control-Allow-Origin: *
ETag: "66b3c0de-6fb52"
expires: Thu, 08 Aug 2024 14:14:45 GMT
Cache-Control: max-age=600
x-proxy-cache: MISS
X-GitHub-Request-Id: B394:341630:2B625E:2C2B7C:66B4D07D
Accept-Ranges: bytes
Age: 0
Date: Thu, 08 Aug 2024 17:48:11 GMT
Via: 1.1 varnish
X-Served-By: cache-fra-eddf8230057-FRA
X-Cache: HIT
X-Cache-Hits: 0
X-Timer: S1723139291.234915,VS0,VE107
Vary: Accept-Encoding
X-Fastly-Request-ID: 68d31c32a51c3b751f0062d6077ca7be944f5a37

As @sneumann writes here, there exists no webserver other than the GH pages, so the DNS of nmrML.org points directly there.

To me, it looks like the PR can be merged now. Correct ? Yours, Steffen

Yes can be merged @sneumann. Only my assumption of the extra web space was wrong. So this fix will improve the metadata of the file that lives in the GH pages. We should make the same changes for the equivalent version that lives in the repo's main branch, to synch both, as the former was autogenerated in a separate PR.

Hi, I made required changes on the GH-pages branch. Thanks, Steffen


CARDS-1341: Create a PROMs run mode

This PR adds the proms runMode that, when enabled (eg. -Dsling.run.modes=proms), assigns the name Cards for PROMs to the web application and makes the PROMs Questionnaires available. Additionally, this PR causes the cancer cells background to only be displayed when in the lfs runMode. When in the kids runMode, the Cards4Kids background is displayed. For all other runModes, a plain black background is displayed.
To test:

Build this branch (mvn clean install)
Start CARDS without specifying any runModes. The web application should be named Clinical ARchive for Data Science and the sidebar background should be plain black.
Stop CARDS and rm -rf sling
Start CARDS with the lfs runMode specified. The web application should be named LFS Data Core and the sidebar background should be the cancer cells image.
Stop CARDS and rm -rf sling
Start CARDS with the kids runMode specified. The web application should be named WilliamsDB and the sidebar background should be an image of a heart containing ones and zeros.
Stop CARDS and rm -rf sling
Start CARDS with the cardiac_rehab runMode specified. The web application should be named Cards 4 CaRe and the sidebar background should be plain black.
Stop CARDS and rm -rf sling
Start CARDS with the proms runMode specified. The web application should be named Cards for PROMs and the sidebar background should be plain black. Additionally, the PROMs Questionnaires should be available and usable to create Forms. Please note that Smoking cessation Forms will always be marked as INCOMPLETE - this is a known bug (CARDS-742) but is out-of-scope of this PR.

wrong logo in lfs mode

Smoking cessation questionnaire preview gets stuck on this page ( NEXT button disabled):

Smoking cessation questionnaire preview gets stuck on this page ( NEXT button disabled):

This is by design: at the end of previewing any paginated questionnaire the Next button gets disabled since there's nothing more to do.
Obviously this is not intuitive (@sdumitriu actually complained about it as well while reviewing #722), however I couldn't come up with anything clearer at the time.
One idea is to have an active "close" button instead of the inactive "Next" in questionnaire preview mode, that would take the user to the questionnaires table. For consistency, we should add a Close button on non-paginated questionnaires questionnaires as well, that would look like the Save button on paginated forms.
This should be reported as a separate task, as it's out of scope for the PROMs run mode.

wrong logo in lfs mode

It's just a browser cache issue. A hard refresh on the page will reveal the correct logo. This problem is independent of the brought by this PR and is unlikely to occur in a real-world setting where we don't swap run modes and logos once the application has been put into production mode.

With the removal of the backgrounds, every time the site is loaded there's a 404 request for it, which is not a good practice. Instead of removing them completely, please add a 1x1 black pixel JPG.

Done in d3a9d7d .


cluster-clean, Fix wait for namespace to disappear logic

The logic was not correct, it waited for the wrong variable.
Adjust parameters and fix logic.
Signed-off-by: Or Shoval<EMAIL_ADDRESS>None

/test pull-kubevirt-manifests

addressed comments

/approve

/retest

/retest
pull-kubevirt-e2e-k8s-1.20-sig-storage lane is in a bad condition (not related to this PR)

/retest


Filter out null feature names

Fixes https://github.com/flutter/flutter/issues/76194

I noted this plugin doesn't have Java unit tests wired up, and I'm unsure if a driver test would be able to do the type of mocking that is usually required for stuff like this. @cyanglaz any thoughts?

https://github.com/flutter/plugins/pull/3609/ includes the same fix and more, I'm going to close this one? @jason-simmons


No surface found for window. in all examples

I'm getting a No surface found for window in all examples for master, however if I checkout 0.5.0, this issue does not occur.
Bevy version
72c888feea2d114d6719da515e9859f76e6b1f11 - freshly pulled master
Operating system & version
Arch Linux, 5700XT using amdgpu (mesa 21.2.4-1), testing on sway(wayland) and openbox(x11)
What you did
Briefly...
> git clone https://github.com/bevyengine/bevy.git
> cd bevy
> cargo run --example mesh
> cargo run --example 3d_scene

What you expected to happen
Rendering etc
What actually happened
Seems to render one frame, then crashes out with:
thread 'main' panicked at 'No surface found for window.', crates/bevy_wgpu/src/renderer/wgpu_render_resource_context.rs:372:14

Example of full logs for 3d_scene:
2021-11-27T08:27:27.203322Z  INFO winit::platform_impl::platform::x11::window: Guessed window scale factor: 1.0833333333333333
UNASSIGNED-BestPractices-vkCreateInstance-specialuse-extension-debugging(WARN / SPEC): msgNum: -2111305990 - Validation Warning: [ UNASSIGNED-BestPractices-vkCreateInstance-specialuse-extension-debugging ] Object 0: VK_NULL_HANDLE, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x822806fa | CreateInstance(): Attempting to enable extension VK_EXT_debug_utils, but this extension is intended to support use by applications when debugging and it is strongly recommended that it be otherwise avoided.
    Objects: 1
        [0] 0, type: 1, name: NULL
UNASSIGNED-BestPractices-vkCreateInstance-deprecated-extension(WARN / SPEC): msgNum: -1861097675 - Validation Warning: [ UNASSIGNED-BestPractices-vkCreateInstance-deprecated-extension ] Object 0: VK_NULL_HANDLE, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x9111e735 | CreateInstance(): Attempting to enable deprecated extension VK_KHR_get_physical_device_properties2, but this extension has been promoted to VK_VERSION_1_1.
    Objects: 1
        [0] 0, type: 1, name: NULL
2021-11-27T08:27:27.388847Z  INFO naga::front::spv: Generated by 524296 version 10000
2021-11-27T08:27:27.389734Z  INFO naga::front::spv: Patching...
2021-11-27T08:27:27.390096Z  INFO naga::front::spv: Generated by 524296 version 10000
2021-11-27T08:27:27.396150Z  INFO naga::front::spv: Patching...
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x55a690b90ea0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 0 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x55a690b90ea0, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x55a690b90ea0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 1 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x55a690b90ea0, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x55a690b90ea0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 0 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x55a690b90ea0, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x55a690b90ea0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 2 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x55a690b90ea0, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x55a690b90ea0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 0 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x55a690b90ea0, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x55a690b90ea0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 2 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x55a690b90ea0, type: 3, name: NULL
UNASSIGNED-BestPractices-SuboptimalSwapchain(WARN / PERF): msgNum:<PHONE_NUMBER> - Validation Performance Warning: [ UNASSIGNED-BestPractices-SuboptimalSwapchain ] Object 0: handle = 0x210d07000000003a, type = VK_OBJECT_TYPE_SWAPCHAIN_KHR; | MessageID = 0x441764b3 | vkQueuePresentKHR: VkSwapchainKHR 0x210d07000000003a[] :VK_SUBOPTIMAL_KHR was returned. VK_SUBOPTIMAL_KHR - Presentation will still succeed, subject to the window resize behavior, but the swapchain is no longer configured optimally for the surface it targets. Applications should query updated surface information and recreate their swapchain at the next convenient opportunity.
    Objects: 1
        [0] 0x210d07000000003a, type:<PHONE_NUMBER>, name: NULL
thread 'main' panicked at 'No surface found for window.', crates/bevy_wgpu/src/renderer/wgpu_render_resource_context.rs:372:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Sounds like something in the wgpu update broke your setup. Could you test out the examples at https://github.com/gfx-rs/wgpu, and experiment with the various branches and/or commits?
The other suggestion I have is to try updating your GPU drivers.

Have you tried running with the wayland feature? I notice that you're using the X11 backend while on sway with XWayland. I also get a similar error message when running with the X11 backend.

Maybe it was the recent raw-window-handle crate version 4.0 update with breaking changes? What version do you have pulled down?

Sounds like something in the wgpu update broke your setup. Could you test out the examples at https://github.com/gfx-rs/wgpu, and experiment with the various branches and/or commits?

Haven't been able to repro an issue master or v0.11 of wgpu (which seems to be the version used by bevy), if you have any particular commits, tags, or branches you reckon I should try then shoot.

The other suggestion I have is to try updating your GPU drivers.

Updated mesa to 21.2.5-1, seems to make no difference.

Have you tried running with the wayland feature? I notice that you're using the X11 backend while on sway with XWayland. I also get a similar error message when running with the X11 backend.

Here's the results of running the 3d_scene example with the wayland feature enabled;
 cargo run --features wayland --example 3d_scene
[compile omited]
    Finished dev [unoptimized + debuginfo] target(s) in 32.90s
     Running `target/debug/examples/3d_scene`
UNASSIGNED-BestPractices-vkCreateInstance-specialuse-extension-debugging(WARN / SPEC): msgNum: -2111305990 - Validation Warning: [ UNASSIGNED-BestPractices-vkCreateInstance-specialuse-extension-debugging ] Object 0: VK_NULL_HANDLE, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x822806fa | CreateInstance(): Attempting to enable extension VK_EXT_debug_utils, but this extension is intended to support use by applications when debugging and it is strongly recommended that it be otherwise avoided.
    Objects: 1
        [0] 0, type: 1, name: NULL
UNASSIGNED-BestPractices-vkCreateInstance-deprecated-extension(WARN / SPEC): msgNum: -1861097675 - Validation Warning: [ UNASSIGNED-BestPractices-vkCreateInstance-deprecated-extension ] Object 0: VK_NULL_HANDLE, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x9111e735 | CreateInstance(): Attempting to enable deprecated extension VK_KHR_get_physical_device_properties2, but this extension has been promoted to VK_VERSION_1_1.
    Objects: 1
        [0] 0, type: 1, name: NULL
2021-11-27T22:53:44.765174Z  INFO naga::front::spv: Generated by 524296 version 10000
2021-11-27T22:53:44.766125Z  INFO naga::front::spv: Patching...
2021-11-27T22:53:44.766486Z  INFO naga::front::spv: Generated by 524296 version 10000
2021-11-27T22:53:44.772529Z  INFO naga::front::spv: Patching...
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x56481c74cb70, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 0 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x56481c74cb70, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x56481c74cb70, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 1 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x56481c74cb70, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x56481c74cb70, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 0 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x56481c74cb70, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x56481c74cb70, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 2 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x56481c74cb70, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x56481c74cb70, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 0 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x56481c74cb70, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x56481c74cb70, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 2 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x56481c74cb70, type: 3, name: NULL
thread 'main' panicked at 'No surface found for window.', crates/bevy_wgpu/src/renderer/wgpu_render_resource_context.rs:372:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Unfortunately, no dice. I was hopeful because I've had xwayland issues before, but it also wouldn't explain why the same behavior shows under openbox on x11.

Is this caused by #3051? Seems suspiciously relevant.

Does this work on current main?


[Bug]: inconsistent iconSize between iOS and Android

Mapbox Implementation
Mapbox
Mapbox Version
default
Platform
iOS, Android
@rnmapbox/maps version
10.0.11
Standalone component to reproduce
import React from 'react';
import {
  Images,
  MapView,
  ShapeSource,
  SymbolLayer,
  Camera,
} from '@rnmapbox/maps';

const styles = {
  mapView: { flex: 1 },
  iconLayer: {
    iconSize: 3.0,
    iconImage: 'example'
  },
};

const features = {
  type: 'FeatureCollection',
  features: [
    {
      type: 'Feature',
      id: 'a-feature',
      geometry: {
        type: 'Point',
        coordinates: [-74.00597, 40.71427],
      },
    },
  ],
};

class BugReportExample extends React.Component {
  render() {
    return (
      <MapView style={styles.mapView}>
        <Camera centerCoordinate={[-74.00597, 40.71427]} zoomLevel={14} />
        <Images images={{ example: require('../assets/example.png') }} />
        <ShapeSource id={'shape-source-id-0'} shape={features}>
          <SymbolLayer
            id="symbol-id"
            style={styles.iconLayer}
          />
        </ShapeSource>
      </MapView>
    );
  }
}

export default BugReportExample;

Observed behavior and steps to reproduce
Images on iOS are are ≈2.5x larger than on Android:

Expected behavior
Same size on both device types.
Notes / preliminary analysis
React 18.2.0
React Native 0.72.4
@rnmapbox/maps 10.0.11
Additional links and references
Previous related bug: https://github.com/rnmapbox/maps/issues/68

note from paul's teammate: we haven't been able to determine yet whether this is a bug in our code which generates the icon image per platform, or a bug in rnmapbox's icon scaling, so if this can't be reproduced it should be safe to close out

We are having the same problem, please write an update if it was a bug in your code.

update: current best guess is that it is due to rnmapbox ignoring the scale attribute of ImageURISources passed into Mapbox.Images's images argument on Android only. in our case we couldn't avoid using the scale attribute due to the way our vector icon library generates images, so we are trying to work around by multiplying the size of the icon on Android only by PixelRatio.get(). will update again if this resolves on all platforms once it gets pushed to more users' devices.

I'm seeing something similar, but with the built-in user heading icon. On iOS in the dev client the image is the proper size, but when built for production the image looks about 3x too big.
Dev Client

Production Build

It's really strange for me. Only certain icons are different sizes, some are rendered the same size regardless of platform. Tried resizing the inconsistent one, but didn't seem to resolve it.

Hey, I think a potential fix could be done here android/src/main/java-v10/com/mapbox/rctmgl/components/images/RCTMGLImages.kt
We might need to replace (1.0/((160.0/bitmap.density)) * scale).toFloat() , with scale.toFloat.  Tested it on 2 devices with different ratio sizes. Works well on my end

I think those are the factors:
1.) Image DPI (a 200x200 image with 144 DPI should be half the size on the map than a 200x200 image with 77 DPI)
2.) Screen scaling (I think this mostly affects android). Device density can go from 160 DPI/MDPI => XXXHDPI aka 640DPI)
3.) Debug/release version, in debug version the image is coming from metro bundler and I think it's an url, wile in release it's from the disk, and has different structure.

Thanks, as I understood, in your fixes for old versions the scale is passed directly to sdk methods without modifying. So what scale RN picks depends on what is available in file system (@, @2x, @3x), that image will be created.
In release mode, the asset looks like this
{ NativeMap: {"__packager_asset":true,"width":29,"uri":"packages_native_src_assets_map_route_bridge_unsafe","height":29,"scale":2} }
Hence, in both cases (debug, prod) the scale property is available and the value is the same. And it's correct as on my device pixelRatio is 1.5 and the image was picked @2x.

So I've tried the example in the bug report, and for me it was the same size.

This was in debug build and using the example in the example repo:

So if anyone have issue with icon size, please write a clear description:
1.) Prod or Debug version
2.) Exact image (was it a multi scale image with `@2x etc version)
3.) Exact images declaration (was scale property used?)
4.) Android device denisity
Screenshots on both platform.
Ideally you can also add a circle layer above the icons, to see how it compares with the desired size:
With the example.png as it's 44x44 pixel sized.
I've just added a CircleLayer to verify it's correct size on both platforms:
        <ShapeSource id={'shape-source-id-0'} shape={features}>
          <SymbolLayer id="symbol-id" style={styles.iconLayer} />
          <CircleLayer
            id="circel-layer"
            style={{
              circleRadius: 3 * (44.0 / 2),
              circleOpacity: 0.4,
              circleStrokeColor: 'green',
              circleStrokeWidth: 2,
            }}
          />
        </ShapeSource>

android:

iOS:

The issues should have been fixed 10.1.0-beta.10, can you pls confirm?

Thanks @mfazekas. It works as expected in debug, but not in prod

Device density 1.5;
Image for testing scale-test-icon. It should be an image with different resolutions @2, @3 in assets folder.

Note: The size of image looks the same as with this workaround https://github.com/rnmapbox/maps/issues/3009#issuecomment-1739935698
Prod

Debug

@snazarkoo can you test 10.1.0-beta.11 the production now uses the same Fresco pipeline for prod as used for debug

@mfazekas Perfect, icons are properly sized. Thanks for your work

Hello, I'm having this exact issue, but the other way around.
The icons look oversized on the iOS production builds only.
Using - "@rnmapbox/maps": "10.1.3".

Hey @JasonSanford , did you find a solution for your issue?
I'm still experiencing the issue on version "10.1.3" (magnified HeadingIcon & some SymbolLayers).


[REQUEST] Games patch notes

Is your feature request related to a problem? Please describe.
Seeing game updates
Describe the solution you'd like
I would like that such as in Steam, the game patch notes are added to the game screen.
It would make it easier than having to go to the game or steam page to see related patch notes and etc.
Describe alternatives you've considered
No response
Additional context
No response

we cant guarantee or expect the download versions to match the ones on steam, so the patch notes in game page might end up causing more confusion than helping


Fix typo in README.md

Description

Why is this needed

Fixes: #
How Has This Been Tested?

How are existing users impacted? What migration steps/scripts do we need?

Checklist:
I have:

[ ] updated the documentation and/or roadmap (if required)
[ ] added unit or e2e tests
[ ] provided instructions on how to upgrade

@sp1999 Thanks. Can you signoff your commit! Quick and easywith this change if you do git commit --amend --no-edit -s && git push -f with your branch checked out.


Action log structure

Is your feature request related to a problem? Please describe.
Action log can be useful for monitoring, debugging or any other analysis. With the fragment event log, it is the source of knowledge about how fragments were processed. It will contain details about services invocations, retries, fallbacks. Developers / SE can easily monitor what is happening the incoming requests, what services are down, what fragments are incomplete.
Describe the solution you'd like
An Action log structure must address all scenarios available in Knot.x graph processing: simple actions, actions with behaviours, composite actions.
An Action is a simple function that gets a fragment, does some updates and responds with the new fragment, transition and action log:
F -> (F', T', AL)

F - fragment
T - transition
AL - action log

A1 -> A2 -> A3
A scenario with three simple Actions.
The processing flow is managed by Graph Engine (GE) and looks like:

GE -(F0)-> A1 -(F1,T1,AL1)-> GE
GE -(F1)-> A2 -(F2,T2,AL2)-> GE
GE -(F2)-> A3 -(F3,T3,AL3)-> GE

Actions are evaluated one after another, the fragment event log containg processing history looks like:

Action
Transition
Action Log

A1
T1
AL1

A2
T2
AL2

A3
T3
AL3

A1 (A1' -> A1'' -> A1''') -> A2 -> A3
A scenario with three simple Actions. First action is wrapped with two behaviours, for example in memory cache behaviour and circuit breaker behaviour.
The flow looks like:

GE -(F0)-> A1' -(F0')-> A1'' -(F0'')-> A1''' -(F1''',T1''',AL1''')-> A1'' -(F1'',T1'',(AL1'',AL'''))-> A1' -(F1',T1',(AL1', AL1'',AL'''))-> GE
GE -(F1')-> A2 -(F2,T2,AL2)-> GE
GE -(F2)-> A3 -(F3,T3,AL3)-> GE

Event log entries:

Action alias
Transition
Action Log

A1
T1
complex AL1

A2
T2
AL2

A3
T3
AL3

Behaviours wrap other behaviours or simple actions and delegate a fragment to them (for processing). They can introduce some stability patterns such as retires, it means that they can call a wrapped Action many times.
The proposal action log structure for the A1 (A1' -> A1'' -> A1''') processing can be
{
  _alias: A'
  _logs: {}
  _doAction [
    {
      _alias: A''
      _logs: {}
      _doAction {
        _alias: A'''
        _logs: {}
      }
    }
  ]
}

Please note that _doAction contains a table to support many invocations.
A more real example for a circuit breaker behaviour can look like:
{
  _alias: CB
  _logs: {
    retries: 3
  }
  _doAction [
    {
      _alias: http
      _logs: {
        status: 500
      }
    },
    {
      _alias: http
      _logs: {
        status: 500
      }
    },
    {
      _alias: http
      _logs: {
        status: 200
      }
    }
  ]
}

** [A11 -> A12; A13 -> A14] -> A2 -> A3**
A scenario with one composite Action and two simple Actions. A composite Action consists of two simple actions with successors.

Action alias
Transition
Action Log

A11
-
AL11

A12
-
AL12

A13
-
AL13

A14
-
AL14

composite
T1
AL1

A2
T2
A2

A3
T3
A3

Additional context

debug mode that allows to analyse each Fragment in the browser (by clicking on it)

Implemented, see ActionLog.


artman regen bigtable with php-cs-fixer v2.2.7

PTAL

Closing as bigtable has already been refreshed in api-client-staging


new version blows up when opening for requests

it's the first time seeing this in prod, when deploying f040a9e5741ca16c84ebc763314f7b4391c98900 with agg-settings = 10min:6h:2:38d:true,2h:6h:2:120d:true, not sure it's because of these changes or because the load pattern has changed (increased) due to recent extra signups:

we went from 20k/s to 24k/s ingest
there's a lot more consistent requests for larger time ranges:

i've seen this twice:

once after being up for 16h but not getting requests, opening up requests (and disabling the other node for reads) -> instant mem+cpu spike and OOM
once with the other node still accepting reads and as soon as the 1h warmup period passed -> instant mem+cpu spike and OOM

MT dash: https://grafana-monitor.raintank.io/dashboard/snapshot/IWAPH7sho06f0n0TgBmdWsuQykwZfVmM
sys dash: https://grafana-monitor.raintank.io/dashboard/snapshot/Fv7Rb3G0yR5enyZF7oS2kF2iyMMaBPIW
will try to repro in QA
hypothesis:maybe extensive GC workload maxing out cpu and blocking progress, but mem usage shouldn't be that high i think. gctrace will help.

no luck yet.
in raintank-docker i'm trying to fill up a bunch of data ( up to 3 days back) and then suddenly launch a similar request workload as seen in prod:
+./fake_metrics_to_nsq -keys-per-org 100 -orgs 10 -statsd-addr statsdaemon:8125 -nsqd-tcp-address nsqd:4150 -offset 3d -speedup 400 -stop-at-now &> /var/log/raintank/fake.log
+./fake_metrics_to_nsq -keys-per-org 100 -orgs 10 -statsd-addr statsdaemon:8125 -nsqd-tcp-address nsqd:4150 &> /var/log/raintank/fake2.log &

followed by:
$ cat repro-prod-issue.sh
#!/bin/sh
./inspect-es -es-index metric -format vegeta-mt -from 3d -es-addr elasticsearch:9200 > mc.txt
./inspect-es -es-index metric -format vegeta-mt -from 9min -es-addr elasticsearch:9200 > m.txt
ls -alh mc.txt m.txt

cat mc.txt | sed 's#18763#6063#' | ./vegeta attack -duration 100s -rate 500 > mc.out &
cat m.txt | sed 's#18763#6063#'  | ./vegeta attack -duration 100s -rate 5000 > m.out &
echo "launched!"
sleep 110

but MT handles this just fine and memory only goes up by a gig or so.
maybe cause i'm working with a smaller amount of metrics here (1k vs 500k in prod). it would take too long to on-demand backload a similar volume on my laptop and since there's no caching going on (at least not in MT)  requesting the same data multiple times should work just as well.
notably in prod:

all cpu cores went up to 50% strongly suggesting GC
also seeing high request handle durations and cassandra response times, but this could be due to cpu maxing out. cassandra dash shows read latency avg of no higher than 5ms (real bummer it only shows averages)

maybe i can do a qa run with similar-to-prod metric volume.
now i'm trying something else: i suspect that maybe the index for the new graphite endpoint introduces too many new pointers and keeps the GC busier
so using basically a steady instream like so:
+./fake_metrics_to_nsq -keys-per-org 100 -orgs 100 -statsd-addr statsdaemon:8125 -nsqd-tcp-address nsqd:4150 -offset 3h -speedup 10 -stop-at-now &> /var/log/raintank/fake.log
+./fake_metrics_to_nsq -keys-per-org 100 -orgs 100 -statsd-addr statsdaemon:8125 -nsqd-tcp-address nsqd:4150 &> /var/log/raintank/fake2.log &

and just running metric-tank with +GODEBUG=gctrace=1 ./metric_tank
with a patched GC like so:
diff --git a/src/runtime/mgc.go b/src/runtime/mgc.go
index 94301c6..b0d3528 100644
--- a/src/runtime/mgc.go
+++ b/src/runtime/mgc.go
@@ -1297,6 +1297,7 @@ func gcMarkTermination() {
                if work.mode != gcBackgroundMode {
                        print(" (forced)")
                }
+               print(" sw ", gcController.scanWork, " bgscancred ", gcController.bgScanCredit)
                print("\n")
                printunlock()
        }

latest master:
sys dash: https://snapshot.raintank.io/dashboard/snapshot/D1A8qzn673G2v01syp32bxlZ516cH8qb
MT dash: https://snapshot.raintank.io/dashboard/snapshot/j5hPeum00o8Itpa8234TYC8cV2bfKgkz

a85f3af (previous stable in prod, aka pkg-0.1.0-1457484036ubuntu1)
MT: https://snapshot.raintank.io/dashboard/snapshot/KU1EmofIUNT6EusRvPrbNkvwvIIcwF5v
sys: https://snapshot.raintank.io/dashboard/snapshot/1jDols6042Vx2CLPotc5QQqt2NRvpa1T
looks the same again.for the record, attached the gc view which also looks the same

been doing more testing using a new mt4 instance that's not in the pool and that has the "broken" MT installed.
then gor to replicate prod traffic to mt4
dieter@metric-tank-2-prod:~$ sudo ./gor --input-raw :18763 --output-http metric-tank-4-prod:18763

also ran loops like
while true ;do let i=i+1; echo $i; curl 'http://localhost:18763/debug/pprof/profile?seconds=1' > mt4-cpu-$i; done
while true ;do let i=i+1; echo $i; curl http://localhost:18763/debug/pprof/heap > mt4-heap-$i; done

to get profiles right before crash. unfortunately those don't seem to show anything interesting.
~ ❯❯❯ go tool pprof --inuse_space mt4-bin mt4-heap-2119
Entering interactive mode (type "help" for commands)
(pprof) top50 -cum
2800.22MB of 2823.27MB total (99.18%)
Dropped 195 nodes (cum <= 14.12MB)
      flat  flat%   sum%        cum   cum%
         0     0%     0%  2823.27MB   100%  runtime.goexit
         0     0%     0%  1844.66MB 65.34%  github.com/nsqio/go-nsq.(*Consumer).handlerLoop
         0     0%     0%  1844.66MB 65.34%  main.(*Handler).HandleMessage
      27MB  0.96%  0.96%  1093.60MB 38.74%  main.(*AggMetrics).GetOrCreate
  760.09MB 26.92% 27.88%  1066.60MB 37.78%  main.NewAggMetric
         0     0% 27.88%   968.06MB 34.29%  main.main
         0     0% 27.88%   968.06MB 34.29%  runtime.main
  104.01MB  3.68% 31.56%   900.58MB 31.90%  main.NewAggregator
         0     0% 31.56%   709.56MB 25.13%  main.(*AggMetric).Add
         0     0% 31.56%   586.57MB 20.78%  main.(*DefCache).Backfill
         0     0% 31.56%   586.57MB 20.78%  main.NewDefCache
         0     0% 31.56%   530.07MB 18.78%  github.com/raintank/raintank-metric/metricdef.(*DefsEs).GetMetrics
   85.51MB  3.03% 34.59%   530.07MB 18.78%  github.com/raintank/raintank-metric/schema.MetricDefinitionFromJSON
  177.51MB  6.29% 40.88%   516.03MB 18.28%  main.NewChunk
         0     0% 40.88%   476.52MB 16.88%  main.(*AggMetric).addAggregators
         0     0% 40.88%   476.52MB 16.88%  main.(*Aggregator).Add
         0     0% 40.88%   476.52MB 16.88%  main.(*Aggregator).flush
         0     0% 40.88%   444.56MB 15.75%  encoding/json.Unmarshal
         0     0% 40.88%   439.56MB 15.57%  encoding/json.(*decodeState).object
         0     0% 40.88%   439.56MB 15.57%  encoding/json.(*decodeState).unmarshal
         0     0% 40.88%   439.56MB 15.57%  encoding/json.(*decodeState).value
  381.48MB 13.51% 54.39%   381.48MB 13.51%  main.NewCassandraStore
  338.52MB 11.99% 66.38%   338.52MB 11.99%  github.com/dgryski/go-tsz.New
  203.51MB  7.21% 73.59%   203.51MB  7.21%  fmt.Sprintf
      26MB  0.92% 74.51%   191.53MB  6.78%  github.com/dgryski/go-tsz.(*Series).Push
         0     0% 74.51%   191.53MB  6.78%  main.(*Chunk).Push
         0     0% 74.51%   181.55MB  6.43%  reflect.Value.SetMapIndex
  181.55MB  6.43% 80.94%   181.55MB  6.43%  reflect.mapassign
  167.53MB  5.93% 86.87%   167.53MB  5.93%  github.com/dgryski/go-tsz.(*bstream).writeBits
         0     0% 86.87%   158.51MB  5.61%  encoding/json.(*decodeState).literal
  158.51MB  5.61% 92.49%   158.51MB  5.61%  encoding/json.(*decodeState).literalStore
         0     0% 92.49%       86MB  3.05%  encoding/json.(*decodeState).array
   56.50MB  2.00% 94.49%    56.50MB  2.00%  main.(*DefCache).Backfill.func1
         0     0% 94.49%    48.50MB  1.72%  reflect.MakeSlice
   48.50MB  1.72% 96.21%    48.50MB  1.72%  reflect.unsafe_NewArray
         0     0% 96.21%    35.50MB  1.26%  reflect.MakeMap
   35.50MB  1.26% 97.47%    35.50MB  1.26%  reflect.makemap
         0     0% 97.47%       33MB  1.17%  github.com/raintank/raintank-metric/msg.(*MetricData).DecodeMetricData
    1.50MB 0.053% 97.52%       33MB  1.17%  github.com/raintank/raintank-metric/schema.(*MetricDataArray).UnmarshalMsg
    1.50MB 0.053% 97.57%    31.50MB  1.12%  github.com/raintank/raintank-metric/schema.(*MetricData).UnmarshalMsg
      30MB  1.06% 98.63%       30MB  1.06%  github.com/tinylib/msgp/msgp.ReadStringBytes
         0     0% 98.63%    15.50MB  0.55%  reflect.Value.Convert
   15.50MB  0.55% 99.18%    15.50MB  0.55%  reflect.cvtBytesString
(pprof)
~ ❯❯❯ go tool pprof mt4-bin mt4-cpu-60
Entering interactive mode (type "help" for commands)
(pprof) top50 -cum
3.52s of 3.54s total (99.44%)
Dropped 6 nodes (cum <= 0.02s)
      flat  flat%   sum%        cum   cum%
         0     0%     0%      3.54s   100%  runtime.goexit
         0     0%     0%      2.85s 80.51%  main.Get
         0     0%     0%      2.85s 80.51%  main.get.func1
     0.26s  7.34%  7.34%      2.85s 80.51%  main.graphiteRaintankJSON
         0     0%  7.34%      2.85s 80.51%  net/http.(*ServeMux).ServeHTTP
         0     0%  7.34%      2.85s 80.51%  net/http.(*conn).serve
         0     0%  7.34%      2.85s 80.51%  net/http.HandlerFunc.ServeHTTP
         0     0%  7.34%      2.85s 80.51%  net/http.serverHandler.ServeHTTP
     0.06s  1.69%  9.04%      1.47s 41.53%  strconv.AppendFloat
     0.11s  3.11% 12.15%      1.41s 39.83%  strconv.genericFtoa
     0.19s  5.37% 17.51%      1.30s 36.72%  strconv.bigFtoa
         0     0% 17.51%      1.29s 36.44%  runtime.growslice
     1.06s 29.94% 47.46%      1.06s 29.94%  runtime.memmove
         0     0% 47.46%      0.76s 21.47%  runtime.growslice_n
         0     0% 47.46%      0.69s 19.49%  runtime.gcBgMarkWorker
         0     0% 47.46%      0.69s 19.49%  runtime.gcDrain
     0.41s 11.58% 59.04%      0.68s 19.21%  runtime.scanobject
     0.08s  2.26% 61.30%      0.68s 19.21%  strconv.formatDigits
     0.19s  5.37% 66.67%      0.60s 16.95%  strconv.fmtF
     0.32s  9.04% 75.71%      0.32s  9.04%  runtime.duffzero
     0.29s  8.19% 83.90%      0.29s  8.19%  runtime.memclr
     0.07s  1.98% 85.88%      0.21s  5.93%  strconv.AppendUint
     0.13s  3.67% 89.55%      0.18s  5.08%  runtime.greyobject
     0.09s  2.54% 92.09%      0.14s  3.95%  strconv.formatBits
     0.09s  2.54% 94.63%      0.09s  2.54%  runtime.heapBitsForObject
     0.05s  1.41% 96.05%      0.07s  1.98%  strconv.(*decimal).Assign
         0     0% 96.05%      0.05s  1.41%  runtime.heapBits.setMarked
     0.05s  1.41% 97.46%      0.05s  1.41%  runtime/internal/atomic.Or8
     0.05s  1.41% 98.87%      0.05s  1.41%  strconv.(*decimal).Round
         0     0% 98.87%      0.03s  0.85%  runtime.mallocgc
         0     0% 98.87%      0.03s  0.85%  runtime.rawmem
         0     0% 98.87%      0.03s  0.85%  runtime.systemstack
         0     0% 98.87%      0.02s  0.56%  runtime.heapBits.initSpan
         0     0% 98.87%      0.02s  0.56%  runtime.largeAlloc
         0     0% 98.87%      0.02s  0.56%  runtime.mallocgc.func3
     0.02s  0.56% 99.44%      0.02s  0.56%  strconv.trim

another experiment, bisecting locally compiled MT instances:
sudo service metric_tank stop; sudo cp metric_tank /usr/sbin/metric_tank ; sudo service metric_tank start; ps aux | grep metric_tank

latest master crash: https://snapshot.raintank.io/dashboard/snapshot/xMn4Otu7iHDE1697hp2fNRkj8LQi9Rl8

a85f3af : ? all request durations go up -> request volume drops, but mem is good. https://snapshot.raintank.io/dashboard/snapshot/6jEWIsSJmfC4629ucjGhF3l3yioBdnns

d1f58892104ee0515a0a727686469f7ebc59a2fc (after faster consolidation merge and before graphite endpoint): crash https://snapshot.raintank.io/dashboard/snapshot/eEZunlcEbH3VE9sn6l3vjM9XtDlB41ds

f817029..seems to be sane timings don't even go up
https://snapshot.raintank.io/dashboard/snapshot/pIdK5z4pjfL1wcEhBLX9eZz4YzF5uVio

8d18f34313097fbda66bfd99a321267790a34df5 disable colors in metric_tank's logs -> instant crash https://snapshot.raintank.io/dashboard/snapshot/i8CzC9yqctFBkHHWpkLN7NvnsbTTeCGf
same but 6e6cb96 reverted: works fine again : https://snapshot.raintank.io/dashboard/snapshot/qeM4pfKB8ret4vwVuA7F7b032u2vve4u

got another mem profile, this time with
+       runtime.MemProfileRate = 1

this shows:
(pprof) top50 -cum
25753346.64kB of 26036249.83kB total (98.91%)
Dropped 633 nodes (cum <= 130181.25kB)
      flat  flat%   sum%        cum   cum%
         0     0%     0% 26035269.52kB   100%  runtime.goexit
         0     0%     0% 20136622.62kB 77.34%  main.getTargets.func1
         0     0%     0% 20136621.12kB 77.34%  main.getTarget
20134415.44kB 77.33% 77.33% 20134415.44kB 77.33%  main.fix
    3.72kB 1.4e-05% 77.33% 3419776.31kB 13.13%  net/http.(*conn).serve
         0     0% 77.33% 3416172.34kB 13.12%  net/http.(*ServeMux).ServeHTTP
         0     0% 77.33% 3416172.34kB 13.12%  net/http.HandlerFunc.ServeHTTP
         0     0% 77.33% 3416172.34kB 13.12%  net/http.serverHandler.ServeHTTP
   48.81kB 0.00019% 77.33% 3416147.31kB 13.12%  main.Get
         0     0% 77.33% 3416147.31kB 13.12%  main.get.func1
   88.34kB 0.00034% 77.33% 3411948.09kB 13.10%  main.graphiteRaintankJSON
         0     0% 77.33% 3411709.25kB 13.10%  strconv.AppendFloat
         0     0% 77.33% 3411709.25kB 13.10%  strconv.bigFtoa
3411709.25kB 13.10% 90.44% 3411709.25kB 13.10%  strconv.fmtF
         0     0% 90.44% 3411709.25kB 13.10%  strconv.formatDigits
         0     0% 90.44% 3411709.25kB 13.10%  strconv.genericFtoa
         0     0% 90.44% 1467987.61kB  5.64%  github.com/nsqio/go-nsq.(*Consumer).handlerLoop
         0     0% 90.44% 1467982.89kB  5.64%  main.(*Handler).HandleMessage
27464.53kB  0.11% 90.54% 1144988.02kB  4.40%  main.(*AggMetrics).GetOrCreate
800744.55kB  3.08% 93.62% 1117522.61kB  4.29%  main.NewAggMetric
    0.33kB 1.3e-06% 93.62% 1004349.55kB  3.86%  main.main
         0     0% 93.62% 1004349.55kB  3.86%  runtime.main
105592.69kB  0.41% 94.02% 950334.19kB  3.65%  main.NewAggregator
    0.16kB 6e-07% 94.02% 613466.55kB  2.36%  main.NewDefCache
         0     0% 94.02% 613466.39kB  2.36%  main.(*DefCache).Backfill
         0     0% 94.02% 556115.67kB  2.14%  github.com/raintank/raintank-metric/metricdef.(*DefsEs).GetMetrics
97334.16kB  0.37% 94.40% 556110.27kB  2.14%  github.com/raintank/raintank-metric/schema.MetricDefinitionFromJSON
         0     0% 94.40% 458785.92kB  1.76%  encoding/json.Unmarshal
         0     0% 94.40% 454360.55kB  1.75%  encoding/json.(*decodeState).object
         0     0% 94.40% 454360.55kB  1.75%  encoding/json.(*decodeState).unmarshal
         0     0% 94.40% 454360.55kB  1.75%  encoding/json.(*decodeState).value
390641.62kB  1.50% 95.90% 390749.15kB  1.50%  main.NewCassandraStore
    0.22kB 8.4e-07% 95.90% 293175.67kB  1.13%  main.(*AggMetric).Add
211988.97kB  0.81% 96.71% 212170.38kB  0.81%  fmt.Sprintf
70345.72kB  0.27% 96.98% 211037.25kB  0.81%  main.NewChunk
         0     0% 96.98% 194668.31kB  0.75%  reflect.Value.SetMapIndex
194668.31kB  0.75% 97.73% 194668.31kB  0.75%  reflect.mapassign
         0     0% 97.73% 167608.80kB  0.64%  encoding/json.(*decodeState).literal
167608.39kB  0.64% 98.37% 167608.80kB  0.64%  encoding/json.(*decodeState).literalStore
         0     0% 98.37% 147612.88kB  0.57%  main.(*AggMetric).addAggregators
         0     0% 98.37% 147612.88kB  0.57%  main.(*Aggregator).Add
         0     0% 98.37% 147612.88kB  0.57%  main.(*Aggregator).flush
140691.44kB  0.54% 98.91% 140691.53kB  0.54%  github.com/dgryski/go-tsz.New
(pprof) list main.fix
Total: 24.83GB
ROUTINE ======================== main.fix in /home/dieter/go/src/github.com/raintank/raintank-metric/metric_tank/dataprocessor.go
   19.20GB    19.20GB (flat, cum) 77.33% of Total
         .          .     51:		start = from + interval - remain
         .          .     52:	}
         .          .     53:
         .          .     54:	// last point should be the last value that divides by interval lower than to (because to is always exclusive)
         .          .     55:	lastPoint := (to - 1) - ((to - 1) % interval)
   19.20GB    19.20GB     56:	out := make([]schema.Point, (lastPoint-start)/interval+1)
         .          .     57:
         .          .     58:	// t is the ts we're looking to fill.
         .          .     59:	// i iterates in
         .          .     60:	// o iterates out
         .          .     61:	for t, i, o := start, 0, -1; t <= lastPoint; t += interval {
(pprof)

really weird that that line is the culprit since it's very similar to the original line.
i see two possibilities:

stack escape analysis treats this slice allocation different as before

somewhere further down the read path the slice leaks and is not reclaimed. but the leak would have to be caused somehow by the perf improvement.. which seems a bit unlikely. also i don't see where it could leak. divide() drops references to it. consolidate() passes it on, and ultimately after graphiteJSON/graphiteRaintankJSON we should have no more references to this slice.

$ b -gcflags='-m' 2>&1 | grep dataprocessor.go:56
./dataprocessor.go:56: make([]schema.Point, (lastPoint - start) / interval + 1) escapes to heap
./dataprocessor.go:56: make([]schema.Point, (lastPoint - start) / interval + 1) escapes to heap

with patch reverted:
$ b -gcflags='-m' 2>&1 | grep dataprocessor.go:39
./dataprocessor.go:39: make([]schema.Point, 0, len(in)) escapes to heap
./dataprocessor.go:39: make([]schema.Point, 0, len(in)) escapes to heap

aha! I think i found the bug.
fix() is getting incoming requests such as from<PHONE_NUMBER> to<PHONE_NUMBER> (e.g. a 30s span) but interval is 60s and len becomes 71582788

the input slices seem to be empty in these cases btw:
+       fmt.Println(">fix", "f", from, "t", to, "int", interval, " len", (lastPoint-start)/interval+1)

>fix [{0<PHONE_NUMBER>} {0<PHONE_NUMBER>} {0<PHONE_NUMBER>}] f<PHONE_NUMBER> t<PHONE_NUMBER> int 10  len 3
>fix [] f<PHONE_NUMBER> t<PHONE_NUMBER> int 10  len 3
>fix [] f<PHONE_NUMBER> t<PHONE_NUMBER> int 60  len 71582788
>fix [{0<PHONE_NUMBER>} {0<PHONE_NUMBER>} {0<PHONE_NUMBER>}] f<PHONE_NUMBER> t<PHONE_NUMBER> int 10  len 3

similar issue was #164


GUACAMOLE-343: Add client-side fields for disabling recording.

Matching client-side changes to apache/guacamole-server#277.

Closing for now - see conversation on JIRA: https://issues.apache.org/jira/browse/GUACAMOLE-343


Support for tedious (MS-SQL) and Pino?

Thanks for all your work on the new version. I see the following list designated for bundled support in the preview / beta 👍

Distributed Tracing
HTTP/HTTPS
MongoDB
MySQL
Postgres
Redis
Redis-4
Azure SDK

I'm a little hazy on what is necessary to support MS-SQL (tedious) and Pino, which look to be available in open telemetry. Will it be enough to add a TraceHandler in ApplicationInsightsClient for @opentelemetry/instrumentation-pino and @opentelemetry/instrumentation-tedious per the new readme or does this come with caveats?

@DevRCRun you can take a look at the sample code we have to add ExpressInstrumentation here, you can add any other OpenTelemetry Instrumentation the same way

Be aware though that  @opentelemetry/instrumentation-pino only adds a few tracing specific records to the pino record - it does not help you in sending logs created through the pino logging interface to application insights, like the built-in log instrumentations for console, winston and bunyan would do.
See also https://github.com/microsoft/node-diagnostic-channel/issues/118#issuecomment-1600730013


Suggestion: Add Socials

It would be really useful to see if the name is taken across popular social media profiles

Thanks for the suggestion Jonny! I've thought about this and settled on namechecker being mostly for project names in software. There is a similar tool, https://namae.dev/s/Netflix, which does check social media.


Points Kubeflow's check_status value to kubeflow.enabled lock file

Creates lock file after all actions in enable.kubeflow.sh
and points check_status in addon-lists.yaml to that file.
This ensures Kubeflow addon is listed as enabled when
running microk8s status
Fixes #2695

We may want to backport this PR to the branches where the kubeflow addon is available (1.21, 1.20,....)

Hi @ktsakalozos I've rebased my dev branch and also changed the target branch to 1.21, which is the last supported version for Kubeflow. Note that I went with the approach of creating a lock file instead of just checking for a resource.

@DnPlas I think we also need to remove the lock file when we disable the add on in https://github.com/ubuntu/microk8s/blob/1.21/microk8s-resources/actions/disable.kubeflow.sh

@DnPlas I think we also need to remove the lock file when we disable the add on in https://github.com/ubuntu/microk8s/blob/1.21/microk8s-resources/actions/disable.kubeflow.sh

Ah you are absolutely right. Let me add that.


Module 1.1 Assignment

Given what you have learned about Git, why would you want to use Git in your classroom?
I am teaching a course on Algorithmics. I am currently using Git/Github since each of the students have created a repository and they are using it to upload/commit/push the assignments.

👋 Hi @vicegd  you are missing your answer for the question above. Please post it here in this thread.

I am teaching a course on Algorithmics. I am currently using Git/Github since each of the students have created a repository and they are using it to upload/commit/push the assignments.


torch.onnx

I want to convert PTH to onnx, what should I do.torch.onnx need to import the network model and weights.But I don't know what a network model it is

I have the same issue

But I don't know what a network model it is

Try to look in this tutorial.
The model is the complex of nn.Module layers. Weights usually save in state_dict() collection, so you need to create/load model architecture and load its state_dict with weights. After that, export to ONNX.

could you please share the code for converting it to onnx format?


Use simulator and PythonAPI with different versions, Segmentation fault occurs

          In https://github.com/opendilab/LMDrive/issues/14#issuecomment-1898154122, the author change the PythonAPI version into 0.9.12 and it works fine.

However, when I use simulator and PythonAPI with different versions, Segmentation fault occurs.
Does anyone face the same situation?
The port is openning for sure.

Python 3.8.18 | packaged by conda-forge | (default, Dec 23 2023, 17:21:28)
Type 'copyright', 'credits' or 'license' for more information
IPython 8.12.3 -- An enhanced Interactive Python. Type '?' for help.
In [1]: import carla
In [2]: client = carla.Client('localhost', 6008)
In [3]: traffic_manager = client.get_trafficmanager(6009)
WARNING: Version mismatch detected: You are trying to connect to a simulator that might be incompatible with this API
WARNING: Client API version     = 0.9.12
WARNING: Simulator API version  = 784d9b9f
Segmentation fault

Originally posted by @dingli-dean in https://github.com/opendilab/LMDrive/issues/14#issuecomment-2012423471

Hi!
What is the version of your Carla simulator and Python API? Can you try to use another traffic manager port, like 6558. 6008+1 is a default streaming port for Carla (https://carla.readthedocs.io/en/latest/start_quickstart/).

Hi @dingli-dean, I had a similar problem when running CARLA. Would you like to provide the compiled CARLA egg for Python 3.8. I appreciate your help!

Hi @dingli-dean, I had a similar problem when running CARLA. Would you like to provide the compiled CARLA egg for Python 3.8. I appreciate your help!

Do you solve the problem? I have the same problem.


Add support for applications listening on Pod IP

Copy of https://github.com/istio/api/pull/1314 and https://github.com/istio/istio/pull/22117 but with a different implementation
This allows defining a Sidecar like
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: echo
spec:
  workloadSelector:
    labels:
      app: echo
  ingress:
  - port:
      number: 8080
      protocol: HTTP
      name: http
    defaultEndpoint: pod:8080
  egress:
  - hosts:
    - "*/*"

and instead of <IP_ADDRESS> we send to <POD_IP>
pod is probably the wrong name here since it applies to VMs, etc.

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

/test all

@howardjohn: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test release-notes_istio

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

@ramaraochavali @lambdai @hzxuzhonghu let me know what you think. Just an early prototype

@howardjohn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test release-notes_istio

lint_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test lint_istio

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

@howardjohn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test release-notes_istio

lint_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test lint_istio

gencheck_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test gencheck_istio

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

@howardjohn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test release-notes_istio

lint_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test lint_istio

gencheck_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test gencheck_istio

integ-pilot-k8s-tests_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test integ-pilot-k8s-tests_istio

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

@howardjohn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test release-notes_istio

lint_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test lint_istio

gencheck_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test gencheck_istio

integ-pilot-k8s-tests_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test integ-pilot-k8s-tests_istio

integ-helm-tests_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test integ-helm-tests_istio

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

@howardjohn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test lint_istio

gencheck_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test gencheck_istio

integ-pilot-k8s-tests_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test integ-pilot-k8s-tests_istio

integ-helm-tests_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test integ-helm-tests_istio

release-notes_istio
88aad792fec68fb44b39d9108823b56d3484bc75
link
/test release-notes_istio

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

@howardjohn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-pilot-k8s-tests_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test integ-pilot-k8s-tests_istio

integ-helm-tests_istio
e7adf4df85a8b54b2590e7b2464183374e546bbe
link
/test integ-helm-tests_istio

release-notes_istio
88aad792fec68fb44b39d9108823b56d3484bc75
link
/test release-notes_istio

lint_istio
88aad792fec68fb44b39d9108823b56d3484bc75
link
/test lint_istio

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

@howardjohn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
88aad792fec68fb44b39d9108823b56d3484bc75
link
/test release-notes_istio

lint_istio
88aad792fec68fb44b39d9108823b56d3484bc75
link
/test lint_istio

integ-pilot-k8s-tests_istio
88aad792fec68fb44b39d9108823b56d3484bc75
link
/test integ-pilot-k8s-tests_istio

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

@howardjohn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
88aad792fec68fb44b39d9108823b56d3484bc75
link
/test release-notes_istio

lint_istio
88aad792fec68fb44b39d9108823b56d3484bc75
link
/test lint_istio

integ-pilot-k8s-tests_istio
88aad792fec68fb44b39d9108823b56d3484bc75
link
/test integ-pilot-k8s-tests_istio

integ-security-k8s-tests_istio
88aad792fec68fb44b39d9108823b56d3484bc75
link
/test integ-security-k8s-tests_istio

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


Inconsistent case in Yes/No (yes/no) type of options in bootstrap command prompts

Describe the bug
Some bool type flags prompt the user with Yes or No while others use yes or no
To Reproduce
In ui.go
func UseKeyringRingSvc() bool {
var optionImageRegistry string
prompt := &survey.Select{
Message: "Do you wish to securely store the git-host-access-token in the keyring on your local machine?",
Help:    "The token will be stored securely in the keyring of your local mahine. It will be reused by kam commands(bootstrap/webhoook), further iteration of these commands will not prompt for the access-token",
Options: []string{"Yes", "No"},
func SetupCommitStatusTracker() bool {
var optionCommitStatusTracker string
prompt := &survey.Select{
Message: "Do you want to enable commit-status-tracker?",
Help:    "commit-status-tracker reports the completion status of OpenShift pipeline runs to your git host on success or failure",
Options: []string{"yes", "no"},

/kind bug

/kind bug


No hab pressure for the mk1-3 and apollo cm

Hi! Playing under RP-1 in 1.8, I can't find any way to activate N2 or O2 pressure control system on those command modules. I believe it is expected that we use the ROcapsule apollo service module as the life support system, which I don't like as I want to stay stock-ish without "UNITED STATES" written on my vessel. I'm not really familiar with editing config parts, so I'm asking please how can I add the N2 pressure module to the mk1-2 command pod? Thank you in advance!

You're correct, you're supposed to use the service module; but if you want to build one yourself, you shouldn't need to edit any config. The external life support module part should give you the option to add any pressure controller you like. Just be sure to download the master branch and use that since I noticed some tech unlocks were wrong, and that you'd get the controllers much later than you should've.


Token Request Error in Safari

Issue and Steps to Reproduce
Random error when using Safari browser to try the https://black-rock-0dc6b0d03.1.azurestaticapps.net/profile-secure-component
Step to produce

Go to https://black-rock-0dc6b0d03.1.azurestaticapps.net/profile-secure-component
Enter login info
If login is successful, logout again and repeat steps 1 and 2.

Versions
7.22.32
Screenshots

Expected
No authentication error
Actual
Authentication error in service worker mode.
Additional Details

code_verifier is not replaced by the Service worker.

@synapxe-siang13 did you manage to solve this issue?
I am having the exact same problem. The Error randomly occurs in Safari.
response from token route is {     “error”: “invalid_grant”,     “error_description”: “grant request is invalid” }
the server is logging PKCE verification failed.
We noticed an extra _default attached to the code verifier param which seems also been attached in @synapxe-siang13 request
code_verifier=CODE_VERIFIER_SECURED_BY_OIDC_SERVICE_WORKER_default_default

@baesslerpa not able to resolve.
@guillaume-chervet Can help to verify this issue?

Hi @synapxe-siang13 , do you have more details about your issue. For example your configuration and service worker configuration and some code?
Does it happen sometime or everytime?

@guillaume-chervet Hi, the issue happened randomly in Safari. From what I have observed, this issue does not occur in Chrome. You may verify this issue with https://black-rock-0dc6b0d03.1.azurestaticapps.net/profile-secure-component, I tested with the above demo URL, this issue happened as well. But I am not sure the configuration with your demo URL.

function App() {
  const config: OidcConfiguration = {
    client_id: import.meta.env.VITE_CLIENT_ID,
    redirect_uri: import.meta.env.VITE_REDIRECT_URI,
    silent_redirect_uri: import.meta.env.VITE_SILENT_REDIRECT_URI,
    scope: "openid profile email ecapi offline_access",
    authority: import.meta.env.VITE_AUTHORITY,
    demonstrating_proof_of_possession: false,
    service_worker_relative_url: `/OidcServiceWorker.js?v=${axaPackage.version}`,
    service_worker_only: false,
  };
  return (
    <>
      <HelmetProvider>
        <OidcProvider
          configuration={config}>
          <RouterProvider router={router} />
        </OidcProvider>
      </HelmetProvider>
    </>
  );
}

this is the configuration we are running.
as @synapxe-siang13 mentioned the error appears randomly in Safari (Mac and IOS) but appears like every second or third try.

function PageError() {
  // show loader while ios bug is not fixed
  useEffect(() => {
    setTimeout(() => {
      console.log("navigating to root");
      window.location.href = "/";
    }, 1000);
  }, []);

  return (
    <div className="w-screen h-screen flex items-center justify-center flex-col">
      <Spinner />
    </div>
  );
}

this works as a temporary fix

I have missed the message with the extra default @baesslerpa @synapxe-siang13 , i have may be an idea . I will take a look next week.
Your safari is on mobile or desktop ?

@guillaume-chervet happens on both platforms, I even had this bug once on chromium based browser (Arc)

@guillaume-chervet Hi, are you checking on this issue?

Hi @synapxe-siang13 what is your oidc trusted domains configuration ? I do not have any problem with safari in production on my side.

@guillaume-chervet I tested with your demo https://black-rock-0dc6b0d03.1.azurestaticapps.net/profile-secure-component with Safari, the issue came out randomly actually. I think it may not related to Oidc trusted domains configuration.

@guillaume-chervet Using latest version of library will have the same issue as well

Hi @synapxe-siang13 do you have a way to debug or give me again more information ?  Whithout any mac I cannot debug or test with it.

@guillaume-chervet Hi,  the issue we tested seems to be happening in the Mac Safari browser or IOS Safari browser. You may replicate by browsing to this link https://black-rock-0dc6b0d03.1.azurestaticapps.net/profile-secure-component and login. If you not manage to see any error after login, you will need to logout again. After that you need to browse to this link https://black-rock-0dc6b0d03.1.azurestaticapps.net/profile-secure-component and login again. Repeat the above process, the error authentication will come out randomly.

A collègue can reproduce it. I have to find a device to test it and debug it.

@guillaume-chervet where you able to debug the issue?


Issue with the MCX gate using WCFLOBDD backend

Hi,
there seems to be some issue with using the MCX gate with the WCFLOBDD backend.
For example, when I run
#include <unordered_map>
#include <string>
#include "quantum_circuit.h"

#define N_SHOTS 1024

int main()
{
    WeightedCFLOBDDQuantumCircuit qc;

    qc.setNumQubits(3);

    qc.ApplyNOTGate(0);
    qc.ApplyNOTGate(1);
    std::vector<long int> controllers = {0, 1};
    qc.ApplyMCXGate(controllers, 2);

    std::unordered_map<std::string, int> measureResults;
    for(int i = 0; i < N_SHOTS; i++) {
        measureResults[qc.Measure()]++;
    }
    for(const auto& pair : measureResults) {
        std::cout << " '" << pair.first << "' : " << pair.second << std::endl;
    }
}

it produces
 '110' : 1024`

when the expected result is '111'. I'm assuming this is because the method WeightedCFLOBDDQuantumCircuit::ApplyMCXGate is defined, however the body of this method is empty.

Hi,
Yes. Some gates have not been implemented yet for the WCFLOBDD backend. I plan to do them in the next few weeks. I will at least add "NotImplementedException" so this output doesn't happen.
Please feel free to do it if you want to take a stab at it. However, it might take a few days atleast for me to get to this.

Sure, and thanks! I'll see if I can get to it. I just wanted to let you know because I wasn't sure whether it is intentional or not.


NUT-06: Deprecate amount in POST /split

The amount field in POST /split was an unnecessary contraint on the split operation. Now, wallets can choose the amount distribitions of the inputs (proofs) and outputs (and thus returned promises) as they wish, as long as they sum up to the same value.
Closes #32
Changes:
Wallets:
Wallets simply don't send the amount field with the POST /split request anymore. They receive a new object with the field promises from which they then need to separate the promises to keep (first elements) and send (last elements).
Previously, they took these two sets of elements from the fields fst and snd from the response. This is no longer the case! Note that wallets already should know how many elements of the promises response they need to slice to get the same as the fst and snd responses because they have previously generated an array of outputs that has the same distribution.
Mints:
Mints now do no receive an amount field anymore. They can simply proceed as usual but remove any security checks that might have previously asserted that the distribution of amounts of outputs must adhere to a certain pattern (for example perfectly decompose in powers of two). This is not necessary anymore. They MUST still check whether the sum of proofs is equal to the sum of outputs and they SHOULD also check whether it equals the sum of generated promises (as a sanity check).
PostSplitRequest
Before:
{
  "proofs": Proofs,
  "outputs": BlindedMessages,
  "amount": int //deprecate
}

Now:
{
  "proofs": Proofs,
  "outputs": BlindedMessages,
}

PostSplitResponse
Before:
{
  "fst": BlindSignatures,
  "snd": BlindSignatures
}

Now:
{
  "promises": BlindSignatures
}

Testing:
For wallet development, use this Nutshell testnut mint that runs on the branch nut06/no_amount_in_split
https://nut06.testnut.cashu.space
Tracking progress of NUT-06 update (please report):

[x] Nutshell (Status: 🛠 PR)
[ ] LNbits
[ ] Feni (Status: WIP)
[ ] Cashu.me
[ ] Nutstash
[ ] eNuts
[ ] cashu-ts
[ ] ngutech21/moksha (Status: Issue)
[ ] clarkmoody/cashu-rs
[x] cashu-crab (Status: ✅ commit)
[x] [cashu-kotlin](Status: 🛠 repo)

Ping: @BilligsterUser @gandlafbtc @clarkmoody @ngutech21 @gohumble @thesimplekid @KKA11010 @thunderbiscuit

Cashu-crab updated in https://github.com/thesimplekid/cashu-crab/commit/e8303fcc8c545111ddfbeb72739d5bd757123157, mint handles both with and without amount and responds accordingly, wallet chooses which to follow. Will deprecate amount fully after transition.

If the amount is not sent anymore, mints that haven't upgraded yet will error. Shouldn't we keep the amount in the request, at least till most mints have upgraded?

If the amount is not sent anymore, mints that haven't upgraded yet will error, right? Shouldn't we keep the amount in the request, at least till most mints have upgraded?

Same as @thesimplekid, I've upgraded Nutshell to be backwards compatible (has two different responses depending on whether amount is sent or not). I will add the same to LNbits and we should be relatively good. Only issue will be clients that have upgraded but want to talk to old mints but there will always be pain!

Moksha mint and wallet upgraded https://github.com/ngutech21/moksha/commit/d0d39f5ffc4379ad7f1e2d49f570216cb5d48301
All changes are backwards compatible. I will remove the deprecated code, after all the other implementations have upgraded as well.


Random bytes as MultisigRune signatories

May want to consider narrowing the signatories type here

Can you please be more specific about the desired narrowing? Do you mean a narrower type for signatories or narrowing the resulting MultisigRune to represent the supplied signatories?
In the former case, it's a bit tricky bc the Uint8Array type doesn't carry length information as do tuples. I suppose you could intersect Uint8Array with { length: 32 }... but this would hinder productivity in cases where signatories are retrieved dynamically. The length would effectively serve as a brand, and users would need to create helpers to apply the brand.

Ideally the MultisigRune would take an array of strings representing member addresses, decode them automatically and make sure they're valid.
Although string[] is not that narrow, if's a bit more safe than Uint8Array[] for UI use cases.
Apart from this, it would remove a manual step in the rune creation.
Instead of this
  const addresses = [
    "5CfJAuXp1SgJ5Fb1AhSzQk61nFXtvzs4GRuQpouBURaP3zXk",
    "5CAmWhTjv6c6ab2uJHazXBiRMSeHy8XHkQMRXLdEeeMTEfw7",
    "5HpR2ELVTHADFAfXxZY8jJjZQMDhjJwMB6ZcHCHJm2yk6C1G",
    "5EAYdWBh4SAontqNxPkgwegFNHKQnC8TsqJ1ZXJ4Ku58aBCe",
  ]
  // signatories is Uint8Array[]
  const signatories = addresses.map((address) => {
    const [_, addressBytes] = ss58.decode(address)
    return addressBytes
  })

  const multisig = MultisigRune.from(westend, { signatories, threshold: 2 })

we could do this
 const signatories = [
   "5CfJAuXp1SgJ5Fb1AhSzQk61nFXtvzs4GRuQpouBURaP3zXk",
   "5CAmWhTjv6c6ab2uJHazXBiRMSeHy8XHkQMRXLdEeeMTEfw7",
   "5HpR2ELVTHADFAfXxZY8jJjZQMDhjJwMB6ZcHCHJm2yk6C1G",
   "5EAYdWBh4SAontqNxPkgwegFNHKQnC8TsqJ1ZXJ4Ku58aBCe",
 ]

 const multisig = MultisigRune.from(westend, { signatories, threshold: 2 })

Ideally the MultisigRune would take an array of strings representing member addresses, decode them automatically and make sure they're valid. Although string[] is not that narrow, if's a bit more safe than Uint8Array[] for UI use cases.
Apart from this, it would remove a manual step in the rune creation.
Instead of this
  const addresses = [
    "5CfJAuXp1SgJ5Fb1AhSzQk61nFXtvzs4GRuQpouBURaP3zXk",
    "5CAmWhTjv6c6ab2uJHazXBiRMSeHy8XHkQMRXLdEeeMTEfw7",
    "5HpR2ELVTHADFAfXxZY8jJjZQMDhjJwMB6ZcHCHJm2yk6C1G",
    "5EAYdWBh4SAontqNxPkgwegFNHKQnC8TsqJ1ZXJ4Ku58aBCe",
  ]
  // signatories is Uint8Array[]
  const signatories = addresses.map((address) => {
    const [_, addressBytes] = ss58.decode(address)
    return addressBytes
  })

  const multisig = MultisigRune.from(westend, { signatories, threshold: 2 })

we could do this
 const signatories = [
   "5CfJAuXp1SgJ5Fb1AhSzQk61nFXtvzs4GRuQpouBURaP3zXk",
   "5CAmWhTjv6c6ab2uJHazXBiRMSeHy8XHkQMRXLdEeeMTEfw7",
   "5HpR2ELVTHADFAfXxZY8jJjZQMDhjJwMB6ZcHCHJm2yk6C1G",
   "5EAYdWBh4SAontqNxPkgwegFNHKQnC8TsqJ1ZXJ4Ku58aBCe",
 ]

 const multisig = MultisigRune.from(westend, { signatories, threshold: 2 })

The same argument could be made if you had a list of multiaddress signatories and would now need to convert them into string. I think we can support both input types but it would require a discriminator as I don't think there is a reasonable way to determine if an array is string[] or Uint8Array[] at runtime.
const signatories = {
  type: "ss58Encoded",
  members: [
    "5CfJAuXp1SgJ5Fb1AhSzQk61nFXtvzs4GRuQpouBURaP3zXk",
    "5CAmWhTjv6c6ab2uJHazXBiRMSeHy8XHkQMRXLdEeeMTEfw7",
    "5HpR2ELVTHADFAfXxZY8jJjZQMDhjJwMB6ZcHCHJm2yk6C1G",
    "5EAYdWBh4SAontqNxPkgwegFNHKQnC8TsqJ1ZXJ4Ku58aBCe",
  ]
 }

MultisigRune.from(westend, { signatories, threshold: 2 })

...

const signatories = {
  type: "ss58Decoded",
  members: [
    new Uint8Array(),
    new Uint8Array(),
    new Uint8Array(),
    new Uint8Array()
  ]
}

MultisigRune.from(westend, { signatories, threshold: 2 })

I don't think we should get in the habit of overloading rune factories. Account IDs are more commonly used on chain for things such as keying into user-specific map entries / specifying users in call data. Account IDs are a lower-level representation than SS58. I understand that account IDs / Uint8Arrays aren't as easy to render in a UI / input in a text field, but I don't think that merits moving further from the FRAME-metadata-based translations.
That being said, I think you can smooth this out with a reusable helper.
ss58_util.ts
import { ss58 } from "capi"

export function publicKeys(addrs: string[]) {
  return addrs.map((a) => ss58.decode(a)[1])
}

Which you could use as follows.
import { publicKeys } from "./ss58_util.ts"

const signatories = [
 "5CfJAuXp1SgJ5Fb1AhSzQk61nFXtvzs4GRuQpouBURaP3zXk",
 "5CAmWhTjv6c6ab2uJHazXBiRMSeHy8XHkQMRXLdEeeMTEfw7",
 "5HpR2ELVTHADFAfXxZY8jJjZQMDhjJwMB6ZcHCHJm2yk6C1G",
 "5EAYdWBh4SAontqNxPkgwegFNHKQnC8TsqJ1ZXJ4Ku58aBCe",
]

const multisig = MultisigRune.from(westend, {
  signatories: publicKeys(signatories),
  threshold: 2,
})

In the case that signatories is a rune of string, you could do the following.
import { ss58, RunicArgs } from "capi"

export function publicKeys<X>(...[addrs]: RunicArgs<X, [string[]]>) {
  return Rune
    .resolve(addrs)
    .map((addrs) => addrs.map((addr) => ss58.decode(addr)[1]))
}

This approach allows you to use the publicKeys util with either a list of addresses or a rune of a list of addresses.

I guess i'm trying to make 2 arguments, one that string[] is more descriptive and readable if not safer.
Second argument  is more about development experience.
During app development we can get these addresses from different places like a form or a wallet, but we usually if not always work with SS58 encoded strings.
A nice development experience would be to have the Capi handle the decoding, at least at the pattern level.
We have created helpers around this of course, but just having to call them each time we need something from Capi signals that it would be perhaps better if Capi could accept string addresses.

I could see a world in which we have another static method / factory of MultisigRune that accepts the addresses for signatories.
- const multisig = MultisigRune.from(westend, { signatories: publicKeys, threshold: 2 })
+ const multisig = MultisigRune.fromSs58(westend, { signatories: ss58Addresses, threshold: 2 })

I just wonder where we'll draw the line? Having many factories, each with subtly-different props, is a slippery slope. The from methods should really just accept the T, that is the data on which the pattern code operates; the raw calls and storage reads operate with account IDs, not ss58s.
If you feel very strongly about this, I'll go ahead and add the fromSs58 factory.

The from methods should really just accept the T, that is the data on which the pattern code operates; the raw calls and storage reads operate with account IDs, not ss58s.

Indeed, the raw calls operate with binary data. However, the whole beauty of a user-friendly API is to simplify the developer's interaction with it.
In my opinion, we shouldn't need to worry about the kind of data these raw calls are working with - that's the whole point of having a user-friendly API in the first place! A robust API should effectively abstract these complexities.

I think this discussion has drifted from the central issue, so I'm posting to restart the discussion.
I think this issue is part of a broader question of address types in our API. @statictype I know I discussed this some with you at Decoded, but I think the conversation got disrupted by everything else going on, so I'd like to start from scratch.

I see there being three main address types under discussion:

Ss58
MultiAddress
AccountId (aka a public key)

Ideally, these would all be interchangeable. Unfortunately, there are many directions we can't convert.
Here's a diagram of how we can convert these address types:
          Ss58
         /    \
        v      v
AccountId ---> MultiAddress

(we can't convert AccountId to Ss58 without the chain prefix, and though we can convert a MultiAddress.Id to an AccountId, we can't convert the other types of MultiAddress)
Which type(s) do we accept in our API?
There are parts of Capi's API that we don't directly control – those generated from the chain metadata. Take, for example, Balances.transfer. In the metadata, dest is typed as MultiAddress, and we can't change that[^1].
[^1]: Though we do change the shape of some codecs from the metadata, we can only do this when there is a bidirectional conversion between the two types. For example, we can change Codec<{ foo_bar: Baz }> to Codec<{ fooBar: Baz }> because the conversion between those types can go both ways. Unfortunately, since we can't convert a MultiAddress to an Ss58, we can't change Codec<MultiAddress> to Codec<Ss58>.
Thus, some of Capi's API must accept MultiAddress.
However, as @statictype points out, when we develop patterns, we do have the ability to make a more user-friendly API.
Here are a few different options in two different cases:
Case 1: The chain wants a MultiAddress
Option 1a: Our API wants a MultiAddress, too
This is, of course, the easiest option, but that shouldn't be a factor – what matters is the end user experience.
This does have the advantage that it's consistent with Capi's generated APIs.
However, as @statictype has pointed out, one drawback of this approach is that frontends usually deal with Ss58s, so app devs would have to manually convert.
Option 1b: Our API wants an Ss58 instead
This resolves the issue of having to manually convert an Ss58 to a MultiAddress.
However, if the user already has a MultiAddress, they can't use this API, as a MultiAddress can't always be converted to an Ss58.
Option 1c: Our API wants a MultiAddress | Ss58
In one sense, this does simplify the end user experience.
However, we (the Capi team) have found in general that APIs with many different overloaded input types with automatic conversion are harder to use overall, as they obscure the real logic and overwhelm the consumer with many (often irrelevant) options.
Thus, the Capi team has adopted a policy: the Capi API won't use union types with automatic conversion.
Option 1d: We have two methods, one which takes MultiAddress, and one which takes Ss58
I think this is a reasonable middle ground. It doesn't prevent the use of MultiAddress, it makes the experience better when one has an Ss58, and it doesn't introduce a auto-converted union type.
However, as @harrysolovay pointed out, this kind of approach can start to snowball, so we need to consider it carefully.
Case 2: The chain wants an AccountId
The four options in Case 1 have analogues here:

Option 2a: Our API wants an AccountId as well
Option 2b: Our API wants an Ss58 instead
Option 2c: Our API wants an AccountId | Ss58
Option 2d: We have two methods, one which takes AccountId, and one which takes Ss58

But I also can think of two other notable options:
Option 2e: Our API wants a MultiAddress.Id
I think this is an interesting variant.

If you have an AccountId, you can quickly convert it into a MultiAddress.Id with a single call
If you have a MultiAddress, you can either:

Do an explicit check to see if it's an Id, and if so pass it through
If you know it must be an Id, use as MultiAddress.Id and pass it through

On the implementation side, we would have a sanity check that ensures it's an Id, to make this option safer.

If you have an Ss58, this is pretty similar to Option 2a (namely, less ergonomic).
Option 2f: We have two methods, one which takes MultiAddress.Id, and one which takes Ss58
This is a combination of 2d and 2e.
So, what options do we choose?
My current thoughts are:

For MultisigRune, go with 2f – namely, have MultisigRune.from and MultisigRune.fromSs58 factories. Seeing as this is a rare case of an array of addresses, converting isn't a single function call – you have to map over the array, which is more verbose and error-prone, so providing an option to skip this explicit step seems worthwhile.

In other parts of the API, go with 1a or 2e (as appropriate). Though I see the appeal of 1d and 2d/2f, I think these alternate versions could get out of hand and ultimately make the API harder to use. I think we should instead ease the pain of converting these addresses in a more general way. So:

How can Capi resolve these pain points more generally?
ss58.toAccountId
I think one easy & high-value option with general utility would be for Capi to add an ss58.toAccountId function.  Since in many cases, you don't care about the chain prefix, you shouldn't have to explicitly discard it.
Other options
Disclaimer: I'm not working on an app using Capi, so my perspective on the app dev experience is incomplete. However, I think this proposal may reduce some pain points:
Use MultiAddress.Ids as the main form of addresses in apps
When developing Capi-based apps, use MultiAddress.Ids as the main form of address in the logic layer, and render/input Ss58s in the presentation layer.
This means:

any raw chain APIs that accept a MultiAddress can be used directly
any raw chain APIs that accept an AccountId can be used with a simple property access (.value)
Capi patterns can take MultiAddress.Id/MultiAddress as appropriate, and both can be used directly

This allows Capi patterns to be used like the raw chain APIs

@statictype Thoughts?

Thank you for the detailed explanation but I still feel this is not a user concern. Please refer to the way this is handled in "competing" libraries (pjs, ethers.js, web3.js) who seem to allow string params throughout their API.
The assumption that the types of the parameters these Runes accept need to comply with the underlying logic layer is creating unnecessary friction for the end user.

Here is a simple illustration:
capi
local.Nfts.create({
    config: collectionConfig,
    admin: MultiAddress.Id(ss58.decode(activeAccount.address)[1]),
})

pjs
api.tx.nfts.create(activeAccount.address, collectionConfig)
Here is a quote from docs:

It consists of a development server and fluent API, which facilitates multichain interactions without compromising either performance or ease of use.

From a dev perspective capi does seem to compromise the ease of use.
Ideally I shouldn't care what happens inside of the API and let the API devs decide on how to make my experience as frictionless as possible.
If it's actually very problematic or in some cases impossible to do conversions on the fly inside of capi and I need to do this myself, then a solution to this would be comprehensive documentation with examples on what exactly capi wants from me and how can I provide that.


Docs：add Chinese and English documentation on how to join the fury community.

Docs：add Chinese and English documentation on how to join the fury community.

Could we don't copy all english documents? We could add tem when build websites, or forward to  english pages when chinese pages don't exist

Could we don't copy all english documents? We could add tem when build websites, or forward to english pages when chinese pages don't exist

I ’m not sure what you're talking about.Do you mean no English documents?

Could we don't copy all english documents? We could add tem when build websites, or forward to english pages when chinese pages don't exist

I ’m not sure what you're talking about.Do you mean no English documents?

Why we need to commit same file content duplicately to repo? We should avoid such things

Could we don't copy all english documents? We could add tem when build websites, or forward to english pages when chinese pages don't exist

I ’m not sure what you're talking about.Do you mean no English documents?

Why we need to commit same file content duplicately to repo? We should avoid such things

One is the English configuration and the other is the Chinese configuration, and the Chinese configuration has not been translated yet. I see that some of the other projects have default English, but there are also duplicate configurations in the en folder, but I think it can be deleted without much impact.

Could we don't copy all english documents? We could add tem when build websites, or forward to english pages when chinese pages don't exist

I ’m not sure what you're talking about.Do you mean no English documents?

Why we need to commit same file content duplicately to repo? We should avoid such things

The reason I copied and pasted the file here is that the Chinese translation can be translated directly on it in the future without creating a new file, and when converting to Chinese mode, no translated articles can be displayed in English.

I don't think so. We will update English document frequently. It's very easy to introduce inconsistency. We should redirect to English document if document for other language doesn't exist

I don't think so. We will update English document frequently. It's very easy to introduce inconsistency. We should redirect to English document if document for other language doesn't exist

ok I just delete them.

I noticed that fury's i18n documentation is very lacking. Maybe we should consider introducing LLM to translate related documents automatically.

I noticed that fury's i18n documentation is very lacking. Maybe we should consider introducing LLM to translate related documents automatically.

You mean deploy a llm in fury website? This needs gpu and is not affordable.
If the developers use llm to translate the doc, It don't involve changes in fury setup

I noticed that fury's i18n documentation is very lacking. Maybe we should consider introducing LLM to translate related documents automatically.

You mean deploy a llm in fury website? This needs gpu and is not affordable. If the developers use llm to translate the doc, It don't involve changes in fury setup

So we can only translate it by hand, and fortunately there are not many documents now. : )


Fixes #2618 - Consolidate statusUpdate logic in TaskTracker life cycle methods

Added some documentation and logging.
Move lifecycle hooks next to each other
Assert that task that is passed to TaskTracker.created does not exist yet.
Separate processUpdate method from statusUpdate to make scalastyle happy.
Make methods only used by processUpdate method private.

@meichstedt and me worked on this BTW.
I think, I addressed your comments by comments (which is only fair ;) ).

TaskTracker becomes more focused with this PR.
See my comments.
Additional things that come to my mind reviewing the code:

there are still a lot of Awaits in the code
didn't we agree to remove expungeOrphanedTasks?
TaskTracker.get should be removed
TaskTracker.fetchTask should be removed
TaskTracker.list returns a Map
TaskTracker.shutdown should be renamed (sounds like system shutdown)
why do we have App and InternalApp?

@aquamatthias: I wish to keep this pull request focussed and not overload it with a complete refactoring of the TaskTracker. I think that we benefit from small incremental steps.
Furthermore, I did not make the design choices that went to the original creation of the TaskTracker. So please ask the original authors.
This is not the pull request to make the TaskTracker perfect.

If have updated the PR.

Thanks for pointing out some crucial points! I didn't understand them at once -- therefore the long-winded discussions...

@kolloch I know this is pretty awful code here - I think FixMe's are a first good step, because they make you think. We need to get rid of those urgently...

But for this PR - thanks!


CameraTest flaky tests on apt CI

See for example https://github.com/robotology/gz-sim-yarp-plugins/actions/runs/7698197313/job/20976938788 .

Closed in #76

Actually I wanted to have an issue to track the underling issue of the CameraTest segfault in a non-deterministic way, but indeed probably an issue with a more appropriate name may be more indicated.

Thanks, I clarified the test.