THRIFT-5644: java to use jdk 17

java to use jdk 17, this is a second try after #2662

[x] Did you create an Apache Jira ticket?  (not required for trivial changes)
[x] If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?
[x] Did you squash your changes to a single commit?  (not required, but preferred)
[x] Did you do your best to avoid breaking changes?  If one was needed, did you label the Jira ticket with "Breaking-Change"?
[x] If your change does not involve any code, include [skip ci] anywhere in the commit message to free up build resources.

turns out that upgrading to java 17 won't solve the TSL runtime error during cross test

@fishy @ctubbsii i have updated the minimal JDK requirement to be 11, please take a look


Build(deps): Bump react-router-dom from 6.22.3 to 6.23.1 (#5774)

Pull request opened by the merge tool on behalf of #5774

Merged in 5bb6c8095f4c3ef92b663ea7c28dedbb1c517532


opencv_core: CUDA: check if CUDA_ARCH is defined before comparing it

Changed statements of type "#if CUDA_ARCH >= 200" to
"#if defined CUDA_ARCH && CUDA_ARCH >= 200" in order to
avoid warnings about CUDA_ARCH being undefined.

:+1:


sh: xdg-open: command not found | macOS

Describe the bug
At the end of the script, the user folder is deleted and the script proceeds to exit. Just after the exiting message, I get the error sh: xdg-open: command not found.
To Reproduce

Device connected via cable to Mac and USB debugging enabled
Python requirements installed and dependencies installed
Run python3 wa_kdbe.py
Successfully uninstall WhatsApp, install legacy, and reinstall original WhatsApp.
See error when exiting

Screenshots

Desktop:

OS: macOS Big Sur

Smartphone:

Device: Motorola G4 Plus
Android Nougat
Version 7.0

I made it to automatically open that folder so you don't have to go through file system. That works with all linux system. How can you open a folder in file explorer using terminal on mac?

The open command opens a file (or a directory or URL), just as if you had double-clicked the file's icon. If no application name is specified, the default application as determined via LaunchServices is used to open the specified files.
I'll modify script accordingly.


'Access violation writing location' crash in IL2CPP build

We are working on a game in Unity and are using the deformer plugin in certain parts of the game. As soon as an action that uses the plugin is triggered, the game crashes with an "Unhandled exception : access violation writing location" error. This happens only in IL2CPP builds. Mono builds work perfectly fine without any crashes. When I debug the crash.dmp file, the detailed error message that I get is "Unhandled exception at 0x00007FFC38D71003 (GameAssembly.dll) in crash.dmp: 0xC0000005: Access violation writing location 0x0000000000000000. occurred". The crash occurs in the "ResetNormalsJob - Execute" method. I am attaching the crash.dmp file and error log as well as screenshots of the call stack and crash location below.
CrashInfo.zip

Hey so sorry for the delay - I hope you've been able to find a workaround!
From what I can tell, that seems like an issue with the IL2CPP compiler. I'm actually not sure if there's anything I can do on my end. There's a small chance the problem is with the burst compiler. To test, you could comment out the BurstCompile attribute on the ResetNormalsJob, but the job is so simple it suggests to me that the problem is external and warrants a bug report to Unity.


Awesome vim does not support C++11 syntax

The following errors would be falsely reported in vim opening C++ code files:

vector nums = {1, 2};
non-aggregate type 'vector' cannot be initialized with an initializer list

vector<vector> matrix;
a space is required between consecutive right angle brackets (use '> >')

I am not a C++ programmer. You are welcome to provide a pull request with proper support 👍


Add raw pointer access method to PoolVector

I'm working with procedural generation in my project and I need to create hundreds of meshes and their respective normals, vertices, indices and for each level of detail.
I'd like to be able to use multithreading for the generation of the Array with the data of the mesh but the API requires the menipulation of PoolVector3Array and other types based on PoolVector in the engine so I'm forced to have a sequential generation of the meshes.
A method to have access to the raw pointer of the memory would be ideal. Maybe it could be called get_ptr_unsafe to make it clear it is not safe to use it for every usecase because the lack of thread safety and the posible invalidation of the pointer after a realloc.
In my case the mutex locking means a noticeably slower generation of the worlds and every mesh uses different PoolVectors so there is no danger of concurrent access.
The new method doesn't make sense in GDScript because you already sacrifice performance using an interpreted language, this is more oriented to GDNative languages.

They exist since GDNative 1.0 and I'm already using them.
They don't solve my problem as Write is useful tu prevent constant locking while accessing the PoolVector. When you create a Write, the locking happens only once and the data is unlocked when the Write goes out of scope.

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!
Note: This proposal may be irrelevant now with the new vector class in 4.0. You'll have to investigate before opening a proposal.


Webchat not rendering a conversation when the same conversation is being rendered multiple times

Is it an issue related to Adaptive Cards?

[ ] Yes, this is an Adaptive Card issue but it is specific to Web Chat.

Do you have any screenshots?

What version of Web Chat are you using?
Latest production
Which distribution are you using Web Chat from?
Bundle (webchat.js)
Which hosting environment does this issue primarily affect?
Web apps
Which browsers and platforms do the issue happened?
Browser: Chrome (latest)
Which area does this issue affect?
Others/unrelated
Is this an accessibility issue?

[ ] Yes, this is an accessibility issue.

Please describe the bug

Start a conversation with a bot by making a POST to https://directline.botframework.com/v3/directline/conversations
Use that token to render the webchat 4 or more times in the same page:
var store = window.WebChat.createStore({}, ({ dispatch }) => (next) => (action) => {
//console.log(action);
handleWebChatAction(action, dispatch);
return next(action);
});
window.WebChat.renderWebChat(
{
directLine: window.WebChat.createDirectLine({
token: token,
}),
styleSet: getBotStyleSet(),
sendTypingIndicator: true,
store,
styleOptions: getBotStyleOptions(),
},
document.getElementById(ctrl.widgetId + "-container")
);`
Most of the times 3 of the 4 webchat instances will load successfully, the fourth will not (see attachment).
Sometimes the 4 of them load as expected, and sometimes more than 1 of them fail to load
Failing to load means that the webchat component does not render anything
I've compared all events generated by directline and there's no difference between the one where the widget fails to load and the others. In fact, all of them at some point generate DIRECT_LINE/UPDATE_CONNECTION_STATUS with status = 2 (online)

Do you see any errors in console log?
No
How to reproduce the issue?

Start a conversation with a bot by making a POST to https://directline.botframework.com/v3/directline/conversations
Use that token to render the webchat 4 or more times in the same page:
 var store = window.WebChat.createStore({}, ({ dispatch }) => (next) => (action) => {                   //console.log(action);                   handleWebChatAction(action, dispatch);                   return next(action);               });               window.WebChat.renderWebChat(                   {                       directLine: window.WebChat.createDirectLine({                           token: token,                       }),                       styleSet: getBotStyleSet(),                       sendTypingIndicator: true,                       store,                       styleOptions: getBotStyleOptions(),                   },                   document.getElementById(ctrl.widgetId + "-container")               );

What is the expected and actual behavior?
Expected:
The 4 instances of the chat in the page should load (or there should be some indicator that it's failed so that the developer can handle it)
Actual:
Not all instances load correctly and there's no indication to handle it
Adaptive Card JSON
No response
Additional context
No response

@antoniobriones - Opening multiple instances of the same Web Chat conversation is not a supported scenario. Web Chat is intended for use in single 1:1 conversation instance between a bot and a user. As I note in this related post, Web Chat can be configured to persist a conversation across multiple web pages. However, there should still only ever be one instance of a Web Chat conversation running at a time.
There is no error message for this because you are attempting to use Web Chat in a manner outside of its design.

@stevkan thanks, we´ll implement a mechanism to block the same conversation from being rendered concurrently.


[NEW] add osx shortcut to enter full screen

[NEW] Add shortcut to enter full screen on osx.
Add new menu item to the view menu to enter full screen by menu an keyboard shortcut.
(Default option in all osx applications)

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Tobi seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Hi @HappyTobi why did you close this PR?

I had deleted the forked repo. I think thats the reason.


I saw this in the HRF newsletter today and was like, "hey, "Awesome!"…

… But the bitcoin symbol is confusing, so I thought I, "maybe now is the time to finally test out my contributing skills." All this to say that I took out the bitcoin symbol and wrote the word sats for unit accuracy sake.
I also uploaded a sat png in case someone can figure out how to integrate that. I was having trouble with the program wanting everything to be a string and I've got to get to work soon, so I just changed to the word sats for time's sake.
I'm so sorry if I'm doing this wrong. This is my first attempt at PR and I tried to pick something easy and obvious so please ignore if this is a waste of time.

@ttooccooll thanks for the PR! You're not doing anything wrong here, but we made the decision to use the bitcoin B to represent sats because it makes more sense for users that don't know what sats are.
The only feedback I have for you is to open an issue first so you don't implement something that won't be merged.
 If you want to try your hand at some more PRs let me know and I'll try to find you some good first issues.

Hey Damian!
Thanks for getting at me about this! Yeah, I'd love any opportunity to
contribute. I really don't understand the process that well, but if there's
some easy first issue I could do, I'd love to take a stab at it.
Thanks!
Jason
http://branscumtunes.com
614-580-9127
https://jasonbranscum.bandcamp.com
On Wed, Oct 30, 2024 at 9:02 AM Damian @.***> wrote:

@ttooccooll https://github.com/ttooccooll thanks for the PR! You're not
doing anything wrong here, but we made the decision to use the bitcoin B to
represent sats because it makes more sense for users that don't know what
sats are.
The only feedback I have for you is to open an issue first so you don't
implement something that won't be merged.
 If
you want to try your hand at some more PRs let me know and I'll try to find
you some good first issues.
—
Reply to this email directly, view it on GitHub
https://github.com/MakePrisms/boardwalkcash/pull/113#issuecomment-2447073166,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AYKSGQWJVDNSMLBFEVW5EY3Z6DKEXAVCNFSM6AAAAABQEGEDKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBXGA3TGMJWGY
.
You are receiving this because you were mentioned.Message ID:
@.***>

@ttooccooll are you on discord?

Yeah, I'm just jasonb on there. I'll send you a message.
Thanks!
Jason
http://branscumtunes.com
614-580-9127
https://jasonbranscum.bandcamp.com
On Mon, Nov 4, 2024 at 5:08 AM Damian @.***> wrote:

@ttooccooll https://github.com/ttooccooll are you on discord?
—
Reply to this email directly, view it on GitHub
https://github.com/MakePrisms/boardwalkcash/pull/113#issuecomment-2454284749,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AYKSGQQRA3S4473YPPYPPE3Z642RFAVCNFSM6AAAAABQEGEDKSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJUGI4DINZUHE
.
You are receiving this because you were mentioned.Message ID:
@.***>


Auto format and lint via ruff

https://github.com/astral-sh/ruff

fast
uses black internally for formatting

done - auto via script
xx vc settings
.

done


fix(src): Parse correct binary name from repo url.

What does this do / why do we need it?
Final binaries are named wrong
How this PR fixes the problem?
Correctly parse the name of the binary
Check lists

[ ] Test passed
[ ] Coding style (indentation, etc)

Additional Comments (if any)
{Please write here}
Which issue(s) does this PR fix?
fixes #34

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 1 (0.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 52.448%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

internal/app/install.go
0
1
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
150

Relevant Lines:
286

💛  - Coveralls


License?

Hi there, thank you for the excellent work! For clarity, could you add a software license to this repo?

Thanks for your interest! We added Apache license.


skip duplicate entities that dont end in a semicolon

https://developer.mozilla.org/en-US/docs/Glossary/Entity
https://html.spec.whatwg.org/multipage/named-characters.html#named-character-references
adding a preference for the semicolon version is safer and more in-spec with the non-semicolon versions only existing on some for historical reasons

I don't concur, and this change doesn't represent "adding a preference"; it breaks code that expects this library to provide unopinionated access to the spec data. The specification explicitly lists the variants without semicolon, and so they are included.
If you don't want to allow them in your application, ensure that your parameter ends in a semicolon before calling lookup. Less than 5% of entities are excluded by this criterion, so I don't think storage is a concern either.


[Colour accuracy issue] doom-dark+ (vscode) theme too vibrant?

In the screenshot below (Visual Studio Code left, Emacs right), we can see that the colours in Emacs are more vibrant than those in Visual Studio Code (use a colour-hex-detector if you find the differences too small), despite supposedly using the same theme.
The vibrancy includes the green comments, the blue keywords and yellow functions etc. As if there has been a vibrancy filter that was masked over my Emacs interface and the contrast was tuned higher.
@ema2159 Hi Emmanuel! I believe you were the original author of this port -- how did you fetch the official colours from VSCode?
On second thought, it could potentially be the problem in how an 'electron' app renders the same colours though -- in which case it's not an issue of doom-themes at all.

That's a pretty good question. I would need to look further into it. As I remember, I got the colors from here: https://github.com/microsoft/vscode/blob/master/extensions/theme-defaults/themes/dark_plus.json
Not only that file but some others inside that repo.
All the colors seem right, except for the comments that seem a little bit off. I'll try to check what's going on

Thanks! For your reference, I'm on macOS Catalina using the default Colour LCD display profile.

@ema2159 I came across the thread, might be of help for those interested: https://github.com/microsoft/vscode/issues/65816

@ianpan870102 interesting, so it was Windows's VS Code fault all along?

The colour rendering issue has been found on macOS, Windows, and Linux platforms -- I think you meant "Microsoft's" VSCode fault right? That'd be my best guess too, since I double checked the colours defined in VSCode's theme and they are indeed not the right colours if I detect it system-wide. This doom-theme port has chosen the official colours of VSCode.
My port of vscode-emacs theme (https://github.com/ianpan870102/vscode-dark-plus-emacs-theme) took the approach of hand-picking every colour using a colour picker directly from the UI, so you could say that it "looks" the most like VSCode, but it won't be the official colours -- since VSCode can't display their official colours either.
Hope this makes sense.

To conclude, the doom-theme "too vibrant" issue is actually how VSCode should look like.

@ianpan870102 that's cool. So it seems VS Code has problems rendering colors properly who would've thought. Should we close the issue then?

Sure, I'll close this one.

@ema2159 Hi there! So the other day I was having a look in Microsoft's vscode github repo and extracted these colours:
;; Official colors from Microsoft's Visual Studio Code:
;; "#DCDCAA"
;; "#4EC9B0"
;; "#C586C0"
;; "#9CDCFE"
;; "#51B6C4",
;; "#CE9178"
;; "#d16969"
;; "#d7ba7d"
;; "#569cd6"
;; "#C8C8C8"
;; "#d4d4d4"
;; "#b5cea8"
;; "#f44747"
;; "#6A9955"

It seems that they have "updated" their color scheme, because the red and magenta are consistent with the ones in doom-dark+, but the others (blue, teal, yellow, etc.) are not.


lxcfs: 2.0.4 -> unstable-2017-03-02

Motivation for this change
The current version segfaults, when removing cgroups concurrently. The unstable version has been tested for 5 days without incident in a 40 container setup.
Things done

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

Yes. I will do that.

back ported in https://github.com/NixOS/nixpkgs/commit/64c6df5e244ad2c0f16dc0378f33e897e908c9e4


'cargo test --features http2' fails with many "associated function is never used"

Version
Current git master
Platform
Linux 5.16.0-4-amd64 #1 SMP PREEMPT Debian 5.16.12-1 (2022-03-08) x86_64 GNU/Linux
Description
Running cargo test --features http2 fails with a bunch of errors:
error: unused import: `self::never::Never`
  --> src/common/mod.rs:32:16
   |
32 | pub(crate) use self::never::Never;
   |                ^^^^^^^^^^^^^^^^^^
   |
note: the lint level is defined here
  --> src/lib.rs:5:24
   |
5  | #![cfg_attr(test, deny(warnings))]
   |                        ^^^^^^^^
   = note: `#[deny(unused_imports)]` implied by `#[deny(warnings)]`

error: variant is never constructed: `Body`
  --> src/error.rs:52:5
   |
52 |     Body,
   |     ^^^^
   |
note: the lint level is defined here
  --> src/lib.rs:5:24
   |
5  | #![cfg_attr(test, deny(warnings))]
   |                        ^^^^^^^^
   = note: `#[deny(dead_code)]` implied by `#[deny(warnings)]`
note: `Kind` has a derived impl for the trait `Debug`, but this is intentionally ignored during dead code analysis
  --> src/error.rs:20:10
   |
20 | #[derive(Debug)]
   |          ^^^^^
   = note: this error originates in the derive macro `Debug` (in Nightly builds, run with -Z macro-backtrace for more info)

error: variant is never constructed: `BodyWrite`
  --> src/error.rs:55:5
   |
55 |     BodyWrite,
   |     ^^^^^^^^^
   |
note: `Kind` has a derived impl for the trait `Debug`, but this is intentionally ignored during dead code analysis
  --> src/error.rs:20:10
   |
20 | #[derive(Debug)]
   |          ^^^^^
   = note: this error originates in the derive macro `Debug` (in Nightly builds, run with -Z macro-backtrace for more info)

error: associated function is never used: `new_body`
   --> src/error.rs:298:19
    |
298 |     pub(super) fn new_body<E: Into<Cause>>(cause: E) -> Error {
    |                   ^^^^^^^^

error: associated function is never used: `new_body_write`
   --> src/error.rs:303:19
    |
303 |     pub(super) fn new_body_write<E: Into<Cause>>(cause: E) -> Error {
    |                   ^^^^^^^^^^^^^^

error: associated function is never used: `from_inner`
  --> src/ext.rs:34:19
   |
34 |     pub(crate) fn from_inner(inner: h2::ext::Protocol) -> Self {
   |                   ^^^^^^^^^^

error: associated function is never used: `into_inner`
  --> src/ext.rs:38:19
   |
38 |     pub(crate) fn into_inner(self) -> h2::ext::Protocol {
   |                   ^^^^^^^^^^

error: struct is never constructed: `Pending`
   --> src/upgrade.rs:109:19
    |
109 | pub(super) struct Pending {
    |                   ^^^^^^^

error: function is never used: `pending`
   --> src/upgrade.rs:114:15
    |
114 | pub(super) fn pending() -> (Pending, OnUpgrade) {
    |               ^^^^^^^

error: associated function is never used: `fulfill`
   --> src/upgrade.rs:235:19
    |
235 |     pub(super) fn fulfill(self, upgraded: Upgraded) {
    |                   ^^^^^^^

error: variant is never constructed: `Default`
  --> src/common/exec.rs:34:5
   |
34 |     Default,
   |     ^^^^^^^
   |
note: `Exec` has a derived impl for the trait `Clone`, but this is intentionally ignored during dead code analysis
  --> src/common/exec.rs:32:10
   |
32 | #[derive(Clone)]
   |          ^^^^^
   = note: this error originates in the derive macro `Clone` (in Nightly builds, run with -Z macro-backtrace for more info)

error: variant is never constructed: `Executor`
  --> src/common/exec.rs:35:5
   |
35 |     Executor(Arc<dyn Executor<BoxSendFuture> + Send + Sync>),
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
note: `Exec` has a derived impl for the trait `Clone`, but this is intentionally ignored during dead code analysis
  --> src/common/exec.rs:32:10
   |
32 | #[derive(Clone)]
   |          ^^^^^
   = note: this error originates in the derive macro `Clone` (in Nightly builds, run with -Z macro-backtrace for more info)

error: associated function is never used: `execute`
  --> src/common/exec.rs:41:19
   |
41 |     pub(crate) fn execute<F>(&self, fut: F)
   |                   ^^^^^^^

error: associated function is never used: `extra_mut`
   --> src/body/body.rs:237:8
    |
237 |     fn extra_mut(&mut self) -> &mut Extra {
    |        ^^^^^^^^^

error: associated function is never used: `is_exact`
  --> src/body/length.rs:78:19
   |
78 |     pub(crate) fn is_exact(&self) -> bool {
   |                   ^^^^^^^^

error: could not compile `hyper` due to 15 previous errors

Looks like the #![cfg_attr(test, deny(warnings))] is a bit overeager here?

Some other combinations of features fail in harder to fix ways:
$ cargo test --features http2,client,server
error[E0599]: no method named `kind` found for struct `error::Error` in the current scope
   --> src/client/dispatch.rs:320:22
    |
320 |         match (err.0.kind(), err.1) {
    |                      ^^^^ method not found in `error::Error`
    |
   ::: src/error.rs:11:1
    |
11  | pub struct Error {
    | ---------------- method `kind` not found for this

$ cargo test --features http1,http2,client,server
error[E0560]: struct `h1::ParseContext<'_>` has no field named `h1_header_read_timeout`
   --> src/proto/h1/io.rs:730:17
    |
730 |                 h1_header_read_timeout: None,
    |                 ^^^^^^^^^^^^^^^^^^^^^^ `h1::ParseContext<'_>` does not have this field
    |
    = note: available fields are: `cached_headers`, `req_method`, `h1_parser_config`, `preserve_header_case`, `h09_responses`

error[E0560]: struct `h1::ParseContext<'_>` has no field named `h1_header_read_timeout_fut`
   --> src/proto/h1/io.rs:731:17
    |
731 |                 h1_header_read_timeout_fut: &mut None,
    |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^ `h1::ParseContext<'_>` does not have this field
    |
    = note: available fields are: `cached_headers`, `req_method`, `h1_parser_config`, `preserve_header_case`, `h09_responses`

[and many more]

Fixed by https://github.com/hyperium/hyper/pull/2795


Inline assembly

A redesigned asm! macro, with a path to stabilization.
Rendered
Thanks to everyone involved in the inline asm project group for their feedback which helped make this RFC possible!

 I think I inferred this from RFC text, but I am not sure my understanding is correct (perhaps this is a content for the future user-level docs?).
This is how I think asm works, is this right ballpark?
So, what we fundamentally hope to achieve here is an ability to insert arbitrary instruction sequences into the generated machine code. I naively expect the solution along the lines of D DSL: we invent a syntax for specifying arbitrary instructions, and compiler produces the binary for us. From this point of view, specifying assembly as a string literal seems very odd.
Now, the reason why this doesn't work too well is that there are numerous fundamentally different CPU architectures (which are themselves moving targets), with fundamentally different institutions, and it is unreasonable to expect that the compiler would fully support all of them. Instead, we rely on the fact that each architecture has a dedicated external tool, an assembler, which is capable of turning assembler-specific syntax into machine code. Compiler more or less invokes the assembler as a black box. Compiler does not understand what mov in ""mov {}, 5" means. The only thing compiler needs to know is the interface. That's why the RFC rigorously specifies the grammar for register specification and flags, but doesn't actually tell us, what can be written between "".
However (and I think this is not spelled out explicitly, or have I just missed it?) we also ship a specific assembler (namely llvm assembler), with specific syntax, which rustc will use for asm! calls. So, to learn what I can actually put into "", I will need to read the docs of this assembler to understand the syntax, and then maybe the docs for the specific CPU/instruction set, to learn which instructions are available and provide which semantics.
Is this all at least somewhat reasonable? :)

My understanding of past inline asm discussions is that the biggest issue was always the stability and portability implications of supporting inline asm at all (and to a lesser extent of exposing LLVM's asm syntax, which thankfully is no longer being proposed). Unless the Rust teams think these issues are now self-evident, we should probably make some explicit statements about them in the RFC.
Specifically, I think all of the following are intended to be true:

The syntax of an asm!() invocation is part of the Rust language grammar, and would go into a future Rust spec, so all Rust compilers must be able to parse it. I'm not sure if this has any practical consequences today, but presumably we want to leave the door open for doing something like #[cfg(backend = "llvm")] where an asm!() might need to get parsed just so it can be discarded successfully.
No Rust compiler is required to "actually implement" asm!(), because asm!()'s semantics are inherently target-specific and cannot be specified terms of any Rust Abstract Machine. Also, implementing asm!() for one target/backend combination does not require implementing it for any other target/backend combinations. Every toolchain gets to choose exactly how much inline asm it does or doesn't provide, independently of rustc, and still be a spec-compliant Rust compiler.
rustc will commit to providing asm!() on the architectures listed in this RFC for as long as LLVM provides any sort of inline asm feature that makes this feasible to implement. So if LLVM makes backwards incompatible changes to its inline asm, rustc will be committed to adapt to those changes as part of its regular LLVM upgrades.
But because LLVM has no stability promise on its inline asm (that hasn't changed, right?), and in theory could simply delete that feature without our consent, rustc cannot unconditionally guarantee stability for inline asm the way it can for most other language features (unless we do something "crazy" like fork LLVM or make Cranelift part of rustc).
At this time, we are not making any guarantees about alternate backends for rustc. So rustc is allowed to add backends that have no inline asm support. And if Cranelift ever provides inline asm, making stable versions of rustc use it would constitute an additional stability commitment (i.e. it'd need an RFC or an FCP on a PR).

If I am correct and all of these are intended, I think at least some of them should be made explicit in the RFC. Especially that part in bold.
Also, should we consider how this interacts with the target tier policy? At first blush, I would think any changes to inline asm support on tier 3 targets require no special approval, but any changes to inline asm support on tier 1 and 2 targets probably should get... I dunno, compiler team approval? And be included in release notes?

@matklad Yes, that sounds about right.

But because LLVM has no stability promise on its inline asm (that hasn't changed, right?), and in theory could simply delete that feature without our consent, rustc cannot unconditionally guarantee stability for inline asm the way it can for most other language features (unless we do something "crazy" like fork LLVM or make Cranelift part of rustc).

In theory, yes, I think, but in practice, I would be pretty shocked if any mature C compiler (e.g. clang) dropped support for inline assembly, and since LLVM is the backend for clang, it's hard to imagine LLVM dropping support altogether.
That said, I'm not sure how stable the LLVM asm interface is. I haven't seen it change in the last few years though...

In theory, yes, I think, but in practice, I would be pretty shocked if any mature C compiler (e.g. clang) dropped support for inline assembly, and since LLVM is the backend for clang, it's hard to imagine LLVM dropping support altogether.
That said, I'm not sure how stable the LLVM asm interface is. I haven't seen it change in the last few years though...

I completely agree that it's "stable in practice", but since this has always been the thing explicitly cited by the lang team in past inline asm discussions to answer "why isn't inline asm on stable yet?", it seems like something we need an official statement on.
I'm hoping the answer is that they were specifically concerned about LLVM changing their inline asm syntax (because independently specifying our own syntax completely solves that), or about muddying the messaging on Rust's stability promise too close to 1.0 (which I'd assume is no longer a concern), but I just don't know for sure.

* The syntax of an `asm!()` invocation is part of the Rust language grammar, and would go into a future Rust spec, so all Rust compilers must be able to parse it. I'm not sure if this has any practical consequences today, but presumably we want to leave the door open for doing something like `#[cfg(backend = "llvm")]` where an `asm!()` might need to get parsed just so it can be discarded successfully.

* No Rust compiler is _required_ to "actually implement" `asm!()`, because `asm!()`'s semantics are inherently target-specific and cannot be specified terms of any Rust Abstract Machine. Also, implementing `asm!()` for one target/backend combination does not require implementing it for any other target/backend combinations. Every toolchain gets to choose exactly how much inline asm it does or doesn't provide, independently of rustc, and still be a spec-compliant Rust compiler.

* At this time, we are not making any guarantees about alternate backends for rustc. So rustc is allowed to add backends that have no inline asm support. And if Cranelift ever provides inline asm, making stable versions of rustc use it would constitute an additional stability commitment (i.e. it'd need an RFC or an FCP on a PR).

The intent is that all backends will supports asm!() in some form. If the backend doesn't support inline assembly natively then it can fall back to invoking an external assembler and generate an out-of-line call to the compiled asm blob. See the "Difficulty of support" section in the RFC for an example of how this would work.

* rustc will commit to providing `asm!()` on the architectures listed in this RFC for as long as LLVM provides any sort of inline asm feature that makes this feasible to implement. So if LLVM makes backwards incompatible changes to its inline asm, rustc will be committed to adapt to those changes as part of its regular LLVM upgrades.

* But because LLVM has no stability promise on its inline asm (that hasn't changed, right?), and in theory could simply delete that feature without our consent, **rustc cannot unconditionally guarantee stability for inline asm** the way it can for most other language features (unless we do something "crazy" like fork LLVM or make Cranelift part of rustc). Or does this non-stability come from the system assemblers, and LLVM is just a middleman?

There are two distinct parts to LLVM's inline assembly support:

The first part is the constraint specification, which is the syntax that LLVM uses to specify operands in the asm code. AFAIK this isn't stable, but this RFC does not expose any of this directly, so this is fine.
The second part is how the final asm string is interpreted, after all the string substitution to insert register names is completed. This is done by LLVM's integrated assembler, which implements the GNU assembler syntax (e.g. .section directive). We do expose this directly, but this is fine since non-LLVM backends can use an external GNU assembler to parse the generated asm code.

Finally, LLVM doesn't exist in a vacuum.  Once Rust gets stable inline assembly support, LLVM will have a strong incentive to keep this support working correctly.

I’m a little surprised this is already being RFCed.  I was expecting we’d come up with a prototype implementation as a procedural macro first, within the working group.  This could serve two purposes:

If it supported transforming asm! to external assembly, it would serve as proof that that transformation is possible, settling the controversy over Cranelift.  It could also serve as a basis for the actual implementation of that in rustc.
It would let us get hands-on experience with what the new syntax feels like to use, and iterate on it if desired.

...Well, I say “we”, but I haven’t been contributing other than responding in some GitHub threads.  I really appreciate the energy investment in moving this forward!  I just think it might be good to start on that before finalizing the design… though I guess that can still happen before stabilization.

I’m a little surprised this is already being RFCed. I was expecting we’d come up with a prototype implementation as a procedural macro first, within the working group.

Unfortunately we can't implement this with just a proc macro that wraps the existing asm! implementation because we need type information for validation and to emit the correct template modifiers for LLVM.

That could be done by parsing the assembly code to validate it (which may still be tricky but is not nearly as tricky as actually implementing an assembler)

If you want to parse the entire assembly syntax, I'd say it's almost equally tricky.
If you just want to whitelist directives, sure.

On January 30, 2020 5:14:48 PM PST, Jonathan Behrens<EMAIL_ADDRESS>wrote:

The inline assembly I've seen in various projects makes extensive use
of directives. A quick and rough search of the inline assembly in the
Linux kernel turned up use of at least the following directives:
.section, .subsection, .previous, .byte, .long, .word, .align, .balign,
.insn, .literal_position, .global/.globl, .set, .even, and probably
more that I managed to miss.

I'd personally feel much better if the RFC/Rust's documentation
included a list like this of the allowed assembly directives, and
ideally statements of what they do and what conditions must be upheld
to prevent them from triggering implementation/undefined behavior. It
wouldn't even be necessary to have the compiler detect violations
(other invariants in the RFC already can't be checked by rustc).
Conceivably this could be as simple as making a pass through the GNU
Assembler
documentation
and making a verdict for each.

This doesn't seem unreasonable to be, as long as rustc doesn't actually try to parse the assembly string.
I'd be happy to compile such a list.

Replying to @RalfJung outside of the code review so GitHub doesn't hide it in the middle of the comment thread.

Breakpoints can be set anywhere, not just in asm blocks, and the Rust spec just has nothing to say about what you will observe then.

It normally has nothing to say.  I suggest that setting breakpoints specifically at asm blocks would have well-defined results, precisely because...

This is peeking into the mapping between the Abstract Machine and its implementation on actual hardware, and I don't think we want to specify this.

...specifying how that mapping "syncs up" at specific points is the only way to adequately specify inline assembly or FFI.  After all, an ABI is a protocol: you put your arguments here, put your return address there, jump here, receive your return value there.  If Rust doesn't promise to abide by the protocol, then it's tantamount to saying that all FFI is undefined behavior.  If it does promise to abide by the protocol, then that includes being prepared to tolerate all the things the protocol allows the other side to do.

In that case we are in strong disagreement. To me this kind of treatment of UB looks extremely fragile and error prone and naive.

I agree that it's fragile and error-prone, and sometimes naive.  It's very easy to argue that 'this (asm block, black_box call, etc.) prevents the compiler from realizing X', when in fact there is some loophole that allows it to realize X anyway.  As a random example, if you have a benchmark function that takes an input value, using black_box:
my_benchmark(black_box(42))

would normally prevent the compiler from constant-folding the benchmark.  But the compiler is technically allowed to guess at the value, replacing it with
let input = black_box(42);
if input == 42 {
    my_benchmark(42)
} else {
    my_benchmark(input)
}

and then constant-folding my_benchmark(42).  Executing the benchmark would still involve a conditional branch (it coudn't constant-fold input == 42), but no more computation than that.
More generally, "out-of-thin-air" guesses break quite a number of things that would otherwise cheat UB, but there's no easy way to ban them, since they can appear as a result of other optimizations.  Too bad.
However, there are a few things they don't break.

When arguing for the UB-freedom of some code, you don't get to say that "yes this code has UB but it is okay because the compiler cannot see it", that's just not how UB works.

I agree.  What you say is that the conversion of high-level state to low-level state (when entering the asm! block, or FFI call) and back (when exiting it) is not lossless, and as a result, some operations that would have been UB before the round-trip are no longer UB.  In particular:

Do you have a concrete example of the kind of "UB cheating" that you think ought to be legal?

On targets where the low-level state does not contain a concept of undefined bytes (which is currently all of them), asm!("", in(reg) &mut val) implicitly freezes everything the assembly block would be allowed to write to: val itself, globals exposed to FFI, and everything transitively reachable through those things (for which a write would not violate Stacked Borrows or otherwise be UB).  That's not a particularly sane way to manage freezing (and freezing is not even that useful).  But it is a necessary consequence of the fact that the code cannot determine whether or not the assembly wrote to those locations, not even dynamically – except by analyzing the asm block itself, which I believe should be illegal (in order to allow code patching, among other reasons), or by using OS calls to set a hardware breakpoint, which is just way out of scope of what compiler-generated code should be doing.

On targets where the low-level state does not contain a concept of undefined bytes (which is currently all of them)

Itanium had NaT (Not a Thing) as value of a register.

Replying to @RalfJung outside of the code review so GitHub doesn't hide it in the middle of the comment thread.

OTOH, now it gets hidden in the middle of the main thread, and mixed with other concerns... GH just isn't great for sprawling discussions such as this. :/

...specifying how that mapping "syncs up" at specific points is the only way to adequately specify inline assembly or FFI. After all, an ABI is a protocol: you put your arguments here, put your return address there, jump here, receive your return value there. If Rust doesn't promise to abide by the protocol, then it's tantamount to saying that all FFI is undefined behavior. If it does promise to abide by the protocol, then that includes being prepared to tolerate all the things the protocol allows the other side to do.

I haven't thought deeply about FFI, but I disagree for inline assembly. The way it is specified in my head (well, one variant -- the one that seems best aligned with @Amanieu and your intuition) does not involve "syncing up" on the Abstract Machine level. I wouldn't even know what that means. The way I think about it, inline assembly is a bit like volatile accesses on steroids: from the Abstract Machine perspective, there's an external (and observable) event happening here. That event makes certain parts of the Abstract Machine state observable (meaning the compiler cannot change what is being observed), and the event is permitted to change certain parts of the Abstract Machine state in arbitrary ways. It's a bit like the Abstract Machine is interacting with another party here that makes some (constrained) choice for what to do. The details of what is observable and what may be changed are determined by the registers and options declared at the asm block. The compiler has to preserve observable behavior for every possible "implementation" of that event.
Nothing in this spec talks about syncing up low-level or high-level vs. low-level state. Everything remains on the Abstract Machine level. This is a spec that I know, in principle, how to make mathematically precise. I cannot say the same thing about the kind of spec that you are proposing. But certainly, this refutes your claim of yours to be the only way.

On targets where the low-level state does not contain a concept of undefined bytes (which is currently all of them), asm!("", in(reg) &mut val) implicitly freezes everything the assembly block would be allowed to write to: val itself, globals exposed to FFI, and everything transitively reachable through those things (for which a write would not violate Stacked Borrows or otherwise be UB).

Thanks for giving an example!
So, let us assume code like this:
let val: MaybeUninit<usize> = MaybeUninit::uninit();
asm!("", in(reg) &mut val);
println!("{}", val.assume_init());

In my proposed semantics, there are many possible executions for this on the Abstract Machine level (one for any possible action of this asm block, subject to the given constraints), including one that does not freeze val. But the execution that actually happens... well, it is not clear to me how to say which one that is, we basically have the choice between any Abstract Machine action that corresponds to a NOP on the physical machine, and this includes freezing. Given that, it probably makes little sense to define that this causes UB by not freezing things.
No conclusion here, I am just trying to recast what you said in a framework that works better for me.
(Earlier thoughts I had included constraining that external action to have something to do with the assembly code in the block, which lead to me saying that the compiler is allowed to understand a NOP asm block and optimize accordingly. But @Amanieu made it quite clear that that is not their intent by saying that it would be legal to patch the assembly code later. I am not sure if I really agree that that is a good idea, but my main goal here is to develop a formal understanding of what you think the right semantics are.)

[...] including one that does not freeze val. But the execution that actually happens... well, it is not clear to me how to say which one that is, we basically have the choice between any Abstract Machine action that corresponds to a NOP on the physical machine, and this includes freezing.

I think the key point here, is that from the perspective of the asm! block ("the other party"), any execution freezes the value of val. If we change the directive to in("eax"), then mov [eax], 3 will set it to 3 (and therefore freeze it), mov [eax], ebx will set it to whatever was in ebx, xchg [eax], ebx; xchg [eax], ebx will set it to whatever bit pattern was sitting in the memory address pointing to val, and of course the empty asm! will do the same.

For example, the asm block above could observe, at the Abstract Machine level, that val is Uninit

This is where the communication protocol comes into question. Under the suggested protocol between Abstract Machine and asm!, Uninit is not a value, and therefore cannot be observed. The specification is that if val has a specific initialized value in the Abstract Machine, then asm! sees that value; if it has the value Uninit, then asm! sees some, unknown but frozen value. And then, for the discussion above, it implicitly re-writes val to that value, freezing it.

This is a spec that I know, in principle, how to make mathematically precise. I cannot say the same thing about the kind of spec that you are proposing. But certainly, this refutes your claim of yours to be the only way.

Sorry, I was a bit sloppy with my wording.  When I said a spec must "specify[] how that mapping 'syncs up' at certain points", I didn't mean that it has to literally use a particular formalism.  I meant that it has to specify that as opposed to leaving it unspecified/undefined.  It has to be able to answer my question, but that answer might require translation from its framework to my framework. :)
Let me try to do a better job of explaining my framework.  It may be largely equivalent to yours, although I'm not sure.

That event makes certain parts of the Abstract Machine state observable

It makes it observable, and the format in which it is observable is what I call 'low-level state', i.e. the assembly-level model of memory and registers.

It's a bit like the Abstract Machine is interacting with another party here that makes some (constrained) choice for what to do.

Indeed, but it's not a truly interactive exchange.  Consider a simple example that uses asm! to read from and write to a string:

    let mut buffer: String = "hello".into();
    // add 1 to the first byte
    asm!("addb $1, ({buffer})", buffer=in(reg) buffer.as_mut_ptr());
    println!("{}", buffer);

At first, the string data exists only in Abstract Machine (high-level) state.  The buffer has some Abstract Machine address, and at that address in Abstract Machine memory are the bytes 'h', 'e', 'l', etc.  But the implementation can track that data any way it wants: it could store it in registers or in memory, or nowhere at all if it's unused.  It could even store it backwards or encrypted if that were somehow useful.
The code then executes an asm! statement, and the assembly observes the string data.  But the assembly doesn't do so by literally making an API call or request to the Rust implementation, asking "what's the Abstract Machine content at address X?".  (I know you're not claiming it does, but see below.)  Instead, it takes in a low-level address and performs a load from low-level memory.  So before invoking the assembly, the Rust implementation must unilaterally pick a low-level address for buffer.as_mut_ptr(), and ensure that the contents of the low-level memory at that address are (again) 'h', 'e', 'l', etc.  I refer to this as "syncing up" low-level state to match high-level state.
The assembly then stores a modified byte to low-level memory, and returns to the Rust code.  Again, the assembly doesn't directly inform the implementation what stores it wants to perform; it just updates low-level memory.  After executing the assembly, then, the implementation has to unilaterally "sync up" in the reverse direction: scan through all low-level memory that the assembly could have written, and update Abstract Machine state to match it.
(In practice, there's no explicit syncing phase because the implementation picks an internal representation that makes it mostly a no-op.  That is, even when assembly is not involved, the implementation typically maintains a 1:1 relationship between Abstract Machine bytes and low-level bytes, although optimizations sometimes break that relationship.  Because of this, the implementation doesn't need to actually do work to copy high-level state to low-level state or vice versa; it just has to hand the assembly the low-level address it was already using for the string data.  But it has to block certain optimizations, e.g. it can't reorder loads or stores of string data past the asm! statement.)
The fact that it's not truly interactive is important because it explains why implicit freezing occurs.  If the implementation could determine at runtime which addresses the assembly actually wrote to, it would only have to freeze those addresses, as opposed to all addresses the assembly could have written to.
In your formulation, I guess this corresponds to the idea that

we basically have the choice between any Abstract Machine action that corresponds to a NOP on the physical machine, and this includes freezing.

From my perspective, the "syncing" concept explains why a NOP on the physical machine could correspond to freezing in the Abstract Machine: because the data is lossily converted from the format of Abstract Machine memory (where Uninit is a possible byte value) to the format of low-level memory (where it's not), and back.  It also explains why the asm block cannot "observe, at the Abstract Machine level, that val is Uninit": because the assembly only sees low-level memory.  But I'm happy to see that formulated a different way.
Again, I'm not in love with implicit freezing as a feature for its own sake.  (I think it's nice that asm! made freezing possible before LLVM explicitly supported it, but AFAIK LLVM does support it now.)  But I think implicit freezing is sort of inherent to the way inline assembly works, such that if a model does not have implicit freezing as a side effect, the model risks either forbidding some specific use cases for inline assembly (like runtime patching), or worse, being underspecified in general.  I also think that largely applies to FFI as well.  But I could be wrong on both counts.

I think the key point here, is that from the perspective of the asm! block ("the other party"), any execution freezes the value of val.

That depends on how you constrain the possible actions of that block. I am a bit worried about encoding too much low-level hardware knowledge into that specification.
The remainder of your paragraph uses some very x86-specific terminology and knowledge; the asm! spec should not incorporate any of that.

This is where the communication protocol comes into question.

There's no protocol in my proposal though. Just some "transition relation on Abstract Machine states". A protocol requires an explicit model of the other party it interacts with, and not modelling that is the entire point of this exercise.

@comex thanks for that, this helps me to track your thoughts. I think I see how in your approach, freezing would come about. And at this point I feel most observable properties are the same in both of our proposals, we just use widely different terminology to get there. In particular, I am saying "freezing is one possible action of the asm block so the compiler does not get to assume that things are still Undef afterwards", and you say "the asm block definitely freezes all this", but this difference does not actually translate into different optimizations the compiler can make or different observations the program can make.
(I got side-tracked here for a minute as I thought that freezing violated the "don't observe too much" property I postulated at the end of my last post... but it actually doesn't. I think the property is some kind of non-interference-refinement thing, saying that if two states are related such that the second is "more defined" (it is the same everywhere except the first state may be Undef in some places where the second is not), then the asm action with the second state must refine the asm action with the first state. And indeed any concrete value refines the non-deterministic choice of freezing.)
My worry with all your talk about "low-level" stuff is that this means we need, as part of the Abstract Machine spec, define what a "low-level state" is, or at least what axioms it needs to satisfy. But at the same time that definition needs to encompass all current and future hardware architectures. That seems like a daunting task to me, which is why I proposed a mechanism that doesn't have to do this.
On the other hand, what I am worried about with my approach is the fact that we need this "observabiltiy restriction", and we need to get it right.

There's no protocol in my proposal though. Just some "transition relation on Abstract Machine states".

Protocol may be the wrong term here. What I meant was something along the lines of what @comex meant with a "lossy conversion":

because the data is lossily converted from the format of Abstract Machine memory (where Uninit is a possible byte value) to the format of low-level memory (where it's not)

The Abstract Machine needs to make the data available to the asm! block, in a format which it can understand. For this, it does need to understand the constraints of this format. So in most architectures, since there's no Uninit value, the Abstract Machine needs to give some other (legal) value, essentially freezing that memory. Arguably, if running an asm! block for an architecture that does have Uninit as a possible value in a memory location, the Abstract machine doesn't need to "sacrifice" the Uninit-ness, just make sure that it is properly encoded. Then when resuming, it can read that memory and know if it is still Uninit or not.
As the compiler knows which architecture is currently used, it can also have knowledge on the valid values under this architecture, convert to them, and make the correct assumptions after this (possibly lossy) conversion. Yes, this means that some of the semantics of what the compiler is and isn't allowed to do around an asm! will be platform-specific, but there's a lot of platform-specific stuff going on anyway.

The Abstract Machine needs to make the data available to the asm! block, in a format which it can understand.

You say "needs", but as I keep trying to explain that is but one of several ways to conceptualize asm! blocks.

So in most architectures, since there's no Uninit value, the Abstract Machine needs to give some other (legal) value, essentially freezing that memory.

The Abstract Machine spec, including the spec for asm blocks, should not depend on what "most architectures" do. After all, we want to be able to optimize Rust code without knowing the target architecture. The fact that you had to say "most" is a big warning sign showing that this approach might be too architecture specific and not sufficiently abstract.
You seem to think that this is inevitable; I strongly disagree and have laid out my proposal for that above.

With the "lot of platform-specific stuff" I meant for instance, that under already under the current proposal, e.g. the registers and their formatting need to be interpreted in an architecture-specific way. Sure, this is much simpler than changing the effect the asm! block has on the state of the machine, but I think this points in the right direction. By it's nature, asm! does different things for different architectures, depending on what's possible on that architecture. Somewhere in this PR, there was even a suggestion to make this difference explicit, by making these separate macros which sit in separate arch modules.
Therefore, I think it makes sense to treat asm! on different architectures as different constructs, which also lets the compiler reason differently about them. When I wrote "in most architectures" I didn't mean "and that's why it should be this way for all of them", rather, that in these architectures it should be this way. Of course, the suggestion attempts to develop a syntax which expands on the common element of all architecture (registers, clobbers, nomem, etc.), but this is user-facing. Making it architecture-specific actually makes it easier to specify the "compiler-facing" sides, such as freeze semantics, because then you don't need to fall back on "in most architectures" - you just define what makes sense for each one of them. And there's no need for a stop-gap "generic" implementation, as each supported architecture needs to be added specifically anyway.
This should also bring your definition, where the Abstract Machine doesn't "do" anything special, and the asm! block just peeks into some of its state and performs one of a defined set of transitions, closer to the one where the Abstract Machine "synchronizes state". Does this set of transitions including only ones which freeze the memory, or also some which don't? There's a clear answer, it just depends on the architecture.
I think the analog suggested above to FFI holds here as well. Just as different FFI conventions have different ABI, which means they might require different things from the compiler, the same can be said for asm! on different architectures (regardless of whether this difference is made explicit in surface-syntax).

Therefore, I think it makes sense to treat asm! on different architectures as different constructs, which also lets the compiler reason differently about them.

I very strong disagree with this logical step. Yes,in the backend, asm! will be treated very architecture-specifically. That is to be expected, and the backend already is architecture-specific.
But in the middle end (e.g. on the MIR layer), that should not be the case. The complexity cost of having something architecture-specific there is huge, and it is also an extreme case of a layering violation. To my knowledge, this is also not how it is done in other compilers -- LLVM's optimizations (the ones that work on the IR, not the lower layers) do not have architecture-specific code to handle inline assembly, do they?
I don't think we should ever accept a feature into rustc that requires architecture-specific reasoning for MIR optimizations. It follows that the Rust Abstract Machine spec should not have anything architecture-specific. (There are some simple "knobs" to turn on the Abstract Machine, such as the pointer size, but that is fundamentally different from what you are proposing.)

I think the analog suggested above to FFI holds here as well. Just as different FFI conventions have different ABI, which means they might require different things from the compiler

They require different things from the backend, but MIR doesn't care. So, this is a false analogy.
I am getting the impression that you are thinking of a spec of asm! that lives on the layer of the backend. That is, unfortunately, the wrong place to solve the problem -- we need to say something about what happens on the MIR/Abstract Machine level, entirely independent of backends and CPUs, and that is what @comex and I were discussing.

You're right, I was missing the distinction between MIR and the backend. I would still argue, that it's possible for the front-end asm! macro to be different for different architectures, then translating into different MIR around that block (e.g. with or without a "freezing directive"). But this might indeed be overly complex and unnecessary.
OTOH, the alternative seems to be to find something which does fit all architectures - regardless of whether you define it in terms of "what is a low-level state" or in terms of "what should be observable" (this also needs to fit real architectures, because it doesn't make sense to define something as observable if the "other party" at the asm! block can't really observe it). The problem with the latter is, that you can't tell what has been observed and what not; so if you limit the possible observable states to be initialized values, you have to assume that they have been observed and therefore "reduced" to these values - i.e. frozen. This probably amounts to the same thing as what you said, about "some possible executions" freezing the value, which means you can't assume it wasn't frozen.
I guess your comparison with LLVM is probably relevant, though: how does LLVM handle undef or poison values passed on to inline assembly?

If we're talking about the MIR level only then inline assembly should be 100% equivalent to any other FFI call. If fact we probably can store the inline assemble as a type that impls the Fn traits so most of the compiler can treat it as nothing special (more details on this idea)

@RalfJung If I'm reading you right, you're saying that inline asm should be handled differently than FFI because it exists at the MIR level?
I think the FFI comparison is a very apt and important one. Inline asm is, by design, leaving the Rust language behind and using a different language -- that of the assembler as implemented by the platform. At some level, the specification has to define how the Abstract Machine state is translated to the Abstract Machine that the language you're communicating with has. (For assembler, this is the physical machine.)
Whether they are all exposed just as asm! or individually as arch::_::asm!, I think it is correct for the Abstract Machine to consider each asm! for each architecture as a distinct thing. Because, in a way, they are: you're interfacing with different other Machines in each case.
Inline asm is super tricky to specify. There are amounts of it that can be specified at the language Abstract Machine level, but ultimately, some of it has to be specified by the target (at an absolute minimum, how to put information in and get information out).
I think the easiest formalization is the one in which you take the Abstract Machine state, and for everything you allow the Foreign ASM to observe, you translate it into the format you've defined the Foreign ASM to observe. After the Foreign ASM has executed, you read any of the concrete state the Foreign ASM was allowed to write, and load that into the Abstract Machine. This is necessarily dependent on how you do the communication with said Foreign ASM. And, my point here, identical to how any other Foreign Interface is handled.
This isn't the only way to model the communication, but any other correct model will end up being isomorphic to it, unless I am sorely mistaken.
So TLDR because I have no other idea how to end this post: yes, MIR needs to treat asm! differently when trargetting different target triples, because the interface between the "Rust (Abstract) Machine" and the "ASM Machine" is different on different target triples. This can and should be different items in MIR as well as specified by the target.

If inline assembly was like an FFI call, things like nomem or pure don't make any sense, do they? There's clearly more going on here.

I think it is correct for the Abstract Machine to consider each asm! for each architecture as a distinct thing.

No, I think that is a terrible mistake. It's also, to my knowledge, not what any other compiler does. It is unnecessary and solves no problems.
Note that whatever the Abstract Machine says about asm! is not the full spec. After all, @Amanieu demanded that it must be legal for run-time code to patch the assembly that comes from the asm! block. Whatever the Abstract Machine says about asm! will be complemented by some lower-level aspects that takes care of everything platform-specific, similar to how we already have lower-level things that specify e.g. calling conventions and volatile accesses. So, yes, it is right that asm is "inherently platform-specific", but that in no way implies that its spec in the Abstract Machine ought to be platform-specific.
There's a reason it is called the Abstract Machine, and not the Concrete Machine. An Abstract Machine that has target-specific parts in its spec (that go beyond simple parameterization like pointer size) is basically useless.

yes, MIR needs to treat asm! differently when trargetting different target triples, because the interface between the "Rust (Abstract) Machine" and the "ASM Machine" is different on different target triples.

No, that is not correct. The interface cannot be different. That would defeat the entire point of having an Abstract Machine in the first place.

I would like to clarify my position here. I believe the semantics of inline asm from the point of view of the Abstract Machine should be treated exactly the same was as a normal FFI call. This makes sense if you consider that an FFI call could be used to call some JIT compiled asm code, which has similar semantics to inline asm.
The fact that inline asm invocations use a custom calling convention isn't really a concern of the Abstract Machine, the same way it doesn't really care if an FFI call uses the "C" or "stdcall" calling convention.

If inline assembly was like an FFI call, things like nomem or pure don't make any sense, do they?

Similar attributes have actually been proposed for normal FFI calls, see #58327. I don't think it would be too difficult to support these semantics in the Abstract Machine.

yes, MIR needs to treat asm! differently when trargetting different target triples, because the interface between the "Rust (Abstract) Machine" and the "ASM Machine" is different on different target triples.

Actually I'm in the middle of writing the MIR passes for the new asm! right now, and the compiler absolutely does not care about any architecture-specific details at that level. Such details only become relevant at the LLVM level when it has to perform register allocation (i.e. one of the last stages of codegen).

@Amanieu

If inline assembly was like an FFI call, things like nomem or pure don't make any sense, do they?
Similar attributes have actually been proposed for normal FFI calls, see #58327. I don't think it would be too difficult to support these semantics in the Abstract Machine.

Indeed, pure and nomem are roughly equivalent to GCC's function attribute __attribute__((const)) or LLVM's readnone.  In fact, from LLVM's perspective, call asm instructions are literally a subclass of call instructions, and both call asm and 'normal' call instructions can be marked readnone, with the same effects on the optimizer.  Clang marks normal calls as readnone if the target function is __attribute__((const)), and it marks asm calls as readnone if the C asm block neither has the memory clobber (the opposite of nomem from this proposal) nor is marked volatile (the opposite of pure from this proposal).  (Things get messy, though, because volatile also sets a separate sideeffect flag which only exists on call asm instructions.)

Indeed, pure and nomem are roughly equivalent to GCC's function attribute attribute((const)) or LLVM's readnone.

Fair.
I am not sure if that really solves the problem though -- all this shows is that specifying FFI properly on the Abstract Machine level is just as hard as specifying inline assembly. ;)
The good news is a good solution to one problem will likely also (mostly) solve the other.
But, it also seems like between @comex and my proposals, we have a few angles of attack that look promising. That certainly seems good enough to proceed for now.

I've been thinking in circles about the architecture-dependence issue and I don't have a firm conclusion.
Perhaps it's worth pointing out that implicit freezing isn't something the compiler would normally be expected to reason about at any level.  The compiler never gets to say, 'originally this byte could be one of {80, Undef}, but we passed an asm block, so now it has to be 80'.  Rather, it's 'we passed an asm block; now this byte could be anything, because the asm was allowed to write to it'.
On the other hand, you could come up with a hypothetical, mostly-useless MIR-to-MIR optimization that would be valid only if implicit freezing exists.  I don't speak MIR, but at a source level, given this function:
unsafe fn foo(p: &mut MaybeUninit<u32>, cond: bool) -> u32 {
    asm!("some asm", in(reg) p);
    if cond { p.read() } else { 0 }
}

you could change
    if cond { p.read() } else { 0 }

to
    let val: u32 = p.read();
    if cond { val } else { 0 }

only if the asm block is guaranteed to freeze p.
I say it's useless because you could alternately just change it to
    let val: MaybeUninit<u32> = *p;
    if cond { val.assume_init() } else { 0 }

which is valid regardless of freezing, and normally results in the same assembly.
But it definitely doesn't make sense to assume that no architecture can ever track uninitialized bytes at a hardware level.  (And if we ever add a C backend, it would violate that assumption.)  If implicit freezing exists at all, it must be architecture-dependent.
So you can say it shouldn't exist.  Fine by me, except that then you have a strange gap between the spec and reality, since there is no possible implementation that can violate the assumption of implicit freezing.
Here's one perspective I thought of.  From the programmer's perspective, the semantics of an asm block are very architecture-dependent.  After all, the programmer is normally allowed to rely on the instructions they wrote in the asm string having their architecture-defined semantics.  Well, not when code patching is involved, but the programmer hopefully knows whether or not they're planning to patch the code. :)  If the compiler was allowed to inspect the asm string, many architecture-dependent MIR-to-MIR optimizations would be possible.  For example, asm!("add {}, 1", inout(reg) foo) could be transformed to foo += 1!  But the compiler is expected to treat the string as a black box.  Implicit freezing then ends up as a weird edge case where it's an architecture-dependent effect that theoretically applies to any asm string, so the compiler can make assumptions about it without actually inspecting the string.  Perhaps it should treat it as the sort of moral equivalent of inspecting the string, something to refrain from doing...

But it definitely doesn't make sense to assume that no architecture can ever track uninitialized bytes at a hardware level. (And if we ever add a C backend, it would violate that assumption.) If implicit freezing exists at all, it must be architecture-dependent.

If you take MADV_FREE into account then platforms actually do track uninitialized memory (albeit at a page granularity): uninitialized memory returned by malloc may have non-deterministic contents (the OS could reclaim the page at any time and replace it with a zero page). You need to actually write data to the page in the asm code to freeze it.

@comex it looks like you switched questions? As far as I was concerned, before we were talking about the question "is the compiler forced to accept that the asm block semantics might be that of freezing".  You explicitly want that to be the case it seems, and I think I can at least rationalize that choice and leave it up to the lang team to decide if they are okay with it. ;)
But now you seem to ask "is the compiler permitted to assume that the asm block definitely froze all inputs/outputs". That is a different question, but also an interesting one.
My proposed model answers this question with "no", as the asm block is perfectly allowed to leave all state unchanged. I think it would be odd to require the asm block action to do anything. In the extreme case, for an asm block that's empty, behaving as a NOP should be a possible behavior of that block (even if the compiler may not assume that it is the only possible behavior). Everything else seems pretty odd to me.

I thought that one point is that the Asm block is "must not be examined", and so even an empty string must operate the same as if you'd written something.

Indeed, and I said nothing to the contrary.

So the question:
Is there a practical difference between "the ASM may have written to this memory" and "the ASM did write to this memory"?
If we say that the memory is in a defined state prior to calling the ASM, there is no observable difference between the asm writing the value that is there and not writing it at all... up to hardware undefined bytes, such as fake pages.
So it is correct to say that the compiler must assume that memory may have been frozen (equivalently, written), but it is not guaranteed to be frozen unless you write to it.

Is there a practical difference between "the ASM may have written to this memory" and "the ASM did write to this memory"?

@comex gave an example where this can make a difference: if the ASM did write, then memory is frozen. At least, that is one possible approach.
But, anyway, given this is intended to support run-time patching, I think there is no way the compiler can make statements like "the ASM did write".

I would like to thank everyone here for their feedback on this RFC. All of the feedback given has been incorporated in the RFC (but let me know if I missed anything).
Since this thread has grown rather large, I have closed it and opened #2873  instead, where the discussion should continue.

Just a minor procedural note by a random:
I understand the desire to have a cleaner RFC thread for newcomers and scan-again-ers, but I disagree with splitting this into a new RFC. The biggest issue is that anyone who subscribed to this thread now has to subscribe to the new one to continue getting notifications.
I don't think the "identity" of the RFC has changed, so there's no semantic reason to make it RFC#2873 rather than RFC#2850. In short, the only impact making the new thread has is to unlink all of the discussion in this thread. Perhaps all of the feedback in this thread has been addressed and nothing is lost, but it feels like (at least to anyone with an open thread here still) like just unanimously declaring all the threads finished rather than letting them hang on organically.

I understand that concern, but the flip side of that is that there's no great way in GitHub to handle threading, or to easily partition discussion into "before latest draft" and "after latest draft", other than opening a new issue. Large discussion threads can be impenetrable to potential participants/contributors, even to people who are experienced with the project but not up to date with the thread.
It's not at all ideal, but the language team felt it was the best we could do with the tools we have.

Github has the "hide as resolved" option.

"Hide as resolved" won't help getting rid of that "XX items hidden" box. "Hide as resolved" also impedes searching within the page.


Change project structure

Instead of having (almost always) one class per file I think it would be better to treat files as a unit containing all related classes and functions.

Decided that it is to much work and benefits are not that great.


After upgrade to 3.10.0 I get compile error: The parameter 'details' of the method....

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Steps to reproduce
Im building for Android on device, but fails...see log output
I have tried everything that comes to mind, cache repair, clean ect, no luck.
Actual results
I can not compile.
Logs

Logs

./../../../.pub-cache/hosted/pub.dev/macos_ui-1.12.2/lib/src/fields/text_field.dart:108:35: Error: The parameter 'details' of the method '_TextFieldSelectionGestureDetectorBuilder.onSingleTapUp' has type 'TapUpDetails', which does not match the corresponding type, 'TapDragUpDetails', in the overridden method, 'TextSelectionGestureDetectorBuilder.onSingleTapUp'.
 - 'TapUpDetails' is from 'package:flutter/src/gestures/tap.dart' ('../../../flutterSDK/flutter/packages/flutter/lib/src/gestures/tap.dart').
 - 'TapDragUpDetails' is from 'package:flutter/src/widgets/tap_and_drag_gestures.dart' ('../../../flutterSDK/flutter/packages/flutter/lib/src/widgets/tap_and_drag_gestures.dart').
Change to a supertype of 'TapDragUpDetails', or, for a covariant parameter, a subtype.
  void onSingleTapUp(TapUpDetails details) {
                                  ^
../../../flutterSDK/flutter/packages/flutter/lib/src/widgets/text_selection.dart:2161:8: Context: This is the overridden method ('onSingleTapUp').
  void onSingleTapUp(TapDragUpDetails details) {
       ^
../../../../.pub-cache/hosted/pub.dev/macos_ui-1.12.2/lib/src/fields/text_field.dart:130:42: Error: The parameter 'details' of the method '_TextFieldSelectionGestureDetectorBuilder.onDragSelectionEnd' has type 'DragEndDetails', which does not match the corresponding type, 'TapDragEndDetails', in the overridden method, 'TextSelectionGestureDetectorBuilder.onDragSelectionEnd'.
 - 'DragEndDetails' is from 'package:flutter/src/gestures/drag_details.dart' ('../../../flutterSDK/flutter/packages/flutter/lib/src/gestures/drag_details.dart').
 - 'TapDragEndDetails' is from 'package:flutter/src/widgets/tap_and_drag_gestures.dart' ('../../../flutterSDK/flutter/packages/flutter/lib/src/widgets/tap_and_drag_gestures.dart').
Change to a supertype of 'TapDragEndDetails', or, for a covariant parameter, a subtype.
  void onDragSelectionEnd(DragEndDetails details) {
                                         ^
../../../flutterSDK/flutter/packages/flutter/lib/src/widgets/text_selection.dart:2839:8: Context: This is the overridden method ('onDragSelectionEnd').
  void onDragSelectionEnd(TapDragEndDetails details) {
       ^
Target kernel_snapshot failed: Exception

FAILURE: Build failed with an exception.

* Where:
Script '/Users/denniskragekjaer/Documents/flutterSDK/flutter/packages/flutter_tools/gradle/flutter.gradle' line: 1159

* What went wrong:
Execution failed for task ':app:compileFlutterBuildRelease'.
> Process 'command '/Users/denniskragekjaer/Documents/flutterSDK/flutter/bin/flutter'' finished with non-zero exit value 1

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

Flutter Doctor output

Doctor output

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.10.0, on macOS 13.3.1 22E261 darwin-x64, locale en-DK)
[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
[✓] Xcode - develop for iOS and macOS (Xcode 14.3)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2021.2)
[✓] VS Code (version 1.78.1)
[✓] Connected device (2 available)
[✓] Network resources

Hi @DennisKragekjaer, the issue is from the macos UI package. An issue has already been filed on their repo. See  https://github.com/macosui/macos_ui/issues/423
Kindly follow up there for updates.
Closing from here.
Thank you


Enable Ray Fast Register

Why are the changes needed?
Today, when launching a Ray job in Flyte only the Head Node is retrieving fast register data - no applying for Ray Worker Nodes. This results in the need for the user of copy the source code into the containers working dir & rebuilding the container image for every change on the ray user code.
This PR utilizes rays functionality of adding files to the ray job on runtime passing the runtime_env {"working_dir":"some_path"}.
⚠ There is an ray gcs storage limit of 500MiB. Thats why ray supports adding an excludes variable along with working_dir which functions as a .ignore file. This PR introduces a excludes_working_dir to the RayJobConfig, which allows control over what files to upload to the ray cluster.
What changes were proposed in this pull request?

Adding working_dir & excludes init parameter when running remotely
Docs on what this parameter is doing
TLDR: after head node downloads fast register data -> ray.init("working_dir"="/root", excludes=["data"]) zips all fast register data, takes excludes into account and uploads to ray gcs -> ray worker nodes downloads zips from ray gcs and unzips

How was this patch tested?

Running the following workflow with Imagespec works:

from flytekit import ImageSpec, Resources, task, workflow, PodTemplate
from flytekitplugins.ray import HeadNodeConfig, RayJobConfig, WorkerNodeConfig
from ray.util.multiprocessing import Pool

import time
import math
import random

container_image = ImageSpec(
    name="rayworkerlove",
    apt_packages=["git", "wget"],
    packages=[
        "git+https://github.com/flyteorg/flytekit.git@6ac4b533d68382e0e50a2dbc14477f33855acfe5#subdirectory=plugins/flytekit-ray"
    ],
    registry="ghcr.io/fiedlerNr9",
)

def sample(num_samples):
    num_inside = 0
    for _ in range(num_samples):
        x, y = random.uniform(-1, 1), random.uniform(-1, 1)
        if math.hypot(x, y) <= 1:
            num_inside += 1
    return num_inside

ray_config = RayJobConfig(
    head_node_config=HeadNodeConfig(
        ray_start_params={"log-color": "True", "num-cpus": "1"}
    ),
    worker_node_config=[
        WorkerNodeConfig(
            group_name="ray-group", replicas=3, min_replicas=1, max_replicas=4
        )
    ],
    shutdown_after_job_finishes=True,
    ttl_seconds_after_finished=120,
    enable_autoscaling=False,
    excludes_working_dir=["micromamba"],
)

@task(
    task_config=ray_config,
    requests=Resources(mem="2Gi", cpu="1"),
    container_image=container_image,
)
def approximate_pi_distributed(num_samples: int):

    pool = Pool()

    start = time.time()
    num_inside = 0
    sample_batch_size = 100000
    for result in pool.map(
        sample, [sample_batch_size for _ in range(num_samples // sample_batch_size)]
    ):
        num_inside += result

    print("pi ~= {}".format((4 * num_inside) / num_samples))
    print("Finished in: {:.2f}s".format(time.time() - start))

@workflow
def wf(n: int = 60000000):
    approximate_pi_distributed(num_samples=n)

Setup process
Screenshots

Check all the applicable boxes

[ ] I updated the documentation accordingly.
[ ] All new and existing tests passed.
[ ] All commits are signed-off.

Okay no need to manually update timestamps here. I am just always put the in the exclude variable, since there is no need to upload the .tar.gz to the ray gcs.
"excludes": ["script_mode.tar.gz", "fast*.tar.gz"]!
Works and tested with pyflyte run and register. Would appreciate another review


Transform file React-PropTypes-to-prop-types.js does not exist

I tried to run the script detailed here but the file does not exist in my node_modules directory.
https://github.com/reactjs/react-codemod#react-proptypes-to-prop-types
steps to reproduce

yarn add jscodeshift react-codemod --D (Installs jscodeshift version 0.3.30 and react-codemod version 4.0.0)
node_modules/jscodeshift/bin/jscodeshift.sh -t node_modules/react-codemod/transforms/React-PropTypes-to-prop-types.js components/
Error is returned

ERROR Transform file [...]/node_modules/react-codemod/transforms/React-PropTypes-to-prop-types.js does not exist

@jdwinall-tm The npm package for this project doesn't get released very often (according to https://www.npmjs.com/package/react-codemod it hasn't had a release in 8 months, and React-PropTypes-to-prop-types.js is newer than that). I think the right way to use one of these codemods is to just clone the react-codemod repo from GitHub, separately install jscodeshift, and point jscodeshift at the React-PropTypes-to-prop-types.js file within the cloned repo.

@alangpierce I agree, but the README.md should be updated capture this.  It states you can install the module using yarn or npm.  I assumed that the readme would be in sync with the code available in the npm package.

The instructions actually do say to npm install -g jscodeshift, then git clone https://github.com/reactjs/react-codemod.git, then npm install or yarn from within the repo (not to run npm install react-codemod or yarn add react-codemod). But I understand how it could be misread.
IMO it would be best if the npm package was just unpublished to avoid confusion (or there was a deprecation message or something). Or maybe the project could be hooked up to semantic-release or some similar system so the npm registry version is automatically kept in sync with the GitHub repo.
(I don't run this project, I've just contributed a few times.)

I tried in this way

npm install -g jscodeshift
git clone https://github.com/reactjs/react-codemod.git
cd react-codemod
4.npm install
5.go to the project which need to transform file, then run this command:

eg.   jscodeshift -t ../demos/react-codemod/transforms/React-PropTypes-to-prop-types.js ./
which means jscodeshift  find the  React-PropTypes-to-prop-types.js to transform the current whole directory.
Then it works! Hope this will help you.

@alangpierce Would you please cut a release with these new transforms? We have a use case for using react-codemod as a locally installed module but will have to copy the source since the transform we want to reference is not available.

@wbeard I guess you could fork the project and publish it to npm under a new name that you pick. Is there a reason git clone as a distribution mechanism doesn't work for you? Arguably it's a little weird to have things installed in node_modules that are neither a library nor a CLI tool, and to need to specify explicit paths to files within node_modules packages.
Here's some prior discussion about the idea of distributing codemods through npm: https://github.com/facebook/jscodeshift/issues/126

Thanks, I'll look over the discussion. I do agree that there could be a better solution for the ecosystem. I'd love to discuss that!
To better explain the use case, we are giving teams a way to easily resolve merge conflicts due to codemods. Our solution, so far, is using an npm script to run jscodeshift and a corresponding codemod. When we make large changes, such as moving proptypes, those who need to rebase can just run a script against their local changeset by running yarn codemod proptypes. The aim is to reduce friction by reducing the amount of steps to resolve possible conflicts.
There are many ways to do it, and arguably there's not a real need to have an up to date version of the react codemods for any extended length of time. It just seems like a better experience to be able to reach into the library for the source rather than forking or copying. I hope I explained it well!

When I ran the jscodeshift command, all my files got skipped. What may be the issue?

We just published v5.

i have installed the codemod and jscodeshift by

npm install -g jscodeshift
git clone https://github.com/reactjs/react-codemod.git
3.cd react-codemod
4.npm install
5.go to the project which need to transform file, then run this command:
~/React_Launcher$ npx jscodeshift -dpt ~/React_Launcher/react-codemod/transforms/rename-unsafe-lifecycles.js src to update the component lifecycles for my whole project but i am seeing an error as :-
ERROR Transform file /home/punith/React_Launcher/transform.js does not exist
could anyone sort me out with the issue

Please file a new issue @Punith22bravo.


ImageSlider with Zoom and ROI

Here's the completed new version of the ImageSlider widget. It implements the zooming algorithm from the ImageDisplay widget, although it is slightly altered to allow for all images to be zoomed at once without the image series needing to be copied. Also, this pull request implements a ROI field that displays the coordinates of the four corners of the currently displayed image. These coordinates are with respect to the original image, not the zoomed image.
For more details on development and changes, see #14.

Nice work Ian. I started today to play with your new widgets to add them to my notebooks.


Printing limitation

Regarding

R visuals currently do not print with dashboard and reports printing.

In Power BI Service:

The File => Print this Page option seems to work fine
The Export => PDF option returns "R visuals are not supported with this operation." for the R visual

Can this limitation please be elaborated on, to clarify what printing scenarios are supported vs. unsupported?

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

ID: 90c7931b-9fbb-bec4-09c4-9c827e4ec7a1
Version Independent ID: 7ebc1400-482b-62e6-3747-bb7ffdb1dcf3
Content: Create advanced analytics and visualizations using R scripts - Power BI
Content Source: powerbi-docs/visuals/service-r-visuals.md
Service: powerbi
Sub-service: pbi-visuals
GitHub Login: @mihart
Microsoft Alias: mihart

Thanks for your comment, @VitalyMCT.
I've assigned this issue to the doc author for review.
In the meantime, you might find an answer in the Power BI Community.

Unfortunately, we have been unable to review this issue in a timely manner. We sincerely apologize for the delayed response. Both the product and documentation might have changed since this issue was opened. Therefore, we are closing this issue. If you feel that the problem persists, please respond to this issue with additional information.
Please continue to provide feedback about the documentation. We appreciate your contributions to our community.


taggings_count not updating in act as taggable

I used gem act_as_taggable in my project. Below is my model
post.rb
acts_as_taggable_on :moods
has_many :taggings, as: :taggable, dependent: :destroy

It is working fine, but the only issue is taggings_count field of tags count isn't updating.
Am I missing something to add any extra config? Because as per my understanding it should update automatically

I resolved this issue, We don't need to write has many association of taggings. I removed below association and everything is working fine now.
has_many :taggings, as: :taggable, dependent: :destroy


UVI Request

--- UVI JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from v4.8 to before v5.15",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=210e7a43fa905bccafa9bb5966fba1d71f33eb8b",
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9037c57681d25e4dcc442d940d6dbe24dd31f461"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "210e7a43fa905bccafa9bb5966fba1d71f33eb8b",
      "note": "introduced"
    },
    {
      "type": "commit",
      "value": "9037c57681d25e4dcc442d940d6dbe24dd31f461",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "mm, slub: fix potential memoryleak in kmem_cache_open()\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.15 by commit 9037c57681d25e4dcc442d940d6dbe24dd31f461, it was introduced in version v4.8 by commit 210e7a43fa905bccafa9bb5966fba1d71f33eb8b. For more details please see the references link."
}
--- UVI JSON ---

This issue has been assigned UVI-2021-1002180


example depends on path_provider_ios which is renamed and there is no path_provider_ios

Hello, can you fix this?

By any chance, did you use audio_session successfully in the past, and then found that it started giving this error recently?

I will note that the *.lock files are not checked into the git repository for audio_session, which is why I think this must be an issue with your own lock files. My theory is that your lock files point to an old dependency, and once you re-resolve the dependencies to the latest versions, the error should go away. E.g. flutter pub upgrade.

It seems in the example directory the pubspec lock file isn't checked in but the Podfile lock file is, so I can remove that. However, the pubspec lock file is primary and the podfile lock file is secondary, so if you fix your pubspec lock file I believe it should work (i.e. flutter pub upgrade)

Thank you for responding. I fixed it. The problem was with removing webview_flutter package from pubspec.yaml and expecting it to work. Because I don't really use flutter_webview in my project. I suppose that some my package depends on it and it couldn't find in dowloaded packages. Sorry for disturbing. I am closing the issue.


NeutralResourcesLanguage Warnings on UWP

I'm getting the following warnings on a Universal Windows App.

warning MSB3817: The assembly "Microsoft.Framework.DependencyInjection.dll" does not have a NeutralResourcesLanguageAttribute on it. To be used in an app package, portable libraries must define a NeutralResourcesLanguageAttribute on their main assembly (ie, the one containing code, not a satellite assembly).

warning MSB3817: The assembly "Microsoft.Framework.DependencyInjection.Abstractions.dll" does not have a NeutralResourcesLanguageAttribute on it. To be used in an app package, portable libraries must define a NeutralResourcesLanguageAttribute on their main assembly (ie, the one containing code, not a satellite assembly).

See https://github.com/aspnet/Options/issues/73

Fixed in https://github.com/aspnet/DependencyInjection/commit/25f57b5ec0f52c9ad2b4308455df506878c2950e

@bricelam BTW can you also confirm that this does what you need for UWP apps? I want to make sure we didn't miss anything anywhere.


Telegram API Integration into Oracle

Overview
As we expand our social media integrations, we've successfully integrated Discord, Reddit, and Twitter APIs. The next logical step is to incorporate Telegram's rich messaging capabilities into our platform.
Goals

Enable our application to send and receive messages through Telegram.
Leverage Telegram's bot features to enhance user interaction.
Integrate Telegram's API to support real-time messaging within our application.

Requirements

Research Telegram's Bot API and identify key methods needed for integration.
Design a secure authentication flow to connect user Telegram accounts with our service.
Implement the ability to send, edit, and delete messages through Telegram.
Ensure the integration supports group chats and channels where applicable.
Develop a system to handle incoming messages and commands sent to the bot.

Potential Challenges

Handling the scale of messages and ensuring the system is performant.
Ensuring privacy and security when dealing with user data.
Adapting to the Telegram API rate limits and managing the bot's responsiveness.

Compliance and Security

Review Telegram's API terms of use to ensure our integration is compliant.
Implement robust encryption for any data exchanged between our servers and Telegram.

Resources

Telegram Bot API Documentation

Acceptance Criteria

The system handles incoming messages and commands efficiently.
All interactions through Telegram are logged and auditable.

@mudler  - updated ticket descriptions in these tickets.

Thank you!

@teslashibe
https://www.loom.com/share/c10d29d8b99c4bb2a5fe80fa8c2869f7


[ERROR] Exception during symbol loading - 'Key '2905' not present in dictionary'

During runtime, I'm running into an exception when loading symbols. Sometimes it fails early or towards the end - but always on the same stage. The key ID has been different each run.
Ultra-Runtime-Exception.txt
If needed, I can provide the application I'm trying to profile.

Just to make sure, which version exactly do you run?

I installed it today, ref Nick Chapsas' video, so the latest (I believe) on NuGet.
PS C:\Windows\system32> ultra --version
2.0.0+20b85170ee37a839bf2e1538f004651f4615f00f

Thanks, I will try to investigate this later tonight.

I have made a tentative fix via 225fdc1 available in 2.0.1+
Please try it, hopefully it should fix your issue. I'm still a bit unclear how that could happen in the first place, but now the code should be more correct. Let's see 🤞


Build html docs in single plugin

Fix html-plain generating 0 bytes output removing unused doctype
Unify all html in single plugin config: each file uses its own execution with shared and custom attributes
Set resources to avoid empty folders & place images only where necessary

The final result is that now we can get the docs in the desired structure for publishing with a single build. With the caveat of the interleaved html directory, but that could be removed easily now, even passed as command argument during CI.

From this point, it should not be hard to get a GH-action that pushes the docs on release :tada:

Thank you very much. Has been merged to master.


Configuration Profiles and AWS Credential Profile Aliasing

Implemented the ability for creating configuration profiles, which are selected using the --profile flag.  Also implemented the ability for users to set their own AWS credential profile aliases, as some role names are long and tedious to type out every time you want to reference the profile.
Also reorganized some of the OktaClient code to create more of a separation of duties for the two classes.
Updated the tests to match the code changes.

LGTM.