Re: static analyzers says I'm leaking, I _think_ I'm not
If the property is set to retain, then the line self.cycler = [[[….initWithGrid:self] autorelease] will cause the setter to retain the passed in object, so after this line, _cycler will have a (heuristic) retain count of 2 (an alloc and a retain). After this, when the autorelease pool is drained, reducing the (heuristic) retain count by 1: you've still got a hold of it in the property. Then in dealloc, you release the object in dealloc to reduce the (heuristic) retain count to 0. To release the object, you can use [_cycler release]; or self.cycler = nil; or you may be able to not even bother if you won't create a cycle, I haven't done manual memory in a while, but I think retained properties are released at destruction automatically. Aaron On May 6, 2015, at 2:30 PM, Michael David Crawford mdcrawf...@gmail.com wrote: Am I correct that autoreleased objects are released after each round of even processing? In this case my cycler needs to hang around for the life of the whole program. Thanks, Mike Michael David Crawford, Consulting Software Engineer mdcrawf...@gmail.com http://www.warplife.com/mdc/ Available for Software Development in the Portland, Oregon Metropolitan Area. On Wed, May 6, 2015 at 2:25 PM, Aaron Montgomery eey...@monsterworks.com wrote: Having cycler set to assign and then releasing it in dealloc doesn't feel right. Why not set cycler to retain, add an autorelease in init then release _cycler in dealloc? Aaron On May 6, 2015, at 1:57 PM, Michael David Crawford mdcrawf...@gmail.com wrote: I've had problems in the past where I failed to understand the Cocoa ownership conventions, I'm willing to grant that could be the case. I know for sure that the analyzer enforces the naming conventions, that is, the exact same function names in C or C++ won't yield that same warnings as alloc, new or copy would in Objective-C. I'm reluctant to use ARC because in my honest opinion, ARC will get the leaks and most out of the crashes out of skanky code. If you don't use ARC, you get them out by fixing the skank: Dave, why do you add twelve extra bytes to all of Spellswell's allocations? That was so Spellswell would stop crashing. Facepalm. // LifeGrid.h @property (assign, nonatomic) GridCycler *cycler; // Lifegrid.m - init self.cycler = [[GridCycler alloc] initWithGrid: self]; // Potential leak of an object if ( nil == self.cycler ) goto cycler_failed; // dealloc [self.cycler release]; Expanding the potential leak message yields: 1. assuming 'self' is not nil 2. method returns Objective-C object with +1 retain count 3. Object leaked: allocated object is not references later in this execution path and has a retain count of +1. Isn't that what I want? I should be taking ownership of it with alloc/initWithGrid. (initWithGrid doesn't do a cyclic retain.) Thanks, Mike Michael David Crawford, Consulting Software Engineer mdcrawf...@gmail.com http://www.warplife.com/mdc/ Available for Software Development in the Portland, Oregon Metropolitan Area. ___ 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/eeyore%40monsterworks.com This email sent to eey...@monsterworks.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: New information. Was: Re: Weird UITableView problem
Works for me. Not saying it doesn't work for you, but the problem isn't the
code.
Created a fresh Single View Application iOS project.
Replaced ViewController.m source with the code below.
Added a UITableView to the View Controller's View and hooked up the DataSource
to the View Controller.
Ran it in the Simulator.
Scrolled the table and could see all the dwarves.
Aaron
On Apr 28, 2015, at 9:45 AM, William Squires wsqui...@satx.rr.com wrote:
Thinking this was a Swift problem, I recreated the project, but with ObjC as
the language. I set up the UI the same as with the Swift project. It too,
only shows a subset of the array, only this one shows 15 rows, not 13. Here's
the ViewController.m
//
// ViewController.m
// SimpleObjCTable
//
// Created by William Squires on 4/28/15.
// Copyright (c) 2015 William Squires. All rights reserved.
//
#import ViewController.h
@interface ViewController ()
@property NSArray *dwarves;
@end
@implementation ViewController
- (void)viewDidLoad
{
[super viewDidLoad];
self.dwarves = [NSArray arrayWithObjects:@Sleepy,
@Sneezy,
@Bashful,
@Happy,
@Doc,
@Grumpy,
@Dopey,
@Thorin,
@Dorin,
@Nori,
@Ori,
@Balin,
@Dwalin,
@Fili,
@Kili,
@Oin, // These are not shown.
@Gloin,
@Bifur,
@Bofur,
@Bombur,
nil];
// Do any additional setup after loading the view, typically from a nib.
}
- (void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];
// Dispose of any resources that can be recreated.
}
#pragma mark UITableView Methods
-(NSInteger)tableView:(UITableView *)tableView
numberOfRowsInSection:(NSInteger)section
{
NSInteger theCount = [self.dwarves count];
NSLog(@theCount = %ld, theCount);
return theCount;
}
-(UITableViewCell *)tableView:(UITableView *)tableView
cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
NSLog(@indexPath.row = %ld, indexPath.row);
UITableViewCell *cell = [tableView
dequeueReusableCellWithIdentifier:@SimpleTableIdentifier];
if (cell == nil)
{
cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault
reuseIdentifier:@SimpleTableIdentifier];
}
cell.textLabel.text = [self.dwarves objectAtIndex:indexPath.row];
return cell;
}
@end
running it gives me (in the debug console) 4 instances of theCount = 20,
followed by 15 lines of indexPath.row = 0 up to indexPath.row = 14 (15
total, which corresponds to the comment in the initialization line for
dwarves = NSArray... line above.) In both cases (the Swift project, and the
ObjC project) I use the default view (with the size class w:any, h:any) and
pin the UITableView to the edges of the parent view.
Now I'm totally lost as to why only a limited subset of the rows are being
shown, especially given that tableView:numberOfRowsInSection: consistently
returns 20 (the number of items initializing the array). HELP!!
On Apr 26, 2015, at 11:29 AM, William Squires wsqui...@satx.rr.com wrote:
I made a fairly simple iOS app (Single View template, iPhone, Swift) that
has a UITableView. I've got it all hooked up, and running the project (in
the simulator) shows the table view, but only 13 (out of 20) rows are ever
shown.
here's the deal:
ViewController.swift
class ViewController: UIViewController, UITableViewDelegate,
UITableViewSource
{
private let dwarves = [Sleepy,
Sneezy,
Bashful,
Happy,
Doc,
Grumpy,
Dopey,
Thorin,
Dorin,
Nori,
Ori,
Balin,
Dwalin,
Fili, // From here on, these might as well not exist
(index = 13)
Kili,
Oin,
Gloin,
Bifur,
Bofur,
Bombur
]
let simpleTableIdentifier = SimpleTableIdentifier
...
// MARK: UITableViewDataSource/UITableViewDelegate methods
func tableView(tableView: UITableView, numberOfRowsInSection section: Int)
- Int
{
return dwarves.count
}
func tableView(tableView:UITableView,
Re: Analyser reports memory leak… where?
On Sep 12, 2013, at 9:17 AM, Graham Cox graham@bigpond.com wrote: On 12/09/2013, at 6:07 PM, Kyle Sluder k...@ksluder.com wrote: Personally, I would avoid doing this, as it could cause reentrancy among KVO observers of eventTypes. Instead, I'd assign to mEventTypes directly from your lazy initializer. Or perhaps I would factor out the common setter code to a private helper method. Indeed, I have changed the code to do just this, which is what I would have written in the first place (honest!). I'm not sure why it wasn't and changing it appears to have not caused any problems. Hopefully this has the side effect of shutting the analyzer up. It does. I guess the thread is now really about why the analyser was thrown off by this. Academic? Perhaps, but here's the bigger picture: I want to gradually move my codebase to ARC, so in preparation for that, I have been going through and trying to ensure the analyser is happy, since my understanding is that ARC relies on the same analysis to do its thing correctly, so if the analyser is getting it wrong, converting to ARC might introduce a bug here. No, I don't think this is academic. The analyzer appears to have a real problem with using a setter inside a getter (both as exhibited with your original example and my more minimal example). If it is going to be responsible for adding all the memory management code to our code, we need to know that it can handle this situation or that it will refuse to convert to ARC when this situation is present. I'll try to see how it handles converting my minimal example to ARC. Aaron ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: @property and automatic synthesis of getters and setters.
On Sep 12, 2013, at 2:45 PM, Peter Teeson ptee...@icloud.com wrote:
Xcode 4.6.2 Lion 10.7.5
Programming with Objective-C seems to indicate I can do this:
#import Cocoa/Cocoa.h
#import Cell.h //My sub-class
@interface Document : NSDocument
@property Cell *protoCell;
@end
and this (i.e. no need to @synthesize):
@implementation Document
- (id)init
{
self = [super init];
if (self) {
protoCell = [[Cell alloc]init];
// Add your subclass-specific initialization here.
}
return self;
}
……
@end
but the compiler tells me
Use of undeclared identifier 'protoCell'; did you mean '_protoCell'?
I think it is either
_protoCell = [[Cell alloc] init];
or
self.protoCell = [[Cell alloc] init];
___
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: @property and automatic synthesis of getters and setters.
On Sep 12, 2013, at 3:02 PM, Lee Ann Rucker lruc...@vmware.com wrote: On Sep 12, 2013, at 2:52 PM, Aaron Montgomery wrote: I think it is either _protoCell = [[Cell alloc] init]; or self.protoCell = [[Cell alloc] init]; These aren't equivalent unless the @property is assign, which usually is not what you want for object instvars that you intend to own. @property (readwrite, retain) protoCell; _protoCell = [[Cell alloc] init]; self.protoCell = [[[Cell alloc] init] autorelease]; self.protoCell = [foo somethingThatReturnsAProtoCell]; // since getters generally do not provide a retained object; see earlier discussions today :) self.protoCell = nil; [_protoCell release]; _protoCell = nil; Right, the original poster will need to decide which one has appropriate semantics for his situation. Just providing him with his two syntactic options. Since he is doing this work in an initializer, I suspect he will want direct ivar access. If he wants to use the property access and isn't using ARC, he will need the autorelease. Aaron ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Analyser reports memory leak… where?
I've been trying to reproduce this problem, but haven't been able to get the
warning on a minimal example. However, I noticed something unusual trying to
build a minimal example to play with. Here's a stripped down example (Xcode
4.6.3):
#import Foundation/Foundation.h
@interface MWObject : NSObject
@property (nonatomic, strong) NSObject* object;
- (NSObject*)newObject;
@end
@implementation MWObject
@synthesize object=_object;
- (void)dealloc
{
[super dealloc];
[_object release];
}
- (NSObject*)newObject
{
return [[NSObject alloc] init];
}
- (void)setObject:(NSObject *)object
{
[_object release];
_object = [object retain];//3
}
- (NSObject*)object
{
NSObject* theObject = [self newObject];
[self setObject:theObject];//2
[theObject release];//1
return _object;
}
@end
Version 0: as above and we do not get a warning (I believe the memory
management is correct even if the semantics may be a little odd).
Version 1: Comment out line 1 and we do not get a warning (I would have
suspected a leak of the theObject).
Version 2: Comment out lines 1 and 2 and we now get a warning (expected).
Version 3: Comment out lines 1 and 3 and we now get a warning (expected).
So somehow the retain call in the setObject: method is causing the release
call in the object method to be ignored. As long as the compiler sees the
retain on line 3, the inclusion or exclusion of the release on line 1 doesn't
seem to matter. Something is pretty clearly confused because Version 0 and
Version 1 cannot both have correct memory management.
Aaron
On Sep 12, 2013, at 7:42 AM, Fritz Anderson anderson.fr...@gmail.com wrote:
On 12 Sep 2013, at 4:35 AM, Graham Cox graham@bigpond.com wrote:
Here's some code for which the Analyser reports potential leak of an object
stored into 'eventTypes'. I don't see it.
I didn't write this code, so I'm reluctant to change it even though I would
have written it a bit differently. mEventTypes is an ivar.
- (void)setEventTypes:(NSDictionary*)eventTypes
{
if (eventTypes != mEventTypes)
{
[mEventTypes release];
mEventTypes = [eventTypes retain];
}
InitializePrefsForEventTypeNames();
}
- (NSDictionary*)eventTypes
{
if (mEventTypes == nil)
{
[self loadNib];
NSDictionary* eventTypes = [self newEventTypes];
[self setEventTypes:eventTypes];
[eventTypes release];
}
return mEventTypes; //- analyser complains here
}
- (NSDictionary*)newEventTypes
{
//[code deleted that presets contents of 'eventTypes']
// Method name begins with new; clients are responsible for releasing.
return [[NSDictionary alloc] initWithDictionary:eventTypes];
}
I tried a Foundation-tool project that included a class with the methods you
show, dummying the methods and functions not shown as empty
void-returning-void, and dictionary data as one string-keying-string. ARC off.
Running this through a later version of clang showed no analyzer errors. I
think it's a bug in the version of clang you're using. Or: clang does
cross-function checks to one degree or another. Can you make a minimal
example, and add the code you omitted here to see what makes the analyzer
unhappy?
I assume you expanded the note and examined the code path on which the
compiler saw a potential problem?
— F
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/eeyore%40monsterworks.com
This email sent to eey...@monsterworks.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: Analyser reports memory leak… where?
Right, sorry, threw it together too quickly and have been living too long in
the land of ARC. Correcting the setter, fixing the dealloc method and removing
the newObject method (see below):
@interface MWObject : NSObject
@property (nonatomic, strong) NSObject* object;
@end
@implementation MWObject
@synthesize object=_object;
- (void)dealloc
{
[_object release];
[super dealloc];
}
- (void)setObject:(NSObject *)object
{
if (object == _object) return;//5
[object retain];
[_object release];
_object = object;//3
}
- (NSObject*)object
{
NSObject* theObject = [[NSObject alloc] init];
[self setObject:theObject];//2
[theObject release];//1
return _object;//4
return [[_object retain] autorelease];
}
@end
Version 0: Comment out line 5, as written has no warnings
Version 1: Comment out line 1 and 5, has no warnings
Version 2: Comment out lines 1 and 2 and 5, has a warning
Version 3: Comment out lines 1 and 3 and 5, has a warning.
Again, Versions 0 and 1 cannot both have correct memory management.
Note that if we comment out line 4, we have:
Version 4: Comment out line 4 and 5, no warnings
Version 5: Comment out lines 4 and 1 and 5, no warnings.
So not returning an retained-autoreleased value from the getter, is not the
issue.
However, if we add a branch test for preventing self-assignment, we do get a
warning when expected:
Version 6: As written above, no warnings
Version 7: Comment out line 1, warning
Also note that the naming of the newObject method is not the core issue here.
We can eliminate that method entirely and we will still get the odd behavior.
Aaron
On Sep 12, 2013, at 8:28 AM, Gary L. Wade garyw...@desisoftsystems.com
wrote:
In your dealloc, you should release ivars before calling super dealloc.
Ideally a crash will tell you that quickly; otherwise things could be very
bad.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.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
UITextField access from outside the main thread
Hi,
I'm currently running into this issue trying to use Telerik Test Studio (and am
asking about it there as well), but I think the issue is more general and would
like some ideas.
The situation: Test Studio drives my app's user interface from a background
thread. In some places where the Test Studio is just interacting wth UI
elements, I get a WebThreadLockFromAnyThread warnings (which is expected since
you shouldn't interact with the UI from another thread). I believe they've done
the coding to avoid the warning in most cases, but I've got some subclasses of
UITextField that are generating the warnings. Note, in all examples, self is an
object whose class is a subclass of UITextField.
In some places, the solution is to use blocks, replacing:
[self.objectField reloadInputViews];
with:
dispatch_async(dispatch_get_main_queue(), ^{ [self.objectField
reloadInputViews]; });
which works. The problem is places where I want to read the data. In those
cases, replacing:
NSString* theName = self.text;
with:
__block NSString* theName = nil;
dispatch_sync(dispatch_get_main_queue(), ^{ theName = self.text; });
will block the main thread if run from the main thread (note that I really need
a dispatch_sync so I can get the return value before continuing). So I end up
with the replacement:
__block NSString* theName = nil;
if ([NSThread isMainThread])
{
theName = self.text;
}
else
{
dispatch_sync(dispatch_get_main_queue(), ^{ theName =
self.text; });
}
which is now looking like an awful lot of work just to read a data value and
adding a lot of extra code just to accommodate Test Studio.
So the questions:
Are there any pitfalls to the replacements above that I'm missing?
Should I be doing this in any case to make my code safer?
Is there a better way to go about accessing self.text that works on any thread?
If I wanted to actually update self.text from any thread (haven't needed to do
this yet, but it may arise) would the code below be my best option?
if ([NSThread isMainThread])
{
self.text = theName;
}
else
{
dispatch_sync(dispatch_get_main_queue(), ^{ self.text =
theName; });
}
Thanks,
Aaron
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: goto and ARC
I use goto in places with ARC without too much trouble. When I get this
warning, it is because ARC cannot figure out the lifetime of an object created
after a possible branch and before the the . Sometimes you can get rid of the
error by simply making the lifetime clear. Here's a silly example that causes
the error:
- (BOOL)test:(BOOL)error
{
if (error) goto cleanup;
NSString* theString = [[NSString alloc] init];
//do stuff with theString;
cleanup:
return error;
}
Here's how you can clarify the lifetime of the string (which is what is causing
the problem):
- (BOOL)test:(BOOL)error
{
if (error) goto cleanup;
{
NSString* theString = [[NSString alloc] init];
//do stuff with theString;
}
cleanup:
return error;
}
and another:
- (BOOL)test:(BOOL)error
{
NSString* theString = [[NSString alloc] init];
if (error) goto cleanup;
//do stuff with theString;
cleanup:
return error;
}
I think the general rule is:
If you aren't going to use the allocated object past the goto target, put it in
a sub-block. If you need to use it after the goto target, allocate it prior to
the first goto.
Aaron
On Feb 2, 2013, at 11:55 AM, Jan E. Schotsman jesc...@xs4all.nl wrote:
Hello,
Today I got an error message about goto and ARC, something about leaving a
protected area.
Does this mean goto is nearly unusable under ARC?
Jan E.___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/eeyore%40monsterworks.com
This email sent to eey...@monsterworks.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSTableView: bindings with drag and drop
On Jan 24, 2013, at 6:46 PM, Chuck Soper chu...@veladg.com wrote: On 1/24/13 6:30 PM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: It's clearly documented that they're optional in your situation, and the documentation is 10.7-vintage. The 10.8 SDK header file also says they're optional. They may not be optional pre-10.7, or the log message is spurious, or you've done something in your table view configuration that makes the table *think* it needs these data source methods. Yes, the methods are optional. But, if I implement drag and drop, then I need to conform to the NSTableViewDataSource protocol which causes the methods to be required. I suppose the only solution is to implement numberOfRowsInTableView: andtableView:objectValueForTableColumn:row:, and return 0 and nil, respectively. Maybe toss an assertion into those methods to see if anyone is actually trying to call them (I'm guessing no one is, but you never know). If someone is (either now or in the future), it will be easier to debug the problem with the assertion than when the caller tries to use the bad data and chokes on it. Aaron ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Is ARC any smarter than Xcode's 'Analyze'?
It has been awhile since I last did a conversion, but I do remember that when I Analyzed my project it didn't raise any issues, but when I tried to convert to ARC there were a few places where these issues were raised that I needed to fix. Also, converting to ARC might actually move the retain/release statements inserted into the code and may result in fixing the problem (although it would be tough to figure out exactly what it did that fixed the problem). I guess I would suggest trying to convert on a copy of the project and seeing if it raises any issues or if the conversion fixes the problem. Aaron On Nov 12, 2012, at 9:19 AM, Jerry Krinock je...@ieee.org wrote: I'm debugging a crash in a large project which evidence indicates is caused by a retain/release imbalance. The project is written with manual retain/release, not ARC. The project is built in Xcode 4.5.2, and when I 'Analyze', I get no warnings pertaining to memory management. So the problem must be some edge case which is not caught by 'Analyze'. Further, I think that ARC is built upon 'Analyze', and therefore if I converted this project to ARC, it would still crash. Am I correct? ___ 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/eeyore%40monsterworks.com This email sent to eey...@monsterworks.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
