Re: Program Crash
Heh probably shouldn't vent here if you don't expect any comments. Definitely not the place to start off topic convo. Regardless, zero issues over here with Safari as well. Report the crash to Apple with the data dump from the console. You could have a hard to find issue cropping up. It could also be a sign of hardware going bad or something corrupt software wise. Have you tried a clean install? Please excuse mobile typos On Jan 30, 2015, at 8:31 AM, Raglan T. Tiger r...@crusaderrabbit.net wrote: On Jan 30, 2015, at 9:04 AM, Ronald Hofmann pro...@jumbosoft.de wrote: I asume you are using some extensions or/and Flash which are resposinble for that. I know this sis off topic but it is just frustrating and I choose to vent. No flash, no extensions. Enough, no more comments. -rags ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/cody%40servalsoft.com This email sent to c...@servalsoft.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: copyWithZone archive/unarchive
On Jan 30, 2015, at 7:26 AM, Trygve Inda cocoa...@xericdesign.com wrote: On Jan 29, 2015, at 9:44 PM, Trygve Inda cocoa...@xericdesign.com wrote: However, naming conventions expect copy to not be autoreleased so should the above really be: return ([copy retain]); Yes, if you're really still not using ARC ;-) —Jens I am not using ARC - this is a large project that has existed for a long time and I see no reason to change it. Just wanted to point out that you can adopt ARC on a per-file basis. Switching back and forth between them can be a bit of a mind bender, but that may be preferable to devoting a chunk of time to a wholesale conversion. --Kyle Sluder ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSCalendar and NSDates prior to October 15, 1582
The documentation for the Date and Time Programming Guide for iOS does not seem to be telling the truth, or perhaps I'm doing something wrong. From https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/DatesAndTimes/Articles/dtHist.html The Julian to Gregorian Transition NSCalendar models the transition from the Julian to Gregorian calendar in October 1582. During this transition, 10 days were skipped. This means that October 15, 1582 follows October 4, 1582. All of the provided methods for calendrical calculations take this into account, but you may need to account for it when you are creating dates from components. Dates created in the gap are pushed forward by 10 days. For example October 8, 1582 is stored as October 18, 1582. This code: NSCalendar *calendar = [NSCalendar calendarWithIdentifier:NSCalendarIdentifierGregorian]; DDLog(@calendar = %@ ,calendar.calendarIdentifier); NSDateComponents *components = [[NSDateComponents alloc] init]; [components setYear:1582]; [components setMonth:10]; [components setDay:10]; NSDate *date = [calendar dateFromComponents:components]; DDLog(@components2 = %@,components); DDLog(@date = %@,date); yields this result: DateLimit: calendar = gregorian DateLimit: components2 = NSDateComponents: 0x7be5b610 Calendar Year: 1582 Month: 10 Day: 10 DateLimit: date = 1582-10-10 07:52:58 + Every other calculation I've tried seems to indicate that NSCalendar provides a proleptic Gregorian calendar - i.e. it does not adjust for the October 15 following October 4 transition. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: copyWithZone archive/unarchive
On Jan 29, 2015, at 9:44 PM, Trygve Inda cocoa...@xericdesign.com wrote: However, naming conventions expect copy to not be autoreleased so should the above really be: return ([copy retain]); Yes, if you're really still not using ARC ;-) —Jens I am not using ARC - this is a large project that has existed for a long time and I see no reason to change it. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
[no subject]
One last thing ... Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0020 VM Regions Near 0x20: -- __TEXT 00010ca2d000-00010ca2e000 [4K] r-x/rwx SM=COW /System/Library/StagedFrameworks/Safari/WebKit.framework/Versions/A/XPCServices/com.apple.WebKit.WebContent.xpc/Contents/MacOS/com.apple.WebKit.WebContent Application Specific Information: Bundle controller class: BrowserBundleController Process Model: Multiple Web Processes Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.WebCore 0x00010daf0ae1 WebCore::TextIterator::range() const + 49 1 com.apple.WebCore 0x00010daf09a0 WebCore::CharacterIterator::range() const + 32 2 com.apple.WebCore 0x00010db2cf90 WebCore::characterSubrange(WebCore::CharacterIterator, int, int) + 48 3 com.apple.WebCore 0x00010db2cf36 WebCore::TextIterator::subrange(WebCore::Range*, int, int) + 134 4 com.apple.WebCore 0x00010dc1dd10 WebCore::AlternativeTextController::applyAlternativeTextToRange(WebCore::Range const*, WTF::String const, WebCore::AlternativeTextType, WTF::VectorWebCore::DocumentMarker::MarkerType, 0ul, WTF::CrashOnOverflow const) + 1648 -rags ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Program Crash
On Jan 30, 2015, at 9:04 AM, Ronald Hofmann pro...@jumbosoft.de wrote: I asume you are using some extensions or/and Flash which are resposinble for that. I know this sis off topic but it is just frustrating and I choose to vent. No flash, no extensions. Enough, no more comments. -rags ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Program Crash
If my products crashed 50 times a day like Safari I would be out of business. Apple records record profits and puts out a piece of shite application, Safari. -rags ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Program Crash
What are you talking about. I'm using Safari very often and can't rember the last time I had a crash. I asume you are using some extensions or/and Flash which are resposinble for that. Regards Ronald Hofmann --- Am 30.01.2015 um 16:43 schrieb Raglan T. Tiger r...@crusaderrabbit.net: If my products crashed 50 times a day like Safari I would be out of business. Apple records record profits and puts out a piece of shite application, Safari. -rags ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/prolog%40jumbosoft.de This email sent to pro...@jumbosoft.de ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Core Data concurrency during import of folder contents
I'm trying to learn Core Data. I have a working document model hooked up to a table view (OS X). I have an import method that uses FSDirectoryEnumerator to add an object for each file in the folder. Oky doke! But that blocks for a few seconds while it loops. So I'm trying to make it threaded. One example I saw uses GCD. It kinda seemed to work when I had a bunch of printfs in there so I could watch it progress, but when I took them out it just crashed at some point, and it still blocked any sort of user events. Next I tried sticking the entire import operation into a block via NSOperationQueue's addOperationWithBlock:. That throws because some set was being changed by multiple threads. Then I tried the suggestion of using a private NSManagedObjectContext in the block. That got me somewhere, but of course the data didn't populate my table. I tried the NSManagedObjectContextDidSaveNotification trick, but I couldn't get that to work. Reading the Concurrency with Core Data page online says the information is outdated. Where do I find current documentation? Or better yet, an actual example that actually works? My brain is about to explode, and nobody wants to clean that up. -- Steve Mills Drummer, Mac geek ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to avoid user interaction in WebView
On Jan 30, 2015, at 7:47 AM, Juanjo Conti jjco...@carouselapps.com wrote: Hi! This is my first email in this list. I'm working with Cocoa (using Swift) on a Mac Os X screensaver. I'd like to use a WebView to show different web pages but I don't want the user to be able to interact with the page. This is: no clicking, no scrolling, no keystrokes firing events in the web pages... How can I achieve this? The easiest and most resilient approach might be to add a local event monitor (using +[NSEvent addLocalMonitor…]) that filters out all keyboard and mouse events targeted at your window. Especially since you probably want any of these actions to dismiss the screensaver. You’ll want to be careful to restrict this only to the window that draws your screensaver, and only to keyboard/mouse/other input events. --Kyle Sluder ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
How to avoid user interaction in WebView
Hi! This is my first email in this list. I'm working with Cocoa (using
Swift) on a Mac Os X screensaver.
I'd like to use a WebView to show different web pages but I don't want the
user to be able to interact with the page. This is: no clicking, no
scrolling, no keystrokes firing events in the web pages...
How can I achieve this?
I was able to do
window?.ignoresMouseEvents = true
to avoid user scrolling
and
// WebUIDelegate Protocol method
override func webView(_: WebView, contextMenuItemsForElement: [NSObject
: AnyObject]!, defaultMenuItems: [AnyObject]!) - [AnyObject]! {
return nil
}
to to avoid right click on WebView to show a context menu.
But this is not enough. Key strokes are a problem. For example, if I'm
showing Twitter web page and a user press 'n', Twitter opens a text area
and you are allow to type there and effectively tweet.
So what I'm considering now is to have a transparent view in front of the
WebView to make it capture all the user interaction. I was able to place
this TransparentView on top of the WebView but events are still reaching
the WebView. This is my current TransparentView implementation:
class TransparentView : NSView {
override func drawRect(dirtyRect: NSRect) {
super.drawRect(dirtyRect)
//NSColor.clearColor().set()
var green = NSColor(calibratedRed: 0, green: 1, blue: 0, alpha: 0.5)
green.set()
NSBezierPath.fillRect(bounds)
}
override func keyDown(theEvent: NSEvent) {}
override func hitTest(aPoint: NSPoint) - NSView? {
return nil
}
override func becomeFirstResponder() - Bool {
return true
}
override func acceptsFirstMouse(_ : NSEvent) - Bool {
return true
}
override var canBecomeKeyView: Bool { return true }
}
You can see there my tries to avoid events reach WebView.
What do you think? Am I wrong in the way I'm trying to solve the problem?
If not, how can I make the TransparentView to catch all the events?
Thanks in advance,
--
Juanjo Conti jjconti http://goog_2023646312@carouselapps.com
jjco...@carouselapps.com
--
Carousel Apps Limited, registered in England Wales with registered number
7689440 and registered office Unit 2 Artbrand Studios, 7 Leathermarket
Street, London SE1 3HN. Any communication sent by or on behalf of Carousel
App Ltd or any of its subsidiary, holding or affiliated companies or
entities (together Watu) is confidential and may be privileged or
otherwise protected. If you receive it in error please inform us and then
delete it from your system. You should not copy it or disclose its contents
to anyone. Messages sent to and from Watu may be monitored to ensure
compliance with our internal policies and to protect our business. Emails
are not secure and cannot be guaranteed to be error free. Anyone who
communicates with us by email is taken to accept these risks.
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Modernising dragging problem
I'm updating some older code that uses the now-deprecated [NSView
dragImage:at:offset:pasteboard:source:slideback:] to use NSDraggingSession and
pals. Note that this older code works just fine, I've never had any issues with
it. I'm doing this mostly just to clear out compiler warnings, though my
instinct tells me not to fix code that isn't broken.
Sadly its replacement is broken.
In order to use NSDraggingItem, I first need to make sure the stuff I'm
dragging supports NSPasteboardWriting. I've done that, it seems straightforward
enough. Then I build a NSDraggingItem and use the same image I previously used,
so there's nothing new there. Finally I use [NSView
beginDraggingSessionWithItems:event:source:].
Nothing shows up. No image, nothing drags. I can break on the
NSPasteboardWriting methods and see that they are being called, so it seems to
be trying to write the correct things to the pasteboard. Nothing is logged.
After this, use of the legacy dragging methods elsewhere in the app also fail
to work - it's like whatever I did in this drag session messes up the dragging
system altogether. Obviously I'm doing something wrong, but I've been over the
docs and am just not getting it.
One thing is that the docs state that this new dragging method returns
immediately and the drag itself is somehow magically handled on the next turn
of the event loop. I think the older approach kept control for the duration of
the drag. That seems like a very different situation from the app's point of
view, and makes updating legacy code that expects it to keep control quite
difficult. That might be where things are messing up, so I'll look into that...
unless anyone can spot an obvious problem otherwise. Or would it just be better
to stick with working code and ignore the deprecation warnings? Those warnings
really go against the grain of everything I've ever learned about coding which
is if it ain't broke don't fix it.
Here's the code:
- (void)dragStyleOrSymbol:(idDKOLibraryObjectProtocol) obj
event:(NSEvent*) event source:(id) sourceObject slideBack:(BOOL) slideBack
{
NSAssert( obj != nil, @can't drag a nil style or symbol);
// can pass in nil to mean self
if( sourceObject == nil )
sourceObject = self;
// create the drag image
NSImage* dragImage = [obj image];
NSPoint mdLoc = [self convertPoint:[event locationInWindow]
fromView:nil];
mdLoc.x -= [dragImage size].width * 0.5;
mdLoc.y -= [dragImage size].height * 0.5;
#if (LEGACY_ CODE)
NSPasteboard* dragPBoard = [NSPasteboard
pasteboardWithName:NSDragPboard];
// put the object on the pasteboard
[obj copyToPasteboard:dragPBoard];
// start dragging it
[self dragImage:dragImage at:mdLoc offset:NSZeroSize event:event
pasteboard:dragPBoard source:sourceObject slideBack:slideBack];
#else
NSDraggingItem* dragItem = [[[NSDraggingItem alloc]
initWithPasteboardWriter:obj] autorelease];
NSRect dragFrame;
dragFrame.origin = mdLoc;
dragFrame.size = dragImage.size;
[dragItem setDraggingFrame:dragFrame contents:dragImage];
NSDraggingSession* session = [self
beginDraggingSessionWithItems:@[dragItem] event:event source:sourceObject];
session.animatesToStartingPositionsOnCancelOrFail = slideBack;
#endif
}
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: copyWithZone archive/unarchive
On Jan 30, 2015, at 7:26 AM, Trygve Inda cocoa...@xericdesign.com wrote: On Jan 29, 2015, at 9:44 PM, Trygve Inda cocoa...@xericdesign.com wrote: However, naming conventions expect copy to not be autoreleased so should the above really be: return ([copy retain]); Yes, if you're really still not using ARC ;-) —Jens I am not using ARC - this is a large project that has existed for a long time and I see no reason to change it. Just wanted to point out that you can adopt ARC on a per-file basis. Switching back and forth between them can be a bit of a mind bender, but that may be preferable to devoting a chunk of time to a wholesale conversion. Do you see non-ARC code becoming obsolete? I could probably start moving it to ARC slowly but it is hard to justify time spent on something that is not really needed. I have not run into any serious bugs or unexplained crashes due to messed up retain/release. (touching wood of course). T. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to avoid user interaction in WebView
For the record, I'm capturing: NSEventMask.RightMouseDownMask | NSEventMask.RightMouseUpMask | NSEventMask.LeftMouseDownMask | NSEventMask.LeftMouseUpMask | NSEventMask.MouseMovedMask | NSEventMask.KeyDownMask | NSEventMask.KeyUpMask | NSEventMask.ScrollWheelMask An to exit I'm returning: NSEvent.keyEventWithType(NSEventType.KeyDown, location: NSPoint(x: 0, y:0), modifierFlags: NSEventModifierFlags(), timestamp: NSTimeInterval(), windowNumber: 1, context: nil, characters: imposiblekeyscombination, charactersIgnoringModifiers: imposiblekeyscombination, isARepeat: false, keyCode: 0) On Fri, Jan 30, 2015 at 3:09 PM, Juanjo Conti jjco...@carouselapps.com wrote: Thanks! this approach is hopeful! Now I just need to figure out which NSEvent return for all the captured events, so the screensaver close properly. I'll let you know my advances. Thanks again, On Fri, Jan 30, 2015 at 2:03 PM, Kyle Sluder k...@ksluder.com wrote: On Jan 30, 2015, at 7:47 AM, Juanjo Conti jjco...@carouselapps.com wrote: Hi! This is my first email in this list. I'm working with Cocoa (using Swift) on a Mac Os X screensaver. I'd like to use a WebView to show different web pages but I don't want the user to be able to interact with the page. This is: no clicking, no scrolling, no keystrokes firing events in the web pages... How can I achieve this? The easiest and most resilient approach might be to add a local event monitor (using +[NSEvent addLocalMonitor…]) that filters out all keyboard and mouse events targeted at your window. Especially since you probably want any of these actions to dismiss the screensaver. You’ll want to be careful to restrict this only to the window that draws your screensaver, and only to keyboard/mouse/other input events. --Kyle Sluder -- Juanjo Conti jjconti http://goog_2023646312@carouselapps.com jjco...@carouselapps.com Software Engineer - Carousel Apps https://carouselapps.com -- Juanjo Conti jjconti http://goog_2023646312@carouselapps.com jjco...@carouselapps.com Software Engineer - Carousel Apps https://carouselapps.com -- Carousel Apps Limited, registered in England Wales with registered number 7689440 and registered office Unit 2 Artbrand Studios, 7 Leathermarket Street, London SE1 3HN. Any communication sent by or on behalf of Carousel App Ltd or any of its subsidiary, holding or affiliated companies or entities (together Watu) is confidential and may be privileged or otherwise protected. If you receive it in error please inform us and then delete it from your system. You should not copy it or disclose its contents to anyone. Messages sent to and from Watu may be monitored to ensure compliance with our internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free. Anyone who communicates with us by email is taken to accept these risks. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to avoid user interaction in WebView
Thanks! this approach is hopeful! Now I just need to figure out which NSEvent return for all the captured events, so the screensaver close properly. I'll let you know my advances. Thanks again, On Fri, Jan 30, 2015 at 2:03 PM, Kyle Sluder k...@ksluder.com wrote: On Jan 30, 2015, at 7:47 AM, Juanjo Conti jjco...@carouselapps.com wrote: Hi! This is my first email in this list. I'm working with Cocoa (using Swift) on a Mac Os X screensaver. I'd like to use a WebView to show different web pages but I don't want the user to be able to interact with the page. This is: no clicking, no scrolling, no keystrokes firing events in the web pages... How can I achieve this? The easiest and most resilient approach might be to add a local event monitor (using +[NSEvent addLocalMonitor…]) that filters out all keyboard and mouse events targeted at your window. Especially since you probably want any of these actions to dismiss the screensaver. You’ll want to be careful to restrict this only to the window that draws your screensaver, and only to keyboard/mouse/other input events. --Kyle Sluder -- Juanjo Conti jjconti http://goog_2023646312@carouselapps.com jjco...@carouselapps.com Software Engineer - Carousel Apps https://carouselapps.com -- Carousel Apps Limited, registered in England Wales with registered number 7689440 and registered office Unit 2 Artbrand Studios, 7 Leathermarket Street, London SE1 3HN. Any communication sent by or on behalf of Carousel App Ltd or any of its subsidiary, holding or affiliated companies or entities (together Watu) is confidential and may be privileged or otherwise protected. If you receive it in error please inform us and then delete it from your system. You should not copy it or disclose its contents to anyone. Messages sent to and from Watu may be monitored to ensure compliance with our internal policies and to protect our business. Emails are not secure and cannot be guaranteed to be error free. Anyone who communicates with us by email is taken to accept these risks. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data concurrency during import of folder contents
I prefer the GCD method but there are a few details that cause people trouble when combining GCD with CoreData. 1. A named GCD queue may guarantee serial processing but it does not guarantee that it will always use the same thread 2. NSManagedObjectContexts are not thread safe, and it’s not just a problem of you avoiding access from two threads at the same time. Only access the MOC from the thread on which it was created. 3 MOCs are light weight, so don’t worry about the premature optimization when creating and destroying them... unless it becomes an issue. In other words a private MOC is not the complete answer. Inside your block you need to create a new MOC, save it once you’ve completed your long running data collection process and then destroy it at the end of the block. You should have another MOC that you keep around, waiting on the main thread to be made aware of the save, so that you can handle the changes in your FRC. This is not the whole story (you can use child MOCs for a little more sophistication) but this should you going in the right direction. __ Terrence On Jan. 30, 2015, at 9:20 AM, Steve Mills sjmi...@mac.com wrote: I'm trying to learn Core Data. I have a working document model hooked up to a table view (OS X). I have an import method that uses FSDirectoryEnumerator to add an object for each file in the folder. Oky doke! But that blocks for a few seconds while it loops. So I'm trying to make it threaded. One example I saw uses GCD. It kinda seemed to work when I had a bunch of printfs in there so I could watch it progress, but when I took them out it just crashed at some point, and it still blocked any sort of user events. Next I tried sticking the entire import operation into a block via NSOperationQueue's addOperationWithBlock:. That throws because some set was being changed by multiple threads. Then I tried the suggestion of using a private NSManagedObjectContext in the block. That got me somewhere, but of course the data didn't populate my table. I tried the NSManagedObjectContextDidSaveNotification trick, but I couldn't get that to work. Reading the Concurrency with Core Data page online says the information is outdated. Where do I find current documentation? Or better yet, an actual example that actually works? My brain is about to explode, and nobody wants to clean that up. -- Steve Mills Drummer, Mac geek ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/tgeernaert%40gmail.com This email sent to tgeerna...@gmail.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data concurrency during import of folder contents
On 31 Jan 2015, at 01:20, Steve Mills sjmi...@mac.com wrote: I'm trying to learn Core Data. I have a working document model hooked up to a table view (OS X). I have an import method that uses FSDirectoryEnumerator to add an object for each file in the folder. Oky doke! But that blocks for a few seconds while it loops. So I'm trying to make it threaded. One example I saw uses GCD. It kinda seemed to work when I had a bunch of printfs in there so I could watch it progress, but when I took them out it just crashed at some point, and it still blocked any sort of user events. Next I tried sticking the entire import operation into a block via NSOperationQueue's addOperationWithBlock:. That throws because some set was being changed by multiple threads. Then I tried the suggestion of using a private NSManagedObjectContext in the block. That got me somewhere, but of course the data didn't populate my table. I tried the NSManagedObjectContextDidSaveNotification trick, but I couldn't get that to work. Reading the Concurrency with Core Data page online says the information is outdated. Where do I find current documentation? Or better yet, an actual example that actually works? My brain is about to explode, and nobody wants to clean that up. Oh yes the documentation does say that doesn't it - that's a shame. My first recommendation right off the bat (and it's the same one I make often) is to go watch the core data videos from WWDC going back to about 2011 when I believe all the 'new' concurrency was introduced. It's a time-investment but there's loads of good stuff in there which I find helps immensely and you really can't find out any other way. (The 2014 video has a brief runthrough towards the start of the history of concurrency with Core Data, that's at least a start). At this point, NSThreadConfinementCurrencyType, the default since confinement types were introduced, is basically obsolete and there was a warning in the 2014 WWDC video that it's going to go away. The concept of worrying about threads has really gone away with it. So you don't need your own operations queues, you should use an MOC which is NSPrivateQueueConcurrencyType and .. this is important .. send all requests to it on with performBlock: or performBlockAndWait: method. This will happily use GCD under the hood and serialize on the queue. Your UI should use an NSMainQueueConcurrencyType usually, because then you're always on the right queue when updating your UI. Two ways to get the results back into the MOC which is backing your table, one which you probably currently created as a default MOC with NSConfinementCurrencyType (the default) but which you should possibly think about changing to the main queue type. Then you have a couple of options, you can have an entirely separate MOC in which you do your import, or you can make a child MOC of the main one, of type NSPrivateQueueConcurrencyType, and do the import then, then 'save' it which will push the changes into the parent. I've done both, I prefer the separate MOC approach for bulk data import and use the child context paradigm mostly for discardable edits, for which it's really well-suited. NSManagedObjectContextDidSaveNotification is regrettably not a trick, it's how different MOCs talk to each other. So you need to get that to work. I think when I started with Core Data I tried hard to avoid it because I don't 'do' notifications, and then I gave up trying to avoid it, figured it out once and used it. What about it couldn't you get to work? When a context saves it sends that notification (plus another one before and one after to tell you things have changed and that it was saved) to anyone who cares to listen, it's that simple (as long as you called save). Core Data itself is very good at updating your local MOC with the results of such a notification, you really just need to get the notification and hand it to your MOC to figure out. If you want to be clever about it and inspect the notification to figure out exactly what objects changed and how to update your UI minimally, you can do that, a first dumb approach is get notification, call core data method to update local MOC, call reloadData on your table. Not pretty but a place to start. So I'd say probably go back to the notification and figure out what it was you were having problems with there, if you want a background import, you're going to need to get to the bottom of that. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Modernising dragging problem
On Fri, Jan 30, 2015, at 05:15 PM, Graham Cox wrote: In order to use NSDraggingItem, I first need to make sure the stuff I'm dragging supports NSPasteboardWriting. I've done that, it seems straightforward enough. Then I build a NSDraggingItem and use the same image I previously used, so there's nothing new there. Finally I use [NSView beginDraggingSessionWithItems:event:source:]. Nothing shows up. No image, nothing drags. I can break on the NSPasteboardWriting methods and see that they are being called, so it seems to be trying to write the correct things to the pasteboard. Nothing is logged. After this, use of the legacy dragging methods elsewhere in the app also fail to work - it's like whatever I did in this drag session messes up the dragging system altogether. Obviously I'm doing something wrong, but I've been over the docs and am just not getting it. Does the source implement the required method -[NSDraggingSource draggingSession:sourceOperationMaskForDraggingContext:]? This is the new replacement for -draggingSourceOperationMaskForLocal:. --Kyle Sluder ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Modernising dragging problem
On 31 Jan 2015, at 10:25 am, Kyle Sluder k...@ksluder.com wrote: Does the source implement the required method -[NSDraggingSource draggingSession:sourceOperationMaskForDraggingContext:]? This is the new replacement for -draggingSourceOperationMaskForLocal:. Ah, thanks - It wasn't - but having corrected that, it hasn't fixed my issue. I've also checked whether the immediate return of the new method would cause a problem (e.g. if the caller were doing stuff after starting the drag that was assuming the drag had completed). It's not - in fact it's just being called from a simple -[NSView mouseDown:] event handler with no other code. --Graham ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: copyWithZone archive/unarchive
It’s best to use ARC uniformly in a project and not mix with non-ARC modules. Xcode has a tool to upgrade projects to ARC. I have used it a number of times, and it seems to do a very good job. David On Jan 30, 2015, at 8:15 PM, Jerry Krinock je...@ieee.org wrote: On 2015 Jan 30, at 10:08, Trygve Inda cocoa...@xericdesign.com wrote: Do you see non-ARC code becoming obsolete? Non-ARC code is already obsolete, but what I think you mean is will non-ARC code fail to compile or run in some future OS version. Never say “never” with Apple, but in this case, I don’t think so, because ARC is a layer on top of non-ARC. I could probably start moving it to ARC slowly but it is hard to justify time spent on something that is not really needed. I have not run into any serious bugs or unexplained crashes due to messed up retain/release. Then don’t touch it. Use ARC for new code. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/rowlandd%40sbcglobal.net This email sent to rowla...@sbcglobal.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: copyWithZone archive/unarchive
On Jan 30, 2015, at 8:43 PM, David Rowland rowla...@sbcglobal.net wrote: It’s best to use ARC uniformly in a project and not mix with non-ARC modules. Xcode has a tool to upgrade projects to ARC. I have used it a number of times, and it seems to do a very good job. I haven't had any problem mixing ARC with non-ARC. It's just a little annoying to have to edit the build flags of individual source files. The upgrade tool is nice, but in a big project it can take a fair amount of work to get all the code ready to convert (i.e. fix all the issues raised by the converter) and then track down residual memory issues afterwards. That said, I'd never go back to writing non-ARC code (unless forced to.) —Jens smime.p7s Description: S/MIME cryptographic signature ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: copyWithZone archive/unarchive
Depending on the complexity of the application and amount of core services utilized, converting an existing manual retain/release project to ARC can instigate a battle you may not want to fight. When I attempted that with my medium complexity application, I quickly realized it was a mistake, held up the white flag, and retreated. But understand, my application is mature so there was (and is) no pressing need to convert to ARC. In any case, I wouldn't recommend converting an existing application to ARC solely for the sake of doing so; there should be a compelling reason. That's one man's humble opinion. Paul On 1/30/2015 8:43 PM, David Rowland wrote: It’s best to use ARC uniformly in a project and not mix with non-ARC modules. Xcode has a tool to upgrade projects to ARC. I have used it a number of times, and it seems to do a very good job. David smime.p7s Description: S/MIME Cryptographic Signature ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data concurrency during import of folder contents
Isn't there just an example of a document-based app that implement concurrent Core Data importing and all that jazz? I see tons and tons of little scraps of info and examples (which end up not working with my app as it is because it was written based on Apple's outdated documentation), but not the whole picture. -- Steve Mills Drummer, Mac geek ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: copyWithZone archive/unarchive
On 2015 Jan 30, at 10:08, Trygve Inda cocoa...@xericdesign.com wrote: Do you see non-ARC code becoming obsolete? Non-ARC code is already obsolete, but what I think you mean is will non-ARC code fail to compile or run in some future OS version. Never say “never” with Apple, but in this case, I don’t think so, because ARC is a layer on top of non-ARC. I could probably start moving it to ARC slowly but it is hard to justify time spent on something that is not really needed. I have not run into any serious bugs or unexplained crashes due to messed up retain/release. Then don’t touch it. Use ARC for new code. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
