Re: ARC conversion help - CFErrorRef* and NSError**
On Oct 29, 2012, at 22:24 , Rick Mann rm...@latencyzero.com wrote: Any way to introduce (into clang) an __attribute__ or something similar on the declaration of NSError to say it's equivalent to CFErrorRef? Except that they're not equivalent, in memory management terms. CF and NS objects have different rules. IIRC, it's also not safe to assume that CF and NS (when toll-free bridged for a class) use the same underlying classes. In some cases they do (often these are NSCFxxx classes at run time), but in a few cases they don't. In yet other cases (collection classes, for example) it's possible to create CF objects of a nominally toll-free bridged class which don't work correctly as NS objects using NS method access (collections that contain non-object pointers or that use non-standard memory allocators, for example). ___ 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 clip inside a path
On 30 oct. 2012, at 01:24, Jens Alfke j...@mooseyard.com wrote: There was a pretty serious proposal floated on objc-language earlier this year (by a non-Apple person), but as far as I can tell it devolved into a bunch of arguing over details, and didn’t go anywhere. (And further discussion thereof should probably take place on that list, not here.) Try Eero. http://www.eerolanguage.org. I maintain the package on MacPorts, if you want to have a try. Vincent ___ 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 clip inside a path
On 30 oct. 2012, at 07:25, Vincent Habchi vi...@macports.org wrote: http://www.eerolanguage.org. I maintain the package on MacPorts, if you want to have a try. Should be http://eerolanguage.org. There is no leading www. V. ___ 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: ARC conversion help - CFErrorRef* and NSError**
On Oct 29, 2012, at 23:23 , Quincey Morris quinceymor...@rivergatesoftware.com wrote: Except that they're not equivalent, in memory management terms. CF and NS objects have different rules. IIRC, it's also not safe to assume that CF and NS (when toll-free bridged for a class) use the same underlying classes. In some cases they do (often these are NSCFxxx classes at run time), but in a few cases they don't. In yet other cases (collection classes, for example) it's possible to create CF objects of a nominally toll-free bridged class which don't work correctly as NS objects using NS method access (collections that contain non-object pointers or that use non-standard memory allocators, for example). Well, whatever the __attribute__ is, I'm sure it could specify all that. Then again, I ran into a problem that I don't know how to properly solve, using CFSockets. I need to retain an NSObject I pass into CFSocket, and have it released when the socket is released, not when a callback occurs, but there's no good way to do that. -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC conversion help - CFErrorRef* and NSError**
On 30 Oct, 2012, at 5:39 PM, Rick Mann rm...@latencyzero.com wrote: Then again, I ran into a problem that I don't know how to properly solve, using CFSockets. I need to retain an NSObject I pass into CFSocket, and have it released when the socket is released, not when a callback occurs, but there's no good way to do that. -- Rick how did you do it before, in non-ARC, what's the code look like? There must be a combination of CFBridgingRetain(), CFBridgingRelease() and (__bridge .. ) you can use to do what you're doing. If this is for the void* info pointer in a CFSocketContext then I'd make the retain callback CFRetain(), the release callback CFRelease and send the NSObject in with (__bridge void*)object. If it's not that, what call are you trying to ARC-ize? ___ 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: ARC conversion help - CFErrorRef* and NSError**
On Oct 30, 2012, at 4:39 AM, Rick Mann wrote: Then again, I ran into a problem that I don't know how to properly solve, using CFSockets. I need to retain an NSObject I pass into CFSocket, and have it released when the socket is released, not when a callback occurs, but there's no good way to do that. That's what the CFSocketContext structure is for. Yes, it uses callbacks, but I think these are different from what you're referring to, which I assume is the CFSocketCallBack. Regards, Ken ___ 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: Cocoa-dev Digest, Vol 9, Issue 751
All On 30/10/2012, at 12:44 AM, cocoa-dev-requ...@lists.apple.com wrote: From: Jens Alfke Subject: Re: zlib, objective-zip, NSDataCategory Date: 30 October 2012 12:44:37 AM AWST To: Michael Brian Bentley Cc: cocoa-dev@lists.apple.com On Oct 25, 2012, at 3:01 PM, Michael Brian Bentley bent...@crenelle.com wrote: I would like to work with zlib using preset dictionaries, and was searching around for a good place to start working with the library in objective c. I've been looking at Objective-Zip, and at cocoadev.com's NSDataCategory at http://cocoadev.com/wiki/NSDataCategory. I tend to use the GTM (Google Toolkit for Mac) wrapper. Another library was just announced here two days ago: That would be my library. I have some private classes there that might be of help: ZZDeflateOutputStream -- a NSOutputStream that deflates bytes from a NSFileHandle. ZZInflateInputStream -- a NSInputStream that inflates bytes from a NSData (typically this would be memory-mapped from your file). Quite a few Cocoa API's use NSStream's e.g. XML parsing, plist loading. They are wrappers around the zlib calls. There's currently no option for presetting dictionaries but you could probably hack it in. https://github.com/pixelglow/zipzap Cheers G. ___ 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: iOS 6 changes in CATextLayer text drawing
And as expected this has been pushed back at me: Works as expected. Apple doesn't mind at all if the very same app with the very same code compiled against the very same SDK draws its text in completely different places under different systems. m. Date: Mon, 29 Oct 2012 08:43:14 -0700 From: Matt Neuburg m...@tidbits.com I've filed a bug on this, clearly demonstrating the problem (the very same code compiled against the very same SDK draws the text in a very different location); but it is obvious that nothing will be done about it. There are pervasive changes in text drawing throughout iOS 6, and backward compatibility has never been a priority. m. On Fri, 12 Oct 2012 09:46:21 -0700, Matt Neuburg m...@tidbits.com said: What about the above part of my original question? This is a serious issue, because it basically means that the text appears in a different place under iOS 5 vs. iOS 6. You can easily see this by making a simple CATextLayer in a project whose base SDK is iOS 6 but whose deployment target is iOS 5. Run in the Simulator using an iOS 6 destination and then using an iOS 5 destination and you will see that the text has moved significantly. So using CATextLayer in a backward-compatible project is going to be a massive headache. m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.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
CALayer still has no constraints on iOS
I find it odd that UIView on iOS now has the wonderful CALayoutConstraint system, but CALayer doesn't have anything analogous. This means that a sublayer - that is, a sublayer of a view's layer - just sits there like a bump on a log when the view is resized. To give an example, Apple has made it clear in the WWDC videos that they would like me to support rotation in table views. But let's say that part of how I was drawing my UITableViewCell was with sublayers. When we rotate and the cell gets wider, the sublayer doesn't get wider. Now, it's not as if I don't see any way out of this. I can probably pretty much do with subviews what I was doing with sublayers, and thus get all the layout constraint's yummy goodness. I'm just surprised that we still have no form of auto-resizing for sublayers, and I'm wondering if I'm missing something. m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.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: createDirectoryAtPath:withIntermediateDirectories:attributes:error: Returns NO when it exists
On Mon, 29 Oct 2012 10:22:57 +0100, Andreas Grosam said: I'm attempting to create a directory with NSFileManager's method. The directory may already exist. According the documentation https://developer.apple.com/library/mac/ #documentation/Cocoa/Reference/Foundation/Classes/NSFileManager_Class/ Reference/Reference.html the method shall return YES if the directory already exists: Return Value YES if the directory was created or already exists or NO if an error occurred. However, when the directory already exists it returns NO with error parameter set: Strange. I filed rdar://9453805 last year about the docs for that method: - 17-May-2011 02:25 PM Sean McBride: The developer documentation for NSFileManager's createDirectoryAtPath:withIntermediateDirectories:attributes:error: says: Parameters path The path at which to create the new directory. The directory to be created must not yet exist. ... Return Value YES if the operation was successful or already exists, otherwise NO. I believe the sentence The directory to be created must not yet exist. should be stricken. It conflicts with what's implied by the return value. Also, in practice, passing an existent path works as expected (YES is returned). 09-Mar-2012 02:31 PM Sean McBride: This is fixed in Xcode 4F90's built-in docs. This issue has been verified as resolved and can be closed. - Note that in my experience YES is returned if the directory exists. Do you require 10.7? If so, try the URL version: createDirectoryAtURL:withIntermediateDirectories:attributes:error:. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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: createDirectoryAtPath:withIntermediateDirectories:attributes:error: Returns NO when it exists
On Oct 30, 2012, at 10:39 , Sean McBride s...@rogue-research.com wrote: Note that in my experience YES is returned if the directory exists. It's also worth consulting the header file comments: createDirectoryAtPath:withIntermediateDirectories:attributes:error: creates a directory at the specified path. If you pass 'NO' for createIntermediates, the directory must not exist at the time this call is made. Passing 'YES' for 'createIntermediates' will create any necessary intermediate directories. This method returns YES if all directories specified in 'path' were created and attributes were set. […] This method returns NO if a failure occurs at any stage of the operation. There's a certain inscrutability to this, but it seems to suggest that passing 'YES' for createIntermediates will allow the directory to already exist (in effect, the directory is created as one of the intermediates), while passing 'NO' requires the directory not to exist. ___ 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
iOS always tells us that the user declined push notifications, even when that's BS.
I noticed that every device registered in our database for our
just-approved app is showing up as having declined all push
notifications. None of our testers' devices had this problem, and I
couldn't repro it on mine. Of course, testing this is nearly
impossible, because Apple gives developers no way to reset
push-notification settings except wiping the entire device.
We discovered that, on the first launch of the released version of the
app, iOS tells us that all notifications for the application are
turned off. The second time it's run, they're reported correctly.
The problem is that our app can run in the background, so we never
know when or if the second launch will occur.
Has anyone else noticed this? Here's the code where we check the
notification elections:
- (void)application:(UIApplication*)application
didRegisterForRemoteNotificationsWithDeviceToken:(NSData*)pushToken
{
// Check what notifications the user has turned on. We registered
for all three, but they may have manually disabled some or all of
them.
NSUInteger RNTypes = [[UIApplication sharedApplication]
enabledRemoteNotificationTypes];
// Set the defaults to disabled unless we find otherwise...
NSString* pushBadge = (RNTypes UIRemoteNotificationTypeBadge) ?
@enabled : @disabled;
NSString* pushAlert = (RNTypes UIRemoteNotificationTypeAlert) ?
@enabled : @disabled;
NSString* pushSound = (RNTypes UIRemoteNotificationTypeSound) ?
@enabled : @disabled;
Thanks for any insight!
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
CFNetworking and ARC (was: ARC conversion help - CFErrorRef* and NSError**)
On Oct 30, 2012, at 3:15 , Roland King r...@rols.org wrote: how did you do it before, in non-ARC, what's the code look like? There must be a combination of CFBridgingRetain(), CFBridgingRelease() and (__bridge .. ) you can use to do what you're doing. Before, I used explicit retain and release. But now, if I CFBridgingRetain() my NSObject as I pass it into CFSocketCreateConnectedToSocketSignature() (via CFSocketContext), then I can't CFBridgingRelease() it in my CFSocketCallBack, it can (will) get over-released, because that's called multiple times. So, obviously I can't do that. The only place I can release it is when I CFRelease() the socket. But there's no way to release my object without compiler sleight-of-hand. -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CFNetworking and ARC (was: ARC conversion help - CFErrorRef* and NSError**)
On Oct 30, 2012, at 4:59 PM, Rick Mann rm...@latencyzero.com wrote: On Oct 30, 2012, at 3:15 , Roland King r...@rols.org wrote: how did you do it before, in non-ARC, what's the code look like? There must be a combination of CFBridgingRetain(), CFBridgingRelease() and (__bridge .. ) you can use to do what you're doing. Before, I used explicit retain and release. But now, if I CFBridgingRetain() my NSObject as I pass it into CFSocketCreateConnectedToSocketSignature() (via CFSocketContext), then I can't CFBridgingRelease() it in my CFSocketCallBack, it can (will) get over-released, because that's called multiple times. So, obviously I can't do that. Where did you use explicit retain and release? Why can you not use the CF forms in the same places? -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: CFNetworking and ARC (was: ARC conversion help - CFErrorRef* and NSError**)
On Oct 30, 2012, at 17:10 , Greg Parker gpar...@apple.com wrote: On Oct 30, 2012, at 4:59 PM, Rick Mann rm...@latencyzero.com wrote: On Oct 30, 2012, at 3:15 , Roland King r...@rols.org wrote: how did you do it before, in non-ARC, what's the code look like? There must be a combination of CFBridgingRetain(), CFBridgingRelease() and (__bridge .. ) you can use to do what you're doing. Before, I used explicit retain and release. But now, if I CFBridgingRetain() my NSObject as I pass it into CFSocketCreateConnectedToSocketSignature() (via CFSocketContext), then I can't CFBridgingRelease() it in my CFSocketCallBack, it can (will) get over-released, because that's called multiple times. So, obviously I can't do that. Where did you use explicit retain and release? Why can you not use the CF forms in the same places? I'm retaining and releasing my own NSObject subclass. Doing so seems to go against the spirit of it all. -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CFNetworking and ARC (was: ARC conversion help - CFErrorRef* and NSError**)
On 31 Oct, 2012, at 7:59 AM, Rick Mann rm...@latencyzero.com wrote: On Oct 30, 2012, at 3:15 , Roland King r...@rols.org wrote: how did you do it before, in non-ARC, what's the code look like? There must be a combination of CFBridgingRetain(), CFBridgingRelease() and (__bridge .. ) you can use to do what you're doing. Before, I used explicit retain and release. But now, if I CFBridgingRetain() my NSObject as I pass it into CFSocketCreateConnectedToSocketSignature() (via CFSocketContext), then I can't CFBridgingRelease() it in my CFSocketCallBack, it can (will) get over-released, because that's called multiple times. So, obviously I can't do that. The only place I can release it is when I CFRelease() the socket. But there's no way to release my object without compiler sleight-of-hand. -- Rick I must be missing something here. Why can't you just set up your CFSocketContext with CFRetain for the CFAllocatorRetainCallback, CFRelease for the CFAllocatorReleaseCallback and cast the object to the (void*)info paramter with (__bridge void*)yourObject when you put that into the CFSocketContext. Job done, the CFSocket code will call CFRetain() for you during CFSocketCreateConnectedToSocketSignature(), which will retain it before ARC releases the original, and will call CFRelease() when the socket deallocs. You don't want CFBridgingRetain() here because you aren't passing ownership to Core Foundation, you're just giving it the object and it's taking ownership and releasing it again via the retain and release methods you've told it to use in CFSocketContext. ___ 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: CFNetworking and ARC (was: ARC conversion help - CFErrorRef* and NSError**)
On Oct 30, 2012, at 17:27 , Roland King r...@rols.org wrote: I must be missing something here. Why can't you just set up your CFSocketContext with CFRetain for the CFAllocatorRetainCallback, CFRelease for the CFAllocatorReleaseCallback and cast the object to the (void*)info paramter with (__bridge void*)yourObject when you put that into the CFSocketContext. Job done, the CFSocket code will call CFRetain() for you during CFSocketCreateConnectedToSocketSignature(), which will retain it before ARC releases the original, and will call CFRelease() when the socket deallocs. You don't want CFBridgingRetain() here because you aren't passing ownership to Core Foundation, you're just giving it the object and it's taking ownership and releasing it again via the retain and release methods you've told it to use in CFSocketContext. I wrote this based on some Apple sample code, never bothered to learn how to properly use CFSocketContext. Nevertheless, is it okay to CF-manage an NSObject subclass that's not one of Apple's toll-free bridged classes? -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CFNetworking and ARC (was: ARC conversion help - CFErrorRef* and NSError**)
On 31 Oct, 2012, at 8:30 AM, Rick Mann rm...@latencyzero.com wrote: On Oct 30, 2012, at 17:27 , Roland King r...@rols.org wrote: I must be missing something here. Why can't you just set up your CFSocketContext with CFRetain for the CFAllocatorRetainCallback, CFRelease for the CFAllocatorReleaseCallback and cast the object to the (void*)info paramter with (__bridge void*)yourObject when you put that into the CFSocketContext. Job done, the CFSocket code will call CFRetain() for you during CFSocketCreateConnectedToSocketSignature(), which will retain it before ARC releases the original, and will call CFRelease() when the socket deallocs. You don't want CFBridgingRetain() here because you aren't passing ownership to Core Foundation, you're just giving it the object and it's taking ownership and releasing it again via the retain and release methods you've told it to use in CFSocketContext. I wrote this based on some Apple sample code, never bothered to learn how to properly use CFSocketContext. Nevertheless, is it okay to CF-manage an NSObject subclass that's not one of Apple's toll-free bridged classes? CFRetain() and CFRelease() on a cast-to-void*-or-CFTypeRef NSObject subclass are fine. You can treat an NSObject as a CFTypeRef for those memory management calls, yes. ___ 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: CFNetworking and ARC (was: ARC conversion help - CFErrorRef* and NSError**)
On Oct 30, 2012, at 5:12 PM, Rick Mann rm...@latencyzero.com wrote: On Oct 30, 2012, at 17:10 , Greg Parker gpar...@apple.com wrote: On Oct 30, 2012, at 4:59 PM, Rick Mann rm...@latencyzero.com wrote: On Oct 30, 2012, at 3:15 , Roland King r...@rols.org wrote: how did you do it before, in non-ARC, what's the code look like? There must be a combination of CFBridgingRetain(), CFBridgingRelease() and (__bridge .. ) you can use to do what you're doing. Before, I used explicit retain and release. But now, if I CFBridgingRetain() my NSObject as I pass it into CFSocketCreateConnectedToSocketSignature() (via CFSocketContext), then I can't CFBridgingRelease() it in my CFSocketCallBack, it can (will) get over-released, because that's called multiple times. So, obviously I can't do that. Where did you use explicit retain and release? Why can you not use the CF forms in the same places? I'm retaining and releasing my own NSObject subclass. Doing so seems to go against the spirit of it all. Is it okay to CF-manage an NSObject subclass that's not one of Apple's toll-free bridged classes? It is. All NS object types are bridged to a generic NSCFType if they aren't bridged to something more specific. CFRetain() et al work on all objects. The CF functions are the recommended and expected solution for explicit memory management in ARC code. The correct way to write your code is probably CFSocketContext ctx; ctx.retain = CFRetain; ctx.release = CFRelease; ctx.info = (__bridge void *)yourObject; -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: CFNetworking and ARC (was: ARC conversion help - CFErrorRef* and NSError**)
On Oct 30, 2012, at 17:35 , Greg Parker gpar...@apple.com wrote: It is. All NS object types are bridged to a generic NSCFType if they aren't bridged to something more specific. CFRetain() et al work on all objects. The CF functions are the recommended and expected solution for explicit memory management in ARC code. The correct way to write your code is probably CFSocketContext ctx; ctx.retain = CFRetain; ctx.release = CFRelease; ctx.info = (__bridge void *)yourObject; Awesome. That's how I would've wanted it to work. Thanks to all for spelling it out for me. -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CFNetworking and ARC (was: ARC conversion help - CFErrorRef* and NSError**)
On Oct 30, 2012, at 17:27 , Roland King r...@rols.org wrote: I must be missing something here. Why can't you just set up your CFSocketContext with CFRetain for the CFAllocatorRetainCallback, CFRelease for the CFAllocatorReleaseCallback and cast the object to the (void*)info paramter with (__bridge void*)yourObject when you put that into the CFSocketContext. Job done, the CFSocket code will call CFRetain() for you during CFSocketCreateConnectedToSocketSignature(), which will retain it before ARC releases the original, and will call CFRelease() when the socket deallocs. You don't want CFBridgingRetain() here because you aren't passing ownership to Core Foundation, you're just giving it the object and it's taking ownership and releasing it again via the retain and release methods you've told it to use in CFSocketContext. One thing that's not clear in the docs for CFSocketCreateConnectedToSocketSignature() is what happens to the CFSocketSignature parameter. Is that information copied immediately, or should it persist? is the supplied CFDataRef retained? The docs are clear about the context parameter, but not this one. -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CFNetworking and ARC (was: ARC conversion help - CFErrorRef* and NSError**)
It's not needed after the call has finished, just used to create the socket, so no retain or copy needed. On 31 Oct, 2012, at 10:16, Rick Mann rm...@latencyzero.com wrote: On Oct 30, 2012, at 17:27 , Roland King r...@rols.org wrote: I must be missing something here. Why can't you just set up your CFSocketContext with CFRetain for the CFAllocatorRetainCallback, CFRelease for the CFAllocatorReleaseCallback and cast the object to the (void*)info paramter with (__bridge void*)yourObject when you put that into the CFSocketContext. Job done, the CFSocket code will call CFRetain() for you during CFSocketCreateConnectedToSocketSignature(), which will retain it before ARC releases the original, and will call CFRelease() when the socket deallocs. You don't want CFBridgingRetain() here because you aren't passing ownership to Core Foundation, you're just giving it the object and it's taking ownership and releasing it again via the retain and release methods you've told it to use in CFSocketContext. One thing that's not clear in the docs for CFSocketCreateConnectedToSocketSignature() is what happens to the CFSocketSignature parameter. Is that information copied immediately, or should it persist? is the supplied CFDataRef retained? The docs are clear about the context parameter, but not this one. -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CFNetworking and ARC (was: ARC conversion help - CFErrorRef* and NSError**)
On Oct 30, 2012, at 9:20 PM, Roland King wrote: On 31 Oct, 2012, at 10:16, Rick Mann rm...@latencyzero.com wrote: One thing that's not clear in the docs for CFSocketCreateConnectedToSocketSignature() is what happens to the CFSocketSignature parameter. Is that information copied immediately, or should it persist? is the supplied CFDataRef retained? The docs are clear about the context parameter, but not this one. It's not needed after the call has finished, just used to create the socket, so no retain or copy needed. And, generally, if there's no documentation to the contrary, you should assume that all other code does the appropriate thing to satisfy its needs, leaving you to only have to worry about your code. That is, if it needs to retain something, it will and it takes the responsibility to balance that retain with a release. If it needs to copy something, ditto. Neither is your concern. Regards, Ken ___ 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
Event loop expiration date insight
I'm handling some mouse dragging tasks modally by implementing my own modal event loop using [NSApp nextEventMatchingMask:untilDate:inMode:dequeue:]. I'm wondering what is the usual correct thing to pass for the 'untilDate' parameter. For a long time I've been using [NSDate distantFuture], but the documentation of this method says that by passing nil it uses [NSDate distantPast], which implies perhaps that this is a more usual default. In thinking about this I realise I don't really understand what this parameter is doing, especially when 'distantPast' is specified - does that mean do not wait at all for any events and only return one if it's already queued? I've changed this to pass nil and my mouse dragging works as normal. What set me looking at this is a strange report of this loop going screwy for one user, which I can't reproduce. According to the logs from that user, suddenly several 'mouseUp' events are delivered one after the other which seems impossible, and that confuses my code. Can anyone think of any reason why multiple mouseUps could be delivered (i'm passing YES for the dequeue parameter)? I'm wondering if a third-party extension could be interfering with events somehow - anyone heard of anything like that? --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
