date:20120317

On Mar 16, 2012, at 9:16 PM, G S wrote:

> Thanks for asking this, Brian.  I've wondered the same thing, and in fact I
> went through my code and removed almost all property declarations from my
> view controllers.  Since most properties are declared as "retain", you're
> just increasing your bookkeeping to avoid leaks.  Not to mention the sheer
> maintenance hassle of typing out or deleting the declarations as you add or
> remove members.
> 
> And as someone pointed out, properties are not at all necessary for making
> connections in IB.  So I don't see the point.  Now I'm referring to the
> members directly, with the added bonus of being able to use member notation
> to identify members for clarity.

This pattern is pretty questionable though in terms of OO — you have one class 
(NSNib, UINib, etc.) directly setting instance variables in another class (your 
view controller) and using runtime functions to hack around things like 
@private. That’s really icky — using properties seems like a much cleaner way 
to do it. The property can be declared in a class extension in the .m file, and 
it’s not like typing

@property IBOutlet NSButton *foo;

is that much harder than typing

{
@private
IBOutlet NSButton *_foo;
}

when it comes down to it.

Charles
___

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: The use of UIActionSheet mysteriously disables our app with a white screen after memory warning.

>
> just use isViewLoaded, it's a property of the UIViewController, don't need
> to track it yourself.


BAH!  I looked for this sort of thing under the properties of
UIViewController, not methods.  Thanks.
___

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: Why so many public properties all up in my grizzle?

>
> This pattern is pretty questionable though in terms of OO — you have one
> class (NSNib, UINib, etc.) directly setting instance variables in another
> class (your view controller) and using runtime functions to hack around
> things like @private.
>

How do you figure?  I'm not doing any manipulation of non-property members
between classes.  If you're saying that Cocoa does it when loading from a
nib, then it's doing that anyway; properties aren't required for that
action.  From the end-user (end-programmer) perspective, I don't see any
bad OO going on here.
___

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: Why so many public properties all up in my grizzle?

On Mar 17, 2012, at 3:45 AM, G S wrote:

> This pattern is pretty questionable though in terms of OO — you have one 
> class (NSNib, UINib, etc.) directly setting instance variables in another 
> class (your view controller) and using runtime functions to hack around 
> things like @private.
> 
> How do you figure?  I'm not doing any manipulation of non-property members 
> between classes.  If you're saying that Cocoa does it when loading from a 
> nib, then it's doing that anyway; properties aren't required for that action. 
>  From the end-user (end-programmer) perspective, I don't see any bad OO going 
> on here.

So you have an ivar marked @private. How do you think that (NS)|(UI)Nib — an 
unrelated class that shouldn’t have access to your private ivars — sets the 
outlet variables to your nib objects? It does it via runtime hackery. If you 
declare a property, on the other hand, it just calls the setter. Much cleaner 
and more OO, if you ask me.

Charles
___

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 185

2012-03-17 Thread Jon Ljunggren

G
On 16 mar ibi, at 14:57, cocoa-dev-requ...@lists.apple.com wrote:

> Send Cocoa-dev mailing list submissions to
>cocoa-dev@lists.apple.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>Speer
> ubInbhttpsuu://lists.al/viburnum-dev
> or, via email, send a message with subject or body 'help' to
>cocoa-dev-requ...@lists.apple.com
> 
> You can reach the person managing the list at
>cocoa-dev-ow...@lists.apple.com
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cocoa-dev digest..."
> Today's Topics:
> 
>   1. Re: Xcode 4.3.1 Universal Apps (Roland King)
>   2. iTunes like Fast Forward and Rewind Buttons (Peter Zegelin)
>   3. NSRuleEditor with variable-height rows? (Demitri Muna)
>   4. The use of UIActionSheet mysteriously disables our app with a
>  whitescreen after memory warning. (G S)
>   5. Re: Xcode 4.3.1 Universal Apps (Eric Dolecki)
>   6. Re: Xcode 4.3.1 Universal Apps (Roland King)
>   7. How to become root (Gerriet M. Denkmann)
>   8. Re: How to become root (Jean-Daniel Dupas)
>   9. Re: How to become root (Gerriet M. Denkmann)
>  10. Re: How to become root (Jean-Daniel Dupas)
>  11. Re: iTunes like Fast Forward and Rewind Buttons (Alex Zavatone)
> ___
> 
> Cocoa-dev mailing list  (Cocoa-dev@lists.apple.com)
> 
> Do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins (at) lists.apple.com
> 
> https://lists.apple.com/mailman/listinfo/cocoa-dev
___

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: Why so many public properties all up in my grizzle?

>
> How do you think that (NS)|(UI)Nib — an unrelated class that shouldn’t
> have access to your private ivars — sets the outlet variables to your nib
> objects? It does it via runtime hackery. If you declare a property, on the
> other hand, it just calls the setter. Much cleaner and more OO, if you ask
> me.
>

Interesting.  I went and read up on NSNib and learned some stuff, so thanks
for the reference.

That kind of behind-the-scenes stuff really doesn't worry me too much,
since there are all kinds of hacky, non-OO things taking place in this
language.  I'm not denigrating you for trying to avoid as much of it as
possible, but it seems like there's more of it going on than one can
practically prevent.
___

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 get Mac codesign certificate?

2012-03-17 Thread Gerriet M. Denkmann

I am a registered developer. And I paid 80€ to get the permission to mess 
around with my iPhone for one year.

I am NOT interested in the Mac app Store, and I do NOT want to pay another 80€.

But I want to codesign my OS X apps.
So how do I get the necessary certificate?


Kind regards,

Gerriet.


___

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 get Mac codesign certificate?

2012-03-17 Thread Marco Tabini

On 2012-03-17, at 9:18 AM, Gerriet M. Denkmann wrote:

