VM "team"

David T. Lewis lewis at mail.msen.com
Thu Mar 17 02:36:15 UTC 2005

On Tue, Mar 15, 2005 at 01:02:58PM -0800, Andreas Raab wrote:
> Hi Ned,
> This sounds good to me and I don't see many changes compared to current
> practice. The major change would be the one that I actually object to:
> Namely having the VMMaker code in SVN instead of having it with the
> appropriate Squeak release. This I really don't like. In my
> understanding, people who want to work with the VM should use:
> * The Squeak version they want to build a VM from.
> * A support code package matching that Squeak version.
> The support code (e.g., the stuff written in C) should come from SVN,
> but the Squeak code (the portion which is translated) should come with
> Squeak, not with the C code.
> Cheers,
>    - Andreas
> Ned Konz wrote:


> > * Additional platform- or plugin-specific Squeak code, documentation, test
> > code, scripts, demos, etc. should also be maintained on SVN, together with
> > the plugin or platform code that it works with. For instance, it's typical
> > that an optional plugin may have Squeak code to actually make it work. So for
> > instance (say for the OSProcess plugin):
> >
> > /trunk
> >     platforms
> >         Cross
> >             plugins
> >                 OSProcess
> >         unix
> >             plugins
> >                 OSProcess
> >

Just for the record, the OSProcess plugin is written in Squeak (Slang)
and requires no C code to make it work. The only thing that appears in
the platforms tree is a Makefile.inc that fixes up the include path for
the C preprocessor.  For what it's worth, I favor Andreas' view of keeping
VMMaker code in the Squeak release, and the support code in SVN.


More information about the Vm-dev mailing list