2009/2/28 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> 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?
>

Let me put my 5 cents :)
I personally, don't see anything wrong. I think things like
micro-kernel, mini-image, kernel-image (or call it as you like) should
be there from a very starting of existance of Squeak, but i can only
guess why its not existing.

Since the first time i met the squeak, an inability to bootstap own
image were always chasing me.
I didn't wanted a pre-built image, like 3.8. I wanted my own, small
image which contains as little as it can to be able to run my own
code. I din't care about rest. Then i found that there is no such
thing (or there is, but solutions is not nearly as trivial as they
should be), and this was very disappointing to me. :(

I know, that paradigm behind every smalltalk is to view an object
memory as a set of ever-evolving living objects.
>From that point, the need of reiterating the Process of Creation
(bootstrapping) having a little value.
But following this road, it lost a most valuable things , like
modularity and ability to automatically strip down to a core.
It vent to a point, that cutting out an 'optional' elements from
image, like Morphic became an untrivial trask which requires high
expertise, and cosumes a lot of time.
I think everyone agrees, that well designed system should allow us to
do that easily, without risk of crippling the neck while trying :)

> 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 would do it different, and in most same way as we doing it in
smalltalk from day to day:
make a class
MyOwnPlugin
 - put a methods, which is common for all platforms,
 - put #isAbstract to return 'true' on class side
then you're free to add
MyOwnWIN32Plugin
MyOwnUnixPlugin
etc.

It would be much more elegant than using C-isms which producing #if-s
around the code. A generated code will be clean, and more easy to
read/audit/whatever. :)
Lets not be lazy , sometimes you could have only a single method,
which behaves differently for different platfroms, but putting it into
a subclass will serve much more for clarity.

And the last thing, i dreaming to have everything in VMMaker /
smalltalk classes. To make every bit of code sitting in slang code and
get rid of manually crafted sources. Yes, we need to improve VMMaker
and slang syntax to make things more easy, especially make things
easier than writing C code manually.

VMMaker, is a metaprogramming tool, and we could modify it
particularily easy comparing to modification of manually-crafted
sources.
(a Hydra is a good example of it  -- i changed VMMaker to produce a
code which could run multiple interpreter instances , while keeping
most of the code (> 99%) in ObjectMemory and Interpreter classes
untouched)

Imagine how much harder it would be if, we don't having VMMaker and VM
sources consisting from manually crafted C sources.

> 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__ ;

good point.

> Best
> Eliot
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.