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

[Igor Stasenko]

On 10 October 2011 15:39, David T. Lewis <lewis at mail.msen.com> wrote:
>
> On Sun, Oct 09, 2011 at 10:05:12AM -0400, David T. Lewis wrote:
>>
>> On Fri, Oct 07, 2011 at 10:22:02PM +0200, Igor Stasenko wrote:
>> >
>> > On 7 October 2011 21:07, David T. Lewis <lewis at mail.msen.com> wrote:
>> > >
>> > > On Fri, Oct 07, 2011 at 05:55:00PM +0200, Igor Stasenko wrote:
>> > >>
>> > >> 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:
>> > >> >> >
>> > >> >> > 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.
>> > >>
>> > >
>> > > It's about modularity. I maintain the three plugins for OSProcess as separate
>> > > packages independent of any version of VMMaker. As with any such problem, maintaining
>> > > the integrity os interfaces is the key to success.
>> > >
>> > The things which i proposing leaving you less to maintain.
>> > I do not see any conflict there.
>> >
>> > > I also care about the people who might use these packages, and often I do not even
>> > > know who they are. ??If someone in Japan or China or a researcher at a university
>> > > wants to build a VM with whatever flavor of Squeak or VMMaker, I want my packages
>> > > to work without problems.
>> > >
>> >
>> > To my observations, this kind of "modularity" never worked without
>> > paying attention (testing & fixing) every time
>> > to new stuff which goes out. Every time something got broken, every
>> > update has some roughness
>> > we have to overcome.
>> >
>> > Remember the numerous reports about OSProcess not working here and
>> > there, FFI here and there, Freetype and so on.
>> > As to me the experience actually showing completely opposite: using
>> > modules as a solution for compatibility
>> > are largely failing.
>> >
>> > > I also am lazy. I find that a little time and effort making sure the interfaces
>> > > work saves a lot of my time later on. If I don't break something, I don't have
>> > > to waste time later on explaining why it does not work. That is the same reason
>> > > I write lots of tests and comments. It just saves a lot of time and excuses later
>> > > on.
>> >
>> > Dont wanna go into deep philosophical discussion, just wanna say that
>> > changing and improving are not synonyms to breaking. :)
>> >
>> > >
>> > > That is the approach I have taken, and it has worked well for me so far.
>> > >
>> >
>> > But it doesn't works. Otherwise there will be no point for current
>> > discussion. Isn't?
>> >
>> > Clever hacks, not matter how clever they are are still remain hacks.
>> > My proposal is to remove them
>> > order to have more consistent interaction between OSP and VM.
>> > I consider the current model having flaws, which needs to be fixed.
>> > And if fixing the flaw meaning to break it, yes lets break it. You
>> > cannot break something which was already broken before.
>>
>> If you feel that this is important, then please go ahead and work
>> on it. As long as the changes do not break things for other people
>> (e.g. the standard interpreter VM), you have my personal commitment
>> to add whatever may be necessary in OSPP. But I will not break
>> compatibility for other VM projects, that is my only point.
>>
>> Please proceed.
>>
>
> Hi Igor,
>
> I added the necessary support to OSPP in VMConstruction-Plugins-OSProcessPlugin-dtl.31,
> and tested it on Linux with standard interpreter VM. All works as
> expected, so if you want to give it a try, the functions that must
> be exported are:
>
>  char  **ioGetEnvVec(void);
>  char  **ioGetArgVec(void);
>  int   ioGetArgCount(void);
>
> I don't have a Mac, so I'll leave it to you (or Esteban) to add the
> hooks in the platforms support code.
>
> The OSPP code will use the global variables when exported functions are
> not available, and it is possible that this will cause problems with
> unreferenced variables on Carbon. I have no way of testing this, so
> if you try it and find problems please let me know.
>

Thanks, Dave.
I added it to issue tracker to not forget.
http://code.google.com/p/cog/issues/detail?id=63

> HTH,
> Dave
>
>



-- 
Best regards,
Igor Stasenko.