Add better error messages to jpype.imports

This has burned me for the last time.  Die! Die! Die!
This pull request improves the error reporting for jpype.imports to try to report wrong version and missing dependencies.   The JClass method we were using gave back the same exception every time thus making it hard to distinguish the source of the problem.  To debug this, the user would then need to call forName to find the actual source of the problem.  This pull request cuts out the middle man and just directly calls forName to get class in the first place.  The performance is slightly worse, but this is a very low frequency operation.

Bonus.  Wildcards are acceptable at the command line for Java but not recognized by the jvm library at start time.  This pull request fixes that defect.  Note that wildcards function per Java rules.  A trailing wildcard expands to all files fitting "*.jar".
jpype.startJVM(classpath=[
   '../../src/myproj/dist/myproj.jar',
   '../../src/dependencies/*']
   )

This one was to address a concern on stack overflow (as well as my own personal needs).  It has minor API issues as it introduces a glob pattern to the classpath syntax.  I have been running with it for a week without issues.
@marscher If you are fine with the API implications of reporting the errors and the glob, I will commit it without further review.   Nothing was large enough in this to trip the testbench as we never checked the messages on errors being returned .

this globbing pattern will make peoples life easier. Thank you!


add pod utilization dashboard

What type of PR is this?
/kind feature

What this PR does / why we need it:
Gpu usage for pod latitude was previously added, but there are no related panels in Dashboard

Which issue(s) this PR fixes:
Fixes #341
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

@wawa0210 @archlitchi PTAL

/lgtm
/approve


Fix #369: html output size

@n-riesco You added these lines in #207. Are there any special cases in which we needed them?

If I remember correctly those lines are meant to deal with large DataFrames; e.g.
import pandas as pd
import numpy as np
pd.DataFrame(np.random.randn(100, 16), columns=list('ABCDEFGHabcdefgh'))

I've just tested it. With this PR the horizontal scrollbar is only visible after scrolling to the bottom:

and without, the horizontal scrollbar is always visible:

On my system the scrollbars are displayed correctly with this PR.

@lgeiger Do you mean that you don't need to scroll down to the bottom of the DataFrame to see the horizontal scroll bar?

@lgeiger Do you mean that you don't need to scroll down to the bottom of the DataFrame to see the horizontal scroll bar?

Yes I see both.

I'm using Pandas 0.17.1 and the DataFrame is styled like this
.

I tried with pandas 0.17.1 and everything works fine for me.
The DataFrame is styled like this

. The problem is caused by overflow: auto.

I can reproduce this issue in Ubuntu 14.04 (using Pandas 0.13.1 and IPython 4.1.2) and Ubuntu 16.04 (using Pandas 0.17.1 and IPython 2.4.1).

@n-riesco I updated the PR. Please test if it works for you.

Great! Works for me as well


97 ask for in app review

Similar rules were applied from the iOS app to ask for a review once per version code after viewing 5 recipes. Also like the iOS app, I wait 2 seconds before showing the dialog so it doesn't appear abruptly after navigating back to the home screen. Google doesn't disclose what the quota is for showing a review, but I assume asking once per version should satisfy the quota, especially since we're not updating the app frequently. (There is technically a way to check if the review dialog was presented by looking for an isNoOp flag in the ReviewInfo object.)
Once again, the toughest part was trying to test the code. The presentReviewIfQualified method is a little messy since I combined coroutines with the more traditional completion listeners of Tasks. Google offers a FakeReviewManager for unit testing, but since I still had to mock the context and activity, I had to mock the rest of the review methods as well, including the listeners. Ultimately, this blog helped me set up all the mocks properly. Slots were the key to capturing the task results from each listener. Also, advanceUntilIdle() was needed to call all the coroutines inside the listeners.
The biggest difference between the iOS and Android implementations is that it's not possible to show the review dialog from a normal debug build (docs). The only way to test the full functionality is to deploy to an internal test track or use internal app sharing (which most closely resembles the iOS behavior since reviews can't be submitted this way). I plan on deploying to an internal test track anyway once the full build is ready, but I can try using internal app sharing to see if I can test this more quickly. If it works, I'll post an update.

So the way internal app sharing works is as follows:

Have the app be deployed to an internal test track at a minimum.
Agree to the T&C for internal app sharing and manage upload & download permissions on the Play Console.
Upload the APK/AAB to https://play.google.com/console/u/1/internal-app-sharing. This can be an unsigned debug build and the version code doesn't have to be unique. (I think Google signs the app on your behalf to testers using a separate certificate from the main one.)
Enable internal app sharing in Google Play settings on the Android device by following the directions here. The internal app sharing switch can be found under General --> Developer Options after enabling developer mode.
Copy the link generated and open it on an Android device. It will be valid for 60 days.
Uninstall any existing versions from the device and install the internal test version.


Replace Sum and Average calls with SumCount call

Description
When the response is JSON, Average call returns a single integer even though the result may be a float. This is problematic, since the result is not correct, and also the user has no control over the conversion of the float to integer.
Meanwhile, in the protobuf response there are two fields: Sum and Count instead of the single integer. Sum and Average returns the same result!
In order to resolve these problems, we can have a SumReduce call which returns Sum and Count fields. That would be easier to implement than the other option: returning floats for Average and returning floats (or integers) from the Sum call.
EDIT
The protobuf result has the SumCount field which has a Count field of type int64. The result also has the N field which is of type uint64. That is confusing. We can remove the SumCount field from the result, and add a Sum field which is int64. The N field would be used in place of Count.
EDIT 2
See: https://github.com/pilosa/pilosa/issues/822 for a related issue.
EDIT 3
Renamed SumCount call to SumReduce.

Renamed SumCount call to SumReduce.


Add node id to kafka_cluster.txt

Add node id to kafka_cluster.txt so that latest changes to parse_cluster_txt will function correctly for kafka cluster builds.

@pu239ppy , mind taking a look.

Looks correct, also if you wanted something not to have an id you want a space between - and hostname

Thanks @pu239ppy .


[New Feature]: Hovering effect over the rank cards.

🎮 feature Request
The rank cards will appear to come out and have shadow effect when hovered  upon
Point down the features
hovering over the cards will make them look stunning using shadow and color changing ,improving overall UI/UX .
Select program in which you are contributing
GSSoC24
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

@Durgesh4993  and @Manaregr8 sir I have already created a pull request since 2 days where i have added hovering effect to the leaderboard. You can check it and close the issue .


community[minor]: add tool calling for DeepInfraChat

DeepInfra now supports tool calling for supported models.

@ccurme Thanks for the explanation 🙏

@ccurme  @baskaryan @eyurtsev  Thank you all!


Updated to spotify's new layout

I haven't fully tested it, also I don't know if it's been rolled out everywhere already or just a/b tests or certain countries.

Is new Spotify interface already released, so I can merge it? I can't test that service. @zwacky?

I researched over internet and see, that new layout is already default. As @zwacky tested this PR, I merge it.


ARROW-16774: [C++] Create Filter Kernel on RLE data

@save-buffer There might be a bit of background reading here but do you want to take a look at the filter kernel itself?


Feature: AR Viewer

1. Why is this change necessary?
2. What does this change do, exactly?
3. Describe each step to reproduce the issue or behaviour.
4. Please link to the relevant issues (if any).
5. Checklist

[ ] I have rebased my changes to remove merge conflicts
[ ] I have written tests and verified that they fail without my change
[ ] I have written or adjusted the documentation according to my changes
[ ] This change has comments for package types, values, functions, and non-obvious lines of code
[ ] I have read the contribution requirements and fulfil them.

@CodiumAI-Agent /review

PR Reviewer Guide 🔍
Here are some key observations to aid the review process:

⏱ Estimated effort to review: 5 🔵🔵🔵🔵🔵
🧪 No relevant tests
🔒 No security concerns identified
⚡ Recommended focus areas for review
Code ComplexityThe DIVEWebXRController class is highly complex and handles multiple responsibilities such as session management, input handling, and scene updates. Consider refactoring into smaller, more focused classes.
Code ComplexityThe DIVEWebXRTouchscreenControls class is very complex, managing touch inputs, gestures, and dispatching events. Refactoring to simplify and possibly splitting into more manageable components would enhance maintainability.
Test CoverageThe test suite for ARQuickLook might be insufficient given the complexity of the AR setup and operations. Consider expanding tests to cover more scenarios and edge cases.
Test CoverageThe test coverage for SceneViewer appears to be missing. Given its role in AR scene management, comprehensive tests are crucial.
Test CoverageThe tests for the AR class do not seem to cover all methods and possible interaction scenarios, which is critical for ensuring the reliability of AR features.

Persistent review updated to latest commit https://github.com/shopware/dive/commit/aecf91007fc0580ae7a1638ec8098c2bab49f53d


showing warning when using with angular 4

WARNING in
/modules/admin-starter/~/angular2-multiselect-dropdown/clickOutside.js
(Emitted value instead of an instance of Error) Cannot find source file '../tmp/src-inlined/clickOutside.ts': Error: Can't resolve '../tmp/src-inlined/clickOutside.ts' in '/modules/admin-starter/node_modules/angular2-multiselect-dropdown'\n @ /modules/admin-starter/~/angular2-multiselect-dropdown/angular2-multiselect-dropdown.js 2:0-55\n @ /modules/admin-starter/src/book-manager/book-manager.module.ts\n @ ./src async\n @ ./~/<EMAIL_ADDRESS>@ ./src/main.ts\n @ multi webpack-dev-server/client?http://<IP_ADDRESS>:9000 webpack/hot/dev-server ./src/main.ts
WARNING in /modules/admin-starter/~/angular2-multiselect-dropdown/multiselect.component.js
(Emitted value instead of an instance of Error) Cannot find source file '../tmp/src-inlined/multiselect.component.ts': Error: Can't resolve '../tmp/src-inlined/multiselect.component.ts' in '/modules/admin-starter/node_modules/angular2-multiselect-dropdown'\n @ //modules/admin-starter/~/angular2-multiselect-dropdown/angular2-multiselect-dropdown.js 1:0-61 6:0-67\n @ /modules/admin-starter/src/book-manager/book-manager.module.ts\n @ ./src async\n @ ./~/<EMAIL_ADDRESS>@ ./src/main.ts\n @ multi webpack-dev-server/client?http://<IP_ADDRESS>:9000 webpack/hot/dev-server ./src/main.ts

working as expected. Please refer to package.json for the version on which the component is developed.


provide some varying styles

I've seen in other threads that you provide zero styling so others can choose how to style the table. That's great, but I think it'd also be great if you provided a few stylesheets to style the table in different, common ways, like material design and bootstrap. This would make the workload much easier on people trying to implement the table and have a nice-looking result.

If you want to contribute one feel free to create a wiki page and submit a PR to link to it in the README :smile:

So why not leave this open until the issue is actually addressed?


Multiple email notifications when adding members to project

GitLabForm when assigns users to project first removes a user from the project and then adds it with desired access level. This causes that each user configured in GitLabForm is notified about an access being granted to a project each time GitLabForm is executed.
This can become really inconvenient if GitLabForm is used to enforce settings on multiple projects and run automatically (for example on a daily basis).

