Excellent idea Dave!!! Stef On Jun 18, 2011, at 5:59 PM, Dave Mason wrote:

On 2011-Jun-18, at 9:07 , laurent laffont wrote:

...

+ a FFI that a stupid idiot like me can use

I'm working on it, aiming for a paper at IWST. I posted a request for opinion and help on this yesterday, but got little response (perhaps because it was part of another thread).

See: http://lists.gforge.inria.fr/pipermail/pharo-project/2011-June/050298.html

../Dave

On Sat, Jun 18, 2011 at 5:18 PM, Norbert Hartl <norbert@hartl.name> wrote:

Are they all of equal importance? To me it sounds really a lot. And it looks like 1.4 will last quite long until it will be released. What happened to the zinc integration btw.?

Zinc is already in 1.3. Laurent.

Norbert

Am 18.06.2011 um 14:59 schrieb Stéphane Ducasse <stephane.ducasse@inria.fr

...

:

...

Hi guys

here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image.

- load FileSystem -> so that we can start to integrate and improve the fileSystem API

- Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work

- Ring -> so that we can start to integrate it

- Fuel -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)).

- I want Opal in 1.4 too.

- continue to remove StringHolder hierarchy

- Morphic improvements

Comments are welcomed.

Stef

Hi, I think that the best idea is to have one image for the system developers and end-users (for example, I almost never used full Pharo so it lost one tester). On the other hand we should continue with the modularization to allow to generate headless kernel image, gopher image, basic morphic image etc. on the request with bootstrapping. To have smallest possible image is not the main goal of the effort around PharoKernel. The main goal is to have beauty modular system where all dependencies all described well and packages can be easily loaded and unloaded. The buildserver can generate all the set of images for special purposes so it will be more natural then now when we have two main images. -- Pavel 18.6.2011 v 22:29, Guillermo Polito <guillermopolito@gmail.com>:

Hi Stef!

do you mean integrating all them in the Core? Or maybe follow Markus' idea of having just one image? Maybe that's an important discussion to have too :). I can give a hand for the repository stuff. Should we replicate repositories + metacello configs in order to be able to freeze them, isn't it?

Guille

On Sat, Jun 18, 2011 at 9:59 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Hi guys

here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image.

- load FileSystem -> so that we can start to integrate and improve the fileSystem API

- Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work

- Ring -> so that we can start to integrate it

- Fuel -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)).

- I want Opal in 1.4 too.

- continue to remove StringHolder hierarchy

- Morphic improvements

Comments are welcomed.

Stef

this is why I want to have a distribution repository and one click load of what we want. Now in addition we need to have the powerful tools inside the system (core) because we should be able to use the best tools to manage the changes. Stef

...

Hi,

I think that the best idea is to have one image for the system developers and end-users (for example, I almost never used full Pharo so it lost one tester). On the other hand we should continue with the modularization to allow to generate headless kernel image, gopher image, basic morphic image etc. on the request with bootstrapping. To have smallest possible image is not the main goal of the effort around PharoKernel. The main goal is to have beauty modular system where all dependencies all described well and packages can be easily loaded and unloaded. The buildserver can generate all the set of images for special purposes so it will be more natural then now when we have two main images.

+1

Me too - I never use full Pharo. I build the image I want from Core. If there were a suitable special purpose image built as outlined above, then that image would be my new starting point. If not, then I guess I would have to start from whatever Core+Dev image results from the process, and then unload stuff (or, if it isn't too big, use it as is).

On Sun, Jun 19, 2011 at 7:27 AM, Pavel Krivanek <pavel.krivanek@gmail.com>wrote:

Hi,

I think that the best idea is to have one image for the system developers and end-users (for example, I almost never used full Pharo so it lost one tester). On the other hand we should continue with the modularization to allow to generate headless kernel image, gopher image, basic morphic image etc. on the request with bootstrapping. To have smallest possible image is not the main goal of the effort around PharoKernel. The main goal is to have beauty modular system where all dependencies all described well and packages can be easily loaded and unloaded. The buildserver can generate all the set of images for special purposes so it will be more natural then now when we have two main images.

+1

-- Pavel

18.6.2011 v 22:29, Guillermo Polito <guillermopolito@gmail.com>:

Hi Stef!

do you mean integrating all them in the Core? Or maybe follow Markus' idea of having just one image? Maybe that's an important discussion to have too :). I can give a hand for the repository stuff. Should we replicate repositories + metacello configs in order to be able to freeze them, isn't it?

Guille

On Sat, Jun 18, 2011 at 9:59 AM, Stéphane Ducasse <<stephane.ducasse@inria.fr> stephane.ducasse@inria.fr> wrote:

...

Hi guys

here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image.

- load FileSystem -> so that we can start to integrate and improve the fileSystem API

- Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work

- Ring -> so that we can start to integrate it

- Fuel -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)).

- I want Opal in 1.4 too.

- continue to remove StringHolder hierarchy

- Morphic improvements

Comments are welcomed.

Stef

-- Mariano http://marianopeck.wordpress.com

What if we try integrating MetacelloBrowser in that PharoCoreWithVitamins? That can solve our one-click-download problem! Dale, Alex, how's the state of MetacelloBrowser? I've just downloaded it in 1.3 and it works. I got ashamed by the amount of options in the menu, but I managed to find how to load a configuration and a version, jeje. Cheers, Guille On Sun, Jun 19, 2011 at 7:02 AM, Stéphane Ducasse <stephane.ducasse@inria.fr

wrote:

On Jun 19, 2011, at 7:27 AM, Pavel Krivanek wrote:

...

Hi,

I think that the best idea is to have one image for the system developers and end-users (for example, I almost never used full Pharo so it lost one tester). On the other hand we should continue with the modularization to allow to generate headless kernel image, gopher image, basic morphic image etc. on the request with bootstrapping. To have smallest possible image is not the main goal of the effort around PharoKernel. The main goal is to have beauty modular system where all dependencies all described well and packages can be easily loaded and unloaded. The buildserver can generate all the set of images for special purposes so it will be more natural then now when we have two main images.

Yes yes yes but :) we should have a set of tools that are working together and we should not be responsible of making sure that all the possible combination work. I would like to get a process (as I mentioned in the other mail) seed + MetacelloSpec + modification => seed' + MetacelloSpec'

and that we are able to build hudson that takes aSeed + a spec => run all the tests + run all the quality check

Right now we have seed + list of package + modification => seed' + list of package'

and we get in trouble when we modify seed parts that influence external package

so what we want is to have seed + metacello = the minimal tools that we need to be efficient modifying seed for me OB Engine Shout O/Ecompletion

Stef

...

-- Pavel

18.6.2011 v 22:29, Guillermo Polito <guillermopolito@gmail.com>:

...

Hi Stef!

do you mean integrating all them in the Core? Or maybe follow Markus'

idea of having just one image? Maybe that's an important discussion to have too :).

...

...

I can give a hand for the repository stuff. Should we replicate repositories + metacello configs in order to be able to freeze them, isn't it?

Guille

On Sat, Jun 18, 2011 at 9:59 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote: Hi guys

here is a kind of dump of roadmap for 1.4 first level is to make sure that we have only one single image.

- load FileSystem -> so that we can start to integrate and improve the fileSystem API

- Load shout, Ocompletion, RBEngine (not OB) so that we can change what should be changed for RPackage to work

- Ring -> so that we can start to integrate it

- Fuel -> so that we can deprecate SmartRefStream (there may be a problem with mcz (not sure)).

- I want Opal in 1.4 too.

- continue to remove StringHolder hierarchy

- Morphic improvements

Comments are welcomed.

Stef

