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

Dave