New source code subsystem

Hi Wolfgang,

I share your view on doIt's, simply because they survive fileOut's and  
fileIn's better and are kept in the context where they belong to.

What do you do with doIt's like "Smalltalk garbageCollect", e.g. those  
which are not related to project work?

/Klaus

On Fri, 28 Jul 2006 10:54:06 +0200, Wolfgang Eder <[hidden email]>  
wrote:

Pavel Krivanek puso en su mail :

> Unfortunately there's almost nobody who can maintain the next release.
> And if we will create the basic kernel imege, there will be no human
> resources to unify it as the base for the current Squeak forks.
>
> -- Pavel
I see your way is better.
Could elaborate about the above what you write ?

Edgar



       
       
               
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

On 7/28/06, Lic. Edgar J. De Cleene <[hidden email]> wrote:
> Pavel Krivanek puso en su mail :
>
> > Unfortunately there's almost nobody who can maintain the next release.
> > And if we will create the basic kernel imege, there will be no human
> > resources to unify it as the base for the current Squeak forks.
> >
> > -- Pavel
> I see your way is better.
> Could elaborate about the above what you write ?

Pardon, could who? I know, Spanish must not use articles :-)

-- Pavel

> Are there any plans to use your small image as the official base
> image?

Not for now. We will not take the responsibility for work we did not  
cary.
Now if Pavel wants he can
        - publish a small kernel that people can use
        - chunk his changes so that we can push them in 3.10

> Using a small base image then importing externally supported
> packages should make image maintenence much easier as there will be
> less code. Is this a good time to burn bridges to move forward to
> a more modular future?

after 3.9 :)

> Sure there's a risk that we might drop code, but code that isn't
> maintained will rot inside the image as well as outside. If people
> know that packages will be gone unless they do something, there is a
> chance that they will step forward knowing the stakes even though they
> might not have volunteered if the code was in the image rotting slowly
> through lack of attention.

I would go first in 3.10 for a first round of dropping code that  
needs to
be dropped: Etoy, MVC, morphic parts and more.

Then...
>
> Bryce
>

On 28 juil. 06, at 08:43, Pavel Krivanek wrote:

>> Are there any plans to use your small image as the official base
>> image? Using a small base image then importing externally supported
>> packages should make image maintenence much easier as there will be
>> less code. Is this a good time to burn bridges to move forward to
>> a more modular future?
>
> Good question. Version 3.9 is in the final stage and I think that
> Stef, Marcus, Cees, Craig, Bert, Tim and Yoshiki should set the plan
> for 3.10 - goals and priorities.

I'm not that this is the role of the foundation.

>
> Stef declared that he wants to burn bridges in this version.

At least I do not want to work on 3.10 for something that have such  
too much strings
attached. However this is really important to make sure that people  
can work with it.
So I would start to discarding a lot more of rotten code.

> We want to have Squeak free and modular and there are three possible
> starting points.  The free version One, Craig's Spoon and the image of
> mine.
>
> I wanted to show that my way is the right one. We have some GUI-less
> image with SUnit tests, we are able to run Seaside applications and we
> are able to load the rest of current Squeak sources and run Morphic.

Excellent start.

> Unfortunately there's almost nobody who can maintain the next release.

Exact!

> And if we will create the basic kernel imege, there will be no human
> resources to unify it as the base for the current Squeak forks.

This is why I always propose you that we join effort.
And that we push step by step part of what you did into the next  
version.

Pavel Krivanek puso en su mail :

Sorry my bad English.

>> Unfortunately there's almost nobody who can maintain the next release.
Why ? You don't work more on kernel.image ?

>> And if we will create the basic kernel image, there will be no human
>> resources to unify it as the base for the current Squeak forks.

Again why?.

You have a killer solution and people soon discover this is a good one to
follow and work.

You could lead a kernel.image team.

I sign for it if my Spanish don't bother you :=)

