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