Re: ARC and Singletons

[Karl Goiser]

Yes they are.


They are a kludge that came about because C++ doesn’t implement object 
behaviour properly.

Try this: http://www.google.com/search?hl=en&q=Singleton%2Bevil


You have not said what about NSFileManager is a great example of the singleton 
pattern.


Of course class methods have their purposes: lots of them!
Normally, not even a class method is allowed to break encapsulation.  What I 
think you mean is that a class method sets class properties that all instances 
of that class refer to..


Of course, class methods aren’t a replacement for the singleton pattern: the 
singleton pattern is a fix for inadequately designed languages.


Karl



On 02/08/2011, at 2:02 PM, Kyle Sluder wrote:

> On Mon, Aug 1, 2011 at 7:14 PM, Karl Goiser  wrote:
>> Wow, class methods finally get the tick of approval!  Only 30+ years after 
>> being specified in the Smalltalk standard..
>> 
>> 
>> Forget about singletons: they are just a workaround for not having class 
>> methods/variables.
> 
> No, they're not. I mentioned the NSFileManager example above; that was
> a great example of how the singleton pattern is more flexible than
> using class methods for the same task.
> 
> Class methods have their purpose. Cocoa and Cocoa Touch use them to
> great effect in places like +[UIView setAnimationsEnabled:], where the
> method logically applies to instances of that class. They help
> maintain encapsulation, since they are defined inside the class and
> therefore, following typical good design principles, are allowed to
> peek behind the public veil of instances.
> 
> But class methods aren't a replacement for the singleton pattern. Even
> if we had class storage (which in practice would be no different from
> static global variables except for scope), class methods would still
> be appropriate for a different set of tasks.
> 
> I wouldn't hold my breath waiting for Apple or anyone else to drop the
> singleton pattern and adopt class methods.
> 
> --Kyle Sluder


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and Singletons

[Kyle Sluder]

On Mon, Aug 1, 2011 at 7:14 PM, Karl Goiser  wrote:
> Wow, class methods finally get the tick of approval!  Only 30+ years after 
> being specified in the Smalltalk standard..
>
>
> Forget about singletons: they are just a workaround for not having class 
> methods/variables.

No, they're not. I mentioned the NSFileManager example above; that was
a great example of how the singleton pattern is more flexible than
using class methods for the same task.

Class methods have their purpose. Cocoa and Cocoa Touch use them to
great effect in places like +[UIView setAnimationsEnabled:], where the
method logically applies to instances of that class. They help
maintain encapsulation, since they are defined inside the class and
therefore, following typical good design principles, are allowed to
peek behind the public veil of instances.

But class methods aren't a replacement for the singleton pattern. Even
if we had class storage (which in practice would be no different from
static global variables except for scope), class methods would still
be appropriate for a different set of tasks.

I wouldn't hold my breath waiting for Apple or anyone else to drop the
singleton pattern and adopt class methods.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and Singletons

[Karl Goiser]

Wow, class methods finally get the tick of approval!  Only 30+ years after 
being specified in the Smalltalk standard..


Forget about singletons: they are just a workaround for not having class 
methods/variables.


Each class is a single object that exists for the life of the application 
therefore it is, by definition a singleton - and you get it for free!


You don’t need to keep and manage variables pointing to the class because you 
already have it when you send a message to a class method.


Karl

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?

[Greg Parker]

On Aug 1, 2011, at 5:51 PM, Wade Tregaskis wrote:
>>> Any code that throws exceptions will probably leak a few objects, since 
>>> according to the ARC design doc the ABI requires not draining autorelease 
>>> pools while unwinding the stack.
>> 
>> Are you sure (or does ARC work differently)?
>> 
>> :
> 
> That'll need to be updated.  If you look at the @autoreleasepool section of 
> the ARC documentation, it specifically states that crossing out of one via an 
> exception will not drain the pool.  There doesn't appear to be any way, even 
> through compiler flags, to change this.

If an autorelease pool pop is skipped by an exception, then the autorelease 
pool will not be drained immediately. However, it will generally be drained 
later, after the exception is caught and handled and some parent pool itself is 
drained normally.

@autoreleasepool is no different from NSAutoreleasePool here. 

http://sealiesoftware.com/blog/archive/2008/09/16/objc_explain_Exceptions_and_autorelease_pools.html

(There is a bug in SnowLeopard and Lion: if an NSAutoreleasePool drain is 
skipped, then the pool's contents are cleaned up later as described, but the 
NSAutoreleasePool object itself may leak. @autoreleasepool fixes this small 
leak if your deployment target is Lion, because it never allocates the 
NSAutoreleasePool object in the first place.)


-- 
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?

[Graham Cox]

Only vaguely following this thread, but two observations occur (rather obvious 
ones at that):

a) NSKeyed(Un)Archiver can take a delegate

b) NSKeyed(Un)Archiver can be subclassed

The first allows you to refine the behaviour of the standard object, the second 
allows you to reimplement it any way you please, while keeping the same overall 
approach.

So, if you feel the built-in class lacks for something, you can easily take the 
matter into your own hands.

--Graham





On 02/08/2011, at 9:29 AM, Jerry Krinock wrote:

> 
> On 2011 Aug 01, at 12:45, Martin Wierschin wrote:
> 
>> This is even worse than the original problem. Rather than getting an 
>> exception at the time of encoding, now you're silently converting 
>> unencodable objects to strings.
> 
> Thank you, Martin.  That is correct.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?

[Wade Tregaskis]

>> Any code that throws exceptions will probably leak a few objects, since 
>> according to the ARC design doc the ABI requires not draining autorelease 
>> pools while unwinding the stack.
> 
> Are you sure (or does ARC work differently)?
> 
> :

That'll need to be updated.  If you look at the @autoreleasepool section of the 
ARC documentation, it specifically states that crossing out of one via an 
exception will not drain the pool.  There doesn't appear to be any way, even 
through compiler flags, to change this.

Also, if you look further, at the Exceptions section, it states that by default 
ARC is not exception-safe even aside from autorelease pools.  You can enable 
it, though - and it is enabled by default for Objective-C++ - using 
-fobjc-arc-exceptions.

You'll note that the "Rationale" comments on those two sections specifically 
lay out the expected usage of exceptions:  for programmer error.  That they're 
tolerated [somewhat] in Objective-C++ is simply a nod to history for the sake 
of compatibility.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?

[Wade Tregaskis]

>>> Granted that NSKeyedUnarchiver might have left some memory leaks or 
>>> partially uninitialized objects somewhere, but unarchiving an invalid 
>>> object should happen rarely if at all... and ordinarily my own code should 
>>> never get pointers to such objects, anyway.
>> 
>> Indeed there may be memory leaks, but that's a relatively benign side 
>> effect.  The security issues I alluded to earlier are a much greater concern 
>> in any case.
> 
> Can you be more specific about those side effects? I'm rather curious,
> and somewhat concerned; I've used NSCoding in the past for persisting
> data.


[[ Sorry for the delay; I've had a busy weekend. ]]

Basically, because there's little validation built-in to NSUnarchiver.  I'm 
going to talk about "attackers" here, but keep in mind that you can substitute 
"random corruption" and the points stand.  So even without an "evil hacker" 
going after your app, you could still hit these issues.

So, some problems:

1) People typically do little validation of values they unarchive, so an 
attacker could substitute all sorts of things which might put the object into 
an unexpected state.  While any individual developer could write their decoding 
carefully, I don't know if all of the standard Apple classes that they're 
likely using have similarly robust validation.  Plus in practice it's sometimes 
tricky to do this validation, and it feels awkward because it can create a lot 
of redundant code within your object.

2) Because the archive can specify any class that supports NSCoding.  While 
technically you can work around this, by subclassing NSKeyedUnarchiver and 
overriding something like -classForClassName:, and having it throw an exception 
for invalid class names, most people don't do this.  And even that is 
preferable to the approach of checking the decoded object's class because it 
prevents any code of that object being run (i.e. the decodeWithCoder:), since 
that code might itself have side-effects.

Some people recommend using property lists instead, since those are more 
restricted while being relatively similar.  They don't necessarily solve issue 
#1, but they are (as far as I know) immune to #2.  You could alternatively 
consider signing the encoded data, if that's possible for your use case.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?

[Kyle Sluder]

On Mon, Aug 1, 2011 at 4:29 PM, Jerry Krinock  wrote:
> Thus, My New Code gives the same result as the Classic Approach, but it does 
> so without raising an exception.  So I'm thinking about changing from Classic 
> Approach to My New Code in my next project.  I always like to think long and 
> hard before applying a category to NSObject, though.

That is worse. Throwing an exception at a predetermined point is far
superior to maybe throwing an exception sometime in the future when
you happen to send a message that the receiver doesn't respond to.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?

[Jerry Krinock]

On 2011 Aug 01, at 12:45, Martin Wierschin wrote:

> This is even worse than the original problem. Rather than getting an 
> exception at the time of encoding, now you're silently converting unencodable 
> objects to strings.

Thank you, Martin.  That is correct.

> When you unarchive one of those strings, code expecting an instance of 
> UnencodableFoo will instead have an NSString, the use of which will likely 
> throw exceptions, eg: when code calls -[UnencodableFoo fooThing]

No, it's not likely if UnencodableFoo is *my* code, because I program 
defensively when dealing with input data such as an archive :)

However, I agree that someone else's code might throw an exception.

But I wouldn't say it's worse.  Compare…

• Classic Approach, @try/catch when archiving:  Results in an unavoidable 
exception, which could be caught, but an unavoidable turd left in stderr.  

• My New Code Code Posted Yesterday:  A possible exception, and a possible 
turd, if I or someone else does not program defensively.

Actually, there could be another error in the Classic Approach because – what 
do you do in the @catch block?  Returning nil when an archive was expected may 
cause an issue.  Presently, when I'm archiving an NSError in my @catch block, I 
replace the object with a string anyhow, which is the same thing I do in my My 
New Code.

Thus, My New Code gives the same result as the Classic Approach, but it does so 
without raising an exception.  So I'm thinking about changing from Classic 
Approach to My New Code in my next project.  I always like to think long and 
hard before applying a category to NSObject, though.

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSAttributedString -initWithPath RTFD crash on Lion

[jonat...@mugginsoft.com]

On 1 Aug 2011, at 20:48, Martin Wierschin wrote:

> I don't have any advice on the actual crash, but:
> 
>> The following workaround seems reliable:
>> 
>> // get path to rtf file
>> NSString *filePath = [path stringByAppendingPathComponent:@"TXT.rtf"];
> 
> Be aware that would probably miss any images/attachments saved in the RTFD 
> package.
> 
Thanks Martin

It turns out that my sample resources don't have any images.
But you are right, any images that I embed don't render when the RTF file is 
reloaded using the above approach.

I tried loading the RTFD via an NSURL and an NSFileWrapper but the issue 
persists.

I could try refactoring my code to change the code path.
The problem code path winds through a number of bindings and observations but I 
don't see why that should effect loading the RTFD.

Regards

Jonathan Mitchell

Developer
Mugginsoft LLP
http://www.mugginsoft.com___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: core data migration - delete old store

[Dave Fernandes]

I'm not using autosave. In fact this is done in my document controller before 
the NSPersistentDocument is even created. Does the Core Data stack have some 
awareness of an autosave mode? Perhaps, as you suggest, Apple has dropped this 
feature and this is just a documentation bug. Hope someone from Apple can 
comment on whether this is the case.

On 2011-08-01, at 1:08 AM, Jerry Krinock wrote:

> 
> On 2011 Jul 31, at 21:18, Dave Fernandes wrote:
> 
>> I just found a strange thing on Lion: the backup~ file doesn't get produced 
>> with in-place lightweight migration. The same binary *does* create the 
>> backup~ file on Snow Leopard, though. Has anyone else noticed this?
> 
> Have not noticed it because I use my own migration code.  If you are using 
> Auto Save, though, there would be no need for the ~ files since they should 
> be available in Versions browser, so it would make sense that Apple drop this 
> "feature".
> 
> I definitely wouldn't consider it much of a loss, though.  The only thing 
> those ~ files have done for me is to confuse users.
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Unnecessary Boolean Warning

[Scott Ribe]

On Aug 1, 2011, at 2:36 PM, Jeffrey Walton wrote:

> I wish I had a dollar for every time I lazy fingered `=` rather than
> `==`. And another buck for each time the compiler caught it (I use
> `-Wall` -Wextra` and firends).

Well, firend, I believe you ;-)

-- 
Scott Ribe
scott_r...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Unnecessary Boolean Warning

[Jeffrey Walton]

On Mon, Aug 1, 2011 at 4:08 PM, Greg Parker  wrote:
>
> On Aug 1, 2011, at 8:47 AM, Gordon Apple wrote:
>
>> It’s not that I object to anyone doing it, if that makes them more
>> comfortable, but a warning on ““&&” inside of “||”” is ridiculous.  Everyone
>> knows that multiplication takes precedence over addition.  “&&” is a
>> multiplication.  “||” is, welll, almost an addition.  (Exor is addition in a
>> mod 2 system.}  Anyone who can’t at least keep these two straight shouldn’t
>> be doing programming.  Overall operator precedence is a little more
>> complicated and I would recommend , for those who don’t have it all down,
>> copying the page (two page spread) out of K&E or Stroustroup and taping it
>> to the wall.  (I have done that in the past.) I just think this particular
>> warning is carrying things to the extreme.  What next?  Warning: “*” inside
>> of “+”?
>>
>> I don’t object to warnings.  “Assignment inside of “if”” is a good thing,
>> because it is a common, easily committed, error, and I appreciate the
>> warning.
>
> "A warning on `==` inside of `if` is ridiculous. `==` is comparison for 
> equality. `=` is assignment. Anyone who can't at least keep these two 
> straight shouldn't be doing programming."
>
> One programmer's appreciated warning is another programmer's annoying noise. 
> If you think some warning is noise, turn it off. Please don't belittle those 
> of us who are not perfect.
>
I wish I had a dollar for every time I lazy fingered `=` rather than
`==`. And another buck for each time the compiler caught it (I use
`-Wall` -Wextra` and firends).

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Unnecessary Boolean Warning

