[squeak-dev] Burn the Squeak Image! (Why I am running for board)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
74 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Burn the Squeak Image! (Why I am running for board)

Tapple Gao
Squeak is a growing community with diverse needs. We have long
outgrown the monolithic image left to us by our founders, Dan
Ingalls and company. The community has long been building its
own images for many purposes, targeting many audiences:
end-users, application developers, core developers, and
researchers. Some examples:

2001: Squeakland Etoys
2002: Croquet
2003: Spoon, by Craig Latta. An experiment in very high
      modularity
2004: DPON, by Michael van der Gulik: A project to revive Henrik
      Godenryd's modularity framework abandoned in Squeak 3.3
2005: Morphic removal, by Edgar J. de Cleene
2006: Scratch, by MIT Media Lab: An end-user application for
      easily building and sharing animations, and teaching basic
      programming
2007: squeak-dev, by Damien Cassau. A distribution targeted
      toward application developers.
2008: Pharo, by Stephane Ducasse and others. A team focused on
      dramatically raising the code quality, usabily, and
      standards conformance of squeak overall.

We need to burn from our minds the idea that there is one
"official" squeak image that serves the needs of the whole
community. It is a lie.

Given that no "official image" can meet the needs of everybody,
who should we target when building something official?

We need to build things for those who would build better images
themselves. Having many good images to choose from makes
everybody happier. The only issue with the situation is that
they are not always compatible. I believe this is the core issue
that the board and the squeak release team needs to address.

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.

A more practical approach to that end is Standard Packages. A
major issue we have currently is that bugs get fixed in one
distribution, but never applied to another. However, if all
distributions of squeak used the same version of a package, it
would be very easy: fix the bug in the common package, and each
distribution will eventually upgrade to it.

I would like the board to do the following project, and I can
manage it:

    By this time next year, every squeak distribution
    (squeak.org, Pharo, eToys, cobalt) will be running a
    standard version of the following three packages:
    - Collections
    - Streams
    - Compiler

    We will also fix and close all of the issues on mantis
    relating to these packages

If we start this process and continue it, we will eventually
have enough standard packages to build a kernel image, and
everybody will already be running on it.


I do not believe the board should do this to the exclusion of
all else, just as one of several projects. I fully support
Andreas's election platform: we should indeed start having both
a stable and unstable release, both happening in parallel

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Burn the Squeak Image! (Why I am running for board)

Edgar J. De Cleene

> 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

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/


Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)

Klaus D. Witzel
In reply to this post by Tapple Gao
On Sat, 28 Feb 2009 09:20:55 +0100, Matthew Fulmer wrote:

...
> I would like the board to do the following project, and I can
> manage it:
>
>     By this time next year, every squeak distribution
>     (squeak.org, Pharo, eToys, cobalt) will be running a
>     standard version of the following three packages:
s/three/four/
        - Magnitude
>     - Collections
>     - Streams
>     - Compiler
>
>     We will also fix and close all of the issues on mantis
>     relating to these packages
...

--
"If at first, the idea is not absurd, then there is no hope for it".  
Albert Einstein


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Burn the Squeak Image! (Why I am running for board)

Eliot Miranda-2
In reply to this post by Edgar J. De Cleene


On Sat, Feb 28, 2009 at 1:17 AM, edgar De Cleene <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)

Klaus D. Witzel
On Sat, 28 Feb 2009 15:35:49 +0100, Eliot Miranda wrote:

> On Sat, Feb 28, 2009 at 1:17 AM, edgar De Cleene 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).

Sure, and Pavel's has this all, and it's working, no wonder that Edgar  
often mentions it:

- http://www.cincomsmalltalk.com/userblogs/ralph/blogView?entry=3342635112

> 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.

Interesting. Where is that one, search didn't show it:

- http://www.google.com/search?q=John+Maloney+MicroSqueak

[... much more good stuff cut away ...]

