Re: Sandboxing and calling Launchctl

[Mark Allan]

Thanks Alex,

Thanks for your reply.

If you're talking about the com.apple.security.inherit entitlement, that only 
works for helper apps which are launched via fork/exec from the main 
application.  When the helper app is launched by LaunchServices (via 
SMLoginItemSetEnabled) it crashes immediately as it can't inherit a sandbox 
from anywhere.

In a last-ditch attempt, I was trying to get around that by:
Have my helper app launch the main app at startup.
The main app could then launch a second helper (with 
com.apple.security.inherit entitlement) to do the scheduling.
Main app then terminates immediately.

The two problems with that approach are firstly, the sandbox wouldn't let the 
helper launch my primary app because it's in a different sandbox, and secondly, 
my understanding of forking is that even if I could do that, when the main app 
terminates, any process it forked also gets terminated doesn't it?

Mark

On 1 Jun 2012, at 02:30, Alex Zavatone wrote:

> If you haven't watched the video for Session 204 - "App Sandbox and the Mac 
> App Store" from the WWDC 2011 videos, there might be some info in there that 
> will help you around the 9 minute mark.
> 
> Search for the 2011 WWDC videos on developer.apple.com
> 
> GL, 
> - Alex Zavatone
> 
> On May 31, 2012, at 6:35 AM, Mark Allan wrote:
> 
>> On 29 May 2012, at 15:42, Mark Allan wrote:
>> 
>>> For anyone following, using temporary entitlements only gets rid of two of 
>>> the four errors, so I still can't make scheduling via launchd work.
>>> 
>>> sandboxd still spits out:
>>> launchctl(14634) deny job-creation
>>> 
>>> and Xcode/run log still gives:
>>> launch_msg(): Socket is not connected
>>> 
>>> Other than rolling my own scheduling and writing a helper app which runs 
>>> constantly in the background, can anyone think of a way around this?
>>> 
>>> Thanks
>>> Mark
>> 
>> OK.  After nearly a week of head-banging, I'm just about ready to throw in 
>> the towel, dump sandboxing and potentially the Mac App Store altogether.
>> 
>> I spent the best part of yesterday reinventing the wheel and implementing my 
>> own scheduling mechanism to put into a helper app which would run in the 
>> background constantly as a login item... the timing/scheduling bit works 
>> fine, but the helper app can't actually DO anything because it runs in a 
>> different sandbox from the main app!!  This means I can't access the user's 
>> preferences without a temporary entitlement, and can't access the resources 
>> within my main app at all.
>> 
>> My helper app sits in Main.app/Contents/Library/LoginItems/MainHelper.app 
>> and is launched (based on user prefs) by calling
>>  SMLoginItemSetEnabled((CFStringRef)[NSString stringWithString:@"> identifier>.helpername"], true)
>> 
>> I've tried giving the helper the same bundle identifier as the main app, but 
>> that doesn't work (as expected, but I wanted to try anyway!).
>> 
>> I've even tried getting the path of the helper app ([[NSBundle mainBundle] 
>> bundlePath]) and removing the last 4 path components to get the path to the 
>> main application and launching it via NSWorkspace, so that I could then 
>> launch my helper that way and inherit the sandbox, but sandboxd gives more 
>> permission violations when attempting to launch the main application.  I 
>> suspect that would have been cause for appstore rejection anyway!
>> 
>> I feel like I've missed something obvious, but I just can't see it.  Is 
>> there a way to make the helper app run in the same sandbox as the main app?
>> 
>> Many thanks for your help.
>> 
>> Mark
>> 
>> 
>> ___
>> 
>> 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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Sandboxing and calling Launchctl

[Roland King]

On Jun 1, 2012, at 4:33 PM, Mark Allan wrote:

> Thanks Alex,
> 
> Thanks for your reply.
> 
> If you're talking about the com.apple.security.inherit entitlement, that only 
> works for helper apps which are launched via fork/exec from the main 
> application.  When the helper app is launched by LaunchServices (via 
> SMLoginItemSetEnabled) it crashes immediately as it can't inherit a sandbox 
> from anywhere.
> 
> In a last-ditch attempt, I was trying to get around that by:
>   Have my helper app launch the main app at startup.
>   The main app could then launch a second helper (with 
> com.apple.security.inherit entitlement) to do the scheduling.
>   Main app then terminates immediately.
> 
> The two problems with that approach are firstly, the sandbox wouldn't let the 
> helper launch my primary app because it's in a different sandbox, and 
> secondly, my understanding of forking is that even if I could do that, when 
> the main app terminates, any process it forked also gets terminated doesn't 
> it?
> 
> Mark

