[ VM ]Smalltalk getSystemAttribute:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

[ VM ]Smalltalk getSystemAttribute:

Stéphane Ducasse

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





Reply | Threaded
Open this post in threaded view
|

Re: [ VM ]Smalltalk getSystemAttribute:

Lorenzo
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 -----
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





Reply | Threaded
Open this post in threaded view
|

Re: [ VM ]Smalltalk getSystemAttribute:

Eliot Miranda-2
In reply to this post by Stéphane Ducasse
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 <[hidden email]> wrote:

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








--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: [ VM ]Smalltalk getSystemAttribute:

Mariano Martinez Peck
Hi Eliot. So, do we need to change something from image side?

On Thu, Dec 1, 2011 at 12:20 AM, Eliot Miranda <[hidden email]> 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 <[hidden email]> wrote:

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








--
best,
Eliot




--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: [ VM ]Smalltalk getSystemAttribute:

Eliot Miranda-2


On Wed, Dec 14, 2011 at 1:13 PM, Mariano Martinez Peck <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

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








--
best,
Eliot




--
Mariano
http://marianopeck.wordpress.com




--
best,
Eliot


oscfvm (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [ VM ]Smalltalk getSystemAttribute:

Sean P. DeNigris
Administrator
In reply to this post by Eliot Miranda-2
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
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: [ VM ]Smalltalk getSystemAttribute:

EstebanLM
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.
>


Reply | Threaded
Open this post in threaded view
|

Re: [ VM ]Smalltalk getSystemAttribute:

Sean P. DeNigris
Administrator
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
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: [ VM ]Smalltalk getSystemAttribute:

David T. Lewis
In reply to this post by EstebanLM
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.
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: [ VM ]Smalltalk getSystemAttribute:

EstebanLM

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


Reply | Threaded
Open this post in threaded view
|

Re: [ VM ]Smalltalk getSystemAttribute:

Ben Coman
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-absolute-path-of-an-os-x-command-line-app
[4]
http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe
[5]
http://stackoverflow.com/questions/933850/how-to-find-the-location-of-the-executable-in-c
[6]
http://stackoverflow.com/questions/3200651/application-path-location-in-ms-windows



Reply | Threaded
Open this post in threaded view
|

Re: [ VM ]Smalltalk getSystemAttribute:

EstebanLM
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-absolute-path-of-an-os-x-command-line-app
> [4] http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe
> [5] http://stackoverflow.com/questions/933850/how-to-find-the-location-of-the-executable-in-c
> [6] http://stackoverflow.com/questions/3200651/application-path-location-in-ms-windows
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [ VM ]Smalltalk getSystemAttribute:

David T. Lewis
In reply to this post by Ben Coman
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


Reply | Threaded
Open this post in threaded view
|

Re: [ VM ]Smalltalk getSystemAttribute:

laza
2012/1/3 David T. Lewis <[hidden email]>
realpath() to resolve symbolic links

... and to convert relative paths into absolute paths.

Alex
Reply | Threaded
Open this post in threaded view
|

Re: [ VM ]Smalltalk getSystemAttribute:

Igor Stasenko
In reply to this post by EstebanLM
On 3 January 2012 14:06, Esteban Lorenzano <[hidden email]> 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-absolute-path-of-an-os-x-command-line-app
>> [4] http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe
>> [5] http://stackoverflow.com/questions/933850/how-to-find-the-location-of-the-executable-in-c
>> [6] http://stackoverflow.com/questions/3200651/application-path-location-in-ms-windows
>>
>>
>>
>
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: [ VM ]Smalltalk getSystemAttribute:

Sean P. DeNigris
Administrator
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.
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: [ VM ]Smalltalk getSystemAttribute:

Sean P. DeNigris
Administrator
Sean P. DeNigris wrote
Or with PetitParser:
But regex is much tighter for this simple case:
    bundlePath := '.*\.app' asRegex matchesPrefix: vmPath; subexpression: 1.
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: [ VM ]Smalltalk getSystemAttribute:

Eliot Miranda-2
In reply to this post by EstebanLM
Hi Esteban,

    you'll find that my Mac VMs as of r2519 do "the right thing", agreeing with the linux VM.  See


--- 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [ VM ]Smalltalk getSystemAttribute:

EstebanLM
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


--- 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 <[hidden email]> 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