Repository name(s) [was Re: [Vm-dev] svn git bridge? ...]

[David T. Lewis]

On Mon, May 02, 2016 at 04:27:11PM -0700, Eliot Miranda wrote:
> 
> Hi Tobias,
> 
> > On May 2, 2016, at 12:12 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
> > 
> > 
> > Hi Eliot,
> > 
> >> On 02.05.2016, at 20:54, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >> 
> >>> Hi Tobias,
> >>> 
> >>> On Mon, May 2, 2016 at 7:10 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
> >>> 
> >>> 
> >>>> On 26.04.2016, at 07:52, Esteban Lorenzano <estebanlm at gmail.com> wrote:
> >>>> 
> >>>> 
> >>>>> On 25 Apr 2016, at 23:57, Frank Shearar <frank.shearar at gmail.com> wrote:
> >>>>> 
> >>>>> On 23 April 2016 at 10:01, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >>>>> 
> >>>>> Hi All,
> >>>>> 
> >>>>>    one very important question is what are the names of the top level git repository and sub modules?  Before you suggest something please check that the name isn't already used on github.
> >>>>> 
> >>>>> Here are some suggestions
> >>>>> 
> >>>>> http://cogvm.github.io/.com
> >>>>> http://backtothefuture.github.io/.com
> >>>>> https://opensmalltalkvm.github.io/com
> >>>>> 
> >>>>> 
> >>>>> _,,,^..^,,,_ (phone)
> >>>>> 
> >>>>> FWIW I'd go with "cogvm". Short, sweet, to the point.
> >>>> 
> >>>> +1
> >>> 
> >>> That would imply to ditch the interpreter vm altogether.
> >>> so  -0 from me???
> >> 
> >> That's not the intention.  
> > 
> > I thought so. My statement might have been a bit succinct. I'd should have written "This name would sound as if it implied that we ditched..."
> > 
> >> What we need is some effort to integrate the ContextInterpreter back into VMMaker.oscog.  David doesn't have the time.  The Interpreter in VMMaker.oscog is both ahead and behind the VMMaker Interpreter.
> > 
> > I thought so.
> > 
> >> The VMMaker.oscog one has Andreas' profiler improvements, but it hasn't been refactored to not inherit from ObjectMemory and and fixes that have been applied to VMMaker's Interpreter could do with being integrated.  But it's not a hinge join, just not one I or David have time for.  Is there anyone out there with curiosity for the VM who does have some time?
> >> 
> >> Tobias, any students you can point at the task?  It's a refactoring job and I'll hand hold.
> > 
> > I understand that this is important yet tedious work. I could ask around, but I won't promise anything.
> > 
> > Yes, I know that the branches should converge again.
> > But how does that solve the naming issue? Would the (Context)Interpreter become another flavor of CogVM?
> 
> Yes.  Since it would be able to use Spur that wouldn't be theft, more an exchange :-)

Regarding naming, I think that Eliot's distintion between the traditional
"context interpreter" and the "stack interpreter" makes perfect sense. Thus
the traditional interpreter VM is ContextInterpreter, and the stack interpreter
(upon which the Cog and Spur work is based), is StackInterpreter. Both of these
subclass from Interpreter.

For the object memory, the corresponding classes are ClassicObjectMemory and
NewObjectMemory, both of which inherit from ObjectMemory.

The traditional "interpreter VM" is now built from ContextInterpreter and
ClassicObjectMemory from the VMMaker trunk repository. A stack interpreter
built from that repository will generate its code from StackInterpreter
and NewObjectMemory. This configuration does not yet work in the VMMaker
trunk branch. I think that it is close to working, but I have been saying
that for several years now, so don't trust me on this.

My hope is to get to the point where a working stack interpreter can be
built from StackInterpreter and NewObjectMemory in VMMaker trunk. If and
when that works, we would have a known good code base from which the trunk
changes could be back-ported to ("exchanged with"?) the oscog repository
for Cog and Spur.

Dave