Post not yet marked as solved
@Polyphonic: Thanks for the reply. I understand what @unchecked Sendable means and I agree that this would mean that NSImage is Sendable – but the thing that prompted this question was that the extension is marked as unavailable on all platforms and versions (because of the *). So what does it mean when a class conforms to a protocol in an unavailable extension?
The following experiments use “Complete” for SWIFT_STRICT_CONCURRENCY:
Xcode 14, macOS 13 SDK, macOS 13 Deployment Target
I tried returning an NSImage from an async top-level method and that gives me this warning:
Xcode 15, macOS 14 SDK, macOS 14 Deployment Target
The same code compiles without the hint at the import Cocoa line, which I would interpret to mean that the macOS 14 SDK has been fully audited for Sendability and suppressing the warnings isn’t an option anymore (not that I would want to do that):
Just to make sure, I also tried it with an actor:
So the compiler definitely does know that NSImage is not Sendable, which means the availability annotation in that extension I originally mentioned does not add Sendability conformance but instead seems to document the opposite. This can also be verified by adding the following (unwise) extension to the code in the screenshots, which “fixes” the warning:
extension NSImage: @unchecked Sendable {}
Post not yet marked as solved
Interesting, copying your code into a new project also works for me 🤷♂️
Thanks for all your input! I guess time will tell and we’ll see whether what I’m trying to do will be possible at some point. As long as there’s the single line workaround using a separate function, it’s all right.
Post not yet marked as solved
Oh, you’re right, my code doesn’t compile due to the duplicate generic parameter name T. Sorry about that. And yes, what you wrote is pretty much where I intended to end up. Weirdly enough, it doesn’t compile, though, and all I get is a nondescript “Command SwiftCompile failed with a nonzero exit code” 😕 In my actual code where I stumbled across this, it does compile, though. I tried but I couldn’t manage to get my sample code (or yours) to compile…
FWIW, here’s my actual code:
/// Adds a side effect that is performed whenever any of the tweaks’ value changes.
@discardableResult
public static func addSideEffect<each Value>(to tweak: repeat Tweak<each Value>, sideEffect: @escaping () -> Void) -> (repeat Tweak<each Value>.SideEffectID) {
func add<V>(to tweak: Tweak<V>) -> CustomSideEffect.ID {
let sideEffect = CustomSideEffect(action: sideEffect)
tweak.tweaks.store.sideEffectPerformer.add(.custom(sideEffect), for: tweak.id)
return sideEffect.id
}
return (repeat add(to: each tweak))
}
Of course I found the solution immediately after posting this 🤦♂️
The trick is to get the parameter pack into the return value somehow. I did it using a typealias inside the generic type:
struct Tweak<Value> {
typealias Name = String
var name: Name
var value: Value
}
func names<each Value>(of tweak: repeat Tweak<each Value>) -> (repeat Tweak<each Value>.Name) {
return (repeat (each tweak).name)
}
And now it works as it should 🙂
Post not yet marked as solved
Note: This is fixed in iOS 15.
Post not yet marked as solved
FYI: This is fixed in macOS 10.15.1
FYI: This bug is fixed in macOS 10.15.1
Post not yet marked as solved
I don’t know what OS you’re targeting, but the (now deprecated) kauth APIs could help here. You can listen for vnode events and whenever you detect in the callback that a vnode is being executed you can get the path from the respective vnode using vn_getpath(). You’d have to cache that information for every process that launches and later you can look the paths up by PID.
Post not yet marked as solved
Following these instructions should fix this: https://obdev.at/support/index.html?product=LS&topic=faq&entry=245694426255130That’s an FAQ entry from the Little Snitch support page. I’m one of the developers of Little Snitch and we have a problem that probably has the same root cause: The kernel cache update is triggered correctly, but the cache isn’t really updated. This means that uninstalled kexts remain in the kernel cache (as in your case) or that updating existing kexts doesn’t work (as in the case of Little Snitch).Just about everyone who updates to macOS Catalina is hit by this problem and we have a massive support burden thanks to this problem. I hope Apple fixes this soon!