--
"If at first, the idea is not absurd, then there is no hope for it".  
Albert Einstein


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Burn the Squeak Image! (Why I am running for board)

Pavel Krivanek
In reply to this post by Edgar J. De Cleene
The KernelImage ZOO including the building environment is here:
http://squeak.cz/public/pub/KernelImage/current/

Of course it is not perfect - the smallest image works only in Linux
and MorphicCore needs a lot of fixes so people should start with
MorphicExt and so on but it is usable starting point if someone is
interested...

-- Pavel

On Sat, Feb 28, 2009 at 10:17 AM, edgar De Cleene
<[hidden email]> 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
>
> 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/
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)

Eliot Miranda-2
In reply to this post by Klaus D. Witzel


On Sat, Feb 28, 2009 at 7:44 AM, Klaus D. Witzel <[hidden email]> wrote:
On Sat, 28 Feb 2009 15:35:49 +0100, Eliot Miranda wrote:


On Sat, Feb 28, 2009 at 1:17 AM, edgar De Cleene 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).

Sure, and Pavel's has this all, and it's working, no wonder that Edgar often mentions it:

- http://www.cincomsmalltalk.com/userblogs/ralph/blogView?entry=3342635112

If it doesn't have a GUI then why is it called MorphicCore??!
Reading from the blog entry it looks like it has eToys removed but not much more.
Pavel, is it a headless image?
Klaus, if the image is not headless ten it doesn't meet my specification.

 


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.

Interesting. Where is that one, search didn't show it:

- http://www.google.com/search?q=John+Maloney+MicroSqueak

[... much more good stuff cut away ...]


--
"If at first, the idea is not absurd, then there is no hope for it". Albert Einstein





Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Burn the Squeak Image! (Why I am running for board)

Igor Stasenko
In reply to this post by Eliot Miranda-2
2009/2/28 Eliot Miranda <[hidden email]>:

>
>
> On Sat, Feb 28, 2009 at 1:17 AM, edgar De Cleene <[hidden email]>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)

David Mitchell-10
In reply to this post by Eliot Miranda-2
KernalImage doesn't have a GUI. It can load Monticello packages. He
has a script that will load in MorphicCore.

MorphicCore does (but has many bugs).

MorphicExt is more stable, but larger.

KernalImage is a Squeak image without any GUI. It has collections,
numbers, classes, the compiler, but little else. It has a text-based
UI that can evaluate Smalltalk expressions, and it can load files from
disk. Pavel has a fileIn for Monticello, so then you can load any
other package, as long as it doesn't have a GUI.

His other image is called MinimalMorphic. He has a Monticello package
for it, so you can load it from KernalImage. MinimalMorphic isn't
particularly minimal, but it has had some stuff (like eToys) removed
and I think he wants to remove more. It is a basic Morphic
environment, showing that you can separate MVC from Morphic.



On Sat, Feb 28, 2009 at 9:51 AM, Eliot Miranda <[hidden email]> wrote:

>
>
> On Sat, Feb 28, 2009 at 7:44 AM, Klaus D. Witzel <[hidden email]>
> wrote:
>>
>> On Sat, 28 Feb 2009 15:35:49 +0100, Eliot Miranda wrote:
>>
>>> On Sat, Feb 28, 2009 at 1:17 AM, edgar De Cleene 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).
>>
>> Sure, and Pavel's has this all, and it's working, no wonder that Edgar
>> often mentions it:
>>
>> - http://www.cincomsmalltalk.com/userblogs/ralph/blogView?entry=3342635112
>
> If it doesn't have a GUI then why is it called MorphicCore??!
> Reading from the blog entry it looks like it has eToys removed but not much
> more.
> Pavel, is it a headless image?
> Klaus, if the image is not headless ten it doesn't meet my specification.
>
>>
>>> 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.
>>
>> Interesting. Where is that one, search didn't show it:
>>
>> - http://www.google.com/search?q=John+Maloney+MicroSqueak
>>
>> [... much more good stuff cut away ...]
>>
>> --
>> "If at first, the idea is not absurd, then there is no hope for it".
>> Albert Einstein
>>
>>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)

