[squeak-dev] Burn the Squeak Image! (Why I am running for board)
Locked
1234
1234
[squeak-dev] Burn the Squeak Image! (Why I am running for board)
 
|
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/ |
Re: [squeak-dev] Burn the Squeak Image! (Why I am running for board)
|
|
> 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/ |
[squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)
|
|
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 |
Re: [squeak-dev] Burn the Squeak Image! (Why I am running for board)
|
|
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:
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. 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
|
[squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)
|
|
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 |
Re: [squeak-dev] Burn the Squeak Image! (Why I am running for board)
|
|
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/ > > > |
Re: [squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)
|
|
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: 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.
|
Re: [squeak-dev] Burn the Squeak Image! (Why I am running for board)
|
|
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. |
Re: [squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)
|
|
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 >> >> > > > > > |
[squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)
|
|
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 >>> >> > |
Re: [squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)
|
|
On Sat, Feb 28, 2009 at 8:19 AM, Klaus D. Witzel <[hidden email]> wrote:
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 |
[squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)
|
|
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 |
[squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)
|
|
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 |
Re: [squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)
|
|
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. 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 |
Re: [squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)
|
|
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/ |
Re: [squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)
|
|
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/ |
Re: [squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)
|
|
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 > 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. |
[squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)
|
|
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 |
|
|
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 |
Re: [squeak-dev] Re: Burn the Squeak Image! (Why I am running for board)
|
|
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 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: 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 |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |