Re: Cocoa-dev Digest, Vol 9, Issue 823
Re: Cocoa-dev Digest, Vol 9, Issue 823
- Subject: Re: Cocoa-dev Digest, Vol 9, Issue 823
- From: email@hidden
- Date: Sun, 02 Dec 2012 18:45:57 -0600
Unsubscribe
Sent from my iPhone
On Dec 2, 2012, at 2:00 PM, email@hidden wrote:
> Send Cocoa-dev mailing list submissions to
> email@hidden
>
> 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
> 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: FileWrapper & iCloud (Dave Fernandes)
> 2. Re: NSApplicationScriptsDirectory access for helper tool
> (email@hidden)
> 3. Re: NSUserUnixTask and com.apple.foundation.UserScriptService
> crash [SOLVED] (email@hidden)
> 4. Re: NSUserUnixTask and com.apple.foundation.UserScriptService
> crash [SOLVED] (Quincey Morris)
> 5. network programming (email@hidden)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 01 Dec 2012 20:00:31 -0500
> From: Dave Fernandes <email@hidden>
> To: Mike Abdullah <email@hidden>
> Cc: "email@hidden \(Apple\)" <email@hidden>
> Subject: Re: FileWrapper & iCloud
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=windows-1252
>
>
> On 2012-12-01, at 5:05 PM, Mike Abdullah <email@hidden> 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: "email@hidden" <email@hidden>
> To: "email@hidden" <email@hidden>
> Subject: Re: NSApplicationScriptsDirectory access for helper tool
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
>
> On 30 Nov 2012, at 15:00, email@hidden 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: email@hidden
> To: "email@hidden" <email@hidden>
> Subject: Re: NSUserUnixTask and com.apple.foundation.UserScriptService
> crash [SOLVED]
> Message-ID: <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> On 1 Dec 2012, at 22:13, email@hidden 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 <email@hidden>
> To: email@hidden
> Cc: "email@hidden" <email@hidden>
> Subject: Re: NSUserUnixTask and com.apple.foundation.UserScriptService
> crash [SOLVED]
> Message-ID:
> <email@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> On Dec 2, 2012, at 02:18 , email@hidden 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: email@hidden
> To: Cocoa-dev <email@hidden>
> Subject: network programming
> Message-ID: <email@hidden>
> 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 (email@hidden)
>
> 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 (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