> But I want to codesign my OS X apps.
> So how do I get the necessary certificate?

You need to buy it from a certificate authority, like Thawte or Verisign (or
one of the myriad resellers) and they will all be happy to sell you one at
prices that range from around $80 to around $500/yr. Alternatively, you can get
a certificate from Apple as part of the OS X Developer Program, which will cost
you the extra $100/yr but also includes beta access to OS X system software.

If you have control over the environment on which you deploy your software, you
can also create a self-signed certificate and, essentially, be your own
authority by adding yourself as a valid root CA on all the machines on which
you software will run. If you don't, you can use a self-signed certificate to
ensure the integrity of your code, but not your identity.

Apple has a bunch of good resources on this topic[1], which are worth a read if
you want more info.

HTH,

—Mt.

[1]:
https://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40005929-CH1-SW1
___

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 get Mac codesign certificate?

2012-03-17 Thread Wade Tregaskis

>> But I want to codesign my OS X apps.
>> So how do I get the necessary certificate?
> 
> You need to buy it from a certificate authority, like Thawte or Verisign (or 
> one of the myriad resellers) and they will all be happy to sell you one at 
> prices that range from around $80 to around $500/yr.

Can you not just use a free provider, like http://www.startssl.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: How to get Mac codesign certificate?

2012-03-17 Thread Marco Tabini

> Can you not just use a free provider, like http://www.startssl.com/?

I'm not an expert, but I think the free cert they provide cannot be used for 
code signing.

One other alternative may be the Developer ID initiative that Apple has 
announced as part of OS X 10.8 Mountain Lion, but I can't figure out if that's 
still under NDA and don't want to incur the wrath of the mods :-)


—Mt.


___

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 get Mac codesign certificate?

2012-03-17 Thread Wade Tregaskis

On 17/03/2012, at 7:54 AM, Marco Tabini wrote:
>> Can you not just use a free provider, like http://www.startssl.com/?
> 
> I'm not an expert, but I think the free cert they provide cannot be used for 
> code signing.

FWIW they can; they'd be pretty useless otherwise.  Many of them are marked, 
however, for use specifically with S/MIME or similar things.  So it really 
boils down to whether there's a special usage that must be marked (nothing in 
the docs about it, if there is), or whether the presence of an extended usage 
field with irrelevant usages defeats it.

It'd be trivial to try it, but it's early in the morning and I'm lazy. :P
___

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 get Mac codesign certificate?


> One other alternative may be the Developer ID initiative that Apple has 
> announced as part of OS X 10.8 Mountain Lion, but I can't figure out if 
> that's still under NDA and don't want to incur the wrath of the mods :-)
> 
> 

I assumed thats what the original poster was referring to. I'm also lacking 
details but got the impression that program is or will be free. 
___

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 get Mac codesign certificate?

2012-03-17 Thread Gerriet M. Denkmann


On 17 Mar 2012, at 22:41, Roland King wrote:

> 
>> One other alternative may be the Developer ID initiative that Apple has 
>> announced as part of OS X 10.8 Mountain Lion, but I can't figure out if 
>> that's still under NDA and don't want to incur the wrath of the mods :-)

> I assumed thats what the original poster was referring to.
You are absolutely right.

> I'm also lacking details but got the impression that program is or will be 
> free.
I got the same impression. But I did not find anything on Apple's sites about 
this.

The problem:  The documentation about SMJobBless says: "The calling application 
and target executable tool must both be signed."

So it seems that new technologies require code signing. Makes sense. But: where 
and how do I get a free certificate?


Kind regards,

Gerriet.





___

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 get Mac codesign certificate?





> 
> So it seems that new technologies require code signing. Makes sense. But: 
> where and how do I get a free certificate?
> 

Not sure you can yet. 
___

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 get Mac codesign certificate?

2012-03-17 Thread Jeff Johnson

On Mar 17, 2012, at 11:14 AM, Gerriet M. Denkmann wrote:

> The problem:  The documentation about SMJobBless says: "The calling 
> application and target executable tool must both be signed."
> 
> So it seems that new technologies require code signing. Makes sense. But: 
> where and how do I get a free certificate?

You can use a self-signed certificate, created in Keychain Access, for code 
signing.

Prior to Mountain Lion, the only advantage of buying a cert from a known 
authority is for the firewall system preference "Automatically allow signed 
software to receive incoming connections" (which by the way is a really stupid 
preference, IMO). The disadvantage of such certs is that they usually expire 
relatively quickly, in one or two years.

Mountain Lion changes the game a bit. It eliminates a lot of the advantage of 
3rd party cert authorities, because only Apple's cert will allow your app to 
run, so if you're not going to get a cert from Apple (I don't think I can 
discuss the terms here), you might as well self-sign.

-Jeff

___

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: Why so many public properties all up in my grizzle?

On Mar 17, 2012, at 6:47 AM, G S wrote:

> That kind of behind-the-scenes stuff really doesn't worry me too much, since 
> there are all kinds of hacky, non-OO things taking place in this language.  
> I'm not denigrating you for trying to avoid as much of it as possible, but it 
> seems like there's more of it going on than one can practically prevent.

Other than the awful misfeature of KVO accessing ivars directly, which I also 
recommend against using, I can’t think of too many other examples of a class 
monkeying with another class’s private instance variables off the top of my 
head.

Charles
___

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 get Mac codesign certificate?

On Mar 17, 2012, at 9:54 AM, Marco Tabini wrote:

> 'm not an expert, but I think the free cert they provide cannot be used for 
> code signing.

It can’t. Only Apple’s certs will work with Gatekeeper.

> One other alternative may be the Developer ID initiative that Apple has 
> announced as part of OS X 10.8 Mountain Lion, but I can't figure out if 
> that's still under NDA and don't want to incur the wrath of the mods :-)