Klaus D. Witzel
On Sat, 28 Feb 2009 16:55:38 +0100, David Mitchell wrote:

> KernalImage doesn't have a GUI.

Here's a bit more background; Eliot is this headless enough?

-  
http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-October/096111.html

> It can load Monticello packages. He
> has a script that will load in MorphicCore.
>
> MorphicCore does (but has many bugs).
>
> MorphicExt is more stable, but larger.
>
> KernalImage is a Squeak image without any GUI. It has collections,
> numbers, classes, the compiler, but little else. It has a text-based
> UI that can evaluate Smalltalk expressions, and it can load files from
> disk. Pavel has a fileIn for Monticello, so then you can load any
> other package, as long as it doesn't have a GUI.
>
> His other image is called MinimalMorphic. He has a Monticello package
> for it, so you can load it from KernalImage. MinimalMorphic isn't
> particularly minimal, but it has had some stuff (like eToys) removed
> and I think he wants to remove more. It is a basic Morphic
> environment, showing that you can separate MVC from Morphic.
>
>
>
> On Sat, Feb 28, 2009 at 9:51 AM, Eliot Miranda wrote:
>>
>>
>> On Sat, Feb 28, 2009 at 7:44 AM, Klaus D. Witzel wrote:
>>>
>>> On Sat, 28 Feb 2009 15:35:49 +0100, Eliot Miranda wrote:
>>>
>>>> On Sat, Feb 28, 2009 at 1:17 AM, edgar De Cleene 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).
>>>
>>> Sure, and Pavel's has this all, and it's working, no wonder that Edgar
>>> often mentions it:
>>>
>>> -  
>>> http://www.cincomsmalltalk.com/userblogs/ralph/blogView?entry=3342635112
>>
>> If it doesn't have a GUI then why is it called MorphicCore??!
>> Reading from the blog entry it looks like it has eToys removed but not  
>> much
>> more.
>> Pavel, is it a headless image?
>> Klaus, if the image is not headless ten it doesn't meet my  
>> specification.
>>
>>>
>>>> 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.
>>>
>>> Interesting. Where is that one, search didn't show it:
>>>
>>> - http://www.google.com/search?q=John+Maloney+MicroSqueak
>>>
>>> [... much more good stuff cut away ...]
>>>
>>> --
>>> "If at first, the idea is not absurd, then there is no hope for it".
>>> Albert Einstein
>>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)

Eliot Miranda-2


On Sat, Feb 28, 2009 at 8:19 AM, Klaus D. Witzel <[hidden email]> wrote:
On Sat, 28 Feb 2009 16:55:38 +0100, David Mitchell wrote:

KernalImage doesn't have a GUI.

Here's a bit more background; Eliot is this headless enough?

Yes, this looks good.  I would still prefer to go that little bit further and construct the core image from first principles, e.g. using John Maloney's MicroSqueak, as I described earlier in this thread.  But Pavel's headless core looks to me to be functionally the right starting point.  In any case it can be used to derive the other images while the first-principles bootstrap is being built (if it doesn't exist already).

Why go that "little bit further" and create the image from first principles?  Repeatability.  The the freedom to choose new object representations and bytecode sets, & hence Bootstrapping new languages like Newspeak is much easier.  Hydra might benefit from pre-packaged minimal starting-points that can easily be tailored.


- http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-October/096111.html

It can load Monticello packages. He
has a script that will load in MorphicCore.

MorphicCore does (but has many bugs).

MorphicExt is more stable, but larger.

KernalImage is a Squeak image without any GUI. It has collections,
numbers, classes, the compiler, but little else. It has a text-based
UI that can evaluate Smalltalk expressions, and it can load files from
disk. Pavel has a fileIn for Monticello, so then you can load any
other package, as long as it doesn't have a GUI.

His other image is called MinimalMorphic. He has a Monticello package
for it, so you can load it from KernalImage. MinimalMorphic isn't
particularly minimal, but it has had some stuff (like eToys) removed
and I think he wants to remove more. It is a basic Morphic
environment, showing that you can separate MVC from Morphic.



On Sat, Feb 28, 2009 at 9:51 AM, Eliot Miranda wrote:



On Sat, Feb 28, 2009 at 7:44 AM, Klaus D. Witzel wrote:

On Sat, 28 Feb 2009 15:35:49 +0100, Eliot Miranda wrote:

On Sat, Feb 28, 2009 at 1:17 AM, edgar De Cleene 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).