[Greg Parker]

On Aug 1, 2011, at 8:47 AM, Gordon Apple wrote:

> It’s not that I object to anyone doing it, if that makes them more
> comfortable, but a warning on ““&&” inside of “||”” is ridiculous.  Everyone
> knows that multiplication takes precedence over addition.  “&&” is a
> multiplication.  “||” is, welll, almost an addition.  (Exor is addition in a
> mod 2 system.}  Anyone who can’t at least keep these two straight shouldn’t
> be doing programming.  Overall operator precedence is a little more
> complicated and I would recommend , for those who don’t have it all down,
> copying the page (two page spread) out of K&E or Stroustroup and taping it
> to the wall.  (I have done that in the past.) I just think this particular
> warning is carrying things to the extreme.  What next?  Warning: “*” inside
> of “+”?
> 
> I don’t object to warnings.  “Assignment inside of “if”” is a good thing,
> because it is a common, easily committed, error, and I appreciate the
> warning.

"A warning on `==` inside of `if` is ridiculous. `==` is comparison for 
equality. `=` is assignment. Anyone who can't at least keep these two straight 
shouldn't be doing programming."

One programmer's appreciated warning is another programmer's annoying noise. If 
you think some warning is noise, turn it off. Please don't belittle those of us 
who are not perfect.


-- 
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSAttributedString -initWithPath RTFD crash on Lion

[Martin Wierschin]

I don't have any advice on the actual crash, but:

> The following workaround seems reliable:
> 
> // get path to rtf file
> NSString *filePath = [path stringByAppendingPathComponent:@"TXT.rtf"];

Be aware that would probably miss any images/attachments saved in the RTFD 
package.

~Martin

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Why Don't Cocoa's (Un)Archiving Methods return Errors?

[Martin Wierschin]

>>> I don't think so, Jens.  "They" is Apple.  Apple has the source code for 
>>> -initWithCoder: and -encodeWithCoder:. 
>> 
>> No they don’t — not for the implementations of those methods in our own 
>> classes…
> 
> Thank you, Jens.  I see the problem.
> 
> Here's a fairly radical solution:
...
> @implementation NSObject (LookMaNoEncodingExceptions)
> 
> - (void)encodeWithCoder:(NSCoder*)coder {
>NSString* archivoid = [NSString stringWithFormat:
>   @"Sorry, %@ is not encodable.\n"
>   @"Here's a description of it: %@",
>   [self className],
>   [self description]] ;
>[coder encodeObject:archivoid
> forKey:@"Archivoid"];
> }

This is even worse than the original problem. Rather than getting an exception 
at the time of encoding, now you're silently converting unencodable objects to 
strings. When you unarchive one of those strings, code expecting an instance of 
UnencodableFoo will instead have an NSString, the use of which will likely 
throw exceptions, eg: when code calls -[UnencodableFoo fooThing]

~Martin

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and Singletons

[Jeff Kelley]

Traditionally, I used the standard +sharedInstance type of singleton, but I 
returned it autoreleased and in its dealloc method, set the sharedInstance 
variable to nil if it was the shared instance:

> - (void)dealloc
> {
> if (self == sharedInstance) {
> sharedInstance = nil;
> }
> 
> // Clean up ivars here
> 
> [super dealloc];
> }

When I create a singleton I did it like this:

> + (MySingletonClass *)sharedInstance
> {
> if (sharedInstance == nil) {
> sharedInstance = [[[self alloc] init] autorelease];
> }
> 
> return sharedInstance;
> }

That had the advantage of allowing the singleton to be released and free up its 
memory if no longer needed, but I think the tradeoff in code simplicity with 
ARC will be worth the handful of pointers that will stick around in memory with 
my singleton staying alive. There were also obviously concurrency concerns.

If I were retaining something large, such as graphics, in the singleton, I 
guess I’d have to respond to memory warnings appropriately and kill resources 
at that time.

Thanks for the feedback, guys.

Jeff Kelley

On Aug 1, 2011, at 1:52 PM, David Duncan wrote:

> On Aug 1, 2011, at 10:12 AM, Kyle Sluder wrote:
> 
>> On Mon, Aug 1, 2011 at 9:05 AM, Dave Zarzycki  wrote:
>>> The simplest and most ARC friendly way to implement the singleton pattern 
>>> is to switch from instance methods to class methods – because the class 
>>> itself is by definition a singleton. In other words:
>> 
>> Eek, this might be conceptually simple but it's a ton of work and
>> giant step backwards in API design. Remember when -[NSFileManager
>> alloc] became useful in 10.5?
> 
> 
> There's nothing wrong with using the +sharedInstance approach either, just 
> remove all the shenanigans that were defined to ensure that there was only 
> one instance. In the majority of cases it was likely overkill and potentially 
> masking memory management bugs.
> --
> David Duncan
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and Singletons

[David Duncan]

On Aug 1, 2011, at 10:12 AM, Kyle Sluder wrote:

> On Mon, Aug 1, 2011 at 9:05 AM, Dave Zarzycki  wrote:
>> The simplest and most ARC friendly way to implement the singleton pattern is 
>> to switch from instance methods to class methods – because the class itself 
>> is by definition a singleton. In other words:
> 
> Eek, this might be conceptually simple but it's a ton of work and
> giant step backwards in API design. Remember when -[NSFileManager
> alloc] became useful in 10.5?


There's nothing wrong with using the +sharedInstance approach either, just 
remove all the shenanigans that were defined to ensure that there was only one 
instance. In the majority of cases it was likely overkill and potentially 
masking memory management bugs.
--
David Duncan

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [iOS] Block animation kills performance

[Rick Mann]

Thank you, Roland, for that thorough explanation. Now I understand what's going 
on and why. I will write a bug, if only to get the docs improved.

-- 
Rick

On Aug 1, 2011, at 3:38 , Roland King wrote:

> 
> On Aug 1, 2011, at 8:08 AM, Rick Mann wrote:
> 
>> 
>> On Jul 31, 2011, at 17:04 , Roland King wrote:
>> 
>>> On Aug 1, 2011, at 7:32, Rick Mann  wrote:
>>> 
 
 On Jul 31, 2011, at 16:23 , Hunter Hillegas wrote:
 