Thanks for reporting the issue!
That’s a valid point, GitLabForm should not generate those notifications.
It’s an easy fix, good for the first PR. Do you want to implement it yourself, @sgraca ?

Unfortunately I don't have the capacity to look into this at the moment, but hopefully I'll get back to this in a couple of months.

I'm starting to run into this now.

It’s an easy fix, good for the first PR

@gdubicki - can you give me some hints on where to start? I might take a stab if I have time. This seems similar to branch protection issue: first remove and then add. I think we need to check if the user is already added with the configured setting.

Thanks @gdubicki . I'll see if I can make some time soon for this fix.

Please make PR to branch v2, @amimas . We will release v2 very soon, there is no point in working on v1 anymore.

v2 final has been released. Please reopen this ticket if you still have issues.

I didn't get a chance work on this but so happy to see that this has been addressed in v2. Now I really need to upgrade. 😅


Docplex 2.20 does not work without cplex

Information

Qiskit Aqua version: latest
Python version: NA
Operating system: NA

What is the current behavior?
Aqua 0.8.2 includes some workaround for Docplex 2.20, but it has another issue that it does not work without cplex.
See https://github.com/Qiskit/qiskit-optimization/issues/24 for the details.
Steps to reproduce the problem
What is the expected behavior?
Suggested solutions
I recommend to pin docplex version (2.15 might be the best).

Sorry. I missed that Aqua 0.8.2 pinned docplex==2.15.194. It has no problem.


fixed hive scripts to new event format

Issue: #PutYourIssueNumberHere

[ ] Tick here to confirm that you have run RunCodeFormatter.ps1

Description:
Briefly describe the work that has been done and how that differ from what was there before. Only a few sentences since reviewer should be able to find more information in the issue linked at the top.
Test:
Describe how a reviewer should go ahead and test the introduced change(s) and/or what to look for.
(Make sure that all above information is provided before submitting your pull request)

Hi @oliviak, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Olivia Klose). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

Started documentation on the output of the analytics building block
fixed hive scripts
powershell script to upload hive scripts to a storage account & SQL DB

Good start on the documentation @oliviak . Very useful!


feat: dlq

Summary by OpenAI
Release Notes:

New Feature: Introduced a DLQ (Dead Letter Queue) feature in the codebase, including a new pallet called dlq that handles orders and side effects.
Logic and Functionality Changes: Modified the pallet module in pallets/xdns/src/lib.rs to handle gateway overrides during genesis, replace &gateway_id with gateway_id, add error handling for missing escrow accounts, and append token IDs to AllTokenIds.
Code Modifications: Added a new trait implementation CircuitSubmitAPI and modified the on_extrinsic_trigger function in pallets/circuit/src/lib.rs. Also introduced new types and an implementation of TryInto in primitives/src/circuit/types.rs.

"Code changes dance,
Features take a chance.
Bugs find their fix,
Docs reveal their tricks.
With logic refined,
Celebrate the code's design."

succeed by #1132


gl-matrix *.set() equivalent missing

Missing a way to set a variable with specific numbers, like a create but with a dst. Or am I missing something?
e.g.
const v = vec3.create();
// ...
vec3.set(1, 2, 3, v);

you're right, there is no set ATM
On creation you can do this
const v = vec3.create(1, 2, 3);

You can also do this
vec3.copy([1, 2, 3], v);

But ATM there is no set. Can add one

added: https://github.com/greggman/wgpu-matrix/commit/b99726f7328bffdc9b54cb6018d76b8cd9b08ba2

thanks!


librarian-puppet returns "Unable to find module" on puppet forge

Environment: Windows 8, Ruby 1.9.3, librarian-puppet 1.1.2, librarian 0.1.2.
Example puppetfile:
forge "http://forge.puppetlabs.com"
mod 'jonono/php',         :git => 'https://github.com/jonono/puppet-php.git', :ref => '0.1.4'
mod 'jonono/syslogng',    :git => 'https://github.com/jonono/puppet-syslogng', :ref => '0.1.0'
mod 'simondean/iis',      '0.1.3'

In this case jonono/php and jonono/syslogng install fine, however librarian-puppet returns
Unable to find module 'simondean/iis' on https://forgeapi.puppetlabs.com

This occurs for any module that doesn't have a specific repo reference. Here's the --verbose output after the above error: https://gist.github.com/pantala/b40edeca743f357b5517
Help?

I'm seeing the same issue, on Ubuntu Linux.  When using the forge url as provided by init, I get a 301 redirect.  I.e.  http://forge.puppetlabs.com/v3/releases?module=puppetlabs-stdlib redirects to https://forge.puppetlabs.com/v3/releases?module=puppetlabs-stdlib
If I change the forge URL in the Puppetfile to https though, the module isn't found:
mc0e@laptop$ librarian-puppet install --verbose
[Librarian] Ruby Version: 1.9.3
[Librarian] Ruby Platform: x86_64-linux
[Librarian] Rubygems Version: 1.8.23
[Librarian] Librarian Version: 0.1.1
[Librarian] Librarian Adapter: puppet
[Librarian] Librarian Adapter Version: 0.9.10
[Librarian] Project: /home/mc0e/tmp/test-plib
[Librarian] Specfile: Puppetfile
[Librarian] Lockfile: Puppetfile.lock
[Librarian] Git: /usr/bin/git
[Librarian] Git Version: 1.9.1
[Librarian] Git Environment Variables:
[Librarian]   (empty)
[Librarian] Pre-Cached Sources:
[Librarian] Post-Cached Sources:
[Librarian]   [:forge, "https://forge.puppetlabs.com", {}]
[Librarian] Scheduling puppetlabs/stdlib (>= 0) <https://forge.puppetlabs.com>
[Librarian] Resolving puppetlabs/stdlib (>= 0) <https://forge.puppetlabs.com>
[Librarian]   Checking manifests
Unable to find module 'puppetlabs/stdlib' on https://forge.puppetlabs.com
/usr/lib/ruby/vendor_ruby/librarian/puppet/source/forge.rb:22:in `versions'
/usr/lib/ruby/vendor_ruby/librarian/puppet/source/forge.rb:34:in `manifests'
/usr/lib/ruby/vendor_ruby/librarian/puppet/source/forge.rb:274:in `manifests'
/usr/lib/ruby/vendor_ruby/librarian/dependency.rb:113:in `cache_manifests!'
/usr/lib/ruby/vendor_ruby/librarian/dependency.rb:109:in `manifests'
/usr/lib/ruby/vendor_ruby/librarian/resolver/implementation.rb:141:in `block in resolving_dependency_map_find_manifests'
/usr/lib/ruby/vendor_ruby/librarian/resolver/implementation.rb:154:in `block (2 levels) in scope_resolving_dependency'
/usr/lib/ruby/vendor_ruby/librarian/resolver/implementation.rb:168:in `block in scope_checking_manifests'
/usr/lib/ruby/vendor_ruby/librarian/resolver/implementation.rb:208:in `scope'
/usr/lib/ruby/vendor_ruby/librarian/resolver/implementation.rb:167:in `scope_checking_manifests'
/usr/lib/ruby/vendor_ruby/librarian/resolver/implementation.rb:153:in `block in scope_resolving_dependency'
/usr/lib/ruby/vendor_ruby/librarian/resolver/implementation.rb:208:in `scope'
/usr/lib/ruby/vendor_ruby/librarian/resolver/implementation.rb:152:in `scope_resolving_dependency'
/usr/lib/ruby/vendor_ruby/librarian/resolver/implementation.rb:140:in `resolving_dependency_map_find_manifests'
/usr/lib/ruby/vendor_ruby/librarian/resolver/implementation.rb:56:in `recursive_resolve'
/usr/lib/ruby/vendor_ruby/librarian/resolver/implementation.rb:32:in `resolve'
/usr/lib/ruby/vendor_ruby/librarian/resolver.rb:16:in `resolve'
/usr/lib/ruby/vendor_ruby/librarian/action/resolve.rb:26:in `run'
/usr/lib/ruby/vendor_ruby/librarian/cli.rb:169:in `resolve!'
/usr/lib/ruby/vendor_ruby/librarian/puppet/cli.rb:63:in `install'
/usr/lib/ruby/vendor_ruby/thor/command.rb:27:in `run'
/usr/lib/ruby/vendor_ruby/thor/invocation.rb:121:in `invoke_command'
/usr/lib/ruby/vendor_ruby/thor.rb:363:in `dispatch'
/usr/lib/ruby/vendor_ruby/thor/base.rb:440:in `start'
/usr/lib/ruby/vendor_ruby/librarian/cli.rb:26:in `block (2 levels) in bin!'
/usr/lib/ruby/vendor_ruby/librarian/cli.rb:31:in `returning_status'
/usr/lib/ruby/vendor_ruby/librarian/cli.rb:26:in `block in bin!'
/usr/lib/ruby/vendor_ruby/librarian/cli.rb:47:in `with_environment'
/usr/lib/ruby/vendor_ruby/librarian/cli.rb:26:in `bin!'
/usr/bin/librarian-puppet:9:in `<main>'

You are using the package provided by ubuntu, if you install librarian using gem install librarian-puppet and remove the package apt-get remove --purge librarian-puppet you will see your problem fixed.

Seems to me that you are all running old versions of librarian-puppet. Update to latest and reopen if it doesn't work.
The Librarian Adapter Version in debug log should be 1.4.1 or 2.0.1

I've now got the gem version, and it's working.
I've created a bug report against the ubuntu package.
https://bugs.launchpad.net/ubuntu/+source/librarian-puppet/+bug/1417620


UriHandler doesnt work as expected with link provider

Does this issue occur when all extensions are disabled?: Yes

Version: 1.74.0-insider
Commit: e764c5b816a99eb8673b2fc4fc028827f202872f
Date: 2022-11-04T05:18:33.639Z
Electron: 19.1.3
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: <IP_ADDRESS>-electron.0
OS: Darwin arm64 21.6.0
Sandboxed: Yes

Issue:
as the docs state https://code.visualstudio.com/api/references/vscode-api#window.registerUriHandler

which means the uri have to have the product scheme ex.vscode and the ext id as authority or the handler wont catch anything.
this also means that because of the wise decision of removing the vscode scheme type of the link provider-supported schemes, u now dont have a clickable popup which makes the whole thing useless.
therefore this leaves us with either

a handler support & a popup with no clickable links
or a popup with clickable links but no handler support.

this is related to https://github.com/microsoft/vscode/issues/151077 which got closed & locked for an incorrect reason.

Steps to Reproduce:

create a link provider that opens a file path

vscode.languages.registerDocumentLinkProvider('fooLang', new class implements vscode.DocumentLinkProvider {
  provideDocumentLinks(document: vscode.TextDocument, token: vscode.CancellationToken): vscode.ProviderResult<vscode.DocumentLink[]> {
    let uri = vscode.Uri.parse('file:///some/path/to/file.js');

    let link = new vscode.DocumentLink(new vscode.Range(0, 0, 1, 0), uri)
    link.tooltip = '/some/path/to/file.js'

    return [link]
  }
})