The good news is that Gatekeeper is actually already in Lion as a hidden 
feature, which you can enable via this command line:

sudo spctl --enable

and turn back off with:

sudo spctl --disable

By doing this, you can get a feel for what Gatekeeper will allow without having 
Mountain Lion or dealing with any NDAed stuff.

Charles
___

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

NSPopover subview positioning issue

2012-03-17 Thread Erik Stainsby

I've got a popover controller which loads one of several subviews ('panels' 
below) as it's content. I have properties on the controller which expose the 
current panel's height and width.  The popover resizes correctly but fails to 
place the panel correctly.  If the replaceSubview:with: is called before the 
resize (as illustrated) the panel appears shifted down by half it's height, 
leaving half of the panel content inaccessible. If the -replaceSubview:with: 
call is placed after the resize, the inserted panel is half invisible off the 
top edge of the popover.

Does anyone understand what on earth is happening? And what I can do about it?


@implementation RSPanelPopoverController

@synthesize popover = _popover;
@synthesize box = _box;
@synthesize activePanelWidth;
@synthesize activePanelHeight;

- (void) showPanelPopover:(NSView*)locator activePanel:(NSView*)panel {

[[self view] replaceSubview:[self box] with:panel];

[self setActivePanelWidth: panel.frame.size.width];
[self setActivePanelHeight: panel.frame.size.height];

[[self popover] showRelativeToRect:[locator bounds] ofView:locator 
preferredEdge:NSMinYEdge];
}


Erik Stainsby
erik.stain...@roaringsky.ca
-
Consistently place constants on the LHS of an expression: you cannot 
accidentally assign when you meant to compare.





___

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: NSPopover subview positioning issue

2012-03-17 Thread Fritz Anderson

On 17 Mar 2012, at 2:48 PM, Erik Stainsby wrote:

> I've got a popover controller which loads one of several subviews ('panels' 
> below) as it's content. I have properties on the controller which expose the 
> current panel's height and width.  The popover resizes correctly but fails to 
> place the panel correctly.  If the replaceSubview:with: is called before the 
> resize (as illustrated) the panel appears shifted down by half it's height, 
> leaving half of the panel content inaccessible. If the -replaceSubview:with: 
> call is placed after the resize, the inserted panel is half invisible off the 
> top edge of the popover.
> 
> Does anyone understand what on earth is happening? And what I can do about it?
> 
> 
> @implementation RSPanelPopoverController
> 
> @synthesize popover = _popover;
> @synthesize box = _box;
> @synthesize activePanelWidth;
> @synthesize activePanelHeight;
> 
> - (void) showPanelPopover:(NSView*)locator activePanel:(NSView*)panel {
>   
>   [[self view] replaceSubview:[self box] with:panel];
>   
>   [self setActivePanelWidth: panel.frame.size.width];
>   [self setActivePanelHeight: panel.frame.size.height];
>   
>   [[self popover] showRelativeToRect:[locator bounds] ofView:locator 
> preferredEdge:NSMinYEdge];
> }

I'm not clear on a few things. It appears that the "panel" frame is offset one 
way or the other, but I don't see the frame being set, nor the panel being 
translated. You say that the order of setActivePanel…: matters, but you don't 
show that the methods (odd, but not wrong, that you don't use dot notation) do 
anything but change the value of an instance variable. If they actually change 
view geometry, you'll have to show us.

What class does RSPanelPopoverController descend from?

What is .box? (It appears that it can be replaced only once.) Have you logged 
the frames of .box, .view, and panel, before and after the replacement? And 
.view.bounds?

— F

___

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: NSPopover subview positioning issue

2012-03-17 Thread Erik Stainsby

Hi Fritz,

The popover controller is a standard NSViewController which is also acting as 
the delegate for the popovers.
I guess I ought to have included the header as well before:

#import 

@interface RSPanelPopoverController : NSViewController < NSPopoverDelegate >

@property (weak) IBOutlet NSPopover * popover;
@property (weak) IBOutlet NSBox * box;
@property (assign) NSInteger activePanelWidth;
@property (assign) NSInteger activePanelHeight;

- (void) showPanelPopover:(NSView*)locator activePanel:(NSView*)panel;

@end


I have modified the showPanelPopover: method  thus:

- (void) showPanelPopover:(NSView*)locator activePanel:(NSView*)panel {

[self setActivePanelWidth: panel.frame.size.width];
[self setActivePanelHeight: panel.frame.size.height];
[panel setFrameOrigin: self.view.bounds.origin];// new 
line
[[self view] replaceSubview:[self box] with:panel];

[[self popover] showRelativeToRect:[locator bounds] ofView:locator 
preferredEdge:NSMinYEdge];
}

with the effect that the view is correctly placed within the popover ON SECOND 
VIEWING. The initial load is still rendered off-set by half the vertical 
dimension.




Erik Stainsby
erik.stain...@roaringsky.ca
-
Consistently place constants on the LHS of an expression: you cannot 
accidentally assign when you meant to compare.




On 2012-03-17, at 1:10 PM, Fritz Anderson wrote:

> On 17 Mar 2012, at 2:48 PM, Erik Stainsby wrote:
> 
>> I've got a popover controller which loads one of several subviews ('panels' 
>> below) as it's content. I have properties on the controller which expose the 
>> current panel's height and width.  The popover resizes correctly but fails 
>> to place the panel correctly.  If the replaceSubview:with: is called before 
>> the resize (as illustrated) the panel appears shifted down by half it's 
>> height, leaving half of the panel content inaccessible. If the 
>> -replaceSubview:with: call is placed after the resize, the inserted panel is 
>> half invisible off the top edge of the popover.
>> 
>> Does anyone understand what on earth is happening? And what I can do about 
>> it?
>> 
>> 
>> @implementation RSPanelPopoverController
>> 
>> @synthesize popover = _popover;
>> @synthesize box = _box;
>> @synthesize activePanelWidth;
>> @synthesize activePanelHeight;
>> 
>> - (void) showPanelPopover:(NSView*)locator activePanel:(NSView*)panel {
>>  
>>  [[self view] replaceSubview:[self box] with:panel];
>>  
>>  [self setActivePanelWidth: panel.frame.size.width];
>>  [self setActivePanelHeight: panel.frame.size.height];
>>  
>>  [[self popover] showRelativeToRect:[locator bounds] ofView:locator 
>> preferredEdge:NSMinYEdge];
>> }
> 
> I'm not clear on a few things. It appears that the "panel" frame is offset 
> one way or the other, but I don't see the frame being set, nor the panel 
> being translated. You say that the order of setActivePanel…: matters, but you 
> don't show that the methods (odd, but not wrong, that you don't use dot 
> notation) do anything but change the value of an instance variable. If they 
> actually change view geometry, you'll have to show us.
> 
> What class does RSPanelPopoverController descend from?
> 
> What is .box? (It appears that it can be replaced only once.) Have you logged 
> the frames of .box, .view, and panel, before and after the replacement? And 
> .view.bounds?
> 
>   — F
> 