> Are you sure you don't need UIViewAnimationOptionAllowUserInteraction and 
> animateWithDuration:delay:options:animations:completion:?
 
 No, I'm not sure :-) I've never worried about that option before, and 
 don't know why it would be different from one approach to the other.
 
 Why do I need it for the block approach and not for the other?
 
 The docs for UIViewAnimationOptionAllowUserInteraction suggest it's only 
 necessary for views that are animating that require user interaction; that 
 is not the case for me. The animating view does not have any user 
 interaction. It's all the other views in my app that fail to respond.
 
 -- 
 Rick
 
> 
>>> 
>>> You need it. 
>> 
>> Why do I need it? That doesn't seem to be what the docs say.
> 
> The docs aren't wonderful on that point I'd agree, you can read 'views' in 
> the description of the flag a variety of different ways and I would suggest 
> requesting a doc change clarifying it. However since that method was 
> introduced as far as I know it's always worked that way and has disabled all 
> user interaction on all views in your application during an animation. So if 
> you want any user interaction when using that method, you need the flag. 
> 
>> 
>> Is it a bug? Why would iOS have a default mode that stops all user 
>> interaction if anything is animating?
> 
> I don't think it's a bug, it's a choice. Having user interaction disabled 
> when view animations are going on is something I could certainly see as a 
> useful option. Whether it makes sense to have had this as the default option 
> or not is definitely open to debate, and there have been comments suggesting 
> apple might change it, but it would probably be rather hard to do that now so 
> we may well be stuck with it as it is. 
> 
>> 
> 
>> And why does it work fine with the older way of doing it?
> 
> The older way of doing it didn't have an option for disabling all view 
> interaction so that had to work that way. I don't see anywhere in the 
> documentation which says the new call with default arguments is a drop-in 
> replacement for the old method and Apple chose the default behavior they 
> wanted for the new API point. Again it's debatable what the smartest default 
> would have been, I would have thought that doing the thing closest to what 
> the old method did would be .. but Apple clearly didn't. 
> 
> You could certainly file it as a bug, be interesting if it came back as 
> 'works as designed' or 'dupe', but I don't quite know how Apple could change 
> this default behavior without breaking a lot of code. 
> 
>> -- 
>> 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and Singletons

[Kyle Sluder]

On Mon, Aug 1, 2011 at 10:12 AM, Kyle Sluder  wrote:
> if it's necessary to store the shared instance in an ivar, why not do
> the following:

Wow, I need coffee. ivars vs class variables…

Wow.

Forget that second example. That's just terrible.

Imagine, instead, I used whatever storage mechanism Dave recommended.
Or even objc_setAssociatedObject on the class object itself.

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and Singletons

[Kyle Sluder]

On Mon, Aug 1, 2011 at 9:05 AM, Dave Zarzycki  wrote:
> The simplest and most ARC friendly way to implement the singleton pattern is 
> to switch from instance methods to class methods – because the class itself 
> is by definition a singleton. In other words:

Eek, this might be conceptually simple but it's a ton of work and
giant step backwards in API design. Remember when -[NSFileManager
alloc] became useful in 10.5?

Is there some reason we cannot continue to use the previously common
path of storing the shared instance in a static global variable? Or,
if it's necessary to store the shared instance in an ivar, why not do
the following:

// MyClass.h
@interface MyClass : NSObject
+ (MyClass *)sharedInstance;
@end

// MyClass.m
@interface MyClass ()
{
  MyClass *_sharedInstance;
}
@end

@implementation MyClass

+ (void)sharedInstance;
{
  static dispatch_once_t once;
  dispatch_once(&once, ^{
_sharedInstance = [[self alloc] init];
  });

  return _sharedInstance;
}

@end

--Kyle Sluder
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: autoresizingMask and transformation

[David Duncan]

On Jul 31, 2011, at 7:18 PM, Tales Pinheiro De Andrade wrote:

> I have a custom view that have a square subview. The superview is stretched 
> in both directions when the device is rotated.
> 
> The subview has autoresizingMask=UIViewAutoresizingFlexibleHeight | 
> UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleTopMargin | 
> UIViewAutoresizingFlexibleBottomMargin | UIViewAutoresizingFlexibleLeftMargin 
> | UIViewAutoresizingFlexibleRightMargin;

If you want the view to remain square, then you don't want flexible height & 
width, because the default is to resize with respect for aspect ratio. If you 
want the view to resize but stay square, then you will have to resize it 
yourself. You can use the willAnimateAutorotation… method on UIViewController 
to do this with animation – see the docs for specifics.

--
David Duncan

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Unnecessary Boolean Warning

[Jean-Daniel Dupas]

If this warning bother you, just disable it.

clang is smart enough to tell you what flag you have to turn off in the warning 
message.

For instance, just add -Wno-constant-logical-operand in your other warning 
flags.


Le 1 août 2011 à 17:47, Gordon Apple a écrit :

> It’s not that I object to anyone doing it, if that makes them more
> comfortable, but a warning on ““&&” inside of “||”” is ridiculous.  Everyone
> knows that multiplication takes precedence over addition.  “&&” is a
> multiplication.  “||” is, welll, almost an addition.  (Exor is addition in a
> mod 2 system.}  Anyone who can’t at least keep these two straight shouldn’t
> be doing programming.  Overall operator precedence is a little more
> complicated and I would recommend , for those who don’t have it all down,
> copying the page (two page spread) out of K&E or Stroustroup and taping it
> to the wall.  (I have done that in the past.) I just think this particular
> warning is carrying things to the extreme.  What next?  Warning: “*” inside
> of “+”?
> 
> I don’t object to warnings.  “Assignment inside of “if”” is a good thing,
> because it is a common, easily committed, error, and I appreciate the
> warning.
> 
> 
> On 7/31/11 8:15 PM, "Graham Cox"  wrote:
> 
>> 
>> On 01/08/2011, at 6:13 AM, Gordon Apple wrote:
>> 
>>> Anybody who understands
>>> basic boolean operator precedence knows this is unnecessary.
>> 
>> 
>> True, but who does? I mean, sure, if everyone who ever sees your source has
>> that fully committed to heart, you're golden. Otherwise, what's the harm of a
>> few brackets to make it absolutely clear? It's not as if it makes any
>> difference to the object code. Code for readability.
>> 
>> --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:
> http://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org
> 
> This email sent to devli...@shadowlab.org

-- Jean-Daniel




___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and Singletons

[Dave Zarzycki]

On Aug 1, 2011, at 9:08 AM, Jeff Kelley wrote:

> Interesting. Your +setFoo: example, I’m assuming, sets a global int.

Correct.

> What about objects? I’m assuming that if I declare a global NSArray pointer 
> like so:
> 
> NSArray *foo = nil;

In general, globals default initialize to zero/nil/NULL and under ARC they must 
initialize to nil in order for ARC to work at all.

> and then have a +setFoo:(NSArray *)array method, that calling it with nil 
> will be sufficient to clean up the array (that is, the ARC code will release 
> the current array)?

Correct. Please be mindful of the fact that ARC does not magically fix 
concurrency issues (globals or otherwise).

davez


