App crashing when adding to Open Recent menu

[Rico]

Hi,

For one of my users my application is always crashing when it tries to add an 
entry to the "Open Recent" menu via:

[[NSDocumentController sharedDocumentController] noteNewRecentDocumentURL: 
[NSURL fileURLWithPath:folderPath]]

He is running Mac OS X Lion Server 10.7.2. Full stack trace of the crashed 
thread below. I can't reproduce this. Has anybody seen a similar problem?

I had him set the NSRecentDocumentsLimit to 0 via the Terminal to not have 
entries added to the Open Recent menu, but the app still crashes with the same 
stack trace.

Some bug reports on the web indicate there's a "special" character in the path 
name, but in this case the path name consists of only ASCII characters.

Thanks,
Rico

_

Date/Time:   2011-12-08 16:30:08.836 +0900
OS Version:  Mac OS X Server 10.7.2 (11C74)
Report Version:  9

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0xfefff000

VM Regions Near 0xfefff000:
CG backing stores  cb439000-cb44b000 [   72K] rw-/rw- 
SM=SHM  
--> VM_ALLOCATEfefff000-ff00 [4K] rw-/rwx 
SM=COW  
Submap -2000  r-x/r-x 
process-only submap

Application Specific Information:
objc[20675]: garbage collection is OFF

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   ??? 0xfefff000 0 + 4278185984
1   com.apple.LaunchServices0x956fdbc9 
_ZL31LSPropertyProviderPrepareValuesPK7__CFURLP11__FileCachePKPK10__CFStringPPKvlSA_PP9__CFError
 + 46
2   com.apple.CoreServicesInternal  0x973fdaae 
_ZL22prepareValuesForBitmapPK7__CFURLP11__FileCacheP19_FilePropertyBitmapPP9__CFError
 + 284
3   com.apple.CoreServicesInternal  0x97408147 
_FSURLCopyResourcePropertyForKey + 181
4   com.apple.CoreFoundation0x9c749ff1 
CFURLCopyResourcePropertyForKey + 129
5   com.apple.LaunchServices0x95765144 _LSGetIconRefForURL + 67
6   com.apple.LaunchServices0x95761caf 
LSSharedFileListInsertItemURL + 364
7   com.apple.AppKit0x98633849 -[NSDocumentController 
_notePendingRecentDocumentURLsForKey:] + 2193
8   com.apple.Foundation0x97ef48ea __NSFireDelayedPerform + 615
9   com.apple.CoreFoundation0x9c74b996 
__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22
10  com.apple.CoreFoundation0x9c74b327 __CFRunLoopDoTimer + 743
11  com.apple.CoreFoundation0x9c72a3e0 __CFRunLoopRun + 1888
12  com.apple.CoreFoundation0x9c7298ec CFRunLoopRunSpecific + 332
13  com.apple.CoreFoundation0x9c729798 CFRunLoopRunInMode + 120
14  com.apple.HIToolbox 0x977b2a7f RunCurrentEventLoopInMode + 
318
15  com.apple.HIToolbox 0x977b9cc6 ReceiveNextEventCommon + 168
16  com.apple.HIToolbox 0x977b9c0a 
BlockUntilNextEventMatchingListInMode + 88
17  com.apple.AppKit0x98234040 _DPSNextEvent + 678
18  com.apple.AppKit0x982338ab -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:] + 113
19  com.apple.AppKit0x9822fc22 -[NSApplication run] + 911
20  com.apple.AppKit0x984c418a NSApplicationMain + 1054

___

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

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

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

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

Re: Locks

[Andreas Grosam]

On Dec 7, 2011, at 12:07 PM, Jean-Daniel Dupas wrote:

> 
> Le 7 déc. 2011 à 06:10, Ken Thomases a écrit :
> 
>> On Dec 6, 2011, at 10:05 PM, Don Quixote de la Mancha wrote:
>> 
>> You still shouldn't implement it manually using atomic increment and 
>> decrement.  You should use OSSpinLock if that's what you're attempting.  
>> Which was my point.  The original code was horrible and horribly misguided 
>> (and suffers from a race condition as others have pointed out, which is 
>> virtually inevitable when people try to reimplement synchronization instead 
>> of using ready-made synchronization primitives).
>> 
> 
> A better solution would be to use posix mutex and completely avoid OSSpinLock.
> There is really few situations where SpinLock give you any benefit,  as mutex 
> implementation already try to spin a couple of time before locking. So if 
> there is no contention, they are both very cheap and fast, and if there is 
> contention, the mutex is better as it don't consume CPU waiting for other 
> threads.
> 
> -- Jean-Daniel

A possibly even better solution is to use dispatch semaphores. A non-recursive 
mutex can be build upon a semaphore. A pthread mutex always requires a call 
through the kernel. Dispatch semaphores require this only when the thread needs 
to be blocked. Otherwise, a spin lock is performed in user space. 