There are two things that need to be done with MetacelloBrowser before it is really ready... 1) is to clean up the menu organization ... there is a purpose for each of the menu items, but some work needs to be done to reorganize the panes/operations/windows so that not so many menu items are needed ... 2) is that the configuration creation logic is not very intuitive ... a wizard of sorts needs to be put together for simplifying the creation of configurations ... At the moment there is an OB and Morphic implementation for the MetacelloBrowser, but you can't do wizards in OB, so the wizard needs to be done in Morphic and that means that there won't be an OB mapping ... GemStone/GemTools is based upon OB and I really need to have a MetacelloBrowser that works in GemStone ... My solution has been to create tODE. tODE is a javascript/web-browser based development environment that is implemented on top of Seaside and I am currently in the process of building the MetacelloBrowser functionality in tODE... The upshot is that I am not actively developing the morphic interface for MetacelloBrowser ... about 80% of the code is shared between the morphic variant and the tODE variant of the MetacelloBrowser ... ...There are three things that need to be done:)... 3) performance improvement... I will be tackling the performance issues as they are smack dab in the middle of the shared code, but someone with Morphic experience needs to tackle the usability and wizard issues... Dale ----- Original Message ----- | From: "Guillermo Polito" <guillermopolito@gmail.com> | To: Pharo-project@lists.gforge.inria.fr, metacello@googlegroups.com | Sent: Sunday, June 19, 2011 7:08:25 AM | Subject: Re: [Pharo-project] roadmap for 1.4 | | What if we try integrating MetacelloBrowser in that | PharoCoreWithVitamins? That can solve our one-click-download | problem! | | Dale, Alex, how's the state of MetacelloBrowser? I've just downloaded | it in 1.3 and it works. I got ashamed by the amount of options in | the menu, but I managed to find how to load a configuration and a | version, jeje. | | Cheers, | Guille | | | On Sun, Jun 19, 2011 at 7:02 AM, Stéphane Ducasse < | stephane.ducasse@inria.fr > wrote: | | | | | On Jun 19, 2011, at 7:27 AM, Pavel Krivanek wrote: | | > Hi, | > | > I think that the best idea is to have one image for the system | > developers and end-users (for example, I almost never used full | > Pharo so it lost one tester). On the other hand we should continue | > with the modularization to allow to generate headless kernel | > image, gopher image, basic morphic image etc. on the request with | > bootstrapping. To have smallest possible image is not the main | > goal of the effort around PharoKernel. The main goal is to have | > beauty modular system where all dependencies all described well | > and packages can be easily loaded and unloaded. The buildserver | > can generate all the set of images for special purposes so it will | > be more natural then now when we have two main images. | | Yes yes yes but :) we should have a set of tools that are working | together and we should not be responsible of making sure that all | the possible combination work. | I would like to get a process (as I mentioned in the other mail) | seed + MetacelloSpec + modification => seed' + MetacelloSpec' | | and that we are able to build hudson that takes | aSeed + a spec | => run all the tests + run all the quality check | | Right now we have | seed + list of package + modification => seed' + list of package' | | and we get in trouble when we modify seed parts that influence | external package | | so what we want is to have | seed + metacello = the minimal tools that we need to be efficient | modifying seed | for me | OB Engine | Shout | O/Ecompletion | | Stef | | | | | | > | > -- Pavel | > | > | > | > 18.6.2011 v 22:29, Guillermo Polito < guillermopolito@gmail.com >: | > | >> Hi Stef! | >> | >> do you mean integrating all them in the Core? Or maybe follow | >> Markus' idea of having just one image? Maybe that's an important | >> discussion to have too :). | >> I can give a hand for the repository stuff. Should we replicate | >> repositories + metacello configs in order to be able to freeze | >> them, isn't it? | >> | >> Guille | >> | >> On Sat, Jun 18, 2011 at 9:59 AM, Stéphane Ducasse < | >> stephane.ducasse@inria.fr > wrote: | >> Hi guys | >> | >> here is a kind of dump of roadmap for 1.4 first level is to make | >> sure that we have only one single image. | >> | >> - load FileSystem | >> -> so that we can start to integrate and improve the fileSystem | >> API | >> | >> - Load shout, Ocompletion, RBEngine (not OB) so that we can change | >> what should be changed for RPackage to work | >> | >> - Ring | >> -> so that we can start to integrate it | >> | >> - Fuel | >> -> so that we can deprecate SmartRefStream (there may be a problem | >> with mcz (not sure)). | >> | >> - I want Opal in 1.4 too. | >> | >> - continue to remove StringHolder hierarchy | >> | >> - Morphic improvements | >> | >> Comments are welcomed. | >> | >> Stef | >> | >> | >> | | | |