VMMaker organzation (was: Re: [Vm-dev] Fwd: Include CryptographicPrimitives In VM's - DESPlugin)

[Ron Teitelbaum]

+1 from n00b (so I don't really count).

By the way what are the chances that those people that are currently
maintaining platform VMs will actually be building new VM's?  Is there a
schedule or process, or just random recompilation?  (I'm not asking that a
new vm be created since we have more plug-ins to contribute yet, I was just
wondering)

Thanks,
Ron

> -----Original Message-----
> From: vm-dev-bounces at lists.squeakfoundation.org [mailto:vm-dev-
> bounces at lists.squeakfoundation.org] On Behalf Of Andreas Raab
> Sent: Monday, October 16, 2006 6:40 PM
> To: Squeak Virtual Machine Development Discussion
> Subject: VMMaker organzation (was: Re: [Vm-dev] Fwd: Include
> CryptographicPrimitives In VM's - DESPlugin)
> 
> 
> Hi Tim and all -
> 
> I'm wondering if we shouldn't "decentralize" the development of VMMaker
> a little. Right now, it seems pretty awkward for someone developing a
> plugin to update that plugin in any reasonable way. For example, the
> current VMMaker release has a somewhat outdated CroquetPlugin which
> -while not horribly broken- fails a few important tests in replication
> (I only noticed that over the weekend btw). The current solution set
> consists of me sending something via email to you in the hope it'll end
> up in some future version of VMMaker. Whether it's gotten there or not I
> can't tell without actually looking at the code itself, e.g., there
> isn't an easy way for me to say "oh, no, Tim's forgotten to include the
> latest Croquet plugin for the 3.9 release! Where is the tar? Where are
> the feathers?" ;-)
> 
> So here is a question: What if we organize a monticello repository with
> sub-packages for the individual plugins which then get updated by
> individuals maintaining these? What I'm thinking about is something like:
> 
>    VMMaker-Generation (CCodeGen, VMMaker, UI)
>    VMMaker-Interpreter (ObjectMemory, Interpreter)
>    VMMaker-Crypto (all the crypto plugins)
>    VMMaker-Croquet (all the croquet related ones)
> 
> etc. This would allow (say) Ron to update the crypto plugin
> independently from me updating the Croquet plugins and it wouldn't
> require you to be in the loop for every minor change. "Real" releases
> might be managed simply by posting a Monticello configuration that lists
> all the packages for that particular version of VMMaker (plus optional
> file releases through SM - I've used load scripts to good effect for
> that in the FFI and one could probably even write a translator that
> takes a configuration as input and spits out an SM loadscript).
> 
> Does this make sense to anyone but me?
> 
> Cheers,
>    - Andreas
> 
> 
> tim Rowledge wrote:
> >
> > I'll add DESPlugin to the next release of VMMaker and you can then
> > persuade the vm makers to make sure it is included for testing.
> >
> > tim
> > --
> > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> > Great leaders inspire by example. When that's not an option, brute
> > intimidation works pretty well.
> >
> >
> >