Re: Uncaught Exception: NSUnknownKeyException

[Mike Abdullah]

Got a stack trace?

Sent from my iPad

On 9 Mar 2012, at 06:57 AM, Donald Hall  wrote:

> Does anyone have any idea what might be wrong if I am getting this exception:
> 
> Uncaught Exception:
> NSUnknownKeyException
> [ valueForUndefinedKey:]: this class is not key value 
> coding-compliant for the key (null).
> 
> Action is one of my classes. I am upgrading an old project for Lion. The 
> present version of the program works fine, and I haven't changed the Action 
> class at all.
> 
> Thanks for any pointers,
> 
> Don
> 
> 
> Don Hall
> Apps & More Software Design, Inc.
> d...@appsandmore.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/cocoadev%40mikeabdullah.net
> 
> This email sent to cocoa...@mikeabdullah.net

___

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

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

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

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

Uncaught Exception: NSUnknownKeyException

[Donald Hall]

Does anyone have any idea what might be wrong if I am getting this exception:

Uncaught Exception:
 NSUnknownKeyException
[ valueForUndefinedKey:]: this class is not key value 
coding-compliant for the key (null).

Action is one of my classes. I am upgrading an old project for Lion. The 
present version of the program works fine, and I haven't changed the Action 
class at all.

Thanks for any pointers,

Don


Don Hall
Apps & More Software Design, Inc.   
d...@appsandmore.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: NSTableView update basics

[Conrad Shultz]

This doesn't make sense - it will either return 1 or 0. Hence only 1 row 
appears. 

Just return [tableData count]. 

(Sent from my iPhone.)

--
Conrad Shultz

On Mar 8, 2012, at 21:42, Erik Stainsby  wrote:

> - (NSInteger) numberOfRowsInTableView:(NSTableView *)tableView {
>return [tableData count] || 0;
> }

___

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

NSTableView update basics

[Erik Stainsby]

I have a tableView which will accept one new row and updates to that row 
succeed. Subsequent application of the same process does add new rowData 
dictionary objects to the tableData model (NSMutableArray) but the tableView 
will not display these additions.

A button on the UI is wired up to - (IBAction) addTableItem:(id)sender; and 
pops in the first row just fine. NSLog() messages have revealed that additional 
clicks on the button add new rows to the tableData array, but the UI does not 
respond to these events.

I'm pretty sure I'm missing something pretty basic here.


@interface MyClass : NSViewController < NSTableViewDataSource, 
NSTableViewDelegate >

@property (retain) IBOutlet NSTableView * tableView;
@property (retain) IBOutlet NSMutableArray * tableData;

- (IBAction) addTableItem:(id)sender;

@end

@implementation MyClass

@synthesize tableView;
@synthesize tableData;

- (id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil
{
self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];
if (self) {
tableData = [NSMutableArray array];
}
return self;
} 


- (NSInteger) numberOfRowsInTableView:(NSTableView *)tableView {
return [tableData count] || 0;
}

- (id) tableView:(NSTableView *)tableView 
objectValueForTableColumn:(NSTableColumn *)tableColumn row:(NSInteger)row {
NSDictionary * rowData = [tableData objectAtIndex:row];
return [rowData valueForKey:[tableColumn identifier]];
}

- (void)tableView:(NSTableView *)aTableView setObjectValue:(id)anObject 
forTableColumn:(NSTableColumn *)aTableColumn row:(NSInteger)rowIndex {

NSMutableDictionary * rowData = [[tableData objectAtIndex:rowIndex] 
mutableCopy];
[rowData setValue:anObject forKey:[aTableColumn identifier]];
[tableData replaceObjectAtIndex:rowIndex withObject:rowData];
[tableView reloadData];
}

- (IBAction) addTableItem:(id)sender {
[tableData addObject:[NSDictionary 
dictionaryWithObjectsAndKeys:@"prop",@"property",@"val",@"value",nil]];
[tableView reloadData];
}

@end




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: @-directives

[Matt Neuburg]

On Thu, 08 Mar 2012 23:14:02 +, Thomas Davie  said:
>Not that I know of off the top of my head, but here's my attempt at such a 
>list:
>
>@class
>@interface
>@implementation
>@end
>@private
>@public
>@protected
>@protocol
>@required
>@optional
>@property
>@synthesize
>@try
>@catch
>@finally
>@autoreleasepool
>@synchronized

And let's not forget humble @"".

m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
___

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 are 2 Terminal windows opening with NSAppleScript?

[Matt Neuburg]

On Thu, 08 Mar 2012 14:32:07 +1100, Prime Coderama  
said:
>If no Terminal app is open, the following code opens TWO Terminal windows. Why 
>is it doing this? I only want one window to open.
>
>If only one Terminal window is open, then the following code opens only ONE 
>additional window.
>
>NSAppleScript* terminal = [[NSAppleScript alloc] initWithSource:
>   [NSString stringWithFormat:
>@"tell application \"Terminal\"\n"
>@"activate\n"
>@"do script \"echo %@\"\n"
>@"tell the front window\n"
>@"set title displays shell path to false\n"
>@"set title displays custom title to 
> true\n"
>@"set custom title to \"My session! %@\"\n"
>@"end tell\n"
>@"end tell", name, name]];
>
>[terminal executeAndReturnError:nil];

It actually might help you to read my AppleScript book! See p. 278 on the 
meaning of launch and on what applications do when they are launched implicitly 
by a tell block.

m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
___

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: UIKit-additions and class references

[Matt Neuburg]

On Wed, 07 Mar 2012 11:40:41 -0800, David Duncan  said:
>On Mar 6, 2012, at 1:28 PM, Mikkel Islay wrote:
>
>> Does anyone know the reason why the UIKit-additions for NSString, NSValue 
>> etc. aren't mentioned in the respective class references in the Apple 
>> documentation for iOS?
>
>Category additions are documented separately from the main class. For example, 
>UIKit's NSString additions are in NSString(UIStringDrawing) (which you can 
>search for in the documetnation).

You can search if you know about it. The fact is that this organization is bad 
for the user (the programmer). There are two related problems:

* Some categories (but not all - that's another problem, the inconsistency) are 
documented separately from the class on which they are a category.

* There is no reference from the class page to the category page.

Taken together, this makes the methods defined by the category pretty much 
impossible to discover. I'm sure *you* know about them, but the purpose of the 
documentation is to help the person who does *not* know, and in this regard it 
falls down completely. Here are some excerpts from my book, alerting the reader 
to this issue:

=

This organization won't matter to you as a programmer, because an NSString is 
an NSString, no matter how it acquires its methods, but it can matter when you 
consult the documentation. The NSString methods declared in _NSString.h_, 
_NSPathUtilities.h_, and _NSURL.h_ are documented in the NSString class 
documentation page, but the NSString methods declared in _UIStringDrawing.h_ 
are not, presumably because they originate in a different framework. Instead, 
they appear in a separate document, _NSString UIKit Additions Reference_. As a 
result, the string drawing methods can be difficult to discover, especially as 
the NSString class documentation doesn't link to the other document. I regard 
this as a major flaw in the structure of the Cocoa documentation. A third-party 
utility such as AppKiDo can be helpful here.

=

Of the methods injected into NSObject by categories, many are delegate methods 
used in restricted situations (so that these are really informal protocols), 
and do not need centralized documentation; for example, +animationDidStart:+ is 
documented under the CAAnimation class, quite rightly, because you need to know 
about it only and exactly when you're working with CAAnimation. Others that are 
general in nature are documented on the NSObject class documentation page 
itself; for example, +cancelPreviousPerformRequestsWithTarget:+ comes from a 
category declared in _NSRunLoop.h_, but it is documented under NSObject, quite 
rightly, since this is a class method, and therefore effectively a global 
method, that you might want to send at any time. However, every object responds 
to +awakeFromNib+, and it's likely to be crucial to every app you write; yet 
you must learn about it outside of the NSObject documentation, sitting all by 
itself on the _NSObject UIKit Additions Reference_, where you're extremely 
unlikely to discover it!

m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
___

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: Versions browser, file access, revertToSaved

[Jerry Krinock]

On 2012 Mar 07, at 23:48, Martin Hewitson wrote:

> I have an app which works with autosave and Versions browser.

Oh, so you've implemented +[NSDocument autosavesInPlace]  ;)

> I have a file-monitor in the app which reloads the document if it changes on 
> disk.

Great feature.  I've done that too.

> For the reloading I was simply calling -revertDocumentToSaved: …

If your document is Core Data, forget it.  You'll need to close and re-open.  
Ugly, but at least it doesn't display any errors and you'll be able to ship 
sometime this year.

> "The document “foo.txt” could not be saved. The file has been changed by 
> another application."


I've successfully beaten that monster a couple times with the following method. 
 It looks silly, but it works.  Try sprinkling one in during your reload 
somewhere…
 
@implementation NSDocument (SyncModDate)

- (void)syncFileModificationDate {
NSFileManger* fm = [NSFileManager defaultManager] ;
NSDictionary* fileAttributes = [fm attributesOfItemAtPath:[[self fileURL] 
path]
error:NULL] ;
NSDate* newDate = [fileAttributes objectForKey:NSFileModificationDate] ;
[self setFileModificationDate:newDate] ;
}

@end

I think I got the idea from here:

http://stackoverflow.com/questions/380076/manual-core-data-schema-migration-without-document-changed-warning


___

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: @-directives

[Roland King]

Good thinking .. 

OBJC1_AT_KEYWORD(not_keyword)
OBJC1_AT_KEYWORD(class)
OBJC1_AT_KEYWORD(compatibility_alias)
OBJC1_AT_KEYWORD(defs)
OBJC1_AT_KEYWORD(encode)
OBJC1_AT_KEYWORD(end)
OBJC1_AT_KEYWORD(implementation)
OBJC1_AT_KEYWORD(interface)
OBJC1_AT_KEYWORD(private)
OBJC1_AT_KEYWORD(protected)
OBJC1_AT_KEYWORD(protocol)
OBJC1_AT_KEYWORD(public)
OBJC1_AT_KEYWORD(selector)
OBJC1_AT_KEYWORD(throw)
OBJC1_AT_KEYWORD(try)
OBJC1_AT_KEYWORD(catch)
OBJC1_AT_KEYWORD(finally)
OBJC1_AT_KEYWORD(synchronized)
OBJC1_AT_KEYWORD(autoreleasepool)

OBJC2_AT_KEYWORD(property)
OBJC2_AT_KEYWORD(package)
OBJC2_AT_KEYWORD(required)
OBJC2_AT_KEYWORD(optional)
OBJC2_AT_KEYWORD(synthesize)
OBJC2_AT_KEYWORD(dynamic)
OBJC2_AT_KEYWORD(__experimental_modules_import)

So I missed compatibilty_alias, defs, encode, selector (!), try, finally and 
dynamic. Plus possibly not_keyword and __experimental_modules_import, whatever 
the heck they are. 

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

> On Mar 8, 2012, at 3:04 PM, Roland King  wrote:
>> Can't find one (why is there not a formal language document in the 
>> documentation somewhere, perhaps because features are added every release) - 
>> maybe we can build one here
>> 
>> @property
>> @synthesize
>> @class
>> @interface
>> @implementation
>> @protocol
>> @end
>> @autoreleasepool
>> @throw
>> @catch
>> @private
>> @public
>> @protected
>> @package
>> @optional
>> @required
>> 
>> that's all the ones I can think of, probably missed 1/2 of them. 
> 
> @compatibility_alias. Don't ask.
> 
> Your best bet is to dig through the compiler's code. They're probably all in 
> one place somewhere.
> 
> 
> -- 
> 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: Problem with refreshing NSMenuItems

[Jerry Krinock]

On Mar 7, 2012, at 2:40 AM, Prime Coderama wrote:

> I then dynamically add n-amount of NSMenuItems between (2) and (3). This 
> works great.
> 
> The problem I am having, is when I hit "Refresh"

I haven't studied your case in detail, but the usual mechanism for implementing 
dynamic menus is the delegate method -menuNeedsUpdate:.  Cocoa invokes it for 
you whenever the menu is about to be displayed.  You don't need a "Refresh" 
button.


___

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: @-directives

[Greg Parker]

On Mar 8, 2012, at 3:04 PM, Roland King  wrote:
> Can't find one (why is there not a formal language document in the 
> documentation somewhere, perhaps because features are added every release) - 
> maybe we can build one here
> 
> @property
> @synthesize
> @class
> @interface
> @implementation
> @protocol
> @end
> @autoreleasepool
> @throw
> @catch
> @private
> @public
> @protected
> @package
> @optional
> @required
> 
> that's all the ones I can think of, probably missed 1/2 of them. 

@compatibility_alias. Don't ask.

Your best bet is to dig through the compiler's code. They're probably all in 
one place somewhere.


-- 
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: String Constants the solution

[Eeyore]

On Mar 8, 2012, at 4:29 PM, Prime Coderama wrote:

> I have references to 'ground' and 'air' in multiple files. It is usually used 
> in this context, but not always.
>>  if ([transport.type isEqualToString:@"ground"]) {
>>// do something for automobiles
>>  }
>>  else if ([transport.type isEqualToString:@"air"]) {
>>// do something else for planes
>>  }
>>  else {
>>// we don't care
>>  }
> 
> Should I be using string constants to represent 'ground' and 'air' so if I 
> ever change their literal, I just update it in one place? e.g.
>>  NSString * const TransportGround = @"ground";
>>  NSString * const TransportAir = @"air";
> 
> I then decide I want to rename 'ground' to be 'wheels', then I would only 
> update the above string constant.

