[Vm-dev] Add argvec and envec to sqVirtualMachine.[ch]? (was: FT2Plugin stops working with latest version)

[Esteban Lorenzano]

well... my opinion: 

1) I more or less agree with Igor: I don't think to expose everything to every plugin around is good. But I can be wrong... this is just an opinion and is *against* the smalltalk principles, in particular the "absolute openess, so you can make your system as you want"... the problems is that if we open everything, in mid time it will be hard to maintain... so... we have a problem here. 
2) I do not like OSProcess plugin living inside the vm, as an internal plugin, just because "why not others, then"? also... if you want to break the API (by using whatever you want...), you just need to make your plugin "internal", and that's it... no more restrictions... and the same problem for maintaining in the future. 
3) I think best solution is to re-think which functions are going to be visible... I agree with Dave we need to expose argv (and argc)... why? because I can think on plugins who need some "configuration". 

So, my two cents, in short term: I would expose argc and argv through exported functions and adapt OSProcess plugin to use it (I think that's the only problem with OSProcess... maybe some other functions. 

best,
Esteban

pd: Dave, please, please... if you have 5', can you see the BytesPerWord problem?


El 05/10/2011, a las 11:41a.m., David T. Lewis escribió:

> 
> On Wed, Oct 05, 2011 at 04:15:20PM +0200, Igor Stasenko wrote:
>> 
>> On 5 October 2011 14:15, David T. Lewis <lewis at mail.msen.com> wrote:
>>> 
>>> On Tue, Oct 04, 2011 at 03:48:18PM +0200, Igor Stasenko wrote:
>>>> 
>>>> On 4 October 2011 14:17, David T. Lewis <lewis at mail.msen.com> wrote:
>>>>> 
>>>>> I think there was an issue on some of the Mac platforms that required
>>>>> a compiler flag to force the compiler to make global variables visible
>>>>> (for the environment vector, etc). Is that the problem here? I do not
>>>>> have a Mac, but I'll try to help figure this out if I can.
>>>>> 
>>>> 
>>>> If i remember correctly, a Cocoa VM using different entry point for
>>>> main() function.
>>>> or have some other differencies, so you cannot just pass argc, argv
>>>> around, but you have to prepare them.
>>>> 
>>>> If you remember, i proposed to make an API for exposing these
>>>> variables, so then not only OSProcess could access them
>>>> but any other plugin, without need of hackish linking flags, which
>>>> lead to confusion and too compiler/linker specific.
>>> 
>>> Yes, I do remember this suggestion (although I can't find a pointer
>>> to it right now). I was mildly (not strongly) against it, but what do
>>> others think?
>>> 
>>> My opinion was based on:
>>> 
>>> 1) Setting a compiler flag to instruct it to make globals visible does
>>> not seem hackish to me. After all, most of the compilers we use work
>>> like that anyway, and it does not seem to be hurting them.
>>> 
>>> 2) In order for the definitions to be visible for both a standard
>>> interpreter VM and a Cog/stack VM, the definitions would need to be
>>> added to the existing VM_PROXY_MINOR 9 definitions. That amounts
>>> to changing the defined interface without incrementing the version
>>> number, which definitely does seem hackish to me (though probably
>>> harmless).
>>> 
>>> 3) The argument vector and environment vector are Unix constructs.
>>> Adding platform specific things to the interpreter interface should
>>> be avoided. Again, this is harmless since all of the major platforms
>>> mimic Unix in this respect, but still ... all the world is not unix ;)
>>> 
>>> In any case, I do not have a strong opinion one way or the other,
>>> I'm just explaining my perspective on it.
>>> 
>>> Other opinions? Esteban, you are probably most directly affected
>>> by this, do you have a preference?
>>> 
>> 
>> I have a strong opinion, that modules (and plugins) should access only
>> those symbols, which are explicitly exported by module(s) they using,
>> and not rely on something granted for free (implicitly visible via
>> linker/compiler flags).
>> Because if we don't care, then why do we need things like
>> InterpreterProxy at all, if any plugin could just link directly to any
>> VM function/variable in order to use it?
>> Apparently, such approach violates the module encapsulation, because
>> you no longer make sure that some symbols of your module is private
>> and should not be
>> accessed by others.
> 
> If no one else speaks up, then your strong opinion will outvote my
> weak opinion.
> 
>> Also, may i ask, why OSProcess needs those vectors at all?
>> Maybe a better solution would be to just avoid using them?
>> I think, that it should be a responsibility of main module to expose
>> those vectors, if it wants to, but not by a plugin. Because it again,
>> violating the encapsulation principles.
> 
> OSProcess is full of stuff that I put in just because I felt like
> doing it. To be honest, I never expected it to be widely used by other
> people. And I certainly was not attempting to rise to any high standards
> of software purity ;) Having said that, I do think that it is important
> to avoid putting platform-dependent things into the VM and image. What
> I choose to put into my own plugin or my own project is my business
> (and the development of OSProcess was an example of that), but I do
> not think it is good for "features" in OSProcess to creep into the
> core system.
> 
> Dave
>