On Sat, Feb 28, 2009 at 1:17 AM, edgar De Cleene
<edgardec2001 at yahoo.com.ar>wrote:

>
> > A standard "kernel image" that everyone builds
> > off of has long
> > been a pipe dream of nearly everyone in the community. I
> > believe
> > that such an image is not achievable in the short term;
> > convincing all of the squeak distributions to adopt it
> > would be
> > nearly impossible to adopt incrementally.
> >
>
> Such image exist and is MorphicCore of Pavel Krivanek.
> We should go towards this , removing packages from the top and reshaping
> packages if packages as we know today can't be unloades/loaded nicely


Any image containing a GUI is a non-starter IMO.  People may not want a GUI
(e.g. the embedded and scripting folks).  People may want a particular GUI
(MVC, Morphic, Tweak, Newspeak, Croquet, one of the native GUIs) with no
vestiges of the old one.  So the common image needs to be a small headless
core that can bootstrap any image.  This image needs minimal scripting
support to respond to command-line bootstrap commands (including
cross-platform stdin & stdout and a file interface), a compiler with which
to compile code, collections, magnitudes, exceptions (as necessary), a
default error handler that dumps the stack to stdout and then aborts, and
that's about it.

All images derived from it should be derived by running scripts (repeatable
process).  These scripts should be versioned.

Further, this initial image should be built from scratch, e.g. using John
Maloney's MicroSqueak as a starting point.  In MicroSqueak a sub-hierarchy
rooted at MObject (but it could be MProtoObject) defines the classes that
will end-up in the generated micro-kernel image.  So this set of classes can
be defined as a package and loaded into any Squeak.  An image builder
analyses the MObject hierarchy and from it generates a new image containing
only the classes in that category with all globals renamed from MFoo back to
Foo.  There are other approaches but John's is a good one.  One can test the
result within Smalltalk using the IDE. (There are limitations; nil, true,
false, Symbol, SmallInteger et al are not rooted in MObject but in Object).
 One can browse the package using the IDE.

The results of building from this can be recorded, e.g. if one bootstraps a
minimal Morphic image from this "micro kernel Squeak image" the minimal
Morphic image can itself be a starting point for other images because it is
also a known repeatably generatable object.  So it too can reliably serve as
the seed for other images.

Of course, any image can serve as the seed for any other but if it was built
by hand and is ever lost it can never be recreated; at least one can never
be sure one has recreated it exactly.

Craig, do you agree?

If so, how much of this do you have already?

If not, what have I got wrong?


BTW,  I intend to build something like this when and if I do a new object
representation for Cog later this year.

(also see BTW2 below)

The first step was 3.10 as Ralph and me design and build and Damien use for
> the dev images.
> The second step is SqueakLightII , which moves out and lets reload EToys
> and Nebraska  (and others)
> Also brings the idea of the Class repository and the "intelligent load".
> This is in beta now and could load old and new code and foreing forks code
> ins some cases.
> Only needs help for polish this ideas and reach the common ground to all
> Squeaks forks.
>
> And we need "official images" , like Linux have a common kernel
>
>
> A clarification:
> Was not me the Morphic wizard, was the amazing Morphic Team I and II with
> Dan , Ned, Juan, Jerome.
> I only learn a little of they and wish learn a lot of you, Andreas, etc as
> I learning of all wonderful people in Board today.
>
> Edgar
>
>
>      Yahoo! Cocina
> Recetas prácticas y comida saludable
> http://ar.mujer.yahoo.com/cocina/
>

BTW2, IMO this (headless generation) also applies to the VM.  VMMaker is fun
but difficult to audit, error-prone and source-code-control/repeatability
unfriendly.  The VMMaker needs to be scriptable so that it can generate VM
sources headlessly (easily done; the Newspeak team have already done it).
 Further, producing different versions of the source for different platforms
is questionable.  I would arrange that metadata on methods identified
platform-specific code, e.g.
         myWindowsOnlyPrimitive
                   <platforms: #(Win32)>
                   self blah
generates
#if WIN32
sqInt
myWindowsOnlyPrimitive()
{
        blah();
}
#endif /* WIN32 */
at least for the core VM, so that people can build a core VM for their
platform from a single check-out containing one copy of the sources, not
three.

I've recently made one good step in this direction in changing the header
VMMaker generates.  The exiating one includes the date on which one pushed
the button (what use is that?? It tells one *nothing* about what one has
produced or where it came from; if one pushes the button starting from
exactly the same starting point as yesterday one generates different
sources?!?!?!).  The change is to state the packages from which it was
built, e.g. here revealing one can't trust this because the package isn't
checked in (as the * indicates).

/* Automatically generated by
    CCodeGenerator * VMMaker-eem.293 uuid:
dff7906f-2c49-4278-9401-8bccc2e6ef13
   from
    SimpleStackBasedCogit * VMMaker-eem.293 uuid:
dff7906f-2c49-4278-9401-8bccc2e6ef13
 */
static char __buildInfo[] = "SimpleStackBasedCogit * VMMaker-eem.293 uuid:
dff7906f-2c49-4278-9401-8bccc2e6ef13 " __DATE__ ;

Best
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090228/979d858d/attachment.htm