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 :) |
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 |
Administrator
|
How come the "comp.lang.smalltalk.squeak.ui" is not on Nabble? |
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. |
Administrator
|
In reply to this post by Brad Fuller-2
How about plans to clean-up of the image (eToys etc ...)? |
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 |
Administrator
|
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 |
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 |
Administrator
|
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 :) |
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 |
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 > > |
In reply to this post by Geert Claes
On 9/19/07, GeertC <[hidden email]> wrote:
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 |
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 > > > |
Administrator
|
In reply to this post by Tapple Gao
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? |
Administrator
|
In reply to this post by cbc
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 :) 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. |
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: 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/ |
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 |
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 |
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 |
Administrator
|
In reply to this post by Edgar J. De Cleene
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? |
Free forum by Nabble | Edit this page |