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

[Igor Stasenko]

On 5 October 2011 16:41, David T. Lewis <lewis at mail.msen.com> wrote:
>
> 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.
>

I understand the situation around plugin, Dave.

Yes, it is platform dependent. You can compile main module with
different entry point (non POSIX), where you don't have access to
argv/argc variables at all.
For instance windows WinMain() function does not have them.
But my point was more about who should take care about exposing those
symbols, not about whether all platforms should support this API or
not.

So, the point is, that since argc/argv stuff are coming from main
module, then main module should care about
exposing (or not) these symbols, not the third-party plugin.


> Dave

-- 
Best regards,
Igor Stasenko.