Sure, and Pavel's has this all, and it's working, no wonder that Edgar
often mentions it:

- http://www.cincomsmalltalk.com/userblogs/ralph/blogView?entry=3342635112

If it doesn't have a GUI then why is it called MorphicCore??!
Reading from the blog entry it looks like it has eToys removed but not much
more.
Pavel, is it a headless image?
Klaus, if the image is not headless ten it doesn't meet my specification.


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.

Interesting. Where is that one, search didn't show it:

- http://www.google.com/search?q=John+Maloney+MicroSqueak

[... much more good stuff cut away ...]

--
"If at first, the idea is not absurd, then there is no hope for it".
Albert Einstein








Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)

Klaus D. Witzel
On Sat, 28 Feb 2009 17:56:54 +0100, Eliot Miranda wrote:

> On Sat, Feb 28, 2009 at 8:19 AM, Klaus D. Witzel wrote:
>
>> On Sat, 28 Feb 2009 16:55:38 +0100, David Mitchell wrote:
>>
>>  KernalImage doesn't have a GUI.
>>>
>>
>> Here's a bit more background; Eliot is this headless enough?
>
>
> Yes, this looks good.  I would still prefer to go that little bit further
> and construct the core image from first principles, e.g. using John
> Maloney's MicroSqueak, as I described earlier in this thread.  But  
> Pavel's
> headless core looks to me to be functionally the right starting point.  
> In
> any case it can be used to derive the other images while the
> first-principles bootstrap is being built (if it doesn't exist already).
>
> Why go that "little bit further" and create the image from first  
> principles?
>  Repeatability.

Agreed, repeatability, but the language of first principles is set to be  
Smalltalk and their [principles] "imagination" is objects, so this sounds  
a bit abstract, no?

> The the freedom to choose new object representations and
> bytecode sets, & hence Bootstrapping new languages like Newspeak is much
> easier.

Right, this was the reason that Moebius was born (formerly: CorruptVM):  
have any pair of old and new representations interoperable, same for pairs  
of old and new instruction sets.

> Hydra might benefit from pre-packaged minimal starting-points that can  
> easily be tailored.

:)

--
"If at first, the idea is not absurd, then there is no hope for it".  
Albert Einstein


Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)

Zulq Alam-2
In reply to this post by Edgar J. De Cleene
Hi All,

edgar De Cleene 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
>

OK, so then we have a minimal image. How then do we see it is used as
the kernel for etoys, croquet, spoon, pharo, etc? I think Matthew's
point is less about producing a minimal image and more about forks
standardising on core packages incrementally until they eventually agree
with each other on some notion of a kernel image.

If I understand correctly the images mentioned in this thread,
SqueakLightII, MorphicCore etc would all be expected to adopt these
standard packages.

My suggestion is that only an image which includes standard packages
alone should be called a core image (and then only if one is needed?
Would it be needed?). I'd reserve the term kernel image for the types of
images Eliot and others are discussing.

- Zulq

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)

Ramon Leon-5
OK, so then we have a minimal image. How then do we see it is used as the kernel for etoys, croquet, spoon, pharo, etc? I think Matthew's point is less about producing a minimal image and more about forks standardising on core packages incrementally until they eventually agree with each other on some notion of a kernel image.