In the case of no contention, a dispatch semaphore is much faster than a 
pthread mutex. In case of contention, performance is comparable - but extreme 
contention should be avoided and considered a programmer error.

I've successfully used dispatch semaphores and variants to implement a mutex to 
synchronize access to resources.


Well, and even yet another solution is to use dispatch queues, if possible. 
dispatch lib is open source and available on other platforms, too. But this 
would require to change the design.



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

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

Re: Locks

[Jean-Daniel Dupas]

Le 8 déc. 2011 à 09:57, Andreas Grosam a écrit :

> 
> On Dec 7, 2011, at 12:07 PM, Jean-Daniel Dupas wrote:
> 
>> 
>> Le 7 déc. 2011 à 06:10, Ken Thomases a écrit :
>> 
>>> On Dec 6, 2011, at 10:05 PM, Don Quixote de la Mancha wrote:
>>> 
>>> You still shouldn't implement it manually using atomic increment and 
>>> decrement.  You should use OSSpinLock if that's what you're attempting.  
>>> Which was my point.  The original code was horrible and horribly misguided 
>>> (and suffers from a race condition as others have pointed out, which is 
>>> virtually inevitable when people try to reimplement synchronization instead 
>>> of using ready-made synchronization primitives).
>>> 
>> 
>> A better solution would be to use posix mutex and completely avoid 
>> OSSpinLock.
>> There is really few situations where SpinLock give you any benefit,  as 
>> mutex implementation already try to spin a couple of time before locking. So 
>> if there is no contention, they are both very cheap and fast, and if there 
>> is contention, the mutex is better as it don't consume CPU waiting for other 
>> threads.
>> 
>> -- Jean-Daniel
> 
> A possibly even better solution is to use dispatch semaphores. A 
> non-recursive mutex can be build upon a semaphore. A pthread mutex always 
> requires a call through the kernel. Dispatch semaphores require this only 
> when the thread needs to be blocked. Otherwise, a spin lock is performed in 
> user space. 

> In the case of no contention, a dispatch semaphore is much faster than a 
> pthread mutex. In case of contention, performance is comparable - but extreme 
> contention should be avoided and considered a programmer error.

This is the same for pthread_mutex. They require a call though the kernel only 
if they have to wait and spin in user space if not. And they are more flexible 
(support recursive lock for example).
Of course, this additional flexibility has a cost, and locking/unlocking is 2 
times slower with mutex, but they remain so fast that even in a tight loop, the 
difference is negligible.

The primitive you're talking about and that require a "syscall" (a mach message 
to be exact) is the mach_semaphore. It is almost 10 times slower than 
dispatch_semaphore.

> I've successfully used dispatch semaphores and variants to implement a mutex 
> to synchronize access to resources.
> 
> 
> Well, and even yet another solution is to use dispatch queues, if possible. 
> dispatch lib is open source and available on other platforms, too. But this 
> would require to change the design.
> 
> 
> 
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org
> 
> This email sent to devli...@shadowlab.org

-- Jean-Daniel




___

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

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

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

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

Re: "byte orders" question

[Sean McBride]

On Sat, 26 Nov 2011 16:23:47 -0800, Kyle Sluder said:

>> Since you're just doing a memcpy(), you can simply cast the bits and avoid
>> the copying.  Try this:
>>
>> float f = *((float*) &res);
>>
>> Or try defining a C union:
>>
>> union foo {  float f;  u_int32_t u;  };
>> union foo bar;
>> bar.u = CFSwapInt32HostToBig(value);
>> float f = bar.f;
>
>Neither of these is legal. You are not allowed to alias a pointer to
>two different types (except pointer-to-char). See Section 6.5,
>paragraph 7 of the C99 standard:
>http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

(My reply is late, but...)

Strangely, there is no CF version, but there is NSSwapBigDoubleToHost() and 
variants, which are more expressive that the trickery above.

As Kyle says, don't cast float* to int* (or variations), you see everyone doing 
it, but it's illegal.  The union strategy is dubious too, but in practice 
safer.  Looking in NSByteOrder.h you see it is the technique used by 
NSSwapBigDoubleToHost() and variants.

Cheers,

--

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

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

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

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

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

Re: "byte orders" question

[Scott Ribe]

On Dec 8, 2011, at 8:45 AM, Sean McBride wrote:

> The union strategy is dubious too, but in practice safer.

It's neither illegal nor dubious. It's explicitly allowed.

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




___

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

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

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

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

NSIndexSet of NSButtonCells in NSOutlineView

[Gilles Celli]

Hi,

I've the following problem:

I'm writing an application which will display plots / graph: an NSOutlineView 
has been setup and working which displays the name, location
of some scientific instruments (like thermometer, voltage etc.).

