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

[David T. Lewis]

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.

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.

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.

That is the approach I have taken, and it has worked well for me so far.

Dave