Re: Cocoa-dev Digest, Vol 9, Issue 28
Re: Cocoa-dev Digest, Vol 9, Issue 28
- Subject: Re: Cocoa-dev Digest, Vol 9, Issue 28
- From: "email@hidden" <email@hidden>
- Date: Thu, 19 Jan 2012 21:47:32 +0800
Re: The desired output is something like:
NSString *template = @"HH:mm:ss EEE dd. MMM yyyy zzz";
NSString *dateFormat = [ NSDateFormatter dateFormatFromTemplate: template options: 0 locale: nil ];
NSDateFormatter *dateFormatter = [ [ NSDateFormatter alloc ] init ];
[ dateFormatter setDateFormat: dateFormat ];
NSString *dateString = [ dateFormatter stringFromDate: someDate ];
[ dateFormatter release ];
Ling Peng
在 2012年1月19日，18:40，email@hidden 写道：
> Send Cocoa-dev mailing list submissions to
> email@hidden
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.apple.com/mailman/listinfo/cocoa-dev
> or, via email, send a message with subject or body 'help' to
> email@hidden
>
> You can reach the person managing the list at
> email@hidden
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Cocoa-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: NSTask terminates when NSApplication exits (Keary Suska)
> 2. Re: NSTask terminates when NSApplication exits (Ken Thomases)
> 3. Re: NSTask terminates when NSApplication exits (Andrew)
> 4. Re: NSTask terminates when NSApplication exits (Scott Ribe)
> 5. Re: Is slowing down bindings updates possible? (Marcel Weiher)
> 6. Re: Is slowing down bindings updates possible? (Ken Thomases)
> 7. Re: Is slowing down bindings updates possible? (Kyle Sluder)
> 8. auto malloc[27012]: attempted to remove unregistered weak
> referrer (Marco S Hyman)
> 9. controlling a camcorder (Eric Smith)
> 10. Printing an NSDate (Gerriet M. Denkmann)
> 11. Get OS version of iOS device connected to Mac OS X
> (Payal Mundhada)
> 12. Re: Printing an NSDate (Andreas Grosam)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 18 Jan 2012 14:13:01 -0700
> From: Keary Suska <email@hidden>
> Subject: Re: NSTask terminates when NSApplication exits
> To: Andrew <email@hidden>
> Cc: "Cocoa-Dev \(Apple\)" <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=windows-1252
>
> On Jan 18, 2012, at 11:59 AM, Andrew wrote:
>
>> I am trying to write a program that maintains different installs of
>> another program including launching the program. To do so, I am using
>> NSTask. Now when I quit my cocoa app. the NSTask app dies. The task
>> that the NSTask is running is a Java program, not sure if that makes a
>> difference. According to what I have read, the application should keep
>> running even when the parent task exits. I am running my cocoa app
>> from in XCode4, not sure if that has any effect on it. Could it be
>> that I am not specifying standard* streams so when the parent app
>> quits, those streams are closed and thus the process?
>>
>> I can probably find out the answer by trying different things, but I'd
>> like to get a better insight for what is going on and why the child
>> task is terminating.
>
> Any special handling of NSTask aside, Mac OS X uses Unix-based process control which closes all child processes when the parent is closed. Since your sub-program is Java you may be able to detach the child process. This is usually accomplished by the sub-program by executing a low-level fork(). It may need to be followed by an exec() to fully detach the process. Note that you can't do this with Cocoa/Objective-C (at least Apple says you shouldn't�)
>
> Alternatively (and probably preferably) you could use launchd/Launch Services as recommended. Useful reading: http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/Introduction.html
>
> HTH,
>
> Keary Suska
> Esoteritech, Inc.
> "Demystifying technology for your home or business"
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 18 Jan 2012 15:27:57 -0600
> From: Ken Thomases <email@hidden>
> Subject: Re: NSTask terminates when NSApplication exits
> To: Keary Suska <email@hidden>
> Cc: "Cocoa-Dev \(Apple\)" <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=windows-1252
>
> On Jan 18, 2012, at 3:13 PM, Keary Suska wrote:
>
>> Any special handling of NSTask aside, Mac OS X uses Unix-based process control which closes all child processes when the parent is closed.
>
> No, that's not true. Where did you get that?
>
> Processes with a controlling terminal get a SIGHUP when that terminal is closed, and that will kill a naive process, but that wouldn't apply to subprocesses of GUI apps. Other than that, child processes are independent of their parent process.
>
>> Since your sub-program is Java you may be able to detach the child process.
>
> This doesn't make sense to me. What does being Java have to do with anything?
>
>> This is usually accomplished by the sub-program by executing a low-level fork(). It may need to be followed by an exec() to fully detach the process.
>
> Fork() creates the child subprocess as a near duplicate of the parent. Exec() replaces the process's image with a new one. This is the standard means of creating a subprocess running a new program, but doesn't particularly "detach" an already-existing subprocess from its parent (whatever that might mean).
>
>> Note that you can't do this with Cocoa/Objective-C (at least Apple says you shouldn't�)
>
> You can fork() and exec() just fine. What you can't do is fork(), _not_ call exec(), and then do anything other than call POSIX async-cancel-safe APIs. That includes using high-level frameworks like Cocoa, Core Foundation, or the like.
>
> Regards,
> Ken
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 18 Jan 2012 14:33:54 -0700
> From: Andrew <email@hidden>
> Subject: Re: NSTask terminates when NSApplication exits
> To: undisclosed-recipients: ;
> Cc: email@hidden
> Message-ID:
> <email@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Thanks, I'll have a look.
>
> BTW, I was able to confirm it is a result of streams. My Java
> processes do not quit if I pipe their output to null:
> �NSTask *task = [NSTask new];
> �[task setLaunchPath:execPath];
> �[task setCurrentDirectoryPath:_directory];
> �[task setArguments:arguments];
> �[task setStandardError:[NSFileHandle fileHandleWithNullDevice]];
> �[task setStandardOutput:[NSFileHandle fileHandleWithNullDevice]];
> �[task launch];
>
> So if I want to capture the output I can simply use a file handle to a
> real file and it looks like the NSTask process no longer quits.
>
> On Wed, Jan 18, 2012 at 12:55 PM, Scott Ribe
> <email@hidden> wrote:
>> On Jan 18, 2012, at 11:59 AM, Andrew wrote:
>>
>>> I can probably find out the answer by trying different things, but I'd
>>> like to get a better insight for what is going on and why the child
>>> task is terminating.
>>
>> You may want to try LSxxxx (Launch Services) routines.
>>
>> --
>> Scott Ribe
>> email@hidden
>> http://www.elevated-dev.com/
>> (303) 722-0567�voice
>>
>>
>>
>>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 18 Jan 2012 14:54:38 -0700
> From: Scott Ribe <email@hidden>
> Subject: Re: NSTask terminates when NSApplication exits
> To: Ken Thomases <email@hidden>
> Cc: "Cocoa-Dev \(Apple\)" <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=windows-1252
>
> On Jan 18, 2012, at 2:27 PM, Ken Thomases wrote:
>
>>> Note that you can't do this with Cocoa/Objective-C (at least Apple says you shouldn't�)
>>
>> You can fork() and exec() just fine. What you can't do is fork(), _not_ call exec(), and then do anything other than call POSIX async-cancel-safe APIs. That includes using high-level frameworks like Cocoa, Core Foundation, or the like.
>
> I think it's recommended that you not launch a GUI app via fork/exec. Calling fork/exec *from* GUI apps is fine all day long.
>
> --
> Scott Ribe
> email@hidden
> http://www.elevated-dev.com/
> (303) 722-0567 voice
>
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 19 Jan 2012 01:12:16 +0100
> From: Marcel Weiher <email@hidden>
> Subject: Re: Is slowing down bindings updates possible?
> To: Kyle Sluder <email@hidden>
> Cc: "email@hidden" <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=windows-1252
>
> Hi Kyle,
>
> On Jan 14, 2012, at 18:37 , Kyle Sluder wrote:
>
>> On Jan 14, 2012, at 2:53 AM, Marcel Weiher <email@hidden> wrote:
>>> You shouldn't push updates to the UI, the UI should query the model, and it should do it at "human speed", not at whatever speed the machine can manage to change the state. There are a bunch of reasons for this, not least is that UI updating is fairly heavyweight and you can actually impact your performance (significantly, in some cases).
>>
>> Be careful here. This is good advice in this particular circumstance, but in general pushing values to the UI is good and common design.
>
> While it sure is common, I have a hard time seeing what's good about this design. The sorts of update problems the OP saw are just one symptom of this approach.
>
>> The UI will register as a KVO observer, or as an NSNotification observer, or perhaps the controller will just call -setObjectValue: directly.
>
> In my experience and opinion most of these are tempting, but ultimately lead to bad results because of the type of model to view coupling that you are supposed to avoid in MVC. The model should be able to send invalidation notices to the view, but not push values. The view should react to the invalidation notices by requesting new values from the model. At least this is how the original Smalltalk MVC worked ( models are ideally passive and don't even know about views, controllers manage the changes; if that doesn't work, models send "#changed", which then causes the view to take proper action to react to that change).
>
> One place where this is illustrated well is view drawing. You don't have the model push to have bits of the view drawn as the updates happen (for example sending drawRect: directly to the view). Instead you have parts of the view invalidated, and invalidations accumulated, until the view is ready to redraw all the invalidated areas at once.
>
>> Breaking this pattern should be a conscious decision.
>
> I'd say that the opposite is true: in general you should avoid specific model -> view communication as per MVC (apart from invalidation), but in specialized and very simple cases you may be able to get away with it.
>
>> For example, you don't push a value to cell-based NSTableViews; you tell the table view it needs to ask you for the values at certain indexes. This is because cell-based table views are an optimization that avoids keeping tons of view objects around.
>
> �and another is NSTableView :-)
>
> [snip]
>
> Marcel
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 18 Jan 2012 18:33:52 -0600
> From: Ken Thomases <email@hidden>
> Subject: Re: Is slowing down bindings updates possible?
> To: Marcel Weiher <email@hidden>
> Cc: "email@hidden" <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> On Jan 18, 2012, at 6:12 PM, Marcel Weiher wrote:
>
>> On Jan 14, 2012, at 18:37 , Kyle Sluder wrote:
>>
>>> The UI will register as a KVO observer, or as an NSNotification observer, or perhaps the controller will just call -setObjectValue: directly.
>>
>> In my experience and opinion most of these are tempting, but ultimately lead to bad results because of the type of model to view coupling that you are supposed to avoid in MVC. The model should be able to send invalidation notices to the view, but not push values. The view should react to the invalidation notices by requesting new values from the model. At least this is how the original Smalltalk MVC worked ( models are ideally passive and don't even know about views, controllers manage the changes; if that doesn't work, models send "#changed", which then causes the view to take proper action to react to that change).
>
> What you are saying "should" be the case is, in fact, exactly how KVO and bindings actually work. You seem to be vehemently agreeing with Kyle, while claiming to be disagreeing.
>
>
>>> Breaking this pattern should be a conscious decision.
>>
>> I'd say that the opposite is true: in general you should avoid specific model -> view communication as per MVC (apart from invalidation), but in specialized and very simple cases you may be able to get away with it.
>
> KVO and bindings are not "specific model -> view communication", they are a generalized mechanism which avoid coupling. The model just supports a generalized observer pattern. It doesn't know anything about its observers; it doesn't even know or care whether there are any.
>
> Regards,
> Ken
>
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 18 Jan 2012 16:53:40 -0800
> From: Kyle Sluder <email@hidden>
> Subject: Re: Is slowing down bindings updates possible?
> To: Ken Thomases <email@hidden>
> Cc: "email@hidden" <email@hidden>
> Message-ID:
> <email@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Wed, Jan 18, 2012 at 4:33 PM, Ken Thomases <email@hidden> wrote:
>> On Jan 18, 2012, at 6:12 PM, Marcel Weiher wrote:
>>> On Jan 14, 2012, at 18:37 , Kyle Sluder wrote:
>>>> Breaking this pattern should be a conscious decision.
>>>
>>> I'd say that the opposite is true: �in general you should avoid specific model -> view communication as per MVC (apart from invalidation), but in specialized and very simple cases you may be able to get away with it.
>>
>> KVO and bindings are not "specific model -> view communication", they are a generalized mechanism which avoid coupling. �The model just supports a generalized observer pattern. �It doesn't know anything about its observers; it doesn't even know or care whether there are any.
>
> And, importantly, the exact same observer interface can be used by
> view objects, controller objects, or anything else.
>
> We often have controller-layer objects that interpose between our
> views and model objects. But there's no sense _forcing_ this
> arrangement if it offers no benefit.
>
> --Kyle Sluder
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 18 Jan 2012 15:47:47 -0800
> From: Marco S Hyman <email@hidden>
> Subject: auto malloc[27012]: attempted to remove unregistered weak
> referrer
> To: email@hidden
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> I've done some searches and haven't found anything regarding this
> in my situation. An appropriate RTFM pointer would be appreciated.
>
> I'm running a *garbage collected* application in Lion (10.7.2) that was
> most recently compiled using Xcode 4.2.1. I'm getting these messages
> logged: auto malloc[27012]: attempted to remove unregistered weak referrer 0xblahblah
> multiple times. What is most interesting is that it only happens when
> selecting multiple items by dragging. I first noticed it in this code:
>
> - (IBAction) showOpenPanel: (id) sender
> {
> BOOL reloadNeeded = NO;
> BOOL showWarning = NO;
>
> NSOpenPanel *panel = [NSOpenPanel openPanel];
> CFArrayRef types = CGImageSourceCopyTypeIdentifiers();
> CFMakeCollectable(types);
> [panel setAllowedFileTypes: (NSArray*) types];
> [panel setAllowsMultipleSelection: YES];
> [panel setCanChooseFiles: YES];
> [panel setCanChooseDirectories: NO];
> NSInteger result = [panel runModal];
> if (result == NSOKButton) {
> // this may take a while, let the user know we're busy
> [self showProgressIndicator];
> NSArray *urls = [panel URLs];
> for (NSURL *url in urls) {
> NSString *path = [url path];
> if (! [self isDuplicatePath: path]) {
> [imageInfos addObject: [ImageInfo imageInfoWithPath: path]];
> reloadNeeded = YES;
> } else
> showWarning = YES;
> }
> [self hideProgressIndicator];
>
> if (reloadNeeded)
> [tableView reloadData];
> if (showWarning) {
> NSAlert *alert = [[NSAlert alloc] init];
> [alert addButtonWithTitle: NSLocalizedString(@"CLOSE", @"Close")];
> [alert setMessageText: NSLocalizedString(@"WARN_TITLE", @"Files not opened")];
> [alert setInformativeText: NSLocalizedString(@"WARN_DESC", @"Files not opened")];
> [alert runModal];
> }
> }
> }
>
> In the open panel I can click, move the mouse, then shift-click and all is OK.
> If instead I click and drag I get the error multiple times. So where did I
> go wrong?
>
> Thanks,
>
> Marc
>
> ------------------------------
>
> Message: 9
> Date: Wed, 18 Jan 2012 21:42:33 -0800
> From: Eric Smith <email@hidden>
> Subject: controlling a camcorder
> To: email@hidden
> Message-ID: <email@hidden>
> Content-Type: text/plain; CHARSET=US-ASCII
>
> All,
>
> I'm trying to grab video from a Dazzle Hollywood or an ADVC-55. Over both of these interfaces I can grab video by opening iMovie, selecting the interface and pressing "play". However, when I try to grab video with the QTCaptureDevice interface, I just get a blank screen (iSight and other streaming video inputs work... but not these frame grabbers). It seems I need the equivalent of a "play" button in the QTKit API. Anyone know how to do this?
>
> Thanks,
> Eric
>
>
>
> ------------------------------
>
> Message: 10
> Date: Thu, 19 Jan 2012 13:41:54 +0700
> From: "Gerriet M. Denkmann" <email@hidden>
> Subject: Printing an NSDate
> To: email@hidden
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> I want to print a date on iOS 5.0.1 ignoring the locale.
> (this is for logging - not for showing strings to users)
>
> I assume that NSDate has no sufficient parameters to control the output.
> So I tried to use NSDateFormatter.
>
> The desired output is something like:
> NSString *template = @"HH:mm:ss EEE dd. MMM yyyy zzz";
>
> NSString *dateFormat = [ NSDateFormatter dateFormatFromTemplate: template options: 0 locale: nil ];
> NSDateFormatter *dateFormatter = [ [ NSDateFormatter alloc ] init ];
> [ dateFormatter setDateFormat: dateFormat ];
> NSString *dateString = [ dateFormatter stringFromDate: someDate ];
> [ dateFormatter release ];
>
> 1. problem:
> The date gets output as year, month, day which is NOT what I specified.
>
> 2. problem:
> The output is: date time, NOT time date as requested.
>
> What am I doing wrong?
>
> Kind regards,
>
> Gerriet.
>
>
> ------------------------------
>
> Message: 11
> Date: Thu, 19 Jan 2012 08:56:06 +0000
> From: Payal Mundhada <email@hidden>
> Subject: Get OS version of iOS device connected to Mac OS X
> To: Cocoa-Dev List <email@hidden>,
> "email@hidden"
> <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi All,
>
> I am transferring audiobooks from Mac OS X to iOS devices (iPhone, iPad, iPod) using iTunes. I am using cocoa with applescript.
>
> For transferring audio tracks from Mac OS X to iOS device using iTunes, I am using apple script function add <track> to <playlist>. I found that the function behaviour for iOS5 device is different than that for the non iOS5 device. Because of this I am facing issue on iOS5 device.
>
> Is there any way that I can know the OS version of the iOS device connected to Mac OS X?
>
> Any help will be appreciated.
>
> Thanks,
> Payal
>
>
> DISCLAIMER
> ==========
> This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails.
>
>
> ------------------------------
>
> Message: 12
> Date: Thu, 19 Jan 2012 11:36:14 +0100
> From: Andreas Grosam <email@hidden>
> Subject: Re: Printing an NSDate
> To: Cocoa-Dev List <email@hidden>
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Jan 19, 2012, at 7:41 AM, Gerriet M. Denkmann wrote:
>
>> I want to print a date on iOS 5.0.1 ignoring the locale.
>> (this is for logging - not for showing strings to users)
>>
>> I assume that NSDate has no sufficient parameters to control the output.
>> So I tried to use NSDateFormatter.
>>
>> The desired output is something like:
>> NSString *template = @"HH:mm:ss EEE dd. MMM yyyy zzz";
>>
>> NSString *dateFormat = [ NSDateFormatter dateFormatFromTemplate: template options: 0 locale: nil ];
>> NSDateFormatter *dateFormatter = [ [ NSDateFormatter alloc ] init ];
>> [ dateFormatter setDateFormat: dateFormat ];
>> NSString *dateString = [ dateFormatter stringFromDate: someDate ];
>> [ dateFormatter release ];
>>
>> 1. problem:
>> The date gets output as year, month, day which is NOT what I specified.
>>
>> 2. problem:
>> The output is: date time, NOT time date as requested.
>>
>> What am I doing wrong?
>>
>> Kind regards,
>>
>> Gerriet.
>
>
> Maybe this is what you are looking for:
>
> NSDateFormatter* dateFormatter = [[NSDateFormatter alloc] init];
> [dateFormatter setDateFormat: @"HH:mm:ss EEE dd. MMM yyyy zzz"];
> NSString* dateString = [dateFormatter stringFromDate: [NSDate date]];
> [dateFormatter release];
>
> NSLog(@"\n%@", dateString);
>
> prints:
> 11:31:42 Thu 19. Jan 2012 GMT+01:00
>
>
>
> The documentation could be a bit more clear in this regard, but please re-read it ;)
>
>
> Andreas
>
> ------------------------------
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins (at) lists.apple.com
>
> http://lists.apple.com/mailman/listinfo/cocoa-dev
>
>
> End of Cocoa-dev Digest, Vol 9, Issue 28
> ****************************************
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden