[Vm-dev] Problems with Mac VM 5.7 and 5.8 on the command-line
Bert Freudenberg
bert at freudenbergs.de
Thu May 19 12:33:15 UTC 2011
On 19.05.2011, at 14:15, Igor Stasenko wrote:
>
> On 19 May 2011 14:06, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>
>>
>> On 19.05.2011, at 13:49, Stefan Marr wrote:
>>
>>>
>>> Hi Esteban:
>>>
>>> I debugged a bit what is going on.
>>>
>>> The main issue seems to be that the VM changes its working directory.
>>> The reason seems to be that the loading mechanism for plugin depends on the wrong directory.
>>> At least, disabling the chdir leads to warnings like this: squeak: could not load plugin `FilePlugin'.
>>>
>>> I don't really understand why that is the way to go. Actually I would expect that the application respects the current working directory and uses it as its own. At least as a command-line user, that's my expectation.
>>
>> But a Mac OS X .app bundle is not a command line application. It expects the Resources directory to be the current directory. That is so that you can use relative paths to specify resources. I guess this is just a convention, though.
>>
>> I would expect more things to break if you change this. E.g., the SqueakImageName in Info.plist needs to be given as a relative path so that an "all-in-one" bundle works everywhere. It is relative to the Resources directory. I'm not sure if the implementation relies on the cwd or if it actually expands the path relative to Resources.
>>
>> Removing the chdir seems like a good idea, I'm just saying that there may be more places relying on cwd == Resources.
>>
>
> Resources could be looked up relatively to VM binary. Or not?
No.
> Is there a way in unix system to tell the location of application
> binary? i guess there is. Because (Smalltalk getSystemAttribute: 0)
> returns it.
That is just convention. By convention, the shell places the path to the binary in argv[0]. But it can be an arbitrary string that you pass to execl().
For the same reason, the unix vm does not rely on argv[0] to find its plugins. Only the wrapper script does that, IIRC.
In any case, it should not be necessary to rely on argv[0]. There are Mac OS functions to find out the bundle directory, and I think the resources directory, too.
- Bert -
More information about the Vm-dev
mailing list