Re: Math.h functions with CGFloat

2010-08-10 Thread Quincey Morris 
On Aug 10, 2010, at 14:00, Michael Ash wrote:

> All operators with floating-point arguments must be performed with
> double precision. However, the C spec operates according to the
> "as-if" rule. The compiler is free to generate ANY code it wishes so
> long as the result is the same "as if" it were performed as the spec
> dictates. So in short, as long as your CPU's FPU does accurate 32-bit
> float calculations (and they usually do), the compiler can take
> something like this:
> 
> floata = floatb * floatc;
> 
> And compile it into code that does not ever promote to double, and
> still adhere to the standard.

Here's where I was going with this:

Although the above might be provably identical (given the CPU/FPU architecture) 
to the spec-mandated calculation:

floata = (double) floatb * (double) floatc;

the following are not identical to each other numerically:

floata = atan (floatb) * atan (floatc);
floata = atanf (floatb) * atanf (floatc);

Therefore, switching from the double to the float versions of math.h functions 
*for the purpose of eliminating compiler warnings about the size of the 
variables* is slightly risky numerically, in a way that depends on the details 
of the expression being calculated. 99 times out 100 in general purpose 
programming the difference is irrelevant, but there is a potential danger.

I was just trying to make explicit the OP's unstated semi-premise that there's 
no numerical issue 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Math.h functions with CGFloat

2010-08-10 Thread Rick Mann 
Thanks. When I did the in-Xcode file search, it didn't turn up, so I was 
curious.

On Aug 10, 2010, at 14:15:03, Nick Zitzmann wrote:

> 
> On Aug 10, 2010, at 3:06 PM, Rick Mann wrote:
> 
>> Is  available on iOS? (I have code shared among platforms.)
> 
> Yes:
> 
> % find /Developer/Platforms/iPhoneOS.platform -name 'tgmath.h'
> [...]
> /Developer/Platforms/iPhoneOS.platform/Developer/usr/lib/clang/1.5/include/tgmath.h
> /Developer/Platforms/iPhoneOS.platform/Developer/usr/lib/gcc/arm-apple-darwin10/4.0.1/include/tgmath.h
> /Developer/Platforms/iPhoneOS.platform/Developer/usr/lib/gcc/arm-apple-darwin10/4.0.1/install-tools/include/tgmath.h
> /Developer/Platforms/iPhoneOS.platform/Developer/usr/lib/gcc/arm-apple-darwin10/4.2.1/include/tgmath.h
> /Developer/Platforms/iPhoneOS.platform/Developer/usr/lib/gcc/arm-apple-darwin10/4.2.1/install-tools/include/tgmath.h
> [...]
> 
> 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Math.h functions with CGFloat

2010-08-10 Thread Nick Zitzmann 

On Aug 10, 2010, at 3:06 PM, Rick Mann wrote:

> Is  available on iOS? (I have code shared among platforms.)

Yes:

% find /Developer/Platforms/iPhoneOS.platform -name 'tgmath.h'
[...]
/Developer/Platforms/iPhoneOS.platform/Developer/usr/lib/clang/1.5/include/tgmath.h
/Developer/Platforms/iPhoneOS.platform/Developer/usr/lib/gcc/arm-apple-darwin10/4.0.1/include/tgmath.h
/Developer/Platforms/iPhoneOS.platform/Developer/usr/lib/gcc/arm-apple-darwin10/4.0.1/install-tools/include/tgmath.h
/Developer/Platforms/iPhoneOS.platform/Developer/usr/lib/gcc/arm-apple-darwin10/4.2.1/include/tgmath.h
/Developer/Platforms/iPhoneOS.platform/Developer/usr/lib/gcc/arm-apple-darwin10/4.2.1/install-tools/include/tgmath.h
[...]

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

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

Re: Math.h functions with CGFloat

2010-08-10 Thread Greg Parker 
On Aug 10, 2010, at 2:06 PM, Rick Mann wrote:
> On Aug 10, 2010, at 08:35:43, Kyle Sluder wrote:
>> The correct thing to do is leave the warning enabled and #include .
> 
> Is  available on iOS? (I have code shared among platforms.)

Yes; it's part of C99.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


___

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

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

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

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

Re: Math.h functions with CGFloat

2010-08-10 Thread Rick Mann 

On Aug 10, 2010, at 08:35:43, Kyle Sluder wrote:

> The correct thing to do is leave the warning enabled and #include .

Is  available on iOS? (I have code shared among platforms.)