If I understand correctly the images mentioned in this thread, SqueakLightII, MorphicCore etc would all be expected to adopt these standard packages.

My suggestion is that only an image which includes standard packages alone should be called a core image (and then only if one is needed? Would it be needed?). I'd reserve the term kernel image for the types of images Eliot and others are discussing.

- Zulq

Seems no one heard a word Matthew said.  The idea that all those different forks will adopt some minimal kernel image is frankly absurd and highly unlikely to ever happen.  Matthew's correct, the best we could hope for would be to get them using common core packages and even that isn't trivial and requires workers rather than board members. 

Andreas is the only person I've seen proposing anything at all pragmatic for the board to do.  They should stop trying to plan the future and start harvesting the present,  get things that are done and proven into the main image.  If it isn't done, and already in use by some subset of the community then it shouldn't exist in the eyes of the board.

This idea that the board should be leading things is frankly flawed, all the forked version of and sub-communities of Squeak are the real leaders, they're the ones doing the work, experimenting with new ideas both good and bad, and making progress, the board should be following them and picking out the usable pieces for inclusion in the mainline Squeak, or better yet, Matthew's idea of core packages and forget the idea of a main Squeak image altogether.

Ramon Leon
http://onsmalltalk.com



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)

Edgar J. De Cleene
In reply to this post by Eliot Miranda-2




--- El sáb 28-feb-09, Eliot Miranda <[hidden email]> escribió:


> >
> >  KernalImage doesn't have a GUI.
> >>
> >
> > Here's a bit more background; Eliot is this
> headless enough?
>
>
> Yes, this looks good.  I would still prefer to go that
> little bit further
> and construct the core image from first principles, e.g.
> using John
> Maloney's MicroSqueak, as I described earlier in this
> thread.  But Pavel's
> headless core looks to me to be functionally the right
> starting point.  In
> any case it can be used to derive the other images while
> the
> first-principles bootstrap is being built (if it
> doesn't exist already).
>

This first principles you said could be the Fenix image and technique of Alejandro Reimondo (Chachara files)
I take his technique and image and could do a partial port to SqueakLightII and have success in build some of his examples for Big Endian (PPC) , the original was for Windows only (Intel).




      Yahoo! Cocina
Recetas prácticas y comida saludable
http://ar.mujer.yahoo.com/cocina/


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)

Edgar J. De Cleene
In reply to this post by Zulq Alam-2

> My suggestion is that only an image which includes standard
> packages alone should be called a core image (and then only
> if one is needed? Would it be needed?). I'd reserve the
> term kernel image for the types of images Eliot and others
> are discussing.
>
> - Zulq

All images discussed here have some kind of trouble.
And yes, I agree on standard packages as several mentioned before.
But again I ask going forward and think about a Class repository as I using for reloading all "missed classes" when some .morph or .pr coming of different fork is dragged and drop or selected via file list in SqueakLightII.

This Class repository could be easily produced for any fork.
We could agree on the common ground between forks and could be easier fix or improve the code of only a Class and not of a bigger package.

And a script for generate a valid image could load from this Class repository , like others Smalltalks do

Edgar


      Yahoo! Cocina
Recetas prácticas y comida saludable
http://ar.mujer.yahoo.com/cocina/


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)

Igor Stasenko
2009/3/1 edgar De Cleene <[hidden email]>:

>
>> My suggestion is that only an image which includes standard
>> packages alone should be called a core image (and then only
>> if one is needed? Would it be needed?). I'd reserve the
>> term kernel image for the types of images Eliot and others
>> are discussing.
>>
>> - Zulq
>
> All images discussed here have some kind of trouble.
> And yes, I agree on standard packages as several mentioned before.
> But again I ask going forward and think about a Class repository as I using for reloading all "missed classes" when some .morph or .pr coming of different fork is dragged and drop or selected via file list in SqueakLightII.
>
> This Class repository could be easily produced for any fork.
> We could agree on the common ground between forks and could be easier fix or improve the code of only a Class and not of a bigger package.
>
> And a script for generate a valid image could load from this Class repository , like others Smalltalks do
>
So, in this repository a most simple brick is a class?
How it could deal then with extension methods, or overrides?
If you add code which handling them, eventually you will get similar
thing to MC :) So, what the difference?

> Edgar
>
>
>      Yahoo! Cocina
> Recetas prácticas y comida saludable
> http://ar.mujer.yahoo.com/cocina/
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)

Zulq Alam-2
In reply to this post by Ramon Leon-5
Hi Ramon,

Ramon Leon wrote:
> Seems no one heard a word Matthew said.  The idea that all those
> different forks will adopt some minimal kernel image is frankly absurd
> and highly unlikely to ever happen.  Matthew's correct, the best we
> could hope for would be to get them using common core packages and even
> that isn't trivial and requires workers rather than board members.

I was trying to guide the discussion back to Matthews proposal which I
agree with. I'm not suggesting they should adopt any image. I do think
however, that when a notion of a core/kernel image (set of Standard
packages) is converged upon then an image is built and released
containing these packages - perhaps a conversation for another day/thread.

I think getting the various communities to buy in and commit to a vision
of shared core packages should be the responsibility of the board. It
should be in each communities interest to work on such an activity. This
is where the real work will need to be done.

> Andreas is the only person I've seen proposing anything at all pragmatic
> for the board to do.  SNIP

What isn't pragmatic about Matthew's proposal? I don't think he suggests
  that the board does this themselves - maybe I misunderstood.

Matthew - could you explain further what you see are the boards roles
and responsibilities in a Standard Packages project?

> This idea that the board should be leading things is frankly flawed, all
> the forked version of and sub-communities of Squeak are the real
> leaders, they're the ones doing the work, experimenting with new ideas
> both good and bad, and making progress, the board should be following
> them and picking out the usable pieces for inclusion in the mainline
> Squeak, or better yet, Matthew's idea of core packages and forget the
> idea of a main Squeak image altogether.

I don't think the board should be following and picking. I don't think
that works. The sub communities should be playing an active role in this
and I think it should be the boards responsibility to:

   - Convince each community that it's worth doing
   - Find out and agree what needs to be done
   - Enable each community to work
       - Remove barriers
       - Define processes
       - Resources: tools, email lists, servers, etc
   - Manage the overall progress and lend support where necessary

- Zulq

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)

keith1y
In reply to this post by Igor Stasenko
Hello everyone,

+1 to everything Andreas, and Matthew said.

To re-iterate this is exactly where we have been heading with the squeak
3.11 effort.

If you look at the goal we want to achieve, it is clear that there are
two ways to approach it.
1) From the bits upwards as Elliot describes, and 2) From what we have,
and are using in production, downwards, in a carefully planned,
engineered effort.

Both ways require tools that work, ways for packaging things, defining
packages, dependencies, and loading those modules and tools for
generating the required result form the starting point.

We have several of these bottom up efforts on the go, Spoon, and
Coke/Pepsi/fonc/Albert or whatever it is called today. For myself I am
not a bits/bytes guy, not having to deal with that stuff is one reason I
came to Smalltalk in the first place.

1) So... Spoon
Spoon is an example of starting from the bottom, with a fresh view, a
fresh look at these tools. One hopes that spoon will do all of these
things superlatively, but I fear it will be a long time until I can use
it for my commercial stuff.

2) 3.11/4.0+  = Tools that allow us to Build stuff test stuff, package
stuff, and load stuff

The expectation is that with these tools in place everyone can benefit,
whether it be myself evolving 3.10 on to 3.11 slowly, Matthew in the
relicencing, or Edgar and Klaus with the kernel images.

