argCnt, argVec, engVec alternatives

>
> Well these aren't vm variables they are the environment,  and pointer(s) to arguments passed to the executable at launch time via the command line.  
> it's all pure unix logic, nothing to do with the vm. You could of course have a fetch routine on the interpreter proxy to better hide the implementation details as you
> already have an primitive to fetch the parms from the VM. Not sure about the environment variables I don't think there was an api to allow smalltalk code to get at those?
>
> On 2011-01-05, at 10:01 AM, Esteban Lorenzano wrote:
>
>>
>> Hi,
>> Ok, I'm trying to run the UnixOSProcessPlugin on Cocoa Cog VM (own version, still not updated with latest from Eliot). One of the things I need to solve is some references to argCnt, argVec, engVec in plugin implementation... I think it is not-good give a plugin access to vm parameters through globals...
>> So, I wonder if there is an alternative to elegantly provide this...
>>
>> Cheers,
>> Esteban
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>

> I would like to commit a OSProcessPlugin package with modifications... or well, maybe project owner can do this changes for me (I just removed primitivePrintAllStacksOnSignal, printAllStacksFunctionAddress and printAllStacksOnSignal).
>
> now... I will work on AioPlugin :P
>
> Cheers,
> Esteban
>
> pd: btw... CommandShell is really funny ;)
>
> El 05/01/2011, a las 3:08p.m., John M McIntosh escribió:
>
>>
>> Well these aren't vm variables they are the environment,  and pointer(s) to arguments passed to the executable at launch time via the command line.
>> it's all pure unix logic, nothing to do with the vm. You could of course have a fetch routine on the interpreter proxy to better hide the implementation details as you
>> already have an primitive to fetch the parms from the VM. Not sure about the environment variables I don't think there was an api to allow smalltalk code to get at those?
>>
>> On 2011-01-05, at 10:01 AM, Esteban Lorenzano wrote:
>>
>>>
>>> Hi,
>>> Ok, I'm trying to run the UnixOSProcessPlugin on Cocoa Cog VM (own version, still not updated with latest from Eliot). One of the things I need to solve is some references to argCnt, argVec, engVec in plugin implementation... I think it is not-good give a plugin access to vm parameters through globals...
>>> So, I wonder if there is an alternative to elegantly provide this...
>>>
>>> Cheers,
>>> Esteban
>>
>> --
>> ===========================================================================
>> John M. McIntosh <[hidden email]>   Twitter:  squeaker68882
>> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
>> ===========================================================================
>>
>>
>>
>>
>
>

>
> On Wed, Jan 05, 2011 at 03:30:19PM -0300, Esteban Lorenzano wrote:
>>
>> ok... removing call to printAllStack in plugin and adding initialization
>> of argCnt, argVec and engVec (plus the changes made last week),
>> UnixOSProcessPlugin, without AioPlugin, is running in Cocoa Cog VM :D
>>
>
> Excellent!
>
>> I would like to commit a OSProcessPlugin package with modifications...
>> or well, maybe project owner can do this changes for me (I just removed
>> primitivePrintAllStacksOnSignal, printAllStacksFunctionAddress and
>> printAllStacksOnSignal).
>>
>
> Actually, if you don't mind working with me on this a bit more, I'd
> like to debug it. I suspect we can can make this work on Cocoa.
>
> We know now that external plugins can access global values such
> as argVec and interpreterProxy, and we know that this works the
> same on Unix and Mac. The last thing that is giving us problems
> is when primitivePrintAllStacksOnSignal tries to access the address
> of the function printAllStacks(). This happens here in the plugin:
>
>  static void * printAllStacksFunctionAddress(void) {
>      extern sqInt printAllStacks();
>          return printAllStacks;
>  }
>
> So the declaration looks right, but apparently accessing the
> address of a global function is not the same as accessing the
> value of a global variable, and perhaps this is a difference
> between the Unix/Linux systems and Mac.
>
> So I am guessing that if, in the support code, we were to assign
> the function address to a global variable, then the plugin would
> be able to access it, and #primitivePrintAllStacksOnSignal would
> work properly.
>
> If this sounds like it might be right, I'll try to think of a way
> to implement it without breaking the existing unix implementations.

