On 2 March 2012 13:34, Camillo Bruni <camillobruni@gmail.com> 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-f... 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"