Hi Doru, I will quote something I hear here, and that I strongly believe: "Pharo is not an unusable set of classes, is the tool we use everyday , so it need to have inside everything we need". But that's not complete, to illustrate I need to quote another phrase: "Also, Pharo should be modular and everybody should be able to start from a minimal image and build on top". So, short answer: Yes, Pharo will have all of that inside, because we need it to evolve Pharo itself, and build a better environment. But long answer: You also will be able to take a really small part of Pharo (let's say Pavel's kernel for 2.0 and maybe hazelnut bootstrap for 3.0) and use metacello to build your own image, the size you want and the packages you need :) To support that, I'm already working on a metacello configuration for Pharo (Idea is to replace current release process with one based on metacello). Of course this will take time , and our objectives for 2.0 are ambitious, but previous releases of Pharo had been created enough bases to allow such a great step. For more details on what we are trying to accomplish, I posted another mail trying to enumerate them: http://forum.world.st/About-the-new-release-process-td4574410.html Hope this works as an explanation. Esteban On Apr 25, 2012, at 7:49 PM, Tudor Girba wrote:

Hi,

I am a bit puzzled by the current trend of 2.0.

Are these additions part of the image, or will they be loaded continuously on top of a seed image?

If it's the former, I thought that we discussed a while ago to keep the image to a minimum, and, in particular, to not load RB in it. Or did anything change in the meantime?

Cheers, Doru

On 25 Apr 2012, at 19:25, Stéphane Ducasse wrote:

...

Esteban

are you sure that loading everything is the best move right now. I would have started one by one. Now this is ok too just more stress.

Stef

On Apr 25, 2012, at 5:31 PM, Esteban Lorenzano wrote:

...

20011 -----

introducing:

-RPackage -Spec -Keymapping -Refactoring Engine -AST -Nautilus

- Issue 5665: bug on new ecompletion/ocompletion http://code.google.com/p/pharo/issues/detail?id=5665

- Issue 5671: Polymorph fixes http://code.google.com/p/pharo/issues/detail?id=5671

-- www.tudorgirba.com

"Problem solving efficiency grows with the abstractness level of problem understanding."

Well... secure steps are overrated this days ;) Ok, being serious: we were introducing Nautilus, and Nautilus has all those requirements... it is maybe a bit too much, but since many of them does not overlap with existing base (AFAIK, just keymapping can cause some interaction problems, if it fails), I don't think is a big issue right now. And you know, this is really early 2.0, things are going to get worse before it starts to get better, but once we stabilize, it will be not better, just great :) Esteban On Apr 25, 2012, at 7:25 PM, Stéphane Ducasse wrote:

Esteban

are you sure that loading everything is the best move right now. I would have started one by one. Now this is ok too just more stress.

Stef

On Apr 25, 2012, at 5:31 PM, Esteban Lorenzano wrote:

...

20011 -----

introducing:

-RPackage -Spec -Keymapping -Refactoring Engine -AST -Nautilus

- Issue 5665: bug on new ecompletion/ocompletion http://code.google.com/p/pharo/issues/detail?id=5665

- Issue 5671: Polymorph fixes http://code.google.com/p/pharo/issues/detail?id=5671