Re: A possibly simpler way to do custom Core Data migration
On 2014 Feb 23, at 01:07, Yi Lin yionco...@gmail.com wrote: After reading Apple’s docs on migration policy subclasses, I find it very convoluted I don’t find mapping models or NSMigrationPolicy to be any more complex than is necessary. There are some holes in the documentation which you’ll need to search around for. This is helpful… https://devforums.apple.com/message/146412#146412 On 2014 Feb 23, at 01:07, Yi Lin yionco...@gmail.com wrote: I can even make use of logic in my NSManagedObject subclasses to construct data in the new model instead of working with the complex mechanism in migration policy. Migration logic is ugly, rarely used, and ideally something that you aspire to delete in the distant future. I would rather have it in an NSMigrationPolicy subclass rather than muck up my managed object subclasses. ___ 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
exporting image files to disk using CGImageDestination
I've written a command line tool that takes an image file (when testing I'm using JPEG files) and applies a custom CIFilter (a naive chroma key filter I've written) and saves a file to disk. Sampling the command line tool when processing files shows it is spending 90% of its time writing the png file of which most of this time is spent in a function called deflate in libz. The final file quality is good. I'm using CGImageDestination to export the file with default settings. I thought I'd try exporting the image file as tiff instead using CGImageDestination with default settings. The command line tool is about 5 times faster but the display of the tiff file in Preview is much worse than the display of the png file. The tiff files are about twice the size of the png files. I've now tried setting kCGImageDestinationLossyCompressionQuality to 1.0 when adding an image to be exported to the CGImageDestination object when exporting as tiff without any improvement in the tiff image quality. Trying to see what the problem with tiff file image is, it is almost like there is only a 1 bit alpha channel. But checking the tiff image file using tiffinfo gives: Image Width: 2272 Image Length: 1704 Bits/Sample: 8 Sample Format: unsigned integer Compression Scheme: none Photometric Interpretation: RGB color Alpha: Present Orientation: row 0 top, col 0 lhs Samples/Pixel: 4 Rows/Strip: 14 Number of Strips: 122 Planar Configuration: Not planar Profile Name: sRGB IEC61966-2.1 I don't particularly care whether I am exporting as tiff or png, and not too fussed about the file size. But I'd like the quality I'm getting with the png file but I would like saving to be faster. Does anyone have suggestions? Is there a known issue(s)? I've just tried exporting as png with the kCGImageDestinationLossyCompressionQuality set to 1.0 but this doesn't change things. I hadn't really expected kCGImageDestinationLossyCompressionQuality to make a difference as it seems really designed for saving jpeg files. The only thing I've not tried but like setting kCGImageDestinationLossyCompressionQuality it seems pointless. I could try LZW compression when saving the tiff file. But since both uncompressed and LZW are meant to be lossless I can't see how this could make a difference. The PNG file reports the same colorspace, profile and bits per channel as the tiff file and contains an alpha channel. Kevin ___ 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: Issues with CIFilters and CALayers
On Feb 23, 2014, at 1:06 PM, Gordon Apple g...@ed4u.com wrote: We have run into a number is issues trying to use CIFilters with CALayers: 1. When a layer is hidden, its filters, especially background filters, should be temporarily removed, or at least bypassed. Hiding the layer should make if effectively non-existent in the displayed layer stack. Is this a statement or a question? 2. The docs should tell you that in a CIFilter you cannot auto-synthesize filter input parameters. This simply does not work, especially for inputImage. Bug? 3. The docs for CALayer filters and background filters say you should name your filters for use in changing parameters. I.e., filter.name = @²myFilter². Amazingly, this works, in spite of the fact that there is no public property called ³name² for a CIFilter. There is a public property, but it isn’t declare in CIFilter.h if I recall correctly. 4. The example keyPath makes no sense whatsoever, unless we just don¹t understand keyPaths: [layer setValue:XXX forKeyPath:@²backgroundFilters.myFilter.filterParam²]; backgroundFilters is an array of filters. myFilter is a property value of some element of the array. (huh?) Core Animation extension to KVC. 5. We need some decent documentation of what in GL Shading Language is actually relevant to writing ciKernels, besides the one page addendum provided. Bug (I don’t know myself, but a bug is the only way you are going to tell the folks in charge of that it is needed). 6. And, of course, the problem we have already mentioned in a previous post about getting a CALayer to update when a filter parameter is changed. You have to go through the key-value path in Core Animation. If you update the CIFilter directly you have no guarantee that CA will notice the change. -- David Duncan ___ 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: exporting image files to disk using CGImageDestination
On 24 Feb 2014, at 17:00, Kevin Meaney k...@yvs.eu.com wrote: I've written a command line tool that takes an image file (when testing I'm using JPEG files) and applies a custom CIFilter (a naive chroma key filter I've written) and saves a file to disk. Sampling the command line tool when processing files shows it is spending 90% of its time writing the png file of which most of this time is spent in a function called deflate in libz. The final file quality is good. I'm using CGImageDestination to export the file with default settings. I’m a little unclear here. Are you saying the process appears to much slower than you can reasonably expect? Or simply that you’d like to find a way to make it go faster? (something which may well not be very possible) ___ 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: Issues with CIFilters and CALayers
Apparently, my comment about not understanding this construct for setValueForKeyPath was correct. It actually works. I finally got the highlighting filter to work and update properly. Now I¹m trying to do something much simpler, i.e., construct a freezeFilter. Nothing I¹ve tried so far works. Apparently, a CIFilter is expected to be stateless function such as outputImage = f(inputImage, parameters). Not accepting this premiss, I decided to try caching the first output image ( from the outputImage method), then return the cashed image thereafter, an ultra simple concept, except that it does not work. Any reason, besides what I postulated, why this shouldn¹t work? On 2/23/14 3:06 PM, Gordon Apple g...@ed4u.com wrote: We have run into a number is issues trying to use CIFilters with CALayers: 1. When a layer is hidden, its filters, especially background filters, should be temporarily removed, or at least bypassed. Hiding the layer should make if effectively non-existent in the displayed layer stack. 2. The docs should tell you that in a CIFilter you cannot auto-synthesize filter input parameters. This simply does not work, especially for inputImage. 3. The docs for CALayer filters and background filters say you should name your filters for use in changing parameters. I.e., filter.name = @²myFilter². Amazingly, this works, in spite of the fact that there is no public property called ³name² for a CIFilter. 4. The example keyPath makes no sense whatsoever, unless we just don¹t understand keyPaths: [layer setValue:XXX forKeyPath:@²backgroundFilters.myFilter.filterParam²]; backgroundFilters is an array of filters. myFilter is a property value of some element of the array. (huh?) 5. We need some decent documentation of what in GL Shading Language is actually relevant to writing ciKernels, besides the one page addendum provided. 6. And, of course, the problem we have already mentioned in a previous post about getting a CALayer to update when a filter parameter is changed. ___ 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: Disabling screen capture
On 2014 Feb 21, at 18:24, Scott Ribe wrote: On Feb 21, 2014, at 2:26 PM, Bradley O'Hearne br...@bighillsoftware.com wrote: Industries such as medical (HIPAA), legal, government, education, military defense, etc. all have such security needs. The only way I can see for the app under discussion to work is to create kiosks with human proctors, and not use the network. The video surveillance won't suffice to stop the cheating. But if you're going to do it that way, why use the computers at all? Might as well go back to paper as we do with election ballots. I'd even recommend privacy shields around each test-taker, require that devices be in opaque containers, etc. I can see why such tests need to be secure, because I've seen the articles about College Board test questions being collected, posted on the net, and crowd-sourcing of answers, which people then memorized. That was about a decade back though, and they pulled the on-line tests, and probably caught and penalized a tiny fraction of those involved. Well, there's certainly no such need for HIPAA compliance... Correct. Because HIPAA is Orwellian. It says it's to protect patient privacy, but makes sure privacy is violated, instead. It was to facilitate federal government snooping into individual medical records (or at least their software snooping), and cross-border processing, while putting on a nice face to the victims. I've consulted for some of the state medical cost containment people, and they yearn for a fool-proof way to integrate all such records so that no one's medical history gets through the cracks (e.g. matching up ambulance/EMT contact with hospital admission treatment, with rehab center admission and treatment and out-patient treatment... despite people giving variants of their names, refusing to give Socialist Insecurity Numbers or intentionally making mistakes or making up new ones on the spot in an effort to preserve some shred of privacy), but despite having nearly full access to people's DNA, we still have some slim shreds of privacy left. ___ 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: exporting image files to disk using CGImageDestination
On 24 Feb 2014, at 17:21, Mike Abdullah mabdul...@karelia.com wrote: On 24 Feb 2014, at 17:00, Kevin Meaney k...@yvs.eu.com wrote: I've written a command line tool that takes an image file (when testing I'm using JPEG files) and applies a custom CIFilter (a naive chroma key filter I've written) and saves a file to disk. Sampling the command line tool when processing files shows it is spending 90% of its time writing the png file of which most of this time is spent in a function called deflate in libz. The final file quality is good. I'm using CGImageDestination to export the file with default settings. I’m a little unclear here. Are you saying the process appears to much slower than you can reasonably expect? Or simply that you’d like to find a way to make it go faster? (something which may well not be very possible) I'd like one of two things, either getting the same quality exporting as TIFF as I do with PNG since exporting as tiff is more than 5 times faster, or that saving as PNG is faster. I suppose I don't understand when TIFF saving as uncompressed is meant to be lossless why is the image quality so much worse than saving as PNG. The ImageIO documentation relating to the dictionary properties when setting values to the CGImageDestination object, or when adding an image to the destination object are not really clear as to where to set which is appropriate. Secondly the description of the keys for the dictionary are not particularly helpful. Trying to work out what settings my work to achieve my goal is confusing and perhaps it is impossible. Both the speed difference between TIFF and PNG, and the quality difference surprised me. Kevin ___ 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: exporting image files to disk using CGImageDestination
On Feb 24, 2014, at 9:48 AM, Kevin Meaney k...@yvs.eu.com wrote: On 24 Feb 2014, at 17:21, Mike Abdullah mabdul...@karelia.com wrote: On 24 Feb 2014, at 17:00, Kevin Meaney k...@yvs.eu.com wrote: I've written a command line tool that takes an image file (when testing I'm using JPEG files) and applies a custom CIFilter (a naive chroma key filter I've written) and saves a file to disk. Sampling the command line tool when processing files shows it is spending 90% of its time writing the png file of which most of this time is spent in a function called deflate in libz. The final file quality is good. I'm using CGImageDestination to export the file with default settings. I’m a little unclear here. Are you saying the process appears to much slower than you can reasonably expect? Or simply that you’d like to find a way to make it go faster? (something which may well not be very possible) I'd like one of two things, either getting the same quality exporting as TIFF as I do with PNG since exporting as tiff is more than 5 times faster, or that saving as PNG is faster. I suppose I don't understand when TIFF saving as uncompressed is meant to be lossless why is the image quality so much worse than saving as PNG. The ImageIO documentation relating to the dictionary properties when setting values to the CGImageDestination object, or when adding an image to the destination object are not really clear as to where to set which is appropriate. Secondly the description of the keys for the dictionary are not particularly helpful. Trying to work out what settings my work to achieve my goal is confusing and perhaps it is impossible. Both the speed difference between TIFF and PNG, and the quality difference surprised me. Make sure that what you are looking at is what you think you are looking at. When you look at it in Preview is it being scaled? If so then the default scaling algorithm in Preview for TIFF might be 'fast but ugly’ (I don’t know, just guessing). With a PNG it might be choosing a ‘nice but slower’ algorithm. My recommendation would be to ensure you are looking at the image unscaled as both PNG and TIFF. In Preview I think the menu item is ‘Show Full Size’ or something like that. When you export as TIFF your file is basically a bit map, i.e. one 4 byte, 32bit number per pixel. If you choose TIFF compression it’s just using LZW to compress that loselessly. TIFF is really fast because nothing happens except disk IO. With PNG the image has to be compressed. The compression is not just LZW but a complex approach to making the image smaller on disk but trying to keep as much quality as possible. All the detail you never wanted to know is here: http://www.libpng.org/pub/png/book/chapter09.html has all the info you would want to know about PNG. If the docs are vague it would help to file a bug (http://bugreporter.apple.com) to make sure the people in charge of those docs get your input. If you want to more fully understand the details behind what Image IO is doing, gaining an understanding TIFF vs PNG vs JPG and other image storage and compression algorithms would be helpful (but not necessary). Hope this helps, -bd Kevin ___ 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/bdudney%40mac.com This email sent to bdud...@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: exporting image files to disk using CGImageDestination
You should not be seeing worse image quality for TIFF unless very different options are being used in each case. Can you tell what about the image quality is worse? Sandy On Feb 24, 2014, at 7:48 PM, Kevin Meaney k...@yvs.eu.com wrote: On 24 Feb 2014, at 17:21, Mike Abdullah mabdul...@karelia.com wrote: On 24 Feb 2014, at 17:00, Kevin Meaney k...@yvs.eu.com wrote: I've written a command line tool that takes an image file (when testing I'm using JPEG files) and applies a custom CIFilter (a naive chroma key filter I've written) and saves a file to disk. Sampling the command line tool when processing files shows it is spending 90% of its time writing the png file of which most of this time is spent in a function called deflate in libz. The final file quality is good. I'm using CGImageDestination to export the file with default settings. I’m a little unclear here. Are you saying the process appears to much slower than you can reasonably expect? Or simply that you’d like to find a way to make it go faster? (something which may well not be very possible) I'd like one of two things, either getting the same quality exporting as TIFF as I do with PNG since exporting as tiff is more than 5 times faster, or that saving as PNG is faster. I suppose I don't understand when TIFF saving as uncompressed is meant to be lossless why is the image quality so much worse than saving as PNG. The ImageIO documentation relating to the dictionary properties when setting values to the CGImageDestination object, or when adding an image to the destination object are not really clear as to where to set which is appropriate. Secondly the description of the keys for the dictionary are not particularly helpful. Trying to work out what settings my work to achieve my goal is confusing and perhaps it is impossible. Both the speed difference between TIFF and PNG, and the quality difference surprised me. Kevin ___ 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/mcguffogl%40gmail.com This email sent to mcguff...@gmail.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: exporting image files to disk using CGImageDestination
On 24 Feb 2014, at 18:08, Sandy McGuffog mcguff...@gmail.com wrote: You should not be seeing worse image quality for TIFF unless very different options are being used in each case. Can you tell what about the image quality is worse? That was my assumption which is why I was confused. As per my reply to Bill Dudney I've noted that the problem is only there for semi-transparent pixels in a tiff image file. I'm wondering if in that case the problem is related to pre-multiplied images? Kevin ___ 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: exporting image files to disk using CGImageDestination
On 24 Feb 2014, at 18:04, Bill Dudney bdud...@mac.com wrote: Make sure that what you are looking at is what you think you are looking at. When you look at it in Preview is it being scaled? If so then the default scaling algorithm in Preview for TIFF might be 'fast but ugly’ (I don’t know, just guessing). With a PNG it might be choosing a ‘nice but slower’ algorithm. My recommendation would be to ensure you are looking at the image unscaled as both PNG and TIFF. In Preview I think the menu item is ‘Show Full Size’ or something like that. I'd already done that, but doing it again made me realize that the problem is 100% associated with the alpha channel. Where the pixels are fully opaque everything is fine. Where pixels are semi-transparent is where the problem occurs. Fully transparent is also fine. I wonder if the problem is to do with premultiply. Does TIFF deal with an image generated from a premultiplied bitmap properly? If the docs are vague it would help to file a bug (http://bugreporter.apple.com) to make sure the people in charge of those docs get your input. I wrote a bug report ages ago relating to the ImageIO documentation when I had the same problem understanding the settings when creating gif animations using CGImageDestination. I've not had any response to that bug report. Thanks for the help. Kevin ___ 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: exporting image files to disk using CGImageDestination
On Feb 24, 2014, at 10:25 AM, Kevin Meaney k...@yvs.eu.com wrote: On 24 Feb 2014, at 18:04, Bill Dudney bdud...@mac.com wrote: Make sure that what you are looking at is what you think you are looking at. When you look at it in Preview is it being scaled? If so then the default scaling algorithm in Preview for TIFF might be 'fast but ugly’ (I don’t know, just guessing). With a PNG it might be choosing a ‘nice but slower’ algorithm. My recommendation would be to ensure you are looking at the image unscaled as both PNG and TIFF. In Preview I think the menu item is ‘Show Full Size’ or something like that. I'd already done that, but doing it again made me realize that the problem is 100% associated with the alpha channel. Where the pixels are fully opaque everything is fine. Where pixels are semi-transparent is where the problem occurs. Fully transparent is also fine. I wonder if the problem is to do with premultiply. Does TIFF deal with an image generated from a premultiplied bitmap properly? How are you generating these images? Specifically, the CGImageRef you pass to CGImageDestination and the pixels backing it. PNG does not store premultiplied image data, so the pixels will be un-multiplied for storage if necessary. TIFF does not seem to have a position on which form the data takes, but decoders may expect pre-multiplied since thats what Photoshop writes. If your starting image is not pre-multiplied alpha, then the TIFF may be written the same way but decoded with a pre-multiplied assumption, which would make the image look horrible. If the docs are vague it would help to file a bug (http://bugreporter.apple.com) to make sure the people in charge of those docs get your input. I wrote a bug report ages ago relating to the ImageIO documentation when I had the same problem understanding the settings when creating gif animations using CGImageDestination. I've not had any response to that bug report. Thanks for the help. Kevin ___ 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/david.duncan%40apple.com This email sent to david.dun...@apple.com -- David Duncan ___ 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: exporting image files to disk using CGImageDestination
On 24 Feb 2014, at 18:40, David Duncan david.dun...@apple.com wrote: On Feb 24, 2014, at 10:25 AM, Kevin Meaney k...@yvs.eu.com wrote: I'd already done that, but doing it again made me realize that the problem is 100% associated with the alpha channel. Where the pixels are fully opaque everything is fine. Where pixels are semi-transparent is where the problem occurs. Fully transparent is also fine. I wonder if the problem is to do with premultiply. Does TIFF deal with an image generated from a premultiplied bitmap properly? How are you generating these images? Specifically, the CGImageRef you pass to CGImageDestination and the pixels backing it. PNG does not store premultiplied image data, so the pixels will be un-multiplied for storage if necessary. TIFF does not seem to have a position on which form the data takes, but decoders may expect pre-multiplied since thats what Photoshop writes. If your starting image is not pre-multiplied alpha, then the TIFF may be written the same way but decoded with a pre-multiplied assumption, which would make the image look horrible. The image is created from a CGContext RGBA, 8 bits per component. sRGB profile with a bitmap info option of kCGImageAlphaPremultipliedLast. As far as I can tell you can't create a CGContext with an alpha channel that isn't pre-multiplied. I tried creating as few different types with no success. In my coreimage filter, I unpremultiply the color values before calculating the new alpha values which will then be multiplied against the old alpha and then I pre-multiply again before the coreimage kernel filter returns. Kevin ___ 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: NSNumber : method to return pointer to represented value
On 23 Feb 2014, at 13:15, Graham Cox graham@bigpond.com wrote: Either that or a custom class would actually require very little effort - probably less than the typing in this discussion so far anyway! It actually takes a bit more effort to subclass NSNumber than it does to talk about not doing it! Group logic won out and I went with the NSNumber subclass. https://gist.github.com/mugginsoft/9198239 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
