<br><br><div class="gmail_quote">On Tue, Mar 19, 2013 at 5:19 AM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On Tue, Mar 19, 2013 at 12:51:02PM +0100, Esteban Lorenzano wrote:<br>
><br>
> yes... in that case, since some time now I want to propose a VMMaker package split.<br>
> I still do not have a real suggestion now, but looks to me that we should be able to split it in something like:<br>
><br>
> VMMaker-Core<br>
> VMMaker-Cog<br>
> VMMaker-Interpreter<br>
> VMMaker-Plugins<br>
> VMMaker-Plugin1<br>
> ...<br>
> VMMaker-PluginN<br>
> VMMaker-InterpreterSimulation<br>
> VMMaker-JITSimulation<br>
><br>
> etc...<br>
><br>
> (hierarchy for dependences)<br>
><br>
> this time we can reduce the granularity and restrain the changes just to where it is needed...<br>
><br>
> what do you think?<br>
><br>
<br>
</div>This will be a good idea when, and only when, we have achieved real progress<br>
in merging the oscog and trunk branches. We are not there yet.<br>
<br>
I would be interested to hear from Eliot, but from my point of view this would<br>
make it much more difficult to manage the changes between the two branches.<br>
<br>
I have some experience in dealing with this in the OSProcess and CommandShell,<br>
and I found that in some cases splitting things into too many packages can<br>
cause a lot of unnecessary work with little real benefit. I would rather live<br>
with the wasted disk space and rely on Monticello to manage the changes.<br>
<br>
Clearly though it is a good objective longer term, and we will get there.<br>
<br>
Dave<br></blockquote><div><br></div><div>Personally I like the following broad separation:</div><div><br></div><div>1. VM (Interpreter, StackInterpreter, CoInterpreter, Cogit, Simulation)</div><div>2. Plugins</div><div>3. Slang + VMMaker</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br>
</div><div>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).</div>
<div><br></div><div>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?</div>
</div>-- <br>best,<div>Eliot</div>