Squeak Roadmap ...

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

Squeak Roadmap ...

Geert Claes
Administrator
What does the roadmap look like for the Squeak core image (the one downloaded from www.squeak.org)?

I reckon the recent Squeak (Squeak by Example) and Seaside (the paper) documentation efforts are great! As are Garry's UI Enhancements (maybe a tutorial on how to make such UI Enhancement will encourage others to improve the Squeak look and feel?)

What I would like to see in Squeak's roadmap is an effort to clean-up the core image (remove eToys ect ... maybe even leverage on what Pavel has been doing?) and improve the default Squeak look and feel.

The "Squeak by Example" book depicts Squeak as "a modern implementation of the Smalltalk programming language and environment" and it would be great if it looked like one too :)

Reply | Threaded
Open this post in threaded view
|

Re: Squeak Roadmap ...

Brad Fuller-2
On Wed September 19 2007, GeertC wrote:

> What does the roadmap look like for the Squeak core image (the one
> downloaded from www.squeak.org)?
>
> I reckon the recent Squeak (Squeak by Example) and Seaside (the paper)
> documentation efforts are great! As are Garry's UI Enhancements (maybe a
> tutorial on how to make such UI Enhancement will encourage others to
> improve the Squeak look and feel?)
>
> What I would like to see in Squeak's roadmap is an effort to clean-up the
> core image (remove eToys ect ... maybe even leverage on what Pavel has been
> doing?) and improve the default Squeak look and feel.
>
> The "Squeak by Example" book depicts Squeak as "a modern implementation of
> the Smalltalk programming language and environment" and it would be great
> if it looked like one too :)

Join our UI efforts in the UI mailing list!

brad

Reply | Threaded
Open this post in threaded view
|

Re: Squeak Roadmap ...

Geert Claes
Administrator

Brad Fuller-2 wrote
Join our UI efforts in the UI mailing list!

brad
How come the "comp.lang.smalltalk.squeak.ui" is not on Nabble?
Reply | Threaded
Open this post in threaded view
|

Re: Squeak Roadmap ...

Brad Fuller-2
On Wed September 19 2007, GeertC wrote:
> Brad Fuller-2 wrote:
> > Join our UI efforts in the UI mailing list!
> >
> > brad
>
> How come the "comp.lang.smalltalk.squeak.ui" is not on Nabble?

i dunno. don't know how to do it. It's on gmane.

Reply | Threaded
Open this post in threaded view
|

Re: Squeak Roadmap ...

Geert Claes
Administrator
In reply to this post by Brad Fuller-2

Brad Fuller-2 wrote
On Wed September 19 2007, GeertC wrote:
> What does the roadmap look like for the Squeak core image (the one
> downloaded from www.squeak.org)?
>
> What I would like to see in Squeak's roadmap is an effort to clean-up the
> core image (remove eToys ect ... maybe even leverage on what Pavel has been
> doing?) and improve the default Squeak look and feel.

Join our UI efforts in the UI mailing list!

brad
How about plans to clean-up of the image (eToys etc ...)?
Reply | Threaded
Open this post in threaded view
|

Re: Squeak Roadmap ...

Edgar J. De Cleene
In reply to this post by Geert Claes



El 9/19/07 7:05 PM, "GeertC" <[hidden email]> escribió:

> What I would like to see in Squeak's roadmap is an effort to clean-up the
> core image (remove eToys ect ... maybe even leverage on what Pavel has been
> doing?) and improve the default Squeak look and feel.


We need Board decision.
I have experimental Etoys and Nebraska reload/load and some more candidates
to go away.
Before Ralph and me start 3.10, I collaborate with Pavel.
I wish soon we go MinimalMorphic.
The difference between roads is me wish remove "from top", modularize more
Morphic from 1.3 mb actual .mcz (I do in Ladrillos, but no agree with my
view).
I produce a "MorphicAgreement" image , but again no agree.
The problem is SystemNavigation default allUnimplementedCalls size is 182 in
3.10 (and in all from 3.7 and newer is close to this)
And without redoing the sources , raise to almost 600.

Edgar



Reply | Threaded
Open this post in threaded view
|

Re: Squeak Roadmap ...

