[Openmcl-devel] OpenMCL.app on panther

[Gary Byers]

On Thu, 4 Dec 2003, Raffael Cavallaro wrote:

>
> On Dec 4, 2003, at 12:37 PM, Gary Byers wrote:
>
> > Someone else ran into this symptom a few weeks ago.  In their case,
> > the problem was that the bundle directory "ccl:OpenMCL.app;" - which
> > is part of the source distribution - wasn't installed.
>
> I might add the following footnote: When Openmcl.app is launched, its
> name in the menu bar is OpenMCL, but its name in the dock is dppccl.
> This is because the executable running is dppccl.
>

On the Jaguar system I'm using at the moment, the Dock icon is named
"OpenMCL" (and is the blue Lambda that Brendan Burns contributed a
few months ago.)  I'll check on Panther when I get home; my (vague)
recollection is that Panther's version of LaunchServices does more
caching than Jaguar's did, and that this cache only gets updated
if the modification date of the bundle directory itself changes.

Does doing:

> touch OpenMCL.app

in the shell before running the Cocoa demo affect the name/appearance
of the Dock icon ?


> If you make OpenMCL standalone and rename
> OpenMCL.app/Contents/MacOS/dppccl to
> OpenMCL.app/Contents/MacOS/OpenMCL, then OpenMCL's name in the Dock
> will match its name in the menu bar (i.e., "OpenMCL"). However, if you
> then try to execute (require 'cocoa) or try to load
> ccl/examples/cocoa.lisp, OpenMCL will die with:
> RegisterProcess failed (error = -50)

When the Cocoa demo's started from the command line, it tries to convince
some things in CoreFoundation that it was launched from inside a bundle
directory; the function FAKE-CFBUNDLE-PATH (in "ccl:examples;apple-objc.lisp")
tries to set an environment variable to the physical pathname of
"ccl:OpenMCL.app;Contents;Macos;dppccl".  It's unfortunate that that has
to happen as early as it does; that environment variable takes effect when
CoreFoundation's first initialized.

If you do what the "cocoa-application" example tries to do (e.g., save
a lisp image inside the bundle directory), it's not necessary to fool
the OS into think that the application was launched form inside a
bundle, since it -was- launched from inside a bundle (and the
hardwired "dppccl" pathname's causing #_CreateProcess to die in
confusion.)  It's unfortunate to have to specify the (fake) pathname
this early in the loading sequence and the executable name shouldn't
be hardwired into the code, but it's totally wrong to be doing this
at all from a saved "bundled" image.


> I don't believe that this was the case under Jaguar, but I may be
> misremembering. It clearly is the case under Panther, however.
>
> Changing the name back to dppccl fixes this problem. If you want the
> Dock name and menu bar name to match, you can make a separate copy of
> OpenMCL.app with dppccl renamed to OpenMCL, and place it somewhere
> other than the ccl directory, such as /Applications. This however,
> leads to another problem - failure of certain files to autoload when
> needed since openmcl is looking for them in a relative directory which
> isn't there.
>

I think that the fact that the dock icon isn't getting set up correctly
may just be a caching issue, but it should clearly be possible to change
the executable name (as long as the Info.plist file in the bundle's
updated as well.)

(It may be necessary to touch the bundle directory after any such change
to defeat Panther's more aggressive caching.)

I know that someone was working on a scheme for setting up application
bundles (more) automatically as of a month or so ago.  (Naturally, I
lost the URL to their work in clozure's disk crash ...)

>
> Raf
>
>
> Raffael Cavallaro, Ph.D.
> raffaelcavallaro at mac.com
>