I would say yes, partially so you only have one place to update it and 
partially so you don't end up with typos, e.g., if ([transport.type 
isEqualToString:@"gound"]).

Depending on your situation, subclassing could use the objects class to 
indicate its type and reduce the number of if-elseif blocks.

Or you might try a typedef-ed enum instead of strings so you could use plain == 
for comparison. The typedef would also allow you to use switch statements so 
that if you add a new transportation mode (e.g., water), you can get the 
compiler to warn you if you aren't handling it (assuming you set the 
appropriate flags and don't use a "default" case). However, you need to be 
careful since Objective C typedefs aren't as carefully checked as C++ typedefs 
(at least I don't think they are).

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: @-directives

[Charles Srstka]

On Mar 8, 2012, at 5:14 PM, Thomas Davie wrote:

> Not that I know of off the top of my head, but here's my attempt at such a 
> list:
> 
> @class
> @interface
> @implementation
> @end
> @private
> @public
> @protected
> @protocol
> @required
> @optional
> @property
> @synthesize
> @try
> @catch
> @finally
> @autoreleasepool
> @synchronized
> 
> Have I missed your favourite out?

Don’t forget:

@“foo” to create strings

And if you’re using the latest SVN of Clang:

@( foo, bar ) to create arrays
@{ foo : bar } to create dictionaries
@12345(l)|(ul)|(ll), @123.45(f), @(YES)|(NO), @‘a' to create NSNumbers

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

String Constants the solution

[Prime Coderama]

I have references to 'ground' and 'air' in multiple files. It is usually used 
in this context, but not always.
>   if ([transport.type isEqualToString:@"ground"]) {
> // do something for automobiles
>   }
>   else if ([transport.type isEqualToString:@"air"]) {
> // do something else for planes
>   }
>   else {
> // we don't care
>   }

Should I be using string constants to represent 'ground' and 'air' so if I ever 
change their literal, I just update it in one place? e.g.
>   NSString * const TransportGround = @"ground";
>   NSString * const TransportAir = @"air";

I then decide I want to rename 'ground' to be 'wheels', then I would only 
update the above string constant.
___

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: Accessing array in thread safe way

[Kyle Sluder]

On Mar 8, 2012, at 2:15 PM, Quincey Morris wrote:

> On Mar 8, 2012, at 12:18 , CoGe - Tamas Nagy wrote:
> 
>> I should subclass NSMutableArray because I had a project which used 
>> NSMutableArray (calls) before, but was not thread safe. Anyway, I can't 
>> really understand why it would be _really_ better to implement just 
>> accessors, but maybe you could explain it a bit more?
> 
> Well, slap my head if I'm missing your intention, but I don't see how having 
> an *atomically* safe NSMutableArray helps at all. As soon as anyone in any 
> thread writes:
> 
>   for (NSInteger i = 0; i <= atomicallySafeArray.count; i++) {
>   id object = [atomicallySafeArray objectAtIndex: i];
>   ...
>   }
> 
> or any such construct that contains 2+ references to the array that might see 
> a different state of the array over time, then the code is broken and not 
> thread safe. This is also broken:
> 
>   for (id object in atomicallySafeArray)
>   …
> 
> for the separate but related reason that fast enumeration will fail if the 
> array mutates.
> 
> Also, implementing the accessors won't solve either of these problems.
> 
> Thread safety does *not* come from atomicity. Conversely, in many cases 
> atomicity has no value whatsoever -- because thread safety is what's really 
> required.

And this is why atomic-by-default is a misfeature. Slower code that contributes 
to a false impression of thread-safety.

--Kyle Sluder
___

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

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

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

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

Re: Accessing array in thread safe way

[Charles Srstka]

On Mar 8, 2012, at 4:57 PM, Quincey Morris wrote:

> It wouldn't solve, e.g., the possibly inconsistency between 'array.count' and 
> a subsequent reference, unless it was coded to keep a "consistent" local 
> reference to the copy of the array, in which case you'd want the copy to be 
> explicit in the API so that a reader of the code would be aware, and that 
> would be a non-atomic-level approach anyway.

If the array that the client is using is an immutable array that was created by 
copying the object’s internal NSMutableArray, then array.count is not going to 
change.

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: @-directives

[Thomas Davie]

Not that I know of off the top of my head, but here's my attempt at such a list:

@class
@interface
@implementation
@end
@private
@public
@protected
@protocol
@required
@optional
@property
@synthesize
@try
@catch
@finally
@autoreleasepool
@synchronized

Have I missed your favourite out?

Bob
if (*ra4 != 0xffc78948) { return false; }

On 8 Mar 2012, at 21:12, H. Miersch wrote:

> hi.
> is there a list of @-directives (like @class, @property and @synthesize) 
> somewhere out there? 
> ___
> 
> 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/tom.davie%40gmail.com
> 
> This email sent to tom.da...@gmail.com

___

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

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

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

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

Re: @-directives

[Jeffrey Walton]

On Thu, Mar 8, 2012 at 4:12 PM, H. Miersch  wrote:
> hi.
> is there a list of @-directives (like @class, @property and @synthesize) 
> somewhere out there?
Apple's official document (they seem to be spread around the document)
* 
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ObjectiveC/ObjC.pdf

Here's a few from others when searching for "Objective C keyword":
* www.roseindia.net/iphone/objectivec/objective.shtml
* http://chachatelier.fr/programmation/fichiers/cpp-objc-en.pdf

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: @-directives

[Roland King]

Can't find one (why is there not a formal language document in the 
documentation somewhere, perhaps because features are added every release) - 
maybe we can build one here

@property
@synthesize
@class
@interface
@implementation
@protocol
@end
@autoreleasepool
@throw
@catch
@private
@public
@protected
@package
@optional
@required

that's all the ones I can think of, probably missed 1/2 of them. 



On Mar 9, 2012, at 5:12 AM, H. Miersch wrote:

> hi.
> is there a list of @-directives (like @class, @property and @synthesize) 
> somewhere out there? 
> ___
> 
> 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/rols%40rols.org
> 
> This email sent to r...@rols.org


___

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: Accessing array in thread safe way

[Quincey Morris]

On Mar 8, 2012, at 14:29 , Charles Srstka wrote:

> For those two examples, it seems like having the default accessor return an 
> immutable array via copy would solve the issue.

It wouldn't solve, e.g., the possibly inconsistency between 'array.count' and a 
subsequent reference, unless it was coded to keep a "consistent" local 
reference to the copy of the array, in which case you'd want the copy to be 
explicit in the API so that a reader of the code would be aware, and that would 
be a non-atomic-level approach anyway.

I also wanted to point out that there's another defect in Tamas's code: it 
needs an explicit atomic 'copy' implementation, and therefore an explicit 
atomic 'mutableCopy' implementation. And who knows what else …

I'm begging ya to forgeddaboudit. The atomicity solution is a fantasy**. You 
can't solve thread safety at that level.



** However, we don't know the scenario Tamas wrote the code for. It's possible 
atomicity solved whatever issue he was facing, that wasn't general thread 
safety. It's also possible he didn't solve anything, but just changed a 
likely-to-cause-a-crash bug into a 
impossible-to-crash-but-likely-to-cause-a-rare-and-subtle-but-almost-impossible-to-debug-error
 bug.

___

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: Accessing array in thread safe way

[Charles Srstka]

On Mar 8, 2012, at 3:29 PM, Brian Lambert wrote:

> Cool! Thanks for that.
> 
> My tests were run on an 27" iMac 3.4 GHz Intel Core i7. Code was compiled 
> with -O3 (Fastest).
> 
> The PerfTimer I used is my own.  I blogged about it here: 
> http://www.objective-brian.com/334 
> Feedback is welcome.
> 
> Brian

What I’d really to know is exactly what locking mechanism @synthesize uses when 
synthesizing atomic properties. In my testing, @synthesized properties 
completely blow away everything else in terms of performance, taking less than 
1/6 of the time of even OSSpinLock.

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: Accessing array in thread safe way

[Charles Srstka]

On Mar 8, 2012, at 4:15 PM, Quincey Morris wrote:

> Well, slap my head if I'm missing your intention, but I don't see how having 
> an *atomically* safe NSMutableArray helps at all. As soon as anyone in any 
> thread writes:
> 
>   for (NSInteger i = 0; i <= atomicallySafeArray.count; i++) {
>   id object = [atomicallySafeArray objectAtIndex: i];
>   ...
>   }
> 
> or any such construct that contains 2+ references to the array that might see 
> a different state of the array over time, then the code is broken and not 
> thread safe. This is also broken:
> 
>   for (id object in atomicallySafeArray)
>   …
> 
> for the separate but related reason that fast enumeration will fail if the 
> array mutates.
> 
> Also, implementing the accessors won't solve either of these problems.
> 
> Thread safety does *not* come from atomicity. Conversely, in many cases 
> atomicity has no value whatsoever -- because thread safety is what's really 
> required.

For those two examples, it seems like having the default accessor return an 
immutable array via copy would solve the issue.

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: Accessing array in thread safe way

[Quincey Morris]

On Mar 8, 2012, at 12:18 , CoGe - Tamas Nagy wrote:

> I should subclass NSMutableArray because I had a project which used 
> NSMutableArray (calls) before, but was not thread safe. Anyway, I can't 
> really understand why it would be _really_ better to implement just 
> accessors, but maybe you could explain it a bit more?

Well, slap my head if I'm missing your intention, but I don't see how having an 
*atomically* safe NSMutableArray helps at all. As soon as anyone in any thread 
writes:

for (NSInteger i = 0; i <= atomicallySafeArray.count; i++) {
id object = [atomicallySafeArray objectAtIndex: i];
...
}

or any such construct that contains 2+ references to the array that might see a 
different state of the array over time, then the code is broken and not thread 
safe. This is also broken:

for (id object in atomicallySafeArray)
…

for the separate but related reason that fast enumeration will fail if the 
array mutates.

Also, implementing the accessors won't solve either of these problems.

Thread safety does *not* come from atomicity. Conversely, in many cases 
atomicity has no value whatsoever -- because thread safety is what's really 
required.


___

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: ivar access during -finalize

[Quincey Morris]

On Mar 8, 2012, at 09:09 , Nick Zitzmann wrote:

> +defaultManager is not thread-safe IIRC.

It's currently listed as thread-safe:


https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html

I believe there was historically some confusion because the safety 
characteristics changed in 10.5, and the documentation didn't properly reflect 
the post-10.5 behavior. There were 2 separate safety issues:

1. Is NSFileManager atomically safe? That is, can you safely use a single 
instance from multiple threads without confusing the instance.

2. Is NSFileManager thread safe? Can you safely use multiple instances from 
multiple threads without (say) running into a file system deadlock.

If #2 wasn't true, you'd have to use instances other than [NSFileManager 
defaultManger] with extreme care. If #1 wasn't true, you'd have use a different 
instance in each thread, or implement your own atomic lock.

I believe #1 wasn't true pre-10.5, but it was hard to know for sure because 
most information on the subject didn't properly distinguish between atomicity 
and thread safety.


___

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: Accessing array in thread safe way

[Brian Lambert]

Cool! Thanks for that.

My tests were run on an 27" iMac 3.4 GHz Intel Core i7. Code was compiled
with -O3 (Fastest).

The PerfTimer I used is my own.  I blogged about it here:
http://www.objective-brian.com/334
Feedback is welcome.

Brian


On Thu, Mar 8, 2012 at 1:20 PM, Charles Srstka wrote:

> On Mar 8, 2012, at 2:51 PM, Brian Lambert wrote:
>
> > I should have said, "relatively".  As in, good enough for many scenarios
> where it will be used infrequently and keeping the code simple makes sense.
> >
> > Of course, you're right, Charles.
> >
> > 1,000,000 integer increments synchronized by @synchronized, OSSpinLock,
> and NSLock:
> > PerfTimer[95716:403] 1,000,000 @synchronized ++value: [118 ms]
> [117,813,038 ns]
> > PerfTimer[95716:403] 1,000,000 OSSpinLock ++value: [8 ms] [8,444,567 ns]
> > PerfTimer[95716:403] 1,000,000 NSLock ++value: [63 ms] [63,049,168 ns]
> >
> > A million operations in ~100 ms is fast. A million operations in ~10 ms
> is WICKED fast.
> >
> > Brian
>
> Another interesting option is mentioned in Apple’s GCD man pages;
> dispatch_sync can actually be used as a locking mechanism, like so:
>
> __block NSUInteger value = 0;
>
> dispatch_sync(myLockQueue, ^{
>value++;
> });
>
> This results in something almost as simple as @synchronized, and quite a
> lot faster. Here are the results I get when running it on my MBP. All my
> results do take about twice as long as yours; I suspect you have a rather
> nice machine. :-)
>
> 2012-03-08 15:14:56.408 Lock Benchmarks[57369:403] @synchronized value++:
> 259.156942 ms
> 2012-03-08 15:14:56.429 Lock Benchmarks[57369:403] OSSpinLock value++:
> 19.486010 ms
> 2012-03-08 15:14:56.517 Lock Benchmarks[57369:403] pthread_mutex_t
> value++: 86.329997 ms
> 2012-03-08 15:14:56.645 Lock Benchmarks[57369:403] NSLock value++:
> 127.897978 ms
> 2012-03-08 15:14:56.692 Lock Benchmarks[57369:403] dispatch_sync value++:
> 45.979023 ms
>
> Not bad; OSSpinLock is the only thing that seems to be able to best 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: Accessing array in thread safe way

