Unsubscribe Sent from my iPhone
On Dec 2, 2012, at 2:00 PM, cocoa-dev-requ...@lists.apple.com wrote: > Send Cocoa-dev mailing list submissions to > cocoa-dev@lists.apple.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://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: FileWrapper & iCloud (Dave Fernandes) > 2. Re: NSApplicationScriptsDirectory access for helper tool > (jonat...@mugginsoft.com) > 3. Re: NSUserUnixTask and com.apple.foundation.UserScriptService > crash [SOLVED] (jonat...@mugginsoft.com) > 4. Re: NSUserUnixTask and com.apple.foundation.UserScriptService > crash [SOLVED] (Quincey Morris) > 5. network programming (hmier...@me.com) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 01 Dec 2012 20:00:31 -0500 > From: Dave Fernandes <dave.fernan...@utoronto.ca> > To: Mike Abdullah <cocoa...@mikeabdullah.net> > Cc: "cocoa-dev@lists.apple.com \(Apple\)" <cocoa-dev@lists.apple.com> > Subject: Re: FileWrapper & iCloud > Message-ID: <397ad51f-7f30-423c-9b60-47d3dd00f...@utoronto.ca> > Content-Type: text/plain; charset=windows-1252 > > > On 2012-12-01, at 5:05 PM, Mike Abdullah <cocoa...@mikeabdullah.net> wrote: > >> On 1 Dec 2012, at 20:21, Dave Fernandes wrote: >> >>>> NSPersistentDocument always creates a MOC of type >>>> NSMainQueueConcurrencyType, even if it is created on a background thread. >>>> So as long as things don't go wrong during document opening, everything >>>> will be the same as a document opened on the main thread forever after. >>> >>> Whoops! I meant to say NSPersistentDocument always creates a MOC of type >>> **NSConfinementConcurrencyType** -- the legacy type that assumes you know >>> what you are doing and will manage access accordingly. >> >> But the Core Data team have said for years that MOCs created on the main >> thread get some special treatment. > > I guess I missed that somewhere. Was it on this list? > >> Of course they’ve never given us any specifics. The docs state very clearly >> that MOCs (using the non-private queue types) should be created on the same >> thread/queue that they’ll be used on. > > They do say that clearly, and if you follow that you are less likely to get > into trouble; but they go on to explain that you *can* access a MOC from > different threads as long as you take responsibility for serializing access. > ("If You Don’t Use Thread Containment" section from the Core Data Programming > Guide) > > With concurrent opening, there is no way to use NSLocking in the background > thread if the frameworks are not doing it for you, but since you only get > hold of the MOC after the background thread has completed its work, you > should not need to lock from that point on. > > -d > > > ------------------------------ > > Message: 2 > Date: Sun, 02 Dec 2012 10:15:28 +0000 > From: "jonat...@mugginsoft.com" <jonat...@mugginsoft.com> > To: "Cocoa-dev@lists.apple.com" <cocoa-dev@lists.apple.com> > Subject: Re: NSApplicationScriptsDirectory access for helper tool > Message-ID: <297d9f57-1f8a-4e94-99a5-ffc0ff0c1...@mugginsoft.com> > Content-Type: text/plain; charset=us-ascii > > > On 30 Nov 2012, at 15:00, jonat...@mugginsoft.com wrote: > >> I think that this question can be distilled down to : >> >> Can a sandboxed app bundle helper tool use NSUserUnixTask to run a user >> script in NSApplicationScriptsDirectory? >> >> All my attempts have failed. >> >> Regards >> >> Jonathan Mitchell > To update this. > > I was attempting to launch a user script from NSApplicationScriptsDirectory > using a bundle helper tool and failed as the operation was not permitted. > > I then ran the helper in the main app executable on a separate thread and the > same code launched the user script without issue. > > If anyone succeeds in launching a user script from > NSApplicationScriptsDirectory via a helper tool then it would be good to know. > > Jonathan > > ------------------------------ > > Message: 3 > Date: Sun, 02 Dec 2012 10:18:42 +0000 > From: jonat...@mugginsoft.com > To: "Cocoa-dev@lists.apple.com" <cocoa-dev@lists.apple.com> > Subject: Re: NSUserUnixTask and com.apple.foundation.UserScriptService > crash [SOLVED] > Message-ID: <f72e6ecf-d11d-4dd1-94e3-dd0a74abb...@mugginsoft.com> > Content-Type: text/plain; charset=us-ascii > > On 1 Dec 2012, at 22:13, jonat...@mugginsoft.com wrote: > >> I am trying to run the following one line echo bash script using >> NSUserUnixTask: >> >> echo "hello" >/dev/stderr > > No need to go any further than here. > A script containing the above line executes in the bash shell as is, however > NSUserUnixTask requires us, not surprisingly, to be explicit. > Hence the following executes as expected: > > #!/bin/bash > echo "hello" >/dev/stderr > > Presumably com.apple.foundation.UserScriptService shouldn't crash when > encountering a script whose command processor it cannot identify. > > The following will launch a user script task from > NSApplicationScriptsDirectory in a sandboxed app. > Thanks to Fritz for pointing out that the error detection was not up to > scratch. > > #import "MGSAppDelegate.h" > > NSString * MGSTaskStartException = @"TaskException"; > > @interface MGSAppDelegate() > - (void)startScript:(NSString *)scriptname withError:(NSError **)error; > > @property NSUserUnixTask *unixTask; > @end > > @implementation MGSAppDelegate > > - (void)applicationDidFinishLaunching:(NSNotification *)aNotification > { > NSError *error = nil; > > // make certain to identify the script command processor correctly > // #!/bin/bash > [self startScript:@"TestScript.bash" withError:&error]; > } > > - (void)startScript:(NSString *)scriptname withError:(NSError **)error > { > NSURL *userScriptsFolderURL = [[NSFileManager defaultManager] > URLForDirectory:NSApplicationScriptsDirectory > inDomain:NSUserDomainMask > appropriateForURL:nil > create:NO > error:error]; > > if (!userScriptsFolderURL || *error) { > [NSException raise:MGSTaskStartException format:@"Bad user scripts > folder URL"]; > } > > NSURL *userScriptURL = [NSURL fileURLWithPathComponents: > @[[userScriptsFolderURL path], scriptname]]; > if (!userScriptURL) { > [NSException raise:MGSTaskStartException format:@"Bad user script URL"]; > } > > > self.unixTask = [[NSUserUnixTask alloc] initWithURL:userScriptURL > error:error]; > if (!_unixTask || *error) { > [NSException raise:MGSTaskStartException format:@"Bad user task"]; > > } > > [_unixTask executeWithArguments:nil completionHandler:^(NSError *err) { > if (err) { > NSLog(@"User Unix task execute failed: %@", err); > } else { > NSLog(@"User Unix task execute okay"); > } > } ]; > } > @end > > Jonathan > > > > > ------------------------------ > > Message: 4 > Date: Sun, 02 Dec 2012 10:04:45 -0800 > From: Quincey Morris <quinceymor...@rivergatesoftware.com> > To: jonat...@mugginsoft.com > Cc: "Cocoa-dev@lists.apple.com" <cocoa-dev@lists.apple.com> > Subject: Re: NSUserUnixTask and com.apple.foundation.UserScriptService > crash [SOLVED] > Message-ID: > <8397a313-1ff6-4ca8-b0e7-5aa3cf082...@rivergatesoftware.com> > Content-Type: text/plain; charset=us-ascii > > On Dec 2, 2012, at 02:18 , jonat...@mugginsoft.com wrote: > >> Thanks to Fritz for pointing out that the error detection was not up to >> scratch. > >> if (!userScriptsFolderURL || *error) { >> [NSException raise:MGSTaskStartException format:@"Bad user scripts >> folder URL"]; >> } > >> if (!_unixTask || *error) { >> [NSException raise:MGSTaskStartException format:@"Bad user task"]; >> >> } > > Except you didn't bring it up to scratch, though Fritz was very explicit > about what was needed. The correct versions are: > >> if (!userScriptsFolderURL) { >> [NSException raise:MGSTaskStartException format:@"Bad user scripts >> folder URL"]; >> } > >> if (!_unixTask) { >> [NSException raise:MGSTaskStartException format:@"Bad user task"]; >> >> } > > > > ------------------------------ > > Message: 5 > Date: Sun, 02 Dec 2012 19:29:23 +0000 > From: hmier...@me.com > To: Cocoa-dev <cocoa-dev@lists.apple.com> > Subject: network programming > Message-ID: <fe99f0b6-d737-4e22-ac42-f37ecd93f...@me.com> > Content-Type: text/plain; CHARSET=US-ASCII > > hi. > > here's the situation: i'm trying to set up a flight simulation system with > PS1 (an old 747 simulator originally written for MS-DOS) as the driving force > (best systems simulation short of a professional full-motion sim) and several > add-ons running in a parallels VM under XP. because PS1 has practically no > eye-candy, i want to use flight gear on the mac side to display the scenery. > problem is, flightgear ignores the input from fgvisual (one of the add-ons > running in the VM), which is why i'm thinking about writing a replacement for > fgvisual. question is, what's the best way to do that? can i use cocoa or do > i have to use some lower-level libraries? i think the broker accepts TCP > while flightgear expects UDP, AFAIK. > > can someone point me in the right direction? thanks. > > PS. if this add-on ever becomes reality, it will definitely run on the mac > side. i have no intention to learn windows programming. > > > ------------------------------ > > _______________________________________________ > > 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 > > https://lists.apple.com/mailman/listinfo/cocoa-dev > > > End of Cocoa-dev Digest, Vol 9, Issue 823 > ***************************************** _______________________________________________ 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
