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，cocoa-dev-requ...@lists.apple.com 写道： > Send Cocoa-dev mailing list submissions to > cocoa-dev@lists.apple.com > > 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 > cocoa-dev-requ...@lists.apple.com > > You can reach the person managing the list at > cocoa-dev-ow...@lists.apple.com > > 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 <cocoa-...@esoteritech.com> > Subject: Re: NSTask terminates when NSApplication exits > To: Andrew <andrewrwr+cocoa...@gmail.com> > Cc: "Cocoa-Dev \(Apple\)" <cocoa-dev@lists.apple.com> > Message-ID: <a1fe8e2b-4440-4845-af31-e2eccf7fd...@esoteritech.com> > 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 <k...@codeweavers.com> > Subject: Re: NSTask terminates when NSApplication exits > To: Keary Suska <cocoa-...@esoteritech.com> > Cc: "Cocoa-Dev \(Apple\)" <cocoa-dev@lists.apple.com> > Message-ID: <da67a348-eb9f-4c18-b765-56550fbb4...@codeweavers.com> > 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 <andrewrwr+cocoa...@gmail.com> > Subject: Re: NSTask terminates when NSApplication exits > To: undisclosed-recipients: ; > Cc: Cocoa-dev@lists.apple.com > Message-ID: > <camwvs1ha5zkvh3h0w5p+zonczvnxavcopc+3+vj-_4vk3gp...@mail.gmail.com> > 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 > <scott_r...@elevated-dev.com> 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 >> scott_r...@elevated-dev.com >> http://www.elevated-dev.com/ >> (303) 722-0567�voice >> >> >> >> > > > ------------------------------ > > Message: 4 > Date: Wed, 18 Jan 2012 14:54:38 -0700 > From: Scott Ribe <scott_r...@elevated-dev.com> > Subject: Re: NSTask terminates when NSApplication exits > To: Ken Thomases <k...@codeweavers.com> > Cc: "Cocoa-Dev \(Apple\)" <cocoa-dev@lists.apple.com> > Message-ID: <9d200772-bd3e-4fe5-a174-f73d4218d...@elevated-dev.com> > 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 > scott_r...@elevated-dev.com > http://www.elevated-dev.com/ > (303) 722-0567 voice > > > > > > > ------------------------------ > > Message: 5 > Date: Thu, 19 Jan 2012 01:12:16 +0100 > From: Marcel Weiher <marcel.wei...@gmail.com> > Subject: Re: Is slowing down bindings updates possible? > To: Kyle Sluder <kyle.slu...@gmail.com> > Cc: "Cocoa-dev@lists.apple.com" <Cocoa-dev@lists.apple.com> > Message-ID: <268d4919-4e5a-418c-a22a-29fdcb19b...@gmail.com> > 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 <marcel.wei...@gmail.com> 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 <k...@codeweavers.com> > Subject: Re: Is slowing down bindings updates possible? > To: Marcel Weiher <marcel.wei...@gmail.com> > Cc: "Cocoa-dev@lists.apple.com" <Cocoa-dev@lists.apple.com> > Message-ID: <28bf3b39-27f7-420a-be1d-98d8fea14...@codeweavers.com> > 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 <kyle.slu...@gmail.com> > Subject: Re: Is slowing down bindings updates possible? > To: Ken Thomases <k...@codeweavers.com> > Cc: "Cocoa-dev@lists.apple.com" <Cocoa-dev@lists.apple.com> > Message-ID: > <canes-cxtelokbkujon0wd47+pgfo8excveooyafu9wcny0h...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, Jan 18, 2012 at 4:33 PM, Ken Thomases <k...@codeweavers.com> 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 <m...@snafu.org> > Subject: auto malloc[27012]: attempted to remove unregistered weak > referrer > To: cocoa-dev@lists.apple.com > Message-ID: <03fe9f5e-33dc-4919-9c81-a56de47e4...@snafu.org> > 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 <eric_h_sm...@mac.com> > Subject: controlling a camcorder > To: cocoa-dev@lists.apple.com > Message-ID: <2292b7a9-2a46-4b6e-8d3b-3d361a9ad...@mac.com> > 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" <gerr...@mdenkmann.de> > Subject: Printing an NSDate > To: cocoa-dev@lists.apple.com > Message-ID: <cd59692a-8452-4d4b-ad12-e49636f8d...@mdenkmann.de> > 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 <payal_mundh...@persistent.co.in> > Subject: Get OS version of iOS device connected to Mac OS X > To: Cocoa-Dev List <cocoa-dev@lists.apple.com>, > "applescript-us...@lists.apple.com" > <applescript-us...@lists.apple.com> > Message-ID: <266abe24-8ff9-4a12-8724-a4d597e30...@persistent.co.in> > 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 <agro...@onlinehome.de> > Subject: Re: Printing an NSDate > To: Cocoa-Dev List <cocoa-dev@lists.apple.com> > Message-ID: <d0beb956-8bfa-427b-9a16-c7e363f6c...@onlinehome.de> > 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 (Cocoa-dev@lists.apple.com) > > 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 (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
