Federico Viticci:
At this point, you may be wondering: if someone has an account on a different instance, or posted something I want to reply to, how can I do this from my account on a separate Mastodon instance?
This is where my friend Jason Snell comes in: a few days ago, he shared a post in which he noted that the default method for redirecting a post or profile from another Mastodon instance back to yours is, well, somewhat convoluted. If you come across a profile or post from a different Mastodon server, you have to copy its original URL, go to your instance, manually paste it into the search box, find the result you’re looking for, and only then you can interact with it. That works, but it’s not intuitive, and I figured I could improve this aspect of the Mastodon experience with a shortcut.
iOS iOS 16 Mac macOS 13 Ventura Mastodon Shortcuts Web
Christian Tietze:
I was under the (wrong) assumption that the mutating func needed to, well, somehow mutate the receiver of that method call, like change a property value. And that this in turn would be noted “somewhere”. Conversely, I was under the (wrong) assumption that a mutating func without any mutations inside would behave 100% like a regular, non-mutating function.
[…]
A pretty nice consequence is that you can use mutating func to change a reference type property inside a value type, and have references to the value type still know that it has changed:
Language Design Programming Swift Programming Language
Tim Kientzle:
I thought it would help to have an informal sketch to help outline why move-only types are interesting, clarify a few subtle points (like what “move” really means), and briefly explain some of the issues we’ll need to tackle in order to bring this to Swift.
[…]
So the first step in bringing move-only support to Swift is to add operations with different lifetime-management behaviors. This will include constructs such as for borrow x in collection that let you iterate over the items in a collection without requiring an implicit copy and f(take x) that explicitly invalidates the local value as part of passing it into a function. We’re also exploring variations of these that would allow you to temporarily gain mutable access to a value. These would allow you to efficiently mutate an element “in place” in various scenarios, which is a useful optimization tool for copyable values and an essential prerequisite for move-only values.
[…]
By making Any a synonym for any Copyable, we can ensure that Any is itself always copyable at the cost of limiting it to only store copyable values. This redefinition would preserve the behavior of current code that uses Any. Of course, this means we need to introduce a new type that can hold any value whether it is copyable or not.
Previously:
Language Design Memory Management Optimization Programming Swift Programming Language
Dougall Johnson (Hacker News):
Generally translating each instruction only once has significant instruction-cache benefits – other emulators typically cannot reuse code when branching to a new target.
[…]
Given these constraints, the goal is generally to get as close to one-ARM-instruction-per-x86-instruction as possible, and the tricks described in the following sections allow Rosetta to achieve this surprisingly often. This keeps the expansion-factor as low as possible. For example, the instruction size expansion factor for an sqlite3 binary is ~1.64x (1.05MB of x86 instructions vs 1.72MB of ARM instructions).
[…]
All performant processors have a return-address-stack to allow branch prediction to correctly predict return instructions.
Rosetta 2 takes advantage of this by rewriting x86 CALL and RET instructions to ARM BL and RET instructions (as well as the architectural loads/stores and stack-pointer adjustments). This also requires some extra book-keeping, saving the expected x86 return-address and the corresponding translated jump target on a special stack when calling, and validating them when returning, but it allows for correct return prediction.
[…]
The Apple M1 has an undocumented extension that, when enabled, ensures instructions like ADDS, SUBS and CMP compute PF and AF and store them as bits 26 and 27 of NZCV respectively, providing accurate emulation with no performance penalty.
Previously:
Update (2022-12-14): Howard Oakley:
Whenever possible Rosetta completes its translation well before the code is required to be run. For some apps, this may occur when they’re installed on the Mac, but it can also be delayed until launch time.
Apple M1 ARM Macs Assembly Language Emulator Mac macOS 13 Ventura Optimization Rosetta
Howard Oakley:
You might think that apps are either running or they’re not, but there are actually four different states a macOS ap can be in (in addition to those a user shouldn’t directly encounter, such as suspended).
[…]
Intel apps running with Rosetta translation […] appear to persist far longer in an undead state than on Intel systems. I’m unsure whether this is deliberate, to minimise the cost of loading them again should the user decide to open that app once more, or a passing phase. But if you run many apps in Rosetta which join the ranks of the undead, it could get inconvenient.
[…]
When napping apps are restored after a restart, they aren’t fully loaded and put into App Nap. Instead, macOS starts to load them and then stops at _dyld_start, so they only take around 8 KB of memory and don’t open any of their other files, such as frameworks. […] This can cause strange problems with some apps which you may leave running in App Nap. When in App Nap, they can be awoken by different events as well as the user bringing them to the front. When they’re in this stopped state, they have insufficient code loaded to respond to events which would normally wake them from App Nap, unless you manually wake them up after starting up.
See also: Felix Schwarz.
Previously:
Mac macOS 11.0 Big Sur Rosetta