___

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

There's obviously something I don't understand about NSDate.

I have a member variable to hold an NSDate:

NSDate* _firstBadAccuracyTime;

At some point, something happens and I set this value to "now":

_firstBadAccuracyTime = [NSDate date];

On my next trip through this function, I calculate how long it has been
since I set this date:

NSDate* now = [NSDate date];
if([now timeIntervalSinceDate:_firstBadAccuracyTime] >
BAD_ACCURACY_TIME)

then CRASH: BAD ACCESS

_firstBadAccuracyTime still contains a valid address, but the object
must've been released.  Why?  If I add a retain where I assign it, the
crash doesn't happen.  I added autorelease, but then got a crash on
releasing an object I hadn't allocated (which makes me think it's already
autoreleased).

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

Re: There's obviously something I don't understand about NSDate.

2012-03-17 Thread Dave Fernandes

Yes, [NSDate date] returns an autoreleased object. So you need to retain it if 
you want to use it later. Once you are done with it, you should release it. See:
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html#//apple_ref/doc/uid/2994-SW6

If a Cocoa method name doesn't begin with “alloc”, “new”, “copy”, or 
“mutableCopy”, then the returned object is autoreleased.

Dave

On 2012-03-17, at 6:38 PM, G S wrote:

> I have a member variable to hold an NSDate:
> 
>NSDate* _firstBadAccuracyTime;
> 
> At some point, something happens and I set this value to "now":
> 
>_firstBadAccuracyTime = [NSDate date];
> 
> On my next trip through this function, I calculate how long it has been
> since I set this date:
> 
>NSDate* now = [NSDate date];
>if([now timeIntervalSinceDate:_firstBadAccuracyTime] >
> BAD_ACCURACY_TIME)
> 
> then CRASH: BAD ACCESS
> 
> _firstBadAccuracyTime still contains a valid address, but the object
> must've been released.  Why?  If I add a retain where I assign it, the
> crash doesn't happen.  I added autorelease, but then got a crash on
> releasing an object I hadn't allocated (which makes me think it's already
> autoreleased).
> 
> 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/dave.fernandes%40utoronto.ca
> 
> This email sent to dave.fernan...@utoronto.ca

___

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: There's obviously something I don't understand about NSDate.

2012-03-17 Thread Dave Fernandes


On 2012-03-17, at 6:57 PM, Dave Fernandes wrote:

> Yes, [NSDate date] returns an autoreleased object. So you need to retain it 
> if you want to use it later. Once you are done with it, you should release 
> it. See:
> https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html#//apple_ref/doc/uid/2994-SW6
> 
> If a Cocoa method name doesn't begin with “alloc”, “new”, “copy”, or 
> “mutableCopy”, then the returned object is autoreleased.

Oops - "init" should be included in this list, of course.

> 
> Dave
> 
> On 2012-03-17, at 6:38 PM, G S wrote:
> 
>> I have a member variable to hold an NSDate:
>> 
>>  NSDate* _firstBadAccuracyTime;
>> 
>> At some point, something happens and I set this value to "now":
>> 
>>  _firstBadAccuracyTime = [NSDate date];
>> 
>> On my next trip through this function, I calculate how long it has been
>> since I set this date:
>> 
>>  NSDate* now = [NSDate date];
>>  if([now timeIntervalSinceDate:_firstBadAccuracyTime] >
>> BAD_ACCURACY_TIME)
>> 
>> then CRASH: BAD ACCESS
>> 
>> _firstBadAccuracyTime still contains a valid address, but the object
>> must've been released.  Why?  If I add a retain where I assign it, the
>> crash doesn't happen.  I added autorelease, but then got a crash on
>> releasing an object I hadn't allocated (which makes me think it's already
>> autoreleased).
>> 
>> 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/dave.fernandes%40utoronto.ca
>> 
>> This email sent to dave.fernan...@utoronto.ca
> 


___

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: There's obviously something I don't understand about NSDate.

>
> If a Cocoa method name doesn't begin with “alloc”, “new”, “copy”, or
> “mutableCopy”, then the returned object is autoreleased.
>
>
Thanks, Dave.  That's what I thought.  But I don't understand why I need to
retain it then; it's assigned to a member pointer.  Why does it get
released, and when?  If I call retain on it, do I have to call release on
it later?

I create another NSDate, on the stack, to hold "now" for use within that
function.  Do I need to retain that too?  If not, why not?
___

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: There's obviously something I don't understand about NSDate.

On Mar 17, 2012, at 6:10 PM, G S wrote:

> Thanks, Dave.  That's what I thought.  But I don't understand why I need to
> retain it then; it's assigned to a member pointer.  Why does it get
> released, and when?

Assigning something to an instance variable doesn’t cause it to get retained 
unless you’re building for ARC. For manual retain-release, you have to retain 
it yourself or it will get released at some indeterminate time in the future.

>  If I call retain on it, do I have to call release on
> it later?

Yes (again, unless you’re using ARC). Do it in your -dealloc method.

> I create another NSDate, on the stack, to hold "now" for use within that
> function.  Do I need to retain that too?

Yes.

It would be a good idea to read Apple’s Memory Management documentation before 
going any further, really.

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html

Charles

___

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: There's obviously something I don't understand about NSDate.

On Mar 17, 2012, at 6:10 PM, G S wrote:

> I create another NSDate, on the stack, to hold "now" for use within that
> function.  Do I need to retain that too?

Er, sorry, I didn’t read this thoroughly last time. No, if you’re just using it 
inside a method, and not storing it to an instance variable, you don’t have to 
retain it. The object is autoreleased, which means it won’t get released until 
the next iteration of the run loop.

Charles
___

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: There's obviously something I don't understand about NSDate.

2012-03-17 Thread Dave Fernandes

On 2012-03-17, at 7:10 PM, G S wrote:

> If a Cocoa method name doesn't begin with “alloc”, “new”, “copy”, or 
> “mutableCopy”, then the returned object is autoreleased.
> 
> 
> Thanks, Dave.  That's what I thought.  But I don't understand why I need to 
> retain it then; it's assigned to a member pointer.  Why does it get released, 
> and when?  If I call retain on it, do I have to call release on it later?

If you are using manual retain-release semantics (not ARC or GC), then instance 
(member) variables are not retained. This means the object will be released 
whenever the autorelease pool is drained - probably at the end of the event 
cycle. So you should retain it (increasing its retain count), and then release 
it when you no longer need it (decreasing its release count and causing it to 
be deallocated).

> 
> I create another NSDate, on the stack, to hold "now" for use within that 
> function.  Do I need to retain that too?  If not, why not?

As long as it is used only within the function, it is safe to use the 
autoreleased object. You only need to retain it if you want to keep it around 
after the method returns.
___

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: There's obviously something I don't understand about NSDate.

2012-03-17 Thread James Bucanek


First, read the memory management link posted by Dave.

G S  wrote (Saturday, March 17, 
2012 4:10 PM -0700):

Thanks, Dave.  That's what I thought.  But I don't understand why I need to
retain it then;


In general, you have to retain an object whenever you plan to 
keep a reference beyond the scope of the current autorelease 
pool. Any any object you retain, you're responsible for 
releasing when you're done with it.



it's assigned to a member pointer.  Why does it get
released, and when?


Because you kept the reference to it beyond the scope of the 
current autorelease pool.



If I call retain on it, do I have to call release on
it later?


Yes.


I create another NSDate, on the stack, to hold "now" for use within that
function.  Do I need to retain that too? If not, why not?


No, because the scope of automatic variables never extends 
beyond the scope of the autorelease pool. So you're more or less 
guaranteed of "forgetting" the reference before the current 
autorelease pool is drained.


An autorelease pool essentially "owns" (retains) all of the 
autoreleased objects you're using. If all of the references to 
that object are within the lifetime of the autorelease pool 
(typically one pass through the event loop for a Cocoa app), 
then you can piggyback on the autorelease pool's ownership of 
the object and generally ignore the whole retain/release thing, 
since you'll be done with the object before the autorelease pool 
releases it.


If, on the other hand, you want to keep a persistent reference 
to the object, you must retain it and release it when you're done.


--
James Bucanek


___

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: There's obviously something I don't understand about NSDate.


> 
>> I create another NSDate, on the stack, to hold "now" for use within that
>> function.  Do I need to retain that too?
> 
> Yes.

Not really, no. You could, it wouldn't be incorrect to retain it at the point 
of creation (or use alloc/init) and then release it at the end of the function, 
but it's not really necessary. The NSDate you create for 'now' should be valid 
through the function you made it in (likely it's on an autorelease pool which 
will be popped later)x

> 
> It would be a good idea to read Apple’s Memory Management documentation 
> before going any further, really.
> 
> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmRules.html
> 

This is vital. You must read and understand this memory management stuff. It's 
surprising you got this far without understanding it, perhaps you've been using 
properties which do a lot of the memory management for you and you just stopped 
and started using instance variables directly. 

You might want to run some of your current code through Instruments if you 
haven't already done so and check memory allocations and leaks, if you were 
confused on the memory management rules, it's easy to fail the other way and 
leak objects by not releasing them. 


___

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: There's obviously something I don't understand about NSDate.

>
> I create another NSDate, on the stack, to hold "now" for use within that
> function.  Do I need to retain that too?
>
>
> Yes.
>
>
 Hm, Apple's doc says:
"Cocoa’s ownership policy specifies that received objects should typically
remain valid throughout the scope of the calling method."

This leads me to believe that the object created by [NSDate date] within
that method will remain valid throughout the method.

Thanks for the info.  I read the memory-management doc a long time ago but
apparently didn't learn everything about autorelease.  I never use it in my
own 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

Re: There's obviously something I don't understand about NSDate.

I did read the memory-management docs a long time ago, and I've run my app
through both Leaks and the analyzer.  I avoid using properties because I
carefully manage my allocations.

I think the hole in my knowledge was limited to autorelease.  I never use
autorelease in my code, so my exposure to it is limited to those Cocoa
functions that use 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

Re: There's obviously something I don't understand about NSDate.

BTW, thanks for all the answers.  I appreciate it!

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

Re: There's obviously something I don't understand about NSDate.