The instrument's name is selectable as an NSButtonCell, the idea is to turn 
on/off its respective graph / plot.
So there's a mix of NSButtonCells along with NSString in the NSOutlineView.
My model's NSButtonCells are based of NSMutableDictionary which will change the 
integerValue of NSButton for their resp. key, this works.

I've setup an NSArray to store the selected instruments.
In fact I've problems creating the NSIndexSet of the selected instruments and 
not knowing where to put the whole code.

Should I put the code in
In outlineView: objectValueForTableColumn:byItem:(id)item or in 
outlineView:setObjectValue:forTableColumn:byItem:  ?

Putting it in the NSOutlineView notification method 
-(void)outlineViewSelectionDidChange:(NSNotification *)notification is bad idea 
(I think) since then
the NSButtons are only changing their state if the row of the NSOutlineView is 
highlighted / selected. 

I want to have the user change the state of the buttons whithout first 
selecting the row of the outlineview.

So should I alway recreate a new NSIndexSet for the selected NSButtonCells ? If 
yes in which method should I put the code ?

Maybe there's a more elegant solution to this….any clues ?

Any help is greatly appreciated.

Cheers,

Gilles


___

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

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

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

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

Re: iOS: How to hide blue personal hotspot status bar?

[Mike Abdullah]

http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIApplication_Class/Reference/Reference.html#//apple_ref/occ/instm/UIApplication/setStatusBarHidden:withAnimation:

On 7 Dec 2011, at 23:40, Eagle Offshore wrote:

> Angry Birds does it so it must be possible.  So how can I do this as well?  I 
> need my app to truly take over the entire iPhone screen with no distractions 
> and no dangerous hit area that can take the user out of my app by accident.
> 
> Thanks
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: ARC and dealloc

[Matt Neuburg]

On Wed, 07 Dec 2011 21:56:56 +0100, Mikkel Islay 
 said:
>Dear list,
>
>A question regarding the proper use of dealloc in ARC-environments (under iOS):
>I have a need to unregister NSNotification observers during exchange of 
>UiViewControllers. Is implementing - (void)dealloc considered a proper use for 
>this purpose? Is it safe to make assumptions regarding when in the 
>release-process dealloc is called?

You can certainly make assumptions about when dealloc is called - it is 
extremely deterministic, actually. See Greg Parker's discussion (in the WWDC 
2011 videos) of the order in which things happen as an object goes out of 
existence.

However, that doesn't necessarily make dealloc a good place to unregister 
observers. You should certainly use dealloc as a backstop - in other words, 
even under ARC, you should always unregister observers there just in case. But, 
in particular, if you are using a block when you register, the notification 
center is retaining the block and, if the block mentions self or any ivar, the 
block is retaining you. That's a retain cycle, and it won't be broken until you 
break it by unregistering the observer you were handed when you registered. 
This means that if you unregister only in dealloc, dealloc will never be called 
and you will leak.

I have discussed this problem and provided some solutions in the draft of the 
new edition of my iOS programming book:

   http://www.apeth.com/iOSBook/ch12.html#_memory_management

Here's a thumbnail sketch from a response I posted on stackoverflow (it was 
down-marked by some reader, but I don't see why - no comment explains the 
downmark, and simple experimentation proves that what I'm saying is true):

When you issue addObserverForName: you must capture the returned value; this is 
the observer token. You store this somewhere (e.g. an instance variable):

self->observer = [[NSNotificationCenter defaultCenter] 
addObserverForName:@"woohoo" object:nil queue:nil 
usingBlock:^(NSNotification *note) 
{
//whatever
}];

Later, when you're going out of existence, you remove that observer token from 
the notification center by calling removeObserver: with that token as argument. 
If you don't do that, you can crash later.

[[NSNotificationCenter defaultCenter] removeObserver:self->observer];

But under ARC, when the block is copied, you'll get a retain cycle. This is 
because the stored observer token contains the block and is itself retaining 
self (and both the notification center and now, apparently, you are retaining 
the observer token). I will give three ways to break this retain cycle:

(a) Store the observer token as a weak reference:

__weak id observer;

(b) Store the observer token as a strong reference, but explicitly release it 
(by nilifying it) when you remove the observer:

[[NSNotificationCenter defaultCenter] removeObserver:self->observer];
self->observer = nil; // crucial

(c) Do the "weak-strong dance", like this, when you create the block (I am 
pretending that self is a FlipsideViewController):

__weak FlipsideViewController* wself = self;
observer = [[NSNotificationCenter defaultCenter] 
 addObserverForName:@"user.login" 
 object:nil queue:nil usingBlock:^(NSNotification *note) {
FlipsideViewController* sself = wself;
[sself dismissModalViewControllerAnimated:YES];
}];

