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
