[Pharo-project] [ VM ]Smalltalk getSystemAttribute:
we will have to check if this impacts some of our parameter handling. Stef Begin forwarded message:
VM.r2518/.
CogVM binaries as per VMMaker.oscog-eem.139/r2518.
Add access to VM arguments to Mac. Make Windows, Mac and Unix consistent: Smalltalk getSystemAttribute: -1 => executable name -2 .. -n => VM arguments *including* image (if explicitly supplied). Replace win32 command line parsing with unixesque code using CommandLineToArgvW.
linux launch script: Cope with old linuxes use of /lib/tls hack for an optional thread-local-storage version of libc/libpthread. The launch scripts add /lib/tls:/usr/lib/tls: to LD_LIBRARY_PATH instead of /lib:/usr/lib: if the VM is linked to /lib/tls/libc. -- best, Eliot
Ho corretto e ho portato l'eseguibile nella direttrice; controlli, perchè con la rete in queste condizioni è impossibile: ci mette 10-15 secondi per eseguire un comando Mi faccia sapere Saluti ----- Original Message ----- From: Stéphane Ducasse To: An open mailing list to discuss any topics related to an open-sourceSmalltalk Sent: Wednesday, November 30, 2011 9:03 AM Subject: [Pharo-project] [ VM ]Smalltalk getSystemAttribute: we will have to check if this impacts some of our parameter handling. Stef Begin forwarded message: VM.r2518/. CogVM binaries as per VMMaker.oscog-eem.139/r2518. Add access to VM arguments to Mac. Make Windows, Mac and Unix consistent: Smalltalk getSystemAttribute: -1 => executable name -2 .. -n => VM arguments *including* image (if explicitly supplied). Replace win32 command line parsing with unixesque code using CommandLineToArgvW. linux launch script: Cope with old linuxes use of /lib/tls hack for an optional thread-local-storage version of libc/libpthread. The launch scripts add /lib/tls:/usr/lib/tls: to LD_LIBRARY_PATH instead of /lib:/usr/lib: if the VM is linked to /lib/tls/libc. -- best, Eliot
My initial implementation was in error. I've now changed it back to 0 => executable name -1 .. -n => VM arguments *including* image (if explicitly supplied). Apologies. On Wed, Nov 30, 2011 at 12:03 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
we will have to check if this impacts some of our parameter handling.
Stef
Begin forwarded message:
VM.r2518/ <http://www.mirandabanda.org/files/Cog/VM/VM.r2518/>.
CogVM binaries as per VMMaker.oscog-eem.139/r2518.
Add access to VM arguments to Mac. Make Windows, Mac and Unix consistent: Smalltalk getSystemAttribute: -1 => executable name -2 .. -n => VM arguments *including* image (if explicitly supplied). Replace win32 command line parsing with unixesque code using CommandLineToArgvW.
linux launch script: Cope with old linuxes use of /lib/tls hack for an optional thread-local-storage version of libc/libpthread. The launch scripts add /lib/tls:/usr/lib/tls: to LD_LIBRARY_PATH instead of /lib:/usr/lib: if the VM is linked to /lib/tls/libc. -- best, Eliot
-- best, Eliot
Hi Eliot. So, do we need to change something from image side? On Thu, Dec 1, 2011 at 12:20 AM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
My initial implementation was in error. I've now changed it back to 0 => executable name -1 .. -n => VM arguments *including* image (if explicitly supplied).
Apologies.
On Wed, Nov 30, 2011 at 12:03 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
we will have to check if this impacts some of our parameter handling.
Stef
Begin forwarded message:
VM.r2518/ <http://www.mirandabanda.org/files/Cog/VM/VM.r2518/>.
CogVM binaries as per VMMaker.oscog-eem.139/r2518.
Add access to VM arguments to Mac. Make Windows, Mac and Unix consistent: Smalltalk getSystemAttribute: -1 => executable name -2 .. -n => VM arguments *including* image (if explicitly supplied). Replace win32 command line parsing with unixesque code using CommandLineToArgvW.
linux launch script: Cope with old linuxes use of /lib/tls hack for an optional thread-local-storage version of libc/libpthread. The launch scripts add /lib/tls:/usr/lib/tls: to LD_LIBRARY_PATH instead of /lib:/usr/lib: if the VM is linked to /lib/tls/libc. -- best, Eliot
-- best, Eliot
-- Mariano http://marianopeck.wordpress.com
On Wed, Dec 14, 2011 at 1:13 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
Hi Eliot. So, do we need to change something from image side?
Hopefully not. But you might try testing launching from the command line and accessing image arguments and vm arguments. Hopefully "Smalltalk image arguments" and "Smalltalk vm arguments" answer the right things (and different things). To help in your testing I'm attaching the script I use to launch from the command line on Mac OS. I should include this in the Cog VM distribution but it isn't part of the .app bundle. I put it in ~/bin and edit it to point at the .app bundle I want. Note that this script can be linked with different names to launch different VMs (i.e. I cal it all of ocsfvm oscavm oscdvm oscfmtvm et al to launch the production, assert, debug and multi-threaded etc VMs). HTH Eliot
On Thu, Dec 1, 2011 at 12:20 AM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
My initial implementation was in error. I've now changed it back to 0 => executable name -1 .. -n => VM arguments *including* image (if explicitly supplied).
Apologies.
On Wed, Nov 30, 2011 at 12:03 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
we will have to check if this impacts some of our parameter handling.
Stef
Begin forwarded message:
VM.r2518/ <http://www.mirandabanda.org/files/Cog/VM/VM.r2518/>.
CogVM binaries as per VMMaker.oscog-eem.139/r2518.
Add access to VM arguments to Mac. Make Windows, Mac and Unix consistent: Smalltalk getSystemAttribute: -1 => executable name -2 .. -n => VM arguments *including* image (if explicitly supplied). Replace win32 command line parsing with unixesque code using CommandLineToArgvW.
linux launch script: Cope with old linuxes use of /lib/tls hack for an optional thread-local-storage version of libc/libpthread. The launch scripts add /lib/tls:/usr/lib/tls: to LD_LIBRARY_PATH instead of /lib:/usr/lib: if the VM is linked to /lib/tls/libc. -- best, Eliot
-- best, Eliot
-- Mariano http://marianopeck.wordpress.com
-- best, Eliot
The latest blessed cocoa build from Jenkins (12/11/11 #10) + 1.3-rc returns: SmalltalkImage current getSystemAttribute: -1."'-psn_0_528513'" SmalltalkImage current getSystemAttribute: 0 "'/Applications'" There does not seem to be a way to get the vm executable name. Sean -- View this message in context: http://forum.world.st/VM-Smalltalk-getSystemAttribute-tp4122708p4249718.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Hi, I was trying to fix this, but seems to be a problem (besides the "'-psn_0_528513'", which is an error). According SmalltalkImage>>#getSystemAttribute: comment, getSystemAttribute: 0 shouldn't answer the executable name, but the VM path: 0 the full path name for currently executing VM (or, on some platforms, just the path name of the VM's directory) ...so... getSystemAttribute: 0 is answering fine... and -1 should answer nil (or the vm parameters, if present), not the executable name. Real problem then is: we don't have a way to get the executable name or getSystemAttribute: comment is wrong :) what's the audience opinion? cheers, Esteban El 31/12/2011, a las 9:11p.m., Sean P. DeNigris escribió:
The latest blessed cocoa build from Jenkins (12/11/11 #10) + 1.3-rc returns:
SmalltalkImage current getSystemAttribute: -1."'-psn_0_528513'" SmalltalkImage current getSystemAttribute: 0 "'/Applications'"
There does not seem to be a way to get the vm executable name.
Sean
-- View this message in context: http://forum.world.st/VM-Smalltalk-getSystemAttribute-tp4122708p4249718.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
EstebanLM wrote
Real problem then is: we don't have a way to get the executable name
That's the problem I ran into. I had to load OSProcess and have my code depend on it to get info that seemed basic to the system -- View this message in context: http://forum.world.st/VM-Smalltalk-getSystemAttribute-tp4122708p4254002.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Mon, Jan 02, 2012 at 01:04:58PM -0300, Esteban Lorenzano wrote:
Hi,
I was trying to fix this, but seems to be a problem (besides the "'-psn_0_528513'", which is an error). According SmalltalkImage>>#getSystemAttribute: comment, getSystemAttribute: 0 shouldn't answer the executable name, but the VM path:
0 the full path name for currently executing VM (or, on some platforms, just the path name of the VM's directory)
...so... getSystemAttribute: 0 is answering fine... and -1 should answer nil (or the vm parameters, if present), not the executable name. Real problem then is:
we don't have a way to get the executable name
or
getSystemAttribute: comment is wrong :)
On a unix VM, it answers the full path to the executable, which is in agreement with the comment. For example: Smalltalk getSystemAttribute: 0 ==> '/usr/local/lib/squeak/4.7.18-2505/squeakvm' Maybe is is more complicated for Mac, but wasn't there some discussion about it on vm-dev a while back? Dave
what's the audience opinion?
cheers, Esteban
El 31/12/2011, a las 9:11p.m., Sean P. DeNigris escribi?:
The latest blessed cocoa build from Jenkins (12/11/11 #10) + 1.3-rc returns:
SmalltalkImage current getSystemAttribute: -1."'-psn_0_528513'" SmalltalkImage current getSystemAttribute: 0 "'/Applications'"
There does not seem to be a way to get the vm executable name.
Sean
-- View this message in context: http://forum.world.st/VM-Smalltalk-getSystemAttribute-tp4122708p4249718.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
El 02/01/2012, a las 4:39p.m., David T. Lewis escribió:
Real problem then is:
we don't have a way to get the executable name
or
getSystemAttribute: comment is wrong :)
On a unix VM, it answers the full path to the executable, which is in agreement with the comment. For example:
Smalltalk getSystemAttribute: 0 ==> '/usr/local/lib/squeak/4.7.18-2505/squeakvm'
Maybe is is more complicated for Mac, but wasn't there some discussion about it on vm-dev a while back?
I don't remember :) so, how can we solve this? of course, it is not a problem to make getSystemAttribute: 0 answer argv[0], but that's not the expected behavior... we can be making a mistake, because it should answer vm path, no vm fullName. I can add a 10XX number to answer vm full name, but that will lead to consistency problems inside the image... I really don't know how to proceed :( Esteban
Esteban Lorenzano wrote:
El 02/01/2012, a las 4:39p.m., David T. Lewis escribió:
Real problem then is:
we don't have a way to get the executable name
or
getSystemAttribute: comment is wrong :)
On a unix VM, it answers the full path to the executable, which is in agreement with the comment. For example:
Smalltalk getSystemAttribute: 0 ==> '/usr/local/lib/squeak/4.7.18-2505/squeakvm'
Maybe is is more complicated for Mac, but wasn't there some discussion about it on vm-dev a while back?
I don't remember :) so, how can we solve this? of course, it is not a problem to make getSystemAttribute: 0 answer argv[0], but that's not the expected behavior... we can be making a mistake, because it should answer vm path, no vm fullName. I can add a 10XX number to answer vm full name, but that will lead to consistency problems inside the image...
I really don't know how to proceed :(
Esteban
Esteban, I am not sure of the semantics within Smalltalk, but within both Windows & Linux "full path" includes the filename. Examples... Linux `which` command [1] "...printing the full path when used from a script" > echo `which q2` /home/carlo/bin/q2 Windows Path.GetFullPath method [2] "Returns the absolute path for the specified path string." // GetFullPath('mydir') returns 'C:\temp\Demo\mydir' // GetFullPath('myfile.ext') returns 'C:\temp\Demo\myfile.ext' From browsing around it does seem harder on OSX to determine the path to the current executable [3,4,5,6] but I'm not qualified to comment. cheers, Ben [1] http://linux.die.net/man/1/which [2] http://msdn.microsoft.com/en-us/library/system.io.path.getfullpath.aspx [3] http://stackoverflow.com/questions/799679/programatically-retrieving-the-abs... [4] http://stackoverflow.com/questions/1023306/finding-current-executables-path-... [5] http://stackoverflow.com/questions/933850/how-to-find-the-location-of-the-ex... [6] http://stackoverflow.com/questions/3200651/application-path-location-in-ms-w...
Hi Ben, yes... to answer full file name is easy... my question is because the VM doesn't do that, and it has an explicit transformation to avoid answer that... then I wonder if that would be on purpose, and why. One thing that comes to my mind is that, in macs, a program is a directory, for example, vm would be: /path/to/Cog.app/, then the real executable is placed inside this directory following a convention: MyApp.app/Contents/MacOS/MyApp So, question is: from mac point of view... which one is the "full path"? /path/to/Cog.app or /path/to/Cog.app/Contents/MacOS/Cog? cheers, Esteban El 03/01/2012, a las 9:54a.m., Ben Coman escribió:
Esteban Lorenzano wrote:
El 02/01/2012, a las 4:39p.m., David T. Lewis escribió:
Real problem then is:
we don't have a way to get the executable name
or
getSystemAttribute: comment is wrong :)
On a unix VM, it answers the full path to the executable, which is in agreement with the comment. For example:
Smalltalk getSystemAttribute: 0 ==> '/usr/local/lib/squeak/4.7.18-2505/squeakvm'
Maybe is is more complicated for Mac, but wasn't there some discussion about it on vm-dev a while back?
I don't remember :) so, how can we solve this? of course, it is not a problem to make getSystemAttribute: 0 answer argv[0], but that's not the expected behavior... we can be making a mistake, because it should answer vm path, no vm fullName. I can add a 10XX number to answer vm full name, but that will lead to consistency problems inside the image... I really don't know how to proceed :(
Esteban
Esteban, I am not sure of the semantics within Smalltalk, but within both Windows & Linux "full path" includes the filename. Examples...
Linux `which` command [1] "...printing the full path when used from a script"
echo `which q2` /home/carlo/bin/q2
Windows Path.GetFullPath method [2] "Returns the absolute path for the specified path string." // GetFullPath('mydir') returns 'C:\temp\Demo\mydir' // GetFullPath('myfile.ext') returns 'C:\temp\Demo\myfile.ext'
From browsing around it does seem harder on OSX to determine the path to the current executable [3,4,5,6] but I'm not qualified to comment.
cheers, Ben
[1] http://linux.die.net/man/1/which [2] http://msdn.microsoft.com/en-us/library/system.io.path.getfullpath.aspx [3] http://stackoverflow.com/questions/799679/programatically-retrieving-the-abs... [4] http://stackoverflow.com/questions/1023306/finding-current-executables-path-... [5] http://stackoverflow.com/questions/933850/how-to-find-the-location-of-the-ex... [6] http://stackoverflow.com/questions/3200651/application-path-location-in-ms-w...
On 3 January 2012 14:06, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi Ben,
yes... to answer full file name is easy... my question is because the VM doesn't do that, and it has an explicit transformation to avoid answer that... then I wonder if that would be on purpose, and why. One thing that comes to my mind is that, in macs, a program is a directory, for example, vm would be: /path/to/Cog.app/, then the real executable is placed inside this directory following a convention: MyApp.app/Contents/MacOS/MyApp
So, question is: from mac point of view... which one is the "full path"? /path/to/Cog.app or /path/to/Cog.app/Contents/MacOS/Cog?
i vote for the full path to executable , i.e. /path/to/Cog.app/Contents/MacOS/Cog because you can always strip down unwanted information (just do regexp like '.app/Contents'), while it is much harder to reproduce original information if your source obscures it in that way.
cheers, Esteban
El 03/01/2012, a las 9:54a.m., Ben Coman escribió:
Esteban Lorenzano wrote:
El 02/01/2012, a las 4:39p.m., David T. Lewis escribió:
Real problem then is:
we don't have a way  to get the executable name
or
getSystemAttribute: comment is wrong :)
On a unix VM, it answers the full path to the executable, which is in agreement with the comment. For example:
Smalltalk getSystemAttribute: 0 ==> '/usr/local/lib/squeak/4.7.18-2505/squeakvm'
Maybe is is more complicated for Mac, but wasn't there some discussion about it on vm-dev a while back?
I don't remember :) so, how can we solve this? of course, it is not a problem to make getSystemAttribute: 0 answer argv[0], but that's not the expected behavior... we can be making a mistake, because it should answer vm path, no vm fullName. I can add a 10XX number to answer vm full name, but that will lead to consistency problems inside the image... I really don't know how to proceed :(
Esteban
Esteban, I am not sure of the semantics within Smalltalk, but within both Windows & Linux "full path" includes the filename. Â Examples...
Linux `which` command [1] Â "...printing the full path when used from a script" Â > echo `which q2` Â /home/carlo/bin/q2
Windows Path.GetFullPath method [2] Â "Returns the absolute path for the specified path string." Â // GetFullPath('mydir') returns 'C:\temp\Demo\mydir' Â // GetFullPath('myfile.ext') returns 'C:\temp\Demo\myfile.ext'
From browsing around it does seem harder on OSX to determine the path to the current executable [3,4,5,6] but I'm not qualified to comment.
cheers, Ben
[1] http://linux.die.net/man/1/which [2] http://msdn.microsoft.com/en-us/library/system.io.path.getfullpath.aspx [3] http://stackoverflow.com/questions/799679/programatically-retrieving-the-abs... [4] http://stackoverflow.com/questions/1023306/finding-current-executables-path-... [5] http://stackoverflow.com/questions/933850/how-to-find-the-location-of-the-ex... [6] http://stackoverflow.com/questions/3200651/application-path-location-in-ms-w...
-- Best regards, Igor Stasenko.
Igor Stasenko wrote
because you can always strip down unwanted information (just do regexp like '.app/Contents'),
Or with PetitParser: | vmPath bundleExtension bundlePathParser bundlePath | vmPath := OSProcess programName. bundleExtension := '.app' asParser. bundlePathParser := (bundleExtension negate star, bundleExtension) flatten. bundlePath := bundlePathParser parse: vmPath. ^ FSFilesystem disk root resolve: bundlePath. -- View this message in context: http://forum.world.st/VM-Smalltalk-getSystemAttribute-tp4122708p4257314.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Sean P. DeNigris wrote
Or with PetitParser:
But regex is much tighter for this simple case: bundlePath := '.*\.app' asRegex matchesPrefix: vmPath; subexpression: 1. -- View this message in context: http://forum.world.st/VM-Smalltalk-getSystemAttribute-tp4122708p4257445.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Tue, Jan 03, 2012 at 11:54:18PM +1100, Ben Coman wrote:
Esteban Lorenzano wrote:
El 02/01/2012, a las 4:39p.m., David T. Lewis escribi?:
Real problem then is:
we don't have a way to get the executable name
or
getSystemAttribute: comment is wrong :)
On a unix VM, it answers the full path to the executable, which is in agreement with the comment. For example:
Smalltalk getSystemAttribute: 0 ==> '/usr/local/lib/squeak/4.7.18-2505/squeakvm'
Maybe is is more complicated for Mac, but wasn't there some discussion about it on vm-dev a while back?
I don't remember :) so, how can we solve this? of course, it is not a problem to make getSystemAttribute: 0 answer argv[0], but that's not the expected behavior... we can be making a mistake, because it should answer vm path, no vm fullName. I can add a 10XX number to answer vm full name, but that will lead to consistency problems inside the image... I really don't know how to proceed :(
Esteban
Esteban,
I am not sure of the semantics within Smalltalk, but within both Windows & Linux "full path" includes the filename. Examples...
Linux `which` command [1] "...printing the full path when used from a script"
echo `which q2` /home/carlo/bin/q2
Windows Path.GetFullPath method [2] "Returns the absolute path for the specified path string." // GetFullPath('mydir') returns 'C:\temp\Demo\mydir' // GetFullPath('myfile.ext') returns 'C:\temp\Demo\myfile.ext'
From browsing around it does seem harder on OSX to determine the path to the current executable [3,4,5,6] but I'm not qualified to comment.
In the unix VM (see platforms/unix/vm/sqUnixMain.c), it is done using argv[0] and the realpath() function. In other words, take the program name from the command line, and pass it though realpath() to resolve symbolic links. I don't know if this approach works on OS X though. Dave
cheers, Ben
[1] http://linux.die.net/man/1/which [2] http://msdn.microsoft.com/en-us/library/system.io.path.getfullpath.aspx [3] http://stackoverflow.com/questions/799679/programatically-retrieving-the-abs... [4] http://stackoverflow.com/questions/1023306/finding-current-executables-path-... [5] http://stackoverflow.com/questions/933850/how-to-find-the-location-of-the-ex... [6] http://stackoverflow.com/questions/3200651/application-path-location-in-ms-w...
Hi Esteban, you'll find that my Mac VMs as of r2519 do "the right thing", agreeing with the linux VM. See http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/Mac%20OS/vm/sqMacU... --- platforms/Mac OS/vm/sqMacUnixCommandLineInterface.c (revision 2515) +++ platforms/Mac OS/vm/sqMacUnixCommandLineInterface.c (revision 2522) @@ -63,14 +63,14 @@ char *unixArgcInterfaceGetParm(int n) { int actual; - if (n < 0) + if (n < 0) { actual = -n; - else + return actual < vmArgCnt ? vmArgVec[actual] : nil; + } + else { actual = n - 2; - - if (actual < squeakArgCnt) - return squeakArgVec[actual]; - return nil; + return actual < squeakArgCnt ? squeakArgVec[actual] : nil; + } } And e.g. $ oscogvm/macbuild/Fast.app/Contents/MacOS/Croquet -headless startreader.image foo bar baz squeak> (0 to: -3 by: -1) collect: [:i| Smalltalk getSystemAttribute: i]! #('oscogvm/macbuild/Fast.app/Contents/MacOS/Croquet' '-headless' 'startreader.image' nil) squeak> (0 to: 5) collect: [:i| Smalltalk getSystemAttribute: i]! #('oscogvm/macbuild/Fast.app/Contents/MacOS/Croquet' '/Users/eliot/Cog/startreader.image' 'foo' 'bar' 'baz' nil) squeak> Smalltalk quit! $ On Mon, Jan 2, 2012 at 8:04 AM, Esteban Lorenzano <estebanlm@gmail.com>wrote:
Hi,
I was trying to fix this, but seems to be a problem (besides the "'-psn_0_528513'", which is an error). According SmalltalkImage>>#getSystemAttribute: comment, getSystemAttribute: 0 shouldn't answer the executable name, but the VM path:
0 the full path name for currently executing VM (or, on some platforms, just the path name of the VM's directory)
...so... getSystemAttribute: 0 is answering fine... and -1 should answer nil (or the vm parameters, if present), not the executable name. Real problem then is:
we don't have a way to get the executable name
or
getSystemAttribute: comment is wrong :)
what's the audience opinion?
cheers, Esteban
El 31/12/2011, a las 9:11p.m., Sean P. DeNigris escribió:
The latest blessed cocoa build from Jenkins (12/11/11 #10) + 1.3-rc returns:
SmalltalkImage current getSystemAttribute: -1."'-psn_0_528513'" SmalltalkImage current getSystemAttribute: 0 "'/Applications'"
There does not seem to be a way to get the vm executable name.
Sean
-- View this message in context: http://forum.world.st/VM-Smalltalk-getSystemAttribute-tp4122708p4249718.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- best, Eliot
Hi, ok, I will answer argv[0], then :) Esteban El 03/01/2012, a las 3:00p.m., Eliot Miranda escribió:
Hi Esteban,
you'll find that my Mac VMs as of r2519 do "the right thing", agreeing with the linux VM. See
http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/Mac%20OS/vm/sqMacU...
--- platforms/Mac OS/vm/sqMacUnixCommandLineInterface.c (revision 2515) +++ platforms/Mac OS/vm/sqMacUnixCommandLineInterface.c (revision 2522) @@ -63,14 +63,14 @@ char *unixArgcInterfaceGetParm(int n) { int actual;
- if (n < 0) + if (n < 0) { actual = -n; - else + return actual < vmArgCnt ? vmArgVec[actual] : nil; + } + else { actual = n - 2; - - if (actual < squeakArgCnt) - return squeakArgVec[actual]; - return nil; + return actual < squeakArgCnt ? squeakArgVec[actual] : nil; + } }
And e.g.
$ oscogvm/macbuild/Fast.app/Contents/MacOS/Croquet -headless startreader.image foo bar baz squeak> (0 to: -3 by: -1) collect: [:i| Smalltalk getSystemAttribute: i]! #('oscogvm/macbuild/Fast.app/Contents/MacOS/Croquet' '-headless' 'startreader.image' nil) squeak> (0 to: 5) collect: [:i| Smalltalk getSystemAttribute: i]! #('oscogvm/macbuild/Fast.app/Contents/MacOS/Croquet' '/Users/eliot/Cog/startreader.image' 'foo' 'bar' 'baz' nil) squeak> Smalltalk quit! $ On Mon, Jan 2, 2012 at 8:04 AM, Esteban Lorenzano <estebanlm@gmail.com> wrote: Hi,
I was trying to fix this, but seems to be a problem (besides the "'-psn_0_528513'", which is an error). According SmalltalkImage>>#getSystemAttribute: comment, getSystemAttribute: 0 shouldn't answer the executable name, but the VM path:
0 the full path name for currently executing VM (or, on some platforms, just the path name of the VM's directory)
...so... getSystemAttribute: 0 is answering fine... and -1 should answer nil (or the vm parameters, if present), not the executable name. Real problem then is:
we don't have a way to get the executable name
or
getSystemAttribute: comment is wrong :)
what's the audience opinion?
cheers, Esteban
El 31/12/2011, a las 9:11p.m., Sean P. DeNigris escribió:
The latest blessed cocoa build from Jenkins (12/11/11 #10) + 1.3-rc returns:
SmalltalkImage current getSystemAttribute: -1."'-psn_0_528513'" SmalltalkImage current getSystemAttribute: 0 "'/Applications'"
There does not seem to be a way to get the vm executable name.
Sean
-- View this message in context: http://forum.world.st/VM-Smalltalk-getSystemAttribute-tp4122708p4249718.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- best, Eliot
participants (10)
-
Alexander LazareviÄ -
Ben Coman -
David T. Lewis -
Eliot Miranda -
Esteban Lorenzano -
Igor Stasenko -
Lorenzo Schiavina -
Mariano Martinez Peck -
Sean P. DeNigris -
Stéphane Ducasse