Core Data nested managed object contexts and frequent deadlocks
I have a parent MOC setup with NSPrivateQueueConcurrencyType and a persistent store coordinator set, it has a child MOC setup with NSMainQueueConcurrencyType. The idea being most of the long hard work and saves can be done on the private MOC freeing the main thread from blocking the UI. Unfortunately I seem to be running into a couple of situations that cause deadlocks. If the child MOC (on the main thread) is faulting in an object and the parent context is sent an -executeFetchRequest: or -save: it always deadlocks. Both operations are done within the context of a performBlock: for their respective MOCs although the docs seem to indicate that using a main thread concurrency type MOC on the main thread without performBlock: is fine. It appears that the private queue is waiting on the PSCs lock which the child context on the main thread has already locked. It appears that the child context (while holding the PSCs lock) is trying to dispatch_sync to the parent context and thus they are both waiting for each other. Is PriveQueue - MainQueue a supported configuration? It seems most people still have the parent context on the main thread. The main thread looks like this: #0 0x960f6c5e in semaphore_wait_trap () #1 0x04956bb5 in _dispatch_thread_semaphore_wait () #2 0x04955c8f in _dispatch_barrier_sync_f_slow () #3 0x04955dea in dispatch_barrier_sync_f () #4 0x01797de5 in _perform () #5 0x01798547 in -[NSManagedObjectContext(_NestedContextSupport) newValuesForObjectWithID:withContext:error:] () #6 0x0176416b in _PFFaultHandlerLookupRow () #7 0x01763f97 in -[NSFaultHandler fulfillFault:withContext:forIndex:] () #8 0x01763b75 in _PF_FulfillDeferredFault () #9 0x017639f2 in _sharedIMPL_pvfk_core () #10 0x017681a0 in _pvfk_11 () #11 0x0001b322 in -[FBUser sectionName] at /Users/mlink/Code/x/x/FBUser.m:62 #12 0x011a8813 in _NSGetUsingKeyValueGetter () #13 0x017a0652 in -[NSManagedObject valueForKey:] () #14 0x011ab8d5 in -[NSObject(NSKeyValueCoding) valueForKeyPath:] () #15 0x01851f72 in -[NSFetchedResultsController(PrivateMethods) _sectionNameForObject:] () #16 0x01853af6 in -[NSFetchedResultsController(PrivateMethods) _computeSectionInfo:error:] () #17 0x01850ea6 in -[NSFetchedResultsController performFetch:] () #18 0x0003a4fc in __62-[SYFriendsTableViewController updateFetchedResultsController]_block_invoke_0 () #19 0x01797af3 in developerSubmittedBlockToNSManagedObjectContextPerform () #20 0x049554f0 in _dispatch_main_queue_callback_4CF () #21 0x01b3e833 in __CFRunLoopRun () #22 0x01b3ddb4 in CFRunLoopRunSpecific () #23 0x01b3dccb in CFRunLoopRunInMode () #24 0x023d6879 in GSEventRunModal () #25 0x023d693e in GSEventRun () #26 0x0089aa9b in UIApplicationMain () #27 0x2656 in main at /Users/mlink/Code/x/x/main.mm:16 the private queue stack looks like this: #0 0x960f8876 in __psynch_mutexwait () #1 0x97e9e6af in pthread_mutex_lock () #2 0x0172ec22 in -[_PFLock lock] () #3 0x0172ebfa in -[NSPersistentStoreCoordinator lock] () #4 0x01746a8c in -[NSManagedObjectContext(_NSInternalAdditions) lockObjectStore] () #5 0x01745030 in -[NSManagedObjectContext executeFetchRequest:error:] () #6 0x0009d49f in -[NSManagedObjectContext(Additions) executeFetchRequest:] at /Users/mlink/Code/objc/C/C/NSManagedObjectContext+Additions.m:44 #7 0x0002177f in +[FBUser usersForFbids:inManagedObjectContext:] at /Users/mlink/Code/x/x/FBUser.m:435 #8 0x00021fc0 in __77+[FBUser updateUserFromGraphValues:inManagedObjectContext:completionHandler:]_block_invoke_0 at /Users/mlink/Code/x/x/FBUser.m:461 #9 0x0180f9f3 in developerSubmittedBlockToNSManagedObjectContextPerform_privateasync () #10 0x04954ecf in _dispatch_queue_drain () #11 0x04954d28 in _dispatch_queue_invoke () #12 0x049544af in _dispatch_worker_thread2 () #13 0x97ea1b24 in _pthread_wqthread () #14 0x97ea36fe in start_wqthread () ___ 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: Messed up UTIs in NSDocument-based application
What happens if you define two document types? My Document, Extension: myext, Identifier: My Document, Extension: myext, Identifier: com.mycompany.myext Although it might be better to use a new extension for the new doc type. On Jan 11, 2012, at 4:26 AM, Donald Ness wrote: So I recently shipped a document based application to the App Store with an unfortunate oversight: the UTI for the main document type was left blank, and wasn't exported. I had a name for it, but the identifier was straight up empty. Everything still worked great, but then I went to add another file type to the mix in the next version. The new file type is simply xml (conforms to public.xml). I set that up and dropped it into the document. This is when I caught the oversight on the first document type's UTI. I entered an appropriate identifier for my main document type, and added it to my exported UTI list. Now when I try to open my document types from my application, they are grayed out in the open dialog. To recap, I released a document-based application with this: Document Types: 1.) Name: My Document, Extension: myext, Identifier: Exported UTIs: (none) Imported UTIs: (none) And now I have this: Document Types: 1.) Name: My Document, Extension: myext, Identifier: com.mycompany.myext 2.) Name: My XML Document, Extension: xml, Identifier: public.xml Exported UTIs: com.mycompany.myext Imported UTIs: public.xml However, I my main document type is grayed out in the open dialog now. I'm at a loss as to how file types are associated with applications, and how to fix this issue. I really want to clean this up, so what's the best way to do so? ___ 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/mike%40michaelrthon.com This email sent to m...@michaelrthon.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
TBXML question
I have XML like this:
xml version=1.0 encoding=UTF-8?
users
user name=Eric Dolecki
playlist name=Iron Maiden source=Spotify/
playlist name=Kate Bush source=Pandora/
/user
/users
I am trying pull out the name and then each of the playlists. I need help
with my while loop (to get all the playlists) - I've bolded that bit.
- (void)parseThatXML:(TBXMLElement *)element {
do {
if(element - firstChild)
[self parseThatXML:element - firstChild];
if([[TBXML elementName:element] isEqualToString:@user]){
NSString *userName = [TBXML valueOfAttributeNamed:@name
forElement:element];
NSLog(@user: %@, userName);
* TBXMLElement *playlist = [TBXML childElementNamed:@playlist
parentElement:element];*
*while (playlist != nil) {*
*NSLog(@%@, [TBXML valueOfAttributeNamed:@name
forElement:playlist]); //infinite loop. how loop through all the playlists
for the user?*
*}*
//TBXMLElement *playlist = [TBXML childElementNamed:@playlist
parentElement:element];
//NSLog(@%@, [TBXML valueOfAttributeNamed:@name
forElement:playlist]);
}
} while ((element = element - nextSibling));
}
Google Voice: (508) 656-0622
Twitter: eric_dolecki XBoxLive: edolecki PSN: eric_dolecki
http://blog.ericd.net
___
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: Is slowing down bindings updates possible?
On Jan 12, 2012, at 10:57 PM, Andrew wrote:
I have a download controller with an NSMutableArray and an
NSArrayController hooked up to a NSTableView with a view based setup.
My array contains custom download objects. Each of those has a
NSURLDownload instance.
Basically, I am showing a browser-download like interface with size
downloaded, total expected size, a progress bar, time elapsed,
download rate and estimated time left.
It is all working wonderfully, but actually too well. Right now, I am
using will/didChangeValueForKey messages to notify observers when the
number of bytes downloaded changes. I am doing this in the callback
method:
- (void)download:(NSURLDownload *)download
didReceiveDataOfLength:(NSUInteger)length
{
[self willChangeValueForKey:@bytesDownloaded];
_bytesDownloaded += length;
[self didChangeValueForKey:@bytesDownloaded];
}
The result of this is that the UI updates really frequently and the
estimated time to complete and the download rate jump around a lot. I
would love it if I could tell cocoa to only update the UI once per
second instead of immediately when the property key changes.
It may well be your calculation. Do you keep a byte count array and average
over that? This kind of approach usually smooths out jumps in data size after
the first few.
Other than that, there isn't really anything you can do except update bytes
only via a timer, but even that won't work all the time if you consistently
experience data jumps. Unless you slow the timer down to a point that might be
user-unfriendly… This approach might require a lot of trial and error to get
right.
Anyway, all the timer callback has to do is send the willChange/DidChange,
which doesn't sound very messy to me.
Alternatively, of course, you could use BSD sockets and control the data
buffering to force consistency.
HTH,
Keary Suska
Esoteritech, Inc.
Demystifying technology for your home or business
___
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: Is slowing down bindings updates possible?
Why don't you just decouple your UI from the by-the-millisecond download
process? For example, you could update calculated values whenever the value of
bytesDownloaded changes but use a NSTimer to update the display of those values
maybe once or twice a second. The display is then sampling the download process
periodically rather than recording every single change, which should also
reduce the amount of time spent redrawing the display.
On Jan 12, 2012, at 9:57 PM, Andrew wrote:
I have a download controller with an NSMutableArray and an
NSArrayController hooked up to a NSTableView with a view based setup.
My array contains custom download objects. Each of those has a
NSURLDownload instance.
Basically, I am showing a browser-download like interface with size
downloaded, total expected size, a progress bar, time elapsed,
download rate and estimated time left.
It is all working wonderfully, but actually too well. Right now, I am
using will/didChangeValueForKey messages to notify observers when the
number of bytes downloaded changes. I am doing this in the callback
method:
- (void)download:(NSURLDownload *)download
didReceiveDataOfLength:(NSUInteger)length
{
[self willChangeValueForKey:@bytesDownloaded];
_bytesDownloaded += length;
[self didChangeValueForKey:@bytesDownloaded];
}
The result of this is that the UI updates really frequently and the
estimated time to complete and the download rate jump around a lot. I
would love it if I could tell cocoa to only update the UI once per
second instead of immediately when the property key changes.
With a bit of work I could probably set up a proxy object for each
download that would do something like that and use timer, but it would
be a lot of messy code. I could also just delay updating the
_bytesDownloaded on a queue. Or a third idea is to cache the estimated
calc time and rate and then only recalculate the value at most once
per second.
Any other brighter ideas? Thoughts?
___
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: LSSharedFileListInsertItemURL/SMLoginItemSetEnabled and sandbox
Anyone aware of sample code for the suggested helper app that manages the login items via SMLoginItemSetEnabled? Not battle tested yet but seems to work... https://github.com/tcurdt/TCLoginItemHelper Still need to find a nice way to get bundle id into the subproject. But that's more a Xcode integration question. cheers, Torsten ___ 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
Child windows appear to move when entering full-screen mode / how to detect full-screen transition
I have an app that is using borderless child windows to suspend controls over
an instance of NSScrollView. When entering full-screen (on Lion) the child
windows appear to move, I assume to make sure they are within the confines of
the parent window and full-screen dimensions.
I tried to compensate for this by manually verifying and reseting the relative
position of the child windows once the transition occurs. Only my attempts to
detect and react to this transition have failed. I've tried the following all
of which never get invoked:
- (void)applicationDidChangeScreenParameters:(NSNotification*)notification
{
MCLogFuncEntry();
// update child window relative positions
[self.bannerWindow setFrameOrigin:NSMakePoint(self.window.frame.origin.x +
kBannerWindowOrigin.x,
self.window.frame.origin.y +
kBannerWindowOrigin.y)];
[self.buttonWindow setFrameOrigin:NSMakePoint(self.window.frame.origin.x +
kButtonWindowOrigin.x,
self.window.frame.origin.y +
kButtonWindowOrigin.y)];
}
- (NSSize)window:(NSWindow*)window
willUseFullScreenContentSize:(NSSize)proposedSize
{
MCLogFuncEntry();
if ( window == self.window )
{
// update child window relative positions
[self.bannerWindow
setFrameOrigin:NSMakePoint(self.window.frame.origin.x + kBannerWindowOrigin.x,
self.window.frame.origin.y + kBannerWindowOrigin.y)];
[self.buttonWindow
setFrameOrigin:NSMakePoint(self.window.frame.origin.x + kButtonWindowOrigin.x,
self.window.frame.origin.y + kButtonWindowOrigin.y)];
}
return NSMakeSize(kImageWidth, kImageHeight);
}
- (NSApplicationPresentationOptions)window:(NSWindow*)window
willUseFullScreenPresentationOptions:(NSApplicationPresentationOptions)proposedOptions
{
if ( NO == [[NSUserDefaults standardUserDefaults] developerMode] )
{
NSApplicationPresentationOptions options =
NSApplicationPresentationDisableAppleMenu |
NSApplicationPresentationDisableHideApplication |
NSApplicationPresentationDisableProcessSwitching |
NSApplicationPresentationFullScreen |
NSApplicationPresentationHideDock |
NSApplicationPresentationHideMenuBar;
if ( proposedOptions != options )
{
return options;
}
}
return proposedOptions;
}
- (void)windowDidResize:(NSNotification*)notification
{
MCLogFuncEntry(); // just wanted to see if this gets called through the
delegate. Nope.
}
So, how can I be notification when entering or exiting full-screen mode on
Lion. Any insights on why the windows move would also be greatly appreciated.
The current document on NSWindow is out of date for Lion. I can only find
WinPanel.pdf dated 2009-11-27.
-Michael
___
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 nested managed object contexts and frequent deadlocks
On Jan 13, 2012, at 12:39 AM, Michael Link wrote: the docs seem to indicate that using a main thread concurrency type MOC on the main thread without performBlock: is fine. It is, otherwise you couldn't (say) bind to a managed object you fetched via a main-queue context on OS X. What OS version(s) are you seeing this with? It appears that the private queue is waiting on the PSCs lock which the child context on the main thread has already locked. It appears that the child context (while holding the PSCs lock) is trying to dispatch_sync to the parent context and thus they are both waiting for each other. Is PriveQueue - MainQueue a supported configuration? It seems most people still have the parent context on the main thread. Using a parent private-queue context and a child main-queue context is actually a good design. I'm not sure about your deadlock; does it still occur if you don't use -performBlock: on your main-queue context but just interact with it directly? -- Chris ___ 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 nested managed object contexts and frequent deadlocks
On Jan 13, 2012, at 3:45 PM, Chris Hanson wrote: On Jan 13, 2012, at 12:39 AM, Michael Link wrote: the docs seem to indicate that using a main thread concurrency type MOC on the main thread without performBlock: is fine. It is, otherwise you couldn't (say) bind to a managed object you fetched via a main-queue context on OS X. What OS version(s) are you seeing this with? iOS 5.0 on simulator and iOS 5.0.1 on iPhone. It appears that the private queue is waiting on the PSCs lock which the child context on the main thread has already locked. It appears that the child context (while holding the PSCs lock) is trying to dispatch_sync to the parent context and thus they are both waiting for each other. Is PriveQueue - MainQueue a supported configuration? It seems most people still have the parent context on the main thread. Using a parent private-queue context and a child main-queue context is actually a good design. I'm not sure about your deadlock; does it still occur if you don't use -performBlock: on your main-queue context but just interact with it directly? Yes, in exactly the same way. I'm starting to think the problem is with NSFetchedResultsController which is always stuck at performFetch: when these deadlocks occur. Most of the time it will be stuck trying to fault in an object as a result of asking for it's section name. As a test I tried to reproduce what the FRC does and performed the executeFetchRequest: and then iterated through the results asking each object for it's section name. And this doesn't cause a deadlock. If I leave the FRC to do performFetch: after I do my test it will still deadlock there. I'm 99% sure that the FRC has a synchronization problem with nested contexts. -- Michael___ 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: Child windows appear to move when entering full-screen mode / how to detect full-screen transition
http://developer.apple.com/library/mac/#documentation/cocoa/reference/NSWindowDelegate_Protocol/Reference/Reference.html
windowWillEnterFullScreen: etc.
Also I recommend
http://developer.apple.com/library/mac/#samplecode/FullScreenWindow/Introduction/Intro.html
Sketch+Fullscreen is also useful, but that seems to have vanished.
On Jan 13, 2012, at 12:47 PM, Michael Crawford wrote:
I have an app that is using borderless child windows to suspend controls over
an instance of NSScrollView. When entering full-screen (on Lion) the child
windows appear to move, I assume to make sure they are within the confines of
the parent window and full-screen dimensions.
I tried to compensate for this by manually verifying and reseting the
relative position of the child windows once the transition occurs. Only my
attempts to detect and react to this transition have failed. I've tried the
following all of which never get invoked:
- (void)applicationDidChangeScreenParameters:(NSNotification*)notification
{
MCLogFuncEntry();
// update child window relative positions
[self.bannerWindow setFrameOrigin:NSMakePoint(self.window.frame.origin.x +
kBannerWindowOrigin.x,
self.window.frame.origin.y +
kBannerWindowOrigin.y)];
[self.buttonWindow setFrameOrigin:NSMakePoint(self.window.frame.origin.x +
kButtonWindowOrigin.x,
self.window.frame.origin.y +
kButtonWindowOrigin.y)];
}
- (NSSize)window:(NSWindow*)window
willUseFullScreenContentSize:(NSSize)proposedSize
{
MCLogFuncEntry();
if ( window == self.window )
{
// update child window relative positions
[self.bannerWindow
setFrameOrigin:NSMakePoint(self.window.frame.origin.x + kBannerWindowOrigin.x,
self.window.frame.origin.y + kBannerWindowOrigin.y)];
[self.buttonWindow
setFrameOrigin:NSMakePoint(self.window.frame.origin.x + kButtonWindowOrigin.x,
self.window.frame.origin.y + kButtonWindowOrigin.y)];
}
return NSMakeSize(kImageWidth, kImageHeight);
}
- (NSApplicationPresentationOptions)window:(NSWindow*)window
willUseFullScreenPresentationOptions:(NSApplicationPresentationOptions)proposedOptions
{
if ( NO == [[NSUserDefaults standardUserDefaults] developerMode] )
{
NSApplicationPresentationOptions options =
NSApplicationPresentationDisableAppleMenu |
NSApplicationPresentationDisableHideApplication |
NSApplicationPresentationDisableProcessSwitching |
NSApplicationPresentationFullScreen |
NSApplicationPresentationHideDock |
NSApplicationPresentationHideMenuBar;
if ( proposedOptions != options )
{
return options;
}
}
return proposedOptions;
}
- (void)windowDidResize:(NSNotification*)notification
{
MCLogFuncEntry(); // just wanted to see if this gets called through the
delegate. Nope.
}
So, how can I be notification when entering or exiting full-screen mode on
Lion. Any insights on why the windows move would also be greatly
appreciated. The current document on NSWindow is out of date for Lion. I
can only find WinPanel.pdf dated 2009-11-27.
-Michael
___
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/lrucker%40vmware.com
This email sent to lruc...@vmware.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: TBXML question
Hi Eric,
Have you considered using Libxml and xpath? Take a look at
http://cocoawithlove.com/2008/10/using-libxml2-for-parsing-and-xpath.html.
Phil
On Jan 13, 2012, at 9:23 AM, Eric E. Dolecki wrote:
I have XML like this:
xml version=1.0 encoding=UTF-8?
users
user name=Eric Dolecki
playlist name=Iron Maiden source=Spotify/
playlist name=Kate Bush source=Pandora/
/user
/users
I am trying pull out the name and then each of the playlists. I need help
with my while loop (to get all the playlists) - I've bolded that bit.
- (void)parseThatXML:(TBXMLElement *)element {
do {
if(element - firstChild)
[self parseThatXML:element - firstChild];
if([[TBXML elementName:element] isEqualToString:@user]){
NSString *userName = [TBXML valueOfAttributeNamed:@name
forElement:element];
NSLog(@user: %@, userName);
* TBXMLElement *playlist = [TBXML childElementNamed:@playlist
parentElement:element];*
*while (playlist != nil) {*
*NSLog(@%@, [TBXML valueOfAttributeNamed:@name
forElement:playlist]); //infinite loop. how loop through all the playlists
for the user?*
*}*
//TBXMLElement *playlist = [TBXML childElementNamed:@playlist
parentElement:element];
//NSLog(@%@, [TBXML valueOfAttributeNamed:@name
forElement:playlist]);
}
} while ((element = element - nextSibling));
}
Google Voice: (508) 656-0622
Twitter: eric_dolecki XBoxLive: edolecki PSN: eric_dolecki
http://blog.ericd.net
___
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/philip.vallone%40verizon.net
This email sent to philip.vall...@verizon.net
___
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: TBXML question
On Jan 13, 2012, at 5:16 PM, Philip Vallone wrote:
Have you considered using Libxml and xpath? Take a look at
http://cocoawithlove.com/2008/10/using-libxml2-for-parsing-and-xpath.html.
libxml is very powerful but it’s also very low-level, and quite grungy to use.
If there’s an Obj-C API available it’d be best to use that unless you’re 100%
certain it won’t do what you need.
* TBXMLElement *playlist = [TBXML childElementNamed:@playlist
parentElement:element];*
*while (playlist != nil) {*
*NSLog(@%@, [TBXML valueOfAttributeNamed:@name
forElement:playlist]); //infinite loop. how loop through all the playlists
for the user?*
*}*
So, I haven’t used TBXML, but it looks like what you need is something like
“playlist = playlist-nextSibling” at the bottom of the while loop. The DOM
tree is chained together as a linked list of siblings at each level, a pretty
typical approach.
—Jens___
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
Adding an observer to an NSOperation crashes my app.
Hi all. Working on an iPhone app and encountered a stumper. I have various kinds of operations (derived from NSOperation) to do async queries over the Internet. As is the norm, I determine when they're finished by observing their isFinished property, and getting the results in observeValueForKeyPath (which as you may know is called in a secondary thread). This works great all over my app. Except... When one particular type of operation finishes, I want to create a follow-up type of operation using info from the first. But when I do so, calling addObserver on the operation crashes my app with a bad access. Since observeValueForKeyPath is called in a secondary thread, I tried creating the follow-up operation and setting the observer on the main thread. Didn't help. This is being done in observeValueForKeyPath: *GetMessagesOperation* msgOp = [[GetMessagesOperation alloc] initWithUserID:_user.getID() sinceLast:true includeSystem:true includeUser:false skipRows:0 maxCount:50 DBManager:_pDatabaseMgr]; * *[msgOp addObserver:self forKeyPath:@isFinished options:0 context:getMessageContext]; * *[_operationQueue addOperation:msgOp]; * *[msgOp release];* The context is a void* to a string; I use the same syntax for many other operations that work fine. Here's how the contexts are defined: *static void* systemInfoContext = (void*)@sys; static void* validateUserContext = (void*)@user; static void* getMessageContext = (void*)@msg;* It crashes instantly on that addObserver call. Anybody have a guess here? Thanks! Gavin ___ 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