Now, you might think that the "weak-strong dance" is an extreme approach,. But 
it has one huge advantage: it is the only one of these three solutions that 
allows you to remove the observer in dealloc. With the other two solutions, 
dealloc will never be called until after you have called removeObserver: - and 
finding a better place to call it may not be easy.

m.

PS In the case of a view controller on iOS, I usually register in viewDidAppear 
and unregister in viewWillDisappear. But you still have to use one of these 
solutions to make sure the observer isn't also retained by self, or you'll leak.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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

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

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

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

Re: App crashing when adding to Open Recent menu

[Jerry Krinock]

I've not experienced this crash, but the call stack of your crash includes 
these lines. 

4   com.apple.CoreFoundation CFURLCopyResourcePropertyForKey
5   com.apple.LaunchServices _LSGetIconRefForURL
6   com.apple.LaunchServices LSSharedFileListInsertItemURL

The declaration of LSSharedFileListInsertItemURL() is at:

/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Headers/LSSharedFileList.h

LSSharedFileListInsertItemURL() takes seven parameters, one of which is an icon.

I conclude that the the problem your user is having is because the file that is 
being added to Recents has a bad, missing, or otherwise strange icon.

___

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

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

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

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

Re: NSIndexSet of NSButtonCells in NSOutlineView

[Quincey Morris]

On Dec 8, 2011, at 08:12 , Gilles Celli wrote:

> The instrument's name is selectable as an NSButtonCell, the idea is to turn 
> on/off its respective graph / plot.
> So there's a mix of NSButtonCells along with NSString in the NSOutlineView.
> My model's NSButtonCells are based of NSMutableDictionary which will change 
> the integerValue of NSButton for their resp. key, this works.
> 
> I've setup an NSArray to store the selected instruments.
> In fact I've problems creating the NSIndexSet of the selected instruments and 
> not knowing where to put the whole code.

Your question is unclear. Because we're talking about a NSOutlineView, 
"selected" means what you're calling "highlighted" below. It's better not to 
use "selected" to refer to the on/off state of your button cells. Let's call 
that "active".

> Should I put the code in
> In outlineView: objectValueForTableColumn:byItem:(id)item or in 
> outlineView:setObjectValue:forTableColumn:byItem:  ?

If you're trying to maintain a NSArray of "active" instruments, the correct 
place would be outlineView:setObjectValue:forTableColumn:byItem:, since that's 
the point at which you get told of the change of state.

> Putting it in the NSOutlineView notification method 
> -(void)outlineViewSelectionDidChange:(NSNotification *)notification is bad 
> idea (I think) since then
> the NSButtons are only changing their state if the row of the NSOutlineView 
> is highlighted / selected. 
> 
> I want to have the user change the state of the buttons whithout first 
> selecting the row of the outlineview.
> 
> So should I alway recreate a new NSIndexSet for the selected NSButtonCells ? 
> If yes in which method should I put the code ?

I'm not sure what the NSIndexSet is for. Do you mean "selected" or "active"?

___

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

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

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

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

Re: ARC and dealloc

[Mikkel Islay]

Thanks for the insightful reply, and of course to Jonny Yu and Scott Anguish as 
well.

On 8 Dec 2011, at 17:36, Matt Neuburg wrote:

>> You can certainly make assumptions about when dealloc is called - it is 
>> extremely deterministic, actually. See Greg Parker's discussion (in the WWDC 
>> 2011 videos) of the order in which things happen as an object goes out of 
>> existence.

Indeed I will.
..

> 
>> PS In the case of a view controller on iOS, I usually register in 
>> viewDidAppear and unregister in viewWillDisappear. But you still have to use 
>> one of these solutions to make sure the observer isn't also retained by 
>> self, or you'll leak.

That was I ended up implementing as well.
A twist on the tale, is that the observer wasn't the UIViewController, but a 
helper object subclassed from NSObject. Hence view-unloading was one step 
further removed from deallocation of the observer-instance. 

/Mikkel Islay

___

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

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

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

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

Re: Locks

[Sean McBride]

On Tue, 6 Dec 2011 20:05:34 -0800, Don Quixote de la Mancha said:

>It is a common misconception that the "volatile" keyword is necessary
>or even helpful to code the implements locks and atomic operations.

Indeed.  A nice discussion of this is here:



--

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer  Montréal, Québec, Canada


___

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

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

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

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

Re: ARC and dealloc

[Matt Neuburg]

On Thu, 08 Dec 2011 20:31:51 +0100, Mikkel Islay 
 said:
>A twist on the tale, is that the observer wasn't the UIViewController, but a 
>helper object subclassed from NSObject. Hence view-unloading was one step 
>further removed from deallocation of the observer-instance. 

I have *never* added or removed any object other than self in the notification 
center. I would rather rearchitect some other aspect of my app to get messages 
passed around than break this rule.