Geert Claes
Administrator
Edgar J. De Cleene wrote
We need Board decision.
I have experimental Etoys and Nebraska reload/load and some more candidates to go away.
Before Ralph and me start 3.10, I collaborate with Pavel.  I wish soon we go MinimalMorphic.

The difference between roads is me wish remove "from top", modularize more Morphic from 1.3 mb actual .mcz (I do in Ladrillos, but no agree with my view).
I produce a "MorphicAgreement" image , but again no agree.  The problem is SystemNavigation default allUnimplementedCalls size is 182 in 3.10 (and in all from 3.7 and newer is close to this) And without redoing the sources , raise to almost 600.

Edgar
Hi Edgar,

I don't fully understand what you were talking about but I assume its more a decision on the technical approach to clean-up Squeak rather than whether it should be done or not?

How do we get a consensus on how to move forward on cleaning-up the standard image?  Where does this need to be raised?

How does the clean-up of the core image affect the Squeal UI initiative?

Geert
Reply | Threaded
Open this post in threaded view
|

Re: Squeak Roadmap ...

Edgar J. De Cleene



El 9/19/07 8:36 PM, "GeertC" <[hidden email]> escribió:

> I don't fully understand what you were talking about but I assume its more a
> decision on the technical approach to clean-up Squeak rather than whether it
> should be done or not?

It's not only technical, is political too.
Many people don't like Etoys go out.
As more visible thing inside Squeak is Etoys

> How do we get a consensus on how to move forward on cleaning-up the standard
> image?  Where does this need to be raised

This issue was discussed here and into the specialized list as the old
Morphic team and now into the 3.10 release team list.

> How does the clean-up of the core image affect the Squeal UI initiative?

I hope no effect if Pavel, Juan, me and others messing with smaller images
do well our job :=)

But people on the UI list should be aware of changes in Morphic.
As Morphic is more that you see...

Edgar



Reply | Threaded
Open this post in threaded view
|

Re: Squeak Roadmap ...

Geert Claes
Administrator
Edgar J. De Cleene wrote
> It's not only technical, is political too.
> Many people don't like Etoys go out.
> As more visible thing inside Squeak is Etoys
I think everyone agrees that eToys should be an optional component and not part of the Squeak/Smalltalk core image, if this is not the case I would be really really surprised :)
Reply | Threaded
Open this post in threaded view
|

Re: Squeak Roadmap ...

Tapple Gao
On Thu, Sep 20, 2007 at 05:45:32AM -0700, GeertC wrote:

>
>
> Edgar J. De Cleene wrote:
> >
> >
> >> It's not only technical, is political too.
> >> Many people don't like Etoys go out.
> >> As more visible thing inside Squeak is Etoys
> >
> >
>
> I think everyone agrees that eToys should be an optional component and not
> part of the Squeak/Smalltalk core image, if this is not the case I would be
> really really surprised :)

Etoys wouldn't be the first thing I would want to take out of a
core image. That would be (in order):
- MVC
- Browsers
- sources and changes file support
- Etoys
- Compiler

A good core image would be Morphic and a package loader. Usable
and customizable. I wouldn't want to distribute anything more or
less to a non-technical user.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808

Reply | Threaded
Open this post in threaded view
|

Re: Squeak Roadmap ...

David Mitchell-10
Excellent distinction between what a developer wants for work and what
a customer wants (or what a developer wants to deploy).

On 9/20/07, Matthew Fulmer <[hidden email]> wrote:

> On Thu, Sep 20, 2007 at 05:45:32AM -0700, GeertC wrote:
> >
> >
> > Edgar J. De Cleene wrote:
> > >
> > >
> > >> It's not only technical, is political too.
> > >> Many people don't like Etoys go out.
> > >> As more visible thing inside Squeak is Etoys
> > >
> > >
> >
> > I think everyone agrees that eToys should be an optional component and not
> > part of the Squeak/Smalltalk core image, if this is not the case I would be
> > really really surprised :)
>
> Etoys wouldn't be the first thing I would want to take out of a
> core image. That would be (in order):
> - MVC
> - Browsers
> - sources and changes file support
> - Etoys
> - Compiler
>
> A good core image would be Morphic and a package loader. Usable
> and customizable. I wouldn't want to distribute anything more or
> less to a non-technical user.
>
> --
> Matthew Fulmer -- http://mtfulmer.wordpress.com/
> Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
>
>

cbc
Reply | Threaded
Open this post in threaded view
|

Re: Squeak Roadmap ...

cbc
In reply to this post by Geert Claes
On 9/19/07, GeertC <[hidden email]> wrote:

What does the roadmap look like for the Squeak core image (the one downloaded
from www.squeak.org)?
 
As far as I've been able to tell, the roadmap looks like:
* The current release team will continue to correct bugs in Squeak as reported until they have decided they are done, they are exhausted, they are told to stop, or someone comes up with a new plan for version 3.11 / 4.0.
*  The next step in the roadmap is based on someone coming up with what they want to do next, proposing it, and getting it accepted by the board.  (Ideally more than 1 group would come up with an idea they would be willing to undertake, and the board could chose between them).  They then start the next relase.
*  This continues until we as a community decide to do it some other way.
 
The Board (or at least members of the board) have stated that they weren't elected to decide where Squeak was going technically, but rather to handle other issues such as the legal formation of the community and other non-technical issues.  This doesn't have to be this way - and we can choose to make that change at the next election if we want too - and demand it during the election.  Or, someone could propose another structure for technical direction - maybe have the board appoint a 'temporary technical dictator' that holds the title until that person is removed from office by that (or a later) board.
 
If you like that roadmap that you proposed and you can find some like-minded individuals that would like to work on that for the next release AND you have the time and dedication to follow through on it, then a great next step would be to start aggitating for the next release cycle to be those goals.  Come up with a proposal (I think that mainly means specific goals, rough dates, and a team roster, maybe other stuff - I haven't actually read any of the previous ones) and forward it to the board and/or list for discussion.  If it is accepted, negotiate with the current release team about their completion date and when you are going to start.
 
At least, this is my interpretation of how these things are currently being handled.  I'd be happy to be corrected wherever necessary.
 
-Chris

 


Reply | Threaded
Open this post in threaded view
|

Re: Squeak Roadmap ...

stephane ducasse
for squeak 3.11 or 4.0 I would like to see implemented the roadmap I  
sent for 3.10.

Now it is also important to learn from the failure of VisualWorks new  
UI: they tried revolution and failed
ow they are following evolution: ie instead of continuing to write a  
brand new framework they are
improving the existing one: now my take for squeak would be
        - clean Morphic (remove borken code, class referencing subclasses,  
favor instance variable access over dictionary use)
        - make sure that a new framework like Morphic3 or xxx could be loaded
        - check out Sophie code that could be packaged and used for Squeak.

Stef

It was and now I would add be based on pavel mini image + more tests  
and repackaging at the package level.

Here are the main actions I would like to see happening:

        - be able to load Tweak

        - be able to load Sophie infrastructural elements (ressource  
location...)
        => even substitute current Squeak ones with sophie ones (Rome renderer)

        - curve/remove Etoy/projects (without having to reload them)

        - remove nebraska and others/ remove packages early in the process

        - new compile method format if available else klaus fix for source  
limits

        - may be newcompiler if ready

        - aggressive cleans in a lot of areas

        - look at Pavel overrides problems
        => ideally be able to use Pavel image as a basis for 10/4

        - Use tool builder (looking at the tool plus) and change the current  
tools
        (the ones that deserve migration)

        - more tests

        - may be using MC2 if ready

        - better integration of AST and refactoring support

So if you want to help there on a regular basis or on specific items  
please say it

Stef




> On 9/19/07, GeertC <[hidden email]> wrote:
> What does the roadmap look like for the Squeak core image (the one  
> downloaded
> from www.squeak.org)?
>
> As far as I've been able to tell, the roadmap looks like:
> * The current release team will continue to correct bugs in Squeak  
> as reported until they have decided they are done, they are  
> exhausted, they are told to stop, or someone comes up with a new  
> plan for version 3.11 / 4.0.
> *  The next step in the roadmap is based on someone coming up with  
> what they want to do next, proposing it, and getting it accepted by  
> the board.  (Ideally more than 1 group would come up with an idea  
> they would be willing to undertake, and the board could chose  
> between them).  They then start the next relase.
> *  This continues until we as a community decide to do it some  
> other way.
>
> The Board (or at least members of the board) have stated that they  
> weren't elected to decide where Squeak was going technically, but  
> rather to handle other issues such as the legal formation of the  
> community and other non-technical issues.  This doesn't have to be  
> this way - and we can choose to make that change at the next  
> election if we want too - and demand it during the election.  Or,  
> someone could propose another structure for technical direction -  
> maybe have the board appoint a 'temporary technical dictator' that  
> holds the title until that person is removed from office by that  
> (or a later) board.
>
> If you like that roadmap that you proposed and you can find some  
> like-minded individuals that would like to work on that for the  
> next release AND you have the time and dedication to follow through  
> on it, then a great next step would be to start aggitating for the  
> next release cycle to be those goals.  Come up with a proposal (I  
> think that mainly means specific goals, rough dates, and a team  
> roster, maybe other stuff - I haven't actually read any of the  
> previous ones) and forward it to the board and/or list for  
> discussion.  If it is accepted, negotiate with the current release  
> team about their completion date and when you are going to start.
>
> At least, this is my interpretation of how these things are  
> currently being handled.  I'd be happy to be corrected wherever  
> necessary.
>
> -Chris
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Squeak Roadmap ...

Geert Claes
Administrator
In reply to this post by Tapple Gao

Matthew Fulmer wrote
Etoys wouldn't be the first thing I would want to take out of a
core image. That would be (in order):
- MVC
- Browsers
- sources and changes file support
- Etoys
- Compiler

A good core image would be Morphic and a package loader. Usable and customizable. I wouldn't want to distribute anything more or less to a non-technical user.
Interesting, I like the idea of stripping down to the basics and letting the user decide which packages they wish to load in their image.

So what needs to be done to make it happen?
Reply | Threaded
Open this post in threaded view
|

Re: Squeak Roadmap ...

Geert Claes
Administrator
In reply to this post by cbc

Chris Cunningham wrote
As far as I've been able to tell, the roadmap looks like:
*  The next step in the roadmap is based on someone coming up with what they want to do next, proposing it, and getting it accepted by the board.  (Ideally more than 1 group would come up with an idea they would be willing to undertake, and the board could chose between them).  They then start the next release.
How or where does one start the discussion for a roadmap towards lets say Squeak 4 - the stripped down, lean and mean version of Squeak 3 :)