Edgar



       
       
               
__________________________________________________
Preguntá. Respondé. Descubrí.
Todo lo que querías saber, y lo que ni imaginabas,
está en Yahoo! Respuestas (Beta).
¡Probalo ya!
http://www.yahoo.com.ar/respuestas

On 28.07.2006, at 08:43, Pavel Krivanek wrote:

>> Are there any plans to use your small image as the official base
>> image? Using a small base image then importing externally supported
>> packages should make image maintenence much easier as there will be
>> less code. Is this a good time to burn bridges to move forward to
>> a more modular future?
>
> Good question. Version 3.9 is in the final stage and I think that

3.9 should be shipped ASAP. I don't want to wait for anything. That
what is 7048 can be considered to be 3.9

So 3.9 is in hard beta, which means that I don't think we should
wait for anything and especially not now start to do big changes.
We had over a year for big changes, and now that's over.
I personally plan to be not involved at all after 3.9 ships.

       Marcus
 
       

Klaus D. Witzel wrote:
> Hi Wolfgang,
>
> I share your view on doIt's, simply because they survive fileOut's and
> fileIn's better and are kept in the context where they belong to.
>
> What do you do with doIt's like "Smalltalk garbageCollect", e.g. those
> which are not related to project work?

i just checked: most methods (there are ca 240) relate to some
task (e.g. packaging, clearCaches, ...) or some project
(mp3playlists, ...)

of course, since it's regular methods, i sometimes to
some refactoring/cleanup.

one more thought on this topic:
you can use class and instance variables in your scripts;
(i use class vars for stuff i like to stick around, inst vars
i never needed). this is much less obscure that workspace
variables imho

cheers,
wolfgang

>
> /Klaus

> >> Unfortunately there's almost nobody who can maintain the next release.
> Why ? You don't work more on kernel.image ?

AFIK Marcus have no time for maintaining of the next Squeak version
and I don't expect that anybody will be able to substitute him. So we
have to modify current development model to make it more independent
on this bottleneck or Squeak will freeze up. Establishing of teams
helped a lot but it seems that it is still not enough.

IMHO we simply need to split Squeak in many small packages and use
very open development model (like Seaside) for every of them. If more
people will use the latest versions, the feedback will be much more
intensive. Then we need some kind of test server that will produce and
test daily builds.

Of course that I still want to work on the kernel image. But there are
some very important projects that I want to see and where I may be
more useful - for example fully web-based Smalltalk IDE - it's
possible to make it as usable as native IDE with current web
technologies and users will get flexible multi-user UI with standard
feel.

> >> And if we will create the basic kernel image, there will be no human
> >> resources to unify it as the base for the current Squeak forks.
>
> Again why?.
>
Look at the current state. We have the draft of the kernel. We have
few basic packages and a way how to load the rest of full Squeak
sources. I can imagine that we will be able to clean the kernel, I can
imagine that we will have good network and Seaside part. Maybe we will
be able to run development tools in Morphic but I don't expect that we
will be able to have Morphic and eToys as the regular clean packages.
There will be no human resources to do it.

If you look at the current package The Rest of Squeak, it's big ugly
package with many confused relationships because current Squeak looks
so. So maybe some other UI like wxSqueak will replace Morphic for
developers and it will be in the same possition like MVC today. In
future it may paradoxicaly cause beginning of the next Squeak fork
based on the old Squeak.
>
> You have a killer solution and people soon discover this is a good one to
> follow and work.
>
> You could lead a kernel.image team.
>
"If asked if he wants to be Prime Minister, the generally acceptable
answer for a politician is that while he does not seek the office, he
has pledged himself to the service of his country, and that should his
colleagues persuade him that that is the best way he can serve, he
might reluctantly have to accept the responsibility, whatever his
personal wishes might be." ;-)

I think that it's too big responsibility for one man, especially if
the man is me :-)
>
> I sign for it if my Spanish don't bother you :=)

Welcome on board :-)

-- Pavel