Got to admire your determination with this, I just can't believe that nobody 
knows how to do it but I've googled around and hunted the dev forums and either 
nobody does know how to do it, hasn't tried it, or they all managed it with 
zero effort and thus didn't post, I doubt it's the latter. 

As to fork(), if your parent dies you live on, just get reparented (to init I 
think). The question is usually asked the other way around, people wanting 
child processes to get killed when the parent dies and it can be quite hard.  
___

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: NSXMLParser thread safe?

[Nick Zitzmann]

On May 31, 2012, at 11:36 PM, Graham Cox wrote:

> I wonder if it's a stack space issue? I'm getting EXC_BAD_ACCESS with code 13 
> - where are these codes listed? Is there a way to increase stack space for a 
> thread?

That depends. How are you creating the thread? It isn't difficult to do using 
either the pthread or NSThread APIs.

Nick Zitzmann



___

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

iOS preferences outside the application bundle

[Alex Zavatone]

Hi.  I've seen demos for writing app preferences within the app's bundle, but 
we have to deliver apps internally that have a unique assigned id on each 
device and changing the value, recompiling and placing the app on each device 
is far from ideal.

What would be nice is that if I could save the preferences outside the 
application's bundle so that the preference file is outside of the app, 
preferably in /Library/Preferences/com.myCo.myApp.pList.

This would allow us to recompile 1 app and place it on each iDevice while 
retaining the prefs that were set previously.

Any ideas on this?  

Thanks in advance, 
- Alex Zavatone
___

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: NSXMLParser thread safe?

[Graham Cox]

On 02/06/2012, at 1:55 AM, Nick Zitzmann wrote:

> That depends. How are you creating the thread? It isn't difficult to do using 
> either the pthread or NSThread APIs.


Well, I started with the NSThread method that I've used classically, but moved 
it over to using NSInvocationOperations in a NSOperationQueue. This second 
approach is easier, and more stable, but I found a few places where things were 
going pear shaped, mostly to do with accessing shared caches, which was easily 
dealt with using @synchronised blocks.

I'm still getting the occasional crash if I let the operation queue perform 
more than one operation at a time (i.e. it has a limit of 1, but runs it on a 
thread other than main, and that's OK, but for 2 or more, it sometimes falls 
over).

I think this has convinced me that there's something not quite thread-safe in 
my own code, rather than a stack space issue. While SVG parsing can sometimes 
end up with quite a deep stack, it's not failing specifically under those 
conditions.

I'll keep working on it

--Graham
___

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: NSXMLParser thread safe?

[Kyle Sluder]

On Jun 1, 2012, at 4:18 PM, Graham Cox  wrote:

> 
> On 02/06/2012, at 1:55 AM, Nick Zitzmann wrote:
> 
>> That depends. How are you creating the thread? It isn't difficult to do 
>> using either the pthread or NSThread APIs.
> 
> 
> Well, I started with the NSThread method that I've used classically, but 
> moved it over to using NSInvocationOperations in a NSOperationQueue. This 
> second approach is easier, and more stable, but I found a few places where 
> things were going pear shaped, mostly to do with accessing shared caches, 
> which was easily dealt with using @synchronised blocks.

It's important to note that operation queues (and dispatch queues for that 
matter) do not guarantee anything about what threads your operations execute 
on. Apple's notoriously slippery definition of "thread-safe" can still bite you 
if the implication is that an NSXMLParser instance is safe to use from a 
non-main thread as long as *all* uses are from the *same* thread. That would 
make it unsafe to access the same NSXMLParser instance from two different 
NSOperations.

--Kyle Sluder
___

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: NSXMLParser thread safe?

[Joar Wingfors]

On 1 jun 2012, at 18:15, Kyle Sluder wrote:

> That would make it unsafe to access the same NSXMLParser instance from two 
> different NSOperations.


Not necessarily. It all depends on the context of where the operations are 
executing.

Joar



___

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: NSXMLParser thread safe?

[Graham Cox]

On 02/06/2012, at 11:15 AM, Kyle Sluder wrote:

> It's important to note that operation queues (and dispatch queues for that 
> matter) do not guarantee anything about what threads your operations execute 
> on. Apple's notoriously slippery definition of "thread-safe" can still bite 
> you if the implication is that an NSXMLParser instance is safe to use from a 
> non-main thread as long as *all* uses are from the *same* thread. That would 
> make it unsafe to access the same NSXMLParser instance from two different 
> NSOperations.


Right, thanks for the clarification.

