[Openmcl-devel] CCL Issue with Lion
Gary Byers
gb at clozure.com
Fri May 3 13:06:18 PDT 2013
The only thing that CCL does that's related to the File->Open ... menu
item is to override NSDocumentController's #/runModalOpenPanel:forTypes:
method to add an "accessory view" (a popup menu that lets one select
the file's text encoding.) AFAIK, commenting our this method definition
will have no significant effect on anything related to using that menu
item.
The header files define NSOpenPanel to have NSPanel and NSWindow and a
few other classes in its CPL; when running in the sandboxed environment,
NSOpenPanel is a more direct descendent of NSObject (so invoking NSPanel/
NSWindow methods on an NSOpenPanel won't work.) CCL doesn't invoke any
such methods in this case.
ObjC method dispatch is (mostly) done by the ObjC runtime; the (partial)
exceptions have to do with relatively rare cases where there's type ambiguity.
(It's perfectly legal for disjoint ObjC classes to both implement ObjC methods
with the same name but with different argument/result types. IIRC, #/size is
defined (somewhere) to return an NSInteger and somewhere else to return an NSSize;
CCL's ObjC bridge has to look at the type of the receiver in order to know how
to do a foreign function call into the ObjC runtime, but the ObjC runtime ultimately
decides what method implementation gets called.
(A short version of the above: a mismatch between header files and reality
isn't likely to be involved here; it could matter if you did some other things
that believed that the header files matched reality.)
When I try to run Mike's demo under Lion and use the File->Open menu item, I
see the following:
2013-05-02 17:09:21.607 dx86cl[5599:1c51b] Connection Invalid error for service com.apple.hiservices-xpcservice.
2013-05-02 17:09:21.722 dx86cl[5599:1c51b] Error received in message reply handler: Connection invalid
2013-05-02 17:09:36.634 dx86cl[5599:1bc23] Error received in message reply handler: Connection invalid
2013-05-02 17:20:42.909 dx86cl[5599:21e23] Error received in message reply handler: Connection invalid
I saw that by just running the executable in the shell; I assume that the output
would go somewhere if one double-clicked on the application icon, and I assume
that the inability to connect to that service is somehow related to the problem.
(The open/save panels run in another process when the application is sandboxed
and the messages are seemingly claiming that the Secret Means Of Connecting To That
Process isn't working; Apple would have to kill you if they told you anything
more useful.)
I may have missed a message in this thread, but I assume that Mike's saying
that he has an ObjC program that's functionally the same but that doesn't
have difficulty establishing this connection. I'm really skeptical that
the only difference between working and non-working code is that the non-working
code involves CCL. Is there some sort of monetary reward for finding another
significant difference ?
After many years of reading announcements like "CCL can't use NSScrollView!
Pay no attention to the NSScrollViews on the screen in front of you!" (see
<http://clozure.com/pipermail/openmcl-devel/2013-April/014262.html>), my
first reaction is to wonder about that.
On Fri, 3 May 2013, Paul Krueger wrote:
> 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-cavpxfrvxshnnmdi
> qxjdocldarco/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
>
>
>
>
More information about the Openmcl-devel
mailing list