[Charles Srstka]

On Mar 8, 2012, at 2:51 PM, Brian Lambert wrote:

> I should have said, "relatively".  As in, good enough for many scenarios 
> where it will be used infrequently and keeping the code simple makes sense.
> 
> Of course, you're right, Charles.
> 
> 1,000,000 integer increments synchronized by @synchronized, OSSpinLock, and 
> NSLock:
> PerfTimer[95716:403] 1,000,000 @synchronized ++value: [118 ms] [117,813,038 
> ns]
> PerfTimer[95716:403] 1,000,000 OSSpinLock ++value: [8 ms] [8,444,567 ns]
> PerfTimer[95716:403] 1,000,000 NSLock ++value: [63 ms] [63,049,168 ns]
> 
> A million operations in ~100 ms is fast. A million operations in ~10 ms is 
> WICKED fast. 
> 
> Brian

Another interesting option is mentioned in Apple’s GCD man pages; dispatch_sync 
can actually be used as a locking mechanism, like so:

__block NSUInteger value = 0;

dispatch_sync(myLockQueue, ^{
value++;
});

This results in something almost as simple as @synchronized, and quite a lot 
faster. Here are the results I get when running it on my MBP. All my results do 
take about twice as long as yours; I suspect you have a rather nice machine. :-)

2012-03-08 15:14:56.408 Lock Benchmarks[57369:403] @synchronized value++: 
259.156942 ms
2012-03-08 15:14:56.429 Lock Benchmarks[57369:403] OSSpinLock value++: 
19.486010 ms
2012-03-08 15:14:56.517 Lock Benchmarks[57369:403] pthread_mutex_t value++: 
86.329997 ms
2012-03-08 15:14:56.645 Lock Benchmarks[57369:403] NSLock value++: 127.897978 ms
2012-03-08 15:14:56.692 Lock Benchmarks[57369:403] dispatch_sync value++: 
45.979023 ms

Not bad; OSSpinLock is the only thing that seems to be able to best 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

@-directives

[H. Miersch]

hi.
is there a list of @-directives (like @class, @property and @synthesize) 
somewhere out there? 
___

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: NSOpenPanel may not respond to setDirectoryURL?

[Howard Moon]

Correct on all counts. Especially the "cruel" part. :-)

(I actually had already realized the real reason calling release was wrong, but 
hadn't removed that line of code yet.)

Thanks,
Howard

On Mar 8, 2012, at 12:47 PM, Mike Abdullah wrote:

> Time for me to be cruel and pick apart your code.
> 
> On 8 Mar 2012, at 18:10, Howard Moon wrote:
> 
>> Hmmm... I'm building a VST3/vstgui4 plug-in, and I think the base SDK and 
>> deployment targets are set as required, like this:
>> 
>> SDKROOT = macosx10.5
>> SDKROOT[arch=x86_64] = $(DEVELOPER_SDK_DIR)/MacOSX10.6.sdk
>> 
>> When I build either a 32-bit or 64-bit build, while running on 10.6, it 
>> executes -setDirectoryURL with no problems.  I haven't tried running in 10.5 
>> yet.
>> 
>> Can I keep my above settings, but do this?
>> 
>>  if ([openPanel respondsToSelector:@selector(setDirectory)])
> 
> -setDirectory: is available on all OS releases. Just because it has been 
> deprecated does not stop it existing! You want to test the -setDirectoryURL: 
> selector instead.
> 
>>  [openPanel setDirectory:nsParentPath];
>>  else
>>  {
>>  NSURL*  nsParentURL = [NSURL 
>> fileURLWithPath:nsParentPath isDirectory:YES];
>>  [openPanel setDirectoryURL:nsParentURL];
>>  //[nsParentURL release]; // No...crashes! must be used by panel
> 
> That you have this code/comment shows you clearly don't understand Cocoa 
> memory management yet. Please, please, please re-read the docs and take the 
> time to understand it. That line of code crashing has NOTHING to do with the 
> open panel.
>>  }
> 
> 
> 


___

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: Accessing array in thread safe way

[Brian Lambert]

I should have said, "relatively".  As in, good enough for many scenarios
where it will be used infrequently and keeping the code simple makes sense.

Of course, you're right, Charles.

1,000,000 integer increments synchronized by @synchronized, OSSpinLock, and
NSLock:

PerfTimer[95716:403] 1,000,000 @synchronized ++value: [118 ms] [117,813,038
ns]
PerfTimer[95716:403] 1,000,000 OSSpinLock ++value: [8 ms] [8,444,567 ns]
PerfTimer[95716:403] 1,000,000 NSLock ++value: [63 ms] [63,049,168 ns]
A million operations in ~100 ms is fast. A million operations in ~10 ms is
WICKED fast.

Brian


On Thu, Mar 8, 2012 at 12:14 PM, Charles Srstka wrote:

> On Mar 8, 2012, at 1:19 PM, Brian Lambert wrote:
>
> In many simple scenarios, especially when contention is very low,
> @synchronized will be the best choice because it's trivial to get right and
> high-performance.
>
>
> @synchronized is easy-to-use, for sure, but it is far from
> high-performance.
>
> The first result that Google turns up for benchmarks comparing
> @synchronized, mutexes, and OSSpinLocks shows @synchronized to be almost an
> order of magnitude slower than the competition:
>
> http://perpendiculo.us/?p=133
>
> 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: Accessing array in thread safe way

[Mike Abdullah]

Clearly I suck at Google code :(

On 8 Mar 2012, at 18:12, CoGe - Tamas Nagy wrote:

> LGPL, as the page mentions it;)
> 
> Sent from my iPhone
> 
> On Mar 8, 2012, at 6:18 PM, Mike Abdullah  wrote:
> 
>> 
>> On 8 Mar 2012, at 14:22, CoGe - Tamas Nagy wrote:
>> 
>>> Maybe this will helps you, here is my thread-safe subclass of 
>>> NSMutableArray: 
>>> http://code.google.com/p/cogeopensource/source/browse/trunk/CoGeOpenSource/CoGeThreadSafeMutableArray.m
>>> 
>>> Works well for my project.
>> 
>> License?
>> 


___

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: NSOpenPanel may not respond to setDirectoryURL?

[Mike Abdullah]

Time for me to be cruel and pick apart your code.

On 8 Mar 2012, at 18:10, Howard Moon wrote:

> Hmmm... I'm building a VST3/vstgui4 plug-in, and I think the base SDK and 
> deployment targets are set as required, like this:
> 
> SDKROOT = macosx10.5
> SDKROOT[arch=x86_64] = $(DEVELOPER_SDK_DIR)/MacOSX10.6.sdk
> 
> When I build either a 32-bit or 64-bit build, while running on 10.6, it 
> executes -setDirectoryURL with no problems.  I haven't tried running in 10.5 
> yet.
> 
> Can I keep my above settings, but do this?
> 
>   if ([openPanel respondsToSelector:@selector(setDirectory)])

-setDirectory: is available on all OS releases. Just because it has been 
deprecated does not stop it existing! You want to test the -setDirectoryURL: 
selector instead.

>   [openPanel setDirectory:nsParentPath];
>   else
>   {
>   NSURL*  nsParentURL = [NSURL 
> fileURLWithPath:nsParentPath isDirectory:YES];
>   [openPanel setDirectoryURL:nsParentURL];
>   //[nsParentURL release]; // No...crashes! must be used by panel

That you have this code/comment shows you clearly don't understand Cocoa memory 
management yet. Please, please, please re-read the docs and take the time to 
understand it. That line of code crashing has NOTHING to do with the open panel.
>   }




___

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: ivar access during -finalize

[jonat...@mugginsoft.com]

On 8 Mar 2012, at 16:58, Quincey Morris wrote:

> 
>> A more robust solution is a probably a separate -dispose method.
> 
> Yes, though knowing when to call it can be a puzzle in itself, if there are 
> multiple references to the object. In general, you'll probably need to invent 
> a reference counting mechanism to keep track of when it's OK for your dispose 
> method to actually dispose of things. That sounds ironic in a GC environment, 
> but there's nothing wrong with reference counting when you need to keep 
> count. :)

Thanks for the input Quincey.
This sounds like the approach I should take.

On 8 Mar 2012, at 17:09, Nick Zitzmann wrote:
> 
> But if you really must use -finalize to clean up something that's not a 
> manually allocated class or data structure, then at least make sure whatever 
> you're doing is thread-safe, because -finalize is always called on a 
> background thread. +defaultManager is not thread-safe IIRC.
Thanks Nick.
I had toyed with the idea of using a static NSMutableSet instance to stash the 
ivar NSStrings (which should stop them getting collected along with self) but I 
had forgotten that finalise doesn't get called on the main thread.

Regards

Jonathan Mitchell
Mugginsoft LLP

___

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: Accessing array in thread safe way

[CoGe - Tamas Nagy]

Thanks for the explanation, you are absolutely right!

Tamas

On Mar 8, 2012, at 9:32 PM, Charles Srstka wrote:

> On Mar 8, 2012, at 2:18 PM, CoGe - Tamas Nagy wrote:
> 
>> I should subclass NSMutableArray because I had a project which used 
>> NSMutableArray (calls) before, but was not thread safe. Anyway, I can't 
>> really understand why it would be _really_ better to implement just 
>> accessors, but maybe you could explain it a bit more?
> 
> Same reason you wouldn’t implement a “name” property as a NSMutableString — 
> encapsulation, an important concept in object-oriented programming. Your 
> object should be the only object that directly manipulates its internal data. 
> You end up with a much more flexible design this way, for a lot of the 
> reasons I already mentioned.
> 
> 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: Accessing array in thread safe way

[Charles Srstka]

On Mar 8, 2012, at 2:18 PM, CoGe - Tamas Nagy wrote:

> I should subclass NSMutableArray because I had a project which used 
> NSMutableArray (calls) before, but was not thread safe. Anyway, I can't 
> really understand why it would be _really_ better to implement just 
> accessors, but maybe you could explain it a bit more?

Same reason you wouldn’t implement a “name” property as a NSMutableString — 
encapsulation, an important concept in object-oriented programming. Your object 
should be the only object that directly manipulates its internal data. You end 
up with a much more flexible design this way, for a lot of the reasons I 
already mentioned.

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: Accessing array in thread safe way

[CoGe - Tamas Nagy]

I should subclass NSMutableArray because I had a project which used 
NSMutableArray (calls) before, but was not thread safe. Anyway, I can't really 
understand why it would be _really_ better to implement just accessors, but 
maybe you could explain it a bit more?

On Mar 8, 2012, at 9:02 PM, Charles Srstka wrote:

> On Mar 8, 2012, at 8:22 AM, CoGe - Tamas Nagy wrote:
> 
>> Maybe this will helps you, here is my thread-safe subclass of 
>> NSMutableArray:http://code.google.com/p/cogeopensource/source/browse/trunk/CoGeOpenSource/CoGeThreadSafeMutableArray.m
>> 
>> Works well for my project.
> 
> IMO, if anything is overkill for something like this, it’s subclassing a 
> mutable array. What you should be doing is implementing accessors to get to 
> the data stored in the array. If you don’t need an NSMutableArray interface, 
> you can just implement methods like -objectAtIndex: and 
> -insertObject:atIndex:, etc. to get at the data, like all of the collection 
> classes do. If you do need an NSArray interface (for bindings, for example), 
> then you should implement the KVO indexed accessors, for a few reasons:
> 
> - Using accessors ensures proper encapsulation of your data; you can later 
> change the implementation under the hood from an NSMutableArray to something 
> completely different if you desire, without breaking the interface.
> 
> - If you later decide you need to be informed when something changes the 
> contents of your array, it’s much easier to do with KVO than with vending an 
> NSMutableArray.
> 
> - It’s generally not a good idea to expose the internal state of your object, 
> in any case.
> 
> - If you’re planning to use bindings to access this property, you’re going to 
> want to implement the KVO indexed accessors like objectInAtIndex:, 
> insertObject:inAtIndex:, etc. anyway for performance reasons — if you 
> don’t, the bindings mechanism will basically replace the whole array every 
> time something changes, by calling the setter for the array.
> 
> - If you really need an NSMutableArray interface to the object’s data, it’s 
> only one line of code to create an NSMutableArray proxy once the KVO indexed 
> accessor methods are already implemented, as opposed to adding a whole new 
> NSMutableArray subclass.
> 
> 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: Accessing array in thread safe way

[Charles Srstka]

On Mar 8, 2012, at 1:19 PM, Brian Lambert wrote:

> In many simple scenarios, especially when contention is very low,
> @synchronized will be the best choice because it's trivial to get right and
> high-performance.

@synchronized is easy-to-use, for sure, but it is far from high-performance.

The first result that Google turns up for benchmarks comparing @synchronized, 
mutexes, and OSSpinLocks shows @synchronized to be almost an order of magnitude 
slower than the competition:

http://perpendiculo.us/?p=133

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: Accessing array in thread safe way

[CoGe - Tamas Nagy]

