smb big sur

You'd need to generate a set of Path instances from the characters in your text. This is only really suitable for small amounts, e.g. the Welcome animation or clock digits, etc., because it's not the most performant thing. Also, bigger text is better. Lastly, remember to wrap it all in a GlassEffectContainer to avoid each character's glass being rendered in a discrete pass. Actually lastly: you'll need to adjust the location of the text using .offset(x:y:) or by tweaking the path creation to include better offset translations. This is my quick & dirty attempt. Since .glassEffect() is designed similarly to a fill API, you need something non-empty to 'fill' with your text. Color.clear gets elided by the rendering engine, but what I've found is that Color.white.opacity(0) works to cause an actual (invisible) view to render and take up space during layout calculations. And now: the code! This was written for tvOS, so it uses BIG fonts and offsets to write big numbers. I had it draw a counter

[quote='869254022, Ionnier, /thread/809951?answerId=869254022#869254022, /profile/Ionnier'] I have to add that the daemon is a NSApplication. [/quote] Hmmm, that’s not good. A launchd daemon runs in the global execution context. Code running in that context cannot safely use GUI frameworks like AppKit. It’s only safe to use GUI frameworks from a GUI user login context. There’s a detailed description of this architecture in TN2083 Daemons and Agents. It’s super old, and there are a few areas where it’s suffering from bit rot, but the big picture stuff is still completely valid. If you break these rules you will run into all sorts of weird problems. Some of them show up immediately, and some of them lurk, waiting to cause you grief as the system evolves. Given that, I strongly recommend that you move away from this design. Coming back to System Extensions framework, it’s intended to be used by a GUI app to load and unload system extensions in response to user actions. Calling it from the global executi

So, in my earlier post, I said: Misunderstanding what the system was actually doing Which now leads to: To add more context, suppose the user is copying a file from one destination to a Network location. Am I correct that you've only actually seen this on Network copies? And (possibly) only some Network copies? As a side test, I'd be curious what happens if you tested with an AFP server instead of smb. I ask because of this: If it took longer than 5 seconds to complete the file inspection (which is well below the deadline for the auth event), then DesktopServicesHelper just deletes this file created at the destination. This we are observing in macOS Tahoe only. Strictly speaking, 5s is a somewhat odd amount of time. That may not sound like a long time, but it's an eternity at the time scale the kernel operates, particularly for any kind of local file system operation. You haven't actually said this, but I suspect you've found that the timing here is fairly precise— that is, it works fine with a delay

I see, thank you for pointing this out. So it is not a percentage, but an actual number of pages. Could you expand a little on how to interpret in your previous answer? So, stepping back for a moment, the basic issue here is deciding when should the kernel stop just blindly backing memory. It COULD (and, historically, did) just limit that to total available storage; however, in practice, that just means the machine grinds itself into a useless state without actually failing. So, what macOS does is artificially limit the VM system to ensure that the machine remains always in a functional state. The next question then becomes how to implement that limit. There are lots of places you COULD limit the VM system, but the problem is that the VM system is complicated enough that many obvious metrics don't really work. For example, purgable memory[1] means that simply dirty pages doesn't necessarily work“ - a process could have a very large number of dirty pages, but if they're all purgable, they shouldn't really coun

One of your targets is likely including the Info.plist file in the Copy Bundle Resources step. Select your project in the project viewer. It's the first item at the top, with the little blue icon. Select your main iOS target under the TARGETS section. In the big main pane, select the Build Settings tab. In the search field in the top-right, enter info, then scroll down to the Packaging section. You likely have Generate Info.plist file set to Yes. This is fine, leave it as it is. For each target you have (you may have only one): Select the target from the TARGETS section. In the big main pane, select the Build Phases tab. Expand the Copy Bundle Resources item. If Info.plist is listed there, remove it. (Do not remove InfoPlist.strings!) Hope this helps.

On macOS Tahoe, our application using the Endpoint Security Framework (ESF) observes that during file copies through Finder application, DesktopServicesHelper unlinks the source file if the ESF authorization response is delayed for ~5 seconds, even though the authorization event deadline remains 15 seconds, indicating that the process does not wait for the full ESF deadline before deleting the file. First, I want to start with a general clarification on this point: if the ESF authorization response is delayed for ~5 seconds, even though the authorization event deadline remains 15 seconds, indicating that the process does not wait for the full ESF deadline before deleting the file. In general, the EndpointSecurity system is implemented as a user space communication component built on top of kauth in the kernel. As such, the calling process has NO ability to bypass or circumvent ANY given check. The only reason any given check is passed is because kauth/EndpointSecurity allowed it to pass. Next, a note on this

True, it is a bit confusing without context. Argument tables basically put all power to you as the developer on how you want your rendering pipeline to interpret your GPU uploaded data. Also, you are free to replace the typical vertex input workflow (using stage_in and MTLVertexDescriptor) with raw buffer indexing in the shader. The Drawing a triangle with Metal 4 sample demonstrates that. So with the attributeStride parameter you can (loosely) recreate what stride does on MTLVertexBufferLayoutDescriptor. It is true that the C++ side structs will determine the underlying buffer layout for the shader, but what if you wanna have multiple variants of the buffer types? e.g. struct { simd_float2 position; simd_float4 color; } VertexData1; struct { simd_float2 position; simd_float4 color; simd_float3 normal; simd_float2 uv; } VertexData2; E.g.: Imagine you have a big vertex buffer that contains lots of data, but not all shaders use the same vertex inputs. Maybe you are interleaving or otherwise packing ver

I have now spent about 12 hours on this. I have pretty much tried everything now, including trying to completely uninstall Xcode and reinstall it as well as unpairing the watch from the phone. Where I am now is that I can get the phone to be seen by xcode but when it pairs and connects, when I click on the phone, it DOES NOT show that the watch is paired with the phone. Name Hostname Identifier State Model -------------- ------------------------------ ------------------------------------ ----------- -------------------------- Bryan's iPhone Bryans-iPhone.coredevice.local 9E04C304-C46E-5719-B97A-5FE176AA60B7 connected iPhone 17 Pro (iPhone18,1) Bryan’s iPad Bryans-iPad.coredevice.local 2B7A9ED0-E1E5-5C0B-9BD7-9BADC752CED4 unavailable iPad (A16) (iPad15,7) What is also the problem is that because I re-paired my watch, there is no developer mode available. So caught in some sort of nefarious loop. I will try waiting to the morning, but honestly, if this works then it is like a big WTF Apple. I really ap

This is such a ridiculous saga. I have spent the entire day trying to get this to work. First, I tried unpairing the watch and that was a big mistake. It took me an hour to finally get it paired, but now 100% of the time the device will not connect. I am moments away from returning this watch and iPhone and just giving up. Whatever engineers at Apple are responsible for this should be ashamed of themselves. I have worked on embedded systems a lot and this is just as bad, if not worse.

Apologies for the delayed update. Yesterday, we completed the rollout of your workaround solution, and our metrics indicate its effectiveness. The issue count has decreased significantly during the implementation, dropping from 6000 per day to 1000 per day as of today. Fabulous, that's great to hear and thank you for sharing concrete numbers. I was fairly confident it would work, but it's good to get independent confirmation. We would like to express our gratitude for the workaround solution you provided. You're very welcome. Currently, we have implemented the workaround only for incoming calls, as these were the primary source of issues observed in our app. We plan to extend the implementation to outbound calls as well. I don't know this for certain, but my guess is that the difference between the incoming/outgoing rate is mostly due to usage patterns and the details of your existing implementation. In particular, these two factors: I suspect most calls originate from the foreground (the user opening your ap