<br><br><div class="gmail_quote">On Sat, Feb 28, 2009 at 1:17 AM, edgar De Cleene <span dir="ltr"><<a href="mailto:edgardec2001@yahoo.com.ar">edgardec2001@yahoo.com.ar</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d"><br>
> A standard "kernel image" that everyone builds<br>
> off of has long<br>
> been a pipe dream of nearly everyone in the community. I<br>
> believe<br>
> that such an image is not achievable in the short term;<br>
> convincing all of the squeak distributions to adopt it<br>
> would be<br>
> nearly impossible to adopt incrementally.<br>
><br>
<br>
</div>Such image exist and is MorphicCore of Pavel Krivanek.<br>
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</blockquote><div><br></div><div>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.</div>
<div><br></div><div>All images derived from it should be derived by running scripts (repeatable process). These scripts should be versioned.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br>
</div><div>Craig, do you agree?</div><div><br></div><div>If so, how much of this do you have already?</div><div><br></div><div>If not, what have I got wrong? </div><div><br></div><div><br></div><div>BTW, I intend to build something like this when and if I do a new object representation for Cog later this year.</div>
<div><br></div><div>(also see BTW2 below)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The first step was 3.10 as Ralph and me design and build and Damien use for the dev images.<br>
The second step is SqueakLightII , which moves out and lets reload EToys and Nebraska (and others)<br>
Also brings the idea of the Class repository and the "intelligent load".<br>
This is in beta now and could load old and new code and foreing forks code ins some cases.<br>
Only needs help for polish this ideas and reach the common ground to all Squeaks forks.<br>
<br>
And we need "official images" , like Linux have a common kernel<br>
<br>
<br>
A clarification:<br>
Was not me the Morphic wizard, was the amazing Morphic Team I and II with Dan , Ned, Juan, Jerome.<br>
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.<br>
<br>
Edgar<br>
<br>
<br>
Yahoo! Cocina<br>
Recetas prácticas y comida saludable<br>
<a href="http://ar.mujer.yahoo.com/cocina/" target="_blank">http://ar.mujer.yahoo.com/cocina/</a><br>
</blockquote></div><div><br></div><div>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.</div>
<div> myWindowsOnlyPrimitive</div><div> <platforms: #(Win32)></div><div> self blah</div><div>generates</div><div>#if WIN32</div><div>sqInt</div><div>myWindowsOnlyPrimitive()<br>
</div><div>{</div><div> blah();</div><div>}</div><div>#endif /* WIN32 */</div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div><div>/* Automatically generated by</div><div> CCodeGenerator * VMMaker-eem.293 uuid: dff7906f-2c49-4278-9401-8bccc2e6ef13</div><div> from</div><div> SimpleStackBasedCogit * VMMaker-eem.293 uuid: dff7906f-2c49-4278-9401-8bccc2e6ef13</div>
<div> */</div><div>static char __buildInfo[] = "SimpleStackBasedCogit * VMMaker-eem.293 uuid: dff7906f-2c49-4278-9401-8bccc2e6ef13 " __DATE__ ;</div><div><br></div></div><div>Best</div><div>Eliot</div>