Chris Cunningham wrote
The Board (or at least members of the board) have stated that they weren't elected to decide where Squeak was going technically, but rather to handle other issues such as the legal formation of the  community and other non-technical issues.  This doesn't have to be this way - and we can choose
to make that change at the next election if we want too - and demand it during the election.  Or, someone could propose another structure for technical direction - maybe have the board appoint a 'temporary technical dictator' that holds the title until that person is removed from office by that (or a later) board.

If you like that roadmap that you proposed and you can find some like-minded individuals that would like to work on that for the next release AND you have the time and dedication to follow through on it, then a great next step would be to start aggitating for the next release cycle to be those goals.
Come up with a proposal (I think that mainly means specific goals, rough dates, and a team roster, maybe other stuff - I haven't actually read any of the previous ones) and forward it to the board and/or list for discussion.  If it is accepted, negotiate with the current release team about their completion date and when you are going to start.
What is the proposal form and/or protocol for the "board"? I don't consider myself skilled enough do make changes to the Squeak core image, but I do have a view and ideas to make Squeak's more user friendly and accessible - if that's what the Squeak community wants.
Reply | Threaded
Open this post in threaded view
|

Re: Squeak Roadmap ...

Michael van der Gulik-2
In reply to this post by Tapple Gao


On 9/21/07, Matthew Fulmer <[hidden email]> wrote:
On Thu, Sep 20, 2007 at 05:45:32AM -0700, GeertC wrote:

>
>
> Edgar J. De Cleene wrote:
> >
> >
> >> It's not only technical, is political too.
> >> Many people don't like Etoys go out.
> >> As more visible thing inside Squeak is Etoys
> >
> >
>
> I think everyone agrees that eToys should be an optional component and not
> part of the Squeak/Smalltalk core image, if this is not the case I would be
> really really surprised :)

