Passing NSTextField Pointer to IOUSBInterfaceInterface182 Callback
I'm doing an asynchronous read from a USB printer. The read works correctly.
My trouble is updating a NSTextField from within the callback.
> -(IBAction)printTest:(id)sender
> { ….
> NSLog(@"starting async read: %@", _printerOutput);
> NSLog(@"_printerOutput pointer = %p", _printerOutput);
>
> result = (*interface)->ReadPipeAsyncTO(interface,
>1,
>readBuffer,
>numBytesRead,
>500,
>1000,
>
> USBDeviceReadCompletionCallback,
>&(_printerOutput)
>);
The callback is defined as:
> void USBDeviceReadCompletionCallback(void *refCon, IOReturn result, void
> *messageArg)
> {
> NSTextField *printerOutput = (__bridge NSTextField *) messageArg;
> NSLog(@"_printerOutput pointer = %p", printerOutput);
> }
The pointer loses its value when inside of the callback.
2013-04-08 16:36:25.348 MyUSB[8120:303] starting async read:
2013-04-08 16:36:25.348 MyUSB[8120:303] _printerOutput pointer = 0x10221dc60
2013-04-08 16:36:27.166 MyUSB[8120:303] _printerOutput pointer = 0x0
I've looked in many places trying to mimic different ways to pass in the
pointer. There can be only one correct way. :)
Another variation on the theme: (__bridge void *)(_printerOutput). This
doesn't work, either.
I understand that the callback is of type IOAsyncCallback1.
Other URLs of note:
http://www.google.com/search?client=safari&rls=en&q=another+usb+notification+example&ie=UTF-8&oe=UTF-8
http://stackoverflow.com/questions/8010382/updating-ui-from-a-c-function-in-a-thread
Thank you for reading.
Caylan
___
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
Modeling a Linux USB Serial Driver with IOKit
Ahoy,
I've been working hard on a basic implementation of a userspace driver for the
WCH341. Would you mind offering some advice for where I may have gone astray?
I've got the device/interface endpoints setup correctly. That is, _usbDevice
and _usbInterface have been initialized properly. I can't configure the device
to get write/read to work. My application is very simple, send one "W\n" and
receive a basic string response from the serial device (9600 baud).
I'm modeling this after
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/drivers/usb/serial/ch341.c
Here is my home grown way to set control.
-(void)sendControlRequest:(int)requestValue
inDirection:(int)direction
withValue:(int)bufferValue
atIndex:(int)index
bufferSize:(int)size
{
NSLog(@"-START");
IOReturnkr;
int writeBuffer[size];
writeBuffer[0] = bufferValue; // Status Request
USBDeviceAddress deviceAddress;
IOUSBDevRequest request;
kr = (*_usbDevice)->GetDeviceAddress(_usbDevice, &deviceAddress);
request.bmRequestType = USBmakebmRequestType(direction, kUSBVendor,
kUSBDevice);
request.bRequest = requestValue;
request.wValue = deviceAddress;
request.wIndex = index;
request.wLength = size;
request.pData = &writeBuffer;
kr = (*_usbDevice)->DeviceRequest(_usbDevice, &request);
if (kr == kIOReturnSuccess)
{
NSLog(@"Success - Bytes are %x and %x", writeBuffer[0], writeBuffer[1]);
}else if ( kr == kIOReturnOverrun)
{
NSLog(@"Device request failed: overrun");
}else
{
NSLog(@"WriteToDevice reset returned err 0x%x\n", kr);
}
NSLog(@"-END");
}
… Then later, I set up the register/values from
http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/drivers/usb/serial/ch341.c…
// ch341_control_in(dev, 0x5f, 0, 0, buffer, size);
[self sendControlRequest:0x5f inDirection:kUSBIn withValue:0 atIndex:0
bufferSize:2];
// ch341_control_out(dev, 0xa1, 0, 0);
[self sendControlRequest:0xa1 inDirection:kUSBOut withValue:0 atIndex:0
bufferSize:2];
// ch341_control_out(dev, 0x9a, 0x1312, a);
[self sendControlRequest:0x9a
inDirection:kUSBOut
withValue:0x1312
atIndex:[self calculateBaudrate]
bufferSize:2];
// ch341_control_in(dev, 0x95, 0x2518, 0, buffer, size);
[self sendControlRequest:0x5f inDirection:kUSBIn withValue:0 atIndex:0
bufferSize:2];
//ch341_control_out(dev, 0x9a, 0x2518, 0x0050);
[self sendControlRequest:0x9a inDirection:kUSBOut withValue:0x2518
atIndex:0x0050 bufferSize:2];
// STATUS - EXPECT 0xff 0xee
[self sendControlRequest:0x95 inDirection:kUSBIn withValue:0x0706 atIndex:0
bufferSize:2];
//ch341_control_out(dev, 0xa1, 0x501f, 0xd90a);
[self sendControlRequest:0xa1 inDirection:kUSBOut withValue:0x501f
atIndex:0xd90a bufferSize:2];
// ch341_control_out(dev, 0x9a, 0x1312, a);
[self sendControlRequest:0x9a
inDirection:kUSBOut
withValue:0x1312
atIndex:[self calculateBaudrate]
bufferSize:2];
// ch341_control_out(dev, 0xa4, ~(CH341_BIT_RTS | CH341_BIT_DTR), 0);
[self sendControlRequest:0xa4
inDirection:kUSBOut
withValue:~(CH341_BIT_RTS | CH341_BIT_DTR)
atIndex:0
bufferSize:2];
Then I write to pipe 2 using...
kr = (*_usbInterface)->WritePipe(_usbInterface,
2,
(void *) [stringToPrint UTF8String],
(UInt32) strlen([stringToPrint UTF8String])
);
2013-04-17 18:18:39.578 Balance[526:303] Attached Modem Device: USB2.0-Ser!
2013-04-17 18:18:39.580 Balance[526:303] Warning Nil - Vendor: (null) Product:
USB2.0-Ser!
2013-04-17 18:18:39.585 Balance[526:303] device pointer before: 0
2013-04-17 18:18:39.586 Balance[526:303] device pointer after: 71304080
2013-04-17 18:18:39.586 Balance[526:303] Found device (vendor = 6790, product =
29987)
2013-04-17 18:18:39.586 Balance[526:303] Iterating a USB interface
2013-04-17 18:18:39.587 Balance[526:303] Interface class 255, subclass 1
2013-04-17 18:18:39.588 Balance[526:303] Interface has 3 endpoints
2013-04-17 18:18:39.588 Balance[526:303] PipeRef 1:
2013-04-17 18:18:39.588 Balance[526:303] direction in,
2013-04-17 18:18:39.588 Balance[526:303] transfer type bulk,
maxPacketSize 32
2013-04-17 18:18:39.589 Balance[526:303] PipeRef 2:
2013-04-17 18:18:39.589 Balance[526:303] direction out,
2013-04-17 18:18:39.589 Balance[526:303] transfer type bulk,
maxPacketSize 32
2013-04-17 18:18:39.590 Balance[526:303] PipeRef 3:
2013-04-17 18:18:39.590
Re: developer.apple.com under maintenance for a few days now?
I just received an email from apple indicating the Dev site was a victim of a hack. On Jul 21, 2013, at 10:02 AM, Alex Zavatone wrote: > It's been this way since mid Friday. > > On Jul 21, 2013, at 10:28 AM, Jean Suisse wrote: > >> Indeed. You're right. I can't log in. >> Given their statement about expiring memberships, they are probably >> expecting the maintenance to take a long while. >> >> --- >> Jean Suisse >> Institut de Chimie Moléculaire de l’Université de Bourgogne >> (ICMUB) — UMR 6302 >> >> >> On Jul 21, 2013, at 4:23 PM, David Delmonte wrote: >> >>> hmm. the referenced site shows developer.apple.com being up. This is >>> correct. However, if you select any of the dev groups (iOS, OSX, Safari), >>> they are not up. >>> >>> >>> On Jul 21, 2013, at 5:18 PM, Jean Suisse wrote: >>> Dear Laurent, Every now and then such questions arise (for developer, bug reporter, etc.). To answer you: it seems to be down for you only (I just tested). Also, there is a nice free online service for answering such questions (downforme.org): http://downforme.org/is-developer.apple.com-down-today-for-everyone Have a nice sunday, Jean --- Jean Suisse Institut de Chimie Moléculaire de l’Université de Bourgogne (ICMUB) — UMR 6302 On Jul 21, 2013, at 4:10 PM, Laurent Daudelin wrote: > Is it only me or has developer.apple.com and devforums.apple.com been > inaccessible for maintenance for several days now? > > -Laurent. > -- > Laurent Daudelin > AIM/iChat/Skype:LaurentDaudelin > http://www.nemesys-soft.com/ > Logiciels Nemesys Softwarelaur...@nemesys-soft.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/zav%40mac.com >> >> This email sent to z...@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/i%40caylan.net > > This email sent to i...@caylan.net ___ 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
Runloops and Window Dragging
I am using CGWindowListCreateImage to fetch an image of the windows behind my app. This works beautifully and is OK for my needs. Except... I have problems when I drag the window. The goal is near real-time image updates during the drag event. The runloop never seems to fully display the results of my drawRect (I can log in drawRect, but the results are not displayed). I've tried operation queues, using mouseDragged, spinning off a thread on a window move notification using detachNewThreadSelector and looking for mouse up using nextEventMatchingMask --- all the while sending setNeedsDisplay:YES to the view or, heaven forbid, sending drawRect straight away (doesn't make a difference). I've made sure "Can Draw Concurrently" is checked at every level as well as the window setting for allowsConcurrentViewDrawing. My next step was to ditch drawRect and instead use an embedded imageView in a scrollView. In windowWillMove I stuff the whole screen's image in the imageView and then scrollPoint to the window's frame origin. This still doesn't get me real-time scrolling of the scrollView when the window is dragged. My hunch is that the window drag event makes the runloop run in NSEventTrackingRunLoopMode, which limits drawRect's efficacy. Any way around this condition? Caylan ___ 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: Runloops and Window Dragging
On Oct 2, 2013, at 5:06 PM, Jens Alfke wrote: >> I am using CGWindowListCreateImage to fetch an image of the windows behind >> my app. This works beautifully and is OK for my needs. > > I assume you’re doing this to apply some kind of fancy effects to the image, > so your window acts like a filter? Correct. The images are previews of renderings. Instead what I've done is create a very large child window with a hole punched for my window. When the window settles down I render the window with the filter. There doesn't seem to be a better way. It works well enough and satisfies my UI needs. Caylan ___ 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: Runloops and Window Dragging
On Oct 2, 2013, at 2:21 PM, Ken Thomases wrote: > On Oct 2, 2013, at 1:36 PM, Caylan Larson wrote: > >> I am using CGWindowListCreateImage to fetch an image of the windows behind >> my app. This works beautifully and is OK for my needs. Except... >> >> I have problems when I drag the window. The goal is near real-time image >> updates during the drag event. >> >> The runloop never seems to fully display the results of my drawRect (I can >> log in drawRect, but the results are not displayed). I've tried operation >> queues, using mouseDragged, spinning off a thread on a window move >> notification using detachNewThreadSelector and looking for mouse up using >> nextEventMatchingMask --- all the while sending setNeedsDisplay:YES to the >> view or, heaven forbid, sending drawRect straight away (doesn't make a >> difference). I've made sure "Can Draw Concurrently" is checked at every >> level as well as the window setting for allowsConcurrentViewDrawing. >> >> My next step was to ditch drawRect and instead use an embedded imageView in >> a scrollView. In windowWillMove I stuff the whole screen's image in the >> imageView and then scrollPoint to the window's frame origin. This still >> doesn't get me real-time scrolling of the scrollView when the window is >> dragged. >> >> My hunch is that the window drag event makes the runloop run in >> NSEventTrackingRunLoopMode, which limits drawRect's efficacy. Any way >> around this condition? > > First, unless you call [yourWindow setMovable:NO], moves are largely handled > in the window server with only occasional notifications to your app that the > frame has changed. If you do call that, then you have to handle clicks and > drags in the window frame by overriding -[NSWindow sendEvent:] and processing > the appropriate events. It's non-trivial, but at least you have full control. > > Second, when the framework (or anything) runs an internal run loop, you can't > rely on the windows being updated. You can try calling -displayIfNeeded > and/or -flushWindow. > > Third, I doubt you're going to get real-time performance out of the CGWindow > API. Apple recommends using the AV Foundation for that: > Technical Q&A QA1740: How to capture screen activity to a movie file using AV > Foundation on Mac OS X Lion > https://developer.apple.com/library/mac/qa/qa1740/_index.html > > The AVScreenShack sample code may also be useful: > https://developer.apple.com/library/mac/samplecode/AVScreenShack/Introduction/Intro.html I looked at the AV Foundation docs and it seems like there is not a way to get a screenshot without my window (like kCGWindowSharingNone). There seems to be a serious problem in CGWindowListCreateImage when called too frequently. From the user's POV, the UI freezes until I "kill -9" via SSH. The recovery looks like: Oct 6 12:22:38 Caylans-MacBook-Pro.local WindowServer[100]: CGXDisableUpdate: UI updates were forcibly disabled by application "Xcode" for over 1.00 seconds. Server has re-enabled them. Oct 6 12:22:38 Caylans-MacBook-Pro.local WindowServer[100]: reenable_update_for_connection: UI updates were finally reenabled by application "Xcode" after 160.03 seconds (server forcibly re-enabled them after 160.02 seconds) Someone told me that this could be due to calls to CGXDisableUpdate without a balanced CGXEnableUpdate. What is the best way to squeeze performance out of CGWindowListCreateImage without getting hosed/throttled by WindowServer? Or is this a race condition that is beyond my reach? Help :-) Caylan ___ 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: Autolayout wrt Cassowary
David, I’m a new cocoa dev. You inspired me to watch WWDC 2011, Session 103 - Cocoa Autolayout. The final minute of this video drops a shout-out and big "Thank You" to the two folks at the Computer Science department at Washington for their work on Cassowary. To others out there: are there other supplementary videos from other WWDCs that I should watch post-2011? I’ve read that Autolayout has much-improved in the last two years. Where are these changes best addressed? Best, Caylan On Oct 25, 2013, at 12:19 PM, David Hoerl wrote: > There have been numerous posts on the internet saying that Apple used > Cassowary as the basis of Autolayout. If so, then why isn't there any mention > of this in the Autolayout document. > > Or was this a white room re-write? > > Cassowary is open source and as far as I can tell requires no attribution, so > its quite possible Apple did leverage it. > > David > ___ > > 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/i%40caylan.net > > This email sent to i...@caylan.net ___ 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
NSWindow Level Side Effect - PopUp to Normal
When my app is active its windows are set to NSPopUpMenuWindowLevel. This is to capture main menu screen real estate inside of its frame (it’s a “scope”-type utility: www.labelscope.com). When I receive applicationDidResignActive, I set all windows as NSNormalWindowLevel. Problem is, the newly active app (whatever it may be) is still underneath my window(s) for one more click. The newly active application has key/main - but my app window is on top. Then, I click once more within the newly active app and my window goes behind. My window is not a ghost - because clicking anywhere on it will activate my app once again. I tried to stash the window’s level before changing it to NSPopUpMenuWindowLevel and set it back - that didn’t work. I tried to get all screen windowNumbers, remove my own app’s window numbers, and then -orderWindow:NSWindowBelow relativeTo:topForeignWindow, but that didn’t work, either. I can orderBack and my window goes way back, but this probably isn’t what the user expects. How do I hover my window above the main menu without getting this strange side-effect? Caylan ___ 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: NSWindow Level Side Effect - PopUp to Normal
On Oct 28, 2013, at 9:38 PM, Caylan Larson wrote: >> Ken Thomas wrote: >> >> I believe that ordering your window behind the other window would work >> (after you've reduced its level), but you're not correctly identifying the >> target window. The window number list includes the menu bar and perhaps >> some other system windows. You can try to use the CGWindow API to identify >> the real window you want to order relative to, but you'll be making a lot of >> unsupported assumptions in any such heuristic. > > Hmm. It does. But like you wrote, the assumptions are a bit … unsupported. > In short, the window list from CGWindowListCopyWindowInfo shows the topmost > user window directly after kCGWindowName as “Dock.” And this works, but I’m > not going to press my luck. I guess this see-all scope will have to wait > until later. :) I could use advice on interface implementation. My app takes the screen real-estate behind its window and rasterizes the screen data using different filters - it then prints the raster data to thermal printers (label, receipt, etc.). http://files.caylan.net/skitch/labelscope-20131028-220538.png This interface is made up of one main window (the paper media in b/w) and the rest of the windows are children (5 of them): gray background with a hole punched out, two rulers, toolbar, and the orientation arrow. For moving the window, each child’s NSView implements mouseDragged to setFrameOrigin on the parent window using the mouse location delta. This works great… except when the window nears the main menu. If I get close to the main menu, the child window’s frames start to get limited in upward mobility. This causes drawing bugs. Strangely, the redrawing doesn’t happen until I setFrame: (vs setFrameOrigin). However, dragging is not the only one use case where the main menu breaks the design - it happens when the window resizes vertically and tries to cross the main menu boundary (user drag and user zoom gesture). In short, this is why I was leaning toward NSWindow’s level via NSPopUpMenuWindowLevel or NSMainMenuWindowLevel. I could just rise above the main menu and not even worry about it. It works - except for the details in the first post of this thread. In the “level” design, the the app's UI would be accessible for people scoping at the top of their display (sure, I could move the toolbar to the bottom of the window… but the border will still get mangled by the main menu). This is my 2nd Mac App as an independent developer. I’m feeling comfortable enough with auto-layout to start merging the child windows into fewer windows. I could have one main window (the background/toolbar/rulers) and one child (the paper media in b/w). However, I don’t think this will cure my problem. Any way to salvage the design? I’m happy to hear recommendations on adding elegance to this design. Stuck between a rock and a menu bar, Caylan ___ 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: NSWindow Level Side Effect - PopUp to Normal
> This works great… except when the window nears the main menu. If I get
> close to the main menu, the child window’s frames start to get limited in
> upward mobility. This causes drawing bugs. Strangely, the redrawing doesn’t
> happen until I setFrame: (vs setFrameOrigin). However, dragging is not the
> only one use case where the main menu breaks the design - it happens when the
> window resizes vertically and tries to cross the main menu boundary (user
> drag and user zoom gesture).
I fixed this problem by adding the following snippet to each child NSWindow
subclass implementation.
-(NSRect)constrainFrameRect:(NSRect)frameRect toScreen:(NSScreen *)screen
{
return frameRect;
}
Of course, I left the default constraint on the main window because it makes
sense from the user’s perspective.
Cheers,
Caylan
___
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
Child Window Resize Cursors When Not Key
Hi, Is it possible to get resize cursors on a child NSWindow that is not key? The only thing I can find on this topic is: http://www.cocoabuilder.com/archive/cocoa/209703-using-nstrackingarea-on-overlay-child-windows.html "I did some experimenting and it appears the updateCursor: message is only sent to the view if its window is key. That's a problem in my case because the window is not and cannot become key.” When the child window is setup to return YES on canBecomeKeyWindow, I can click once and then the resize cursors are visible. Anyone know a good way around this limitation? I’m thinking I need to override the default tracking areas of the window to NSTrackingActiveInActiveApp. But heck, this may be something outside of my app’s control. Thoughts? Caylan ___ 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: Status Bar problem
On Jan 3, 2014, at 3:54 AM, Roland King wrote: >> >> But the iPad version does NOT work (status Bar overlaps): >> > > ... > >> When I Toggle In-Call Status Bar the UILayoutContainerView does not change. >> BUT: here the status bar overlaps the top of the UITableView, which looks >> rather ugly. >> >> What am I doing wrong? >> > What does the in-call status bar on iPad mean anyway? You can't make calls on > them. The in call status bar is also used when another device is connected to your iPhone's “Personal Hotspot.” Perhaps the LTE versions of iPads support this feature. On the other hand, I would suspect navigation routing… but my quick iPad test didn’t show an updated status bar. Caylan ___ 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
