Re: ARC vs Manual Reference Counting

[Louis Gerbarg]

On Wed, Sep 11, 2013 at 6:58 AM, Dave  wrote:

>
> On 11 Sep 2013, at 05:04, Jens Alfke  wrote:
>
> >
> > On Sep 10, 2013, at 12:33 PM, Dave  wrote:
> >
> >> You with all this talk of memory management, you'd think that Apple (or
> someone) would have come up with a hardware solution for this by now. In
> the 70's and 80's I worked on some firmware and hardware that would handle
> garbage collection in real time (with a little help from OS Software).
> >
> > I’ve read through a lot of GC papers in the past, and I’m not sure what
> you’re talking about here, unless it’s something that allows extra tag bits
> to be stored in pointers. This was used a lot in old LISP systems; it can
> be useful with interpreted languages but I don’t think it’d be applicable
> to a C-based language. (A lot of the more sophisticated GC techniques
> simply don’t work with C-like code because it’s too low-level and makes too
> many assumptions about memory. For example, you can’t use compaction or
> copying collectors at all because objects can’t be relocated. The Obj-C
> garbage collector had to rely on inefficient conservative mark/sweep
> algorithms.)
>
> This was using aUnix Box/MS-DOS box and it was our own hardware, and yes
> it worked with C and Assembler (via a set of Macro's). Basically it was a
> lump of hardware that controlled allocating memory from a pool. It wasn't
> used for system memory (although it could have been), but as a way of
> speeding up certain Image Processing operations. Basically it could
> allocate or free a memory block in one machine cycle - it could also copy
> or fill a block much faster then the CPU too.


The world is a very different place than it was then, in the 80s RAM was a
lot faster relative to the CPU. There is absolutely no way something like
you describe today could be done today, most deeply pipelined OoOE CPUs can
barely forward a register in 1 CPU cycle. Getting out to L3 cache is often
on the order of 20-40 cycles depending on the part, and main memory can
literally be hundreds of cycles. Algorithms designed to work in an
environments with single cycle ram access simply don't hold up on modern
pipelined cache coherent multi-process systems where the processing logic
runs at significant multiples of the memory.


>

>> If Apple were to implement something like this I think there would be a
> massive increase in performance and reliability
> >
> > Nothing personal, but I think you’re falling into the common fallacy of
> thinking that Apple engineers are naive and/or ignorant. It happens all the
> time on these lists. In general, you should assume that the people working
> on system software are pretty damn smart and experienced, and are aware of
> all the techniques that an interested but non-expert outsider would know
> of. If they’re not using them, there’s probably a good reason for it.
>
> I'm sure the engineers are a mixture of good, mediocre, and not so good
> the same as any where else, why should Apple be different? But engineers
> don't get much say on what projects/features are implemented (especially
> somewhere like Apple, MS or any of the big 5 technology companies).


If you mean user features then sure, often engineers have little say. If
you mean runtime and developer features then you are wrong, the developers
at Apple have a lot of say in how what happens. Tim Cook and Phil Schiller
didn't sit down in a meeting and say "Let's implemented tagged pointers,
users will love those," and yet somehow we have them ;-)

 Louis
___

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: Mutable and immutable class cluster implementation / "method swizzling" question

[Louis Gerbarg]

The corner case you mention below ( [myMutableArrayInstance 
isKindOfClass:[NSMutableArray class]] ) is a nonissue for a somewhat surprising 
reason. All instances of NSArray are actually implemented via the concrete 
class NSCFArray, which is a subclass of NSMutableArray. Thus any instances of 
mutable or immutable arrays return YES to isKindOfClass for both NSArray and 
NSMutableArray. The only time that is not true is when people implement custom 
subclasses of NSArray. Thus no one can depend on that particular construct 
working unless they have implemented their own subclasses. 

For that reason, you can probably completely ignore the issue. If you care 
about behaving like Apple's imps I would suggest that you should make your 
immutable class a subclass of NSMutableArray, and just have it's mutation 
methods throw exceptions. Implement your mutable array as a subclass of that. 
That will actually give you the same (somewhat counter intuitive) behavior as 
the builtin classes. Better yet, you could do exactly what they do, have a 
single implementation and control whether mutation works or throws by setting a 
bit.

(Everything I said about arrays is equally applicable to dictionaries, sets, 
and strings)

Louis

