[Vm-dev] VM team

Ken G. Brown kbrown at mac.com
Sun Apr 12 00:02:10 UTC 2009

At 11:05 AM -0400 4/11/09, David T. Lewis apparently wrote:
>The Squeak oversight board suggested that we formalize a VM team
>(http://squeakboard.wordpress.com/) and Bert asked if I would be willing
>to serve as team leader. I replied that I would be happy to do so.
>I'd like to start by asking the list, and specifically the major platform
>developers (Ian, John, Andreas) for your support - do you agree that
>this is a good idea, and are you willing to have me serve as team
>We will need to set some team objectives, and then establish a plan
>to achieve them. For starters, here are some initial ideas for a set
>of VM team objectives. All comments, additions, deletions, objections,
>etc are welcome.
>- Community
>  - Communicate status and announcements to the community
>  - Periodically update team objectives based on community input
>  - Ensure availability of known-good versions (SqueakMap, Universes, SqueakSource)
>  - Identify where help is needed (e.g. Sugar, Ubuntu, sound support)
>  - Where appropriate, inform Board of resource or funding needs
>    (e.g. access to computers for building and testing VM distributions)
>- Support Squeak as an open system
>  - Support educational goals, an accessible VM is part of Squeak as a learning tool
>  - Write it in Squeak, run it in Squeak, debug it in Squeak (InterpreterSimulator should work)
>  - Everyone should be able to explore and create their own Squeak VM
>  - Ensure license integrity
>- Provide solid base to enable VM distributions
>  - Support distribution developers (Ian, John, Andreas, Tim, others)
>    - Primary support for Mac/Win/unix/iSqueak
>    - Enablement for others including RiscOS and SqueakNOS, new projects
>    - Identify resources to support distribution developers
>  - Coordinate changes across the several platform source trees and VMMaker
>  - Ensure owners and maintainers for plugins
>  - Drive resolution of Mantis issues
>- Provide base to support new ideas for VM
>  - Support and enable new development (Spoon, Exupery, Cog, Hydra, others)
>  - Enable new image formats (including 64-bit object memory, Cog)
>- Support Squeak new directions
>  - Support eToys, OLPC, SqueakNOS, Cuis, Pharo
>  - Provide common VM where possible, encourage extensions as needed

Maybe now would be the time to go through the plugins and make all the names of source folders, plugin names and generated plugin names more consistent with the convention? Some cleanup would surely improve things for the future by reducing the confusion factor.

Way back, I was rooting around everywhere learning where things happened and it being the first time through, I was initially quite confused by the following:

internal plugin B3DEnginePlugin generated as Squeak3D
internal plugin BalloonEnginePlugin generated as B2DPlugin
internal plugin BitBltSimulation generated as BitBltPlugin
internal plugin DSAPlugin generated as DSAPrims
internal plugin DeflatePlugin generated as ZipPlugin
internal plugin FFIPlugin generated as SqueakFFIPrims
internal plugin KlattSynthesizerPlugin generated as Klatt
internal plugin LargeIntegersPlugin generated as LargeIntegers

There most likely are more that I missed.

Ken G. Brown

More information about the Vm-dev mailing list