On 7 October 2011 01:39, David T. Lewis lewis@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@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