register the handler

vscode.window.registerUriHandler({
  handleUri(provider) {
    console.log(provider);
  }
})

click the link & check ur console

nothing shows up but the popup link is clickable

now change the uri to follow the docs

vscode.languages.registerDocumentLinkProvider('fooLang', new class implements vscode.DocumentLinkProvider {
  provideDocumentLinks(document: vscode.TextDocument, token: vscode.CancellationToken): vscode.ProviderResult<vscode.DocumentLink[]> {
    let uri = vscode.Uri
            .parse(`vscode-insiders://file` + '/some/path/to/file.js')
            .with({authority: 'my.extension'});

    let link = new vscode.DocumentLink(new vscode.Range(0, 0, 1, 0), uri)
    link.tooltip = '/some/path/to/file.js'

    return [link]
  }
})

click the link & check ur console

handler works but the popup link is not clickable

@ctf0 did you find https://github.com/microsoft/vscode/issues/151720#issuecomment-1159068769 from @mjbvz and the suggestion of using command: URIs?

@gjsjohnmurray yes i did, however i didnt find why it was removed, why do need to creat a way around when we can already have a straight forward api, why its still in the docs if its not secure/over complicated?

why do need to create a way around when we can already have a straight forward api,

I would argue the opposite way: the command uri is straight forward and direct towards your extension, the vscode and vscode-insider schemes (uri handler) involve the operating systems link handler. That seems wasteful and excessive.
@joaomoreno The doc for the UriHandler mentions system-wide uris, maybe we should clarify that system means operating system and not just VS Code
@ctf0 Looking at your sample and assuming that's from the "real world": it looks like you want to open a file at a certain location. Note that you can use fragments for that, e.g file:///some/path.txt#L12,34 will open path.txt and reveal line 12 column 34. No command, no uri handler in that case

We have a great extension developer community over on GitHub discussions and Slack where extension authors help each other. This is a great place for you to ask questions and find support.
Happy Coding!


Bigdecimal crate does not translate.

Describe the bug
In my flutter_rust_bridge.yaml:
rust_input: crate::api,num-rational,bigdecimal

Then:
❯ flutter_rust_bridge_codegen generate
[0.9s] Parse
  └── [0.8s] Cargo expand & syn parse
  └── [0.1s] Parse HIR
  └── [0.0s] Parse MIR
[0.1s] Generate
Error: Will generate duplicated class names (["BigDecimalRef"]).
This is often because the type is auto inferred as both opaque and non-opaque.
Try to add `#[frb(opaque)]` or `#[frb(non_opaque)]` to the struct, or change code that uses it.
Another way to debug is to temporarily set environment variable `FRB_DEBUG_SKIP_SANITY_CHECK_CLASS_NAME_DUPLICATES=1` and check the generated code.

As bigdecimal is a third party crate, I can't really add any #[frb(...)] stuff anywhere ...
OS
Linux
Version of flutter_rust_bridge_codegen
Latest (git)

Hmm, maybe num-rational or decimal is too complex to be fully automatically scanned?
As for the error, try what it suggests - FRB_DEBUG_SKIP_SANITY_CHECK_CLASS_NAME_DUPLICATES=1 and see (maybe paste here) what is wrong

Oh I see, seems that you want to use https://github.com/fzyzcjy/flutter_rust_bridge/issues/2105, then see my suggestion there.

Close since the suggestions of BigDecimal are in https://github.com/fzyzcjy/flutter_rust_bridge/issues/2103#issuecomment-2178131466, but feel free to reopen or create new issues if you do need to translate this crate!


[bug] Could not find a declaration file for module @ensdomains/thorin

Package Version
0.6.44
Current Behavior
There are no types for the package

Expected Behavior
No response
Steps To Reproduce
No response
Anything else?
No response

This makes sense if you were unable to install Thorin. Please try installing with the --legacy-peer-deps flag I suggested in #136


Requirement: Make sure no .DS_Store files are included in packages

Reference: https://en.wikipedia.org/wiki/.DS_Store
@ferventcoder what are your thoughts on the level this should be at?

Requirement

:+1:


Freeze when resizing docks

Tested versions
Reproducible in: v4.3.stable.steam [77dcf97d8], v4.3.stable.official [77dcf97d8], v4.2.2.stable.official [15073afe3], v4.1.4.stable.official [fe0e8e557], v4.0.4.stable.official [fc0b241c9]
Not reproducible in: v3.6.stable.official [de2f0f147]
System information
Godot v4.3.stable (77dcf97d8) - Windows 10.0.26100 - Vulkan (Forward+) - integrated Intel(R) Iris(R) Xe Graphics (Intel Corporation; <IP_ADDRESS>58) - 12th Gen Intel(R) Core(TM) i5-12500H (16 Threads)
Issue description
Godot editor freezes when trying to resize docks while in 2d or 3d editor. Seems to work fine while in Script editor
Tested on another PC: Godot v4.3.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4060 (NVIDIA; <IP_ADDRESS>70) - AMD Ryzen 5 7500F 6-Core Processor (12 Threads), works fine
Steps to reproduce
Open any project, open 2d or 3d editor, resize any dock horizontally couple times
Video replay:
https://youtu.be/LUhZdLDJL-k
Minimal reproduction project (MRP)
N/A

Doesn't freeze when using Compatibility and Mobile renderers, freezes only with Forward+
I guess it might be because of integrated graphics on my laptop


Rotated monitor stoped working

Hyprland Version
v0.32.3-57-gbe3d6352
Bug or Regression?
Regression
Description
Rotated monitor with transform,1 stopped working correctly.
Now it only works on like 1/3 of the screen.
How to reproduce
Rotate a monitor in the configuration with transform,1
Maybe it's only on NVIDIA cards (need to verify).
Crash reports, logs, images, videos

looks fine to me, people who rotate their monitors are the devil


The variable did not appear

I couldn't find the volume_muted, is_playing, is_stuffled variables, and even after reinstalling the plugin, these variables didn't appear
——————
Macro Deck 2.14.1
——————
Is it my problem? What should I do?

The exact same issue. 🙌🏼🐺

Macro Deck 2.14.1


fix(OCPADVISOR-59): Fix not loading pages

Fixes https://issues.redhat.com/browse/OCPADVISOR-59.
This should fix the bug when the users navigated to the cluster or recommendation details page for the second and further times and couldn't see data loaded.
Screencast from 03-08-2023 01:48:38 PM.webm
How to test
Navigate to recommendation/id or cluster/id pages. Go back to the recommendations/clusters list table via breadcrumbs. Go again to any of the details pages. The end page should load fine (whereas for example in production it does not currently).

Some more details on the bug: looks like https://github.com/reduxjs/redux-toolkit/releases/tag/v1.9.0 has introduced a change which breaks our pages. Downgrading to 1.8.6 helps to get back things to normal, however would be nice to make investigation on what exactly started to cause the proble,

Codecov Report
Patch coverage: 100.00% and project coverage change: -3.04 :warning:

Comparison is base (c57b8a1) 88.03% compared to head (f1c146d) 85.00%.

:exclamation: Current head f1c146d differs from pull request most recent head 67582e7. Consider uploading reports for the commit 67582e7 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #528      +/-   ##
==========================================
- Coverage   88.03%   85.00%   -3.04%
==========================================
  Files          25       25
  Lines        1162     1160       -2
  Branches      450      450
==========================================
- Hits         1023      986      -37
- Misses        139      174      +35

Impacted Files
Coverage Δ

...nts/AffectedClustersTable/AffectedClustersTable.js
95.68% <ø> (ø)

src/Components/Breadcrumbs/index.js
100.00% <ø> (ø)

.../Components/ClustersListTable/ClustersListTable.js
88.23% <ø> (ø)

src/Components/MessageState/EmptyStates.js
92.59% <ø> (ø)

src/Components/RecsListTable/RecsListTable.js
82.22% <ø> (ø)

src/Components/Cluster/Cluster.js
100.00% <100.00%> (ø)

src/Components/ClusterHeader/index.js
100.00% <100.00%> (ø)

src/Components/Recommendation/Recommendation.js
86.11% <100.00%> (-0.13%)
:arrow_down:

src/Components/ClusterRules/ClusterRules.js
65.26% <0.00%> (-20.96%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

:tada: This PR is included in version 1.11.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Forms 254 adjust pre defined form

Description
Ticket: FORMS-215

Adjust designer's new form JSON.
Extend eslint with plugin:json/recommended (lint was failing to validate new-form.json changes.

Type of change

[X] New feature (non-breaking change which adds functionality)

How Has This Been Tested?

[X] I have added unit tests to verify my changes.
[X] New and existing unit tests pass locally with my changes
[X] I have manually tested the application to confirm initial empty form is correct

Checklist:

[X] My changes do not introduce any new linting errors
[X] I have performed a self-review of my own code
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have made corresponding changes to the documentation and versioning
[X] My changes generate no new warnings
[X] I have added tests that prove my fix is effective or that my feature works
[X] New and existing unit tests pass locally with my changes
[X] I have rebased onto master and there are no code conflicts
[X] I have checked deployments are working in all environments
[X] I have updated the architecture diagrams as per Contribute.md

@TheSpartan1980 I have fixed one of the smoke tests but looking at the toher I think you might want to review it because adjusting it might require some design changes. With the new-fom configuration we now have 3 pages that are linked by default, First page -> Second page -> Summary.

@TheSpartan1980 I decided to fix the tests in case that facilitates to you, I am making the assumption that it wouldn't be an issue to refactor the test so it adds a new Third page linked to the First page instead of Second page, also because a page can link to multiple pages then the tests is still validating that the page linkage works correctly, please feel free to push changes to this branch as you see fit.

@bertrandmc Good from a QA perspective


Improve bounds checks

https://github.com/openssl/openssl/issues/22986

This PR has the label 'hold: cla required' and is stale: it has not been updated in 30 days. Note that this PR may be automatically closed in the future if no CLA is provided.  For CLA help see https://www.openssl.org/policies/cla.html

This PR has the label 'hold: cla required' and is stale: it has not been updated in 61 days. Note that this PR may be automatically closed in the future if no CLA is provided.  For CLA help see https://www.openssl.org/policies/cla.html

This PR has been closed.  It was waiting for a CLA for 90 days.


cppo: only compare OCAML_VERSION as tuples

To test if the version is greater or equal than 4.03.0,
The code base uses variants of OCAML_MAJOR >= 4 && OCAML_MINOR >= 3.
This is incorrect after 5.0.0. The right way is to use lexicographic
comparison, in extension:
(OCAML_MAJOR > 4) || (OCAML_MAJOR == 4 && OCAML_MINOR >= 3)

But fortunately cppo supports tuples natively (thanks @Julow for the
tip!), so we can express that as just OCAML_VERSION >= (4, 3, 0).
In addition, this commit standardizes the order in which comparisons are
done:

conditionals with an else are written with >=:

#if OCAML_VERSION >= xxx
  ...
#else
  ...
#endif

polyfills for former versions of ocaml are written with <:

#if OCAML_VERSION < xxx
  ...function introduced in xxx...
#endif

@NathanReb done!


Google Chrome version renamed to latest + update

No reason to have version specific manifest

[X] Have you signed the Contributor License Agreement?
[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

Yes there is a conflict with #3259
Microsoft Reviewers: Open in CodeFlow

@OfficialEsco why are you putting latest rather than the version in this case?  unless we have daily updates, there is no guarantee for the app to be the latest?

There is no reason for multiple manifest for a program that don't have specific version
Its easier to update one manifest rather than update and rename another manifest

The guarantee for the app to be the latest is that it will always download the latest, the hash will however not match unless someone keep an eye on it. You guys do not guarantee to download the version we specify so there is no difference.


How do you save changes on the app?

I've remapped my controls and added some cheats, but every time i enter back, all the changes are gone. Is there a way Retroarch or me can save the changes inside my browser or do i have to download something to load them?
Sincerely, Eladio Palacios. :)

fork https://github.com/nenge123/webretro
rewrite /mobile/module.js
replace cdn url path
you site /m.html
this one is use indexdb，when you FS any change will save to indexdb,

@EladioPalacios currently, any configuration changes you make inside the RetroArch menu are not saved. You can use the keybinds menu, which offers a limited number of keys. Cheats support is coming in a future update.


[BUG] MICRO_CLIENT env var is not working on client side

I'm setting up the client.
Client must connect to the server working via gRPC.
Server setup
---

apiVersion: v1
kind: ConfigMap
metadata:
  name: micro-server-env
data:
  MICRO_SERVER: grpc
  MICRO_REGISTRY: kubernetes
  MICRO_SERVER_NAME: micro-server
  MICRO_SERVER_VERSION: latest

func main() {
	// Create tracer
	tracer, closer, err := jaeger.NewTracer(
		jaeger.Name(service),
		jaeger.FromEnv(true),
		jaeger.GlobalTracer(true),
	)
	if err != nil {
		log.Fatal(err)
	}

	defer func(closer io.Closer) {
		_ = closer.Close()
	}(closer)

	// Create service
	// micro.Version(version) - set version
	// micro.Name(service) - set service name
	// micro.Server(grpc.NewServer()), // must come before any other options
	srv := micro.NewService(
		micro.WrapCall(ot.NewCallWrapper(tracer)),
		micro.WrapClient(ot.NewClientWrapper(tracer)),
		micro.WrapHandler(ot.NewHandlerWrapper(tracer)),
		micro.WrapSubscriber(ot.NewSubscriberWrapper(tracer)),
	)
	srv.Init()

	// Register handler
	_ = pb.RegisterTransactionPersistenceHandler(srv.Server(), new(handler.TransactionPersistence))

	// Run service
	if err := srv.Run(); err != nil {
		log.Fatal(err)
	}
}

Client setup
---

apiVersion: v1
kind: ConfigMap
metadata:
  name: micro-env
data:
  MICRO_CLIENT: grpc
#  MICRO_SERVER: grpc
  MICRO_REGISTRY: kubernetes
  MICRO_SERVER_NAME: micro-server
  MICRO_SERVER_VERSION: latest

func main() {
	// Create client
	// micro.Client(grpc.NewClient()), // must come before any other options
	// micro.Name(service), - is defined in config map
	// micro.Version(version), - is defined in config map

	srv := micro.NewService(
		micro.Client(grpc.NewClient()), // Should be working as env var: `MICRO_CLIENT: grpc` but doesn't work
		micro.Version(version),
	)
	srv.Init()

	// Create client
	c := pb.NewTransactionPersistenceService(service, srv.Client())

	for {
		// Call service
		rsp, err := c.Call(context.Background(), &pb.CallRequest{Name: "John"})
		if err != nil {
			log.Fatal(err)
		}

		log.Info(rsp)

		time.Sleep(1 * time.Second)
	}
}

The issue:
MICRO_CLIENT: grpc should replace micro.Client(grpc.NewClient())
When I use micro.Client(grpc.NewClient()), the client works fine.
[micro-client] 2021-11-26 18:56:55  file=micro-client/main.go:40 level=info msg:"Hello John"
[micro-client] 2021-11-26 18:56:56  file=micro-client/main.go:40 level=info msg:"Hello John"
[micro-client] 2021-11-26 18:56:57  file=micro-client/main.go:40 level=info msg:"Hello John"
[micro-client] 2021-11-26 18:56:58  file=micro-client/main.go:40 level=info msg:"Hello John"

But when I use MICRO_CLIENT: grpc, the client doesn't work.
  MICRO_CLIENT: grpc
  MICRO_SERVER: grpc

- deployment/micro-client: container micro-client terminated with exit code 1
    - pod/micro-client-77b5bb5b84-7fzkt: container micro-client terminated with exit code 1
      > [micro-client-77b5bb5b84-7fzkt micro-client] 2021-11-29 11:51:11  file=micro-client/main.go:36 level=fatal {"id":"go.micro.client.transport","code":500,"detail":"malformed HTTP response \"\\x00\\x00\\x06\\x04\\x00\\x00\\x00\\x00\\x00\\x00\\x05\\x00\\x00@\\x00\"","status":"Internal Server Error"}

Are you still importing the grpc client plugin when specifying the flag?

Are you still importing the grpc client plugin when specifying the flag?

Yes

I tried with import and without.
The result is the same
 - deployment/micro-client: container micro-client terminated with exit code 1
    - pod/micro-client-64746fc94-f669r: container micro-client terminated with exit code 1
      > [micro-client-64746fc94-f669r micro-client] 2021-11-29 12:18:27  file=micro-client/main.go:34 level=fatal {"id":"go.micro.client.transport","code":500,"detail":"malformed HTTP response \"\\x00\\x00\\x06\\x04\\x00\\x00\\x00\\x00\\x00\\x00\\x05\\x00\\x00@\\x00\"","status":"Internal Server Error"}
 - deployment/micro-client failed. Error: container micro-client terminated with exit code 1.
 - ```

I can see that http is used to decode binary payload, I'll try using TRANSPORT graph

The code for setting client/server has been unchanged for many years. Both plugins import the cmd package which includes them in the list.
Ensure you're doing
import (
  _ "github.com/asim/go-micro/plugins/client/grpc/v4"
)

And then setting MICRO_CLIENT=grpc

@asim I've posted 2 projects which reproduce this issue:
https://github.com/Dmdv/micro-server
https://github.com/Dmdv/micro-client
Server log:
2021-11-29 16:33:12  file=v4@v4.4.0/service.go:206 level=info Starting [service] micro-server
2021-11-29 16:33:12  file=v4@v4.0.0-20211124174154-b25d744f5c51/grpc.go:894 level=info Server [grpc] Listening on [::]:52719
2021-11-29 16:33:12  file=v4@v4.0.0-20211124174154-b25d744f5c51/grpc.go:725 level=info Registry [mdns] Registering node: micro-server-7fe78676-aafd-428e-b02c-f1e9befa1cd2

Client log:
/private/var/folders/dg/3075cgkj2p12184z1r0949pm0000gn/T/GoLand/___1go_build_micro_client
2021-11-29 16:33:47  file=micro-client/main.go:34 level=fatal {"id":"go.micro.client.transport","code":500,"detail":"malformed HTTP response \"\\x00\\x00\\x06\\x04\\x00\\x00\\x00\\x00\\x00\\x00\\x05\\x00\\x00@\\x00\"","status":"Internal Server Error"}

Client env:
MICRO_CLIENT=grps
MICRO_SERVER_NAME=micro-server
Server env:
MICRO_SERVER=grpc
MICRO_SERVER_NAME=micro-server
MICRO_SERVER_VERSION=latest

https://github.com/Dmdv/micro-client/blob/master/plugins.go#L5
You are importing the server plugin NOT the client plugin. Please change that, then it should work. Once done, please close this issue.

Thank you so much! Tunnel vision
BTW, what MICRO_TRANSPORT is used for?

The default client/server are transport agnostic, they can use http, nats, grpc and many other things. Its not directly compatible with a grpc client/server as it uses a fixes service called Transport.

Thank you, understood.


[HotFix] Op is not bound to any variables

After PR #12349 inference of some Adreno networks was broken. In the
output it was the following error:
TVMError: Not all Vars are passed in api_args: 'compute' is not bound
to any variables

cc: @tkonolige, @Lunderberg
cc @driazati

Thanks @echuraev @Lunderberg for the great follow up. This is merged.


bosh login failed

I tried to "bosh login" using credential "ops_manager" and its $BOSH_CLIENT_SECRET, but got
Failed to authenticate with UAA
Where can I find credentials to "bosh login" - Thanks

Running “cf dev bosh env” should output the environment variables. “cf dev bosh” should give you instructions on how to load these variables into your shell.
Does that work for you?

yes, it works. Thank you @aemengo

Don't know why I have to issue the load command every so often to bosh login.  I should only need to load it once, correct?
Also, can you tell me the URL to credhub associated with the pcfdev cloud foundry deployment? or this is not the right forum for pcfdev.?

Don't know why I have to issue the load command every so often to bosh login. I should only need to load it once, correct?

Yes, you should only have to load it once, once per shell session. If you are entering new console windows, you'll have to perform the load command again.

Also, can you tell me the URL to credhub associated with the pcfdev cloud foundry deployment?

The BOSH director credhub can be found at <IP_ADDRESS>:8844. The internal credhub that utilized for PAS deployment is not accessible from outside of the VM

is this the right forum for pcfdev.?

Yes, it is :)


Ignoring certain tasks for model selection

Is there, at the moment, a built in way to ignore certain tasks when choosing the best model? I.e. there is an auxiliary task on which I’d like to train, but not necessarily consider its performance when selecting the best model.

There is not a parameter for this function. One could however disable early stopping, and save the model after every epoch, or leave out the dev data for the auxiliary task.
I can take a look later this week whether this functionality is hard to add.

I do not see a very easy way to implement this, and don't have much time on my hands. Harcoding something should be easy though. You can avoid going into this "if" https://github.com/machamp-nlp/machamp/blob/master/machamp/model/machamp.py#L541
One nice way might be to check for " if not decoder.task.endswith('skip') " and rename the tasks you do not want to include so that they end with the string "skip"


casing: Starknet instead of StarkNet

Is your feature request related to a problem? Please describe.
The official casing for Starknet is not StarkNet anymore, but Starknet.
However, some occurrences of StarkNet can still be found, most notably in the TypeHash function:
https://github.com/0xs34n/starknet.js/blob/384db9f3bfaf066dea43f60e49f255c9a4a28b63/src/utils/typedData.ts#L255-L256
Describe the solution you'd like
Replace every occurence of StarkNet with Starknet
Describe alternatives you've considered
Keep StarkNet and dismiss this issue. I think it's still early enough to change to Starknet though.
Additional notes
This introduces a big breaking change (:

Hey! Can this issue be assigned to me?

@0xdorifto Yes feel free to take it

@tabaktoni thanks! I'll start working on it now.

@0xdorifto Yes feel free to take it

should we discuss if it's worth introducing the breaking change?

Not sure it's still early enough to change.

It's up here if you guys want to check it out ^

Will probably be able to close this after this one is closed https://github.com/starknet-io/get-starknet/pull/194

Will at the end be defined by this snip : https://community.starknet.io/t/snip-off-chain-signatures-a-la-eip712/98029#abstract-1

Resolved in favor of the snip, for further progress push change's on the snip


Space between axis line and the first bar

Version
5.2.2
Link to Minimal Reproduction
https://echarts.apache.org/examples/en/editor.html?c=bar-background
Steps to Reproduce

Create any basic bar chart
Observed that there is space between axis line and the bar

Current Behavior
Observed that there is space between axis line and the bar
Expected Behavior
Need any setting to remove that spacing can be removed

Environment
- OS:
- Browser:
- Framework:

Any additional comments?
No response

This is not the space between the bar and the axis line. You can change it by setting barWidth to be '100%'.

@Ovilia, I have given barWidth as 100% but we are not getting gap between each bar.

Yes, this is expected. It's not possible to remove the gap only for the first bar.

we can hack it, but why? Does it look prettier ? Demo Code


React native Upgrade issue

Description
i am upgrading from 0.67.5 to 0.72.3. Android is working fine but in ios i am having some issue with project.pbxproj file and unable to install pods.
Error -- RuntimeError - [Xcodeproj] Type checking error: got PBXBuildFile for attribute: Attribute children (type: to_many, classes: ["PBXGroup", "PBXFileReference", "PBXReferenceProxy"], owner class: PBXGroup)
New Version
0.72.3
Old Version
0.67.5
Build Target(s)
12.4
Output of react-native info
System:
OS: macOS 13.4.1
CPU: (8) arm64 Apple M1
Memory: 95.28 MB / 8.00 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node:
version: 16.11.0
path: /usr/local/bin/node
Yarn:
version: 1.22.19
path: ~/Desktop/Final/mobile/node_modules/.bin/yarn
npm:
version: 8.0.0
path: /usr/local/bin/npm
Watchman: Not Found
Managers:
CocoaPods:
version: 1.12.0
path: /Users/test/.rvm/gems/ruby-3.0.0/bin/pod
SDKs:
iOS SDK:
Platforms:
- DriverKit 22.1
- iOS 16.1
- macOS 13.0
- tvOS 16.1
- watchOS 9.1
Android SDK: Not Found
IDEs:
Android Studio: 2022.2 AI-222.4459.24.2221.9862592
Xcode:
version: 14.1/14B47
path: /usr/bin/xcodebuild
Languages:
Java:
version: 11.0.12
path: /usr/bin/javac
Ruby:
version: 3.0.0
path: /Users/test/.rvm/rubies/ruby-3.0.0/bin/ruby
npmPackages:
"@react-native-community/cli": Not Found
react:
installed: 18.2.0
wanted: 18.2.0
react-native:
installed: 0.72.3
wanted: ^0.72.3
react-native-macos: Not Found
npmGlobalPackages:
"react-native": Not Found
Android:
hermesEnabled: true
newArchEnabled: false
iOS:
hermesEnabled: Not found
newArchEnabled: Not found
Issue and Reproduction Steps
i am upgrading from 0.67.5 to 0.72.3. Android is working fine but in ios i am having some issue with project.pbxproj file and unable to install pods.
Error -- RuntimeError - [Xcodeproj] Type checking error: got PBXBuildFile for attribute: Attribute children (type: to_many, classes: ["PBXGroup", "PBXFileReference", "PBXReferenceProxy"], owner class: PBXGroup)
i have attached Xcodeproj file also here
pbxproject.zip
pod file
pod file.zip

i am able to fix the issue but getting this issue now with ios, so just looking into it. There was duplicate classes and some wrong references earlier
warn No apps connected. Sending "reload" to all React Native apps failed. Make sure your app is running in the simulator or on a phone connected via USB.
info Reloading app..

i am able to fix the issue .There was duplicate classes and some wrong references earlier so got this issue now with ios, so just looking into it.

Closing because you mentioned it's fixed


Update owners

Signed-off-by: leonardpahlke<EMAIL_ADDRESS>I added the tool creators to the reviewers. (see https://github.com/encodeflush/testgrid-json-exporter)

@justaugustus @saschagrunert this PR updates the reviewers (OWNERS) with the tool authors, since @encodeflush and I are not part of the organization yet, should I close this PR again, or should I apply for membership?

I would say apply for membership

/verify-owners

/verify-owners

/verify-owners


Add atomic memcpy RFC.

Rendered

cc @ojeda

This could mention the atomic-maybe-uninit crate in the alternatives section (cc @taiki-).

With some way for the language to be able to express "this type is valid for any bit pattern", which project safe transmute presumably will provide (and that exists in the ecosystem as bytemuck and zerocopy and probably others), I'm wondering if it would be better to return an AtomicPerByteRead<T>(MaybeUninit<T>) which we/the ecosystem could provide a safe into_inner if T is valid for any bit pattern.
This would also require removing the safe uninit method. But you could always presumably do an AtomicPerByte<MaybeUninit<T>> with no runtime cost to passing MaybeUninit::uninit() to new.
That's extra complexity, but means that with some help from the ecosystem/future stdlib work, this can be used in 100% safe code, if the data is fine with being torn.

The "uninit" part of MaybeUninit is essentially not a bit pattern though. That's the problem. Even if a value is valid "for all bit patterns", you can't unwrap uninit memory into that type.
not without the fabled and legendary Freeze Intrinsic anyway.

On the other hand, AnyBitPatternOrPointerFragment isn't a type we have, nor really a type we strictly need for this. Assuming tearing can't deinitialize initialized memory, then MaybeUninit would suffice I think?

note that LLVM already implements this operation:
llvm.memcpy.element.unordered.atomic Intrinsic
with an additional fence operation for acquire/release.

The trouble with that intrinsic is that unordered is weaker than monotonic aka Relaxed, and it can't easily be upgraded.  There's no "relaxed fence" if the ordering you want is Relaxed; and even if the ordering you want is Acquire or Release, combining unordered atomic accesses with fences doesn't produce quite the same result.  Fences provide additional guarantees regarding other memory accessed before/after the atomic access, but they don't do anything to restore the missing "single total order" per address of the atomic accesses themselves.

The trouble with that intrinsic is that unordered is weaker than monotonic aka Relaxed, and it can't easily be upgraded. There's no "relaxed fence" if the ordering you want is Relaxed; and even if the ordering you want is Acquire or Release, combining unordered atomic accesses with fences doesn't produce quite the same result. Fences provide additional guarantees regarding other memory accessed before/after the atomic access, but they don't do anything to restore the missing "single total order" per address of the atomic accesses themselves.

I'm very familiar with the standard Rust and C++ memory orderings, but I don't know much about llvm's unordered ordering. Could you give an example of unexpected results we might get if we were to implement AtomicPerByte<T>::{read, write} using llvm's unordered primitive and a fence? Thanks!
(It

cc @ojeda

Thanks! Cc'ing @wedsonaf since he will like it :)

Unordered is not monotonic (as in, it has no total order across all accesses), so LLVM is free to reorder loads/stores in ways it would not be allowed to with Relaxed (it behaves a lot more like a non-atomic variable in this sense)
In practical terms, in single-thread scenarios it behaves as expected, but when you load an atomic variable with unordered where the previous writer was another thread, you basically have to be prepared for it to hand you back any value previously written by that thread, due to the reordering allowed.
Concretely, I don't know how we'd implement relaxed ordering by fencing without having that fence have a cost on weakly ordered machines (e.g. without implementing it as an overly-strong acquire/release fence). That said, I think we could add an intrinsic to LLVM that does what we want here. I just don't think it already exists.
(FWIW, another part of the issue is that this stuff is not that well specified, but it's likely described by the "plain" accesses explained in https://www.cs.tau.ac.il/~orilahav/papers/popl17.pdf)

CC @RalfJung who has stronger opinions on Unordered (and is the one who provided that link in the past).
I think we can easily implement this with relaxed in compiler-builtins though, but it should get a new intrinsic, since many platforms can implement it more efficiently.

We already have unordered atomic memcpy intrinsics in compiler-builtins. For 1, 2, 4 and 8 byte access sizes.

I'm not sure we'd want unordered, as mentioned above...

To clarify on the difference between relaxed and unordered (in terms of loads and stores), if you have
static ATOM: AtomicU8 = AtomicU8::new(0);
const O: Ordering = ???;

fn thread1() {
    ATOM.store(1, O);
    ATOM.store(2, O);
}

fn thread2() {
    let a = ATOM.load(O);
    let b = ATOM.load(O);
    assert!(a <= b);
}

thread2 will never assert if O is Relaxed, but it could if O is (the hypothetical) Unordered.
In other words, for unordered, it would be legal for 2 to be stored before 1, or for b to be loaded before a. In terms of fences, there's no fence that "upgrades" unordered to relaxed, although I believe (but am not certain) that stronger fences do apply to it.

something that could work but not be technically correct is:
compiler acquire fence
unordered atomic memcpy
compiler release fence
those fences are no-ops at runtime, but prevent the compiler from reordering the unordered atomics -- assuming your on any modern cpu (except Alpha iirc) it will behave like relaxed atomics because that's what standard load/store instructions do.

Those fences aren't always no-ops at runtime, they actually emit code on several platforms (https://github.com/rust-lang/rust/issues/62256). It's also unclear what can and can't be reordered across compiler fences (https://github.com/rust-lang/unsafe-code-guidelines/issues/347), certainly plain stores can in some cases (this is easy to show happening in godbolt).
Either way, my point has not been that we can't implement this. We absolutely can and it's probably even straightforward. My point is just that I don't really think those existing intrinsics help us do that.

I like MaybeAtomic, but following C++ with AtomicPerByte sounds reasonable.
The LLVM guys started something similar in 2016:
https://reviews.llvm.org/D27133

CC @RalfJung who has stronger opinions on Unordered (and is the one who provided that link in the past).

Yeah, I don't think we should expose Unordered to users in any way until we are ready and willing to have our own concurrency memory model separate from that of C++ (or until C++ has something like unordered, and it's been shown to also make sense formally). There are some formal memory models with "plain" memory accesses, which are similar to unordered (no total mo order but race conditions allowed), but I have no idea if those are an accurate model of LLVM's unordered accesses. Both serve the same goal though, so there's a high chance they are at least related: both aim to model Java's regular memory accesses.

We already have unordered atomic memcpy intrinsics in compiler-builtins. For 1, 2, 4 and 8 byte access sizes.

Well I sure hope we're not using them in any ways that this actually becomes observable in program behavior, as that would be unsound.

For specific types the load granularity can be larger than a byte and we will likely want to take advantage of that, so the name AtomicPerByte might not fit well.

@ibraheemdev that is covered by the as-if rule. It is impossible for the program to tell if the load is truly per-byte, of if adjacent reads are merged into 2-byte reads (or larger).

I think it's worth mentioning (if for nothing less than for it to have been mentioned) that an alternative to address the core problem of "how can we implement a seqlock?" is to make racy reads/writes on MaybeUninit act more like LLVM's undef.
That is, instead of a racy read of a MaybeUninit<T> being instant global ub, it simply gets an undefined value (which is valid for MaybeUninit) and the UB only "happens" (not sure of better terminology) if the undefined value is ever observed.
This would allow something very close to how a seqlock is classically handled:
pub struct SeqLock<T> {
    seq: AtomicUsize,
    data: UnsafeCell<MaybeUninit<T>>,
}

unsafe impl Sync<T: Copy + Send> for SeqLock<T> {}

impl<T: Copy> SeqLock<T> {
    /// Safety: Only call from one thread.
    pub unsafe fn write(&self, value: T) {
        self.seq.fetch_add(1, Relaxed);
        self.data.write(MaybeUninit::new(value));
        self.seq.fetch_add(1, Release);
    }

    pub fn read(&self) -> T {
        loop {
            let s1 = self.seq.load(Acquire);
            let data = self.data.read();
            let s2 = self.seq.load(Relaxed);
            if s1 & 1 == 0 && s1 == s2 {
                return unsafe { data.assume_uninit() };
            }
        }
    }
}

This has the nice advantages of not having to figure out atomics or how llvm's unordered memcpy actually works while also not actually inuring the performance penalty of having to do a literal bytewise atomic memcpy which can be significantly slower than a more tuned implementation.
Again, not saying that this is strictly the best option, I just think that it's a fairly useful alternative and at the very least worth drawing attention to

@Kixiron That wouldn't suffice, as Ralf explains here: https://github.com/rust-lang/rfcs/pull/3301#discussion_r950713536

It wouldn't suffice on its own, but I think it could be made to work by also placing a suitable fence after the data load and another fence in the write, or something like that?
I do agree that the LLVM semantics for data races are nicer than those of C++. Sadly, that model is also not very well explored, so for now I think it would be better to stick to C++ -- until we are confident enough to define our own concurrency memory model.

It wouldn't suffice on its own, but I think it could be made to work by also placing a suitable fence after the data load and another fence in the write, or something like that?

Doesn't this still have the issue of plain RW not actually interacting with fences: https://github.com/rust-lang/rfcs/pull/3301#discussion_r950100411? A memory model where racy read is undefined value instead of undefined behaviour could work, but you'll still need read-dont-modify-write on the sequence number read

you'll still need read-dont-modify-write on the sequence number read

Yes that is what I meant.

Most of the discussion so far is about the general concept and implementability of an "atomic per byte memcpy", but I'd also like some feedback on the API design itself. E.g. does the usage of MaybeUninit make sense, or should we have a separate MaybeTeared or something like that? Is it ergonomic enough, especially for slices? Etc.

I think the fact that the reason the discussion has focused on the implementability is that the API is pretty good for the use case. I certainly have no objections to it.

My only API concern is the asymmetry around reads returning MaybeUninit<T> but writes taking T. But store_from seems to cover that well enough, and the asymmetry might also serve as a speedbump for people to go read the docs and figure out what is happening.

Most of the discussion so far is about the general concept and implementability of an "atomic per byte memcpy", but I'd also like some feedback on the API design itself. E.g. does the usage of MaybeUninit make sense, or should we have a separate MaybeTeared or something like that? Is it ergonomic enough, especially for slices? Etc.

It does seem kind of odd to me that unsafe code is needed to unpack the result of a byte-wise load even for types where that is actually always safe because any stream of bytes is a valid representation.
For a caricatural example, I do not see why I should need unsafe code to load the contents of an AtomicPerByte<[u8; LENGTH]> into a &mut [u8; LENGTH], given that this operation is UB-free by definition.
In the actual use case that I have in mind, it would be convenient to load an &[f32] byte-wise into an &mut [f32], which should be safe as well.
Basically, I second comment https://github.com/rust-lang/rfcs/pull/3301#issuecomment-1214439068 : any type that allows safe-transmute from a suitably sized stream of bytes, should be safe to load from AtomicPerByte storage, and MaybeUninit does not model that guarantee well as it's designed to also handle uninitialized memory, which this is not about.

It does seem kind of odd to me that unsafe code is needed to unpack the result of a byte-wise load even for types where that is actually always safe because any correctly sized stream of bytes is a valid representation.

We have to be careful here, because not every stream of bytes is valid for [u8; N] -- if any of the bytes is uninitialized, that would be invalid. (So e.g. transmuting (u8, u16) to u32 or to [u8; 4] is not sound.)
However,  [u8; N] has the property that mixing the bytes of any valid instance, yields a valid instance. [bool; N] also has that property. But [NonZeroU32; N] does not. For the types that have that property we could offer an API that skips the MaybeUninit.

The way I read the API as proposed in the RFC text, it always goes between two instances of the same type. So, the transmutation questions shouldn't be an issue. If there's (u8, 16) giving you an uninit byte in there somewhere, then both the source and dest locations would have the same uninit byte position, and it remains sound.

You could have an enum with one variant being A((u8, 16)) and the other B([u8; 4]), a write can change the tag before setting the value, etc.

Yes, but that enum wouldn't count as "any correctly sized stream of bytes is a valid representation" to begin with.

The only types for which "any correctly sized stream of bytes is a valid representation" are MaybeUninit<T> and ZST's. Other types don't allow uninit bytes.

As I said, the property "any correctly sized stream of bytes is a valid representation" is not necessary for making this API return a T. We should stop talking about it, and talk about the actually relevant property instead: mixing the bytes of multiple valid instances yields a valid instance.

However,  [u8; N] has the property that mixing the bytes of any two or more valid instances, yields a valid instance. [bool; N] also has that property. But [NonZeroU32; N] does not. For the types that have that property we could offer an API that skips the MaybeUninit.

That could mean we should use a new MaybeTeared<T> here, instead of MaybeUninit<T>. I suppose that's slightly more accurate, but I'm not sure if it's worth adding such a type.

If any of the bytes of a value depend on other bytes, and the value gets torn at one or more random positions within the byte sequence, then you really can't do much with that torn thing. You mostly just have to reset the whole blob of bytes to some known good value.

ibraheemdev: For specific types the load granularity can be larger than a byte and we will likely want to take advantage of that, so the name AtomicPerByte might not fit well.

RalfJung: that is covered by the as-if rule. It is impossible for the program to tell if the load is truly per-byte, of if adjacent reads are merged into 2-byte reads (or larger).

thomcc: From the x86 architecture manual 3A/I <IP_ADDRESS>:

Software should access semaphores (shared memory used for signalling between multiple processors) using identical addresses and operand lengths. For example, if one processor uses accesses a semaphore using a word access, other processors should not access the semaphore using a byte access.

RalfJung: I agree for now we should keep ruling them out, because I assume that's what C++ does -- and that should probably be explicitly documented for atomic memcpy, because that operation is much more likely to be used in unsafe type-punning code than the regular Atomic types.

P1478: Note that on standard hardware, it should be OK to actually perform the copy at larger than byte granularity. Copying multiple bytes as part of one operation is indistinguishable from running them so quickly that the intermediate state is not observed. In fact, we expect that existing assembly memcpy implementations will suffice when suffixed with the required fence.

I'm trying to wrap my head around the implications of these statements. Does this mean that:

it's never allowed for any atomic byte copy implementation to copy more than 1 byte in a single instruction, or
is (only) the internal (llvm?) implementation of atomic_{load|store}_per_byte_memcpy allowed to copy larger-than-1-byte values on targets where this is legal + it is never allowed to mix any of the Rust atomic types (not even AtomicU8) with atomic_{load|store}_per_byte_memcpy? (because from the programmer's perspective there is no way to tell which atomic granularity the internal implementation will choose).

If the second situation is the case, does this also imply that it could be UB if atomic_{load|store}_per_byte_memcpy is called from multiple threads simultaneously on overlapping memory regions with a different byte count or a different offset?

it's never allowed for any atomic byte copy implementation to copy more than 1 byte in a single instruction, or

That is definitely not the intent.

is (only) the internal (llvm?) implementation of atomic_{load|store}per_byte_memcpy allowed to copy larger-than-1-byte values on targets where this is legal + it is never allowed to mix any of the Rust atomic types (not even AtomicU8) with atomic{load|store}_per_byte_memcpy? (because from the programmer's perspective there is no way to tell which atomic granularity the internal implementation will choose).

Ah, good question. If we have two overlapping non-equal atomic-per-byte accesses we could run afoul of the x86 requirement to not mix differently-sized atomic accesses. Does C++ do anything here to prevent that?

A conforming implementation could use u32 for load and u64 for store.

That wouldn't be conforming if it causes UB on the x86 assembly level due to mixed-size concurrent accesses. (See above.)

I did't say x86, but in general this should be valid.

We  we are talking about x86 here currently, so if you mean something else you should clarify that you are not replying to the previous posts just above yours.

I know that the motivation for this feature is implementing seqlocks, but let me state another motivation: safe mmap.
Currently at least Linux allows modifying mapped files and reflects the modifications to program memory, even if the map is created with MAP_PRIVATE. This means that referring the mapped memory as &[u8] is clearly unsound. (Though fine, if modifications don't happen; but even if that's the intention, that's not something guaranteeable at the level of a programming language.) Accessing the memory with ptr::read_volatile or via UnsafeCell seems plausible, but while unlikely to cause problems in practice, the docs of both state that concurrent modification is UB.
I think that with the current memory model, only atomics can guarantee freedom from UB in the face of spurious modifications. (Another possibility seems to be allowing concurrent modifications with ptr::read_volatile and UnsafeCell, relaxing the memory model for accesses that are not attempting to communicate via the memory or trying to synchronize with any other accesses, but I'm not sure if that's possible or plausible.)
This API looks relevant for this use in the sense that the motivation for this mmap use case is avoiding UB; having performant accesses is also important but caring about tearing is not a relevant for many use cases.
I expressed recently my dissatisfaction with the current situation of mmap in Rust in Reddit, and I had a bunch of discussion: https://www.reddit.com/r/rust/comments/10u4anm/how_to_use_mmap_safely_in_rust/ I'm aware that many people who use mmap are either unaware of its soundness issues or aware of them, but forced to ignore them. I don't think using AtomicPerByte to express the mmapped memory safely would necessarily fix all of those issues, but at least it would be one step in a better direction.

I would be in favor of adding atomic volatile primitives so that volatile stuff can be done concurrently. LLVM supports this we just don't support it in Rust (yet?)

afaict representing a mmap via [AtomicU8] is valid

@programmerjake Ah should have mentioned that. Yes, I think all of the current numeric atomics are valid for that use case. This would just let the user to pick a custom type, while letting AtomicPerByte wrapping to provide the (lack of) guarantees.

However,  [u8; N] has the property that mixing the bytes of any two or more valid instances, yields a valid instance. [bool; N] also has that property. But [NonZeroU32; N] does not. For the types that have that property we could offer an API that skips the MaybeUninit.

That could mean we should use a new MaybeTeared<T> here, instead of MaybeUninit<T>. I suppose that's slightly more accurate, but I'm not sure if it's worth adding such a type.

After thinking about it a bit more, I'm going to try to see what this proposal looks like if we add a new MaybeTeared<T> and use that instead of using MaybeUninit<T>. I'm starting to think that might actually be better, making it clearer what the unsafety is about.

Since it is a property of a type, wouldn't this be an (unsafe) trait rather than a wrapper type?

MaybeTeared<T> would be the return type of AtomicPerByte<T>::load(), representing a value of type T that might have been torn. It'd have something like an unsafe .assume_not_teared() to convert it to a T.
For certain types such as [u8; N], it's always safe to call that function (although it might not result in the expected value of course). There could be a trait for that category of types, but that's a tricky to define usefully. Would it include types like u32 or f32 for which any teared value still results in a valid value, even though it's very unlikely it'd be a meaningful value? This gets us into 'safe transmute' territories, which I think falls outside the scope of this RFC for now.

note that Teared is generally considered incorrect when referring to the past sense of tear as in to rip up.
https://en.m.wiktionary.org/wiki/teared#Verb_2
you probably want tore or torn or tearing

I just realized that atomic memcpy would probably require x86 to define what happens with mixed-size atomics: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/mixed-size.20atomics.20and.20atomic.20memcpy/near/403111841

This question came up before but indeed has not been answered yet, I think.

I have vague memories of someone once mentioning in one of the numerous threads about this topic that they were approached by Intel engineers who claimed that this is fine on every current Intel hardware, but spec people are feeling nervous about committing to the public statement that it will stay fine on all future hardware, as they fear this could prevent future hardware optimizations.
So basically x86-TSO memory model history repeating itself: spec specifies a certain memory model, hardware actually follows a stronger memory model, software people would like to leverage useful properties of the stronger hardware memory model in their program, but hardware people first need to decide if they are ready to permanently close the door to the envisioned future hardware optimizations that led them to specify a weaker-than-necessary memory model in the first place.
Anyway, instead of trusting my faillible memory, maybe let me ping @joshtriplett in case they have more reliable memories or can in turn summon some former Intel colleague(s) to provide more authoritative material.

If the eventual conclusion is that mixed-size atomics are not fine, then it would indeed heavily constrain the implementation of the proposed atomic memcpy functionality.
On one hand, we would like implementations to use the most efficient hardware load and store operations, not juste byte loads and stores but at least native word loads and stores and ideally even SIMD loads and stores and more exotic load/stores like rep movs too, as long as the target range of memory addresses is large enough. So restricting ourselves to the moral equivalent of this...
struct AtomicMemcpyZone(Box<[AtomicU8]>);

...would be undesirable, and not an obvious improvement over the statu quo.
On the other hand, getting to the desired goal without hitting mixed-size atomics UB would mean something along the lines of the following...

Exposing, for each hardware, a hardware-specific largest memory access granularity (e.g. max-width SIMD load and store).
Conceptually slicing memory into aligned blocks of this granularity.
Stating that if two memory operations (not just memcpy, any atomic and non-atomic memory op counts) hit the same aligned block without hitting the same range of bytes within the block, and at least one of them is a memcpy, then it's instant UB for the program.

...and that would definitely be a very nasty memory model to commit to :(

Intel engineers who claimed that this is fine on every current Intel hardware

See: https://github.com/rust-lang/unsafe-code-guidelines/issues/345#issuecomment-1499421708

It's been a while. I've explored the option of having a MaybeTorn<T> type, but it seems next to impossible to integrate that ergonomically into Rust today. I think the best option is to continue with MaybeUninit<T>.
It is true that technically it should be safe to load a f32 from a AtomicPerByte<f32> (if it didn't have the ability to store uninit bytes), since every bit pattern is a valid f32, but it also seems like a big footgun. Except in rare cases for [u8; _] or [bool; _], it's almost certainly a mistake to continue with torn values.
Note that if we have this MaybeUninit-based AtomicPerByte API in the standard library, a crate in the ecosystem could use it to build an API on top of it that allows safe loading of torn values, encapsulating the unsafe blocks for types that can be "safely torn". Leaving that to a community crate sounds good enough to me.

The only thing left I'm still struggling with is the signature of the store method(s):
      pub fn store(&self, value: MaybeUninit<T>, ordering: Ordering);
// or
      pub fn store(&self, value: &MaybeUninit<T>, ordering: Ordering);
// or
      pub fn store(&self, value: T, ordering: Ordering);
// or
      pub fn store(&self, value: T, ordering: Ordering) where T: Copy;
// or
      pub fn store(&self, value: &T, ordering: Ordering);
// or
      pub fn store(&self, value: &T, ordering: Ordering) where T: Copy;

Or a combination of these (store and store_from).
Taking by value fits the most basic use case, but consuming the value can be annoying if you need to attempt a store multiple times. However, taking a by but can get weird for non-Copy/needs-drop types. Wrapping it in a MaybeUninit makes the Drop situation clearer, but taking that by reference can be annoying if you have a &T and need a &MaybeUninit<T> here. :/

Taking by value fits the most basic use case, but consuming the value can be annoying if you need to attempt a store multiple times.

I don't see a use case where you wouldn't have some sort of external synchronization that guarantees only 1 write is happening at a time, so this is less of a concern.
I think that store operations should only accept T instead of MaybeUninit<T>. In almost all use cases, users will want to store complete values.
Therefore I would recommend:

Removing load_from and store_to: these are redundant with load and store.
Changing store_from_slice to take &[T] instead of &[MaybeUninit<T>]. Most users will want the &[T] version and there are functions to convert between initialized and uninitialized slices.'
Removing the From<MaybeUninit<T>> impl. This is surprising and should be handled through an explicit constructor instead.

@Amanieu pointed out that this could be used to solve the problem of how to express shared memory in a way that is sound. (In particular, memory which is shared with external processes outside of Rust's visibility - separate OS processes, user land (if implementing a kernel), a kernel (if implementing a hypervisor), etc.). I'll refer to this as the "IPC use case" for brevity.
I think it'd be good to mention IPC explicitly in this RFC. It differs a bit from the existing use cases which are described. In particular, the existing use case assumes that you're trying to synchronize with other threads which are known to the Rust abstract machine. As a consequence, it needs to uphold whole-program correctness - the code emitted for a particular thread is tasked with not exhibiting UB on that thread but also not causing UB to be exhibited in other threads of the same process. It can also take advantage of the fact that the other threads are doing the same thing.
By contrast, the IPC use case is only concerned with preventing UB in a single thread, but it must do so in the face of arbitrary memory writes by the other process, possibly malicious ones.
It may be the case, as @Amanieu suggests, that the existing solution in this RFC is already sufficient. But IMO it'd be good to explicitly articulate that since it's not obvious (at least to me) that any solution to the stated problem would also be a solution the IPC problem.
Thanks for this RFC, btw! The shared memory use case is a thorn we've had in Fuchsia for years. It would be awesome to have a solution to it.

Isn’t it overkill for atomic IPC? You just need to synchronize amount of bytes you’re going to read/write and then plain volatile operations should be enough, because you already did the synchronization.

Isn’t it overkill for IPC? You just need to synchronize amount of bytes you’re going to read/write and then plain volatile operations should be enough, because you already did the synchronization.

It's more complicated than that unfortunately. Volatile is both too much and not enough.
It's too much because it forces the compiler to emit read and write instructions for every memory read and write, which prevents it from doing various optimizations such as coalescing reads, eliding writes that are performed multiple times, etc. That's not actually necessary for IPC. All you care about from a correctness standpoint is that all of your reads happen after any memory fence and that all of your writes happen before any memory fence (consistent w/ where those fences appear in source code).
It's not enough because volatile still assumes that no other threads are concurrently reading/writing the same memory. Using volatile to perform concurrent modifications to the same memory is UB (see the write_volatile docs). Now, if your IPC partner is behaving nicely, this isn't a problem since they'll only be writing to the memory before a memory fence, and then not touching it afterwards once you're reading from it. But if you don't trust your IPC partner (it's considered part of another security domain, it's a user space program and you're the kernel, etc), then you have to assume that your IPC partner might be writing to the memory concurrently. Thus, for your code to be sound in the face of arbitrary, possibly malicious behavior, it has to be sound in the face of arbitrary, concurrent memory writes.

"UB in a single thread" is unfortunately not really a thing -- UB is a property of the entire execution. So it's not entirely clear what exactly we could say here. Furthermore, it is already the case that it is generally okay to use atomics to communicate with non-Rust threads, this RFC "just" makes atomics more powerful, so atomic memcpy itself isn't really IPC-specific at all.

"UB in a single thread" is unfortunately not really a thing -- UB is a property of the entire execution. So it's not entirely clear what exactly we could say here. Furthermore, it is already the case that it is generally okay to use atomics to communicate with non-Rust threads...

How do we square the circle here? I'm imagining it's one of the following two options:

We don't have any way of formally modeling (in the AM) what happens in shared-memory IPC, but we know that the compiler doesn't do anything silly in practice, so we consider it to be fine
We know how to formally model shared-memory IPC, but we don't do it by talking about "UB in a single thread"

The reason I ask is that my naive understanding of your comment is just that this isn't something we could in principle model, but I assume there's more to it than that.

could we model it as processes at the other end of the IPC act as if they're a set of threads where every memory op is a relaxed atomic or a fence? I think this should work since we know on all reasonable ISAs that every load/store op acts as at least a set of relaxed atomics. that way, it's only UB in our process if we do something on our threads that would cause UB (e.g. non-atomic read that races with the other process's writes).

We know how to formally model shared-memory IPC, but we don't do it by talking about "UB in a single thread"

There's nothing special about memory shared between processes - I mean on linux threads are literally processes. Anything that can be used to synchronize between threads can also be used to synchronize between processes.

edit: there is a difference if you need your IPC communication method to be a security boundary - in that case you also need to consider that the other process may do anything to that memory at any time. If all you're doing is reading using AtomicPerByte then that should never cause UB in your process though.

Yeah, this is the use case - treating shared-memory IPC as a security boundary. IIUC that's what @RalfJung was responding to by saying that it's not well-defined since UB is a whole-program property. (I'm sure Ralf will push back and clarify that "not well-defined" is not an accurate characterization of what he said, but I've learned not to try to capture the subtleties 😛 )

When reasoning about security, I would argue there are other ways to prove that the boundary is solid:
If you can prove that for any malicious program M, there is a non-malicious program N that does the exact same shared memory operations at the hardware level, and that your program has no UB when combined with N, then you don't even need to consider M because they are literally the same program. For x86 this seems plausible since relaxed atomics generally compile down to no additional synchronization.
ie. the step from abstract machine to actual hardware is injective, and if two different programs in the abstract machine translate to the same actual program, then it's clearly indistinguishable which program was used because they are identical.

@Diggsey: Rust cannot be fully specified in terms of an abstract machine.  Rust is a systems programming language, and that means that it must also make guarantees about how the abstract machine is implemented in terms of the concrete machine that the hardware and OS actually implement.

Can we please move shared-memory IPC with atomics off of this RFC? As I said, this isn't specific to atomic-per-byte memcpy at all, so this is really the wrong place for that discussion.

What is the current state / blocker for progress on this RFC? Today I ran across another case where I needed this. It doesn't seem like much happened since end of summer.

@VorpalBlade This is still stuck on the details of the API. See https://github.com/rust-lang/rfcs/pull/3301#issuecomment-2206131327

Because that would just result in confusion and unexpected behaviour. E.g. it's unclear what reasonable behaviour would be for types that need to be dropped.

what if the only option was:
pub fn store(&self, value: &MaybeUninit<T>, ordering: Ordering);

and to make storing a copy more ergonomic, MaybeUninit gains:
impl<T> MaybeUninit<T> { // maybe have ?Sized bound? icr if that works with unions
    pub const fn from_ref(v: &T) -> &Self {
        // Safety: &Self can't be written to, so this works
        unsafe { &*(v as *const T as *const Self) }
    }
}

that way if you want to store a copy of some type, you just use: a.store(MaybeUninit::from_ref(&my_value), Ordering::Relaxed)
and my_value will still be dropped later. or you can just use a reference if that's all you have access to.
and if you want my_value to not be dropped, just write:
a.store(&MaybeUninit::new(my_value), Ordering::Relaxed)
do remember that atomic memcpy is not terribly common so being a bit more verbose is fine.

What about only providing the intrinsic as an unsafe raw pointer operation, and letting users write their own higher-level wrappers?

What about only providing the intrinsic as an unsafe raw pointer operation, and letting users write their own higher-level wrappers?

The intrinsic seems more fundamental to me than the API around it.


DOC: Removed uniform method from kmeans2 doc

kmeans2 documentation contains information about a uniform initialization method.  However, it was never implemented, so it should be removed for the time being until someone actually does, avoiding confusion as was evident in #5786.

@@            master   #5795   diff @@
======================================
  Files          235     235
  Stmts        43282   43347    +65
  Branches      8155    8164     +9
  Methods          0       0
======================================
+ Hit          33664   33723    +59
- Partial       2591    2594     +3
- Missed        7027    7030     +3

Review entire Coverage Diff as of fbd21ed

Powered by Codecov. Updated on successful CI builds.

Thanks @gfyoung


Ability to Create Configuration Profiles

Users want to be able to create configuration profiles for gimme-creds so they can quickly switch between role and account configurations to update their credentials.
gimme-aws-creds --profile <ProfileName>
[DEFAULT]
cerberus_url = https://cerberus.example.com
cred_profile = role
write_aws_creds = True
idp_entry_url = https://example.idp.com
aws_appname = App1
aws_rolename = Role1

[ProfileName]
cerberus_url = https://cerberus.example.com
cred_profile = role
write_aws_creds = True
idp_entry_url = https://example.idp.com
aws_appname = App2
aws_rolename = Role2

https://github.com/Nike-Inc/gimme-aws-creds/pull/12

this has been merged, closing.


[EXAMPLES] Post and share your examples here...

If you have examples, you would like to share with other users, you can post them here.
Examples will be available since version 8.0.0 from Visual Studio Code directly.

You can

write them directly in your post
submit a markdown document as attachment (example)
submit one or more example files as attachments
share the URLs to own repositories, that contains templates you maintain ... have a look at the official vs-deploy.json file to get to known what structure a repository file has

You also can use that issue if you have questions about (posting or requesting) examples, of course.
More information can be found at the wiki.

added first example Uglify files BEFORE deploy

added example Encode files with ionCube BEFORE deploy


[App]: UI summary differs from json summary

Current Behavior
When analysing my runs, there are some experiments without a summary element.
(at first, I through it was my code problem, like not waiting enough to sync before the program finish, SPOILER: it is not)

When studying the summary (raw) of a run from the web user interface (on the overview section), some "updated" elements are missing: ctrl+F of "mIoU" find 8 coincidences (after some seconds).
When studing the wandb-summary.json of the same run from the web user interface (on the files section), all elements are there: ctrl+F of "mIoU" find 12 coincidences.

I should like to post the summaries but, although the wandb-summary.json only weights 10,2 MB, the summary (raw) is not downloadable, copiable  or printable (because the webpage memory requirement). Then, I will share my links:
For the wandb-summary.json: https://wandb.ai/ignasi00/platgesBCN/runs/wlq59dbl/files
For the overview: https://wandb.ai/ignasi00/platgesBCN/runs/wlq59dbl/overview

By the way, how can each tab related to a project on wandb.ai require 2 GB of RAM?
By instance, this run is 50 epochs and the plain text json summary weights 10,2 MB which makes approx 0,5 GB for all the run, given that most of the data is not required at the same time, it is scary how it requires that much memory.
Expected Behavior
The web app should coincide with the summary JSON.

The web app should requiere less RAM
Steps To Reproduce

Get my script (wandb obtains the github from my project by itself)
Get some semantic segmentation dataset (prepared to work with my dataset objects, by instance ArgusNL)
Make the lists for the step 2 dataset.
Run my kfolds code with the step 3 lists
Check that the run ends succesfully with the full summary
Check that wandb web app do not found valid_mIoU on the run summary
Check that wandb do not have it on the summary raw of the overview section.
Check that wandb do have it on the wandb-summary.json of the files section.

Screenshots
No response
Environment
OS: Code run on Ubuntu (see the overview for details), web view on Windows 10 pro 64bits (although Google Chrome is a embedded OS)
Browsers: Google Chrome
Version: Google Chrome 99.0.4844.74 (Build oficial) (64 bits); wandb-0.12.11
Additional Context
No response

I've been having the same issue. I can see some metrics are logged in wandb-summary.json but they don't show up in the summary panel on the web page (or the "raw" summary). This is troubling especially when using Sweep, as it can't track the summary metric to choose the hyper params for the next run.
Is there any update on this issue?

I've been having the same issue. I can see some metrics are logged in wandb-summary.json but they don't show up in the summary panel on the web page (or the "raw" summary). This is troubling especially when using Sweep, as it can't track the summary metric to choose the hyper params for the next run.
Is there any update on this issue?

After some time without receiving any idea of how I could try to solve it, and knowing why the web page requiered that much memory, I decided to remove my project and start another (with the same name) from scratch with my code updated. I restarted the project because there was column names from previous runs that I do not use anymore. Hopefully it won't happen to me anymore :) (<- I wanted to post this here because it may affect the work of the ones that could solve it)
If you need faster help, maybe you should provide some examples of runs where this happens (if it was lunched on a git folder with origin on GitHub they will be able to read the exact code used on the run).
Answering your question: No, at least not that I know.
I hope your problem will be solved as soon as possible :)

Hi @bruzwen and @ignasi00, sorry for the delay on this. Could you both upgrade to W&B version 0.12.16 and then run wandb sync -project <name-of-project> <path/to/run/folder> and see if you still experience the issue after trying to sync the run again? Here are the docs for this.
@bruzwen could you share a link to the workspace as well?
Thank you,
Nate

@bruzwen were you able to try the above solution or do you have a link to the workspace where I can investigate this further?

Hi All, since we haven't heard back I'll go ahead and close this ticket on our side but feel to comment and tag me if you would like reopen this issue and we'll be happy to look into it more.
Thank you,
Nate

We are closing this ticket due to inactivity, please comment to reopen.


Fix typo in activated

1. Why is this change necessary?
Fixes a typo in the changelog.
2. What does this change do, exactly?
If fixes said typo :)
3. Describe each step to reproduce the issue or behaviour.
4. Please link to the relevant issues (if any).
5. Checklist

[ ] I have written tests and verified that they fail without my change
[x] I have squashed any insignificant commits
[] I have created a changelog file with all necessary information about my changes
[] I have written or adjusted the documentation according to my changes
[] This change has comments for package types, values, functions, and non-obvious lines of code
[x] I have read the contribution requirements and fulfil them.

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/NEXT-11060
Please use this issue to track the state of your pull request.

thanks for your contribution @soebbing  :+1: :tada: :blue_heart:


feat: Add a link for a recommented VSCode extension somewhere

Feature Request
Describe the Feature Request
There have been a few supply chain attacks lately in VSCode extensions, but a VSCode extension for syntax highlighting helps a lot. It would be nice for newcomers to know which ones are safe or recommended
Describe Preferred Solution
A link somewhere, maybe in the tutorial, maybe in resources, that points out which VSCode Cairo syntax highligting extension is safe or preferred.
If the feature request is approved, would you be willing to submit a PR?
(Help can be provided if you need assistance submitting a PR)
Yes

looks like it's already linked in the Cairo Book: https://book.cairo-lang.org/ch01-01-installation.html#installing-the-vscode-extension


[BUG] Asus Zenfone AR weird colors on camera surface

Hello, i`m using ue 4.18 build from arcore repository and this project + NVPACK and built on OpenGL ES 3.1 for asus zenfone ar. But camera color is weird and hue is blue for some reason (tracking works perfectly btw).
And why Vulcan one is crashing?

Thanks for the bug report.
Vulkan isn't supported in ARCore yet. I believe the color issue you saw is a bug on our side, the red and blue channel are swapped in the camera texture when building with GLES 3.1. We will try to resolve the issue in our next release. For now, you can either use GLES 2.0 or you can use a workaround that swap the red and blue channel in the shader in GoogleARCoreCameraImageBlitter.cpp. Simply changes line 129 to
"outColor.zyx = texture(cameraTexture, uvs).rgb;\n"


result on mini-imagenet dataset

Hi, thanks for the code.
I am trying test the code on the mini-imagenet dataset. However, my result is very bad, much worse than the reported ones. I wonder if you have tested the implementation on the dataset, and how about your results. If possible, could you possible upload your scripts of experimenting on the mini-imagenet dataset. Your help is much appreciated.

I have not tested the implementation on miniImageNet, sorry!


Fix deadlocks in rolling update tests

Fixes a few independent issues:

several test cases weren't unwatching groups, leaving extra goroutines running (benign, but untidy)
not preventing multiple writes to unbuffered healthChecksStarted, causing a deadlock
holding a lock in scaledGroup while calling plugin functions, opening possibility of a deadlock

Signed-off-by: Bill Farner<EMAIL_ADDRESS>

Current coverage is 71.37% (diff: 89.47%)

Merging #258 into master will not change coverage

@@             master       #258   diff @@
==========================================
  Files            19         19
  Lines          1233       1233
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits            880        880
  Misses          276        276
  Partials         77         77

Powered by Codecov. Last update 173ad78...0086175

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "debug-deadlock" git@github.com:wfarner/infrakit.git somewhere
$ cd somewhere
$ git rebase -i HEAD~2
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.


Send Gift:Add recipient in F&F-Associate a contact using Skip.

When we add recipient in F&F while sending gift and we have selected Skip contact then it is showing blank icon and also showing a message "F&F contact number missing".

https://xd.adobe.com/view/e8259038-6a8a-4b4f-b88f-780e311438a5-bd76/screen/50f3a2cc-f211-4431-bd6b-e98e028834d2/

Able to reproduce this issue in dev app v2.0.66(401)

When we select Skip contact to send the gift to the F&F, it is showing blank icon and also the QR code is constantly loading and the link is also showing that it is being created and yet we try to share that link then it shows "Null" message or shows "unable to share file".

fixed, tested on 2.0.75