[Vm-dev] A proposal to split VMMaker into subpackages WAS: [ VM Maker: VMMaker-dtl.304.mcz ]

[David T. Lewis]

On Tue, Mar 19, 2013 at 11:19:05AM -0700, Eliot Miranda wrote:
>  
> On Tue, Mar 19, 2013 at 5:19 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> >
> > On Tue, Mar 19, 2013 at 12:51:02PM +0100, Esteban Lorenzano wrote:
> > >
> > > yes... in that case, since some time now I want to propose a VMMaker
> > package split.
> > > I still do not have a real suggestion now, but looks to me that we
> > should be able to split it in something like:
> > >
> > > VMMaker-Core
> > >       VMMaker-Cog
> > >       VMMaker-Interpreter
> > >       VMMaker-Plugins
> > >               VMMaker-Plugin1
> > >               ...
> > >               VMMaker-PluginN
> > > VMMaker-InterpreterSimulation
> > > VMMaker-JITSimulation
> > >
> > > etc...
> > >
> > > (hierarchy for dependences)
> > >
> > > this time we can reduce the granularity and restrain the changes just to
> > where it is needed...
> > >
> > > what do you think?
> > >
> >
> > This will be a good idea when, and only when, we have achieved real
> > progress
> > in merging the oscog and trunk branches. We are not there yet.
> >
> > I would be interested to hear from Eliot, but from my point of view this
> > would
> > make it much more difficult to manage the changes between the two branches.
> >
> > I have some experience in dealing with this in the OSProcess and
> > CommandShell,
> > and I found that in some cases splitting things into too many packages can
> > cause a lot of unnecessary work with little real benefit. I would rather
> > live
> > with the wasted disk space and rely on Monticello to manage the changes.
> >
> > Clearly though it is a good objective longer term, and we will get there.
> >
> > Dave
> >
> 
> Personally I like the following broad separation:
> 
> 1. VM (Interpreter, StackInterpreter, CoInterpreter, Cogit, Simulation)
> 2. Plugins
> 3. Slang + VMMaker
> 
> The VM and the simulator are too tightly bound to separate and I don't see
> much use in separating off the simulator; it's not that large.  Note that
> the processor support for simulation of the Cog VM is in Cog already.

This seems like a good level of separation to me also.

> 
> Plugins are logically distinct and it would be a step towards merging the
> trunk interpreter and Cog if plugins were in a separate package and merged.
>  I'd be for doing this quite soon.

I agree.

> 
> With Slang + VMMaker separated we might find it easier to experiment with
> e.g. using the Cog Slag on the Interpreter (the other way round isn't going
> to work, sicne Cog requires lots of Slang extensions, especially with
> record types such as CogMethod).
> 
> But the main problem I see here is that there's lots of Slang dependencies
> on the class side of Interpreter classes, all of the translation protocol
> for example.  That might be quite hard to tease out.  I think separating
> plugins is the worthwhile step now.  What do y'all think?
> -- 
> best,
> Eliot

I think that separating the plugins now is a good idea. I would like to take
some time (say perhaps a week) to review the current differences so we will
know what to expect, but overall I think that we have the plugins fairly close
already. The remaining differences are due more to accident than intent, so
resolving these should be quite manageable.

We will need a package name that does not start with "VMMaker". Suggestions?

Dave