Thanks for the great explanation Brian. Having a dual-processor system is a 
need for my app, so that's why I chose SpinLocks. But using dispatch blocks is 
could be an other option, I guess.


On Mar 8, 2012, at 8:19 PM, Brian Lambert wrote:

> Spin locks are useful in certain situations.
> 
> First of all, on a single-processor system, it's never a good idea to use a
> spin lock because all it will do is burn up the waiting thread's scheduling
> quantum while preventing a thread that's holding the lock from getting
> scheduled so that it can complete its work and release the lock.
> 
> A spin lock is useful in multi-processor environments when you know that a
> lock will be held for a *very short period of time*.  In this case, spin
> locks can help you avoid excessive context switching because a waiting
> thread will often be able to spin (do something else) while waiting for a
> lock to be released, acquire the lock, and do its work, all within its
> scheduling quantum.
> 
> In many simple scenarios, especially when contention is very low,
> @synchronized will be the best choice because it's trivial to get right and
> high-performance.
> 
> In other scenarios, a fair readers-writers lock will be ideal.
> 
> 
> On Thu, Mar 8, 2012 at 9:52 AM, Jan E. Schotsman  wrote:
> 
>> 
>> On Mar 8, 2012, at 3:22 PM, CoGe - Tamas Nagy wrote:
>> 
>> Maybe this will helps you, here is my thread-safe subclass of
>>> NSMutableArray: http://code.google.com/p/**cogeopensource/source/browse/*
>>> *trunk/CoGeOpenSource/**CoGeThreadSafeMutableArray.m
>>> 
>> 
>> Thanks for the code.
>> I have two questions:
>> 
>> 1. If you believe that OSSpinLock is faster than NSLock why don't you use
>> it for your thread-safe mutable array class too?
>> 
>> 2. Once you start using an enumerator for the array you probably need  a
>> explicit mutex after all. Isn't it simpler to just use
>> @synchronized(array) wherever the array is accessed?
>> 
>> Jan E.
>> 
>> __**_
>> 
>> 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/**
>> brianlambert%40gmail.com
>> 
>> This email sent to brianlamb...@gmail.com
>> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/info%40cogevj.hu
> 
> This email sent to i...@cogevj.hu

Tamas Nagy
-
CoGe VJ Software
http://cogevj.hu
i...@cogevj.hu




___

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: Accessing array in thread safe way

[Charles Srstka]

On Mar 8, 2012, at 8:22 AM, CoGe - Tamas Nagy wrote:

> Maybe this will helps you, here is my thread-safe subclass of 
> NSMutableArray:http://code.google.com/p/cogeopensource/source/browse/trunk/CoGeOpenSource/CoGeThreadSafeMutableArray.m
> 
> Works well for my project.

IMO, if anything is overkill for something like this, it’s subclassing a 
mutable array. What you should be doing is implementing accessors to get to the 
data stored in the array. If you don’t need an NSMutableArray interface, you 
can just implement methods like -objectAtIndex: and -insertObject:atIndex:, 
etc. to get at the data, like all of the collection classes do. If you do need 
an NSArray interface (for bindings, for example), then you should implement the 
KVO indexed accessors, for a few reasons:

- Using accessors ensures proper encapsulation of your data; you can later 
change the implementation under the hood from an NSMutableArray to something 
completely different if you desire, without breaking the interface.

- If you later decide you need to be informed when something changes the 
contents of your array, it’s much easier to do with KVO than with vending an 
NSMutableArray.

- It’s generally not a good idea to expose the internal state of your object, 
in any case.

- If you’re planning to use bindings to access this property, you’re going to 
want to implement the KVO indexed accessors like objectInAtIndex:, 
insertObject:inAtIndex:, etc. anyway for performance reasons — if you 
don’t, the bindings mechanism will basically replace the whole array every time 
something changes, by calling the setter for the array.

- If you really need an NSMutableArray interface to the object’s data, it’s 
only one line of code to create an NSMutableArray proxy once the KVO indexed 
accessor methods are already implemented, as opposed to adding a whole new 
NSMutableArray subclass.

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: Accessing array in thread safe way

[Jeffrey Walton]

On Thu, Mar 8, 2012 at 10:46 AM, Per Bull Holmen  wrote:
> Den 23:55 7. mars 2012 skrev Don Quixote de la Mancha
>  følgende:
>
>> If you possibly can replace locking algorithms with what are commonly but 
>> incorrectly called lock free algorithms.  They use Atomic Arithmetic 
>> Primitives provided by the CPU Instruction Set  Archetector to manage very 
>> short term locks on single words of memory.
>
> Lock-free algorithms are cool, but keep in mind that they can be hard
> to implement, so you have to know what you're doing. Once you have
> forgotten to think of a possible scheduling sequence that might
> corrupt your data, you have introduced very subtle bugs that can be
> very hard to track down.
And it may not scale... What if the program runs virtualized? Memory
locks on one machine are not honored on a separate, virtualized
server.

___

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: Accessing array in thread safe way

[CoGe - Tamas Nagy]

On Mar 8, 2012, at 6:52 PM, Jan E. Schotsman wrote:

> 
> On Mar 8, 2012, at 3:22 PM, CoGe - Tamas Nagy wrote:
> 
>> Maybe this will helps you, here is my thread-safe subclass of 
>> NSMutableArray: 
>> http://code.google.com/p/cogeopensource/source/browse/trunk/CoGeOpenSource/CoGeThreadSafeMutableArray.m
> 
> Thanks for the code.
> I have two questions:
> 
> 1. If you believe that OSSpinLock is faster than NSLock why don't you use it 
> for your thread-safe mutable array class too?

I mostly using the NSMutableDictionary subclass, and just forgot to update the 
NSMutableArray class. Thats the only reason,


> 
> 2. Once you start using an enumerator for the array you probably need  a 
> explicit mutex after all. Isn't it simpler to just use  @synchronized(array) 
> wherever the array is accessed?

@syncronized(array) is not really fast.

> 
> Jan E.
> 
> ___
> 
> 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/info%40cogevj.hu
> 
> This email sent to i...@cogevj.hu

Tamas Nagy
-
CoGe VJ Software
http://cogevj.hu
i...@cogevj.hu




___

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: Accessing array in thread safe way

[Brian Lambert]

Spin locks are useful in certain situations.

First of all, on a single-processor system, it's never a good idea to use a
spin lock because all it will do is burn up the waiting thread's scheduling
quantum while preventing a thread that's holding the lock from getting
scheduled so that it can complete its work and release the lock.

A spin lock is useful in multi-processor environments when you know that a
lock will be held for a *very short period of time*.  In this case, spin
locks can help you avoid excessive context switching because a waiting
thread will often be able to spin (do something else) while waiting for a
lock to be released, acquire the lock, and do its work, all within its
scheduling quantum.

In many simple scenarios, especially when contention is very low,
@synchronized will be the best choice because it's trivial to get right and
high-performance.

In other scenarios, a fair readers-writers lock will be ideal.


On Thu, Mar 8, 2012 at 9:52 AM, Jan E. Schotsman  wrote:

>
> On Mar 8, 2012, at 3:22 PM, CoGe - Tamas Nagy wrote:
>
>  Maybe this will helps you, here is my thread-safe subclass of
>> NSMutableArray: http://code.google.com/p/**cogeopensource/source/browse/*
>> *trunk/CoGeOpenSource/**CoGeThreadSafeMutableArray.m
>>
>
> Thanks for the code.
> I have two questions:
>
> 1. If you believe that OSSpinLock is faster than NSLock why don't you use
> it for your thread-safe mutable array class too?
>
> 2. Once you start using an enumerator for the array you probably need  a
> explicit mutex after all. Isn't it simpler to just use
>  @synchronized(array) wherever the array is accessed?
>
> Jan E.
>
> __**_
>
> 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/**
> brianlambert%40gmail.com
>
> This email sent to brianlamb...@gmail.com
>
___

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

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

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

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

Re: NSOpenPanel may not respond to setDirectoryURL?

[Howard Moon]

>> Hmmm... I'm building a VST3/vstgui4 plug-in, and I think the base SDK and 
>> deployment targets are set as required, like this:
>> 
>> SDKROOT = macosx10.5
>> SDKROOT[arch=x86_64] = $(DEVELOPER_SDK_DIR)/MacOSX10.6.sdk
>> 
>> When I build either a 32-bit or 64-bit build, while running on 10.6, it 
>> executes -setDirectoryURL with no problems.  I haven't tried running in 10.5 
>> yet.
>> 
>> Can I keep my above settings, but do this?
>> 
>>  if ([openPanel respondsToSelector:@selector(setDirectory)])
>>  [openPanel setDirectory:nsParentPath];
>>  else
>>  {
>>  NSURL*  nsParentURL = [NSURL 
>> fileURLWithPath:nsParentPath isDirectory:YES];
>>  [openPanel setDirectoryURL:nsParentURL];
>>  //[nsParentURL release]; // No...crashes! must be used by panel
>>  }
> 
> 
> That code works in either 32-bit or 64-bit under 10.6, but it seems to be 
> throwing an exception or something on 10.5(.8), because when I execute it, no 
> dialog appears and I can continue along with other work in my plug-in, as if 
> nothing had happened.  (This is all executed from a button press in a sheet.)
> 

D'oh!  I forgot the ':' in that selector... should have been 
respondsToSelector:@selector(setDirectory:). Silly computer, always doing what 
I say, not what I want...

-Howard



___

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: NSOpenPanel may not respond to setDirectoryURL?

[Howard Moon]

On Mar 8, 2012, at 10:10 AM, Howard Moon wrote:

> 
> On Mar 8, 2012, at 9:17 AM, Mike Abdullah wrote:
> 
>> 
>> On 8 Mar 2012, at 14:54, Howard Moon wrote:
>> 
>>> On Mar 8, 2012, at 6:21 AM, Mike Abdullah wrote:
> 
>   I'm really not that familiar with Objective-C and Cocoa yet, but I'm 
> getting a warning for something that works fine, and I hate warnings.  
> The warning is:
> 
>   'NSOpenPanel' may not respond to '-setDirectoryURL:'
> 
>   I know that setDirectoryURL: is an NSSavePanel message, but NSOpenPanel 
> derives from NSSavePanel, so why does it give me this warning?  As I 
> said, it works fine (i.e., the open panel starts out in the folder I 
> specified).  Is there a case where it WON'T work?  If not, then is there 
> a way to prevent the warning?
 
 That method was introduced in 10.6. Are you perhaps building against the 
 10.5 SDK or even earlier?
 
>>> 
>>> Ah, yes, that's it.  But I do need to support 10.5.  What can I use that 
>>> works in 10.5 thru 10.7?
>> 
>> Options:
>> 
>> A)
>> Bump the SDK setting to 10.6, keeping the deployment target at 10.5. Don't 
>> call any 10.6-only methods when running on 10.5. (i.e. check 
>> -respondsToSelector: or similar)
>> 
>> B)
>> Declare the new methods as categories in headers, but don't actually 
>> implement the methods. That will tell the compiler how to call those new 
>> methods. Once again, don't call 10.6-only methods while running on 10.5
>> 
>> C)
>> Fallback to older, deprecated APIs. e.g. -directory
>> 
> 
> 
> Hmmm... I'm building a VST3/vstgui4 plug-in, and I think the base SDK and 
> deployment targets are set as required, like this:
> 
> SDKROOT = macosx10.5
> SDKROOT[arch=x86_64] = $(DEVELOPER_SDK_DIR)/MacOSX10.6.sdk
> 
> When I build either a 32-bit or 64-bit build, while running on 10.6, it 
> executes -setDirectoryURL with no problems.  I haven't tried running in 10.5 
> yet.
> 
> Can I keep my above settings, but do this?
> 
>   if ([openPanel respondsToSelector:@selector(setDirectory)])
>   [openPanel setDirectory:nsParentPath];
>   else
>   {
>   NSURL*  nsParentURL = [NSURL 
> fileURLWithPath:nsParentPath isDirectory:YES];
>   [openPanel setDirectoryURL:nsParentURL];
>   //[nsParentURL release]; // No...crashes! must be used by panel
>   }


That code works in either 32-bit or 64-bit under 10.6, but it seems to be 
throwing an exception or something on 10.5(.8), because when I execute it, no 
dialog appears and I can continue along with other work in my plug-in, as if 
nothing had happened.  (This is all executed from a button press in a sheet.)

I need to be able to set the default directory in whatever OS I'm in, whether 
it's 10.5, 10.6 or 10.7.  Will option B above allow that?  (I'm not sure what 
that actually means... I'll have to look up categories, I guess.  But any hint 
would be appreciated.)

-Howard





___

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: Accessing array in thread safe way

[CoGe - Tamas Nagy]

LGPL, as the page mentions it;)

Sent from my iPhone

On Mar 8, 2012, at 6:18 PM, Mike Abdullah   
wrote:




On 8 Mar 2012, at 14:22, CoGe - Tamas Nagy wrote:

Maybe this will helps you, here is my thread-safe subclass of  
NSMutableArray: http://code.google.com/p/cogeopensource/source/browse/trunk/CoGeOpenSource/CoGeThreadSafeMutableArray.m


Works well for my project.


License?


___

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: NSOpenPanel may not respond to setDirectoryURL?

[Howard Moon]

On Mar 8, 2012, at 9:17 AM, Mike Abdullah wrote:

> 
> On 8 Mar 2012, at 14:54, Howard Moon wrote:
> 
>> On Mar 8, 2012, at 6:21 AM, Mike Abdullah wrote:
 
I'm really not that familiar with Objective-C and Cocoa yet, but I'm 
 getting a warning for something that works fine, and I hate warnings.  The 
 warning is:
 
'NSOpenPanel' may not respond to '-setDirectoryURL:'
 
I know that setDirectoryURL: is an NSSavePanel message, but NSOpenPanel 
 derives from NSSavePanel, so why does it give me this warning?  As I said, 
 it works fine (i.e., the open panel starts out in the folder I specified). 
  Is there a case where it WON'T work?  If not, then is there a way to 
 prevent the warning?
>>> 
>>> That method was introduced in 10.6. Are you perhaps building against the 
>>> 10.5 SDK or even earlier?
>>> 
>> 
>> Ah, yes, that's it.  But I do need to support 10.5.  What can I use that 
>> works in 10.5 thru 10.7?
> 
> Options:
> 
> A)
> Bump the SDK setting to 10.6, keeping the deployment target at 10.5. Don't 
> call any 10.6-only methods when running on 10.5. (i.e. check 
> -respondsToSelector: or similar)
> 
> B)
> Declare the new methods as categories in headers, but don't actually 
> implement the methods. That will tell the compiler how to call those new 
> methods. Once again, don't call 10.6-only methods while running on 10.5
> 
> C)
> Fallback to older, deprecated APIs. e.g. -directory
> 


Hmmm... I'm building a VST3/vstgui4 plug-in, and I think the base SDK and 
deployment targets are set as required, like this:

SDKROOT = macosx10.5
SDKROOT[arch=x86_64] = $(DEVELOPER_SDK_DIR)/MacOSX10.6.sdk

When I build either a 32-bit or 64-bit build, while running on 10.6, it 
executes -setDirectoryURL with no problems.  I haven't tried running in 10.5 
yet.

Can I keep my above settings, but do this?

if ([openPanel respondsToSelector:@selector(setDirectory)])
[openPanel setDirectory:nsParentPath];
else
{
NSURL*  nsParentURL = [NSURL 
fileURLWithPath:nsParentPath isDirectory:YES];
[openPanel setDirectoryURL:nsParentURL];
//[nsParentURL release]; // No...crashes! must be used by panel
}


-Howard



___

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: Accessing array in thread safe way

[Jan E. Schotsman]

On Mar 8, 2012, at 3:22 PM, CoGe - Tamas Nagy wrote:

Maybe this will helps you, here is my thread-safe subclass of  
NSMutableArray: http://code.google.com/p/cogeopensource/source/browse/trunk/CoGeOpenSource/CoGeThreadSafeMutableArray.m


Thanks for the code.
I have two questions:

1. If you believe that OSSpinLock is faster than NSLock why don't you  
use it for your thread-safe mutable array class too?


2. Once you start using an enumerator for the array you probably need   
a explicit mutex after all. Isn't it simpler to just use   
@synchronized(array) wherever the array is accessed?


Jan E.

___

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: Accessing array in thread safe way

[Mike Abdullah]

On 8 Mar 2012, at 14:22, CoGe - Tamas Nagy wrote:

> Maybe this will helps you, here is my thread-safe subclass of NSMutableArray: 
> http://code.google.com/p/cogeopensource/source/browse/trunk/CoGeOpenSource/CoGeThreadSafeMutableArray.m
> 
> Works well for my project.

License?


___

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: NSOpenPanel may not respond to setDirectoryURL?

[Mike Abdullah]

On 8 Mar 2012, at 14:54, Howard Moon wrote:

> On Mar 8, 2012, at 6:21 AM, Mike Abdullah wrote:
>>> 
>>> I'm really not that familiar with Objective-C and Cocoa yet, but I'm 
>>> getting a warning for something that works fine, and I hate warnings.  The 
>>> warning is:
>>> 
>>> 'NSOpenPanel' may not respond to '-setDirectoryURL:'
>>> 
>>> I know that setDirectoryURL: is an NSSavePanel message, but NSOpenPanel 
>>> derives from NSSavePanel, so why does it give me this warning?  As I said, 
>>> it works fine (i.e., the open panel starts out in the folder I specified).  
>>> Is there a case where it WON'T work?  If not, then is there a way to 
>>> prevent the warning?
>> 
>> That method was introduced in 10.6. Are you perhaps building against the 
>> 10.5 SDK or even earlier?
>> 
> 
> Ah, yes, that's it.  But I do need to support 10.5.  What can I use that 
> works in 10.5 thru 10.7?

Options:

A)
Bump the SDK setting to 10.6, keeping the deployment target at 10.5. Don't call 
any 10.6-only methods when running on 10.5. (i.e. check -respondsToSelector: or 
similar)

B)
Declare the new methods as categories in headers, but don't actually implement 
the methods. That will tell the compiler how to call those new methods. Once 
again, don't call 10.6-only methods while running on 10.5

C)
Fallback to older, deprecated APIs. e.g. -directory


___

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: ivar access during -finalize

[Nick Zitzmann]

On Mar 8, 2012, at 8:39 AM, jonat...@mugginsoft.com wrote:

> I largely eschew -finalize in my GC app but on some occasions I do use it and 
> I am seeing some resurrection problems.
> I have read "Implementing a finalize method" and "Inapplicable Patterns" in 
> the "Garbage Collection Programming Guide".
> 
> Consider:
> 
> - (void)finalize
> {
>   // a single reference to _myIvar is held by self
>   [[NSFileManager defaultManager] removeItemAtPath:_myIvar error:NULL]
>   [super finalize];
> }
> 
> Which occasion leads to:
> 
> Thread 9 Crashed:: Dispatch queue: Garbage Collection Work Queue
> 0 libauto.dylib 0x94712a5b void 
> handle_resurrection(Auto::Zone*, void*, 
> Auto::SubzoneBlockRef, unsigned long) + 683
> ...
> 5 libobjc.A.dylib 0x94644256 objc_assign_ivar_gc + 55
> 6 com.apple.Foundation 0x9102df8d -[NSFilesystemItemRemoveOperation 
> initWithPath:] + 57
> 7 com.apple.Foundation 0x9102d547 +[NSFilesystemItemRemoveOperation 
> filesystemItemRemoveOperationWithPath:] + 65
> 8 com.apple.Foundation 0x9102d382 -[NSFileManager removeItemAtPath:error:] + 
> 57
> 9 com.mugginsoft.myframework  0x00291387 -[MGSBrowserImage finalize] + 183 
> (MGSBrowserImage.m:87)
> ...
> 16 libauto.dylib 0x94723e29 Auto::Zone::invalidate_garbage(unsigned long, 
> void**) + 89
> 
> I had initially assumed that _myIvar would be finalised after self.
> But the reality appears to be that an object and any objects referenced by 
> ivars may be collected simultaneously.
> The crash therefore occurs when the ivar is finalised first and is 
> subsequently re-assigned to a reference as a result of calling the 
> NSFileManager method.
> 
> Question:
> Is the above correct?

Yes.

> If so it means that finalisers need to be very carefully about manipulating 
> ivars.
> In my case I could probably work around the issue by replacing  
> -removeItemAtPath with unlink(2), assuming that I can get a char 
> representation from my finalised NSString ivar.
> A more robust solution is a probably a separate -dispose method.


I'd say "definitely" instead of "probably" above. As you've discovered, it's a 
bad idea to do anything in -finalize that doesn't involve freeing up memory 
allocated outside of the garbage collector's zone, so if you must clean 
something up that isn't RAM, you should figure out an alternative way of doing 
so.

But if you really must use -finalize to clean up something that's not a 
manually allocated class or data structure, then at least make sure whatever 
you're doing is thread-safe, because -finalize is always called on a background 
thread. +defaultManager is not thread-safe IIRC.

Nick Zitzmann



___

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: ivar access during -finalize

[Quincey Morris]

On Mar 8, 2012, at 07:39 , jonat...@mugginsoft.com wrote:

> Consider:
> 
> - (void)finalize
> {
>   // a single reference to _myIvar is held by self
>   [[NSFileManager defaultManager] removeItemAtPath:_myIvar error:NULL]
>   [super finalize];
> }

> I had initially assumed that _myIvar would be finalised after self.
> But the reality appears to be that an object and any objects referenced by 
> ivars may be collected simultaneously.
> The crash therefore occurs when the ivar is finalised first and is 
> subsequently re-assigned to a reference as a result of calling the 
> NSFileManager method.
> 
> Question:
> Is the above correct?

Yes, precisely so.

> If so it means that finalisers need to be very carefully about manipulating 
> ivars.

Here's a good rule of thumb about referencing object ivars during finalize:

Don't.

In order to use object references safely in finalize, you have to be able to 
prove that they're still alive, and that can be very, very hard -- at least 
with ivars.

> In my case I could probably work around the issue by replacing  
> -removeItemAtPath with unlink(2), assuming that I can get a char 
> representation from my finalised NSString ivar.

In practical terms, finalize should limit itself to doing things with 
non-objects, such as using 'free' on memory acquired by 'malloc'. You can never 
safely get a char representation of your NSString during finalize. However, you 
*could* have a malloc-ed char* ivar that you created earlier and use that to 
delete the file.

> A more robust solution is a probably a separate -dispose method.

Yes, though knowing when to call it can be a puzzle in itself, if there are 
multiple references to the object. In general, you'll probably need to invent a 
reference counting mechanism to keep track of when it's OK for your dispose 
method to actually dispose of things. That sounds ironic in a GC environment, 
but there's nothing wrong with reference counting when you need to keep count. 
:)


___

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 are 2 Terminal windows opening with NSAppleScript?

[Ken Thomases]

On Mar 7, 2012, at 9:32 PM, Prime Coderama wrote:

> If no Terminal app is open, the following code opens TWO Terminal windows. 
> Why is it doing this? I only want one window to open.
> 
> If only one Terminal window is open, then the following code opens only ONE 
> additional window.
> 
> NSAppleScript* terminal = [[NSAppleScript alloc] initWithSource:
>   [NSString stringWithFormat:
>@"tell application \"Terminal\"\n"
>@"activate\n"
>@"do script \"echo %@\"\n"
>@"tell the front window\n"
>@"set title displays shell path to false\n"
>@"set title displays custom title to 
> true\n"
>@"set custom title to \"My session! %@\"\n"
>@"end tell\n"
>@"end tell", name, name]];
> 
> [terminal executeAndReturnError:nil];

Hint: what happens if you just launch Terminal?

Terminal opens a window (or, depending on settings, a window group) at launch.  
Then, as you note, your script opens an additional window.

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: Accessing array in thread safe way

[Per Bull Holmen]

Den 23:55 7. mars 2012 skrev Don Quixote de la Mancha
 følgende:

> If you possibly can replace locking algorithms with what are commonly but 
> incorrectly called lock free algorithms.  They use Atomic Arithmetic 
> Primitives provided by the CPU Instruction Set  Archetector to manage very 
> short term locks on single words of memory.

Lock-free algorithms are cool, but keep in mind that they can be hard
to implement, so you have to know what you're doing. Once you have
forgotten to think of a possible scheduling sequence that might
corrupt your data, you have introduced very subtle bugs that can be
very hard to track down. If you only stick to well-known algorithms
that are well tested, you should be OK, I think. But remember to
analyze the whole structure of the app to determine if that algorithm,
used the way you intend to use it, does really make it thread safe. I
guess this last bit is true whether you use locks or not.

To see a list of atomic primitives for OS X apps, start terminal and type

man atomic

Per

___

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

ivar access during -finalize

[jonat...@mugginsoft.com]

I largely eschew -finalize in my GC app but on some occasions I do use it and I 
am seeing some resurrection problems.
I have read "Implementing a finalize method" and "Inapplicable Patterns" in the 
"Garbage Collection Programming Guide".

Consider:

- (void)finalize
{
// a single reference to _myIvar is held by self
[[NSFileManager defaultManager] removeItemAtPath:_myIvar error:NULL]
[super finalize];
}

Which occasion leads to:

Thread 9 Crashed:: Dispatch queue: Garbage Collection Work Queue
0 libauto.dylib 0x94712a5b void 
handle_resurrection(Auto::Zone*, void*, 
Auto::SubzoneBlockRef, unsigned long) + 683
...
5 libobjc.A.dylib 0x94644256 objc_assign_ivar_gc + 55
6 com.apple.Foundation 0x9102df8d -[NSFilesystemItemRemoveOperation 
initWithPath:] + 57
7 com.apple.Foundation 0x9102d547 +[NSFilesystemItemRemoveOperation 
filesystemItemRemoveOperationWithPath:] + 65
8 com.apple.Foundation 0x9102d382 -[NSFileManager removeItemAtPath:error:] + 57
9 com.mugginsoft.myframework0x00291387 -[MGSBrowserImage finalize] + 183 
(MGSBrowserImage.m:87)
...
16 libauto.dylib 0x94723e29 Auto::Zone::invalidate_garbage(unsigned long, 
void**) + 89

I had initially assumed that _myIvar would be finalised after self.
But the reality appears to be that an object and any objects referenced by 
ivars may be collected simultaneously.
The crash therefore occurs when the ivar is finalised first and is subsequently 
re-assigned to a reference as a result of calling the NSFileManager method.

Question:
Is the above correct?

If so it means that finalisers need to be very carefully about manipulating 
ivars.
In my case I could probably work around the issue by replacing  
-removeItemAtPath with unlink(2), assuming that I can get a char representation 
from my finalised NSString ivar.
A more robust solution is a probably a separate -dispose method.

Regards

Jonathan Mitchell
Mugginsoft LLP









___

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: Finding object array index when iterating through array

[Daniel Vollmer]

On 7 Mar 2012, at 12:09, John Maisey wrote:

> Hi,
> 
> If the items are unique, how about:
> 
> [array indexOfObject:object];

Congratulations, you have just (depending on NSArray-implementation details) 
"improved" your loop from from O(N) to O(N^2). Don't do this.

> Using a counter is likely be faster though.

Correct.

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

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

Re: NSOpenPanel may not respond to setDirectoryURL?

[Howard Moon]

On Mar 8, 2012, at 6:21 AM, Mike Abdullah wrote:
>> 
>>  I'm really not that familiar with Objective-C and Cocoa yet, but I'm 
>> getting a warning for something that works fine, and I hate warnings.  The 
>> warning is:
>> 
>>  'NSOpenPanel' may not respond to '-setDirectoryURL:'
>> 
>>  I know that setDirectoryURL: is an NSSavePanel message, but NSOpenPanel 
>> derives from NSSavePanel, so why does it give me this warning?  As I said, 
>> it works fine (i.e., the open panel starts out in the folder I specified).  
>> Is there a case where it WON'T work?  If not, then is there a way to prevent 
>> the warning?
> 
> That method was introduced in 10.6. Are you perhaps building against the 10.5 
> SDK or even earlier?
> 

Ah, yes, that's it.  But I do need to support 10.5.  What can I use that works 
in 10.5 thru 10.7?

Thanks,
Howard



___

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 161

[John Maisey]

Hi,

The 'do script' command opens a new shell window. From Terminal's  Applescript 
dictionary:

   do script v : Runs a UNIX shell script or command.

This script opens a new window always.

tell application "Terminal"
activate
do script
end tell

The previous window when the applications opens will be stored from the 
previous session that Terminal.app was opened. If you don't want to see it,  
you could check to see if the Terminal.app is running and if it is not close 
all windows once you activate it In the NSAppleScript command.

Best wishes

John Maisey

www.nhoj.co.uk
www.twitter.com/johnmaisey
www.facebook.com/nhojcouk





On 8 Mar 2012, at 05:19, cocoa-dev-requ...@lists.apple.com wrote:

> Subject: Why are 2 Terminal windows opening with NSAppleScript?
> 
> If no Terminal app is open, the following code opens TWO Terminal windows. 
> Why is it doing this? I only want one window to open.
> 
> If only one Terminal window is open, then the following code opens only ONE 
> additional window.
> 
> NSAppleScript* terminal = [[NSAppleScript alloc] initWithSource:
>   [NSString stringWithFormat:
>@"tell application \"Terminal\"\n"
>@"activate\n"
>@"do script \"echo %@\"\n"
>@"tell the front window\n"
>@"set title displays shell path to false\n"
>@"set title displays custom title to 
> true\n"
>@"set custom title to \"My session! %@\"\n"
>@"end tell\n"
>@"end tell", name, name]];
> 
> [terminal executeAndReturnError:nil];
> 


___

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: Accessing array in thread safe way

[CoGe - Tamas Nagy]

Maybe this will helps you, here is my thread-safe subclass of NSMutableArray: 
http://code.google.com/p/cogeopensource/source/browse/trunk/CoGeOpenSource/CoGeThreadSafeMutableArray.m

Works well for my project.



On Mar 8, 2012, at 11:22 AM, Jan E. Schotsman wrote:

> Thanks for all the answers.
> 
> 1. I'll read the ThreadSafetySummary. So far I had only read the Threading 
> section of the Objective C Programming Language.
> 
> 2. Accessing the progress values of the subprojects seems the way to go here.
> 
> 3. Creating a proxy mutable array seems like overkill. Basically this is a 
> thread-safe subclass of NSMutableArray, correct?
> 
> 4. @Don Quixote: interesting lecture. Now I know what 'lockfree" means.
> 
>> To improve performance share as little data as possible, access it as 
>> infrequently as possible and if you access it at all, finish what you're 
>> doing with the shared data as quickie as you can.
> 
> In this case the subprojects shouldn't update their progress values too 
> often. Only if additional progress is more than 1% for example.
> 
> Jan E.
> ___
> 
> 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/info%40cogevj.hu
> 
> This email sent to i...@cogevj.hu

Tamas Nagy
-
CoGe VJ Software
http://cogevj.hu
i...@cogevj.hu




___

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: NSOpenPanel may not respond to setDirectoryURL?

[Mike Abdullah]

On 7 Mar 2012, at 19:07, Howard Moon wrote:

> Hi all,
> 
>   I'm really not that familiar with Objective-C and Cocoa yet, but I'm 
> getting a warning for something that works fine, and I hate warnings.  The 
> warning is:
> 
>   'NSOpenPanel' may not respond to '-setDirectoryURL:'
> 
>   I know that setDirectoryURL: is an NSSavePanel message, but NSOpenPanel 
> derives from NSSavePanel, so why does it give me this warning?  As I said, it 
> works fine (i.e., the open panel starts out in the folder I specified).  Is 
> there a case where it WON'T work?  If not, then is there a way to prevent the 
> warning?

That method was introduced in 10.6. Are you perhaps building against the 10.5 
SDK or even earlier?


___

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: Finding object array index when iterating through array

[Peter]

Am 08.03.2012 um 03:39 schrieb Greg Parker:

> On Mar 6, 2012, at 6:19 PM, Marco Tabini  wrote:
>>> I have an array and I am iterating through it using this technique:
>>> 
 for (id object in array) {
  // do something with object
 }
>>> 
>>> Is there  way to obtain the object's current array index position or do I 
>>> have to add a counter?
>> 
>> [array indexOfObject:object] should do the trick, though, if you need to do 
>> it at every iteration, keeping a counter may be better.
> 
> Note that -indexOfObject: returns an object from the array that is -isEqual: 
> to the parameter. This might not be the same object that you are looking at. 
> 
> -indexOfObjectIdenticalTo: would solve the -isEqual: problem, but would still 
> return the wrong index if the same object were in the array twice.
> 
> You should add a counter to your for..in loop, or use a traditional counted 
> for loop and -objectAtIndex:

Finally...
After reading so much "doubtful" (= outright bad) advice I began to doubt my 
own understanding of Objective-C.
What a relief!
Thank you!

Peter
___

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: Problem with refreshing NSMenuItems

[Michael Babin]

On Mar 7, 2012, at 2:40 AM, Prime Coderama wrote:

> I have an NSMenu with the following static NSMenuItems
> 
> 1. NSMenuItem "Count of people" (hidden)
> 2. NSMenuItem  (hidden)
> 3. NSMenuItem 
> 4. NSMenuItem "Refresh List"
> 5. NSMenuItem 
> 6. NSMenuItem "Quit"
> 
> I then dynamically add n-amount of NSMenuItems between (2) and (3). This 
> works great.
> 
> The problem I am having, is when I hit "Refresh", I am unsure on how to 
> remove all of the dynamically added NSMenuItems from the NSMenu and add all 
> of the new ones?
> 
> I am currently causing a mess using NSMenu:removeItemAtIndex.
> 
> Any suggestions?

1. When you add NSMenuItems to the menu, also add them to an array you create 
and maintain. When your Refresh action occurs, iterate through the array and 
remove each item from the menu (and clear your array). Then add the new items 
(to the menu and your array).
2. Set a tag attribute for your dynamic menu items. Then iterate the menu and 
remove the menu items with that tag attribute.



___

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: Finding object array index when iterating through array

[Roland King]

On Mar 8, 2012, at 9:47 AM, Stephen J. Butler wrote:

> On Tue, Mar 6, 2012 at 8:19 PM, Marco Tabini  wrote:
>>> I have an array and I am iterating through it using this technique:
>>> 
 for (id object in array) {
// do something with object
 }
>>> 
>>> Is there  way to obtain the object's current array index position or do I 
>>> have to add a counter?
>> 
>> [array indexOfObject:object] should do the trick, though, if you need to do 
>> it at every iteration, keeping a counter may be better.
> 
> Here's a stupid question that occurred to me: do the documents
> anywhere guarantee that NSFastEnumeration over an NSArray will always
> return the items in order? That is, the first item returned will have
> index 0, second will have index 1, etc.
> 
> I feel like the safe thing in this situation is to just revert back to
> an plain old "for (;;;)" loop. You know then that the index you have
> is the one for the object.
> 

Yes. The documentation for NSArray guarantees that. Look at objectEnumerator 
and the discussion following 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: Problem with refreshing NSMenuItems

[Gregory Weston]

Prime Coderama wrote:

> I have an NSMenu with the following static NSMenuItems
> 
> 1. NSMenuItem "Count of people" (hidden)
> 2. NSMenuItem  (hidden)
> 3. NSMenuItem 
> 4. NSMenuItem "Refresh List"
> 5. NSMenuItem 
> 6. NSMenuItem "Quit"
> 
> I then dynamically add n-amount of NSMenuItems between (2) and (3). This 
> works great.
> 
> The problem I am having, is when I hit "Refresh", I am unsure on how to 
> remove all of the dynamically added NSMenuItems from the NSMenu and add all 
> of the new ones?
> 
> I am currently causing a mess using NSMenu:removeItemAtIndex.
> 
> Any suggestions?

My first suggestion would be that it's very weird and potentially troublesome 
to have static items in a menu that come after a dynamic list of arbitrary 
size. Even if you can guarantee the user is never going to have to scroll 
through 183 items to get to the Refresh command, you're still working against 
the development of any kind of "muscle memory." If I were doing something like 
this design, my menu have the refresh command first, then the count, the 
separator and then the dynamic list. I don't think a quit command belongs in 
such a menu at all, but if you really need it I'd still put it above the 
dynamic list. Then your solution becomes just deleting everything after a given 
index.

That said: Your current solution should work in the abstract. You don't 
describe the "mess" you're causing but I'm quite confident it's a logic error 
rather than any kind of fundamental problem with using removeItemAtIndex: for 
this task. Other alternatives that might work well involve finding items to 
remove based on their tag, target or represented object, any one of which you 
may already be setting depending on how you react to those items being invoked.
___

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: Accessing array in thread safe way

[Jan E. Schotsman]

Thanks for all the answers.

1. I'll read the ThreadSafetySummary. So far I had only read the  
Threading section of the Objective C Programming Language.


2. Accessing the progress values of the subprojects seems the way to  
go here.


3. Creating a proxy mutable array seems like overkill. Basically this  
is a thread-safe subclass of NSMutableArray, correct?


4. @Don Quixote: interesting lecture. Now I know what 'lockfree" means.

To improve performance share as little data as possible, access it  
as infrequently as possible and if you access it at all, finish what  
you're doing with the shared data as quickie as you can.


In this case the subprojects shouldn't update their progress values  
too often. Only if additional progress is more than 1% for example.


Jan E.
___

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: Finding object array index when iterating through array

[Andreas Grosam]

On Mar 7, 2012, at 3:35 AM, Conrad Shultz wrote:

> On 3/6/12 12:42 PM, Prime Coderama wrote:
>> I have an array and I am iterating through it using this technique:
>> 
>>> for (id object in array) {
>>>// do something with object
>>> }
>> 
>> Is there  way to obtain the object's current array index position or do I 
>> have to add a counter?
>> 
> 
> You could use [array indexOfObjectIdenticalTo:object].
> 
> But I'm partial to block-based enumeration, which gives you the index
> "for free":
> 
> - (void)enumerateObjectsUsingBlock:(void (^)(id obj, NSUInteger idx,
> BOOL *stop))block;

Unless I missed the newest compiler technologies which are capable to inline 
blocks straight into the loop, invoking a block is essentially a jump to 
another code section or is akin a function call. This isn't free at all and 
prevents several optimizations by the compiler  ;)

Andreas
___

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: Dynamic NSMenuItems with default param

[Prime Coderama]

Figured it out:
> NSMenuItem *menuItem;
> menuItem = [subMenu addItemWithTitle:@"Open folder" 
> action:@selector(openDirectory:person.directory) keyEquivalent:@""];
> [menuItem setRepresentedObject:person];

On 08/03/2012, at 6:56 PM, Prime Coderama wrote:

> I am dynamically building menu's based on an array and there is a sub-menu is 
> linked to an IBAction which opens a folder in Finder. The folder it opens is 
> based on a property of the object in my initial array.
> 
> Is there a way of linked the NSMenuItem action to the IBAction and passing in 
> this directory variable as I am dynamically creating this array?
> 
> OR should I be going into the IBAction and resolving the directory by 
> referencing the NSMenuItem with against array?
> 
> I was thinking something along the lines of this:
> person = [[Person alloc] init];
> // person is assigned
> subMenu = [[NSMenu alloc] init];
> [subMenu addItemWithTitle:@"Open folder" 
> action:@selector(openDirectory:person.directory) keyEquivalent:@""];

___

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

Dynamic NSMenuItems with default param

[Prime Coderama]

I am dynamically building menu's based on an array and there is a sub-menu is 
linked to an IBAction which opens a folder in Finder. The folder it opens is 
based on a property of the object in my initial array.

Is there a way of linked the NSMenuItem action to the IBAction and passing in 
this directory variable as I am dynamically creating this array?

OR should I be going into the IBAction and resolving the directory by 
referencing the NSMenuItem with against array?

I was thinking something along the lines of this:
person = [[Person alloc] init];
// person is assigned
subMenu = [[NSMenu alloc] init];
[subMenu addItemWithTitle:@"Open folder" 
action:@selector(openDirectory:person.directory) keyEquivalent:@""];
___

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

Versions browser, file access, revertToSaved

[Martin Hewitson]

Dear list,

I have an app which works with autosave and Versions browser. However, I have 
discovered some strange behaviour. If I have a file (text file) open in the 
app, and the file is somehow accessed on disk (doing touch on the file is 
enough), the app jumps in and out of the Versions browser in a most bizarre 
way. It really goes bananas, to employ a technical term.

I tested the same actions with TextEdit, and there the problem doesn't happen, 
so it's clearly something with my app.

I think I tracked this down to a call to -revertDocumentToSaved:. I have a 
file-monitor in the app which reloads the document if it changes on disk 
(silently if there are no in-app edits; with an alert if there are).  For the 
reloading I was simply calling -revertDocumentToSaved:. If I don't do that and 
instead use the same routine I use when the document opens, the problem goes 
away. But it leaves me with a different problem. In the file-loading method I 
call

[self setFileModificationDate:[NSDate date]];
[self updateChangeCount:NSChangeCleared];

if the load was successful. But now when I try to save the document from within 
the app (after further edits) I get the usual 

"The document “foo.txt” could not be saved. The file has been changed by 
another application."

alert. Is there something else I should do to convince the NSDocument machinery 
that the in memory version of the document is in sync with the on-disk version?

Cheers,

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

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

Re: Finding object array index when iterating through array

[Graham Cox]

On 07/03/2012, at 2:22 PM, Graham Cox wrote:


That was over 28 hours ago. Why is it taking so long for posted messages to 
show up on the list? It's crazy, because by the time the response arrives, the 
question has been answered over and over and over again


--Graham




___

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

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

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

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

Re: NSTableCellView subclass layout from independent nib

[Seth Willits]

On Mar 6, 2012, at 6:03 PM, Seth Willits wrote:

> Another possible solution is to use a class method on the cell view class 
> which does loading from a nib. That method would then have some 
> TableCellViewNibLoader class be File's Owner when loading the nib, and then 
> the view inside the nib can actually be the table cell view instance which 
> gets returned by the method. Possible, but also annoying.



Actually a separate class isn't needed. I had thought about it, thought it 
wasn't going to work, and now I realize it will work: You can just load the nib 
with no owner and scan the top level objects and find an instance of the cell 
view's class. 


@implementation NSTableCellView (AraeliumAdditions)

+ (id)tableCellViewWithNibNamed:(NSString *)nibName;
{
NSView * view = nil;
NSArray * topLevelObjects = nil;
NSNib * nib = [[[NSNib alloc] initWithNibNamed:nibName bundle:nil] 
autorelease];
if (!nib || ![nib instantiateNibWithOwner:nil 
topLevelObjects:&topLevelObjects]) {
return nil;
}

for (id obj in topLevelObjects) {
if ([obj isKindOfClass:[self class]]) {
view = obj;
break;
}
}

return view;
}

@end



So, other than that this is different of any other nib loading I know of, it's 
useful and convenient.


--
Seth Willits




--
Seth Willits



___

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: Finding object array index when iterating through array

[John Maisey]

Hi,

If the items are unique, how about:

[array indexOfObject:object];

Using a counter is likely be faster though.

John Maisey

www.nhoj.co.uk
www.twitter.com/johnmaisey
www.facebook.com/nhojcouk


> Date: Wed, 07 Mar 2012 07:42:17 +1100
> From: Prime Coderama 
> To: cocoa-dev@lists.apple.com
> Subject: Finding object array index when iterating through array
> Message-ID: <85e319f7-f507-4dac-b69c-fcff7dea2...@gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
> I have an array and I am iterating through it using this technique:
>
>> for (id object in array) {
>> // do something with object
>> }
>
> Is there  way to obtain the object's current array index position or do I
> have to add a counter?
>
> 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Finding object array index when iterating through array

[J. C. Allen]

On Mar 6, 2012, at 3:42 PM, Prime Coderama wrote:

> I have an array and I am iterating through it using this technique:
> 
>> for (id object in array) {
>>// do something with object
>> }
> 
> Is there  way to obtain the object's current array index position or do I 
> have to add a counter?
> 
> Thanks in advance.

Is there a reason [array indexOfObjectIdenticalTo:object] won't work?  Is the 
same object stored in the array multiple times?

Regards,
J. C. Allen

Allen Analytical and Information Services, LLC
www.allenanalytical.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: Accessing array in thread safe way

[Brian Lambert]

No.

Assuming the property you describe is declared something like this:

@property (strong, atomic) NSMutableArray * myArray;

Then what's atomic is getting and setting the entire array.  That is
[project setMyArray:[[NSMutableArray alloc] init]]; would be atomic.

Once a caller obtains the array by calling:

NSMutableArray * theArray = [project myArray];

And starts messing with it:

[theArray someMethod];

The array contents are not protected.



On Tue, Mar 6, 2012 at 11:51 AM, Jan E. Schotsman  wrote:

> Hello,
>
> I have an array of progress values (number objects) for subprojects, from
> which I calculate the overall progress .
> The array is an atomic property of the project class.
>
> Is it safe to access this array from multiple threads, using methods like
> objectAtIndex and replaceObjectAtIndex?
>
> Jan E.
> __**_
>
> 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/**
> brianlambert%40gmail.com
>
> This email sent to brianlamb...@gmail.com
>
___

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

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

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

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

Re: Finding object array index when iterating through array

[Jens Alfke]

On Mar 6, 2012, at 6:19 PM, Marco Tabini wrote:

> [array indexOfObject:object] should do the trick, though, if you need to do 
> it at every iteration, keeping a counter may be better.

Not if the array contains objects that are equal to one another. (It’s also a 
fairly expensive method, and the running time in this context will be O(n^2).)

-indexOfObjectIdenticalTo: is slightly better but won’t work if the array 
contains multiples of the same object.

Really it’s just much better all around to use a counter.

—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

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

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

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

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

[MEET] CocoaHeadsNYC Thursday night (tonight)

[Andy Lee]

When: Thursday, March 8, 2012, 6:30-8:00 PM, followed by pizza at Patsy's.

Who: Two speakers this month: Samuel Goodwin and Bob Clair.

What: Samuel's talk will be on "Refactoring: Why you should do it, when you 
should do it, how to do it, and what to aim for." Bob will discuss a few quirks 
of ARC.

Where: Google. See our official meeting page for directions:



You might want to arrive early -- sometimes there is a delay at the security 
desk and it takes a few minutes to get your badge printed.

See you there!

--Andy

___

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

Why are 2 Terminal windows opening with NSAppleScript?

[Prime Coderama]

If no Terminal app is open, the following code opens TWO Terminal windows. Why 
is it doing this? I only want one window to open.

If only one Terminal window is open, then the following code opens only ONE 
additional window.

NSAppleScript* terminal = [[NSAppleScript alloc] initWithSource:
   [NSString stringWithFormat:
@"tell application \"Terminal\"\n"
@"activate\n"
@"do script \"echo %@\"\n"
@"tell the front window\n"
@"set title displays shell path to false\n"
@"set title displays custom title to true\n"
@"set custom title to \"My session! %@\"\n"
@"end tell\n"
@"end tell", name, name]];

[terminal executeAndReturnError:nil];
___

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: Accessing array in thread safe way

[Charles Srstka]

On Mar 6, 2012, at 1:51 PM, Jan E. Schotsman wrote:

> Hello,
> 
> I have an array of progress values (number objects) for subprojects, from 
> which I calculate the overall progress .
> The array is an atomic property of the project class.
> 
> Is it safe to access this array from multiple threads, using methods like 
> objectAtIndex and replaceObjectAtIndex?

(Resending since my original reply, written yesterday, still hasn’t posted; 
apologies if this ends up showing up twice on the list.)

It’s not; however, if you implement the KVO indexed accessors for to-many 
properties, described here:

https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/AccessorConventions.html#//apple_ref/doc/uid/20002174-178830-BAJEDEFB

and guard each accessor with a mutex, spinlock, dispatch_sync, or something 
similar, you should then be able to use -mutableArrayValueForKey: to return an 
NSMutableArray proxy that you can use like an ordinary NSMutableArray, but 
which will call your now-atomic indexed accessors to get at the contents of the 
array. Just make sure all accessors are properly thread-safe and that none of 
them return the actual ivar backing the property, and you should be fine.

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: Finding object array index when iterating through array

[Greg Parker]

On Mar 6, 2012, at 6:19 PM, Marco Tabini  wrote:
>> I have an array and I am iterating through it using this technique:
>> 
>>> for (id object in array) {
>>>   // do something with object
>>> }
>> 
>> Is there  way to obtain the object's current array index position or do I 
>> have to add a counter?
> 
> [array indexOfObject:object] should do the trick, though, if you need to do 
> it at every iteration, keeping a counter may be better.

Note that -indexOfObject: returns an object from the array that is -isEqual: to 
the parameter. This might not be the same object that you are looking at. 

-indexOfObjectIdenticalTo: would solve the -isEqual: problem, but would still 
return the wrong index if the same object were in the array twice.

You should add a counter to your for..in loop, or use a traditional counted for 
loop and -objectAtIndex:.


-- 
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: Finding object array index when iterating through array

[Eric Wing]

On 3/6/12, Prime Coderama  wrote:
> I have an array and I am iterating through it using this technique:
>
>> for (id object in array) {
>> // do something with object
>> }
>
> Is there  way to obtain the object's current array index position or do I
> have to add a counter?
>
> Thanks in advance.

If you can instead use enumerateObjectsUsingBlock:, that API will give
you the index.

[array enumerateObjectsUsingBlock:^(id object, NSUInteger index, BOOL* stop)
{
// do something with object
}];

-Eric
-- 
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
___

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: Finding object array index when iterating through array

[Stephen J. Butler]

On Tue, Mar 6, 2012 at 8:19 PM, Marco Tabini  wrote:
>> I have an array and I am iterating through it using this technique:
>>
>>> for (id object in array) {
>>>    // do something with object
>>> }
>>
>> Is there  way to obtain the object's current array index position or do I 
>> have to add a counter?
>
> [array indexOfObject:object] should do the trick, though, if you need to do 
> it at every iteration, keeping a counter may be better.

Here's a stupid question that occurred to me: do the documents
anywhere guarantee that NSFastEnumeration over an NSArray will always
return the items in order? That is, the first item returned will have
index 0, second will have index 1, etc.

I feel like the safe thing in this situation is to just revert back to
an plain old "for (;;;)" loop. You know then that the index you have
is the one for the object.

___

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

Twitter Account accountStore Permissions Dialog / Alert ...

[R]

I notice that when I call:

[[self accountStore] requestAccessToAccountsWithType:[self
accountType]
   
withCompletionHandler:^(BOOL granted, NSError *error) {

etc

}];

when the dialog is presents and asks for allow or notAllow access, my
app resigns active.  After the button push, the app resumes.  I can't
find anything in the documentation warning me of this.

Is this normal behavior?

___

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: Accessing array in thread safe way

[Don Quixote de la Mancha]

> Personally, I avoid sharing mutable data between threads if I possibly can. 
> It can quickly turn into an unholy mess.
> 
> —Jens

The key to not just safe but performant multithreaded code is to redesign your 
data structures and algorithm so that you need not synchronize at all.

Many problems do ultimately require some locking but close examination often 
yields the insight that it doesn't need to be locked in as many different 
places, to be locked for as long when it is locked at all, or locked as 
frequently.

If you start with a straightforward single threaded solution to some common 
problem, break it down into multiple threads so as to share the load among 
multiple cores then add locks where you think they are necessary you are 
unlikely to ever get all the threading bugs out.

But there are often ways to divide up the problem so that many of the locks you 
thought you needed turn out to be unnecessary.

Just acquiring a lock takes time and will require costly context switches into 
and back out of the kernel even if the acquisition succeeds. if another thread 
attempts to acquire that same lock it will totally block until the lock is 
released by it's original owner and that second thread's acquisition succeeds.  
During the time it is blocked that thread is not serving your user's needs.

If you have to wait to acquire locks too much you may find that naively 
designed threaded code is slower than well designed single threaded code, even 
on multiple cores.

If you possibly can replace locking algorithms with what are commonly but 
incorrectly called lock free algorithms.  They use Atomic Arithmetic Primitives 
provided by the CPU Instruction Set  Archetector to manage very short term 
locks on single words of memory.

If a thread performs Atomic Arithmetic on a memory word, it will still lock it 
but is guaranteed to release that lock on the very next instruction.  A second 
thread that attempts to operate Atomically on the same word will stop cold but 
only for a few clock cycles.  At least that's better than suspending the entire 
thread, which costs expensive kernel  calls and returns.

Often overlooked is the performance penalty of maintaining multicore cache 
coherency.  If you've got your locking right you won't have any discernible 
bugs but if two or more cores read or write the same cache line simultaneously 
your perfermance will be poor due to all the cache flushing so that all the 
cores maintain an identical view of memory.

To improve performance share as little data as possible, access it as 
infrequently as possible and if you access it at all, finish what you're doing 
with the shared data as quickie as you can.

The best is to find some way to order access to shared regions so that multiple 
cores tend not to access the same cache line at the same time.

This is all very vague and conceptual so it may not be clear how you need to 
revise your source so as to heed my advice.

But we have always known that hardware can go faster if we use more instances 
of it, and it is a lot easier to design a computer with two cores than it is to 
design a single core that yields useful results twice as fast.

The literature has rich discussions of concurrent processing going all the way 
back to the 1940s.  The problems you and I face today may well have been solved 
and published decades ago. Even if the algorithms were patented those patents 
may well have expired by now.

I'm sorry but I cannot recommend any reading.  I expect others on this list can.

Don Quixote de la Mancha
Software of Elegance and Beauty
http://www.dulcineatech.com/
quix...@dulcineatech.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: No indentation when displaying an icon in an NSMenuItem

[Ken Thomases]

On Mar 6, 2012, at 7:21 PM, Prime Coderama wrote:

> I am trying to add an icon to only one NSMenuItem item but it is indenting 
> the icon and text by 1 level.
> 
> I tried to set the setIndentationLevel to "0" but that doesn't work.
> 
> An example of what I am trying to achieve can be seen in the Wireless status 
> bar menu where the tickbox is displayed against the current WiFi your 
> connected to e.g. http://cl.ly/2T362b2I0f1G1O3b3G3z

That's not an icon on the menu item, per se, it's an indication of the menu 
item state.  See -setState:, setOnStateImage:, etc.

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: No indentation when displaying an icon in an NSMenuItem

[Fritz Anderson]

On 6 Mar 2012, at 7:21 PM, Prime Coderama wrote:

> An example of what I am trying to achieve can be seen in the Wireless status 
> bar menu where the tickbox is displayed against the current WiFi your 
> connected to e.g. http://cl.ly/2T362b2I0f1G1O3b3G3z

The check mark is not an icon, but a part of how menu items are drawn by 
default. You set a mark by calling [menuItem setState: NSOnState], and not 
setImage:. I'd expect that if you did set an image, it would be indented enough 
to allow space for a check mark. Compare to the Safari Bookmarks menu.

Maybe you could post a picture of how your menu looks, so we can see if the 
appearance really is off.

— 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: No indentation when displaying an icon in an NSMenuItem

[Peter Ammon]

The checkmark is the on-state image. Try calling [menuItem setState:NSOnState];

Hope this helps,
-Peter

On Mar 6, 2012, at 5:21 PM, Prime Coderama  wrote:

> I am trying to add an icon to only one NSMenuItem item but it is indenting 
> the icon and text by 1 level.
> 
> I tried to set the setIndentationLevel to "0" but that doesn't work.
> 
> An example of what I am trying to achieve can be seen in the Wireless status 
> bar menu where the tickbox is displayed against the current WiFi your 
> connected to e.g. http://cl.ly/2T362b2I0f1G1O3b3G3z
> 
> Any tips are appreciated!
> ___
> 
> 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/pammon%40apple.com
> 
> This email sent to pam...@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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: No indentation when displaying an icon in an NSMenuItem

[Seth Willits]

On Mar 6, 2012, at 5:21 PM, Prime Coderama wrote:

> I am trying to add an icon to only one NSMenuItem item but it is indenting 
> the icon and text by 1 level.
> 
> I tried to set the setIndentationLevel to "0" but that doesn't work.

Because it is 0. The gap on the left is for menu state, not images.


> An example of what I am trying to achieve can be seen in the Wireless status 
> bar menu where the tickbox is displayed against the current WiFi your 
> connected to e.g. http://cl.ly/2T362b2I0f1G1O3b3G3z

Just set the menu item's state to NSStateOn.


--
Seth Willits

___

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: UIKit-additions and class references

[Mikkel Islay]

On 7 Mar 2012, at 20:40, David Duncan wrote:

> Category additions are documented separately from the main class. For 
> example, UIKit's NSString additions are in NSString(UIStringDrawing) (which 
> you can search for in the documetnation).

Absolutely. However, it would be convenient (and helpful) if the class 
reference page made a linked reference to the appropriate addition.
(Presumably the iOS NSString reference isn't supposed to mention the Appkit 
addition .)

Mikkel
___

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: Finding object array index when iterating through array

[David Duncan]

On Mar 6, 2012, at 12:42 PM, Prime Coderama wrote:

> I have an array and I am iterating through it using this technique:
> 
>> for (id object in array) {
>>// do something with object
>> }
> 
> Is there  way to obtain the object's current array index position or do I 
> have to add a counter?


You have to add a counter. Alternatively you can use the -enumerateObjects* 
APIs on NSArray which give you an index as well as the object, and allow you to 
stop the iteration early (if you need that capability).
--
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: UIKit-additions and class references

[David Duncan]

On Mar 6, 2012, at 1:28 PM, Mikkel Islay wrote:

> Does anyone know the reason why the UIKit-additions for NSString, NSValue 
> etc. aren't mentioned in the respective class references in the Apple 
> documentation for iOS?


Category additions are documented separately from the main class. For example, 
UIKit's NSString additions are in NSString(UIStringDrawing) (which you can 
search for in the documetnation).
--
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

NSOpenPanel may not respond to setDirectoryURL?

[Howard Moon]

Hi all,

I'm really not that familiar with Objective-C and Cocoa yet, but I'm 
getting a warning for something that works fine, and I hate warnings.  The 
warning is:

'NSOpenPanel' may not respond to '-setDirectoryURL:'

I know that setDirectoryURL: is an NSSavePanel message, but NSOpenPanel 
derives from NSSavePanel, so why does it give me this warning?  As I said, it 
works fine (i.e., the open panel starts out in the folder I specified).  Is 
there a case where it WON'T work?  If not, then is there a way to prevent the 
warning?

Thanks,
Howard



___

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

Sandbox, CoreData, Spotlight

[Gerd Knops]

My sandboxed app with spotlight importer and using core data uses Record-Level 
Indexing as described here:


https://developer.apple.com/library/mac/#documentation/cocoa/Conceptual/SpotlightCoreData/Articles/recordLevel.html#//apple_ref/doc/uid/TP40008065-CH101-SW2

The importer does work, and a command line

mdfind "some search string"

lists records containing the string.

However the spotlight search from the UI (Spotlight icon at the top right of 
the screen) or in Finder does not list any records.

If I copy some records from the sandbox to somewhere else on the disk, both UI 
and Finder will show them fine.

Is there a trick to having Spotlight from the UI showing the records contained 
in the sandbox? Clearly they are being scanned (mdfind works), but they are 
excluded from UI based searches for some reason.

Or is that yet another Sandbox bug?

Thanks

Gerd




___

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: Finding object array index when iterating through array

[Nick Zitzmann]

On Mar 6, 2012, at 1:42 PM, Prime Coderama wrote:

> I have an array and I am iterating through it using this technique:
> 
>> for (id object in array) {
>>// do something with object
>> }
> 
> Is there  way to obtain the object's current array index position or do I 
> have to add a counter?


Unless you must support Leopard or iOS 3, I'd recommend using 
-enumerateObjectsUsingBlock: instead, which will give you both the object and 
its index in the array.

Nick Zitzmann



___

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: Finding object array index when iterating through array

[Fritz Anderson]

On 6 Mar 2012, at 2:42 PM, Prime Coderama wrote:

> I have an array and I am iterating through it using this technique:
> 
>> for (id object in array) {
>>// do something with object
>> }
> 
> Is there  way to obtain the object's current array index position or do I 
> have to add a counter?

• Maintain a counter.
• Use -[NSArray indexOfObject:].
• Use a conventional for loop that provides an index.

— 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: Accessing array in thread safe way

[Per Bull Holmen]

Den 14:33 7. mars 2012 skrev Per Bull Holmen  følgende:
> Den 23:48 6. mars 2012 skrev Conrad Shultz
>  følgende:
>
>> Personally, I try to the maximum extent possible to make properties be
>> of immutable types for exactly this reason.  It allows you to centralize
>> management of locking/synchronization thus wipe out a whole category of
>> potential bugs.  It also allows for, e.g., easier KVO and generally
>> simpler code.
>
> I agree. While making data graphs immutable is no guarantee of thread
> safety, it is still a good practice which (usually) can make it easier
> to achieve thread safety, performance, maintainability etc...

Sorry, I need to claridy that: It may not always be the best thing to
make entire data trees immutable, that depends on the problem at hand,
but exactly as Conrad Shultz says, make properties be of immutable
types.

Per

___

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: Accessing array in thread safe way

[Per Bull Holmen]

Den 23:48 6. mars 2012 skrev Conrad Shultz
 følgende:

> Personally, I try to the maximum extent possible to make properties be
> of immutable types for exactly this reason.  It allows you to centralize
> management of locking/synchronization thus wipe out a whole category of
> potential bugs.  It also allows for, e.g., easier KVO and generally
> simpler code.

I agree. While making data graphs immutable is no guarantee of thread
safety, it is still a good practice which (usually) can make it easier
to achieve thread safety, performance, maintainability etc...

Per

___

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: Finding object array index when iterating through array

[Mike Abdullah]

On 6 Mar 2012, at 20:42, Prime Coderama wrote:

> I have an array and I am iterating through it using this technique:
> 
>> for (id object in array) {
>>// do something with object
>> }
> 
> Is there  way to obtain the object's current array index position or do I 
> have to add a counter?

Well you could query the array for the index of the object, but that's 
potentially slow. Increment a counter yourself instead.


___

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: UIKit-additions and class references

[Mikkel Islay]

On 7 Mar 2012, at 06:10, Richard Somers wrote:

> It appears that the same NSString Class Reference documentation for the Mac 
> OS X Developer Library is also used for the iOS Developer Library. The 
> original Mac OS X documentation does not mention iOS.

No doubt that is the case. For example the Appkit equivalents of the NSString 
drawing-methods are mentioned in the its class reference in the iOS 
documentation.
I will submit a request to have the iOS documentation updated, and suggest that 
a URI to the relevant additions-document is added in.

Mikkel
___

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

Problem with refreshing NSMenuItems

[Prime Coderama]

I have an NSMenu with the following static NSMenuItems

1. NSMenuItem "Count of people" (hidden)
2. NSMenuItem  (hidden)
3. NSMenuItem 
4. NSMenuItem "Refresh List"
5. NSMenuItem 
6. NSMenuItem "Quit"

I then dynamically add n-amount of NSMenuItems between (2) and (3). This works 
great.

The problem I am having, is when I hit "Refresh", I am unsure on how to remove 
all of the dynamically added NSMenuItems from the NSMenu and add all of the new 
ones?

I am currently causing a mess using NSMenu:removeItemAtIndex.

Any suggestions?
___

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: Accessing array in thread safe way

[Preston Sumner]

On Mar 6, 2012, at 12:51 PM, Jan E. Schotsman wrote:

> Hello,
> 
> I have an array of progress values (number objects) for subprojects, from 
> which I calculate the overall progress .
> The array is an atomic property of the project class.
> 
> Is it safe to access this array from multiple threads, using methods like 
> objectAtIndex and replaceObjectAtIndex?

Apple has a "Thread Safety Summary" document with basic guidelines for using 
framework classes from multiple threads:

https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html

Preston
___

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: No indentation when displaying an icon in an NSMenuItem

[Prime Coderama]

I should have been more specific with what I wanted. The icon was in fact a 
tickbox, and the solution was to use NSMenuItem's setSate with a value of 
NSOnState

On 07/03/2012, at 12:21 PM, Prime Coderama wrote:

> I am trying to add an icon to only one NSMenuItem item but it is indenting 
> the icon and text by 1 level.
> 
> I tried to set the  to "0" but that doesn't work.
> 
> An example of what I am trying to achieve can be seen in the Wireless status 
> bar menu where the tickbox is displayed against the current WiFi your 
> connected to e.g. http://cl.ly/2T362b2I0f1G1O3b3G3z
> 
> Any tips are appreciated!

___

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: Accessing array in thread safe way

[Per Bull Holmen]

Den 23:10 6. mars 2012 skrev Marco Tabini  følgende:
> On 2012-03-06, at 2:51 PM, Jan E. Schotsman wrote:
>
>> Hello,
>>
>> I have an array of progress values (number objects) for subprojects, from 
>> which I calculate the overall progress .
>> The array is an atomic property of the project class.
>>
>> Is it safe to access this array from multiple threads, using methods like 
>> objectAtIndex and replaceObjectAtIndex?
>>
>
> NSMutableArray is not (as far as I know) thread-safe while being mutated[1]. 
> That said, it doesn't mean that you can't use the array in a multi-threaded 
> environment: Just make sure that writes are all synchronized, and that 
> enumerations only happen on immutable copies.
>
> HTH,

Perhaps OP thought that just declaring the array as an atomic property
would make it thread-safe. I believe this would happen if
getters/setters were synthesized, and the array contents was only
changed by creating a whole new array, and always replacing it using
the setter. You would typically make the array immutable for such an
approach. In general, this can be a decent way of doing things in a
multithreaded app, because time spent in synchronized code would be
minimized. But I don't know if there are Cocoa-specific reasons to
avoid it, and of course it depends on how feasible it is for the
application.

Per

___

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