Actually, I did it once and became hopelessly confused: my notification was 
never arriving and I didn't know why, and I couldn't easily find out because 
you can't query the notification center as to what observers it's got 
registered. Eventually it turned out that some other object was unregistering 
me behind my back. So since that day I have followed the above rule and have 
been a happy camper. I'm not saying it isn't possible, I'm not saying you 
shouldn't do it, I'm just saying. :) m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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

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

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

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

Re: NSIndexSet of NSButtonCells in NSOutlineView

[Gilles Celli]

Ok as you suggested it's better to call it active Buttons in the OutlineView 
then selected...

For the NSIndexSet: let's say that I've 3 ore more NSButtonCells, if only one 
is active then it will display only one Graph, if it has 2 activated let's say 
the first and last one both resp. graphs will be displayed and so on.

For example NSTableView / NSOutlineView method  (NSIndexSet 
*)selectedRowIndexes is useful if a user selects / unselects multiple rows.
However in my case I've a bunch of NSButtonCells which can be activated / 
deactivated without selecting / deselecting the outlineview multiple rows...the 
difference is that to have the multiple rows activated a user
must press the SHIFT key... with a bunch of NSButtonCells this is not necessary.
So the question is: how do I detect which set if NSButtonCells are active ? 

I hope that my explanation are a little bit more clear now ...

Gilles

On 8 déc. 2011, at 19:13, Quincey Morris wrote:

> On Dec 8, 2011, at 08:12 , Gilles Celli wrote:
> 
>> The instrument's name is selectable as an NSButtonCell, the idea is to turn 
>> on/off its respective graph / plot.
>> So there's a mix of NSButtonCells along with NSString in the NSOutlineView.
>> My model's NSButtonCells are based of NSMutableDictionary which will change 
>> the integerValue of NSButton for their resp. key, this works.
>> 
>> I've setup an NSArray to store the selected instruments.
>> In fact I've problems creating the NSIndexSet of the selected instruments 
>> and not knowing where to put the whole code.
> 
> Your question is unclear. Because we're talking about a NSOutlineView, 
> "selected" means what you're calling "highlighted" below. It's better not to 
> use "selected" to refer to the on/off state of your button cells. Let's call 
> that "active".
> 
>> Should I put the code in
>> In outlineView: objectValueForTableColumn:byItem:(id)item or in 
>> outlineView:setObjectValue:forTableColumn:byItem:  ?
> 
> If you're trying to maintain a NSArray of "active" instruments, the correct 
> place would be outlineView:setObjectValue:forTableColumn:byItem:, since 
> that's the point at which you get told of the change of state.
> 
>> Putting it in the NSOutlineView notification method 
>> -(void)outlineViewSelectionDidChange:(NSNotification *)notification is bad 
>> idea (I think) since then
>> the NSButtons are only changing their state if the row of the NSOutlineView 
>> is highlighted / selected. 
>> 
>> I want to have the user change the state of the buttons whithout first 
>> selecting the row of the outlineview.
>> 
>> So should I alway recreate a new NSIndexSet for the selected NSButtonCells ? 
>> If yes in which method should I put the code ?
> 
> I'm not sure what the NSIndexSet is for. Do you mean "selected" or "active"?
> 

___

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

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

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

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

NSNetService getInputStream:outputStream: and ARC

[Martin Linklater]

Hi - I'm writing some OSX NSNetService code with ARC enabled, and I'm getting 
the following compile error with the following code:

@property(strong) NSInputStream* inputStream;
@property(strong) NSOutputStream* outputStream;

- (void)netServiceDidResolveAddress:(NSNetService *)sender
{
[sender getInputStream:&_inputStream outputStream:&_outputStream]; 
<===ERROR
}

The error is:

'Passing address of non-local object to __autoreleasing parameter for 
write-back'

I'm a bit stumped as to what I need to do to get this compiling... can anyone 
help at all ?

Thanks.___

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

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

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

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

Re: NSNetService getInputStream:outputStream: and ARC

[John Pannell]

Some insights here - hope it helps!

http://developer.apple.com/library/ios/#qa/qa1546/_index.html#//apple_ref/doc/uid/DTS40011324

John

On Dec 8, 2011, at 3:11 PM, Martin Linklater wrote:

> Hi - I'm writing some OSX NSNetService code with ARC enabled, and I'm getting 
> the following compile error with the following code:
> 
> @property(strong) NSInputStream* inputStream;
> @property(strong) NSOutputStream* outputStream;
> 
> - (void)netServiceDidResolveAddress:(NSNetService *)sender
> {
>   [sender getInputStream:&_inputStream outputStream:&_outputStream]; 
> <===ERROR
> }
> 
> The error is:
> 
> 'Passing address of non-local object to __autoreleasing parameter for 
> write-back'
> 
> I'm a bit stumped as to what I need to do to get this compiling... can anyone 
> help at all ?
> 
> Thanks.___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/john%40positivespinmedia.com
> 
> This email sent to j...@positivespinmedia.com

