A little more info. Also, just as a FYI allTagLabels did return all tags, but customTagLabels didn't return all custom tags I had created. Going through the differences will actually probably be

There's unfortunately no API in macOS to retrieve the tags that you have created yourself in the Finder. The solution is to parse the

Spotlight has to store them in order to find them, so they'd be stored there as well as where ever the file system puts them. -- Steve Mills Drummer, Mac geek

I doubt it's Spotlight that stores them because they also work on vols where the Spotlight index is disabled.

I’m not sure if it’s officially documented somewhere, but what I’d do is add some tags to a particular file, see what that file looks like from the Terminal (e.g., xattr), and do a search for

Maybe this is managed by Spotlight (i.e. Metadata.framework) now? Since it’s Spotlight that actually stores the tags. —Jens

I wonder if anyone has figured out a way to retrieve ALL available Finder tags on Monterey and later? On pre-Monterey systems, it was possible by reading this file:

Would you use a sizeToFit or sizeThatFits method call to do that for you even after you’ve set the attributed text? I have some old Objective-C libraries that I wrote for CVS to set iOS app text to

Doesn’t AttributedString uses a dictionary to set its attributes, including font and font size? -Laurent. -- Laurent Daudelin laurent@... Skype: LaurentDaudelin Logiciels Némésys

I have a Watch-App using SwiftUI. let fontSize = 40.0 struct WatchContentView: View { @State var timeAttributedStr = AttributedString("--") let timer = Timer.publish(every: 1, tolerance: 0.1,

If you haven’t already, submit a feedback request with your source, Xcode version, and platform used that demonstrate the issue. -- Gary

I was wondering about the P/E cores too. Perhaps you can avoid that difference by using GCD + QOS to explicitly run the calculation on the desired kind of core. Though I guess we don’t actually know

Steve Cannon explained that: • Arm has “madd” which does multiply and add in one go. But has a latency of more than one cycle. • x86_64 doesn't have a multiply-add instruction. Using

For those of us not in that forum, what was the explanation? You have our attention with this one... Jack

As you see, I got an excellent in depth answer and also some very helpful tips for improvements. So no reason to be embarrassed at all. Rather I have to thank you for a very good and fruitful

OK, this is embarrassing. I’m so used to looking at Swift code these days, that my brain just automatically translated your code into Swift, and I never realized it was C. So the Swift forums

I really think you should start by asking this question over in the Swift forums, in case there is some compiler-specific answer that can immediately explain the result. It could be a compiler code

I did this: typedef uint32_t limb; typedef uint64_t bigLimb; const uint len = 50000; const int shiftLimb = sizeof(limb) * 8; limb *someArray = malloc( len * sizeof(limb) ); bigLimb someBig

It might seem like a primitive approach, but logging with time stamps should be able to highlight where the suckyness is. Run a log that displays the time delta from the last logging statement so

The results are stable and repeatable and do not depend on the order. Gerriet.