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

[Eliot Miranda]

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.

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?
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130319/ecdd2b5a/attachment.htm