Problems with Mac VM 5.7 and 5.8 on the command-line
Locked
Problems with Mac VM 5.7 and 5.8 on the command-line
 
|
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 -- 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 |
Re: Problems with Mac VM 5.7 and 5.8 on the command-line
|
|
On Mon, May 16, 2011 at 4:35 PM, Stefan Marr <[hidden email]> 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
-- Mariano http://marianopeck.wordpress.com |
Re: Problems with Mac VM 5.7 and 5.8 on the command-line
|
|
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 |
|
|
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 > |
Re: Problems with Mac VM 5.7 and 5.8 on the command-line
|
|
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 |
Re: Problems with Mac VM 5.7 and 5.8 on the command-line
|
|
On 19 May 2011 09:15, stephane ducasse <[hidden email]> 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 > > -- Best regards, Igor Stasenko AKA sig. |
Re: Problems with Mac VM 5.7 and 5.8 on the command-line
|
|
In reply to this post by EstebanLM
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 >> > -- 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 |
Re: Problems with Mac VM 5.7 and 5.8 on the command-line
|
|
On 19 May 2011 13:49, Stefan Marr <[hidden email]> 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); > } > > > > -- Best regards, Igor Stasenko AKA sig. |
Re: Problems with Mac VM 5.7 and 5.8 on the command-line
|
|
In reply to this post by Stefan Marr
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 > |
Re: Problems with Mac VM 5.7 and 5.8 on the command-line
|
|
On 19 May 2011 14:06, Bert Freudenberg <[hidden email]> 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 >> > > > -- Best regards, Igor Stasenko AKA sig. |
Re: Problems with Mac VM 5.7 and 5.8 on the command-line
|
|
On 19.05.2011, at 14:15, Igor Stasenko wrote: > > On 19 May 2011 14:06, Bert Freudenberg <[hidden email]> 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 - |
Re: Problems with Mac VM 5.7 and 5.8 on the command-line
|
|
In reply to this post by Bert Freudenberg
On Thu, May 19, 2011 at 5:06 AM, Bert Freudenberg <[hidden email]> wrote:
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 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.
Agreed on both.
|
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |