[Vm-dev] Add argvec and envec to sqVirtualMachine.[ch]? (was:
FT2Plugin stops working with latest version)
siguctua at gmail.com
Fri Oct 7 20:22:02 UTC 2011
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
>> 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
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
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.
More information about the Vm-dev