[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:06:52 UTC 2011


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.

- Bert -

> So, the question is, how to fix it?
> 
> On the upside, removing chdir seems to restore the expected behavior: at least it parses the arguments fine and accepts the image after a -headless even with a relative path. So, all necessary functionality is there, only the plugin loading would need adaptation.
> 
> Best regards
> Stefan
> 
> PS:
> 
> The code is in sqMacMain.c around line 370:
> 
> {
> 	// Change working directory, this works under os-x, previous logic worked pre os-x 10.4
> 
> 	char target[4097],temp[4097];
> 	getVMPathWithEncoding(target,gCurrentVMEncoding);
> 	sqFilenameFromStringOpen(temp,(sqInt) target, strlen(target));
> 	chdir(temp);
> }
> 
> 
> 
> 
> On 19 May 2011, at 01:24, Esteban Lorenzano wrote:
> 
>> 
>> Hi, 
>> Sorry for the delayed answer. 
>> Yes, there are problems with command line and osx vms. Yes... the cocoa versions are experimenting a lot of problems with it (well... more specifically, they are different than what users expect, and not all of them are present). 
>> I would like to unify the command line between osx, windows and linux vms... but I don't know where to start. 
>> If someone can point me in the right direction (which options should be present... maybe linux version should rule?), I will add this job to the "infinite todo" :)
>> 
>> cheers,
>> Esteban
>> 
>> El 16/05/2011, a las 1:40p.m., Stefan Marr escribió:
>> 
>>> 
>>> Hi:
>>> 
>>> On 16 May 2011, at 18:19, Mariano Martinez Peck wrote:
>>> 
>>>> You have the .surces and .changes properly locacted, haven't you?  because otherwise you have a nice popup waiting for you ;)  but your are headless hheheh
>>> 
>>> There is always room for me doing something stupid, but since the following works just fine with Eliot's Cog build, I assume it is a bug in the Mac VMs:
>>> 
>>> smarr at minerva:~/tmp/pharo$ /Applications/Cog.app/Contents/MacOS/Croquet -headless  ~/tmp/pharo/Pharo-1.2.image HelloWorld
>>> Hello World!
>>> HelloWorld
>>> smarr at minerva:~/tmp/pharo$
>>> 
>>> 
>>> Bye the way, it would be awesome if there would be a platform independent way to produce newlines on the console...
>>> 
>>> 
>>> Best regards
>>> Stefan
>>> 
>>> 
>>> -- 
>>> Stefan Marr
>>> Software Languages Lab
>>> Vrije Universiteit Brussel
>>> Pleinlaan 2 / B-1050 Brussels / Belgium
>>> http://soft.vub.ac.be/~smarr
>>> Phone: +32 2 629 2974
>>> Fax:   +32 2 629 3525
>>> 
>> 
> 
> -- 
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
> http://soft.vub.ac.be/~smarr
> Phone: +32 2 629 2974
> Fax:   +32 2 629 3525
> 




More information about the Vm-dev mailing list