On 2 March 2012 13:34, 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.
To be fair, that's not MC's fault. A usability fault, perhaps. When you load a package you load from a repository. Your package-cache is but one such repository. Metacello will (Dale can correct me as necessary!) check your package-cache before downloading something, if it's configured correctly in some ConfigurationOfFoo. So I guess what I'm saying is that the tools _around_ MC might need adjusting, but otherwise MC's just doing what you tell it to do! I don't want to give the impression that I have it perfect, but if you look at http://www.squeaksource.com/MetacelloRepository/ConfigurationOfSqueakCheck-fbs.8.mcz you'll see in the #ensureMetacello how to make your configuration use the package-cache. (It's not just performance either: using the package-cache first lets you work offline, provided you have a properly populated package-cache. For me, working offline is crucial: a lot of my Smalltalk hacking happens on my train commute.) frank >> 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" >> > >