> 
> Jeff Kelley
> 
> 
> On Mon, Aug 1, 2011 at 12:05 PM, Dave Zarzycki  wrote:
> The simplest and most ARC friendly way to implement the singleton pattern is 
> to switch from instance methods to class methods – because the class itself 
> is by definition a singleton. In other words:
> 
>+ (MyClass *)sharedInstance;
>// and maybe override alloc/retain/release to enforce the singleton 
> pattern
>- (int)foo;
>- (void)setFoo:(int)val;
> 
> …becomes simply:
> 
>+ (int)foo;
>+ (void)setFoo:(int)val;
> 
> davez
> 
> 
> On Aug 1, 2011, at 8:48 AM, Jeff Kelley wrote:
> 
> > Is there a new recommended way to implement a singleton with ARC? I remember
> > hearing something about it, but I’m not sure what it was.
> >
> > Jeff Kelley

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and Singletons

[Dave DeLong]

That would work.  However, you lose out on being able to declare "foo" as an 
@property (not a big deal) and have to write the accessors yourself (annoying, 
since the compiler knows how to do this already but can't in this case).

Dave

On Aug 1, 2011, at 9:05 AM, Dave Zarzycki wrote:

> The simplest and most ARC friendly way to implement the singleton pattern is 
> to switch from instance methods to class methods – because the class itself 
> is by definition a singleton. In other words:
> 
>   + (MyClass *)sharedInstance;
>   // and maybe override alloc/retain/release to enforce the singleton 
> pattern
>   - (int)foo;
>   - (void)setFoo:(int)val;
> 
> …becomes simply:
> 
>   + (int)foo;
>   + (void)setFoo:(int)val;
> 
> davez
> 
> 
> On Aug 1, 2011, at 8:48 AM, Jeff Kelley wrote:
> 
>> Is there a new recommended way to implement a singleton with ARC? I remember
>> hearing something about it, but I’m not sure what it was.
>> 
>> Jeff Kelley
>> ___
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/cocoa-dev/zarzycki%40apple.com
>> 
>> This email sent to zarzy...@apple.com
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/davedelong%40me.com
> 
> This email sent to davedel...@me.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Receiving Unicode Input in NSView

[Bill Appleton]

Hi Aki and others,

So implementing the NSTextInputClient protocol works great in our
stand-alone product, we get unicode as expected

In the browser product we synthesize NSEvents for key downs and send them
through the same system with handleEvent

this does NOT work as expected, which i think is what Aki was trying to tell
me last week  :)

so this is because there must be extra hidden contextual information in the
system not captured in the NSEvents for keyDowns

so we DO have to use the (buggy, new) NPAPI handlers to get unicode text
into the plugin

Please jump right in if i am missing something... hopefully this thread will
help future travelers


Best,

Bill







On Fri, Jul 29, 2011 at 11:22 AM, Aki Inoue  wrote:

> Bill,
>
> > we used to call interpretKeyEvents in the keyDown handler and the
> InsertText
> > handler would get the unicode string, I guess this stopped working with a
> > system update a while back.
> We have always required the first responder to adopt either NSTextInput or
> NSTextInputClient for handling text input with complex user interaction
> required such as the deadkey sequence.
>
> > 1) subclass nsview and make it conform to the NSTextInputClient protocol
> >
> > i have been picking away at this, i added the NSTextInputClient handlers
> but
> > they aren't being called. a working example or a pointer would help if
> > anyone has done this.
> Yes, we do have a sample.  Check out
> file://localhost/Developer/Examples/AppKit/TextInputView/
>
> Aki
>
> On 2011/07/29, at 7:31, Bill Appleton wrote:
>
> > Hi all,
> >
> > I have seen this issue come up a lot, but there isn't much information on
> > how to receive unicode input in a NSView.
> >
> > (I know we are supposed to just type in a NSTextField but that is
> impossible
> > in our situation where the app must run stand-alone and as a browser
> > plugin).
> >
> > we used to call interpretKeyEvents in the keyDown handler and the
> InsertText
> > handler would get the unicode string, I guess this stopped working with a
> > system update a while back.
> >
> > Now i think there are 2 ways to do this:
> >
> > 1) subclass nsview and make it conform to the NSTextInputClient protocol
> >
> > i have been picking away at this, i added the NSTextInputClient handlers
> but
> > they aren't being called. a working example or a pointer would help if
> > anyone has done this.
> >
> > 2) use a fake NSTextField and try to use that for gathering the unicode
> as
> > it arrives.
> >
> > I have seen someone recommend NSWindow fieldEditor:forObject: to do this.
> > This sounds pretty bad and i have a lot of uncertainty as to how to make
> > this work right.
> >
> > So do you guys have a recommendation here?
> >
> > thanks in advance
> > ___
> >
> > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> >
> > Please do not post admin requests or moderator comments to the list.
> > Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> >
> > Help/Unsubscribe/Update your Subscription:
> > http://lists.apple.com/mailman/options/cocoa-dev/aki%40apple.com
> >
> > This email sent to a...@apple.com
>
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and Singletons

[Jeff Kelley]

Interesting. Your +setFoo: example, I’m assuming, sets a global int. What
about objects? I’m assuming that if I declare a global NSArray pointer like
so:

NSArray *foo = nil;

and then have a +setFoo:(NSArray *)array method, that calling it with nil
will be sufficient to clean up the array (that is, the ARC code will release
the current array)?

Jeff Kelley


On Mon, Aug 1, 2011 at 12:05 PM, Dave Zarzycki  wrote:

> The simplest and most ARC friendly way to implement the singleton pattern
> is to switch from instance methods to class methods – because the class
> itself is by definition a singleton. In other words:
>
>+ (MyClass *)sharedInstance;
>// and maybe override alloc/retain/release to enforce the singleton
> pattern
>- (int)foo;
>- (void)setFoo:(int)val;
>
> …becomes simply:
>
>+ (int)foo;
>+ (void)setFoo:(int)val;
>
> davez
>
>
> On Aug 1, 2011, at 8:48 AM, Jeff Kelley wrote:
>
> > Is there a new recommended way to implement a singleton with ARC? I
> remember
> > hearing something about it, but I’m not sure what it was.
> >
> > Jeff Kelley
>
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and Singletons

[Dave Zarzycki]

The simplest and most ARC friendly way to implement the singleton pattern is to 
switch from instance methods to class methods – because the class itself is by 
definition a singleton. In other words:

+ (MyClass *)sharedInstance;
// and maybe override alloc/retain/release to enforce the singleton 
pattern
- (int)foo;
- (void)setFoo:(int)val;

…becomes simply:

+ (int)foo;
+ (void)setFoo:(int)val;

davez


On Aug 1, 2011, at 8:48 AM, Jeff Kelley wrote:

> Is there a new recommended way to implement a singleton with ARC? I remember
> hearing something about it, but I’m not sure what it was.
> 
> Jeff Kelley
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/zarzycki%40apple.com
> 
> This email sent to zarzy...@apple.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC and Singletons

