Re: Crash with ARC enabled on Xcode 6.1
On 23 Oct 2014, at 00:34, Beinan Li wrote:
> Oh! I did actually.
>
> The method I posted belongs to an ObjC object which is wrapped by a C++
> object.
> That C++ object is a singleton (static).
>
> How is this going to affect ARC and why it didn't down-right crash a week ago
> before I upgraded Xcode?
I wouldn't worry about why it worked before. I don't think that helps, and if
you have any other cases they should be removed as well.
Array and dictionary literals are not evaluated at compile time but are
replaced with the objective-c calls to create the arrays and dictionaries. This
is very different to string literals.
From what I understand any code that is executed before main is called is done
so before the objective-c runtime is fully setup which means you have no
guarantees about what will work. In objective-c++ where you can create static
C++ objects that results in objective-c being called it is an easy way to make
difficult to track crashes.
I'd like confirmation from an apple engineer that my understanding is correct.
My quick perusal of the docs didn't find the info I was after.
Kevin
> Thanks,
> Beinan
>
>
> On Wed, Oct 22, 2014 at 7:00 PM, Kevin Meaney wrote:
> Your not creating a static C++ object anywhere are you? One that creates the
> dictionary before main gets called by any chance?
>
> Kevin
>
> Sent from my iPhone
>
> > On 22 Oct 2014, at 22:45, Beinan Li wrote:
> >
> > Note, the initial crashing function is merely translating a C++ enum to the
> > AVFoundation builtin constants.
> >
> > Thanks,
> > Beinan
> >
> >
> >> On Wed, Oct 22, 2014 at 5:45 PM, Beinan Li wrote:
> >>
> >> It is quite unpredictable.
> >> At first it crashes at a dictionary creation line in a .mm implementation
> >> like this:
> >>
> >> - (NSString*) getAVAudioSessionMode:(myAudioSessionMode)modeKey {
> >> NSDictionary* modeDict = @{ // Here it crashes
> >> @(myAudioSessionModeDefault): AVAudioSessionModeDefault,
> >> @(myAudioSessionModeVoiceChat): AVAudioSessionModeVoiceChat,
> >> @(myAudioSessionModeGameChat): AVAudioSessionModeGameChat,
> >> @(myAudioSessionModeVideoRecording): AVAudioSessionModeVideoRecording,
> >> @(myAudioSessionModeMeasurement): AVAudioSessionModeMeasurement,
> >> @(myAudioSessionModeMoviePlayback): AVAudioSessionModeMoviePlayback,
> >> @(myAudioSessionModeVideoChat): AVAudioSessionModeVideoChat
> >> };
> >> NSString* mode = [modeDict objectForKey:@
> >> (mySettings.audioSession.eMode)];
> >> return mode;
> >> }
> >>
> >> The backtrace gives me:
> >>
> >> * thread #1: tid = 0x2403, 0x0013148c MyDemo`-[MyImp
> >> getAVAudioSessionMode:](self=0x1e839a80, _cmd=0x002d3077,
> >> modeKey=myAudioSessionModeDefault) + 676 at MyImp.mm:78, queue =
> >> 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
> >> * frame #0:
> >> 0x0013148c MyDemo -[MyImp getAVAudioSessionMode:](self=0x1e839a80,
> >> _cmd=0x002d3077, modeKey=myAudioSessionModeDefault) + 676 at MyImp.mm:78
> >>
> >> Then if I remove this dictionary all together and do it like this:
> >>
> >> - (NSString*) getAVAudioSessionMode:(myAudioSessionMode)modeKey {
> >> return AVAudioSessionModeDefault;
> >> }
> >>
> >> Then I get a crash right in the main.mm:
> >>
> >> int retVal = UIApplicationMain(argc, argv, nil, @"MyDemoAppDelegate");
> >>
> >> backtrace:
> >>
> >> * thread #1: tid = 0x2403, 0x3c4df350
> >> libsystem_kernel.dylib`__pthread_kill + 8, queue = 'com.apple.main-thread',
> >> stop reason = signal SIGABRT
> >>frame #0: 0x3c4df350 libsystem_kernel.dylib`__pthread_kill + 8
> >>frame #1: 0x3c456122 libsystem_c.dylib`pthread_kill + 58
> >>frame #2: 0x3c492972 libsystem_c.dylib`abort + 94
> >>frame #3: 0x3ba30d4e libc++abi.dylib`abort_message + 74
> >>frame #4: 0x3ba2dff8 libc++abi.dylib`default_terminate() + 24
> >>frame #5: 0x3bfe1a
>
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post 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: Crash with ARC enabled on Xcode 6.1
Thank you Kevin!
I didn't know this before. This might be it because I did at some point
change the dictionary creation from the old API-based syntax to literals.
Maybe I should move back to the API calls. I'll try that today.
Thanks,
Beinan
On Thu, Oct 23, 2014 at 5:18 AM, Kevin Meaney wrote:
>
> On 23 Oct 2014, at 00:34, Beinan Li wrote:
>
> Oh! I did actually.
>
> The method I posted belongs to an ObjC object which is wrapped by a C++
> object.
> That C++ object is a singleton (static).
>
> How is this going to affect ARC and why it didn't down-right crash a week
> ago before I upgraded Xcode?
>
>
> I wouldn't worry about why it worked before. I don't think that helps, and
> if you have any other cases they should be removed as well.
>
> Array and dictionary literals are not evaluated at compile time but are
> replaced with the objective-c calls to create the arrays and dictionaries.
> This is very different to string literals.
>
> From what I understand any code that is executed before main is called is
> done so before the objective-c runtime is fully setup which means you have
> no guarantees about what will work. In objective-c++ where you can create
> static C++ objects that results in objective-c being called it is an easy
> way to make difficult to track crashes.
>
> I'd like confirmation from an apple engineer that my understanding is
> correct. My quick perusal of the docs didn't find the info I was after.
>
> Kevin
>
> Thanks,
> Beinan
>
>
> On Wed, Oct 22, 2014 at 7:00 PM, Kevin Meaney wrote:
>
>> Your not creating a static C++ object anywhere are you? One that creates
>> the dictionary before main gets called by any chance?
>>
>> Kevin
>>
>> Sent from my iPhone
>>
>> > On 22 Oct 2014, at 22:45, Beinan Li wrote:
>> >
>> > Note, the initial crashing function is merely translating a C++ enum to
>> the
>> > AVFoundation builtin constants.
>> >
>> > Thanks,
>> > Beinan
>> >
>> >
>> >> On Wed, Oct 22, 2014 at 5:45 PM, Beinan Li
>> wrote:
>> >>
>> >> It is quite unpredictable.
>> >> At first it crashes at a dictionary creation line in a .mm
>> implementation
>> >> like this:
>> >>
>> >> - (NSString*) getAVAudioSessionMode:(myAudioSessionMode)modeKey {
>> >> NSDictionary* modeDict = @{ // Here it crashes
>> >> @(myAudioSessionModeDefault): AVAudioSessionModeDefault,
>> >> @(myAudioSessionModeVoiceChat): AVAudioSessionModeVoiceChat,
>> >> @(myAudioSessionModeGameChat): AVAudioSessionModeGameChat,
>> >> @(myAudioSessionModeVideoRecording):
>> AVAudioSessionModeVideoRecording,
>> >> @(myAudioSessionModeMeasurement): AVAudioSessionModeMeasurement,
>> >> @(myAudioSessionModeMoviePlayback): AVAudioSessionModeMoviePlayback,
>> >> @(myAudioSessionModeVideoChat): AVAudioSessionModeVideoChat
>> >> };
>> >> NSString* mode = [modeDict objectForKey:@
>> >> (mySettings.audioSession.eMode)];
>> >> return mode;
>> >> }
>> >>
>> >> The backtrace gives me:
>> >>
>> >> * thread #1: tid = 0x2403, 0x0013148c MyDemo`-[MyImp
>> >> getAVAudioSessionMode:](self=0x1e839a80, _cmd=0x002d3077,
>> >> modeKey=myAudioSessionModeDefault) + 676 at MyImp.mm:78, queue =
>> >> 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1,
>> address=0x0)
>> >> * frame #0:
>> >> 0x0013148c MyDemo -[MyImp getAVAudioSessionMode:](self=0x1e839a80,
>> >> _cmd=0x002d3077, modeKey=myAudioSessionModeDefault) + 676 at
>> MyImp.mm:78
>> >>
>> >> Then if I remove this dictionary all together and do it like this:
>> >>
>> >> - (NSString*) getAVAudioSessionMode:(myAudioSessionMode)modeKey {
>> >> return AVAudioSessionModeDefault;
>> >> }
>> >>
>> >> Then I get a crash right in the main.mm:
>> >>
>> >> int retVal = UIApplicationMain(argc, argv, nil, @"MyDemoAppDelegate");
>> >>
>> >> backtrace:
>> >>
>> >> * thread #1: tid = 0x2403, 0x3c4df350
>> >> libsystem_kernel.dylib`__pthread_kill + 8, queue =
>> 'com.apple.main-thread',
>> >> stop reason = signal SIGABRT
>> >>frame #0: 0x3c4df350 libsystem_kernel.dylib`__pthread_kill + 8
>> >>frame #1: 0x3c456122 libsystem_c.dylib`pthread_kill + 58
>> >>frame #2: 0x3c492972 libsystem_c.dylib`abort + 94
>> >>frame #3: 0x3ba30d4e libc++abi.dylib`abort_message + 74
>> >>frame #4: 0x3ba2dff8 libc++abi.dylib`default_terminate() + 24
>> >>frame #5: 0x3bfe1a
>>
>
>
>
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post 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: Crash with ARC enabled on Xcode 6.1
Personally I'd try and not call any objective-c code from a C++ static object.
If it did look the appropriate solution then I'd make sure I was comfortable
with my knowledge of the objective-c runtime and the order in which things are
called before main is called.
Kevin
On 23 Oct 2014, at 13:02, Beinan Li wrote:
> Thank you Kevin!
> I didn't know this before. This might be it because I did at some point
> change the dictionary creation from the old API-based syntax to literals.
> Maybe I should move back to the API calls. I'll try that today.
>
> Thanks,
> Beinan
>
>
> On Thu, Oct 23, 2014 at 5:18 AM, Kevin Meaney wrote:
>
> On 23 Oct 2014, at 00:34, Beinan Li wrote:
>
>> Oh! I did actually.
>>
>> The method I posted belongs to an ObjC object which is wrapped by a C++
>> object.
>> That C++ object is a singleton (static).
>>
>> How is this going to affect ARC and why it didn't down-right crash a week
>> ago before I upgraded Xcode?
>
> I wouldn't worry about why it worked before. I don't think that helps, and if
> you have any other cases they should be removed as well.
>
> Array and dictionary literals are not evaluated at compile time but are
> replaced with the objective-c calls to create the arrays and dictionaries.
> This is very different to string literals.
>
> From what I understand any code that is executed before main is called is
> done so before the objective-c runtime is fully setup which means you have no
> guarantees about what will work. In objective-c++ where you can create static
> C++ objects that results in objective-c being called it is an easy way to
> make difficult to track crashes.
>
> I'd like confirmation from an apple engineer that my understanding is
> correct. My quick perusal of the docs didn't find the info I was after.
>
> Kevin
>
>> Thanks,
>> Beinan
>>
>>
>> On Wed, Oct 22, 2014 at 7:00 PM, Kevin Meaney wrote:
>> Your not creating a static C++ object anywhere are you? One that creates the
>> dictionary before main gets called by any chance?
>>
>> Kevin
>>
>> Sent from my iPhone
>>
>> > On 22 Oct 2014, at 22:45, Beinan Li wrote:
>> >
>> > Note, the initial crashing function is merely translating a C++ enum to the
>> > AVFoundation builtin constants.
>> >
>> > Thanks,
>> > Beinan
>> >
>> >
>> >> On Wed, Oct 22, 2014 at 5:45 PM, Beinan Li wrote:
>> >>
>> >> It is quite unpredictable.
>> >> At first it crashes at a dictionary creation line in a .mm implementation
>> >> like this:
>> >>
>> >> - (NSString*) getAVAudioSessionMode:(myAudioSessionMode)modeKey {
>> >> NSDictionary* modeDict = @{ // Here it crashes
>> >> @(myAudioSessionModeDefault): AVAudioSessionModeDefault,
>> >> @(myAudioSessionModeVoiceChat): AVAudioSessionModeVoiceChat,
>> >> @(myAudioSessionModeGameChat): AVAudioSessionModeGameChat,
>> >> @(myAudioSessionModeVideoRecording): AVAudioSessionModeVideoRecording,
>> >> @(myAudioSessionModeMeasurement): AVAudioSessionModeMeasurement,
>> >> @(myAudioSessionModeMoviePlayback): AVAudioSessionModeMoviePlayback,
>> >> @(myAudioSessionModeVideoChat): AVAudioSessionModeVideoChat
>> >> };
>> >> NSString* mode = [modeDict objectForKey:@
>> >> (mySettings.audioSession.eMode)];
>> >> return mode;
>> >> }
>> >>
>> >> The backtrace gives me:
>> >>
>> >> * thread #1: tid = 0x2403, 0x0013148c MyDemo`-[MyImp
>> >> getAVAudioSessionMode:](self=0x1e839a80, _cmd=0x002d3077,
>> >> modeKey=myAudioSessionModeDefault) + 676 at MyImp.mm:78, queue =
>> >> 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1,
>> >> address=0x0)
>> >> * frame #0:
>> >> 0x0013148c MyDemo -[MyImp getAVAudioSessionMode:](self=0x1e839a80,
>> >> _cmd=0x002d3077, modeKey=myAudioSessionModeDefault) + 676 at MyImp.mm:78
>> >>
>> >> Then if I remove this dictionary all together and do it like this:
>> >>
>> >> - (NSString*) getAVAudioSessionMode:(myAudioSessionMode)modeKey {
>> >> return AVAudioSessionModeDefault;
>> >> }
>> >>
>> >> Then I get a crash right in the main.mm:
>> >>
>> >> int retVal = UIApplicationMain(argc, argv, nil, @"MyDemoAppDelegate");
>> >>
>> >> backtrace:
>> >>
>> >> * thread #1: tid = 0x2403, 0x3c4df350
>> >> libsystem_kernel.dylib`__pthread_kill + 8, queue =
>> >> 'com.apple.main-thread',
>> >> stop reason = signal SIGABRT
>> >>frame #0: 0x3c4df350 libsystem_kernel.dylib`__pthread_kill + 8
>> >>frame #1: 0x3c456122 libsystem_c.dylib`pthread_kill + 58
>> >>frame #2: 0x3c492972 libsystem_c.dylib`abort + 94
>> >>frame #3: 0x3ba30d4e libc++abi.dylib`abort_message + 74
>> >>frame #4: 0x3ba2dff8 libc++abi.dylib`default_terminate() + 24
>> >>frame #5: 0x3bfe1a
>>
>
>
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post 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-
Within a UITableView cellForRowAtIndexPath indexPath's row and section become nil.
I just started seeing this in Xcode 5.1.1 the post few days under iOS 7. In the tableView:cellForRowAtIndexPath, you can log the indexPath and the results are not nil, but attempting to display [indexPath row] or section results in nil. My only clue here is that this VC is. Subclass of UIViewController, but the interface conforms to the tableView dataSource and delegate. Any insight into what I might be missing here? Thanks in advance. Sent from my iPad. Please pardon typos. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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: Within a UITableView cellForRowAtIndexPath indexPath's row and section become nil.
On Thu, Oct 23, 2014, at 12:25 PM, Alex Zavatone wrote: > I just started seeing this in Xcode 5.1.1 the post few days under iOS 7. > > In the tableView:cellForRowAtIndexPath, you can log the indexPath and the > results are not nil, but attempting to display [indexPath row] or section > results in nil. -row returns an NSInteger, not an object. Are you po'ing the integer by mistake? --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
Frame of views during awakeFromNib or restoration
Hi, I see a problem on several places in my app. In awakeFromNib, in restoreStateWithCoder: or just after adding a view programmatically, the bounds aren’t in sync with the final size or with the super view. The relayout is done at the end of the runloop. This was not the case in 10.7 but is now in 10.9. I think I read somewhere about that but cant find it. I have several things I need to do. One is to set the initial scroll position, another is that I want to manually restore some split views. Thanks Georg Seifert ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post 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: Crash with ARC enabled on Xcode 6.1
> On Oct 23, 2014, at 2:18 AM, Kevin Meaney wrote: > > From what I understand any code that is executed before main is called is > done so before the objective-c runtime is fully setup which means you have no > guarantees about what will work. In objective-c++ where you can create static > C++ objects that results in objective-c being called it is an easy way to > make difficult to track crashes. The situation is much more favorable than that. Problems with Objective-C initialization are uncommon. The initialization order is generally like this: 1. Everything in libraries you link to is initialized. 2. Your classes' +load methods run. Each class runs +load before its subclasses. (Timing of category +load is more complicated, but in most cases they also run now.) 3. Your C and C++ static constructors run. 4. main() Any of your code can use anything from libraries it links to without fear. Those libraries should be completely ready to go when your code runs. C/C++ static initializers can call Objective-C code without fear. (Note that if your C/C++ static initializers call your own Objective-C code which has its own C/C++ static initializers inside then you still have to worry about the traditional "static initialization order fiasco". Objective-C does not make that problem better or worse.) Objective-C +load methods need to be the most careful because they run before the C/C++ static initializers in the same executable or even in the same source file. -- 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: Crash with ARC enabled on Xcode 6.1
On Thu, Oct 23, 2014, at 05:06 PM, Greg Parker wrote: > > > On Oct 23, 2014, at 2:18 AM, Kevin Meaney wrote: > > > > From what I understand any code that is executed before main is called is > > done so before the objective-c runtime is fully setup which means you have > > no guarantees about what will work. In objective-c++ where you can create > > static C++ objects that results in objective-c being called it is an easy > > way to make difficult to track crashes. > > The situation is much more favorable than that. Problems with Objective-C > initialization are uncommon. > > The initialization order is generally like this: > 1. Everything in libraries you link to is initialized. > 2. Your classes' +load methods run. Each class runs +load before its > subclasses. (Timing of category +load is more complicated, but in most > cases they also run now.) > 3. Your C and C++ static constructors run. > 4. main() Is it accurate to say that Objective-C +initialize methods happen, at the earliest, as part of Step 3? --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: Crash with ARC enabled on Xcode 6.1
> On Oct 23, 2014, at 15:26, Kyle Sluder wrote: > > On Thu, Oct 23, 2014, at 05:06 PM, Greg Parker wrote: >> >>> On Oct 23, 2014, at 2:18 AM, Kevin Meaney wrote: >>> >>> From what I understand any code that is executed before main is called is >>> done so before the objective-c runtime is fully setup which means you have >>> no guarantees about what will work. In objective-c++ where you can create >>> static C++ objects that results in objective-c being called it is an easy >>> way to make difficult to track crashes. >> >> The situation is much more favorable than that. Problems with Objective-C >> initialization are uncommon. >> >> The initialization order is generally like this: >> 1. Everything in libraries you link to is initialized. >> 2. Your classes' +load methods run. Each class runs +load before its >> subclasses. (Timing of category +load is more complicated, but in most >> cases they also run now.) >> 3. Your C and C++ static constructors run. >> 4. main() > > Is it accurate to say that Objective-C +initialize methods happen, at > the earliest, as part of Step 3? No. +initialize is called the first time a particular class or its subclasses are sent a message (other than +load or +initialize). If you never call any methods on a class or its subclass, then that class’ +initialize will never be called. -- Clark Smith Cox III clarkc...@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: Crash with ARC enabled on Xcode 6.1
> On Oct 23, 2014, at 3:26 PM, Kyle Sluder wrote: > >> On Thu, Oct 23, 2014, at 05:06 PM, Greg Parker wrote: >> >> The initialization order is generally like this: >> 1. Everything in libraries you link to is initialized. >> 2. Your classes' +load methods run. Each class runs +load before its >> subclasses. (Timing of category +load is more complicated, but in most >> cases they also run now.) >> 3. Your C and C++ static constructors run. >> 4. main() > > Is it accurate to say that Objective-C +initialize methods happen, at > the earliest, as part of Step 3? No. If a +load method calls another method then it will provoke +initialize at that time. (This includes messages to that +load's own class.) -- 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: Crash with ARC enabled on Xcode 6.1
On Oct 23, 2014, at 10:50 AM, Kevin Meaney wrote: > > Personally I'd try and not call any objective-c code from a C++ static > object. If it did look the appropriate solution then I'd make sure I was > comfortable with my knowledge of the objective-c runtime and the order in > which things are called before main is called. The runtime is up. But of course, no run loop, no event handling. -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