___

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

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

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

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

Re: NSNetService getInputStream:outputStream: and ARC

[Ken Thomases]

On Dec 8, 2011, at 4:11 PM, Martin Linklater wrote:

> Hi - I'm writing some OSX NSNetService code with ARC enabled, and I'm getting 
> the following compile error with the following code:
> 
> @property(strong) NSInputStream* inputStream;
> @property(strong) NSOutputStream* outputStream;
> 
> - (void)netServiceDidResolveAddress:(NSNetService *)sender
> {
>   [sender getInputStream:&_inputStream outputStream:&_outputStream]; 
> <===ERROR
> }
> 
> The error is:
> 
> 'Passing address of non-local object to __autoreleasing parameter for 
> write-back'
> 
> I'm a bit stumped as to what I need to do to get this compiling... can anyone 
> help at all ?

Create two local variables, pass the addresses of them to the the method, then 
assign their values to the ivars after it returns.

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

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

Re: NSNetService getInputStream:outputStream: and ARC

[Martin Linklater]

Thanks Ken - that did the trick.

On 8 Dec 2011, at 22:17, Ken Thomases wrote:

> On Dec 8, 2011, at 4:11 PM, Martin Linklater wrote:
> 
>> Hi - I'm writing some OSX NSNetService code with ARC enabled, and I'm 
>> getting the following compile error with the following code:
>> 
>> @property(strong) NSInputStream* inputStream;
>> @property(strong) NSOutputStream* outputStream;
>> 
>> - (void)netServiceDidResolveAddress:(NSNetService *)sender
>> {
>>  [sender getInputStream:&_inputStream outputStream:&_outputStream]; 
>> <===ERROR
>> }
>> 
>> The error is:
>> 
>> 'Passing address of non-local object to __autoreleasing parameter for 
>> write-back'
>> 
>> I'm a bit stumped as to what I need to do to get this compiling... can 
>> anyone help at all ?
> 
> Create two local variables, pass the addresses of them to the the method, 
> then assign their values to the ivars after it returns.
> 
> Cheers,
> 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Strange behivor when our document-based Cocoa application launch on lion

[qiang zhu]

Hello group,

Our application use document-based architecture and works well on snow
leopard, below are the call sequences:
1, when user launch our application, our application's delegate's method "-
applicationOpenUntitledFile:" is called.
2, when user double click a document which our application can recognize,
our application's delegate's method "- application:openFiles:" is called.

But when on lion, those sequences are changed:
1, when user launch our application, NSDocumentController's
"openDocumentWithContentsOfURL:display:completionHandler" is called, and
the last opened document's path is passed into this method. Our
application's delegate's method "- applicationOpenUntitledFile:"
 will never be called.
2, when user double click a document which our application can recognize,
again, NSDocumentController's
"openDocumentWithContentsOfURL:display:completionHandler" is firstly
called, then our application's delegate's method "- application:openFiles:"
is called.

I also found that this strange behivor is only occured when I quit our
application using cmd+q, if I quit our application using cmd+w or by
closing the main window, everything is normal again.

Can anyone tell the cause or any cue to find the root cause will be
appreciated.

Thanks

Qiang
___

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

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

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

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

Singletons with ARC

[Ben]

I'm rather confused by the commonly used implementation of singletons. 
(Ignoring the fact that perhaps I shouldn't be using singletons) I would 
appreciate you view on this…

Normally I implement a singleton such as..

static MyClass *sharedInstance = nil;
+ (MyClass *)sharedInstance
{
@synchronized(self)
{
if (sharedInstance == nil)
sharedInstance = [[self alloc] init];
}
return(sharedInstance);
}

This has fared me well over the years.

With the introduction of ARC, I assumed there might be a more suitable 
implementation out there, and I found this common snippet of code commonly on 
the net…

+ (MyClass *)sharedInstance
{
static MyClass *sharedInstance = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
sharedInstance = [[MyClass alloc] init];
// Do any other initialisation stuff here
});
return sharedInstance;
}

Which confuses me because surely it should look more like…

static MyClass *sharedInstance = nil;
+ (MyClass *)sharedInstance
{
if(sharedInstance==nil){
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
sharedInstance = [[MyClass alloc] init];
// Do any other initialisation stuff here
});
}
return sharedInstance;
}

...else otherwise the second time I access the singleton, MyClass * 
sharedInstance is declared a second time and set to nill, removing the first 
instance from memory under ARC?___

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

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

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

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

RE: Singletons with ARC

[Abdul Sowayan]

Hi Ben,
 