[Thomas Davie]

On 1 Aug 2011, at 16:48, Jeff Kelley wrote:

> Is there a new recommended way to implement a singleton with ARC? I remember
> hearing something about it, but I’m not sure what it was.

Was it perhaps… don't use singletons, they're just globals in disguise?

Bob___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Unnecessary Boolean Warning

[Sean McBride]

On Sun, 31 Jul 2011 15:13:45 -0500, Gordon Apple said:

>The following expression generates a warning message (3&&2 within 3||2) and
>says to include the 3anded2 expression in parens.  Anybody who understands
>basic boolean operator precedence knows this is unnecessary.  Bug report?
>
>BOOL isInUse = [super mediaIsInUse];
>isInUse = isInUse || [self videoIsOn] && ([[self capMgr] isRecording]
>  || [[self camVC]
>movieIsPlaying]
>  || [[self camVC]
>movieIsPaused]);

This warning has found several bugs (ie incorrect programmer recollection of 
precedence rules) in at least 2 open source projects I use.  I'm glad we have 
it.  Turn it off it offends you so.

--

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

ARC and Singletons

[Jeff Kelley]

Is there a new recommended way to implement a singleton with ARC? I remember
hearing something about it, but I’m not sure what it was.

Jeff Kelley
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Unnecessary Boolean Warning

[Gordon Apple]

It¹s not that I object to anyone doing it, if that makes them more
comfortable, but a warning on ³³&&² inside of ³||²² is ridiculous.  Everyone
knows that multiplication takes precedence over addition.  ³&&² is a
multiplication.  ³||² is, welll, almost an addition.  (Exor is addition in a
mod 2 system.}  Anyone who can¹t at least keep these two straight shouldn¹t
be doing programming.  Overall operator precedence is a little more
complicated and I would recommend , for those who don¹t have it all down,
copying the page (two page spread) out of K&E or Stroustroup and taping it
to the wall.  (I have done that in the past.) I just think this particular
warning is carrying things to the extreme.  What next?  Warning: ³*² inside
of ³+²?

I don¹t object to warnings.  ³Assignment inside of ³if²² is a good thing,
because it is a common, easily committed, error, and I appreciate the
warning.


On 7/31/11 8:15 PM, "Graham Cox"  wrote:

> 
> On 01/08/2011, at 6:13 AM, Gordon Apple wrote:
> 
>> Anybody who understands
>> basic boolean operator precedence knows this is unnecessary.
> 
> 
> True, but who does? I mean, sure, if everyone who ever sees your source has
> that fully committed to heart, you're golden. Otherwise, what's the harm of a
> few brackets to make it absolutely clear? It's not as if it makes any
> difference to the object code. Code for readability.
> 
> --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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Telling Auto Save, "No, I'm busy now"

[Kevin Perry]

