[Pharo-project] Building vs. Stone carving (was: some explanations about what we are doing :)
Stef/Mariano wrote:
So now we are including several packages in the image so that we do not have two images.
I am not against this, but I think it is a must to provide a #shrinkToPharoCore and a hudson associated to that.
yes good idea
Interesting (nearly silent) switch in the way we build Pharo(core). With one "Core" and several distro packages like "pharo-dev", "seaside" we once switched to the model anyone is used to in other technology sectors: building a house or a machine by stacking up/assembling small pieces. So we had a "start with a base/core and load what you need" model similar to Linux kernel and distros. So you could pick up what you need. I thought this is the right model - since we can cleanly load and keep images small while checking if something is running after loading with CI/Hudson. But now we extract the kernel/core from the (bloated?) distro. For whatever reason I often see this tradition of "Stone carving" in Smalltalk. One has a large image and strips it down for deployment (throw out what you do not need). Often you get problems in unloading/ clean loading again. Classes are referenced across the image without checking the load order, ... Mmmmhhh ... who shares the same feeling that this is not a good idea! When there is a #shrinkToPharoCore then there is a pharo core image anyway - so we always have two images. And we have to test it and check if packages load cleanly anyway (using CI). Can you at least ellaborate what led to this step? Is PharoKernel the new Pharo Core? Will we test reloading after shrinking? ... Thx T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
The root of the problem, that we don't have enough resources to maintain two different images: core and dev. So we decided to keep only one release artifact since 1.4. It will be bigger than existing Pharo-Core, but i think smaller than older Pharo-Dev images. It is all about optimizing our workload, and to make sure that things we're releasing is working and well tested. Because in 1.2-1.3 we have issues with this separation (i think you aware of that). Concerning building vs carving: i agree, we should build rather than carving :) But testing that parts of image could be unloaded/thrown away is also useful. On 16 August 2011 20:21, Torsten Bergmann <astares@gmx.de> wrote:
Stef/Mariano wrote:
So now we are including several packages in the image so that we do not have two images.
I am not against this, but I think it is a must to provide a #shrinkToPharoCore and a hudson associated to that.
yes good idea
Interesting (nearly silent) switch in the way we build Pharo(core).
With one "Core" and several distro packages like "pharo-dev", "seaside" we once switched to the model anyone is used to in other technology sectors: building a house or a machine by stacking up/assembling small pieces. So we had a "start with a base/core and load what you need" model similar to Linux kernel and distros. So you could pick up what you need.
I thought this is the right model - since we can cleanly load and keep images small while checking if something is running after loading with CI/Hudson.
But now we extract the kernel/core from the (bloated?) distro.
For whatever reason I often see this tradition of "Stone carving" in Smalltalk. One has a large image and strips it down for deployment (throw out what you do not need). Often you get problems in unloading/ clean loading again. Classes are referenced across the image without checking the load order, ...
Mmmmhhh ... who shares the same feeling that this is not a good idea! When there is a #shrinkToPharoCore then there is a pharo core image anyway - so we always have two images. And we have to test it and check if packages load cleanly anyway (using CI).
Can you at least ellaborate what led to this step? Is PharoKernel the new Pharo Core? Will we test reloading after shrinking? ...
Thx T.
-- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
-- Best regards, Igor Stasenko AKA sig.
I agree with what igor said. Now give us or join to build one of these items - a fast way to load package (fuel but there is still some work) - a spec for managing packages (metacello) - a set of tests (we have some but we need more) - a bootstrap (with have a mini image so this could be ok). and we will build and not carve and we will maintain a full set of packages. So we are getting there but this is not good to not test/use all day long what we release. So this will be like that for a moment but our goal is what I mention above: rebuilding from scratch all the pieces all the time and fast and we will get there. Stef On Aug 16, 2011, at 8:21 PM, Torsten Bergmann wrote:
Stef/Mariano wrote:
So now we are including several packages in the image so that we do not have two images.
I am not against this, but I think it is a must to provide a #shrinkToPharoCore and a hudson associated to that.
yes good idea
Interesting (nearly silent) switch in the way we build Pharo(core).
With one "Core" and several distro packages like "pharo-dev", "seaside" we once switched to the model anyone is used to in other technology sectors: building a house or a machine by stacking up/assembling small pieces. So we had a "start with a base/core and load what you need" model similar to Linux kernel and distros. So you could pick up what you need.
I thought this is the right model - since we can cleanly load and keep images small while checking if something is running after loading with CI/Hudson.
But now we extract the kernel/core from the (bloated?) distro.
For whatever reason I often see this tradition of "Stone carving" in Smalltalk. One has a large image and strips it down for deployment (throw out what you do not need). Often you get problems in unloading/ clean loading again. Classes are referenced across the image without checking the load order, ...
Mmmmhhh ... who shares the same feeling that this is not a good idea! When there is a #shrinkToPharoCore then there is a pharo core image anyway - so we always have two images. And we have to test it and check if packages load cleanly anyway (using CI).
Can you at least ellaborate what led to this step? Is PharoKernel the new Pharo Core? Will we test reloading after shrinking? ...
Thx T.
-- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
participants (3)
-
Igor Stasenko -
Stéphane Ducasse -
Torsten Bergmann