-- 
Rick


___

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

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

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

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

Re: Math.h functions with CGFloat

2010-08-10 Thread Michael Ash 
On Tue, Aug 10, 2010 at 1:44 PM, Quincey Morris
 wrote:
> Excuse me for jumping into this discussion with half a brain, but isn't there 
> another consideration?
>
> I was under the impression that C does not have symmetric support for 
> 'double' and 'float'. Specifically, I thought that any (a) expression 
> involving floating point numbers promoted everything to doubles to apply the 
> operators to;

All operators with floating-point arguments must be performed with
double precision. However, the C spec operates according to the
"as-if" rule. The compiler is free to generate ANY code it wishes so
long as the result is the same "as if" it were performed as the spec
dictates. So in short, as long as your CPU's FPU does accurate 32-bit
float calculations (and they usually do), the compiler can take
something like this:

floata = floatb * floatc;

And compile it into code that does not ever promote to double, and
still adhere to the standard.

> and (b) 'float' values passed as function arguments are actually passed as 
> doubles.  (Or is it that there are no 'float' expressions, only 'double' 
> expressions?) (Isn't that why it's safe to put 'float's in variable argument 
> lists without casting them to 'double'?) Is this just something I dreamed, or 
> is there something in the C language spec that's relevant?

It's sort of half and half. Floats are promoted to doubles *when
passed as a variable argument to a function that takes varargs*. They
are not promoted when passing to a normal, non-variable argument
function, unless of course the function takes 'double' for that
parameter. So in the vast majority of cases, passing a float to a
function that takes a float will not result in promotion to double.

Mike
___

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: Math.h functions with CGFloat

2010-08-10 Thread Greg Parker 
On Aug 10, 2010, at 10:44 AM, Quincey Morris wrote:
> Also, I remember we had a discussion on this list a few months ago concerning 
> a warning flag that might have been 'Wshorten-64-to-32' or might have been 
> something vaguely similar, where someone from Apple jumped in to say that 
> using the warning *didn't* really make sense. I can't remember any more 
> details, and I can't find the post in a quick search of the archives, but I 
> mention it in case someone else has a better memory.

You're probably thinking of -Wconversion, which adds some useful 
type-conversion checking but also some unavoidable complaints about perfectly 
good prototypes.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler


___

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

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

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

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

Re: Math.h functions with CGFloat

2010-08-10 Thread Quincey Morris 
Excuse me for jumping into this discussion with half a brain, but isn't there 
another consideration?

I was under the impression that C does not have symmetric support for 'double' 
and 'float'. Specifically, I thought that any (a) expression involving floating 
point numbers promoted everything to doubles to apply the operators to; and (b) 
'float' values passed as function arguments are actually passed as doubles.  
(Or is it that there are no 'float' expressions, only 'double' expressions?) 
(Isn't that why it's safe to put 'float's in variable argument lists without 
casting them to 'double'?) Is this just something I dreamed, or is there 
something in the C language spec that's relevant?

If I'm at all correct, then using the 'float' versions of the math functions 
doesn't entirely eliminate (runtime) type conversions, and may introduce 
troubling precision issues in the order of conversions in an expression is not 
considered. Compiler optimization may mitigate some of this, but see 
http://ridiculousfish.com/blog/archives/2010/07/23/will-it-optimize/ for a 
salutary warning about naively believe in floating point optimization 
techniques.

Also, I remember we had a discussion on this list a few months ago concerning a 
warning flag that might have been 'Wshorten-64-to-32' or might have been 
something vaguely similar, where someone from Apple jumped in to say that using 
the warning *didn't* really make sense. I can't remember any more details, and 
I can't find the post in a quick search of the archives, but I mention it in 
case someone else has a better memory.


___

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: Math.h functions with CGFloat

2010-08-10 Thread Sean McBride 
On Tue, 10 Aug 2010 16:50:17 +0100, Alastair Houghton said:

> seems like a good solution.

Indeed.  I wish I knew about that before.  :)  A pity that Cocoa.h
includes math.h and not tgmath.h.

--

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: Math.h functions with CGFloat

2010-08-10 Thread Alastair Houghton 
On 10 Aug 2010, at 16:28, Graham Cox wrote:

> If your code is working with CGFloat, then the warning isn't very helpful, 
> because by using CGFloat you've elected to use 32-bit precision.