Hmm - with respect - autorelease is an implementation detail. Nothing says that 
objects created through the convenience constructors like [ NSDate date ] have 
to be autoreleased, they just have to be valid for long enough to be useful, 
they could be held in a cache and cleaned out by little gnomes later. 

This was a basic question of ownership, the important difference is that 

[ [ NSDate alloc ] init ];

returns an object you own and 

[ NSDate date ]

returns an object you do not. That's the key memory management takeaway here 
and is why you needed to retain the [ NSDate date ] when you put it in an 
instance variable (and release it later when you're done with it). No mention 
of autorelease pools there, just the concept of ownership. 

On Mar 18, 2012, at 7:38 AM, G S wrote:

> I did read the memory-management docs a long time ago, and I've run my app 
> through both Leaks and the analyzer.  I avoid using properties because I 
> carefully manage my allocations.
> 
> I think the hole in my knowledge was limited to autorelease.  I never use 
> autorelease in my code, so my exposure to it is limited to those Cocoa 
> functions that use 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

Re: There's obviously something I don't understand about autorelease.

On Sat, Mar 17, 2012 at 4:55 PM, Roland King  wrote:

> Hmm - with respect - autorelease is an implementation detail. Nothing says
> that objects created through the convenience constructors like [ NSDate
> date ] have to be autoreleased, they just have to be valid for long enough
> to be useful, they could be held in a cache and cleaned out by little
> gnomes later.
>

Fair enough.  Better to have said, "objects I didn't allocate."

I would've converted my project to ARC had time permitted.  I will say that
this new understanding does make me reconsider my opinion on the merits of
properties (meaning I think they have more merit than I used to).

Would it be a waste of time to go through and add properties for my members
before converting to ARC?  Does it make any difference?
___

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: There's obviously something I don't understand about autorelease.


> 
> I would've converted my project to ARC had time permitted.  I will say that 
> this new understanding does make me reconsider my opinion on the merits of 
> properties (meaning I think they have more merit than I used to).
> 
> Would it be a waste of time to go through and add properties for my members 
> before converting to ARC?  Does it make any difference?


Yes it would be a waste of time I think. If the code is working, leave it 
alone. I love ARC although I'm pleased I learned manual-retain-release first 
and now don't have to worry about 99% of memory issues. 

I like properties, even private ones, because I like to split the interface of 
the class, even the methods it only uses itself, from the implementation. So 
often I find I start with 

@synthesize foo=_foo;

and by the time I get to the end of the project I've written custom foo: and 
setFoo: methods which do something else too. 

But it's all in the end just style and what makes you most productive. I follow 
one pattern which works for me. 
___

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: There's obviously something I don't understand about NSDate.

2012-03-17 Thread Eeyore

I believe you were also on the discussion of properties vs. direct ivar access. 
This ties into that discussion. If you declare/define a property with:

@property (nonatomic, retain) NSDate* firstBadAccuracyTime;

and

@synthesize firstBadAccuracyTime=_firstBadAccuracyTime;

then the runtime will automatically retain the value in the setter, allowing 
you to make a call:

self.firstBadAccuracyTime = [NSDate date];

You would still need to release the object in dealloc

[_firstBadAccuracyTime release]

If you are using ARC, the property would be

@property (nonatomic, strong) NSDate* firstBadAccuracyTime;

the synthesize and set statements would be the same, but you would not be 
required to make the release call in dealloc. By using direct ivar access, you 
are taking the responsibility to handle the memory management yourself, meaning 
you really need to understand autorelease pools (see references in other posts).

Aaron

On Mar 17, 2012, at 3:38 PM, G S wrote:

> I have a member variable to hold an NSDate:
> 
>NSDate* _firstBadAccuracyTime;
> 
> At some point, something happens and I set this value to "now":
> 
>_firstBadAccuracyTime = [NSDate date];
> 
> On my next trip through this function, I calculate how long it has been
> since I set this date:
> 
>NSDate* now = [NSDate date];
>if([now timeIntervalSinceDate:_firstBadAccuracyTime] >
> BAD_ACCURACY_TIME)
> 
> then CRASH: BAD ACCESS
> 
> _firstBadAccuracyTime still contains a valid address, but the object
> must've been released.  Why?  If I add a retain where I assign it, the
> crash doesn't happen.  I added autorelease, but then got a crash on
> releasing an object I hadn't allocated (which makes me think it's already
> autoreleased).
> 
> 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/eeyore%40monsterworks.com
> 
> This email sent to eey...@monsterworks.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: There's obviously something I don't understand about NSDate.

On Sat, Mar 17, 2012 at 5:19 PM, Eeyore  wrote:

> I believe you were also on the discussion of properties vs. direct ivar
> access. This ties into that discussion.

Yep.  That's why I mentioned that I see new merit to properties.

You would still need to release the object in dealloc
>
> [_firstBadAccuracyTime release]
>
>
Not a big fan of that asymmetry, but ARC will make it nicer.

Thanks.
___

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: There's obviously something I don't understand about autorelease.

2012-03-17 Thread Richard Somers

On Mar 17, 2012, at 6:12 PM, Roland King wrote:

> So often I find I start with 
> 
> @synthesize foo=_foo;
> 
> and by the time I get to the end of the project I've written custom foo: and 
> setFoo: methods which do something else too. 

I have also done that but I recently read a blog where the writer recommends 
"Do not override @synthesized properties with your own code: use @dynamic 
properties instead ...".

 http://wiki.akosma.com/Objective-C_Code_Standards

I would be curious if anyone else has an opinion on that one way or the other.

--Richard

___

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: There's obviously something I don't understand about autorelease.

2012-03-17 Thread Eeyore

On Mar 17, 2012, at 6:10 PM, Richard Somers wrote:

> On Mar 17, 2012, at 6:12 PM, Roland King wrote:
> 
>> So often I find I start with 
>> 
>> @synthesize foo=_foo;
>> 
>> and by the time I get to the end of the project I've written custom foo: and 
>> setFoo: methods which do something else too. 
> 
> I have also done that but I recently read a blog where the writer recommends 
> "Do not override @synthesized properties with your own code: use @dynamic 
> properties instead ...".
> 
> http://wiki.akosma.com/Objective-C_Code_Standards
> 
> I would be curious if anyone else has an opinion on that one way or the other.

If you define methods foo and setFoo:, you don't need to use @dynamic or 
@synthesize (but I doubt it hurts). I think @dynamic tends to be used in 
situations where you want to promise the compiler that these will be 
implemented, but the compiler cannot determine that while parsing the source (I 
think these arise in Core Data).

Aaron

___

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: There's obviously something I don't understand about autorelease.

On Mar 18, 2012, at 9:10 AM, Richard Somers wrote:

> On Mar 17, 2012, at 6:12 PM, Roland King wrote:
> 
>> So often I find I start with 
>> 
>> @synthesize foo=_foo;
>> 
>> and by the time I get to the end of the project I've written custom foo: and 
>> setFoo: methods which do something else too. 
> 
> I have also done that but I recently read a blog where the writer recommends 
> "Do not override @synthesized properties with your own code: use @dynamic 
> properties instead ...".
> 
> http://wiki.akosma.com/Objective-C_Code_Standards
> 
> I would be curious if anyone else has an opinion on that one way or the other.
> 
> --Richard
> 

I don't know what he's talking about. I don't override synthesized properties, 
I remove the synthesized and replace it with my own  and 
set: methods  (**) and that's totally supported (and necessary if you 
are going to do more than just set an ivar) 

Nor do I know if he understands what @dynamic means, if you are writing your 
own getters and setters and putting them in the .m file then you don't need 
@dynamic. @dynamic means "I haven't synthesized the property nor written a 
getter/setter for it so you want to give me a compile error. Please don't, I 
will make the code dynamically available at runtime, like core data does for 
instance". 

Sorry but I take that blog entry with a pinch of salt. 

Roland

(**) You don't need to remove the @synthesize either if you don't want to, you 
can leave it there and still write your own getter and setter, they will 
override. Why however would you do this. The only good reason I've found is 
because I've done this piece of stupidity twice now. (The code below uses ARC)

Bar.h

@interface Bar
{
Foo *_foo;  // booboo on foo declaration
}

@property( readwrite, weak )Foo *foo;

Bar.m

@synthesize foo=_foo;   // syntheisze it - this gives a helpful compile 
error

// override it
-(Foo*)foo
{
return _foo;
}

-(void)setFoo:(Foo*)foo
{
_foo=foo;
[ self doSomethingClever ];
}

The error here is that the property foo is declared weak but the ivar _foo is 
strong. It's REMARKABLY easy to make that mistake when you change a property 
from strong to weak when for-instance you discover a retain cycle and forget to 
change the underlying ivar. If the @synthesize is there, the compiler catches 
the mismatch, very useful, if you leave it out because you don't need it, 
nothing catches it and you have a weak property using a strong ivar and ... you 
still have a retain cycle. 

This leads to my last pet peeve which is that I think property syntax should 
have always been 

@property( readwrite, weak, ivar=_foo)  Foo *foo;

where the underlying ivar for the property, if there is one, is declared as 
part of the property declaration instead of split into the synthesize 
directive, but that ship I suspect has sailed a long time ago.  
___

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: There's obviously something I don't understand about autorelease.

On Mar 17, 2012, at 5:05 PM, G S wrote:
> I would've converted my project to ARC had time permitted.  I will say that
> this new understanding does make me reconsider my opinion on the merits of
> properties (meaning I think they have more merit than I used to).
> 
> Would it be a waste of time to go through and add properties for my members
> before converting to ARC?  Does it make any difference?

With ARC, instance variables by default get the same automatic memory 
management as retaining properties. When you assign to a strong ivar in ARC any 
old value is released and the new value is retained. You don't need to use 
properties in ARC solely to get their memory management behavior.

-- 
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: There's obviously something I don't understand about autorelease.

On Mar 17, 2012, at 6:34 PM, Roland King wrote:
> This leads to my last pet peeve which is that I think property syntax should 
> have always been 
> 
>   @property( readwrite, weak, ivar=_foo)  Foo *foo;
> 
> where the underlying ivar for the property, if there is one, is declared as 
> part of the property declaration instead of split into the synthesize 
> directive, but that ship I suspect has sailed a long time ago.  

The @property/@synthesize split tries to separate public interface from private 
implementation details. That's why the ivar is not in the @property.

If you have the Xcode 4.4 developer prerelease, the new synthesize-by-default 
feature may be close to what you want.

-- 
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: There's obviously something I don't understand about autorelease.

On Mar 18, 2012, at 9:53 AM, Greg Parker wrote:

> 
> If you have the Xcode 4.4 developer prerelease, the new synthesize-by-default 
> feature may be close to what you want.
> 
> 
> -- 
> Greg Parker gpar...@apple.com Runtime Wrangler
> 
> 