On Mar 25, 2011, at 12:49 AM, John Engelhart  wrote:

> I've considered the "assume everyone and everything practices proper duck
> typing" and just make @interface MYMutableArray : MYArray.  There is one
> corner case that I can think of where this breaks:
> [myMutableArrayInstance isKindOfClass:[NSMutableArray class]].  Granted,
> doing this is frowned on as "not proper Objective-C programming", but none
> the less, I'm sure some people do it.  I'm also not entirely sure how this
> might interact with serialization, either NSCoder or property lists.
> Currently, my spot checks of NSCoder behavior causes the instances to be
> serialized as NSArray or NSMutableArray, which is just fine and what I want
> since the sole reason that I'm creating these custom classes is for bulk
> creation of collection objects very, very quickly.
> 
> Can anyone think of corner cases in which these would not behave
> "identically" to their respective concrete Cocoa versions?  KVO / KVC?
> Anything "weird" but still considered legitimate?  The CoreFoundation
> CFArray... / CFDictionary calls seem to work as expected (but I can't say
> I've done a comprehensive test of everything).  Fast enumeration and block
> based enumeration works, though come to think of it I haven't tried the
> "parallel" option.  Distributed Objects... CoreData?  I'd like to provide
> "maximally compatible" if at all possible, and if not, then clearly document
> the limitations / caveats.
___

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: [iPhone] How to create a unique string

[Louis Gerbarg]

On May 13, 2010, at 11:05 AM, Michael Ash  wrote:

> On Thu, May 13, 2010 at 10:56 AM, Thomas Davie  wrote:
>> 
>> On 13 May 2010, at 15:33, Eric Gorr wrote:
>> 
>>> So long as it is ok for the string to be unique for the network the user is 
>>> on only. From the docs:
>>> 
>>> The ID includes the host name, process ID, and a time stamp, which ensures 
>>> that the ID is unique for the network.
>>> 
>>> A UUID (Universally Unique Identifier) is entirely unique.
>> 
>> No it's not, as can easily be proven by observing that there are only a 
>> finite number of 40 character strings.  A UUID is probabilistically unique.
> 
> CFUUID includes the MAC address, so unless your MAC address is cloned
> or you manage to generate two UUIDs on the same device in the same
> 100ns time interval or the calendar rolls over (which will take about
> 3700 years), they are entirely unique within the universe of CFUUID
> strings.

No, it doesn't use the MAC address. MAC addresses are uses as part of type 1 
uuids, CFUUID has generated type 4 (random) uuids by default since Tiger, and 
has always generated type 4 on iPhone. If you look at the source to CF there is 
a way to force it to generate type 1 uuids, but I doubt that is supported. 

Louis  ___

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: BIG Thread problem (theorical).. need some advice.

[Louis Gerbarg]

On Tue, Jan 26, 2010 at 7:52 AM, Gustavo Pizano  wrote:

>
> I duno if its the best solution but it works.. Im open to hear other
> approaches...
>
>
This isn't a threading issue, everything is happening on a single thread.
The issue is that you have a synchronous API that depends on an asynchronous
API underneath. You have correctly deduced that one way to handle this is to
spin in a loop (in this case an event loop) waiting for the asynchronous API
to complete so you can return the data. In many cases that is a reasonable
solution, though if you get several of these things nested together or are
using weird runloop modes you can start to have some very complex behaviors.
You also potentially need to make sure any code in the call stack leading up
to that runloop reentrant, depending on exactly what you are doing.

Personally, I prefer to make my design asynchronous all the way up and down
the stack. So instead of implementing something like:

-(NSDictionary *)pListWithWebElements;

I might do:

- (void) updatePListWebElements; //Exact same IMP except it doesn't return
anything

and then in the load delegate:

#pragma mark LoadFrameDelegate.
-(void)webView:(WebView *)sender didFinishLoadForFrame:(WebFrame *)frame{
  //Your original code
  

  [[NSNotificationCenter defaultCenter]
postNotificationName:@"PListWithWebElementsLoaded"
object:self];
}

which would then fire an NSNotification at the time it was updated, and I
would just register a notification handler to deal with it. Depending on the
exact nature and complexity of what is going on it may also be apropriate to
implement your own delegate protocol and make calls into the delegate just
like the system does with your delegates.

Louis
___

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: Sensible way to extend base class?

[Louis Gerbarg]

As several people have mentioned, doing this kind of thing is very skanky,
and it won't work properly under GC without some additional machinery. But
if GC is not a concern you can do something that works with a bit grotesque
monkey patching.
The below code is generic, but it mucks with everything. I recommend you
always trim it down from NSObject to whatever class you are actually doing
it to.

Louis

#import 

#import 


@interface NSObject (LGAssociativeStorage)

@property (retain) id associatedObject;

@end

---


#import 

#import "LGAssociativeStorage.h"


/* We are using STL containers because:

   1) Using Objective C containers can cause deallocs which cause recursion
issues

   2) STL containers are high perf containers that don't introduce external
code dependencies

   Ideally one could include a thread safe map implementation, but I don't
need one currently

*/


#include 


typedef std::map idMap_t;

typedef std::pair idPair_t;


static NSMutableDictionary * data = nil;

static pthread_mutex_t data_lock = PTHREAD_MUTEX_INITIALIZER;

static IMP gOriginalNSObjectDealloc = nil;

static idMap_t associatedObjectMap;


static

void removeAssociatedObjectFromMap(id self) {

  idMap_t::iterator iter = associatedObjectMap.find(self);

if( iter != associatedObjectMap.end() ) {

[iter->second release];

associatedObjectMap.erase(iter);

}

}


static

id newNSObjectDealloc(id self, SEL deallocSelector, ...) {

pthread_mutex_lock(&data_lock);

removeAssociatedObjectFromMap(self);

pthread_mutex_unlock(&data_lock);

return gOriginalNSObjectDealloc(self, deallocSelector);

}


static void initIfNecessary(void) {

if (!data) {

data = [[NSMutableDictionary alloc] init];

 // The below line of code is abusive... in the future the Objective C
runtime will use it as evidence

// that I am an unfit software engineer and take custody of all my code

gOriginalNSObjectDealloc = class_replaceMethod([NSObject class], @selector(
dealloc), newNSObjectDealloc, "v@:");

}

}




@implementation NSObject (LGAssociativeStorage)


- (id) associatedObject {

id retval = nil;

pthread_mutex_lock(&data_lock);

initIfNecessary();

idMap_t::iterator iter = associatedObjectMap.find(self);

if( iter != associatedObjectMap.end() ) {

retval = iter->second;

}

pthread_mutex_unlock(&data_lock);

return retval;

}


- (void) setAssociatedObject:(id)object_ {

pthread_mutex_lock(&data_lock);

initIfNecessary();

removeAssociatedObjectFromMap(self);

[object_ retain];

associatedObjectMap.insert(idPair_t(self, object_));

pthread_mutex_unlock(&data_lock);

}


@end
___

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: Performance problem with GC enabled

[Louis Gerbarg]

On Fri, Mar 13, 2009 at 12:04 PM, Paul Sanders  wrote:
>
> (Off topic again): Call me old-fashioned, but I don't like autorelease pools
> all that much.  I believe Cocoa could have gotten along just fine without
> them, had they never been invented.  I prefer C++-style 'smart pointers'
> that delete (or release) themselves when they go out of scope.  That way you
> avoid the loss of determinism and potential memory usage peaks that
> autorelease pools introduce and it's really not painful writing code that
> way.  It's a pity that Objective-C doesn't support such a construct - life
> would have been so much easier.  But it's far too late now.

Autorelease pools exist explicitly for passing things out of scopes
("return [retval autorelease];"), otherwise you have to deal with
substantially more complicated ownership semantics for all methods
that return objects. The fact that people have overloaded them to
emulate scoped release a has more to do with people not wanting to
have to cleanup after themselves and the autorelease infrastructure
already existing. Now, having said that, I don't tend to use
autoreleased objects inside a scope they won't escape because I would
rather not bloat my apps high watermark and fragment my zones.
Instead, I do something along these lines:

#define autoscoped __attribute__((cleanup(releaseObject)))

static inline
void releaseObject(id *object) {
   [*object release];
}

- (void) demo {
    autoscoped NSArray *myArray = [[NSArray alloc] init];
    //do some stuff
}

The autoscoped macro tags the lval with an attribute that causes the
cleanup function to be called when the lvals scope disappears.

It is not quite the same as a smart pointer, but it does allow me to
have objects automatically released when their scope disappears,
without causing autorelease traffic.

Louis
___

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: What's the use of the Z_UUID in the Z_METADATA table?

[Louis Gerbarg]

Performing migrations by altering the underlying structure of files you do
not understand will most likely result in data corruption. Even if the file
appears to work correctly now, that does not mean it is correct, and it does
not mean that it will continue to work in the future, especially if you have
violated any assumption that future schema migrators make about the DB file.
Louis

On Wed, Aug 13, 2008 at 9:56 AM, Gustavo Vera <[EMAIL PROTECTED]> wrote:

> Maybe I should not, but I'm doing it anyway :D
> I'm looking inside and also I'm manipulating the structure and data of the
> sqlite file since about 200 revisions in my project. I'm doing this to
> provide newer versions of the app that has the possibility of performing
> database migrations / upgrades from older versions of the app if available.
> With the new functionalities, occasionally a change in the database
> structure results necessary, and when the change is simple (for example,
> just adding a new attribute to an entity) altering the data model and the
> data structures in an old sqlite is far easier and faster than implementing
> the migration functionality suggested in the documentation. In fact, I
> think
> this is faster and easier even when more complex changes are necessary.
> Anyway... I was wondering if I should take care of the Z_UUID during the
> perform of this upgrades, or if I can just ignore it. I'm currently
> ignoring
> it... can this become a problem in the future?
>
>
> On Tue, 12 Aug 2008 17:28:39 -0300, Marcelo Alves
> <[EMAIL PROTECTED]> wrote:
>
> >
> >  It is a implementation detail. You should not look inside the sqlite
> file.
> >
> > 2008/8/12 Gustavo Vera <[EMAIL PROTECTED]>:
> > > What's the use of the Z_UUID in the Z_METADATA table?
> > > Is some kind of check sum or something like that?
> > > CoreData uses this value for something?
> > > Why is this value different every time the DB is regenerated?
> > > Is the generation of it a random-based one? Or is it based on
> > > random+"another thing"?
> > >
> > > Please don't answer my question with another question!!! At least not
> at
> > > first instance! :D
> > >
> > > Thanks in advance!
> >
> ___
>
> 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/lgerbarg%40gmail.com
>
> This email sent to [EMAIL PROTECTED]
>
___

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 [EMAIL PROTECTED]

Re: Rethinking my approach; rather overwhelmed.

[Louis Gerbarg]

I have not used glut for any OS X based projects, but my impression is
that if you intend to use no OS facilities in the window you are
interacting with then glutKeyboardFunc() and friends should work just
fine. If you want to use a WebView or anything that expects NSEvents
in that window you are probably going to find it much more
complicated. Instead of just consuming the incoming NSEvents you want
and passing on the rest you will need to synthesize NSEvents for
anything you want to pass on.

In general mixing and matching event models is a lot more pain than it
is usually worth. If you are going to write a pure OpenGL based
application then glut will probably serve you well, if you intend to
use any Cocoa facilities (such as WebKit) you are going to have to
work with the native event system at some point along the way, and I
suspect converting glut style events into something the rest of the
stack can use is a lot more (platform specific) code than just
extracting what you want from the NSEvents in the first place.

Louis

On Tue, Jun 17, 2008 at 9:28 PM, Josh de Lioncourt
<[EMAIL PROTECTED]> wrote:
> Hi Louis and Andy,
>
> I'm certainly looking at this suggestion, but another developer suggested
> that I may be better served by hooking into the keyboard input functionality
> of OpenGL.  Assuming that have focus on an NSWindow doesn't interfere with
> such an implementation, I'd be able to accomplish the input through a
> non-platform specific API, potentially making my code even more portable
> between Windows and OS X.
>
> Is there any reason why I shouldn't consider OpenGL for input?
>
>
> Josh de Lioncourt
> Mac-cessibility: http://www.Lioncourt.com
> Twitter: http://twitter.com/Lioncourt
>
>
> "The rich declare themselves poor,
> "And most of us are not sure,
> "If we have too much,
> "But we'll take our chances,
> "'cause God stopped keeping score."
> Praying for Time--George Michael
>
>
>
>
> On Jun 17, 2008, at 5:03 PM, Andreas Monitzer wrote:
>
>> On Jun 18, 2008, at 01:22, Louis Gerbarg wrote:
>>
>>> It sounds like what you want to do is here is subclass NSApplication,
>>> with a replacement implementation of sendEvent that decodes the
>>> incoming events, marshals the NSEvent's parameters, then sends them to
>>> your C++ code for processing. If your C++ code uses them you swallow
>>> the event, if not you pass it onto the superclasses implementation and
>>> the app code will handle them just like any other Cocoa application.
>>
>> Note that this is just what I did for the X-server:
>>
>>
>> http://www.google.com/codesearch?hl=en&q=monitzer+show:Nu3rlWhknBM:x28_xYSo3mE:b82DNfVvtyQ&sa=N&cd=1&ct=rc&cs_p=http://gentoo.osuosl.org/distfiles/X430src-3.tgz&cs_f=xc/programs/Xserver/hw/darwin/quartz/XApplication.m
>>
>> This can serve as an example on how to implement something like this. Just
>> don't forget to declare this subclass to be the principal class of the
>> application bundle.
>>
>> andy
>
> ___
>
> 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/lgerbarg%40gmail.com
>
> This email sent to [EMAIL PROTECTED]
>
___

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 [EMAIL PROTECTED]

Re: Rethinking my approach; rather overwhelmed.

[Louis Gerbarg]

On Tue, Jun 17, 2008 at 2:42 PM, Josh de Lioncourt
<[EMAIL PROTECTED]> wrote:

>> 2. Complex keyboard control.  We need to be able to intercept keystrokes,
>> be able to determine when keys are pressed or released, held in combination,
>> etc.  This includes the pressing of modifier keys alone.  We need to let
>> these keys pass through to the OS unless the game has need of them.  Many
>> games do this sort of keyboard control.  Under Windows we used DirectInput,
>> a component of DirectX to accomplish this.
>>

It sounds like what you want to do is here is subclass NSApplication,
with a replacement implementation of sendEvent that decodes the
incoming events, marshals the NSEvent's parameters, then sends them to
your C++ code for processing. If your C++ code uses them you swallow
the event, if not you pass it onto the superclasses implementation and
the app code will handle them just like any other Cocoa application.

Depending on exactly how complicated your internal event
representation is this might be anywhere from a couple dozen to a
couple hundred lines of objc, but it should be identical from project
to project once you get it done. This kind of thing can be a bit on
the tricky side, but since it should be short and reusable for
basically all of your projects that is probably acceptable.

>> 3. Obviously, timing is everything in most computer games.  Timing down to
>> milliseconds is essential.  Nanoseconds is overkill.  I understand the
>> concepts for getting the timing working with mach_absolute_time() on the Mac
>> using Duration objects to measure the time in milli/micro seconds, but have
>> yet to actually come up with working code.  I suspect this is because I am
>> far from adept in Objective C at this point.  I don't believe I can write
>> such code in C++ to take advantage of mach_absolute_time(), but if would
>> love to be proven wrong.

There is nothing preventing you from directly calling
mach_absolute_time from C++ if you want, it is a pure C function.. I
would recommend using gettimeofday() instead. It has millisecond
precision, and is a standard POSIX API that tons of OSes support (so
there is lots of sample code out there).

Louis
___

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 [EMAIL PROTECTED]

Re: Efficient XML loading [continuation of NSString from mapped NSData thread]

[Louis Gerbarg]

NSXMLParser needs to load everything into ram first, then it starts
generating its stream of events. I recommend filing a bug asking for
it to be enhanced to support incrementally available data. It will
definitely be a dupe (I've filed it, among others I am sure)., but the
more people who ask for it, the more likely it will get engineering
resources.

For situations where you have slow connections, high latency, large
documents, and/or limited ram being able to work with the file as a
stream is definitely a competitive advantage. While I (and a lot of
other people, I am certain) have written libxml2 interfaces to achieve
that, I would much rather just use NSXMLParser in the future.

Louis

On Wed, May 14, 2008 at 11:04 AM, Jens Alfke <[EMAIL PROTECTED]> wrote:

> I am nearly always cheerfully willing to give out source code, but in this
> case I kind of see this as a competitive advantage for a product I might
> release in the future, so I'm going to keep the code to myself. It isn't
> brain surgery, or even rocket science, but it took some work; libxml2 is a
> lot lower-level than the plist API. (I didn't try using NSXMLParser, which
> is an Obj-C wrapper around libxml2; that might get you comparable
> performance with less pain.)
>
> —Jens
> ___
>
> 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/lgerbarg%40gmail.com
>
> This email sent to [EMAIL PROTECTED]
>
___

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 [EMAIL PROTECTED]