Re: Cocoa-dev Digest, Vol 8, Issue 190
Re: Cocoa-dev Digest, Vol 8, Issue 190
- Subject: Re: Cocoa-dev Digest, Vol 8, Issue 190
- From: alfredo laghi <email@hidden>
- Date: Thu, 17 Mar 2011 15:53:20 +0100
Grès;3.z,...2,..;//9º,,=.==.\\\\]{
Inviato da iPhone
Il giorno 16/mar/2011, alle ore 18:24, email@hidden]a scritto:
> Send Cocoa-dev mailing list submissions to
> email@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.apple.com/mailman/listinfo/cocoa-dev
> or, via email, send a message with subject or body 'help' to
> email@hidden
>
> You can reach the person managing the list at
> email@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cocoa-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: NSTableView Column Count (Nicholas Zaccardi)
> 2. Re: NSTableView Column Count (Kyle Sluder)
> 3. Re: Debugging a sleepless Mac (Aaron Burghardt)
> 4. Re: Debugging a sleepless Mac (Kyle Sluder)
> 5. Re: NSTableView Column Count (Nicholas Zaccardi)
> 6. Re: NSTableView Column Count (Kyle Sluder)
> 7. Re: Books covering iOS security issues (Sean McBride)
> 8. RE: [Moderator] Lion NDA reminder (Shawn Bakhtiar)
> 9. RE: Books covering iOS security issues (Shawn Bakhtiar)
> 10. Re: Debugging a sleepless Mac (Matt Gough)
> 11. Re: crash in initWithCoder (James Maxwell)
> 12. Master Detail (Georg Seifert)
> 13. Re: crash in initWithCoder (James Maxwell)
> 14. Re: Debugging a sleepless Mac (Kyle Sluder)
> 15. Re: Books covering iOS security issues (Stephane Sudre)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 16 Mar 2011 11:09:51 -0400
> From: Nicholas Zaccardi <email@hidden>
> Subject: Re: NSTableView Column Count
> To: Indragie Karunaratne <email@hidden>
> Cc: email@hidden
> Message-ID:
> <AANLkTim6tS9Zmbs=QHJ89atDAjn=email@hidden>
> Content-Type: text/plain; charset=UTF-8
>
> That did not work for me, I resized it manually and it works, but I
> want to have IB do it automatically.
>
> Thanks for any more suggestions.
>
> On Wed, Mar 16, 2011 at 10:13 AM, Indragie Karunaratne
> <email@hidden> wrote:
>> This is a weird solution that worked for me:
>>
>> 1. Decrease column count to one
>> 2. Click the "Headers" checkbox to disable table headers
>> 3. Click the "Headers" checkbox again to re-enable table headers, and it automatically sizes your single column to fill the entire width of the table
>>
>> This seems to be more of a bug with Xcode but its a quick solution :)
>>
>> On 2011-03-15, at 11:13 AM, Nicholas Zaccardi wrote:
>>
>>> I am trying to make an NSTableView with only one column. Here is what I do:
>>>
>>> 1. Open nib
>>> 2. Add TableView
>>> 3. Decrease column count
>>> 4. Save the NIB
>>>
>>> However if I build and run, I still get 2 columns. Any suggestions?
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (email@hidden)
>>>
>>> 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:
>>>
>>> This email sent to email@hidden
>>
>>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 16 Mar 2011 08:16:24 -0700
> From: Kyle Sluder <email@hidden>
> Subject: Re: NSTableView Column Count
> To: Nicholas Zaccardi <email@hidden>
> Cc: email@hidden
> Message-ID:
> <email@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Wed, Mar 16, 2011 at 8:09 AM, Nicholas Zaccardi
> <email@hidden> wrote:
>> That did not work for me, I resized it manually and it works, but I
>> want to have IB do it automatically.
>
> Have IB do what automatically? NSTableView doesn't autoresize its
> columns unless they fit the exact visible width of the enclosing
> scrollview. If you remove the last column, the tableview no longer
> fills the scroll view, and therefore will not autosize its columns as
> you resize it in Interface Builder.
>
> --Kyle Sluder
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 16 Mar 2011 11:22:05 -0400
> From: Aaron Burghardt <email@hidden>
> Subject: Re: Debugging a sleepless Mac
> To: Matt Gough <email@hidden>
> Cc: Cocoa <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Mar 16, 2011, at 8:37 AM, Matt Gough wrote:
>
>> So it seems that something else is preventing idle sleep, but I've no idea how to find the culprit. Is there some defaults setting I can use that will log what the OS wants to do at sleep time and what is blocking it?
>
> Leaving a Terminal session/window open seems to prevent sleep for me.
>
> Aaron
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 16 Mar 2011 08:32:44 -0700
> From: Kyle Sluder <email@hidden>
> Subject: Re: Debugging a sleepless Mac
> To: Matt Gough <email@hidden>
> Cc: Cocoa <email@hidden>
> Message-ID:
> <AANLkTi=email@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Wed, Mar 16, 2011 at 5:37 AM, Matt Gough <email@hidden> wrote:
>> So it seems that something else is preventing idle sleep, but I've no idea how to find the culprit. Is there some defaults setting I can use that will log what the OS wants to do at sleep time and what is blocking it?
>
> According to the I/O Kit Power Management Release Notes, `pmset -g`
> should list all outstanding power management assertions.
> http://developer.apple.com/library/mac/#releasenotes/Darwin/RN-IOKitPowerManagment/_index.html
>
> I'd say try that and see if it tells you who's preventing system sleep.
>
> --Kyle Sluder
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 16 Mar 2011 11:44:45 -0400
> From: Nicholas Zaccardi <email@hidden>
> Subject: Re: NSTableView Column Count
> To: Kyle Sluder <email@hidden>
> Cc: email@hidden
> Message-ID:
> <email@hidden>
> Content-Type: text/plain; charset=UTF-8
>
> Okay. This is not a problem per say, but let me make sure I understand you.
>
> In order for a single column to fill the entire width of a scroll
> view, I have to make the width of the column the width of the scroll
> view - the scroll bars?
>
> For example, a scroll view is 100 wide and my NSTableView is also 100
> wide, but the one and only column is only 65 wide then I would have to
> manually make it 100 in order for the column to make use of the full
> NSTableView. XCode/IB/Cocoa will not do that for me.
>
> Then if I resize the window/Scroll/TableView will the column auto resize?
>
> Thank you for helping me understand this!
>
>
> On Wed, Mar 16, 2011 at 11:16 AM, Kyle Sluder <email@hidden> wrote:
>> On Wed, Mar 16, 2011 at 8:09 AM, Nicholas Zaccardi
>> <email@hidden> wrote:
>>> That did not work for me, I resized it manually and it works, but I
>>> want to have IB do it automatically.
>>
>> Have IB do what automatically? NSTableView doesn't autoresize its
>> columns unless they fit the exact visible width of the enclosing
>> scrollview. If you remove the last column, the tableview no longer
>> fills the scroll view, and therefore will not autosize its columns as
>> you resize it in Interface Builder.
>>
>> --Kyle Sluder
>>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 16 Mar 2011 08:51:32 -0700
> From: Kyle Sluder <email@hidden>
> Subject: Re: NSTableView Column Count
> To: Nicholas Zaccardi <email@hidden>
> Cc: email@hidden
> Message-ID:
> <AANLkTi=mGm24rpqfQMKEF=X1f=email@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Wed, Mar 16, 2011 at 8:44 AM, Nicholas Zaccardi
> <email@hidden> wrote:
>> In order for a single column to fill the entire width of a scroll
>> view, I have to make the width of the column the width of the scroll
>> view - the scroll bars?
>>
>> For example, a scroll view is 100 wide and my NSTableView is also 100
>> wide, but the one and only column is only 65 wide then I would have to
>> manually make it 100 in order for the column to make use of the full
>> NSTableView. XCode/IB/Cocoa will not do that for me.
>>
>> Then if I resize the window/Scroll/TableView will the column auto resize?
>
> Yes. As Indragie mentioned, you might need to temporarily turn on
> column headers so you have something to resize.
>
> --Kyle Sluder
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 16 Mar 2011 12:10:06 -0400
> From: Sean McBride <email@hidden>
> Subject: Re: Books covering iOS security issues
> To: Eric Gorr <email@hidden>, Cocoa Dev
> <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Wed, 16 Mar 2011 10:20:49 -0400, Eric Gorr said:
>
>> I was just wondering if there were any books people would recommend,
>> apart from Apple's documentation on the topic ( http://bit.ly/gz36Bn,
>> etc. ), which discuss security issues and best-coding practices for iOS.
>
> Since you're likely working in a C-based language, this could be educational:
>
> <https://www.securecoding.cert.org/confluence/display/seccode/CERT+C
> +Secure+Coding+Standard>
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng email@hidden
> Rogue Research www.rogue-research.com
> Mac Software Developer Montréal, Québec, Canada
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 16 Mar 2011 12:22:03 -0400
> From: Shawn Bakhtiar <email@hidden>
> Subject: RE: [Moderator] Lion NDA reminder
> To: email@hidden, email@hidden
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset="Windows-1252"
>
>
>
> In the jungle the quiet jungle...
> The lion sleeps tonight...
>
> In the jungle the quite jungle....
> The lion sleeps tonight....
>
> Owimboeh... owimboeh...
> Owimboeh... owimboeh...
>
> Owimboeh... owimboeh...
> Owimboeh... owimboeh...
>
>> From: email@hidden
>> Date: Wed, 16 Mar 2011 01:13:27 -0400
>> To: email@hidden
>> Subject: [Moderator] Lion NDA reminder
>>
>> While there haven’t been any issues that I’m aware of I wanted to take an opportunity to remind subscribers...
>>
>> Lion APIs, features, changes, etc. are all covered by non-disclosure. So they can’t be discussed here.
>>
>> However, there are forums at devforums.apple.com that have facilities for this.
>>
>> So head over there for those questions/comments/etc.
>>
>> Thanks in advance
>>
>> [scott]
>> moderator
>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>
>
> ------------------------------
>
> Message: 9
> Date: Wed, 16 Mar 2011 12:26:42 -0400
> From: Shawn Bakhtiar <email@hidden>
> Subject: RE: Books covering iOS security issues
> To: email@hidden, email@hidden,
> email@hidden
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>
> http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40007072
>
> I've looked. This is the best. The examples are all there, and it does a pretty good job of explaining how to do things.
>
>> From: email@hidden
>> To: email@hidden; email@hidden
>> Date: Wed, 16 Mar 2011 12:10:06 -0400
>> CC:
>> Subject: Re: Books covering iOS security issues
>>
>> On Wed, 16 Mar 2011 10:20:49 -0400, Eric Gorr said:
>>
>>> I was just wondering if there were any books people would recommend,
>>> apart from Apple's documentation on the topic ( http://bit.ly/gz36Bn,
>>> etc. ), which discuss security issues and best-coding practices for iOS.
>>
>> Since you're likely working in a C-based language, this could be educational:
>>
>> <https://www.securecoding.cert.org/confluence/display/seccode/CERT+C
>> +Secure+Coding+Standard>
>>
>> --
>> ____________________________________________________________
>> Sean McBride, B. Eng email@hidden
>> Rogue Research www.rogue-research.com
>> Mac Software Developer Montréal, Québec, Canada
>>
>>
>> _______________________________________________
>>
>> Cocoa-dev mailing list (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>
>
> ------------------------------
>
> Message: 10
> Date: Wed, 16 Mar 2011 16:35:41 +0000
> From: Matt Gough <email@hidden>
> Subject: Re: Debugging a sleepless Mac
> To: Kyle Sluder <email@hidden>
> Cc: Cocoa <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
>
> On 16 Mar 2011, at 15:32, Kyle Sluder wrote:
>
>> On Wed, Mar 16, 2011 at 5:37 AM, Matt Gough <email@hidden> wrote:
>>> So it seems that something else is preventing idle sleep, but I've no idea how to find the culprit. Is there some defaults setting I can use that will log what the OS wants to do at sleep time and what is blocking it?
>>
>> According to the I/O Kit Power Management Release Notes, `pmset -g`
>> should list all outstanding power management assertions.
>> http://developer.apple.com/library/mac/#releasenotes/Darwin/RN-IOKitPowerManagment/_index.html
>>
>> I'd say try that and see if it tells you who's preventing system sleep.
>>
>> --Kyle Sluder
>
>
> Thanks to everyone for the suggestions so far.
>
> Alas, pmset -g it doesn't show any active assertions (I know it can do as I slapped one in my code and it showed up).
>
> I have also tried turning off ttyskeepawake, but to no avail.
>
> I didn't mention in my previous email that I have no problem with display sleep working correctly, its just idle sleep that is misbehaving.
>
> Looking through the logs, I can't see any power related ones.
>
> Apart from user interactions, what other sorts of activity automatically prevent idle sleep?
>
> Matt
>
> ------------------------------
>
> Message: 11
> Date: Wed, 16 Mar 2011 09:56:37 -0700
> From: James Maxwell <email@hidden>
> Subject: Re: crash in initWithCoder
> To: Cocoa Dev <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> Thanks Greg. The initWithCoder is indeed at launch, so Guard Malloc shouldn't be a huge problem. I'll give it a try.
>
> cheers,
>
> J.
>
> On 2011-03-15, at 6:45 PM, Greg Parker wrote:
>
>> On Mar 15, 2011, at 4:10 PM, James Maxwell wrote:
>>> I'm getting a crash in initWithCoder, which seems related to decoding a property called "value", which is of type id. Sometimes this object is an NSString, sometimes it's an NSNumber, and sometimes it's an NSArray. The crash only occurs in cases where "value" is an NSArray. The last few lines in my backtrace are:
>>>
>>> #0 0x963c4206 in szone_malloc_should_clear ()
>>> #1 0x963c41a8 in malloc_zone_malloc ()
>>> #2 0x94920a13 in _CFRuntimeCreateInstance ()
>>> #3 0x94943482 in CFNumberCreate ()
>>> #4 0x949586f2 in __CFBinaryPlistCreateObject2 ()
>>> #5 0x94985fe0 in __CFBinaryPlistCreateObject ()
>>> #6 0x9823eb11 in _decodeObjectBinary ()
>>> #7 0x98240314 in -[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] ()
>>> #8 0x98240981 in -[NSArray(NSArray) initWithCoder:] ()
>>> #9 0x9823f508 in _decodeObjectBinary ()
>>> #10 0x9823e800 in _decodeObject ()
>>> #11 0x000cdf05 in -[CbCM_Node initWithCoder:] (self=0x4098770, _cmd=0x9433805c, aDecoder=0x410f1c0) at /Volumes/Wheet-Docs/jamesmaxwell/Documents/xcode/rubato/ManuScore+MusiCOG/ManuScore Test Build/ManuScore/CbCM_Node.m:573
>>>
>>> From this, I'm guessing that the problem is happening with one of the members of the "value" array. Does that seem right? (I should mention, though, that the trace isn't always the same...)
>>> I am retaining "value" when I decode it, so it's not a simple memory bug. I have also run the code with Zombies (NSZombieEnabled=YES), which doesn't indicate any Zombied objects. Finally, the analyzer sees no memory errors (there are a number of "dead stores" - mostly unused variables - but these aren't likely to be real problems, are they?), so I'm stumped. I'm running Xcode 4, btw.
>>
>> A crash inside malloc generally means that there's a memory error elsewhere that corrupted malloc's data structures. (Actual bugs in malloc are rare.) malloc may store information before or after each allocation, and inside freed allocations.
>>
>> The usual bugs are:
>> * writing data before or after the bounds of an allocation. Usually this comes from bounds errors in C arrays.
>> * writing data into an allocation after freeing it.
>>
>> NSZombie catches the latter for Objective-C objects. But if the problem is a non-object allocation, or a bounds error, then NSZombie won't help.
>>
>> The next tool to try is Guard Malloc. It catches both of the above errors for any malloc allocation. On the down side, it is slow and memory intensive, but if this -initWithCoder: is running early in app launch then you won't have any trouble with it.
>>
>> http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/guardmalloc.3.html
>>
>>
>> --
>> Greg Parker email@hidden Runtime Wrangler
>>
>>
>
> James B Maxwell
> Composer/Doctoral Student
> School for the Contemporary Arts (SCA)
> School for Interactive Arts + Technology (SIAT)
> Simon Fraser University
> email@hidden
> email@hidden
>
>
>
> ------------------------------
>
> Message: 12
> Date: Wed, 16 Mar 2011 17:57:20 +0100
> From: Georg Seifert <email@hidden>
> Subject: Master Detail
> To: Cocoa Developers <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> Hi,
>
> If I have a master detail interface bound to a array controller.
>
> To explain my problem (the actual structure is different but as an explanation):
> The list shows a some persons. Then I have a switch that selects if the detail view shows the private or the work address. Is there any easy way do that.
>
> Now I use another array controller. On every selection change I make an array of addresses and set as the content array.
>
> Is there an easier solution?
>
> Or can I change the keypath if the address switch changes?
>
> Best
> Georg
>
> ------------------------------
>
> Message: 13
> Date: Wed, 16 Mar 2011 10:00:29 -0700
> From: James Maxwell <email@hidden>
> Subject: Re: crash in initWithCoder
> To: Cocoa Dev <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> oops... How do I enable Guard Malloc in Xcode 4?
>
> J.
>
>
> On 2011-03-15, at 6:45 PM, Greg Parker wrote:
>
>> On Mar 15, 2011, at 4:10 PM, James Maxwell wrote:
>>> I'm getting a crash in initWithCoder, which seems related to decoding a property called "value", which is of type id. Sometimes this object is an NSString, sometimes it's an NSNumber, and sometimes it's an NSArray. The crash only occurs in cases where "value" is an NSArray. The last few lines in my backtrace are:
>>>
>>> #0 0x963c4206 in szone_malloc_should_clear ()
>>> #1 0x963c41a8 in malloc_zone_malloc ()
>>> #2 0x94920a13 in _CFRuntimeCreateInstance ()
>>> #3 0x94943482 in CFNumberCreate ()
>>> #4 0x949586f2 in __CFBinaryPlistCreateObject2 ()
>>> #5 0x94985fe0 in __CFBinaryPlistCreateObject ()
>>> #6 0x9823eb11 in _decodeObjectBinary ()
>>> #7 0x98240314 in -[NSKeyedUnarchiver _decodeArrayOfObjectsForKey:] ()
>>> #8 0x98240981 in -[NSArray(NSArray) initWithCoder:] ()
>>> #9 0x9823f508 in _decodeObjectBinary ()
>>> #10 0x9823e800 in _decodeObject ()
>>> #11 0x000cdf05 in -[CbCM_Node initWithCoder:] (self=0x4098770, _cmd=0x9433805c, aDecoder=0x410f1c0) at /Volumes/Wheet-Docs/jamesmaxwell/Documents/xcode/rubato/ManuScore+MusiCOG/ManuScore Test Build/ManuScore/CbCM_Node.m:573
>>>
>>> From this, I'm guessing that the problem is happening with one of the members of the "value" array. Does that seem right? (I should mention, though, that the trace isn't always the same...)
>>> I am retaining "value" when I decode it, so it's not a simple memory bug. I have also run the code with Zombies (NSZombieEnabled=YES), which doesn't indicate any Zombied objects. Finally, the analyzer sees no memory errors (there are a number of "dead stores" - mostly unused variables - but these aren't likely to be real problems, are they?), so I'm stumped. I'm running Xcode 4, btw.
>>
>> A crash inside malloc generally means that there's a memory error elsewhere that corrupted malloc's data structures. (Actual bugs in malloc are rare.) malloc may store information before or after each allocation, and inside freed allocations.
>>
>> The usual bugs are:
>> * writing data before or after the bounds of an allocation. Usually this comes from bounds errors in C arrays.
>> * writing data into an allocation after freeing it.
>>
>> NSZombie catches the latter for Objective-C objects. But if the problem is a non-object allocation, or a bounds error, then NSZombie won't help.
>>
>> The next tool to try is Guard Malloc. It catches both of the above errors for any malloc allocation. On the down side, it is slow and memory intensive, but if this -initWithCoder: is running early in app launch then you won't have any trouble with it.
>>
>> http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/guardmalloc.3.html
>>
>>
>> --
>> Greg Parker email@hidden Runtime Wrangler
>>
>>
>
> James B Maxwell
> Composer/Doctoral Student
> School for the Contemporary Arts (SCA)
> School for Interactive Arts + Technology (SIAT)
> Simon Fraser University
> email@hidden
> email@hidden
>
>
>
> ------------------------------
>
> Message: 14
> Date: Wed, 16 Mar 2011 09:59:29 -0700
> From: Kyle Sluder <email@hidden>
> Subject: Re: Debugging a sleepless Mac
> To: Matt Gough <email@hidden>
> Cc: Cocoa <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> On Mar 16, 2011, at 9:35 AM, Matt Gough <email@hidden> wrote:
>
>> Apart from user interactions, what other sorts of activity automatically prevent idle sleep?
>
> Time Machine, I think?
>
> --Kyle Sluder
>
> ------------------------------
>
> Message: 15
> Date: Wed, 16 Mar 2011 18:22:19 +0100
> From: Stephane Sudre <email@hidden>
> Subject: Re: Books covering iOS security issues
> To: Eric Gorr <email@hidden>
> Cc: Cocoa Dev <email@hidden>
> Message-ID:
> <AANLkTi=email@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I haven't read it so it's just to add a reference to the list:
>
> Professional Cocoa Application Security
> Graham J. Lee, Wrox, 2010
> ISBN 978-0-470-52595-1, £33.99
> http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470525959.html
>
>
> ------------------------------
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins (at) lists.apple.com
>
> http://lists.apple.com/mailman/listinfo/cocoa-dev
>
>
> End of Cocoa-dev Digest, Vol 8, Issue 190
> *****************************************
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden