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

[David T. Lewis]

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