Post

Replies

Boosts

Views

Activity

Reply to Unhandled exception finding default Directory URL '+[NSPersistentContainer defaultDirectoryURL] Could not conjure up a useful location for writing persistent stores.'
import Benchmark import CoreData let benchmarks = { Benchmark("Benchmark") { benchmark in let _ = NSPersistentContainer.defaultDirectoryURL } } This crashes: *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '+[NSPersistentContainer defaultDirectoryURL] Could not conjure up a useful location for writing persistent stores.' *** First throw call stack: ( 0 CoreFoundation 0x0000000189caa2ec __exceptionPreprocess + 176 1 libobjc.A.dylib 0x000000018978e158 objc_exception_throw + 60 2 CoreData 0x00000001904d9034 __44+[NSPersistentContainer defaultDirectoryURL]_block_invoke + 0 3 CoreData 0x00000001905c3f74 $sSo21NSPersistentContainerC8CoreDataE19defaultDirectoryURL10Foundation0G0VvgZ + 40 4 Benchmarks 0x00000001047530e4 $s10Benchmarks10benchmarks9BenchmarkACCSgycvpfiAEycfU_yADcfU_ + 92 5 Benchmarks 0x0000000104703608 $s9Benchmark0A8ExecutorV3runySayAA0A6ResultVGA2ACF + 2640 6 Benchmarks 0x0000000104728f34 $s9Benchmark0A6RunnerV3runyyYaKFTY0_ + 6768 7 Benchmarks 0x0000000104725cb5 $s9Benchmark0A11RunnerHooksPAAE4mainyyYaFZTQ1_ + 1 8 Benchmarks 0x00000001047535a5 $sIetH_yts5Error_pIegHrzo_TR10async_MainTf3npf_nTQ0_ + 1 9 libswift_Concurrency.dylib 0x00000002513d6149 _ZL22completeTaskAndReleasePN5swift12AsyncContextEPNS_10SwiftErrorE + 1 ) libc++abi: terminating due to uncaught exception of type NSException
Topic: App & System Services SubTopic: iCloud Tags:
Aug ’24
Reply to Unhandled exception finding default Directory URL '+[NSPersistentContainer defaultDirectoryURL] Could not conjure up a useful location for writing persistent stores.'
CoreData: error: Failed to create directory file:///Users/rick/Library/Application%20Support/Benchmarks: NSCocoaErrorDomain (513) CoreData: fault: Unhandled exception finding default Directory URL '+[NSPersistentContainer defaultDirectoryURL] Could not conjure up a useful location for writing persistent stores.' https://github.com/vanvoorden/2024-08-26 I am running into these errors when attempting to run a benchmark on a SwiftData context from the 2024-08-26 repo. The errors seem to be harmless… the benchmark continues without crashing on those unhandled exceptions. https://github.com/vanvoorden/2024-08-02/ I seem to have no problem running against SwiftData from a different Swift Package Executable (2024-08-02). This package seems to build and run with no errors. This package also creates the expected directory under ~/Library/Application%20Support/2024-08-02. I don't yet completely understand what is happening… but there seems to be some reason why Benchmarks is failing to create that extra directory under Application%20Support. I can also run Benchmarks with no errors after I add the Application%20Support/Benchmarks directory manually from mac Finder. The benchmarks seem to be running correctly even after printing those errors… so I am not sure if there is anything important to fix in the Benchmarks package for now.
Topic: App & System Services SubTopic: iCloud Tags:
Aug ’24
Reply to SwiftData ModelContext fails to delete all model instances from unit tests.
The reference of delete(model:where:includeSubclasses:) doesn't mention that behavior, and I believe that is because delete(model:where:includeSubclasses:) goes down directly to the store to delete the objects (for better performance), like what NSBatchDeleteRequest does, and doesn't discard the unsaved objects in the context. Ahh… interesting! This is very valuable insight. Thanks! I am beginning to understand this behavior more. A follow up question is I am still looking for one "single shot" function to delete all model instances (including staged and pending models prior to save). I can think of (at least) three options: Explicitly save before attempting to delete all: func testSaveAndDelete() throws { let modelContext = ModelContext(container) modelContext.insert(Item()) print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 1) modelContext.insert(Item()) print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 2) try modelContext.save() try modelContext.delete(model: Item.self) print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 0) } Attempt to delete all and then follow up with an iteration through all remaining: func testSaveAndDeleteAndIterate() throws { let modelContext = ModelContext(container) modelContext.insert(Item()) print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 1) try modelContext.save() modelContext.insert(Item()) print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 2) try modelContext.delete(model: Item.self) print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 1) for model in try modelContext.fetch(FetchDescriptor<Item>()) { modelContext.delete(model) } print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 0) } Iterate through all inserted models prior to delete all: func testSaveAndIterateAndDelete() throws { let modelContext = ModelContext(container) modelContext.insert(Item()) print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 1) try modelContext.save() modelContext.insert(Item()) print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 2) for model in modelContext.insertedModelsArray { // TODO: filter only for `item` models! :D modelContext.delete(model) } print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 1) try modelContext.delete(model: Item.self) print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 0) } All of these options seem to operate correctly and pass my tests. any opinion about which pattern might provide the right choice to optimize for memory and CPU? My intuition tells me the most efficient pattern might depend on the model schema and the state of this context at any point in time. Any more insight about what might be the right option here? Thanks!
Topic: App & System Services SubTopic: iCloud Tags:
Aug ’24
Reply to SwiftData ModelContext fails to delete all model instances from unit tests.
Did you try to save the model context after doing the deletion? When using a model context created with ModelContext(modelContainer), you need to save the changes explicitly because the auto-save doesn't come to play, which is different from when you use mainContext. Hmm… I can give that a try. My question then would be is why do these two functions: extension Store { public func delete<T>(model: T.Type) throws where T : PersistentModel { try self.modelContext.delete(model: model) } } extension Store { public func deleteWithIteration<T>(model: T.Type) throws where T : PersistentModel { for model in try self.fetch(model) { self.modelContext.delete(model) } } } Seem to show different behavior without an explicit save being called? Calling the delete function (with no explicit save) returns with no error thrown and no models have been deleted. Calling the deleteWithIteration function (with no explicit save) returns with no error thrown and all models have been deleted. Should those two functions not return with the same state (either both functions delete all models or both functions delete no models)?
Topic: App & System Services SubTopic: iCloud Tags:
Aug ’24
Reply to How to debug this?
With Xcode, you can use -com.apple.CoreData.ConcurrencyDebug 1 as a launch argument to do the check. By any chance do we know if there are any known issues that might lead to false positive errors when using the ConcurrencyDebug argument with SwiftData? I am seeing some concurrency errors with a SwiftData stack… but I'm looking through how this stack is set up and I can't understand what could be leading to any kind of race condition. Ahh… I don't know how to delete this comment and move it to a thread. Sorry about that!
Topic: UI Frameworks SubTopic: SwiftUI
Jul ’24
Reply to Unhandled exception finding default Directory URL '+[NSPersistentContainer defaultDirectoryURL] Could not conjure up a useful location for writing persistent stores.'
Building the SPM plug in with disable-sandbox seems to work around the errors… but I'm still not clear why a model context specified as an in-memory context needs a valid URL on the system to begin work.
Topic: App & System Services SubTopic: iCloud Tags:
Replies
Boosts
Views
Activity
Aug ’24
Reply to Unhandled exception finding default Directory URL '+[NSPersistentContainer defaultDirectoryURL] Could not conjure up a useful location for writing persistent stores.'
https://github.com/swiftlang/swift-package-manager/issues/6948 This might be another version of this error from SPM plug ins.
Topic: App & System Services SubTopic: iCloud Tags:
Replies
Boosts
Views
Activity
Aug ’24
Reply to Unhandled exception finding default Directory URL '+[NSPersistentContainer defaultDirectoryURL] Could not conjure up a useful location for writing persistent stores.'
import Benchmark import CoreData let benchmarks = { Benchmark("Benchmark") { benchmark in let _ = NSPersistentContainer.defaultDirectoryURL } } This crashes: *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '+[NSPersistentContainer defaultDirectoryURL] Could not conjure up a useful location for writing persistent stores.' *** First throw call stack: ( 0 CoreFoundation 0x0000000189caa2ec __exceptionPreprocess + 176 1 libobjc.A.dylib 0x000000018978e158 objc_exception_throw + 60 2 CoreData 0x00000001904d9034 __44+[NSPersistentContainer defaultDirectoryURL]_block_invoke + 0 3 CoreData 0x00000001905c3f74 $sSo21NSPersistentContainerC8CoreDataE19defaultDirectoryURL10Foundation0G0VvgZ + 40 4 Benchmarks 0x00000001047530e4 $s10Benchmarks10benchmarks9BenchmarkACCSgycvpfiAEycfU_yADcfU_ + 92 5 Benchmarks 0x0000000104703608 $s9Benchmark0A8ExecutorV3runySayAA0A6ResultVGA2ACF + 2640 6 Benchmarks 0x0000000104728f34 $s9Benchmark0A6RunnerV3runyyYaKFTY0_ + 6768 7 Benchmarks 0x0000000104725cb5 $s9Benchmark0A11RunnerHooksPAAE4mainyyYaFZTQ1_ + 1 8 Benchmarks 0x00000001047535a5 $sIetH_yts5Error_pIegHrzo_TR10async_MainTf3npf_nTQ0_ + 1 9 libswift_Concurrency.dylib 0x00000002513d6149 _ZL22completeTaskAndReleasePN5swift12AsyncContextEPNS_10SwiftErrorE + 1 ) libc++abi: terminating due to uncaught exception of type NSException
Topic: App & System Services SubTopic: iCloud Tags:
Replies
Boosts
Views
Activity
Aug ’24
Reply to Unhandled exception finding default Directory URL '+[NSPersistentContainer defaultDirectoryURL] Could not conjure up a useful location for writing persistent stores.'
CoreData: error: Failed to create directory file:///Users/rick/Library/Application%20Support/Benchmarks: NSCocoaErrorDomain (513) CoreData: fault: Unhandled exception finding default Directory URL '+[NSPersistentContainer defaultDirectoryURL] Could not conjure up a useful location for writing persistent stores.' https://github.com/vanvoorden/2024-08-26 I am running into these errors when attempting to run a benchmark on a SwiftData context from the 2024-08-26 repo. The errors seem to be harmless… the benchmark continues without crashing on those unhandled exceptions. https://github.com/vanvoorden/2024-08-02/ I seem to have no problem running against SwiftData from a different Swift Package Executable (2024-08-02). This package seems to build and run with no errors. This package also creates the expected directory under ~/Library/Application%20Support/2024-08-02. I don't yet completely understand what is happening… but there seems to be some reason why Benchmarks is failing to create that extra directory under Application%20Support. I can also run Benchmarks with no errors after I add the Application%20Support/Benchmarks directory manually from mac Finder. The benchmarks seem to be running correctly even after printing those errors… so I am not sure if there is anything important to fix in the Benchmarks package for now.
Topic: App & System Services SubTopic: iCloud Tags:
Replies
Boosts
Views
Activity
Aug ’24
Reply to SwiftData ModelContext fails to delete all model instances from unit tests.
The reference of delete(model:where:includeSubclasses:) doesn't mention that behavior, and I believe that is because delete(model:where:includeSubclasses:) goes down directly to the store to delete the objects (for better performance), like what NSBatchDeleteRequest does, and doesn't discard the unsaved objects in the context. Ahh… interesting! This is very valuable insight. Thanks! I am beginning to understand this behavior more. A follow up question is I am still looking for one "single shot" function to delete all model instances (including staged and pending models prior to save). I can think of (at least) three options: Explicitly save before attempting to delete all: func testSaveAndDelete() throws { let modelContext = ModelContext(container) modelContext.insert(Item()) print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 1) modelContext.insert(Item()) print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 2) try modelContext.save() try modelContext.delete(model: Item.self) print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 0) } Attempt to delete all and then follow up with an iteration through all remaining: func testSaveAndDeleteAndIterate() throws { let modelContext = ModelContext(container) modelContext.insert(Item()) print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 1) try modelContext.save() modelContext.insert(Item()) print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 2) try modelContext.delete(model: Item.self) print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 1) for model in try modelContext.fetch(FetchDescriptor<Item>()) { modelContext.delete(model) } print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 0) } Iterate through all inserted models prior to delete all: func testSaveAndIterateAndDelete() throws { let modelContext = ModelContext(container) modelContext.insert(Item()) print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 1) try modelContext.save() modelContext.insert(Item()) print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 2) for model in modelContext.insertedModelsArray { // TODO: filter only for `item` models! :D modelContext.delete(model) } print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 1) try modelContext.delete(model: Item.self) print(try modelContext.fetchCount(FetchDescriptor<Item>()) == 0) } All of these options seem to operate correctly and pass my tests. any opinion about which pattern might provide the right choice to optimize for memory and CPU? My intuition tells me the most efficient pattern might depend on the model schema and the state of this context at any point in time. Any more insight about what might be the right option here? Thanks!
Topic: App & System Services SubTopic: iCloud Tags:
Replies
Boosts
Views
Activity
Aug ’24
Reply to SwiftData ModelContext fails to delete all model instances from unit tests.
If that doesn't help, I'd be interested in taking a closer look if you can provide a sample project to demo the issue. https://github.com/vanvoorden/2024-08-02 Here is a repo to reproduce the behaviors. I am not seeing any change when I explicitly save my model context.
Topic: App & System Services SubTopic: iCloud Tags:
Replies
Boosts
Views
Activity
Aug ’24
Reply to SwiftData ModelContext fails to delete all model instances from unit tests.
Did you try to save the model context after doing the deletion? When using a model context created with ModelContext(modelContainer), you need to save the changes explicitly because the auto-save doesn't come to play, which is different from when you use mainContext. Hmm… I can give that a try. My question then would be is why do these two functions: extension Store { public func delete<T>(model: T.Type) throws where T : PersistentModel { try self.modelContext.delete(model: model) } } extension Store { public func deleteWithIteration<T>(model: T.Type) throws where T : PersistentModel { for model in try self.fetch(model) { self.modelContext.delete(model) } } } Seem to show different behavior without an explicit save being called? Calling the delete function (with no explicit save) returns with no error thrown and no models have been deleted. Calling the deleteWithIteration function (with no explicit save) returns with no error thrown and all models have been deleted. Should those two functions not return with the same state (either both functions delete all models or both functions delete no models)?
Topic: App & System Services SubTopic: iCloud Tags:
Replies
Boosts
Views
Activity
Aug ’24
Reply to SwiftData does not work on a background Task even inside a custom ModelActor.
I'm seeing similar behavior (ModelActor eagerly dispatching work to main) in Xcode_16_beta_3. Has anyone heard if this is supposed to be fixed… or should we plan to continue to ship with these workarounds going forward when the new OS is released?
Topic: App & System Services SubTopic: iCloud Tags:
Replies
Boosts
Views
Activity
Jul ’24
Reply to How to debug this?
With Xcode, you can use -com.apple.CoreData.ConcurrencyDebug 1 as a launch argument to do the check. By any chance do we know if there are any known issues that might lead to false positive errors when using the ConcurrencyDebug argument with SwiftData? I am seeing some concurrency errors with a SwiftData stack… but I'm looking through how this stack is set up and I can't understand what could be leading to any kind of race condition. Ahh… I don't know how to delete this comment and move it to a thread. Sorry about that!
Topic: UI Frameworks SubTopic: SwiftUI
Replies
Boosts
Views
Activity
Jul ’24
Reply to How to resolve SwiftUI.DynamicProperty on MainActor compiler warning on 6.0?
I'm seeing this same error from Xcode_16_beta_3. Is there anything that can be communicated to engineers about the future direction of DynamicProperty? It seems like the type of work that could be expected to be on main… is the explicit MainActor requirement on DynamicProperty coming later before the new OS goes to production?
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Replies
Boosts
Views
Activity
Jul ’24
Reply to OSSignposts not working after upgrade to Sonoma (14.2.1)
This workaround ("last x seconds") unblocked me for now from macOS 14.4.1 (23E224) and Instruments 15.3 (15E204a). Are there any other places I can go to follow along for a more robust fix that might land soon? Thanks!
Replies
Boosts
Views
Activity
Apr ’24
Reply to How to resolve SwiftUI.DynamicProperty on MainActor compiler warning on 6.0?
@eskimo Sounds good. Thanks!
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Replies
Boosts
Views
Activity
Apr ’24
Reply to Instruments in Xcode 15.3 not showing symbols
I able to see macOS symbols from Instruments 15.3 but my symbols from iPhone sim are gone.
Replies
Boosts
Views
Activity
Mar ’24
Reply to Aggregating Xcode Metrics Measure Test Reporting in Xcode or Command Line
You might be able to use xcresulttool for this. I'll take a look. Thanks!
Replies
Boosts
Views
Activity
Jan ’24
Reply to SwiftUI.View Compiler Errors when Property Wrapper is Annotated with MainActor
I found this article quite enlightening: https://lucasvandongen.dev/swift_actors_and_protocol_extensions.php @enodev I'll take a look. Thanks!
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Replies
Boosts
Views
Activity
Jan ’24