[Openmcl-devel] CCL Issue with Lion

Paul Krueger plkrueger at comcast.net
Fri May 3 11:52:14 PDT 2013


Just a thought, but a check through past emails found this from Matthew:

"I just committed new interface databases for Darwin x8664 systems, built from the 10.8 SDK."

If this really is a Lisp-specific problem, is it possible that there was some difference from 10.7 to 10.8 that makes the CCL interface database not work in this particular case on a Lion (10.7) system?

I suppose the test would be to rebuild the database from the 10.7 sdk and see what happens. I haven't looked at internals, can CCL select from different databases based on the level of the currently running system? That would seem like a great feature to have for cases like this.

On May 3, 2013, at 12:16 PM, Michael Minerva <minerva at agentsheets.com> wrote:

> Sorry I forgot to mention in my last message, if anyone would like to see my ObjC application or code for the test program I mentioned in my last email, I can upload it for your viewing pleasure.
> 
> --Mike
> 
> On May 3, 2013, at 11:15 AM, Michael Minerva <minerva at agentsheets.com> wrote:
> 
>> Hey Gary,
>> 
>> Thanks a lot for your response.
>> 
>> On May 2, 2013, at 6:19 PM, Gary Byers <gb at clozure.com> wrote:
>> 
>>> The behavior that you describe seems similar to that described in:
>>> 
>>> <http://stackoverflow.com/questions/10508522/nsopenpanel-doesnt-show-when-i-call-runmodal>
>>> 
>>> where the problem apparently had to do with (lack of proper) "entitlements".  (The owner of the
>>> appliance - quaintly referred to as the "user" in some documents - might try to access the filesystem
>>> on their "computer" otherwise.)
>>> 
>> 
>> I believe this is not the same issue I am dealing with.  We have enabled the entitlement that he is referencing in this post.  Here is our entitlements plist for the file I sent:
>> 
>> <plist version="1.0">
>> <dict>
>> 	<key>com.apple.security.app-sandbox</key>
>> 	<true/>
>> 	<key>com.apple.security.files.user-selected.read-write</key>
>> 	<true/>
>> 	<key>com.apple.security.network.client</key>
>> 	<true/>
>> </dict>
>> </plist>
>> 
>> The com.apple.security.files.user-selected.read-write is the entitlement he references in his post which allows the user to select a location where the application can read and write. 
>> 
>>> I have no idea why this would work on some systems that support sandboxing and not on others,
>>> but I confess that I had some difficulty parsing your message.  (There's more reason to think that
>>> this is a Lion problem than that it's a Mountain Lion problem, but I don't know how anyone would
>>> know for sure.)
>>> 
>> 
>> Sorry if my message was unclear, just to be sure, we have tested this on 3 machines with Mountain Lion and 2 machines with Lion, and so far, the dialog would not show up on any of Lion machines and it showed up on all of the Mountain Lion machines. While this is not a comprehensive test, this does indeed seem to be a Lion only problem. 
>> 
>>> There's no reason to think that this is not a CCL problem.  There's no reason to think that it is a
>>> CCL problem, either.  If a sandboxed ObjC program with exactly the same entitlements behaved
>>> differently, then there'd at least be some reason to wonder why Cocoa methods called from CCL behave
>>> differently than they do when called by that ObjC program.  My model of things is that those Cocoa methods
>>> don't know or care what programming language their callers were compiled in, and I don't know of any 
>>> reason to think of that model as being incorrect.
>>> 
>> 
>> I have created a Sandboxed ObjC app with the same entitlements and tested it on Lion and Mountain Lion machines and the dialog always pops up. The app simply has a button hooked up to an IBAction that creates the NSOpenPanel when it is pushed. I tried the exact same cocoa code in sandboxed CCL on Lion and the dialog does not pop up.  
>> 
>> Here is the IBAction:
>> 
>> - (IBAction)openDialog:(id)pId
>> {
>>     NSOpenPanel *panel = [[NSOpenPanel alloc] init];
>>    [panel runModal];
>> }
>> 
>> After creating the app I verified that it had the same entitlements with:
>>  codesign -dvvv --entitlements :- /Users/Mike/Library/Developer/Xcode/DerivedData/DialogTest-cavpxfrvxshnnmdiqxjdocldarco/Build/Products/Debug/DialogTest.app 
>> 
>> and it did indeed have the same entitlements:
>> 
>> PropertyList-1.0.dtd">
>> <plist version="1.0">
>> <dict>
>> 	<key>com.apple.security.app-sandbox</key>
>> 	<true/>
>> 	<key>com.apple.security.files.user-selected.read-write</key>
>> 	<true/>
>> 	<key>com.apple.security.network.client</key>
>> 	<true/>
>> </dict>
>> </plist>
>>> Googling for "sandbox NSOpenPanel" indicates that many people have found that these things don't
>>> interact as people expect them to and as the documentation suggests that they should, and that this
>>> is often due to bugs in the underlying technology.   Some messages that one can easily find via that
>>> Google search suggest that the forums on Apple's developer site offer a better explanation of what works
>>> and what doesn't than one can easily find elsewhere.
>> 
>> This is a good suggestion and I have found a lot of good stuff on the Apple Developer boards but I do not know if it would be much help on this issue which does not seem to occur with a similar Xcode project.
>> 
>> --Mike
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20130503/c9fc7aef/attachment.htm>


More information about the Openmcl-devel mailing list