[Vm-dev] A proposal to split VMMaker into subpackages WAS: [ VM
Maker: VMMaker-dtl.304.mcz ]
David T. Lewis
lewis at mail.msen.com
Tue Mar 19 20:18:59 UTC 2013
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.
> 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?
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?
More information about the Vm-dev