In this case, it's not the same NSXMLParser instance - it's a new instance for 
each file I need to parse.

I found the source of my crashes - I was sharing an NSTextLayout object among 
the different objects used to layout text. Previously that worked on the main 
thread because only one was in use at a time, but it's not thread-safe. Making 
a new instance each time fixed that problem.

A similar issue concerned the use of [NSFileManager sharedManager] - making 
that a new instance instead allowed access from several threads (I believe this 
particular case is documented).

There are still some shared objects, such as the NSFontManager, but that hasn't 
caused any problems so far.


--Graham


___

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

NSOperationQueue

[Graham Cox]

A question about NSOperationQueue:

Is there a way to add operations to the queue so that they "jump the queue" 
ahead of any operations that are not running and have not been run yet?

Here's my use case:

I have a browser that browses folders full of SVG files. To create a thumbnail 
preview of the file, it needs to be parsed and converted but it's really slow 
to do this, so I encapsulate this in an operation and stick it on a concurrent 
operation queue. The queue limits the number of concurrent ops to a small 
handful. As each thumbnail is generated, it refreshes the browser and the 
thumbnail pops into view.

If I'm scrolling through the browser, it may have queued up a large number of 
these, but ideally I would prefer if it gave priority to those that are 
actually visible in the window, which are the ones most recently added to the 
queue. Instead, it adds them to the end which means I often have to wait a long 
time for the window to show the thumbnails. Setting a higher priority on these 
items doesn't help because the operations all end up with the same priority.

An NSOperationQueue that simply iterated in reverse would do it, or a way to 
prepend the objects to the head of the queue.

--Graham

 
___

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: NSOperationQueue

[Kyle Sluder]

On Jun 1, 2012, at 8:07 PM, Graham Cox  wrote:

> A question about NSOperationQueue:
> 
> Is there a way to add operations to the queue so that they "jump the queue" 
> ahead of any operations that are not running and have not been run yet?

Give them a higher priority. You should be able to alter the priorities as the 
user scrolls, and NSOperationQueue will do the right thing.

--Kyle Sluder
___

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: NSOperationQueue

[Graham Cox]

On 02/06/2012, at 1:12 PM, Kyle Sluder wrote:

> Give them a higher priority. You should be able to alter the priorities as 
> the user scrolls, and NSOperationQueue will do the right thing.


I tried this but it doesn't work - a bit of thought about how the ops are 
queued will show why no meaningful priority value can be assigned.

At the moment that the operations are queued, there are some operations in the 
queue not yet run, and some running. The code that creates the operations 
doesn't know which ones are needed more urgently (the latest ones), so it can 
only assign a high priority to all of them, so they all end up with the same 
(high) priority and so we're back to square one.

What I'm considering is actually adding them to a priority "holding queue" of 
my own then moving them to the operation queue when it has some capacity 
available. I'm sure it will work but I was hoping there might have been a ready 
solution given this sort of scenario.

--Graham


___

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: NSOperationQueue

[Kyle Sluder]

On Jun 1, 2012, at 8:23 PM, Graham Cox  wrote:

> 
> On 02/06/2012, at 1:12 PM, Kyle Sluder wrote:
> 
>> Give them a higher priority. You should be able to alter the priorities as 
>> the user scrolls, and NSOperationQueue will do the right thing.
> 
> 
> I tried this but it doesn't work - a bit of thought about how the ops are 
> queued will show why no meaningful priority value can be assigned.
> 
> At the moment that the operations are queued, there are some operations in 
> the queue not yet run, and some running. The code that creates the operations 
> doesn't know which ones are needed more urgently (the latest ones), so it can 
> only assign a high priority to all of them, so they all end up with the same 
> (high) priority and so we're back to square one.

Maintain a mapping of objects to be previewed and the operations that generate 
those previews. As the user scrolls, figure out which placeholders have been 
scrolled on/off screen and modify the related operations' priorities 
appropriately. Altering a running operation's priority won't have an effect.

--Kyle Sluder
___

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: NSOperationQueue

[Julius Oklamcak]

>> At the moment that the operations are queued, there are some operations
in the queue not yet run, and some running. The code that creates the
operations doesn't know which ones are needed more urgently (the latest
ones), so it can only assign a high priority to all of them, so they all end
up with the same (high) priority and so we're back to square one.
>
> Maintain a mapping of objects to be previewed and the operations that
generate those previews. As the user scrolls, figure out which placeholders
have been scrolled on/off screen and modify the related operations'
priorities appropriately. Altering a running operation's priority won't have
an effect.

