Re: Debugging insight needed for NSKeyedUnarchiver
On 3 Mar 2014, at 5:09 pm, Graham Cox wrote: > Since I suspect some sort of memory overflow to be causing the problem, I did > attempt to use the usual tools for this - guard malloc, scribbling, etc, but > nothing showed up. Once again the opaque nature of a framework class makes > tracking down a bug extremely difficult - if the dearchiver were my own code > it would probably become trivial. Are there any other tools I could use to > detect memory corruption? OK, I've identified the problem - and it's not memory corruption. It does throw up a new question though. In one of my class's -initWithCoder: method, I do some sanity checking on a number of values. If some of these values are zero, it indicates an unviable object, in that far, far down the track, these zero values are used in a calculation that leads to a NaN value being passed to Core Graphics. (div by zero). So, if I detect these zeros in -initWithCoder, I autorelease self, set self to nil and return nil. This is in accordance with the usual rules for -init. It appears as though doing this in -initWithCoder : may not be legitimate. This is only one object among hundreds, and not dearchiving it should not affect other objects in the archive. However, it does, in that returning nil here prevents objects which are peers of this one from being added to the array that should be returned - that's why the array is returned empty. It's as if the dearchiving code is using -arrayWithObjects:, but because the first item in the list is nil, the rest are skipped, even though they have been decoded fine. If I return a substitute object instead, everything else dearchives correctly. However, the substitute object is really undesirable - I'd rather it were simply removed. I can probably do that by some roundabout means, but the more general question here is whether returning nil from -initWithCoder: should be legitimate or not. After all, it's an init method, and it should follow the rules for all other init methods, shouldn't it? If it should, then NSKeyedUnarchiver must be considered to have a bug. If this isn't legitimate, then where is it documented? --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSOperation Dispatch Thread Soft Limit
I have a MyOperation, subclass of NSOperation. MyOperation does: create an NSOperationQueue add a few MyOperations to this queue waitUntilAllOperationsAreFinished (obviously this recursion stops at some point - I do not create an infinite number of operations). The good thing: this is very energy saving: cpu utilisation = 0% The bad thing: nothing gets done. Using Activity Monitor to sample my app I see: "Dispatch Thread Soft Limit: 64 reached in 2152 of 2152 samples -- too many dispatch threads blocked in synchronous operations" Using trial and error, I managed to not create too many operations, so that this blocking does not happen anymore. But: Is there some way to find out programmatically at which point my app should stop adding operations? Either with NSOperationQueue or GCD. 10.9.2 Gerriet. ___ 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: Debugging insight needed for NSKeyedUnarchiver
On Mar 2, 2014, at 23:58 , Graham Cox wrote: > the more general question here is whether returning nil from -initWithCoder: > should be legitimate or not. After all, it's an init method, and it should > follow the rules for all other init methods, shouldn't it? What are you suggesting that these rules are? AFAIK, there isn’t any “rule” about whether an init method can return nil — it’s part of the API contract in each individual case, isn’t it? IAC, I don’t think it’s exactly about whether initWithCoder returns nil. Surely it’s about the fact that decoding a NSArray can’t deal with a nil element, since it can’t be inserted into the array. Simply dropping nil elements doesn’t even seem like a possible strategy. I think you have to assume that it’s your responsibility not to return nil when the object being decoded is part of a collection**. After all, it was certainly non-nil when it was originally archived. I’d also say there’s a parallel problem when *not* dealing with array elements. If in unarchiving an object (*not* in a collection) you return nil from ‘initWithCoder’ (under the assumption that the object wasn’t nil when archived), you’ll end up with a “hole” in your data model, and you won’t know about it. Putting those two things together, it seems that simply returning nil from initWithCoder should *never* be done, which is the policy I’ve always followed. ** Which is, in general, unknowable. ___ 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: NSDocument save incremental file package in-place
If you do end up writing your own safe-saving logic, that's achieved by overriding -writeSafelyToURL:… Sent from my iPad On 2 Mar 2014, at 15:23, Trygve Inda wrote: >> 7,500 file operations of any kind are going to take some time, even just >> creating hard links. Does it require 40 seconds? Well, I don't know. But I do >> seriously doubt that it could be done in 1 second. >> >> You might try it out yourself, write test code to create a new package, walk >> through your package, and create hard links in the new to the old. If that >> takes too long, then you're done, you can't do incremental save this way. >> (And >> of course, if it's fast enough, then continue on this course and try to >> figure >> out how to make it happen that way.) >> >> It just seems to me that 7,500 files is bordering on being a database of >> images, and calls for the typical database techniques. In other words, write >> new image files into a temp location within the package, write a log of >> changes about to happen, apply the changes (move the new files into place), >> and delete the log. Then your recovery code checks for a log, if it's there >> move any files still in the temp location into their proper final location, >> and delete the log. > > It is essentially a database of images. > > How can I override the various NSDocument methods so that I can write the > changes/updates myself in a temp place within my own package (which makes it > safe). > > There is just no reason to touch the other 7500 files at all. > > > > ___ > > 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/mabdullah%40karelia.com > > This email sent to mabdul...@karelia.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: Debugging insight needed for NSKeyedUnarchiver
On 3 Mar 2014, at 7:48 pm, Quincey Morris wrote: > What are you suggesting that these rules are? AFAIK, there isn’t any “rule” > about whether an init method can return nil — it’s part of the API contract > in each individual case, isn’t it? The documentation for -init states: "If the new object can’t be initialized, the method should return nil. In some cases, an init method might return a substitute object. You must therefore always use the object returned by init, and not the one returned by alloc or allocWithZone:, in subsequent code." This has also been the subject of much discussion that I've seen over the years of how to actually do this, and what I do is to call [self autorelease]; then self = (either a new retained object or nil); return self; This then gets further complicated by designated initializers and the like, but the basic idea remains. - initWithCoder: is just the designated initializer used when dearchiving, so my reading of it is that it "inherits" the rules about returning nil or another object from -init. The documentation for -initWithCoder: states (and this seems to be something added recently) that -initWithCoder: must return self. However it does not say anything about self being reassigned or set to nil like any other init method is permitted to do. > IAC, I don’t think it’s exactly about whether initWithCoder returns nil. > Surely it’s about the fact that decoding a NSArray can’t deal with a nil > element, since it can’t be inserted into the array. Simply dropping nil > elements doesn’t even seem like a possible strategy. Why not? If I decode a list of objects into an array, it would be a very simple matter when looping over those objects to skip nil items. If the code uses -arrayWithObjects: instead, then that's a choice made by its designer, not the only possible way to do it. I would argue that it's definitely the wrong choice - it's making an assumption about how external code is operating. Looking at it from the opposite point of view, if you have five objects in an archive but only the first one is invalid and can't be initialized, then why should it go on to drop the remaining four objects in that array? It certainly doesn't stop it from dearchiving further objects in a different array. Or, if the first two objects were fine, but number 3 was nil, then you end up with two objects in the array instead of four. How is that behaviour useful or consistent? What you get depends on the order of the items in the array, which seems to me unintentional - if there were a (documented) rule that says if any object is nil the whole array ends up empty then OK, but right now it contains the objects up to, but not following, the nil object. > I think you have to assume that it’s your responsibility not to return nil > when the object being decoded is part of a collection**. After all, it was > certainly non-nil when it was originally archived. Yes, but the discussion for -init says it's fine to return nil "if the new object can't be initialized". There are many good reasons why an object could be archived but when dearchiving it would be better to skip it, such as the case I am faced with. > I’d also say there’s a parallel problem when *not* dealing with array > elements. If in unarchiving an object (*not* in a collection) you return nil > from ‘initWithCoder’ (under the assumption that the object wasn’t nil when > archived), you’ll end up with a “hole” in your data model, and you won’t know > about it. I'm not sure about that. If your code deliberately does work to discontinue initialization, then you definitely know about it. > Putting those two things together, it seems that simply returning nil from > initWithCoder should *never* be done, which is the policy I’ve always > followed. If that's the conclusion, which I'm not yet convinced about, then it should be documented. I can't find anywhere that says that. It would also be a simple matter to enforce it - NSKeyedUnarchiver could throw an exception if an object was allocated but returned nil from -initWithCoder:. It does not do that, so it's obviously not considering it as an error. (This is distinct from having a nil value actually archived - in that case there is no object allocated). --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Debugging insight needed for NSKeyedUnarchiver
On 3 Mar 2014, at 09:47, Graham Cox wrote: > > >> IAC, I don’t think it’s exactly about whether initWithCoder returns nil. >> Surely it’s about the fact that decoding a NSArray can’t deal with a nil >> element, since it can’t be inserted into the array. Simply dropping nil >> elements doesn’t even seem like a possible strategy. > > Why not? If I decode a list of objects into an array, it would be a very > simple matter when looping over those objects to skip nil items. If the code > uses -arrayWithObjects: instead, then that's a choice made by its designer, > not the only possible way to do it. I would argue that it's definitely the > wrong choice - it's making an assumption about how external code is operating. > I agree that skipping nil items seems, from our perspective, like a sound idea. However, it is seemingly not to be. It is hard to argue with the statement that you must return self from initWithCoder:. Have you considered using: - (id)awakeAfterUsingCoder:(NSCoder *)aDecoder The docs say: If you have an advanced need that requires substituting a different object after decoding, you can do so in awakeAfterUsingCoder:. This sounds like it might offer an out. I am not sure of the detail but the docs for -awakeAfterUsingCoder allow a substitute object to be returned. Perhaps you use a single proxy object to represent all the invalid ones. Otherwise it might be possible to return NSNull +null from -initWithCoder:, though that violates the -initWithCoder: stricture to return self. When the archive is complete you can remove the proxies/NSNull instances from the collection. Given that the object doesn’t decode it would be better if it wasn’t encoded in the first place; but I imagine that is a fait accompli. Jonathan ___ 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: Debugging insight needed for NSKeyedUnarchiver
On 3 Mar 2014, at 9:56 pm, jonat...@mugginsoft.com wrote:
> It is hard to argue with the statement that you must return self from
> initWithCoder:.
Well, except what is self? It's perfectly legitimate in an init method to write
self = . ***that's why you always check if( self ){} after
calling super in all init methods, including -initWithCoder:.***
Documenting that you must return self means nothing - you always return self
from an init method. What it does not state (and perhaps should) is that unlike
other init methods, self may not be reassigned or set to nil.
> Have you considered using:
>
> - (id)awakeAfterUsingCoder:(NSCoder *)aDecoder
Yes, indeed that's what I am doing. It seems to work and it certainly fixes my
problem.
But if there are some rules which need to be made clearer here (rather than
just my own understanding), then it still might be worth flushing them out so I
can file a bug on the documentation at least.
--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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSOperation Dispatch Thread Soft Limit
Hi, On 3 Mar 2014, at 09:43, Gerriet M. Denkmann wrote: > I have a MyOperation, subclass of NSOperation. > > MyOperation does: > create an NSOperationQueue > add a few MyOperations to this queue > waitUntilAllOperationsAreFinished > (obviously this recursion stops at some point - I do not create an infinite > number of operations). > > The good thing: this is very energy saving: cpu utilisation = 0% > The bad thing: nothing gets done. > > Using Activity Monitor to sample my app I see: > > “Dispatch Thread Soft Limit: 64 reached in 2152 of 2152 samples -- too many > dispatch threads blocked in synchronous operations" IMO the problem is not really the limit itself, but the second part of the message: That your operations themselves are blocking. If you haven’t, take a look at https://www.mikeash.com/pyblog/friday-qa-2009-09-25-gcd-practicum.html He has reasonably expensive blocks, so he aims to have 2x cpuCores operations in flight (and does IO scheduling). > But: Is there some way to find out programmatically at which point my app > should stop adding operations? That depends largely on what your operations do (e.g. whether I/O is involved, duration, dependencies, …). Somehow (constant) scaling with the number of cores available in the machine seems like a good start, as you cannot ever execute more things in parallel. Daniel. ___ 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
Public API method naming for NSString * / const char * parameters
I am pondering the following framework public API method signatures. The API requires a mixture of const char* and NSString * parameters. The question is whether to precede const char * parameter names with UTF8 e.g.: + (MonoClass *)monoClassWithName:(char *)className fromAssemblyName:(const char *)assemblyName; becomes + (MonoClass *)monoClassWithUTF8Name:(char *)className fromAssemblyUTF8Name:(const char *)assemblyName; I have doubts in case that NSString * convenience variants become desirable in the future. Just wondering how others have approached this. === + (MonoClass *)monoClassWithName:(char *)className fromAssemblyName:(const char *)assemblyName; - (MonoClass *)monoClassWithName:(char *)className fromAssemblyName:(const char *)name; + (MonoClass *)monoClassWithName:(char *)className fromAssembly:(MonoAssembly *)assembly; + (MonoClass *)corlibMonoClassWithName:(char *)className; + (MonoClass *)dubrovnikMonoClassWithName:(char *)className; + (MonoMethod *)dubrovnikMonoMethodWithName:(char *)methodName className:(char *)className argCount:(int)argCount; - (MonoAssembly *)loadedAssemblyWithName:(const char *)name; - (MonoAssembly *)loadedAssembly:(NSString *)name; - (MonoAssembly *)openAssemblyWithName:(const char *)name; - (MonoAssembly *)openAssemblyWithPath:(NSString *)assemblyPath; - (MonoAssembly *)openAssembly:(NSString *)name path:(NSString *)assemblyPath; - (MonoAssembly *)openAssemblyWithName:(const char *)name path:(NSString *)path; Jonathan ___ 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: Public API method naming for NSString * / const char * parameters
I would say that adding UTF8 to the method names implies that the framework expects UTF8, if that's true, that's a good method name. If you want to support other encodings then a method name which takes a char* and an encoding would be better, still including a UTF8 version which just calls the char*+encoding version with a fixed UTF8 encoding. I would say that in this encoding-enlightened day and age +(XX)xxWithName:(char*)name; is lacking. If that name is meant to be UTF-8, say so, it's a few extra characters. On 3 Mar, 2014, at 10:37 pm, jonat...@mugginsoft.com wrote: > I am pondering the following framework public API method signatures. > > The API requires a mixture of const char* and NSString * parameters. > > The question is whether to precede const char * parameter names with UTF8 > e.g.: > > + (MonoClass *)monoClassWithName:(char *)className fromAssemblyName:(const > char *)assemblyName; > > becomes > > + (MonoClass *)monoClassWithUTF8Name:(char *)className > fromAssemblyUTF8Name:(const char *)assemblyName; > > I have doubts in case that NSString * convenience variants become desirable > in the future. > > Just wondering how others have approached this. > > === > > + (MonoClass *)monoClassWithName:(char *)className fromAssemblyName:(const > char *)assemblyName; > - (MonoClass *)monoClassWithName:(char *)className fromAssemblyName:(const > char *)name; > + (MonoClass *)monoClassWithName:(char *)className fromAssembly:(MonoAssembly > *)assembly; > + (MonoClass *)corlibMonoClassWithName:(char *)className; > > + (MonoClass *)dubrovnikMonoClassWithName:(char *)className; > + (MonoMethod *)dubrovnikMonoMethodWithName:(char *)methodName > className:(char *)className argCount:(int)argCount; > > - (MonoAssembly *)loadedAssemblyWithName:(const char *)name; > - (MonoAssembly *)loadedAssembly:(NSString *)name; > > - (MonoAssembly *)openAssemblyWithName:(const char *)name; > - (MonoAssembly *)openAssemblyWithPath:(NSString *)assemblyPath; > - (MonoAssembly *)openAssembly:(NSString *)name path:(NSString *)assemblyPath; > - (MonoAssembly *)openAssemblyWithName:(const char *)name path:(NSString > *)path; > > Jonathan > > > > > > > > > > > > > ___ > > 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/rols%40rols.org > > This email sent to r...@rols.org ___ 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: Public API method naming for NSString * / const char * parameters
First, why not have just the NSString versions? Are you working in an environment where Foundation might not/will not be linked? Are these selectors bound to library functions that must take char *’s and you can’t afford the overhead of a second method dispatch or function call (bearing in mind that that just means you’re forcing your API’s consumers to do the conversion before the call themselves, as they’ll likely be working with NSStrings)? If not, don’t have the char * params at all, and take NSString * instead. But, assuming for the moment that you have a really good reason for such a Cocoa-unfriendly API: “UTF8Name" is highly specific. I’d first consider what your source encoding is (both of the strings that are likely to be passed to this method and of whatever data it’s searching). Do these class names ever even have characters from outside the ASCII character set or could they in the future? “CStringName” is a better name if neither. If they don’t now but might in the future, their representation to your framework may not even be in UTF8 and you’ll just end doing conversions back and forth. Any method that takes a C string without explicitly specifying an encoding in the method name (like "UTF8Name”) really should take an encoding as well. Daniel On Mar 3, 2014, at 3:37 PM, jonat...@mugginsoft.com wrote: > I am pondering the following framework public API method signatures. > > The API requires a mixture of const char* and NSString * parameters. > > The question is whether to precede const char * parameter names with UTF8 > e.g.: > > + (MonoClass *)monoClassWithName:(char *)className fromAssemblyName:(const > char *)assemblyName; > > becomes > > + (MonoClass *)monoClassWithUTF8Name:(char *)className > fromAssemblyUTF8Name:(const char *)assemblyName; > > I have doubts in case that NSString * convenience variants become desirable > in the future. > > Just wondering how others have approached this. > > === > > + (MonoClass *)monoClassWithName:(char *)className fromAssemblyName:(const > char *)assemblyName; > - (MonoClass *)monoClassWithName:(char *)className fromAssemblyName:(const > char *)name; > + (MonoClass *)monoClassWithName:(char *)className fromAssembly:(MonoAssembly > *)assembly; > + (MonoClass *)corlibMonoClassWithName:(char *)className; > > + (MonoClass *)dubrovnikMonoClassWithName:(char *)className; > + (MonoMethod *)dubrovnikMonoMethodWithName:(char *)methodName > className:(char *)className argCount:(int)argCount; > > - (MonoAssembly *)loadedAssemblyWithName:(const char *)name; > - (MonoAssembly *)loadedAssembly:(NSString *)name; > > - (MonoAssembly *)openAssemblyWithName:(const char *)name; > - (MonoAssembly *)openAssemblyWithPath:(NSString *)assemblyPath; > - (MonoAssembly *)openAssembly:(NSString *)name path:(NSString *)assemblyPath; > - (MonoAssembly *)openAssemblyWithName:(const char *)name path:(NSString > *)path; > > Jonathan > > > > > > > > > > > > > ___ > > 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/danhd123%40mac.com > > This email sent to danhd...@mac.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: Public API method naming for NSString * / const char * parameters
Forgot to add, if your framework *does* expect and will continue to expect UTF8 strings, then yes, “UTF8Name” is a fine choice. Daniel On Mar 3, 2014, at 4:19 PM, Daniel DeCovnick wrote: > First, why not have just the NSString versions? > > Are you working in an environment where Foundation might not/will not be > linked? Are these selectors bound to library functions that must take char > *’s and you can’t afford the overhead of a second method dispatch or function > call (bearing in mind that that just means you’re forcing your API’s > consumers to do the conversion before the call themselves, as they’ll likely > be working with NSStrings)? If not, don’t have the char * params at all, and > take NSString * instead. > > But, assuming for the moment that you have a really good reason for such a > Cocoa-unfriendly API: > > “UTF8Name" is highly specific. I’d first consider what your source encoding > is (both of the strings that are likely to be passed to this method and of > whatever data it’s searching). Do these class names ever even have characters > from outside the ASCII character set or could they in the future? > “CStringName” is a better name if neither. If they don’t now but might in the > future, their representation to your framework may not even be in UTF8 and > you’ll just end doing conversions back and forth. Any method that takes a C > string without explicitly specifying an encoding in the method name (like > "UTF8Name”) really should take an encoding as well. > > Daniel > > On Mar 3, 2014, at 3:37 PM, jonat...@mugginsoft.com wrote: > >> I am pondering the following framework public API method signatures. >> >> The API requires a mixture of const char* and NSString * parameters. >> >> The question is whether to precede const char * parameter names with UTF8 >> e.g.: >> >> + (MonoClass *)monoClassWithName:(char *)className fromAssemblyName:(const >> char *)assemblyName; >> >> becomes >> >> + (MonoClass *)monoClassWithUTF8Name:(char *)className >> fromAssemblyUTF8Name:(const char *)assemblyName; >> >> I have doubts in case that NSString * convenience variants become desirable >> in the future. >> >> Just wondering how others have approached this. >> >> === >> >> + (MonoClass *)monoClassWithName:(char *)className fromAssemblyName:(const >> char *)assemblyName; >> - (MonoClass *)monoClassWithName:(char *)className fromAssemblyName:(const >> char *)name; >> + (MonoClass *)monoClassWithName:(char *)className >> fromAssembly:(MonoAssembly *)assembly; >> + (MonoClass *)corlibMonoClassWithName:(char *)className; >> >> + (MonoClass *)dubrovnikMonoClassWithName:(char *)className; >> + (MonoMethod *)dubrovnikMonoMethodWithName:(char *)methodName >> className:(char *)className argCount:(int)argCount; >> >> - (MonoAssembly *)loadedAssemblyWithName:(const char *)name; >> - (MonoAssembly *)loadedAssembly:(NSString *)name; >> >> - (MonoAssembly *)openAssemblyWithName:(const char *)name; >> - (MonoAssembly *)openAssemblyWithPath:(NSString *)assemblyPath; >> - (MonoAssembly *)openAssembly:(NSString *)name path:(NSString >> *)assemblyPath; >> - (MonoAssembly *)openAssemblyWithName:(const char *)name path:(NSString >> *)path; >> >> Jonathan >> >> >> >> >> >> >> >> >> >> >> >> >> ___ >> >> 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/danhd123%40mac.com >> >> This email sent to danhd...@mac.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/danhd123%40mac.com > > This email sent to danhd...@mac.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: Public API method naming for NSString * / const char * parameters
On 3 Mar 2014, at 15:19, Daniel DeCovnick wrote: > But, assuming for the moment that you have a really good reason for such a > Cocoa-unfriendly API: > > “UTF8Name" is highly specific. I’d first consider what your source encoding > is (both of the strings that are likely to be passed to this method and of > whatever data it’s searching). Do these class names ever even have characters > from outside the ASCII character set or could they in the future? Hmm.That’s a good point. I was hung up on the Cocoa side of things. Commonly the char *strings represent a C# identifier http://msdn.microsoft.com/en-us/library/aa664670.aspx The rules for identifiers given in this section correspond exactly to those recommended by the Unicode Standard Annex 15. http://unicode.org/reports/tr15/ In actual fact though the identifier may represent an identifier from any CLR language. The char * is derived from XML that is sourced from reflecting on a .NET binary assembly This assembly may, in theory at least, have been written in any supported CLR language (though I have severe doubts about whether this would occur in practice). Hence the Common Language Specification could then apply: http://msdn.microsoft.com/en-us/library/12a7a7h3(v=vs.110).aspx This is governed by the CLS specification, chapter 8.5.1 "Valid names": CLS Rule 4: Assemblies shall follow Annex 7 of Technical Report 15 of the Unicode Standard 3.0 governing the set of characters permitted to start and be included in identifiers, available on-line athttp://www.unicode.org/unicode/reports/tr15/tr15-18.html. Identifiers shall be in the canonical format defined by Unicode Normalization Form C. For CLS purposes, two identifiers are the same if their lowercase mappings (as specified by the Unicode locale-insensitive, one-to-one lowercase mappings) are the same. That is, for two identifiers to be considered different under the CLS they shall differ in more than simply their case. However, in order to override an inherited definition the CLI requires the precise encoding of the original declaration be used. Unicode is not a subject about which I know much so much of the above is pretty opaque. However, UTF8 is obviously not a good choice of prefix. Perhaps Unicode or CLR/CLS would be more precise. J ___ 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: NSOperation Dispatch Thread Soft Limit
On Mar 3, 2014, at 12:43 AM, Gerriet M. Denkmann wrote: > MyOperation does: > create an NSOperationQueue > add a few MyOperations to this queue > waitUntilAllOperationsAreFinished > (obviously this recursion stops at some point - I do not create an infinite > number of operations). NSOperation already has dependency settings so you can tell an NSOperation not to start running until dependent operations finish. You should be using that instead. Having large numbers of NSOperations blocked in mid-flight is bad for scalability, as you found, because it creates lots of threads. It sounds like you’ve implemented some hierarchical algorithm in the simplest possible way. (Which is not an insult; one of the Agile principles is Do The Simplest Thing That Could Possibly Work.) The flip side of this approach is that when profiling shows you that the simple approach isn’t good enough, you have to go back and redesign it in a cleverer/faster way. —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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Public API method naming for NSString * / const char * parameters
On Mar 3, 2014, at 7:19 AM, Daniel DeCovnick wrote: > Are these selectors bound to library functions that must take char *’s and > you can’t afford the overhead of a second method dispatch or function call The OP is working with Mono, a C# runtime, so I’m sure the glue to it takes C strings. The overhead of using NSString would be greater than just a method dispatch. Converting an NSString to a UTF-8 C string will often require allocating memory, depending on the internal representation the NSString is using and whether it contains non-ASCII characters. (NSStrings are internally stored as either UTF-16 or MacRoman, not UTF-8.) —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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSOperation Dispatch Thread Soft Limit
On 3 Mar 2014, at 23:14, Jens Alfke wrote: > > On Mar 3, 2014, at 12:43 AM, Gerriet M. Denkmann wrote: > >> MyOperation does: >> create an NSOperationQueue >> add a few MyOperations to this queue >> waitUntilAllOperationsAreFinished >> (obviously this recursion stops at some point - I do not create an infinite >> number of operations). > > NSOperation already has dependency settings so you can tell an NSOperation > not to start running until dependent operations finish. You should be using > that instead. Having large numbers of NSOperations blocked in mid-flight is > bad for scalability, as you found, because it creates lots of threads. > > It sounds like you’ve implemented some hierarchical algorithm in the simplest > possible way. (Which is not an insult; one of the Agile principles is Do The > Simplest Thing That Could Possibly Work.) The flip side of this approach is > that when profiling shows you that the simple approach isn’t good enough, you > have to go back and redesign it in a cleverer/faster way. Yes, I did that. The new version: MyOperation does: if at the root of the recursion: create an NSOperationQueue add 4 MyOperations to this queue waitUntilAllOperationsAreFinished else do all stuff synchronously endif This is much faster. It is twice as fast as the single-threaded version. Only four MyOperations are ever put into an NSOperationQueue; no more blocking. Adding more operations increases the Cpu load (up to 800%), but takes longer to finish. Thanks for your suggestions! Kind regards, Gerriet. ___ 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: Public API method naming for NSString * / const char * parameters
Sure, but the consumer of the framework is still an Objective-C application or framework, which is going to be using NSStrings for everything else already and presumably up to the boundary with this framework. Why make the consumer do the conversion? If the method is going to be called “a lot”, the framework can cache UTF8 representations, just like the consumer was going to have to do anyway. Daniel On Mar 3, 2014, at 5:18 PM, Jens Alfke wrote: > > On Mar 3, 2014, at 7:19 AM, Daniel DeCovnick wrote: > >> Are these selectors bound to library functions that must take char *’s and >> you can’t afford the overhead of a second method dispatch or function call > > The OP is working with Mono, a C# runtime, so I’m sure the glue to it takes C > strings. > > The overhead of using NSString would be greater than just a method dispatch. > Converting an NSString to a UTF-8 C string will often require allocating > memory, depending on the internal representation the NSString is using and > whether it contains non-ASCII characters. (NSStrings are internally stored as > either UTF-16 or MacRoman, not UTF-8.) > > —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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Public API method naming for NSString * / const char * parameters
On 03 Mar 2014, at 17:09, jonat...@mugginsoft.com wrote: > Commonly the char *strings represent a C# identifier > http://msdn.microsoft.com/en-us/library/aa664670.aspx I can't answer this for you, but should it even be exposed in the API that it is a string? Think of SEL. Under the hood, it is still implemented as a (uniqued) string constant. Still, you're expected to use other functions to generate these things (NSSelectorFromString or objc_selectorNamed or whatever it's called). So maybe it would be better to typedef them to void* or if they're not actually constant, to wrap them in another object that allocates/releases them. -- Uli Kusterer "The Witnesses of TeachText are everywhere..." ___ 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: Public API method naming for NSString * / const char * parameters
On Mar 3, 2014, at 5:09 PM, jonat...@mugginsoft.com wrote: > > Hmm.That’s a good point. I was hung up on the Cocoa side of things. > > Commonly the char *strings represent a C# identifier > http://msdn.microsoft.com/en-us/library/aa664670.aspx > The rules for identifiers given in this section correspond exactly to those > recommended by the Unicode Standard Annex 15. http://unicode.org/reports/tr15/ > > In actual fact though the identifier may represent an identifier from any CLR > language. > The char * is derived from XML that is sourced from reflecting on a .NET > binary assembly > This assembly may, in theory at least, have been written in any supported CLR > language (though I have severe doubts about whether this would occur in > practice). > > Hence the Common Language Specification could then apply: > http://msdn.microsoft.com/en-us/library/12a7a7h3(v=vs.110).aspx > > This is governed by the CLS specification, chapter 8.5.1 "Valid names": > > CLS Rule 4: Assemblies shall follow Annex 7 of Technical Report 15 of the > Unicode Standard 3.0 governing the set of characters permitted to start and > be included in identifiers, available on-line > athttp://www.unicode.org/unicode/reports/tr15/tr15-18.html. Identifiers shall > be in the canonical format defined by Unicode Normalization Form C. For CLS > purposes, two identifiers are the same if their lowercase mappings (as > specified by the Unicode locale-insensitive, one-to-one lowercase mappings) > are the same. That is, for two identifiers to be considered different under > the CLS they shall differ in more than simply their case. However, in order > to override an inherited definition the CLI requires the precise encoding of > the original declaration be used. > > Unicode is not a subject about which I know much so much of the above is > pretty opaque. > > However, UTF8 is obviously not a good choice of prefix. > > Perhaps Unicode or CLR/CLS would be more precise. > > J > Given that, UTF8Name actually sounds fine. ___ 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: Debugging insight needed for NSKeyedUnarchiver
On Mar 3, 2014, at 01:47 , Graham Cox wrote: > On 3 Mar 2014, at 7:48 pm, Quincey Morris > wrote: > >> IAC, I don’t think it’s exactly about whether initWithCoder returns nil. >> Surely it’s about the fact that decoding a NSArray can’t deal with a nil >> element, since it can’t be inserted into the array. Simply dropping nil >> elements doesn’t even seem like a possible strategy. > > Why not? If I decode a list of objects into an array, it would be a very > simple matter when looping over those objects to skip nil items. If the code > uses -arrayWithObjects: instead, then that's a choice made by its designer, > not the only possible way to do it. I would argue that it's definitely the > wrong choice - it's making an assumption about how external code is operating. > > Looking at it from the opposite point of view, if you have five objects in an > archive but only the first one is invalid and can't be initialized, then why > should it go on to drop the remaining four objects in that array? It > certainly doesn't stop it from dearchiving further objects in a different > array. Or, if the first two objects were fine, but number 3 was nil, then you > end up with two objects in the array instead of four. How is that behaviour > useful or consistent? What you get depends on the order of the items in the > array, which seems to me unintentional - if there were a (documented) rule > that says if any object is nil the whole array ends up empty then OK, but > right now it contains the objects up to, but not following, the nil object. It can certainly be true that for some unarchived arrays, dropping un-unarchivable elements is appropriate. You’re currently dealing with such a case. That’s a valid strategy for your app, but it’s not a valid strategy for the frameworks unarchiver classes: 1. It’s not true *in general* that an array is a list of objects whose index in the array is insignificant. *In general* it must be assumed that the index matters, so dropping elements is not a possible *general* strategy. 2. It’s disingenuous to argue that it “could” unarchive and keep the rest of the array elements, and that dropping them is wild behavior. The point is that you’re asking it to do something impossible (add a nil element to a NSArray). That’s your fault, not the unarchiver’s, so don’t blame it for giving up. 3. Unarchiving contains no standard error reporting mechanism. If it were to do as you say you wish, there’d be no indication that anything was wrong. (As it is, there’s no indication that anything was wrong with the array. *That* seems like a bug — it should probably throw an exception.) 4. IMO, it’s significant that an archive is an archive, not a mere data structure. That is, it’s a representation of an object graph that’s recoverable by unarchiving. Although there’s no clear documentation on this point AFAIK, it seems at least a bit code-smelly for an object that was in the object graph at archive time to just disappear at unarchive time. Of course, you can invent cases where this doesn’t matter, but again it’s not a viable general strategy. ___ 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: Public API method naming for NSString * / const char * parameters
On Mon, Mar 3, 2014, at 09:54 AM, Daniel DeCovnick wrote: > Given that, UTF8Name actually sounds fine. No it doesn't. There's nothing in Jonathan's links to suggest that the CLS specifies that identifiers are stored in UTF-8 encoding. In fact, it implies otherwise: """Before you compare identifiers, you should filter out formatting codes and convert the identifiers to Unicode Normalization Form C, because a single character can be represented by multiple UTF-16-encoded code units. """ But Jonathan, why are you even exposing raw C pointer access to the identifiers in the first place? Why wouldn't you convert them to NSStrings and only expose them to Objective-C code that way? --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Public API method naming for NSString * / const char * parameters
On 3 Mar 2014, at 19:23, Kyle Sluder wrote:
> But Jonathan, why are you even exposing raw C pointer access to the
> identifiers in the first place? Why wouldn't you convert them to
> NSStrings and only expose them to Objective-C code that way?
>
Jens sort of nailed it.
The underlying Mono API is C.
So every call to a managed method looks something like:
onoObject *monoObject = [self invokeMonoMethod:"SumAndSwitch(double*,double*)"
withNumArgs:2, p1, p2];
The code generator wraps it up like so:
- (float)sumAndSwitch_withFloatPtrX:(float*)p1 floatPtrY:(float*)p2
{
MonoObject *monoObject = [self
invokeMonoMethod:"SumAndSwitch(single*,single*)" withNumArgs:2, p1, p2];
return DB_UNBOX_FLOAT(monoObject);
}
So only the direct access Cocoa methods have to futz with char *.
There would be an obvious overhead unboxing every NSString instance.
Plus I would have to refactor the entire legacy API.
I don’t really like all the char * pointers but given the context of the API
it’s probably for the best.
Jonathan
___
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: notification when device change in /dev
On Thu, 27 Feb 2014 07:19:26 +0800, Roland King said: >Is there an NSNotification or some other kind of notification you can >subscribe to when there's a change in /dev? I'm dealing with an old USB- >serial device which creates a cu/tty when inserted (and removed when >removed) and I'd like to get a notification when that happens so I can >update UI. > >I've hunted around the docs but clearly haven't found the right one yet. >I wish there were a master list of all system notifications somewhere, >would be handy to find them, or rule out that they exist. You might want to look at the source for AMSerialPort, which sounds pretty similar to what you're doing. It can detect new/removed devices. Cheers, -- 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSDocument save incremental file package in-place
> I did some testing about optimal number > of files per folder for our package format and 3750 files per directory are > way too many. The file system is much more efficient if you spread those > files into sub-folders. We got the best performance with a 3-level sparse > folder index (files are stored on the third folder level). I did some testing All 3750 in one folder: 40 seconds to save. Split into two levels: 16 folders -> 16 folders -> image files: 5 sec Three levels: 16 folders -> 16 folders -> 16 folders -> image files: 10 sec Seems like 2 levels is best in my case. Trygve ___ 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: Debugging insight needed for NSKeyedUnarchiver
On 4 Mar 2014, at 5:30 am, Quincey Morris wrote: > t can certainly be true that for some unarchived arrays, dropping > un-unarchivable elements is appropriate. You’re currently dealing with such a > case. That’s a valid strategy for your app, but it’s not a valid strategy for > the frameworks unarchiver classes: > > 1. It’s not true *in general* that an array is a list of objects whose index > in the array is insignificant. *In general* it must be assumed that the index > matters, so dropping elements is not a possible *general* strategy. We can agree on this point - I'm sure *in general* that keeping an object at its original index is desirable, even though in my particular case it's not important. I could settle for that. What's disagreeable is that at the moment it keeps an arbitrary number of array items and discards an arbitrary number, based on where in the array an object failed to dearchive. > 3. Unarchiving contains no standard error reporting mechanism. If it were to > do as you say you wish, there’d be no indication that anything was wrong. (As > it is, there’s no indication that anything was wrong with the array. *That* > seems like a bug — it should probably throw an exception.) Definitely. If the rules are that -initWithCoder: *must* return an object and that object *must* be the same one that was created by the internal alloc and not some other, then that needs to be spelt out in the documentation, as it is contrary to other forms of -init, and further, NSKeyedArchiver should enforce it by throwing an exception if the pointer returned by initWithCoder: is not the same as the one returned by alloc. If NSKeyedUnarchiver was doing this, I'd have discovered my bug immediately, instead of taking three very hard and wearisome days to track it down. Radar: 16215603 --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSDocument save incremental file package in-place
On Mar 3, 2014, at 14:26 , Trygve Inda wrote: > I did some testing > > All 3750 in one folder: 40 seconds to save. > > Split into two levels: 16 folders -> 16 folders -> image files: 5 sec > > Three levels: 16 folders -> 16 folders -> 16 folders -> image files: 10 sec It seems to me this would be good input for a bug report. On a HFS disk (IIRC) the directory is stored as a B-tree, presumably because it has the precise advantage of “automatically” making levels like this. If the save time is something like exponentially related to the number of levels, then that sounds like a performance weakness that Apple ought to address. ___ 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: Debugging insight needed for NSKeyedUnarchiver
On Mar 3, 2014, at 14:42 , Graham Cox wrote: > If NSKeyedUnarchiver was doing this, I'd have discovered my bug immediately, > instead of taking three very hard and wearisome days to track it down. Yes. In fact, there are at least three bugs worth reporting: 1. Inadequate documentation of the requirements of ‘initWithCoder:’s return value. 2. Lack of an exception when the unarchiving of a collection encounters a nil member. 3. Need for proper error reporting in the standard unarchiving mechanism (say, deprecating ‘initWithCoder:’ in favor of a putative ‘initWithCoder:error:’). ___ 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