If we all have the same tools, and compatible packaging, external to our
treasured creations, we start to have some common ground, and the
ability to share ideas.

We do not expect to get everyone to use the exact same kernel, but we
think we can get folks sharing stuff. If they share tools like
Monticello, then it ensures that there is some minimal level of
compatibility preserved between the forks. They can only share stuff
like Monticello, if they can load it and keep up with the most
maintained versions.

Once the common tools are in place, then Matthews common core packages
can actually happen. 3.11 may not change much in functionality, but it
is planning to do things like splitting "System" category up into sub
packages.

regards

Keith



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)

Ramon Leon-5
In reply to this post by Zulq Alam-2
I was trying to guide the discussion back to Matthews proposal which I agree with. I'm not suggesting they should adopt any image.

You misunderstand, I was agreeing with you, the comment about what was absurd wasn't in reply to you but to the previous suggestion that all these different forks could be convinced to come back to a core image; just isn't going to happen.
 
I think getting the various communities to buy in and commit to a vision of shared core packages should be the responsibility of the board. It should be in each communities interest to work on such an activity. This is where the real work will need to be done.

Again, I was agreeing with that position.

Andreas is the only person I've seen proposing anything at all pragmatic for the board to do.  SNIP

What isn't pragmatic about Matthew's proposal? I don't think he suggests  that the board does this themselves - maybe I misunderstood.

I like his proposal, that doesn't make it pragmatic, at least, not as pragmatic as what Andreas is always saying, harvest what's done, rather than making big plans for doing stuff that the past has shown rarely works out.

One of Squeaks big problems, IMHO, is that every version is planned and realised by someone grand idea of features that should be in the next version.  More often than not, this is vaporware, work someone wants to do, or thinks can be done, but isn't done, so everyone waits and waits and waits for a new version.

I'd much rather see releases done by specific dates, like a release every 6 months, each release harvesting the latest fixes and patches of accomplished work.  Make it easier to get new stuff integrated into the core by releasing regularly and often rather than these pie in the sky visions of what might be.  Guaranteed steady gradual evolution and continual progress beats the hell out of revolutionary grand changes that might or might not actually happen.
 
I don't think the board should be following and picking. I don't think that works. The sub communities should be playing an active role in this and I think it should be the boards responsibility to:

 - Convince each community that it's worth doing
 - Find out and agree what needs to be done
 - Enable each community to work
     - Remove barriers
     - Define processes
     - Resources: tools, email lists, servers, etc
 - Manage the overall progress and lend support where necessary

- Zulq

Which is what they've been doing, it's not been working so well.  The Squeak community wouldn't be splintered into so many fragments otherwise.  The Pharo guys forked because it's the only way to get anything done, it takes too long to try and get anything real done in the core Squeak, progress is glacial, so everyone forks.

Keith and Matthew are right, focus on packages and tools for sharing code, Andreas is right, focus on what's done, integrate it, make progress, stop the pie in the sky dreams of the ultimate system, or core kernel image, or whatever other pipe dream people keep chasing that clearly isn't being used by all the sub communities anyway. 

I don't care what image I use, I care what packages I use.  I care that my Collections package is the latest and greatest, or that my Seaside package is up to date, or that I'm using the newest FFI, or the right Polymorph.  I don't care about eToys or Graphics or 3D or anything to do with educating kids.  Packages are more important than images.  The only thing I want from an image is that it isn't bloated with a bunch of unloadable code like eToys that infects everything and breaks everything when you try and remove it.

Elliot is right about building images from scripts as well, I want to automate the builds of the images I use with a script to load onto a base image just the packages I want.  Damien does this now with his dev images, a good starting point for me, then I use a script and Keiths installer to further load and customize it to my liking.

Anyway, now I'm just rambling, so I'll leave it at that.  +1 for tools, Packages, and integrate what's done and get it out.

Ramon Leon
http://onsmalltalk.com


1234