I do, and am just downloading DP2 as well. There is some COOL stuff in there 
which of course I won't talk about (but please bring it to iOS soon). The 
auto-synthesize is super useful, wouldn't however save me from my own stupidity 
in the case I wrote about where I have to write my own getters and setters 
because they do more than set an ivar. I will just need to be more diligent 
checking ivars against the properties they support to ensure they match (strong 
to strong, weak to weak .. really shouldn't be that hard for me!) 

___

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: There's obviously something I don't understand about autorelease.

On Mar 17, 2012, at 6:59 PM, Roland King wrote:
> I do, and am just downloading DP2 as well. There is some COOL stuff in there 
> which of course I won't talk about (but please bring it to iOS soon). The 
> auto-synthesize is super useful, wouldn't however save me from my own 
> stupidity in the case I wrote about where I have to write my own getters and 
> setters because they do more than set an ivar. I will just need to be more 
> diligent checking ivars against the properties they support to ensure they 
> match (strong to strong, weak to weak .. really shouldn't be that hard for 
> me!) 

Hmm, I wonder if it would be possible for the static analyzer to help with that 
sort of check. You should file a bug report / feature request.


-- 
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: There's obviously something I don't understand about autorelease.

2012-03-17 Thread Quincey Morris

On Mar 17, 2012, at 18:59 , Roland King wrote:

> I will just need to be more diligent checking ivars against the properties 
> they support to ensure they match 

Clang *was* checking this, at least in Xcode 4.2.

We had a thread a couple of months ago discussing this, in a case where the 
check was over-zealous. Clang would produce a warning for '@synthesize foo' if 
the property was declared '@property (readonly)', and required you to declare 
it as '@property (readonly, strong)' to avoid the warning.

I mention this because Xcode 4.3's clang doesn't complain about this any more.

Also, note that 'weak' and 'strong' etc really shouldn't be on @property 
either, since they only affect the way the ivar is handled. The property itself 
is neither weak nor strong.

The justification given for leaving them on @property was that the complication 
of attributes on @synthesize seemed undesirable, and that @synthesize is headed 
the way of the dodo anyway.

___

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: There's obviously something I don't understand about autorelease.

On Mar 17, 2012, at 7:35 PM, Quincey Morris wrote:
> The justification given for leaving them on @property was that the 
> complication of attributes on @synthesize seemed undesirable, and that 
> @synthesize is headed the way of the dodo anyway.

The memory management behavior of a property frequently is part of the public 
interface. For example, if you want to understand your retain cycles then it's 
important to know which properties are strong and which are weak. Or if you 
have a mutable string then it's important to know which properties are 
retaining and which are copying.

-- 
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: How to get Mac codesign certificate?

2012-03-17 Thread Kurt Revis

The SMJobBless example code has a ReadMe.txt file that explains how to make a 
self-signed certificate, and how to set up the project to use it.  It worked 
correctly when I tried it.

https://developer.apple.com/library/mac/#samplecode/SMJobBless/Listings/ReadMe_txt.html

> You can get a self-signed code signing identity using these steps:
> 
> 1. Launch Keychain Access.
> 2. Select Keychain Access > Certificate Assistant > Create a Certificate...
> 3. In the Name field, enter "Joe Developer".
> 4. Change Certificate Type to "Code Signing".
> 5. Press Continue.
> 6. You're done!
> 
> If you use a signing identity with a different Common Name (CN), you will 
> need to change the CN in four places:
> 
> o The Code Signing Identity build setting in the target SMJobBlessApp
> o The Code Signing Identity build setting in the target 
> com.apple.bsd.SMJobBlessHelper
> o The SMPrivilegedExecutables property in SMJobBlessApp-Info.plist
> o The SMAuthorizedClients property in SMJobBlessHelper-Info.plist
> 
> Once you have your code signing identity set up and the project configured to 
> refer to the desired code signing identity, you should be able to just choose 
> Build from the Build menu.


___

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: There's obviously something I don't understand about autorelease.

2012-03-17 Thread Ken Thomases

On Mar 17, 2012, at 9:35 PM, Quincey Morris wrote:

> Also, note that 'weak' and 'strong' etc really shouldn't be on @property 
> either, since they only affect the way the ivar is handled. The property 
> itself is neither weak nor strong.

This doesn't seem right.  It's an important part of the semantics of a property 
whether it holds a strong or weak reference.  It is _not_ just an 
implementation detail.  The logic is just the same as for pre-ARC retain/assign 
properties.

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: There's obviously something I don't understand about NSDate.

On Mar 17, 2012, at 7:19 PM, Eeyore wrote:

> I believe you were also on the discussion of properties vs. direct ivar 
> access. This ties into that discussion. If you declare/define a property with:
> 
> @property (nonatomic, retain) NSDate* firstBadAccuracyTime;
> 
> If you are using ARC, the property would be
> 
> @property (nonatomic, strong) NSDate* firstBadAccuracyTime;

One thing to add is that if your property is a type of object for which there 
exists a mutable variant — NSString, NSArray, etc. — then you should use copy 
instead of retain/strong. For immutable objects, this will just do a retain 
anyway, so no harm no foul, but if someone passes, say, an NSMutableString to 
your property, you’d want to make an immutable copy of it so that the value 
wouldn’t change under your feet.

Charles
___

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: There's obviously something I don't understand about autorelease.

On Mar 17, 2012, at 7:05 PM, G S wrote:

> On Sat, Mar 17, 2012 at 4:55 PM, Roland King  wrote:
> 
>> Hmm - with respect - autorelease is an implementation detail. Nothing says
>> that objects created through the convenience constructors like [ NSDate
>> date ] have to be autoreleased, they just have to be valid for long enough
>> to be useful, they could be held in a cache and cleaned out by little
>> gnomes later.
>> 
> 
> Fair enough.  Better to have said, "objects I didn't allocate.”

Or better yet, “objects you don’t own.” In addition to allocating an object, 
you can take ownership of an object by retaining an object that something else 
passes to you.

> I would've converted my project to ARC had time permitted.  I will say that
> this new understanding does make me reconsider my opinion on the merits of
> properties (meaning I think they have more merit than I used to).
> 
> Would it be a waste of time to go through and add properties for my members
> before converting to ARC?  Does it make any difference?

It makes the code cleaner and more flexible, IMO.

Charles
___

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: There's obviously something I don't understand about autorelease.