On 01.03.2009, at 05:02, Avi Bryant wrote:

> On Sat, Feb 28, 2009 at 7:32 PM, Eliot Miranda <eliot.miranda at gmail.com 
> > wrote:
>
>> I need to point out that unless the various communities can start  
>> building
>> their disparate and diverging images form a micro-kernel image I  
>> don't see
>> how improved execution technology is going to be adopted by the  
>> community.
>>  I'm working hard on a VM that will be potentially 10x the current  
>> Squeak VM
>> for Smalltalk intensive benchmarks.  This VM will be source code  
>> compatible
>> and bytecode compatible but likely it will not be image compatible  
>> as it
>> will use a streamlined object representation that doesn't use compact
>> classes.  The only way I can see this being adopted by the  
>> community at
>> large is if the community starts building images form microkernels.
>
> I'm not sure that's true.  Say it becomes yet another fork, separate
> (necessarily, at first, because it's a different image format) from
> all of the other forks.  As long as most packages can be loaded into
> it, it'll get used.  Maybe not by the people doing the forking (by
> Scratch, say, or Squeakland), but by the majority of us who have a few
> pet packages (in my case, Seaside, OmniBrowser, DabbleDB, etc) that we
> can load into nearly any Squeak image and feel at home.  I'm pretty
> happy to load those into a MinimalMorphic image this month, a Pharo
> image next month, and a Cog image the month after, if there's some
> compelling reason to do so - and 10x performance would certainly be
> compelling.
>
> A shared microkernel would be nice, but I don't think it's essential
> in the short term to drive adoption of a new technology.

Agreed.

I'm still looking for ways to get Squeakland Etoys and squeak.org  
sharing resources as much as possible. We last cross-merged for the  
3.8 release, which was a considerable manual effort, but worth it for  
both sides (etoys got many bug fixes, squeak.org got the m17n/unicode  
support). After that, some new packages were shared (Rome, DBus,  
GStreamer), but no reliable process for exchanging bug fixes exists -  
not because we do not want it, but because it's simply too much effort.

I'll support anyone who finds a way around this, a way to share  
between forks. Matthew's proposal sounds great and doable. I'll  
advocate starting to use Monticello for Etoys development - it's the  
only feasible way to share I see currently.

Sharing a microkernel image would be nice but I fear too much has  
changed in the class/metaclass kernel to make that feasible.  But  
perhaps for using Cog, does it really require extensive image-level  
changes, or couldn't the SystemTracer be used to convert the image  
format?

- Bert -