>
> Hi,
>
> El 05/01/2011, a las 10:56p.m., David T. Lewis escribió:
>
>>
>> On Wed, Jan 05, 2011 at 03:30:19PM -0300, Esteban Lorenzano wrote:
>>>
>>> ok... removing call to printAllStack in plugin and adding initialization
>>> of argCnt, argVec and engVec (plus the changes made last week),
>>> UnixOSProcessPlugin, without AioPlugin, is running in Cocoa Cog VM :D
>>>
>>
>> Excellent!
>>
>>> I would like to commit a OSProcessPlugin package with modifications...
>>> or well, maybe project owner can do this changes for me (I just removed
>>> primitivePrintAllStacksOnSignal, printAllStacksFunctionAddress and
>>> printAllStacksOnSignal).
>>>
>>
>> Actually, if you don't mind working with me on this a bit more, I'd
>> like to debug it. I suspect we can can make this work on Cocoa.
>>
>> We know now that external plugins can access global values such
>> as argVec and interpreterProxy, and we know that this works the
>> same on Unix and Mac. The last thing that is giving us problems
>> is when primitivePrintAllStacksOnSignal tries to access the address
>> of the function printAllStacks(). This happens here in the plugin:
>>
>>  static void * printAllStacksFunctionAddress(void) {
>>      extern sqInt printAllStacks();
>>          return printAllStacks;
>>  }
>>
>> So the declaration looks right, but apparently accessing the
>> address of a global function is not the same as accessing the
>> value of a global variable, and perhaps this is a difference
>> between the Unix/Linux systems and Mac.
>>
>> So I am guessing that if, in the support code, we were to assign
>> the function address to a global variable, then the plugin would
>> be able to access it, and #primitivePrintAllStacksOnSignal would
>> work properly.
>>
>> If this sounds like it might be right, I'll try to think of a way
>> to implement it without breaking the existing unix implementations.
>
>
> yes, that would work. In fact, declaring printAllStacks() as:
>
> EXPORT(sqint) printAllStacks();
>
> ... works too. And even adding setting -fvisibility=default (which exports ALL symbols) will work too. But I think the last one is a little bit too much: visibility=default is default for plain gcc compiler, but not un mac now (I think that's the reason why it was working before and not now) :)
>

>
> On 6 January 2011 03:15, Esteban Lorenzano <[hidden email]> wrote:
> >
> > El 05/01/2011, a las 10:56p.m., David T. Lewis escribi??:
> >
> >> On Wed, Jan 05, 2011 at 03:30:19PM -0300, Esteban Lorenzano wrote:
> >>>
> >>> ok... removing call to printAllStack in plugin and adding initialization
> >>> of argCnt, argVec and engVec (plus the changes made last week),
> >>> UnixOSProcessPlugin, without AioPlugin, is running in Cocoa Cog VM :D
> >>
> >> Excellent!
> >>
> >>> I would like to commit a OSProcessPlugin package with modifications...
> >>> or well, maybe project owner can do this changes for me (I just removed
> >>> primitivePrintAllStacksOnSignal, printAllStacksFunctionAddress and
> >>> printAllStacksOnSignal).
> >>>
> >> Actually, if you don't mind working with me on this a bit more, I'd
> >> like to debug it. I suspect we can can make this work on Cocoa.
> >>
> >> We know now that external plugins can access global values such
> >> as argVec and interpreterProxy, and we know that this works the
> >> same on Unix and Mac. The last thing that is giving us problems
> >> is when primitivePrintAllStacksOnSignal tries to access the address
> >> of the function printAllStacks(). This happens here in the plugin:
> >>
> >> ??static void * printAllStacksFunctionAddress(void) {
> >> ?? ?? ??extern sqInt printAllStacks();
> >> ?? ?? ?? ?? ??return printAllStacks;
> >> ??}
> >>
> >> So the declaration looks right, but apparently accessing the
> >> address of a global function is not the same as accessing the
> >> value of a global variable, and perhaps this is a difference
> >> between the Unix/Linux systems and Mac.
> >>
> >> So I am guessing that if, in the support code, we were to assign
> >> the function address to a global variable, then the plugin would
> >> be able to access it, and #primitivePrintAllStacksOnSignal would
> >> work properly.
> >>
> >> If this sounds like it might be right, I'll try to think of a way
> >> to implement it without breaking the existing unix implementations.
> >
> >
> > yes, that would work. In fact, declaring printAllStacks() as:
> >
> > EXPORT(sqint) printAllStacks();
> >
> > ... works too. And even adding setting -fvisibility=default (which exports ALL symbols) will work too. But I think the last one is a little bit too much: visibility=default is default for plain gcc compiler, but not un mac now (I think that's the reason why it was working before and not now) :)
> >

>
> So, how it works for Squeak VM, where #printAllStacks is listed in
> #requiredMethodNames,
> which meand that generator should always retain this method in source code,
> but it is not means that printAllStacks symbol is visible to external
> module(s).. I mean the declaration is just:
> sqInt printAllStacks(void);
>
> Doesn't symbols should be marked for export to make them visible
> externally? Or on unix systems its not necessary?
>
> Ah.. -fvisibility=default explains this.
>
> Heh.. but then out of curiosity,  why do we need to use
> interpreterProxy struct, while plugins can just use any VM function(s)
> directly,
> even through dynamic linking?
>
> Okay, in Cog this function marked as a part of api.