Re: how to clip inside a path

2012-10-30 Thread Vincent Habchi 
On 30 oct. 2012, at 07:25, Vincent Habchi  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**

2012-10-30 Thread Rick Mann 

On Oct 29, 2012, at 23:23 , Quincey Morris 
 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**

2012-10-30 Thread Roland King 

On 30 Oct, 2012, at 5:39 PM, 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.
> 
> -- 
> 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**

2012-10-30 Thread Ken Thomases 
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

2012-10-30 Thread Glen Low 
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  
> 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

2012-10-30 Thread Matt Neuburg 
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 
> 
> 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  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

2012-10-30 Thread Matt Neuburg 
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

2012-10-30 Thread Sean McBride 
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 #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  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

2012-10-30 Thread Quincey Morris 
On Oct 30, 2012, at 10:39 , Sean McBride  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.

2012-10-30 Thread Gavin Stokes 
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**)

2012-10-30 Thread Rick Mann 

On Oct 30, 2012, at 3:15 , Roland King  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**)

2012-10-30 Thread Greg Parker 
On Oct 30, 2012, at 4:59 PM, Rick Mann  wrote:
> On Oct 30, 2012, at 3:15 , Roland King  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**)

2012-10-30 Thread Rick Mann 

On Oct 30, 2012, at 17:10 , Greg Parker  wrote:

> On Oct 30, 2012, at 4:59 PM, Rick Mann  wrote:
>> On Oct 30, 2012, at 3:15 , Roland King  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**)

2012-10-30 Thread Roland King 

On 31 Oct, 2012, at 7:59 AM, Rick Mann  wrote:

> 
> On Oct 30, 2012, at 3:15 , Roland King  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**)

2012-10-30 Thread Rick Mann 

On Oct 30, 2012, at 17:27 , Roland King  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**)

2012-10-30 Thread Roland King 

On 31 Oct, 2012, at 8:30 AM, Rick Mann  wrote:

> 
> On Oct 30, 2012, at 17:27 , Roland King  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**)

2012-10-30 Thread Greg Parker 
On Oct 30, 2012, at 5:12 PM, Rick Mann  wrote:
> On Oct 30, 2012, at 17:10 , Greg Parker  wrote:
>> On Oct 30, 2012, at 4:59 PM, Rick Mann  wrote:
>>> On Oct 30, 2012, at 3:15 , Roland King  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**)

2012-10-30 Thread Rick Mann 

On Oct 30, 2012, at 17:35 , Greg Parker  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**)

2012-10-30 Thread Rick Mann 

On Oct 30, 2012, at 17:27 , Roland King  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**)

2012-10-30 Thread Roland King 
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  wrote:

> 
> On Oct 30, 2012, at 17:27 , Roland King  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**)

2012-10-30 Thread Ken Thomases 
On Oct 30, 2012, at 9:20 PM, Roland King wrote:

> On 31 Oct, 2012, at 10:16, Rick Mann  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

2012-10-30 Thread Graham Cox 
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

Re: Event loop expiration date insight

2012-10-30 Thread Vincent Habchi 
> 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 

I am running manually a runloop in a command line utility that loads XML data 
through an URL. I use the current date for the time parameter like this:

while (_WMSenCours) {

[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode
 beforeDate:[NSDate 
dateWithTimeIntervalSinceNow:0]];
}
 
where the flag _WMSenCours goes false when I received a message of data 
completion.

I suspect if you pass a date that is either in the past or present, the runloop 
is performed only once and exits whether it detects or no an incoming event. If 
you specify “distant future”, you will be stuck in the runloop until an event 
occurs. Which, in most cases, should not make any difference except for 
debugging purposes.

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: Event loop expiration date insight

2012-10-30 Thread Greg Parker 
On Oct 30, 2012, at 9:58 PM, Graham Cox  wrote:
> 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?

If the date is in the past then the method returns immediately. If there is a 
matching event in the queue then it will be returned.


> I've changed this to pass nil and my mouse dragging works as normal.

This is generally not recommended. Using nil instead of -distantFuture may use 
more CPU and power while the drag is in progress.


-- 
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