Potentially you could end up queuing up hundreds (or thousands) of thumbnail
generation requests (depending on how many SVG files the user has). If the
user was to close the browser to do something else, or switch to another
app, you would continue generating those thumbnails. My solution, in an iOS
app FWIW, was to cancel the thumbnail generation operations for the
thumbnails that scrolled out of view.

___

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: Sandboxing. WTF?

[koko]

On May 29, 2012, at 8:03 PM, Shawn Bakhtiar wrote:

> The Master Control Program from Tron

Could not agree with you more.

Rather than abandon the App Store we are going to use it as a 'nose under the 
tent' … I cannot go into details but suffice it to say there are ways to use 
the ubiquity of the App Store without giving up your application's  freedom.  
(Quote Braveheart here.)

As you say, if we band together we can defeat Apple.  I am all for it.

Excellent post my friend.

-koko

___

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: NSOperationQueue

[Graham Cox]

On 02/06/2012, at 2:36 PM, Julius Oklamcak wrote:

> Potentially you could end up queuing up hundreds (or thousands) of thumbnail
> generation requests (depending on how many SVG files the user has). If the
> user was to close the browser to do something else, or switch to another
> app, you would continue generating those thumbnails. My solution, in an iOS
> app FWIW, was to cancel the thumbnail generation operations for the
> thumbnails that scrolled out of view.


Yes, this is an issue I'm needing to consider.

Right now, Kyle's suggestion, while it certainly sounds interesting and 
workable, is difficult for a couple of reasons. Chief among these is that the 
view in question is an IKImageBrowserView, and I'm supplying it with images on 
demand through its dataSource protocol. This protocol does not keep you up to 
date with view changes as scrolling takes place, so it's currently quite 
difficult to keep track of the set of visible items in order to prioritise 
them. I'm hoping I can avoid having to subclass the view.

At the moment, when the datasource gets asked for an image, I kick off the 
asynchronous fetch if needed and return nil. When the image arrives, I am able 
to check if it's still visible and refresh the given cell of the view, which 
requests the image again. Another source of difficulty is that the image 
supplier item (implementing the IKImageBrowserItem protocol) is not strongly 
linked to the object that handles the file parse to generate the thumbnail. It 
is its delegate, and gets called back when the image is available, but it 
cannot actively go to that object and cancel it - it simply doesn't know what 
it is. This isn't a showstopper - I could make the browser item own the 
thumbnail generator for a while, but that's a bit of a redesign. 

My simple priority stack sorts out the problem of prioritising the visible 
items without really needing to know what they are, though I think Kyle's idea 
would work better if I could make it work. But it doesn't bother cancelling 
items no longer required.

Need to think this through a bit more - any ideas or experiences of something 
similar welcomed.

--Graham




___

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

adding space for 'annotations' with a typesetter subclass

[Bill Dudney]

Hello,

I'm able to add additional space around a paragraph in my subclass of 
NSATSTypesetter's implementation of 
willSetLineFragmentRect:forGlyphRange:usedRect:baselineOffset:. However, I am 
not getting what I expect as I tweak the parameters to this method. I was 
hoping for some insight on what these parameters really mean from the group to 
help me understand why I'm not getting what I expect.

When I increase the height of the lineFragmentRect and the usedRect the space 
for the paragraph does grow and I get the space I expect.

What is confusing me is where the line of text is drawn in the 
lineFragmentRect. Based on experimentation the line of text is always drawn 
near the top. When I first encountered this I assumed that tweaking the 
baselineOffset would allow me control over where the text is drawn. I was 
unable to change where the text is drawn by tweaking baselineOffset.

My next attempt was to tweak the origin of the lineFragmentRect. That did move 
the line of text, but not in ways I expected it to. My thinking was that moving 
the origin.y 3 would move the text by 3. That does not appear to be the case.

Based my reading of the docs it looks to me as if the changes I make in 
willSetLineFrag… are passed on to 
setLineFragmentRect:forGlyphRange:usedRect:baselineOffset:. During the 
implementation of setLineFrag… the layout manager must be called with 
setLocation:forStartOfGlyphRange: 

I'm trying to follow a sample from Doug Davidson's WWDC 2003 NSText talk, 
however the sample is not on the ADC site. I found this post where Doug pasted 
in part of the sample:

http://lists.apple.com/archives/cocoa-dev/2006/Dec/msg00096.html

My end goal is similar but not the same. I have multiple paragraphs that will 
be marked with an additional attribute. I only want the first and last lines to 
be expanded/moved.

Thanks for your time!

-bd
___

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