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

Igor Stasenko siguctua at gmail.com
Wed Oct 5 15:19:48 UTC 2011


So, my proposal is to add
TheArgC and TheArgV variables to exports table of system module,
in same way as on windows it uses to expose stWindow variable:


void *os_exports[][3] = {
...
  {"","stWindow", &stWindow},
  {"", "argc" , &theArgc }
....
};


then any plugin could lookup for given symbol using ioLoadFunction() function,
and if there is no such symbol, then ok.. it will answer null , fail
the primitive etc etc.

So, there is no need to change an API, just need to add few entries to
os_exports structure.


On 5 October 2011 17:13, Igor Stasenko <siguctua at gmail.com> wrote:
> 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.
>



-- 
Best regards,
Igor Stasenko.


More information about the Vm-dev mailing list