Only on 32-bit.  On the 64-bit runtime, CGFloat is a double, not a float, and 
therein lies the problem.  If you use e.g. sqrtf() on 64-bit you'll get the 
conversion warning, and if you use sqrt() on 32-bit and assign the result to a 
CGFloat, you'll get the conversion warning too.

 seems like a good solution.

Kind regards,

Alastair.

--
http://alastairs-place.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: Math.h functions with CGFloat

2010-08-10 Thread Kyle Sluder 
On Tue, Aug 10, 2010 at 8:28 AM, Graham Cox  wrote:
> If your code is working with CGFloat, then the warning isn't very helpful, 
> because by using CGFloat you've elected to use 32-bit precision. If you want 
> 'double', use 'double'. The warning could be useful on 64-bit compiles to 
> indicate the inadvertent use of 'float' where you meant 'double' or 
> 'CGFloat', but if you're only using CGFloat then that won't happen.

Turning off -Wshorten-64-to-32 is not a preferable option. Remember
that this also warns about long -> int conversion on LP64.

The correct thing to do is leave the warning enabled and #include .

--Kyle Sluder
___

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

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

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

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

Re: Math.h functions with CGFloat

2010-08-10 Thread Graham Cox 

On 11/08/2010, at 1:08 AM, steven Hooley wrote:

> But then e.g. when building 32-bit i still have to cast the return
> value or i get the warning:-
> 
> 'implicit conversion shortens 64-bit value into a 32-bit value'
> 
> It seems that this warning is my fault because i have added the flag
> -Wshorten-64-to-32 which isn't enabled by default so maybe it
> shouldn't be?


If your code is working with CGFloat, then the warning isn't very helpful, 
because by using CGFloat you've elected to use 32-bit precision. If you want 
'double', use 'double'. The warning could be useful on 64-bit compiles to 
indicate the inadvertent use of 'float' where you meant 'double' or 'CGFloat', 
but if you're only using CGFloat then that won't happen.

--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: Math.h functions with CGFloat

2010-08-10 Thread steven Hooley 
But then e.g. when building 32-bit i still have to cast the return
value or i get the warning:-

'implicit conversion shortens 64-bit value into a 32-bit value'

It seems that this warning is my fault because i have added the flag
-Wshorten-64-to-32 which isn't enabled by default so maybe it
shouldn't be?
Thanks

On 10 August 2010 15:19, Graham Cox  wrote:
>
> On 11/08/2010, at 12:12 AM, steven Hooley wrote:
>
>> Because CGFloat is typedef'd to float on 32bit and double on 64bit i
>> have to swap between, eg,  atan and atanf depending on my build
>> settings. I have a framework which is intended to support 32bit and
>> 64bit.
>
>
> Just use atan(). 32-bit floats are promoted to doubles silently. There is a 
> slight performance penalty but it's absolutely tiny.
>
> --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: Math.h functions with CGFloat

2010-08-10 Thread Graham Cox 

On 11/08/2010, at 12:12 AM, steven Hooley wrote:

> Because CGFloat is typedef'd to float on 32bit and double on 64bit i
> have to swap between, eg,  atan and atanf depending on my build
> settings. I have a framework which is intended to support 32bit and
> 64bit.


Just use atan(). 32-bit floats are promoted to doubles silently. There is a 
slight performance penalty but it's absolutely tiny.

--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: Math.h functions with CGFloat

2010-08-10 Thread James Montgomerie 
You should, I believe, be able to include  ('type generic math' - a 
C99 addition) instead, and then just 'use' the non-suffixed versions of the 
functions.  Hidden macro magic is supposed to then make the compiler call the 
double or float versions as appropriate for the type used.

Having said that, I had a lot of trouble when trying this in my iPhone app a 
year or so ago.  Things seemed very slow when complied, and disassembly showed 
all sorts of float<->double conversion going on.  I ended up explicitly calling 
the f-suffixed ones anyway.  I don't think I should have needed to though, and 
if there was a bug back then (rather than just me doing something incorrect) it 
could be fixed now.

Jamie.

On 10 Aug 2010, at 15:04, steven Hooley wrote:

> Sorry, 'safe' was a bad choice. I do care because i have compiler
> warnings. I have started defining macros for each function and thought
> i better check that they didn't already exist.
> Thankyou
> 
> On 10 August 2010 14:54, Alastair Houghton  
> wrote:
>> On 10 Aug 2010, at 13:42, steven Hooley wrote:
>> 
>>> Is there a preferred way to use the Math.h functions with CGFloats
>>> that is 32 and 64 bit safe?
>> 
>> Why would they be unsafe?  (They aren't.)
>> 
>> It's possible that using the double versions (the ones without the "f" 
>> suffix) is inefficient in 32-bit mode, but in practice you're very unlikely 
>> to notice.  If you particularly cared, you could #define some macros for 
>> them, but I doubt it's worthwhile unless you're going to do some heavy-duty 
>> geometry (and in that case, you might find that you want to use double 
>> anyway, for accuracy).
>> 
>> BTW,  isn't capitalised; please don't use random upper-case letters 
>> when including header files... it causes grief if your source code is ever 
>> moved somewhere case-sensitive.
>> 
>>> Should i even be using Math.h functions in Cocoa?
>> 
>> Why should you not?
>> 
>> Kind regards,
>> 
>> Alastair.
> ___
> 
> 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/jamie%40montgomerie.net
> 
> This email sent to ja...@montgomerie.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: Math.h functions with CGFloat

2010-08-10 Thread steven Hooley 
Yes, sorry - i meant /usr/include/math.h

Because CGFloat is typedef'd to float on 32bit and double on 64bit i
have to swap between, eg,  atan and atanf depending on my build
settings. I have a framework which is intended to support 32bit and
64bit.

I thought this may have been a common scenario and some useful macros
might already exist.
Thanks

On 10 August 2010 14:10, lbland  wrote:
> hi-
>
> On Aug 10, 2010, at 8:42 AM, steven Hooley wrote:
>
>> Is there a preferred way to use the Math.h functions with CGFloats
>> that is 32 and 64 bit safe?
>> Do some Macros already exist somewhere?
>>
>> Should i even be using Math.h functions in Cocoa?
>
> What do you mean by Math.h ? Do you mean: math.h (/usr/include/math.h) ?
>
> You can use math.h in Cocoa.
>
> math.h is a C standard and doesn't know about CGFloat (except that CGFloat is 
> typedef to double or float). math.h functions generally take doubles (with 
> implicit promotion of floats), or you can use the float counterpart (such as 
> cos() v.s. cosf() ).
>
> thanks!-
>
> -lance
___

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

Fwd: Math.h functions with CGFloat

2010-08-10 Thread steven Hooley 
Sorry, 'safe' was a bad choice. I do care because i have compiler
warnings. I have started defining macros for each function and thought
i better check that they didn't already exist.
Thankyou

On 10 August 2010 14:54, Alastair Houghton  wrote:
> On 10 Aug 2010, at 13:42, steven Hooley wrote:
>
>> Is there a preferred way to use the Math.h functions with CGFloats
>> that is 32 and 64 bit safe?
>
> Why would they be unsafe?  (They aren't.)
>
> It's possible that using the double versions (the ones without the "f" 
> suffix) is inefficient in 32-bit mode, but in practice you're very unlikely 
> to notice.  If you particularly cared, you could #define some macros for 
> them, but I doubt it's worthwhile unless you're going to do some heavy-duty 
> geometry (and in that case, you might find that you want to use double 
> anyway, for accuracy).
>
> BTW,  isn't capitalised; please don't use random upper-case letters 
> when including header files... it causes grief if your source code is ever 
> moved somewhere case-sensitive.
>
>> Should i even be using Math.h functions in Cocoa?
>
> Why should you not?
>
> Kind regards,
>
> Alastair.
___

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: Math.h functions with CGFloat

2010-08-10 Thread Alastair Houghton 
On 10 Aug 2010, at 13:42, steven Hooley wrote:

> Is there a preferred way to use the Math.h functions with CGFloats
> that is 32 and 64 bit safe?

Why would they be unsafe?  (They aren't.)

It's possible that using the double versions (the ones without the "f" suffix) 
is inefficient in 32-bit mode, but in practice you're very unlikely to notice.  
If you particularly cared, you could #define some macros for them, but I doubt 
it's worthwhile unless you're going to do some heavy-duty geometry (and in that 
case, you might find that you want to use double anyway, for accuracy).

BTW,  isn't capitalised; please don't use random upper-case letters 
when including header files... it causes grief if your source code is ever 
moved somewhere case-sensitive.

> Should i even be using Math.h functions in Cocoa?

Why should you not?

Kind regards,

Alastair.

--
http://alastairs-place.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

Math.h functions with CGFloat

2010-08-10 Thread steven Hooley 
Is there a preferred way to use the Math.h functions with CGFloats
that is 32 and 64 bit safe?
Do some Macros already exist somewhere?

Should i even be using Math.h functions in Cocoa?

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