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

[Igor Stasenko]

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?
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.
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.

Does that makes sense?


> Dave
>
>



-- 
Best regards,
Igor Stasenko.