Etoys wouldn't be the first thing I would want to take out of a
core image. That would be (in order):
- MVC
- Browsers
- sources and changes file support
- Etoys
- Compiler

A good core image would be Morphic and a package loader. Usable
and customizable. I wouldn't want to distribute anything more or
less to a non-technical user.


You'd leave Morphic in? o_O

How would you load packages without a compiler or sources/changes file support?

Michael




--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

Reply | Threaded
Open this post in threaded view
|

Re: Squeak Roadmap ...

Tapple Gao
On Fri, Sep 21, 2007 at 10:42:35AM +1200, Michael van der Gulik wrote:

>    On 9/21/07, Matthew Fulmer <[hidden email]> wrote:
>      Etoys wouldn't be the first thing I would want to take out of a
>      core image. That would be (in order):
>      - MVC
>      - Browsers
>      - sources and changes file support
>      - Etoys
>      - Compiler
>
>      A good core image would be Morphic and a package loader. Usable
>      and customizable. I wouldn't want to distribute anything more or
>      less to a non-technical user.
>
>    You'd leave Morphic in? o_O
>
>    How would you load packages without a compiler or sources/changes file
>    support?

You must have missed the subliminal reference to spoon I hid in
the message

Spoon doesn't need a compiler to load packages. After all,
CompiledMethods are just a series of bytecodes and a literal
list.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808

Reply | Threaded
Open this post in threaded view
|

Re: Squeak Roadmap ...

Edgar J. De Cleene
In reply to this post by Geert Claes



El 9/20/07 7:02 PM, "GeertC" <[hidden email]> escribió:

> How or where does one start the discussion for a roadmap towards lets say
> Squeak 4 - the stripped down, lean and mean version of Squeak 3 :)


In case you are new:

>From small to big size and power

Squeak what only do 3 + 4 and exit and several micro images ==> exists from
a long, long time by works of Alejandro Reimondo (Fenix system)

Squeak super mininimal system => exists from a long, long time by works of
Craig Latta

Squeak "kernel" system exists from a long time by works of Pavel Krivanek

SqueakLight , the more powerful and versatil and comes with a pack of beer
cans exists from a long time by works of me
I deny rumors of it running on iPhone...:=)

Squeak "MinimalMorphic" , the next step  we should do, exists from a long
time by works of Pavel Krivanek and some contributions of me.

Squeak 3.10 , the first image without some of packages of previous Squeak
(now load from Universes), with quality control process (few red test from
more of 2200)

And you could count Juan Vuletich Morphic 3.0.image as very valuable idea...

So , you could choose to who join forces.

Edgar




Reply | Threaded
Open this post in threaded view
|

Re: Squeak Roadmap ...

Andreas.Raab
Edgar J. De Cleene wrote:
> Squeak 3.10 , the first image without some of packages of previous Squeak
> (now load from Universes), with quality control process (few red test from
> more of 2200)

Which packages were removed in 3.10?

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Squeak Roadmap ...

Geert Claes
Administrator
In reply to this post by Edgar J. De Cleene
Edgar J. De Cleene wrote
Squeak what only do 3 + 4 and exit and several micro images ==> exists from
a long, long time by works of Alejandro Reimondo (Fenix system)

Squeak super mininimal system => exists from a long, long time by works of
Craig Latta

Squeak "kernel" system exists from a long time by works of Pavel Krivanek

SqueakLight , the more powerful and versatil and comes with a pack of beer
cans exists from a long time by works of me
I deny rumors of it running on iPhone...:=)

Squeak "MinimalMorphic" , the next step  we should do, exists from a long
time by works of Pavel Krivanek and some contributions of me.

And you could count Juan Vuletich Morphic 3.0.image as very valuable idea...

So , you could choose to who join forces.
Shouldn't one of these approaches be incorporated by Squeak itself rather than all these different spin-offs? It seems to me that Pavel has done a great job at stripping Squeak down to the kernel (which is probably all Squeak should be), now it only needs some good IDE options with Morphic being one of them ...

ps. where can I find Juan's image?
12