Re: NSBlockOperation with +[sendSynchronousRequest sendSynchronousRequest:...] or async?
Always use the async API. For networking, there are *tons* of reasons to avoid your own threading (ie, CPU - battery consumption) when Apple does all that for your using their Async API (and only one global thread to manage the network) Look at the free WWDC videos from 2010, this is very well explained. Aurélien, Objective Decision Team On 20 janv. 2011, at 23:51, Rick Mann wrote: With the advent of code blocks and NSBlockOperation, it's a lot tidier, and easier, to write code using NSURLConnection, particularly in the presence of multiple operations. The approach is to use an NSBlockOperation and +[NSURLConnection sendSynchronousRequest:returningResponse:error:] to synchronously request a resource (which occurs on a separate thread). The alternative is to use the asynchronous methods, and then manage all the state necessary to keep track of multiple instances of the same request. I prefer the former approach, but does Apple still recommend the async approach? Or is there no real difference between the two? I'm running on iOS 4.x, on a single-core device, but I don't think these devices will remain single-core for long, and the same question applies to multicore Macs. Thanks, Rick ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/hugele.aurelien%40objective-decision.com This email sent to hugele.aurel...@objective-decision.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data mergeChangesFromContextDidSaveNotification: does not *completely* update the context ?
BTW, the main thread sent notification (when main thread moc is saved) does not contain the NSRefreshedObjects key. This would probably be a solution to my problem, but mergeChangesFromContextDidSaveNotification: either does not refresh objects (strange) or their is something wrong since objects are definitely refreshed, so why does NSRefreshedObjects key is not in the didSaveNotification ? Aurélien, Objective Decision Team Le 20 déc. 2010 à 06:49, Aurélien Hugelé a écrit : Hi! I think mergeChangesFromContextDidSaveNotification: does not work as most people expect: I have a mainthread and a subthread. My subthread updates a managed object (change one of the property value) and save. In the mainthread, I use [mainThreadContext mergeChangesFromContextDidSaveNotification:subThreadNotification]; and it merges the main thread context as expected (binded UI is updated) What is not expected is : 1/ asking the main thread for its updatedObjects (just after the mergeChangesFromContext... but before the save:) does not show the changes made in the subthread! So updated objects in subthread are not seen as updated in the main thread after the mergeChangesFromContext call! 2/ Saving the main thread generates a did save notification, that does not contain changes made in the subthread (and merged) ! The subthread is temporary (does it job in an NSOperation that terminates quickly), its context is also temporary. In the mainthread, *many* controllers are observers of the did save notification of the main thread context. How am I supposed to make them listen to changes made in a temporary, dumb, subthreaded managed context without using mergeChangesFromContext... call ??? I'm pertty sure, most developers expect the mergeChangesFromContextDidSaveNotification: API to really merge the data in the main thread context and set the merged updated objects as *really* updated, as if the change really occured in the main thread! Aurélien, Objective Decision Team ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/hugele.aurelien%40objective-decision.com This email sent to hugele.aurel...@objective-decision.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data mergeChangesFromContextDidSaveNotification: does not *completely* update the context ?
Thanks Ben, after thought, this is indeed very logical and can be expected when you know Core Data. I came to the same conclusion but you phrased it much better than me :) Aurélien, Objective Decision Team Le 21 déc. 2010 à 01:45, Ben Trumbull a écrit : On Dec 19, 2010, at 9:49 PM, Aurélien Hugelé wrote: Hi! I think mergeChangesFromContextDidSaveNotification: does not work as most people expect: I have a mainthread and a subthread. My subthread updates a managed object (change one of the property value) and save. In the mainthread, I use [mainThreadContext mergeChangesFromContextDidSaveNotification:subThreadNotification]; and it merges the main thread context as expected (binded UI is updated) What is not expected is : 1/ asking the main thread for its updatedObjects (just after the mergeChangesFromContext... but before the save:) does not show the changes made in the subthread! So updated objects in subthread are not seen as updated in the main thread after the mergeChangesFromContext call! 2/ Saving the main thread generates a did save notification, that does not contain changes made in the subthread (and merged) ! The subthread is temporary (does it job in an NSOperation that terminates quickly), its context is also temporary. In the mainthread, *many* controllers are observers of the did save notification of the main thread context. How am I supposed to make them listen to changes made in a temporary, dumb, subthreaded managed context without using mergeChangesFromContext... call ??? I'm pertty sure, most developers expect the mergeChangesFromContextDidSaveNotification: API to really merge the data in the main thread context and set the merged updated objects as *really* updated, as if the change really occured in the main thread! The method is merging the state into the receiving context purely from the perspective of results. Deleted objects are deleted, updated objects have new values, inserted objects exist. It does not replay the individual changes, nor does it guarantee any particular path or implementation for getting the state of MOC B to look like the state of MOC A. For efficiency, it prefers refreshing existing objects from the PSC's cache over replaying individual changes whenever possible. Refreshing is observable by KVO. These objects are also noted in the NSManagedObjectContextObjectsDidChangeNotification with the NSRefreshedObjectsKey. This is how NSArrayController observes these kinds of events. The objects aren't updated in the sense that they'll be saved again. Because they won't. They've already been saved a first time. They *were* updated, and NSManagedObjectContext's -updatedObjects reports the state about next upcoming save, not the last save. - Ben ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Core Data mergeChangesFromContextDidSaveNotification: does not *completely* update the context ?
Hi! I think mergeChangesFromContextDidSaveNotification: does not work as most people expect: I have a mainthread and a subthread. My subthread updates a managed object (change one of the property value) and save. In the mainthread, I use [mainThreadContext mergeChangesFromContextDidSaveNotification:subThreadNotification]; and it merges the main thread context as expected (binded UI is updated) What is not expected is : 1/ asking the main thread for its updatedObjects (just after the mergeChangesFromContext... but before the save:) does not show the changes made in the subthread! So updated objects in subthread are not seen as updated in the main thread after the mergeChangesFromContext call! 2/ Saving the main thread generates a did save notification, that does not contain changes made in the subthread (and merged) ! The subthread is temporary (does it job in an NSOperation that terminates quickly), its context is also temporary. In the mainthread, *many* controllers are observers of the did save notification of the main thread context. How am I supposed to make them listen to changes made in a temporary, dumb, subthreaded managed context without using mergeChangesFromContext... call ??? I'm pertty sure, most developers expect the mergeChangesFromContextDidSaveNotification: API to really merge the data in the main thread context and set the merged updated objects as *really* updated, as if the change really occured in the main thread! Aurélien, Objective Decision Team ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CoreData database sharing and migration
Hi Ben, Can you be kind enough to explain how Apple frameworks do that ? (multiple processes, single machine, one SQLite database) I'm thinking of CalendarStore, AddressBook framework. Can you describe what is the general idea behind those Apple frameworks? Aurélien, Objective Decision Team On 17 mars 2010, at 22:29, Ben Trumbull wrote: I am wondering whether it is possible to create a database in core data that can be opened by more than one application at the same time. It is currently impossible to handle one SQLite database with two instances of the same app. The problem is if user1 quits the app, the data is saved but user2's instance of the app doesn't recognize this file system change and just overwrites its version in memory. So the data from user1 is gone. Is there a way I can handle this? Second -- I am having more than two database versions now but still want to support my version 1.0 but the mapping model only allows one source model as well as only one target model. I would have to remove one version but that makes version 1.0 users' database unusable. Has anyone gotten something like this to work? Yes, several Apple frameworks use Core Data databases from multiple processes simultaneously with a single user account and single physical machine. Do you mean more than one application simultaneously on more than one physical computer over NFS/AFP/SMB ? Don't do that. Or do you mean an NSDocument based application using Core Data an SQLite store ? NSDocuments intentionally behave like TextEdit. Last writer wins, overwites everything. If so, you should be using a non-document based Core Data project template. - Ben ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/hugele.aurelien%40objective-decision.com This email sent to hugele.aurel...@objective-decision.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Where can I find Debug Profile Libraries for 10.6 ?
Hi lists, I'm cross posting because this was already discussed in both lists, sorry for that. I'm looking the the Debug Profile libraries that have been discussed here http://lists.apple.com/archives/cocoa-dev/2008/Mar/msg01098.html and http://developer.apple.com/mac/library/technotes/tn2004/tn2124.html#SECDEBUGLIB Ben T explained how to use them and it is very useful for Core Data in particular. Unfortunately they seem to have disappeared from connect.apple.com Can anyone provide me a link to download them? Thanks Aurélien, Objective Decision Team ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Long term performance of NSConnection
Are you sure you are not instantiating/creating/opening a connection each time? are you really reusing the same connection? Aurélien, Objective Decision Team On 2 juil. 09, at 21:29, Kevin Brock wrote: We've got an application that uses some NSConnection objects to call between binaries. An application calls interfaces of an object which is vended by a daemon. The calls between modules are made frequently, and during some testing I noticed a steady drop in perfomance of the application. I ran Shark, and saw that after a lot ( 1,000,000) calls across the API more than 95% of the time was being spent in 5 calls, all of which look like they're related to distributed objects: lookUpConnectionForProxy 30.5% lookUpLocalProxyForWireID 26.5% lookUpLocalObjectForProxy 22.8 lookUpOrCreateLocalProxyForObject 8.2% lookUpWireIDForProxy 7.6% I can't find any references to these functions on the net, and don't see anything in the docs that would explain this. We use a long term, persistent connection. The degradation starts very soon. Call Startup ~10,000 calls ~20,000 Calls lookUpConnectionForProxy0.4% 4.2% 14.6% lookUpLocalProxyForWireID 0.8% 12.4% 15.7% lookUpLocalObjectForProxy 0.3% 2.8% 8.8% lookUpOrCreateLocalProxyForObject 0.5% 3.3% 4.8% lookUpWireIDForProxy0.1% 0.7% 3.3% Is there something we are missing about the usage of the connection object? It looks like there's some table internal to the connection that's not being cleaned up. When I graph the actual perormance hit taken by the application (secs/1000 connections) it's essentially linear increase in time from 0 to 500,000 connections. When I run Shark on the daemon side for the 1,000,000 call case it shows three calls consuming 97% of the time Call Time lookUpConnectionForProxy58% lookUpWireIDForProxy28.9% lookUpOrCreateLocalProxyForObject 11.2% I'd really appreciate any suggestions about why this might be happening. Kevin Brock ap...@kevin.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/hugele.aurelien%40objective-decision.com This email sent to hugele.aurel...@objective-decision.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [Core Data] mergeChangesFromContextDidSaveNotification: and thread safety
Thanks for the explanation, I like when you have to bend the rules ;) Aurélien, Objective Decision Team On 29 mai 09, at 23:25, Ben Trumbull wrote: On May 29, 2009, at 2:49 AM, Aurélien Hugelé wrote: Core Data multithreading basic rule is to avoid passing managed objects across threads, and pass objectIDs instead. yup. To synchronize 2 mocs from 2 different threads (sharing the same psc), I use mergeChangesFromContextDidSaveNotification:. As Apple demonstrate in the documentation, I use performSelectorInMainThread: since I just want to synchronize my main moc, in the main thread, with inserted objects, created in a second moc, in a subthread. So there is no need to lock. Ok. But the mergeChangesFromContextDidSaveNotification: method uses the notification as an argument, and the userInfo of this notification contains managed objects, not objectIDs! Managed objects are then passed from sub thread to mainthread... This is supported. You may pass the NSNotification object from didSaveChanges to the mergeChangesFromContext... method on another MOC even across threads. Of course, if you yank the managed objects out of the NSNotification and use them in different threads yourself, that is a violation. Isn't it a violation of the basic rule described below? In a literal sense, it can appear that way. The specific implementation details of mergeChangesFromContextDidSaveNotification address the paradox. The framework gets to bend its own rules a touch in much the same way that an object accessing its own private ivars is still honoring encapsulation. You can download the debug version of Core Data from ADC and use the multithreading assertions. They enforce the rules, even on the framework itself :-) A lot of strange crashes with threads are actually very complicated memory management bugs. Something like malloc_history can be very useful for tracking those down. Instruments as well with its ObjectAlloc tool can provide stack traces for every retain and release ever on an object. - Ben ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
[Core Data] mergeChangesFromContextDidSaveNotification: and thread safety
Hi ! I'm having strange crashes in my threaded core data application. Happy WWDC is in few days! Core Data multithreading basic rule is to avoid passing managed objects across threads, and pass objectIDs instead. To synchronize 2 mocs from 2 different threads (sharing the same psc), I use mergeChangesFromContextDidSaveNotification:. As Apple demonstrate in the documentation, I use performSelectorInMainThread: since I just want to synchronize my main moc, in the main thread, with inserted objects, created in a second moc, in a subthread. So there is no need to lock. But the mergeChangesFromContextDidSaveNotification: method uses the notification as an argument, and the userInfo of this notification contains managed objects, not objectIDs! Managed objects are then passed from sub thread to mainthread... Isn't it a violation of the basic rule described below? Aurélien, Objective Decision Team ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
[Core Data] Can we use setValue:forKey: in *willSave* method of NSManagedObject?
Hi list!
In the documentation it is clearly stated that we should not trigger
change notifications in the *didSave* method of NSmanagedObject.
The willSave method is not very well described. In particular, can we
use setValue:forKey: (or trigger change notifications) inside it?
I usually do something like :
-(void)willSave
{
if([self isDeleted])
{
// cleanup some other object state
// or use [self setValue:Y forKey:X] here
}
}
And as a result I often get a strange exception :
Failed to process pending changes before save. The context is still
dirty after 100 attempts. Typically this recursive dirtying is caused
by a bad validation method, -willSave, or notification handler.
it seems that for *deleted* objects only, triggering change
notifications is now allowed.
Am I right ?
Aurélien,
Objective Decision Team
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: [Core Data] Difference between objectWithID: and a fetch self IN %@, someObjectIDs ????
That's very clear, thanks for the explanation! Aurélien, Objective Decision Team On 20 mai 09, at 21:15, Ben Trumbull wrote: In the main thread, using objectWithID: repeatedly on each objectID sent by the subthread returns the object that was inserted in the background thread. This is exactly what I want. But reading from the doc, it seems that we are encouraged to use a fetch using self IN %@,listOfObjectIDs instead of objectWithID: since it is faster for many objects... Unfortunately, this fetch returns 0 results (and yes this is the correct entity, store and moc...) The objects probably haven't been saved yet. what does objectWithID: *exactly* do that a fetch does not ?? Imagine the NSPersistentStoreCoordinator has a cache of row data for recently fetched or saved objects. This cache is used to fulfill faults quickly. Faulting becomes very slow when it needs to go all the way to the database due to a cache miss. The Core Data template in Instruments shows this. But cache hits are very fast. This is how most managed objects get initialized. Fetching always goes to disk and gets the latest values from the database. Those values are then added to the PSC's cache. -objectWithID: creates a fault. When you access the fault's data, it first tries to populate the data from the PSC's cache. If it can't, then it goes to disk. The documentation is showing how to load a number of objects at once. If the objects are unlikely to already be cached, then fetching all of them in 1 transaction will be much faster than faulting them in one at a time via -objectWithID: - Ben ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
[Core Data] Difference between objectWithID: and a fetch self IN %@, someObjectIDs ????
Hi list ! I have a subthread that sends to my main thread some objectIDs (of objects it inserted in the same store (same PSC)) I have 2 MOCs, one per thread, sharing the same PSC (following advices from the doc...) In the main thread, using objectWithID: repeatedly on each objectID sent by the subthread returns the object that was inserted in the background thread. This is exactly what I want. But reading from the doc, it seems that we are encouraged to use a fetch using self IN %@,listOfObjectIDs instead of objectWithID: since it is faster for many objects... Unfortunately, this fetch returns 0 results (and yes this is the correct entity, store and moc...) what does objectWithID: *exactly* do that a fetch does not ?? Thanks for your help. Aurelien Aurélien, Objective Decision Team ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [Core Data] Difference between objectWithID: and a fetch self IN %@, someObjectIDs ????
Hmmm, It seems I was using temporary objectIDs, not permanent ones... It was a nightmare with 10.4 because there was no way to get permanent objectIDs... now we can, and I've been overlooking that problem ;) Aurélien, Objective Decision Team On 20 mai 09, at 12:03, Aurélien Hugelé wrote: Hi list ! I have a subthread that sends to my main thread some objectIDs (of objects it inserted in the same store (same PSC)) I have 2 MOCs, one per thread, sharing the same PSC (following advices from the doc...) In the main thread, using objectWithID: repeatedly on each objectID sent by the subthread returns the object that was inserted in the background thread. This is exactly what I want. But reading from the doc, it seems that we are encouraged to use a fetch using self IN %@,listOfObjectIDs instead of objectWithID: since it is faster for many objects... Unfortunately, this fetch returns 0 results (and yes this is the correct entity, store and moc...) what does objectWithID: *exactly* do that a fetch does not ?? Thanks for your help. Aurelien Aurélien, Objective Decision Team ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/hugele.aurelien%40objective-decision.com This email sent to hugele.aurel...@objective-decision.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [Core Data] Difference between objectWithID: and a fetch self IN %@, someObjectIDs ????
There clearly is a difference since fetching is *much* slower that objectWithID: then testing using try/catch is the object is a fault or not. I'm puzzled... it works bout I would like to know the real difference here. Aurélien, Objective Decision Team On 20 mai 09, at 12:03, Aurélien Hugelé wrote: Hi list ! I have a subthread that sends to my main thread some objectIDs (of objects it inserted in the same store (same PSC)) I have 2 MOCs, one per thread, sharing the same PSC (following advices from the doc...) In the main thread, using objectWithID: repeatedly on each objectID sent by the subthread returns the object that was inserted in the background thread. This is exactly what I want. But reading from the doc, it seems that we are encouraged to use a fetch using self IN %@,listOfObjectIDs instead of objectWithID: since it is faster for many objects... Unfortunately, this fetch returns 0 results (and yes this is the correct entity, store and moc...) what does objectWithID: *exactly* do that a fetch does not ?? Thanks for your help. Aurelien Aurélien, Objective Decision Team ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/hugele.aurelien%40objective-decision.com This email sent to hugele.aurel...@objective-decision.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSCalendarDate to be deprecated
I too find NSCalendarDate tremendously useful. The fact that it is used (not to say necessary) in Sync Services let me believe it won't be deprecated. I hope Apple won't ask 3rd party developer dto rewrite their code using Sync Services ... Aurélien, Objective Decision Team On 18 août 08, at 17:22, David Riggle wrote: I wish NSCalendarDate could be fixed instead of discarded. I find it a convenient class, and it is heavily used in the standard sync schemas. If it must go, I hope somebody comes up with an open source replacement for it. :) Dave ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/hugele.aurelien%40objective-decision.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: DO woes
See DO problems posted just few days ago. Aurélien, Objective Decision Team On 29 mai 08, at 00:39, Western Botanicals wrote: Cocoa Experts, Thank you for your time. I am having a problem with DOs. I am working on this time clock system to track the timecards of employees. The following code works perfectly if run as a non- distributed system. When I try to set it up for a distributed system, it works once, and the second time I get the following on the server app: 2008-05-28 16:28:27.734 TimeKeeper[1454:813] *** NSDistantObject initWithCoder: 0xe not given away for conn 0x152170 2008-05-28 16:28:27.734 TimeKeeper[1454:813] *** - [NSConcretePortCoder decodeInvocation]: no local target If I step through the client-side I get this error on the server app, and both apps freeze up after stepping over line 94. To the code: http://pastebin.org/39323 (server-side is on top, client-side starts on line 67) Thank you, Justin Giboney ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/hugele.aurelien%40objective-decision.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: DO problems
I really wanted this patch to work, but in my tests, it does not work : Here is my backtrace. #0 0x939d4689 in _cache_getImp () #1 0x939c3bd0 in lookupMethodInClassAndLoadCache () #2 0x939c3c5b in object_cxxDestructFromClass () #3 0x939c4943 in _internal_object_dispose () #4 0x949f8f70 in NSDeallocateObject () #5 0x94a38570 in -[NSDistantObjectTableEntry dealloc] () #6 0x9156f5fa in CFRelease () #7 0x914fec8d in __CFArrayReleaseValues () #8 0x914ff00d in _CFArrayReplaceValues () #9 0x949faf6b in -[NSCFArray removeObjectAtIndex:] () #10 0x949fadd9 in -[NSMutableArray(NSMutableArray) removeObjectsAtIndexes:] () #11 0x94a3829a in invalidateProxy () #12 0x94a38023 in -[NSDistantObject dealloc] () #13 0x949f4d9f in NSPopAutoreleasePool () #14 0x25404120 in -[GDOPKPeer _connectToRemotePeerWithDictionary:] () #15 0x949fa15c in __NSThreadPerformPerform () #16 0x9156d62e in CFRunLoopRunSpecific () #17 0x9156dd18 in CFRunLoopRunInMode () #18 0x94a2db15 in -[NSRunLoop(NSRunLoop) runMode:beforeDate:] () #19 0x25407bca in -[GDOPKPeer _startPeer] () Aurélien, Objective Decision Team On 27 mai 08, at 21:08, Guy Meyer wrote: Welcome to the Leopard club. Yes there is DO code that works fine with Tiger and faults on Leopard. The issue described below refers to remote DO (i.e. socketports) as opposed to local DO. What I have found (after spending many hours on the issue) is that if there are multiple DO connections between the same addresses and one of them is invalidated/ closed the result is that all of them are faulting. The reason for this behavior is that when an nsconnection dies the socketport (which is also used by all other nsconnections to same address - in order to save resources) is getting released twice !!! ( and on Tiger once). When the count reach zero the port is invalidated/deallocated and all other nsconnections using said socketport fail. Because of that the bug is not always reproducible and appears to behave randomly - a nightmare. It seems that on Leopard (as opposed to Tiger) the socketport is observing the nsconnection and when it is closed and dies the socketport receives a notification and its reference count is decreased, beside some other code that decreases the count. The solution is unbelievable simple (and I have found that there are no memory management issues with this solution - but better test for yourself). You should cancel the port observation of NSConnectionDidDieNotification, just after creating the port, as follows: clientPort = (NSPort *)[[NSSocketPort alloc] initRemoteWithProtocolFamily:PF_INET socketType:SOCK_STREAM protocol:IPPROTO_TCP address:serverAddress]; [[NSNotificationCenter defaultCenter] removeObserver:clientPort name:NSConnectionDidDieNotification object:nil]; The above code does not create a problem on Tiger as the socketport is not observing NSConnectionDidDieNotification. A bug was opened by ADC on my behalf in January radr: //5706866 It is a shame that a bug like this (which is neither fixed nor publicly published) causes so many people to waste their time, but this is a discussion for another list, I guess. Update me if it works for you. Guy Meyer On May 27, 2008, at 2:41 AM, Ben Einstein wrote: I, too, have encountered this nasty little problem on Leopard. Works fine on Tiger, but I see this error followed by a nice crash about 10% of time on my DO servers with Leopard. I have no idea what's going on and why it's fine 80% of the time and not the other. Alex/Aurélien, have you found a solution? Thanks, Ben Einstein On Mar 25, 2008, at 9:12 AM, Aurélien Hugelé wrote: I encountered this very same problem with DO since Leopard. I noticed that a large part of the DO backend has been rewritten in Leopard. If you know how to fix/reproduce the problem, I'll be glad to know. I suggest trying your program on a Tiger/Tiger configuration.. I'm pretty sure it will work as expected. Aurélien, Objective Decision Team On 19 mars 08, at 01:58, Alexander Cohen wrote: Hi, i have a server and client communication through DO. Connections are all set up then the client send a message to the server with itself as the first argument. The server should then just reply right away to the client using the first argument as the proxy. Problem is, im getting the error below when trying to send the response form the server back to the client. Any ideas what might be happening? server received hello *** NSDistantObject initWithCoder: 0x2 not given away for conn 0x171a62f0 exceptionHandler:shouldHandleException: -[NSConcretePortCoder decodeInvocation]: no local target thanks AC ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription
Re: DO problems
I encountered this very same problem with DO since Leopard. I noticed that a large part of the DO backend has been rewritten in Leopard. If you know how to fix/reproduce the problem, I'll be glad to know. I suggest trying your program on a Tiger/Tiger configuration.. I'm pretty sure it will work as expected. Aurélien, Objective Decision Team On 19 mars 08, at 01:58, Alexander Cohen wrote: Hi, i have a server and client communication through DO. Connections are all set up then the client send a message to the server with itself as the first argument. The server should then just reply right away to the client using the first argument as the proxy. Problem is, im getting the error below when trying to send the response form the server back to the client. Any ideas what might be happening? server received hello *** NSDistantObject initWithCoder: 0x2 not given away for conn 0x171a62f0 exceptionHandler:shouldHandleException: -[NSConcretePortCoder decodeInvocation]: no local target thanks AC ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/hugele.aurelien%40objective-decision.com This email sent to [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
