[Vm-dev] Add argvec and envec to sqVirtualMachine.[ch]? (was:
FT2Plugin stops working with latest version)
siguctua at gmail.com
Wed Oct 5 14:15:20 UTC 2011
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
> 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
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.
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.
More information about the Vm-dev