>I'm rather confused by the commonly used implementation of singletons. 
>(Ignoring the fact that perhaps I shouldn't be using singletons) I would 
>appreciate you view on this.
>
>Normally I implement a singleton such as..
>
>static MyClass *sharedInstance = nil;
>+ (MyClass *)sharedInstance
>{
>   @synchronized(self)
>{
>   if (sharedInstance == nil)
>   sharedInstance = [[self alloc] init];
>   }
>   return(sharedInstance);
>}

The above will still work in an ARC environment. It is rather inefficient, 
however. For details please check the "Double Check Locking Optimization 
pattern":
http://www.cs.wustl.edu/~schmidt/PDF/DC-Locking.pdf

The reason it is inefficient is that locking (mutexes, or @synchronized above) 
is expensive. And you incur that expense every single time you call 
sharedInstance method.

A better way to write that method is below:


+ (MyClass *)sharedInstance
{
  static MyClass *sharedInstance = nil;

  if(sharedInstance == nil)
  {
@synchronized(self)
{
  if (sharedInstance == nil)
  sharedInstance = [[self alloc] init];
}
  }

  return sharedInstance;
}

The above is a lot more efficient. It does not incur the cost of locking 
(mutex, or @synchronized) every single time. It is thread safe. Read the paper 
for detailed analysis.

>This has fared me well over the years.
>
>With the introduction of ARC, I assumed there might be a more suitable 
>implementation out there, and I found this common snippet of code commonly on 
>the net.
>
>+ (MyClass *)sharedInstance
>{
>static MyClass *sharedInstance = nil;
>   static dispatch_once_t onceToken;
>dispatch_once(&onceToken, ^{
>sharedInstance = [[MyClass alloc] init];
>// Do any other initialisation stuff here
>});
>return sharedInstance;
>}

Yes, the above looks correct.

>Which confuses me because surely it should look more like.
>
>static MyClass *sharedInstance = nil;
>+ (MyClass *)sharedInstance
>{
>   if(sharedInstance==nil){
>static dispatch_once_t onceToken;
>dispatch_once(&onceToken, ^{
>sharedInstance = [[MyClass alloc] init];
>// Do any other initialisation stuff here
>});
>}
>return sharedInstance;
>}
>
>...else otherwise the second time I access the singleton, MyClass * 
>sharedInstance is declared a second time and set to nill, removing the first 
>instance from memory under ARC?

No, the second time sharedInstance is called it will NOT be set to nil. This is 
more of a C/C++ detail. It will not be set to nil again because the variable is 
static.


try the following in Xcode and you will see :-)