AppKit-initiated autosaves generally happen for two main reasons: the autosave 
timer, and file coordination. These are both initiated with 
-autosaveWithImplicitCancellability:completionHandler:. The "implicitly 
cancelable" flag indicates whether it's appropriate for an NSDocument subclass 
to cancel an autosave (with an NSUserCancelled NSError, as you've discovered). 
Timer-initiated autosaves are cancelable (up to a certain limit), and you can 
detect this by calling -autosavingIsImplicitlyCancellable. Canceling an 
autosave when -autosavingIsImplicitlyCancellable returns NO will cause problems 
with file coordination.

If you absolutely cannot save when a non-cancellable autosave starts, it is OK 
to defer the autosave until you're ready, as long as you make sure to call the 
original completionHandler when you're done. There are consequences to this 
though. Not only will your application be blocked until the completionHandler 
is called, but you will cause other applications using File Coordination on 
your document's file to wait longer as well.

-KP

On Jul 30, 2011, at 6:41 PM, Jerry Krinock wrote:

> 
> On 2011 Jul 30, at 15:39, wadesli...@mac.com wrote:
> 
>> You're lying to the save machinery by saying that you have saved, when you 
>> have not.  So NSFileCoordinator will then think your file is up to date, and 
>> let others read (or write) it.  It could lead to all sorts of nasty 
>> behaviors…
> 
> Thank you, Wade.  Yes, that's a good point.
> 
>> What you should be doing is deferring the save - just hang on to 
>> 'completionHandler', queue up the save for the next available opportunity, 
>> and invoke the handler after the save really happens.
> 
> OK, but I thought of an easier solution.  Replace this line of code 
> 
>completionHandler(nil) ;
> 
> which told the system that I had saved with no error, with this:
> 
>completionHandler([NSError errorWithDomain:NSCocoaErrorDomain
>  code:NSUserCancelledError
>  userInfo:nil]) ;
> 
> Now I'm not lying to Mother any more.  And because this particular error 
> domain/code is documented to not be displayed (see -Document-Based 
> Applications Overview ▸ Error Handling in the Document Architecture), the 
> user doesn't get any crap.
> 
> Indeed, the behavior is a little different now.  Instead of waiting 10-15 
> seconds after my operations are completed, now the Auto Save happens 
> immediately after my operations are completed.  This implies that the system 
> now knows that it has unsaved data, and so it kicks in more aggressively.
> 
> I like it better now.  But it still seems that Apple should document the 
> correct way to handle this situation.
> 
>> you're in the middle of applying a user action, one that has been expressly 
>> approved and is merely taking some time
> 
> Yes, that is the situation.
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/kperry%40apple.com
> 
> This email sent to kpe...@apple.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Multithreaded Coredata save in Lion

[Jim Thomason]

> -saveDocument: has never been expected to do its work immediately. Instead, 
> you want to call:
>
> -saveDocumentWithDelegate:didSaveSelector:contextInfo:
>
> Then, when the delegate is called, spawn off your new MOC.

That's exactly what I needed. A little rewiring of the app to use the
delegate method and hand in a few new flags regarding whether any
changes were saved and I'm back in business. Guess it was just dumb
luck that it consistently behaved the other way on the older OSes.

And, incidentally, I'd say that the auto-save is justified - it's at a
point where the user should have saved all changes anyway ("Okay, my
data is stable. Now analyze it."), so it just saves it for them if
necessary instead of prompting to require it.

Thanks!

-Jim.
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Initializing Radio buttons in an NSMatrix problem

[Fritz Anderson]

On 1 Aug 2011, at 7:47 AM, John James wrote:

> Using Lion: I have a NSMatrix 1 row 3 cols. 
> at Startup I can not get the first radio button to show an indication; works 
> fine if user clicks on any one. 
> Relavent code (called from awakeFromNib):
> (framesPersec is an outlet for the NSMatrix with tags 1,2,3 respectively)
> 
> - (void) initFramespersec
> {
>if (framesPersec!=NULL) {
>[framesPersec setAllowsEmptySelection: NO];
>indexSelectedItem = 2;  <== I change this to 1 
> or 2
>if (indexSelectedItem==1)
>[self setMyFramesPerSec: 24];
>else if (indexSelectedItem==2)
>[self setMyFramesPerSec: 29.97];
>else
>[ self setMyFramesPerSec: 30];
>secPerFrame = 1./myFramesPerSec;
>[self updateInterBeatNumbers];
>NSCell* mycell = [framesPersec cellWithTag: indexSelectedItem];
>[mycell setState:NSOnState];
>}
> }

(Quick note: The way to branch against integral values is a switch statement. 
It indicates your intentions, gives you a clean way to post an error for an 
unexpected value, and future-proofs against adding or removing tags.)

I tried this on Lion (abbreviated):

@interface KillMeRadioButtonAppDelegate : NSObject 
@property(nonatomic, retain) IBOutlet NSMatrix *buttonMatrix;
- (IBAction)matrixChanged:(id)sender;
@end

@implementation KillMeRadioButtonAppDelegate
// Set only one, or neither, to 1:
#define SET_CELL_DIRECTLY   0
#define SET_THROUGH_MATRIX  0

- (void) awakeFromNib
{
NSLog(@"%s: Initial selection = %ld", 
  __PRETTY_FUNCTION__, [self.buttonMatrix selectedTag]);
#if SET_CELL_DIRECTLY
NSCell *secondCell = [self.buttonMatrix cellWithTag: 2];
[secondCell setState: NSOnState];
#elif SET_THROUGH_MATRIX
[self.buttonMatrix selectCellWithTag: 2];
#endif
}

- (IBAction) matrixChanged: (id) sender 
{
NSLog(@"%s: Selected %ld",
  __PRETTY_FUNCTION__, [self.buttonMatrix selectedTag]);
}

@end

What I'm seeing is that the matrix comes into -awakeFromNib with the first cell 
selected. ([KillMeRadioButtonAppDelegate awakeFromNib]: Initial selection = 1)

If SET_CELL_DIRECTLY is 1 (and SET_THROUGH_MATRIX is 0), both the first cell 
and the cell with tag 2 are on. 

If SET_THROUGH_MATRIX is 1 (and SET_CELL_DIRECTLY is 0), only the cell with tag 
2 is on.

So the first lesson is that accessing the cells directly doesn't do what you 
hope.

The next thing to suspect is that setMyFramesPerSec: or updateInterBeatNumbers 
is somehow setting the matrix selection. And double-check that the button tags 
are as you expect.

— 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Initializing Radio buttons in an NSMatrix problem

[John James]

Using Lion: I have a NSMatrix 1 row 3 cols. 
at Startup I can not get the first radio button to show an indication; works 
fine if user clicks on any one. 
Relavent code (called from awakeFromNib):
(framesPersec is an outlet for the NSMatrix with tags 1,2,3 respectively)

- (void) initFramespersec
{
if (framesPersec!=NULL) {
[framesPersec setAllowsEmptySelection: NO];
indexSelectedItem = 2;  <== I change this to 1 
or 2
if (indexSelectedItem==1)
[self setMyFramesPerSec: 24];
else if (indexSelectedItem==2)
[self setMyFramesPerSec: 29.97];
else
[ self setMyFramesPerSec: 30];
secPerFrame = 1./myFramesPerSec;
[self updateInterBeatNumbers];
NSCell* mycell = [framesPersec cellWithTag: indexSelectedItem];
[mycell setState:NSOnState];
}
}

If indexSelectedItem == 1

If indexSelectedItem == 2


Any feedback would be appreciated
John___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: CALayer memory management [was: Tracking down CALayer problem in iTunes plug-in]

[Dave Keck]

> I've narrowed this error down to a very simple test case.

Could you post you test case?
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSAttributedString -initWithPath RTFD crash on Lion

[jonat...@mugginsoft.com]

On OS X 10.7 the following is crashing on occasion in a GC app when the path 
contains an RTFD document:
On SL the issue does not occur.

NSAttributedString *atext = [[NSAttributedString alloc] initWithPath:Path 
documentAttributes:NULL];


The kernel log states:
01/08/2011 09:44:29.000 kernel: Data/Stack execution not permitted: 
MondayApp[pid 59614] at virtual address 0xfefff000, protections were read-write

I have tried disabling the collector without effect.
The code is used to load an RTFD file resource and often loads the resource 
without issue.
The crash is repeatable in the sense that it occurs when the code is triggered 
by particular set of bindings.
Other non RTFD file resources are loaded at the same time and load without 
issue.
The path is okay.

The following workaround seems reliable:

// get path to rtf file
NSString *filePath = [path stringByAppendingPathComponent:@"TXT.rtf"];

// get data
NSData *data = [NSData dataWithContentsOfFile:filePath options:0 
error:&docError];

// get attributed string
if (!docError) {
atext = [[NSAttributedString alloc] initWithData:data options:nil 
documentAttributes:NULL error:&docError];
}

This might work for anyone else hitting this issue.

0x95c48d61  <+>  push   %ebp
0x95c48d62  <+0001>  mov%esp,%ebp
0x95c48d64  <+0003>  push   %esi
0x95c48d65  <+0004>  sub$0x24,%esp
0x95c48d68  <+0007>  call   0x95c48d6d 
<-[NSAttributedString(NSAttributedStringKitAdditions) 
initWithPath:documentAttributes:]+12>
0x95c48d6d  <+0012>  pop%esi
0x95c48d6e  <+0013>  mov0x16b37697(%esi),%eax
0x95c48d74  <+0019>  mov0x16b26803(%esi),%ecx
0x95c48d7a  <+0025>  mov0x10(%ebp),%edx
0x95c48d7d  <+0028>  mov%edx,0x8(%esp)
0x95c48d81  <+0032>  mov%ecx,0x4(%esp)
0x95c48d85  <+0036>  mov%eax,(%esp)
0x95c48d88  <+0039>  call   0x962937e2 
0x95c48d8d  <+0044>  mov0x16b26dd3(%esi),%ecx
0x95c48d93  <+0050>  mov0x14(%ebp),%edx
0x95c48d96  <+0053>  mov%edx,0x10(%esp)
0x95c48d9a  <+0057>  mov%eax,0x8(%esp)
0x95c48d9e  <+0061>  mov%ecx,0x4(%esp)
0x95c48da2  <+0065>  mov0x8(%ebp),%eax
0x95c48da5  <+0068>  mov%eax,(%esp)
0x95c48da8  <+0071>  movl   $0x0,0x14(%esp)
0x95c48db0  <+0079>  movl   $0x0,0xc(%esp)
0x95c48db8  <+0087>  call   0x962937e2 
0x95c48dbd  <+0092>  add$0x24,%esp <<-- program received signal 
EXC_BAD_ACCESS
0x95c48dc0  <+0095>  pop%esi
0x95c48dc1  <+0096>  pop%ebp
0x95c48dc2  <+0097>  ret

Regards

Jonathan Mitchell

Developer
Mugginsoft LLP
http://www.mugginsoft.com







___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: [iOS] Block animation kills performance

[Roland King]

On Aug 1, 2011, at 8:08 AM, Rick Mann wrote:

> 
> On Jul 31, 2011, at 17:04 , Roland King wrote:
> 
>> On Aug 1, 2011, at 7:32, Rick Mann  wrote:
>> 
>>> 
>>> On Jul 31, 2011, at 16:23 , Hunter Hillegas wrote:
>>> 
 Are you sure you don't need UIViewAnimationOptionAllowUserInteraction and 
 animateWithDuration:delay:options:animations:completion:?
>>> 
>>> No, I'm not sure :-) I've never worried about that option before, and don't 
>>> know why it would be different from one approach to the other.
>>> 
>>> Why do I need it for the block approach and not for the other?
>>> 
>>> The docs for UIViewAnimationOptionAllowUserInteraction suggest it's only 
>>> necessary for views that are animating that require user interaction; that 
>>> is not the case for me. The animating view does not have any user 
>>> interaction. It's all the other views in my app that fail to respond.
>>> 
>>> -- 
>>> Rick
>>> 
 
>> 
>> You need it. 
> 
> Why do I need it? That doesn't seem to be what the docs say.

The docs aren't wonderful on that point I'd agree, you can read 'views' in the 
description of the flag a variety of different ways and I would suggest 
requesting a doc change clarifying it. However since that method was introduced 
as far as I know it's always worked that way and has disabled all user 
interaction on all views in your application during an animation. So if you 
want any user interaction when using that method, you need the flag. 

> 
> Is it a bug? Why would iOS have a default mode that stops all user 
> interaction if anything is animating?

I don't think it's a bug, it's a choice. Having user interaction disabled when 
view animations are going on is something I could certainly see as a useful 
option. Whether it makes sense to have had this as the default option or not is 
definitely open to debate, and there have been comments suggesting apple might 
change it, but it would probably be rather hard to do that now so we may well 
be stuck with it as it is. 

> 

> And why does it work fine with the older way of doing it?

The older way of doing it didn't have an option for disabling all view 
interaction so that had to work that way. I don't see anywhere in the 
documentation which says the new call with default arguments is a drop-in 
replacement for the old method and Apple chose the default behavior they wanted 
for the new API point. Again it's debatable what the smartest default would 
have been, I would have thought that doing the thing closest to what the old 
method did would be .. but Apple clearly didn't. 

You could certainly file it as a bug, be interesting if it came back as 'works 
as designed' or 'dupe', but I don't quite know how Apple could change this 
default behavior without breaking a lot of code. 

> -- 
> 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Custom autocompletion with NSTextField

[Joe White]

Hi Kyle, thanks for the reply.

On 1 August 2011 01:12, Kyle Sluder  wrote:

> On Sun, Jul 31, 2011 at 4:29 PM, Joe White  wrote:
> > Hi all,
> >
> > I'm currently implementing custom autocomplete functionality into a
> > NSTextField. I've managed so far to generate a list of my own available
> > words and these show when escape is pressed.
> >
> > However, I'd like the autocompletion to automatically show as the user
> > types.
>
>
> Have you thought about how this will interact with the default
> autocorrect-options-as-you-type on Lion?
>
> Actually, I haven't even looked at Lion yet. I don't want to update halfway
through a project (not code based). Can you explain more or is there a link
I can read? Sounds like this could be trouble.

>
> >
> > I'm using the delegate methods of a NSTextView to override -
> > (NSArray*)textView:(
> > NSTextView *)textView completions:(NSArray *)words
> >  forPartialWordRange:(NSRange)charRange
> indexOfSelectedItem:(NSInteger*)index
> >
> > And setting the delegate in - (void)controlTextDidBeginEditing:(
> > NSNotification *)obj {
> >
> >  fieldEditor = [[obj userInfo] objectForKey:@"NSFieldEditor"];
> >
> >  [fieldEditor setDelegate:self]; }
>
> Do not change the delegate of a field editor. It needs to be the
> control that's being edited. This is the mechanism whereby
> -controlTextDidChange: gets called.
>
> You have two options:
>
> 1. Subclass NSTextField, override the appropriate text view delegate
> methods (like -textDidChange: or
> -textView:shouldChangeTextInRange:replacementString:), and call
> super's implementation.
>
> 2. Add your object as an observer of the relevant NSNotifications on
> the field editor. You might still need to subclass NSTextField so you
> can perform your setup in -setUpFieldEditorAttributes:, but most
> likely you could get away with doing this in your window delegate's
> -window:willReturnFieldEditor:toObject:. Still, this approach is
> slightly less powerful, but if you don't need all the power of being
> the field editor's delegate it could result in a cleaner
> implementation.
>
> After some more exploring I found that I could receive the NSTextView
delegate methods with -textDidChange instead of -controlTextDidChange. This
seems to work but I get the impression this is not the correct approach.

I'd prefer option 2 if it is the cleaner way, as long as I still have
control over the text input. I'm aiming at a similar approach to Xcode,
where it displays the available methods and shows the parameters needed.

p.s. I was just talking to a colleague and he said he turned Lion's default
autocomplete off straight away as it was annoying :S

Thanks,
Joe

>  --Kyle Sluder
>



-- 
Joe White
Production Department, RjDj

Tel : +44 7515 731499

Reality Jockey Ltd.
Floor B “The Mission”
55 Holywell Lane
London
EC2A 3PQ
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

CALayer memory management [was: Tracking down CALayer problem in iTunes plug-in]

[Graham Cox]

I've narrowed this error down to a very simple test case.

I have a CALayer subclass. In this subclass, I've added properties which are 
synthesized and retained (in fact, they are NSColors). I don't attempt to 
animate these properties.

In my -dealloc method, I'm setting these properties to nil, in accordance with 
normal procedure for a synthesized property, so that whatever I'm retaining 
gets released. When I do this, I always get this error logged to the console:

1/08/11 3:30:48 PM  iTunes[38653]   attempting to modify layer that is 
being finalized - 0x1a2a87f0

It's only logged once, but from then on the whole Core Animation system shuts 
down - I can no longer get any visual display from any layer. I'm guessing that 
this is a 'feature', in that an attempt to modify a layer is for some reason a 
highly dangerous operation during finalization (I'm writing this code as if it 
used retain/release, but it might be using GC, as it's a plug-in hosted by the 
(new, Cocoa) version of iTunes - I don't know whether it uses GC or not). If I 
neglect to clean up these properties, I don't get the error, the CA system 
continues to work, but of course I'm then leaking my colour objects.

What's the proper way to correctly clean up a CALayer subclass and make sure 
I'm not leaking retained properties NOR modifying the layer at finalize time?

--Graham



On 28/07/2011, at 1:07 PM, Graham Cox wrote:

> When I clean-up my visualizer view, I see this in the console: 
> 
> 28/07/11 12:43:40 AM  iTunes[22132]   attempting to modify layer that is 
> being finalized - 0x1ec78650

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com