Hi, On Fri, Mar 2, 2012 at 2:34 PM, Camillo Bruni <[email protected]> wrote: > > On 2012-03-02, at 10:06, Tudor Girba wrote: > >> Hi, >> >> I believe everyone agrees that one important goal in Pharo is to get >> to a small code/kernel/seed. During the Pharo Sprint at Bern we saw >> that the only reason for now having a unified image is just a >> temporary convenience that stems from two things: >> 1. Until Pharo 1.3, the core team worked in the core image, and this >> was frustrating because they were missing proper tools >> 2. After 1.3, building a pharo image out of a seed image was perceived >> as being too long and not fitting for the process of integration > > this mainly comes from the fact that MC is not particularly fast. > I was recently amazed how fast simple CS loading is compared to the same > with a SLICE. So I think that rebuilding a dev image from a core image > might even work locally given that MC can be made 10 to 100 times faster. > > I recently made updates on my machines some 10 times faster by actually > using the package-cache and not always reloading the versions from the > remote server! So MC has quite some room for performance improvements.
That is even better. But, even without, I think that the current image can be loaded quite fast if we work on it. So, how can I find/obtain a seed image? Cheers, Doru >> It's clear that the core team needs development tools. However, we >> think that 2 can be actually quite cheap if the build starts from the >> latest seed, and not from the original seed of 1.4 as it currently >> seem to happen. If this would be fast, we could go back to having one >> seed image (I call it seed just to avoid confusion and wrong feelings, >> but you can call it anyway you want) out of which the Pharo >> distribution (like the current image is) is built. The core team would >> work on this distribution, and Jenkins would do the rest. By switching >> the distribution build to work with the latest seed, we can probably >> reduce the amount of build time to a couple of minutes (at least this >> is what we saw during a couple of quick tests). >> >> Regarding the flow of the integrator, we saw that actually, when >> multiple changes need to be integrated, you can base the second change >> on the image that already exists locally, without needing to wait >> until Jenkins finishes. >> >> I would be interested in providing help. So, what do you say? >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"