-(void) callMe
{
  static int i = 0;

  NSLog(@"value before increment is: %d, i);

  ++i;

  NSLog(@"value after increment is: %d, i);
}

Invoke "callMe" several times and you will see that it keeps incrementing i. So 
you will see


value before increment is: 0
value after increment is: 1
value before increment is: 1
value after increment is: 2
value before increment is: 2
value after increment is: 3

Thanks,
Abdul
___

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

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

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

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

Re: Strange behivor when our document-based Cocoa application launch on lion

[Jerry Krinock]

On 2011 Dec 08, at 02:54, qiang zhu wrote:

> Can anyone tell the cause or any cue to find the root cause will be
> appreciated.

A lot change in Lion.  Read the section titled

"NSDocumentController Asynchronous Opening and Reopening"

in the Mac OS X Lion AppKit Release Notes, currently at

http://developer.apple.com/library/mac/#releasenotes/Cocoa/AppKit.html

(until Apple moves it)

The header file they refer you to for details, AppKit/NSDocumentController.h, 
is in your /Developer directory installed by Xcode 4.

___

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

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

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

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

Re: Singletons with ARC

[Ken Thomases]

On Dec 8, 2011, at 11:18 PM, Abdul Sowayan wrote:

> Hi Ben,
> 
>> I'm rather confused by the commonly used implementation of singletons. 
>> (Ignoring the fact that perhaps I shouldn't be using singletons) I would 
>> appreciate you view on this.
>> 
>> Normally I implement a singleton such as..
>> 
>> static MyClass *sharedInstance = nil;
>> + (MyClass *)sharedInstance
>> {
>>  @synchronized(self)
>>   {
>>  if (sharedInstance == nil)
>>  sharedInstance = [[self alloc] init];
>>  }
>>  return(sharedInstance);
>> }
> 
> The above will still work in an ARC environment. It is rather inefficient, 
> however. For details please check the "Double Check Locking Optimization 
> pattern":
> http://www.cs.wustl.edu/~schmidt/PDF/DC-Locking.pdf

Double-checked locking is broken.  It is an anti-pattern in many languages, 
including the C family under most common implementations.  Don't use it.  
Google it if you want to confirm.  One reference: 
.

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

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

Re: NSIndexSet of NSButtonCells in NSOutlineView

[Graham Cox]

On 09/12/2011, at 8:22 AM, Gilles Celli wrote:

> how do I detect which set if NSButtonCells are active ?


You need to track that in your dataSource, NSOutlineView will not do it for you.

As Quincey suggested, when your dataSource method 
-outlineView:setObjectValue:forTableColumn:byItem: is invoked, you have all the 
necessary information about the new state of that item. You dataSource uses 
that information to track the states - in this case if it has a 
NS(Mutable)IndexSet, you would figure out which index the item corresponds to 
and set or clear that index according to the objectValue of the item.


--Graham___

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

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

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

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

Re: Singletons with ARC

[Uli Kusterer]

On 09.12.2011, at 07:55, Ken Thomases wrote:
> On Dec 8, 2011, at 11:18 PM, Abdul Sowayan wrote:
>> The above will still work in an ARC environment. It is rather inefficient, 
>> however. For details please check the "Double Check Locking Optimization 
>> pattern":
>> http://www.cs.wustl.edu/~schmidt/PDF/DC-Locking.pdf
> 
> Double-checked locking is broken.  It is an anti-pattern in many languages, 
> including the C family under most common implementations.  Don't use it.  
> Google it if you want to confirm.  One reference: 
> .


 Is this an issue that just exists when you want to write against ANSI C, or is 
this an actual, practical concern when writing on the Mac, for MacOS or iOS? 
Does anyone have information on the actual memory model implemented in Mac C, 
ObjC and C++ compilers that reinforce this?

 Just trying to figure out whether I have to change a lot of existing Mac and 
iOS code now, or whether it suffices to be aware of the problem and not write 
it in new code and stuff that gets ported.

Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de



___

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

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

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

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

Re: Singletons with ARC

[Charles Srstka]

On Dec 9, 2011, at 1:11 AM, Uli Kusterer wrote:

> On 09.12.2011, at 07:55, Ken Thomases wrote:
>> On Dec 8, 2011, at 11:18 PM, Abdul Sowayan wrote:
>>> The above will still work in an ARC environment. It is rather inefficient, 
>>> however. For details please check the "Double Check Locking Optimization 
>>> pattern":
>>> http://www.cs.wustl.edu/~schmidt/PDF/DC-Locking.pdf
>> 
>> Double-checked locking is broken.  It is an anti-pattern in many languages, 
>> including the C family under most common implementations.  Don't use it.  
>> Google it if you want to confirm.  One reference: 
>> .
> 
> 
> Is this an issue that just exists when you want to write against ANSI C, or 
> is this an actual, practical concern when writing on the Mac, for MacOS or 
> iOS? Does anyone have information on the actual memory model implemented in 
> Mac C, ObjC and C++ compilers that reinforce this?
> 
> Just trying to figure out whether I have to change a lot of existing Mac and 
> iOS code now, or whether it suffices to be aware of the problem and not write 
> it in new code and stuff that gets ported.

Why not just use dispatch_once?

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

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

Re: Safari downloader-like behavior

[Nick]

Thanks.
And to have Lion Safari's download box like behavior I have to
implement everything by myself?  I am just wondering how difficult
would it be. It seems to be a very customized NSTableView.
There's no existing components at the moment?


2011/12/7 John Joyce :
> That is weird. Calling that a download is going to confuse users and promote 
> confusion.
> Copying a file from a local mounted drive is copying, maybe installing.
> That said,
> Uli Kulsterer has a control similar to The pre-lion Safari downloads window.
> Safari lion just puts it in an annoying popover window.
>
> Sent from my iPad
>
> On Dec 6, 2011, at 11:25 PM, Nick  wrote:
>
>> Hi
>> I am writing an application, that should behave (and look) like Safari
>> downloader, but "download" files from a flash drive to a folder. I was
>> guessing that an interface similar to "Downloads" would help users to
>> feel more comfortable. Just wondering if there's any third-party
>> "downloads" control exists.
>> Thank you
>> ___
>>
___

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

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

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

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

Re: Singletons with ARC

[Ken Thomases]

On Dec 9, 2011, at 1:11 AM, Uli Kusterer wrote:

> On 09.12.2011, at 07:55, Ken Thomases wrote:
>> 
>> Double-checked locking is broken.  It is an anti-pattern in many languages, 
>> including the C family under most common implementations.  Don't use it.  
>> Google it if you want to confirm.  One reference: 
>> .
> 
> Is this an issue that just exists when you want to write against ANSI C, or 
> is this an actual, practical concern when writing on the Mac, for MacOS or 
> iOS?

It is an actual, practical concern.  The compilers can re-order memory 
accesses.  The CPU can, too.

The second and subsequent threads through the double-checked lock can see the 
singleton pointer as non-nil, but the pointed-to object may not be valid.  Its 
content may not have been written to memory, yet.

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

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