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

[Igor Stasenko]

On 7 October 2011 16:18, David T. Lewis <lewis at mail.msen.com> wrote:
>
> On Fri, Oct 07, 2011 at 10:53:51AM +0200, Igor Stasenko wrote:
>>
>> On 7 October 2011 01:39, David T. Lewis <lewis at mail.msen.com> wrote:
>> >
>> > On Thu, Oct 06, 2011 at 04:34:17PM +0200, Igor Stasenko wrote:
>> >>
>> >> On 6 October 2011 14:11, David T. Lewis <lewis at mail.msen.com> wrote:
>> >> >
>> >> > On Wed, Oct 05, 2011 at 05:19:48PM +0200, Igor Stasenko wrote:
>> >> >>
>> >> >> 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.
>> >> >
>> >> > To check my understanding, do you mean #ioLoadFunction:From: as implemented
>> >> > in vm/sqNamedPrims.c, so the idea would be to treat the main VM as a module,
>> >> > and load functions that answer the argvec and envvec from that module?
>> >> >
>> >>
>> >> Right. It is already treated as a module, so it is not new.
>> >
>> > Thanks, I understand now.
>> >
>> > I'll try this with OSPP when I get a chance. Meanwhile, if you want
>> > to take the lead on this issue to get the exported functions added
>> > to platforms code, that would be good.
>> >
>> > I need to ensure that OSPP runs on trunk as well as oscog branches,
>> > which means that updates to all those branches would be best. But
>> > I suspect it may be possible to adopt a strategy of loading with
>> > ioLoadFunction, and if this fails, try a direct reference to the
>> > global variable (though I don't know if Carbon will allow this?).
>> >
>>
>>
>> Why? Why keeping workarounds?
>
> Because for OSProcessPlugin I choose to maintain a certain level of
> backward compatibity and support for as many different VM projects
> as possible.
>

You lost me here.
VM is evolving, things keep changing. Can you tell me any of the
reason for keeping a freshly-built
plugin to be compatible with 10-years old VMs?
One could always use older version(s) of plugin which works with that
VMs.. so, what is the problem?

Can you explain me , what is the benefits from staying compatible with
dusty systems which, most probably,
are used by 1% of users (if any)?

IMO, the purpose of plugin subsystem should be to serve as a way to
customize the VM(s) for various kinds of distributions, but not as a
way
to ensure that something which was working 10 years ago, will keep
working today without any changes.


>> You can introduce this logic right now in OSPP, without waiting
>> updates to VM sources,
>> since there are no any requirements to change VM code to be compatible.
>> If those symbols are not exported by VM module, then plugin should
>> behave as if platform have no support for this functionality,
>> which is pretty fair (as you already told - some platforms/build
>> configurations could simply not provide it). Its fine.
>
> I will give it a try as soon as I have a chance (but I am traveling,
> so maybe not this weekend).
>
>> You fail primitive etc, and it is perfectly ok as to me.
>> As soon as newer VMs will start exporting those symbols, an updated
>> OSPP will be available to provide corresponding functionality.
>
> It might be OK with you, but it is *not* OK with me.
>
>>
>> Does that makes sense?
>
> Yes, and thanks very much for your patience in explaining the export
> mechanism (sorry I was so dense before!).
>

You were not even close to testing my patience.
Actually by saying "does it makes sense" i meant "does it sounds like
a plan"? :)


> Thanks,
> Dave



-- 
Best regards,
Igor Stasenko.