Hi Esteban:
I have some trouble here with the Mac VM on the command-line.
Using 5.7.4.1 like this: /Applications/Squeak\ 5.7.4.1.app/Contents/MacOS/Squeak Pharo-1.2.image results in a file dialog popping up instead of the image. And even worse, when I chose cancel the VM freezes.
The behavior on 5.8b12 is identical, but the Cog VM does not freeze on cancel.
Using absolute paths (also ~/tmp/pharo/Pharo-1.2.image is ok) works.
Ok, so far, that was already my problem yesterday.
Really new today is my next issue, headless operation:
/Applications/Squeak\ 5.7.4.1.app/Contents/MacOS/Squeak -headless ~/tmp/pharo/Pharo-1.2.image
Without -headless it works just fine, with -headless, it pops up a file dialog again.
Is that know, or are there any work-arounds/newer VMs I should use?
Thanks Stefan
On Mon, May 16, 2011 at 4:35 PM, Stefan Marr squeak@stefan-marr.de wrote:
Hi Esteban:
I have some trouble here with the Mac VM on the command-line.
Using 5.7.4.1 like this: /Applications/Squeak\ 5.7.4.1.app/Contents/MacOS/Squeak Pharo-1.2.image results in a file dialog popping up instead of the image. And even worse, when I chose cancel the VM freezes.
The behavior on 5.8b12 is identical, but the Cog VM does not freeze on cancel.
Using absolute paths (also ~/tmp/pharo/Pharo-1.2.image is ok) works.
Ok, so far, that was already my problem yesterday.
Really new today is my next issue, headless operation:
/Applications/Squeak\ 5.7.4.1.app/Contents/MacOS/Squeak -headless ~/tmp/pharo/Pharo-1.2.image
Without -headless it works just fine, with -headless, it pops up a file dialog again.
Is that know, or are there any work-arounds/newer VMs I should use?
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
Thanks 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
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@minerva:~/tmp/pharo$ /Applications/Cog.app/Contents/MacOS/Croquet -headless ~/tmp/pharo/Pharo-1.2.image HelloWorld Hello World! HelloWorld smarr@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
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@minerva:~/tmp/pharo$ /Applications/Cog.app/Contents/MacOS/Croquet -headless ~/tmp/pharo/Pharo-1.2.image HelloWorld Hello World! HelloWorld smarr@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
Thanks having a good support for command line is definitively important for us. Having to specify an absolute path was a problem in the past.
Stef
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
On 19 May 2011 09:15, stephane ducasse stephane.ducasse@gmail.com wrote:
Thanks having a good support for command line is definitively important for us. Having to specify an absolute path was a problem in the past.
yes, i ran into same problem, unable to understand why VM ignoring everything which goes from command line.
Stef
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
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.
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@minerva:~/tmp/pharo$ /Applications/Cog.app/Contents/MacOS/Croquet -headless ~/tmp/pharo/Pharo-1.2.image HelloWorld Hello World! HelloWorld smarr@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
On 19 May 2011 13:49, Stefan Marr squeak@stefan-marr.de 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'.
The plugin search algorithm IMO is over-engineered. I think we should leave only few locations where VM searching for plugins: some canonical VM 'plugins' dir, which is relative to VM module. And current dir. Rest is up to OS defaults. This would simplify things.
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.
+1
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.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@minerva:~/tmp/pharo$ /Applications/Cog.app/Contents/MacOS/Croquet -headless ~/tmp/pharo/Pharo-1.2.image HelloWorld Hello World! HelloWorld smarr@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
On 19 May 2011 14:06, Bert Freudenberg bert@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? Is there a way in unix system to tell the location of application binary? i guess there is. Because (Smalltalk getSystemAttribute: 0) returns it.
- 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@minerva:~/tmp/pharo$ /Applications/Cog.app/Contents/MacOS/Croquet -headless ~/tmp/pharo/Pharo-1.2.image HelloWorld Hello World! HelloWorld smarr@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
On 19.05.2011, at 14:15, Igor Stasenko wrote:
On 19 May 2011 14:06, Bert Freudenberg bert@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 -
On Thu, May 19, 2011 at 5:06 AM, Bert Freudenberg bert@freudenbergs.dewrote:
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 don't think so. If one launches a .app with the open command (and indeed by clicking on a document which opens its associated app, or clicking on the app) then the current working directory is the root directory /. One can find the Resources directory from the path of the executable which will be in Application.app/Contents/MacOS/theexe and so the Resources directory is parent(fullpath(theexe))/Resources.
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.
I think this can be fixed. Just yesterday with the Newspeak VM I'm working on I found that the chdir breaks a particular use of mercurial. So at least in the Newspeak VM the chdir has been eliminated.
Removing the chdir seems like a good idea, I'm just saying that there may be more places relying on cwd == Resources.
Agreed on both.
- 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@minerva:~/tmp/pharo$
/Applications/Cog.app/Contents/MacOS/Croquet -headless ~/tmp/pharo/Pharo-1.2.image HelloWorld
Hello World! HelloWorld smarr@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
vm-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Eliot Miranda -
Esteban Lorenzano -
Igor Stasenko -
Mariano Martinez Peck -
Stefan Marr -
stephane ducasse