[Pharo-project] Stroke of genius
Hi, First I want to re-iterate that I too am really happy with Pharo 2.0 - a lot of stability and polish was gained in the last push. Thanks everybody ! Second, I must say, after using the command line config handler for some time now, that the little fact that it is incremental - it updates and saves the same image based on 1 metacello configuration - is really a stroke of genius. It saves an enormous amount of time as in the past I always did a complete build from scratch. Updating servers is now really a joy. Thanks Camillo ! Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
Sven Van Caekenberghe-2 wrote
the little fact that it is incremental - it updates and saves the same image based on 1 metacello configuration - is really a stroke of genius. It saves an enormous amount of time as in the past I always did a complete build from scratch. Updating servers is now really a joy.
Sounds great! And, I don't exactly understand ;) Can you say more about that feature? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Stroke-of-genius-tp4681471p4681537.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 15 Apr 2013, at 15:07, "Sean P. DeNigris" <sean@clipperadams.com> wrote:
Sven Van Caekenberghe-2 wrote
the little fact that it is incremental - it updates and saves the same image based on 1 metacello configuration - is really a stroke of genius. It saves an enormous amount of time as in the past I always did a complete build from scratch. Updating servers is now really a joy.
Sounds great! And, I don't exactly understand ;) Can you say more about that feature?
Building a new image goes like this $ ./vm.sh Pharo.image save test $ ./vm.sh test.image config http://mc.stfx.eu/XXX ConfigurationOfBetaNineT3 --install=bleedingEdge --username=XXX --password=XXX The Pharo.image is 'empty' as far as your own code is concerned, the config loads lots of dependencies. A build takes 10 minutes or so. But the next time, you can do only the second part $ ./vm.sh test.image config http://mc.stfx.eu/XXX ConfigurationOfBetaNineT3 --install=bleedingEdge --username=XXX --password=XXX The test.image contains all your project specific code, and loading the config just checks all dependencies and only loads what has changed, incrementally. It only takes some 10s of seconds. It never occurred to me that this was the way to go, but the config handler does it by default. Maybe it is just me, but I had the impression that everybody (including CIs) always built from scratch (more or less, there were staged systems), while it is actually quite practical to keep on updating the same image for a much faster turn around. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On 2013-04-15, at 15:46, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 15 Apr 2013, at 15:07, "Sean P. DeNigris" <sean@clipperadams.com> wrote:
Sven Van Caekenberghe-2 wrote
the little fact that it is incremental - it updates and saves the same image based on 1 metacello configuration - is really a stroke of genius. It saves an enormous amount of time as in the past I always did a complete build from scratch. Updating servers is now really a joy.
Sounds great! And, I don't exactly understand ;) Can you say more about that feature?
Building a new image goes like this
$ ./vm.sh Pharo.image save test
$ ./vm.sh test.image config http://mc.stfx.eu/XXX ConfigurationOfBetaNineT3 --install=bleedingEdge --username=XXX --password=XXX
The Pharo.image is 'empty' as far as your own code is concerned, the config loads lots of dependencies. A build takes 10 minutes or so.
But the next time, you can do only the second part
$ ./vm.sh test.image config http://mc.stfx.eu/XXX ConfigurationOfBetaNineT3 --install=bleedingEdge --username=XXX --password=XXX
The test.image contains all your project specific code, and loading the config just checks all dependencies and only loads what has changed, incrementally. It only takes some 10s of seconds.
It never occurred to me that this was the way to go, but the config handler does it by default. Maybe it is just me, but I had the impression that everybody (including CIs) always built from scratch (more or less, there were staged systems), while it is actually quite practical to keep on updating the same image for a much faster turn around.
;)
Sven Van Caekenberghe-2 wrote
The test.image contains all your project specific code, and loading the config just checks all dependencies and only loads what has changed, incrementally. It only takes some 10s of seconds.
It never occurred to me that this was the way to go, but the config handler does it by default. Maybe it is just me, but I had the impression that everybody (including CIs) always built from scratch (more or less, there were staged systems), while it is actually quite practical to keep on updating the same image for a much faster turn around.
Ah, I see. The speed is very nice, but what about e.g. class-side initialization? i.e. if a class>>initialize has changed, the update will not be run, no. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Stroke-of-genius-tp4681471p4681578.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 15 Apr 2013, at 15:54, "Sean P. DeNigris" <sean@clipperadams.com> wrote:
Sven Van Caekenberghe-2 wrote
The test.image contains all your project specific code, and loading the config just checks all dependencies and only loads what has changed, incrementally. It only takes some 10s of seconds.
It never occurred to me that this was the way to go, but the config handler does it by default. Maybe it is just me, but I had the impression that everybody (including CIs) always built from scratch (more or less, there were staged systems), while it is actually quite practical to keep on updating the same image for a much faster turn around.
Ah, I see. The speed is very nice, but what about e.g. class-side initialization? i.e. if a class>>initialize has changed, the update will not be run, no.
Yes it will, if you change the source code of the #initialize that you want to force run, else you have to add post load actions to the metacello configs, or call some initializers manually from you startup scripts. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
Am 15.04.2013 um 15:46 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 15 Apr 2013, at 15:07, "Sean P. DeNigris" <sean@clipperadams.com> wrote:
Sven Van Caekenberghe-2 wrote
the little fact that it is incremental - it updates and saves the same image based on 1 metacello configuration - is really a stroke of genius. It saves an enormous amount of time as in the past I always did a complete build from scratch. Updating servers is now really a joy.
Sounds great! And, I don't exactly understand ;) Can you say more about that feature?
Building a new image goes like this
$ ./vm.sh Pharo.image save test
$ ./vm.sh test.image config http://mc.stfx.eu/XXX ConfigurationOfBetaNineT3 --install=bleedingEdge --username=XXX --password=XXX
The Pharo.image is 'empty' as far as your own code is concerned, the config loads lots of dependencies. A build takes 10 minutes or so.
But the next time, you can do only the second part
$ ./vm.sh test.image config http://mc.stfx.eu/XXX ConfigurationOfBetaNineT3 --install=bleedingEdge --username=XXX --password=XXX
The test.image contains all your project specific code, and loading the config just checks all dependencies and only loads what has changed, incrementally. It only takes some 10s of seconds.
It never occurred to me that this was the way to go, but the config handler does it by default. Maybe it is just me, but I had the impression that everybody (including CIs) always built from scratch (more or less, there were staged systems), while it is actually quite practical to keep on updating the same image for a much faster turn around.
This is less reliable than building from scratch. If you only build your own packages without a lot of external packages that might go well. If there are external dependencies it can even be that not loading it from scratch will get you a different package set installed in your image afterwards. So you should build from scratch from time to time anyway. For the config handler I don't see a reason why a config option should overwrite the existing image by default. Without extra options I don't even see why the image should shutdown after loading the config. Is it how it is? That looks like there are too many assumptions taken from the commandline handlers. Norbert
On 15 April 2013 15:58, Norbert Hartl <norbert@hartl.name> wrote:
Am 15.04.2013 um 15:46 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 15 Apr 2013, at 15:07, "Sean P. DeNigris" <sean@clipperadams.com> wrote:
Sven Van Caekenberghe-2 wrote
the little fact that it is incremental - it updates and saves the same image based on 1 metacello configuration - is really a stroke of genius. It saves an enormous amount of time as in the past I always did a complete build from scratch. Updating servers is now really a joy.
Sounds great! And, I don't exactly understand ;) Can you say more about that feature?
Building a new image goes like this
$ ./vm.sh Pharo.image save test
$ ./vm.sh test.image config http://mc.stfx.eu/XXX ConfigurationOfBetaNineT3 --install=bleedingEdge --username=XXX --password=XXX
The Pharo.image is 'empty' as far as your own code is concerned, the config loads lots of dependencies. A build takes 10 minutes or so.
But the next time, you can do only the second part
$ ./vm.sh test.image config http://mc.stfx.eu/XXX ConfigurationOfBetaNineT3 --install=bleedingEdge --username=XXX --password=XXX
The test.image contains all your project specific code, and loading the config just checks all dependencies and only loads what has changed, incrementally. It only takes some 10s of seconds.
It never occurred to me that this was the way to go, but the config handler does it by default. Maybe it is just me, but I had the impression that everybody (including CIs) always built from scratch (more or less, there were staged systems), while it is actually quite practical to keep on updating the same image for a much faster turn around.
This is less reliable than building from scratch. If you only build your own packages without a lot of external packages that might go well. If there are external dependencies it can even be that not loading it from scratch will get you a different package set installed in your image afterwards. So you should build from scratch from time to time anyway.
For the config handler I don't see a reason why a config option should overwrite the existing image by default. Without extra options I don't even see why the image should shutdown after loading the config. Is it how it is? That looks like there are too many assumptions taken from the commandline handlers.
Well, as i understand , Camillo took most often used practice and implemented it in code to make repeatable tasks less tedious and straightforward. Nevertheless, i think you raising valid questions.
Norbert
-- Best regards, Igor Stasenko.
On 15 Apr 2013, at 15:58, Norbert Hartl <norbert@hartl.name> wrote:
Am 15.04.2013 um 15:46 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 15 Apr 2013, at 15:07, "Sean P. DeNigris" <sean@clipperadams.com> wrote:
Sven Van Caekenberghe-2 wrote
the little fact that it is incremental - it updates and saves the same image based on 1 metacello configuration - is really a stroke of genius. It saves an enormous amount of time as in the past I always did a complete build from scratch. Updating servers is now really a joy.
Sounds great! And, I don't exactly understand ;) Can you say more about that feature?
Building a new image goes like this
$ ./vm.sh Pharo.image save test
$ ./vm.sh test.image config http://mc.stfx.eu/XXX ConfigurationOfBetaNineT3 --install=bleedingEdge --username=XXX --password=XXX
The Pharo.image is 'empty' as far as your own code is concerned, the config loads lots of dependencies. A build takes 10 minutes or so.
But the next time, you can do only the second part
$ ./vm.sh test.image config http://mc.stfx.eu/XXX ConfigurationOfBetaNineT3 --install=bleedingEdge --username=XXX --password=XXX
The test.image contains all your project specific code, and loading the config just checks all dependencies and only loads what has changed, incrementally. It only takes some 10s of seconds.
It never occurred to me that this was the way to go, but the config handler does it by default. Maybe it is just me, but I had the impression that everybody (including CIs) always built from scratch (more or less, there were staged systems), while it is actually quite practical to keep on updating the same image for a much faster turn around.
This is less reliable than building from scratch. If you only build your own packages without a lot of external packages that might go well. If there are external dependencies it can even be that not loading it from scratch will get you a different package set installed in your image afterwards. So you should build from scratch from time to time anyway.
For the config handler I don't see a reason why a config option should overwrite the existing image by default. Without extra options I don't even see why the image should shutdown after loading the config. Is it how it is? That looks like there are too many assumptions taken from the commandline handlers.
Norbert
Yes, of course, sometimes, especially when you suspect strange loading problems, it is a good idea to start from scratch. But in general that is not needed, IMHO. Hence the default is good. Using the 'save' command handler you can easily and quickly mimic the other behaviour. Note also that normally, the external dependencies will change much more slowly than your own code. Sven
participants (5)
-
Camillo Bruni -
Igor Stasenko -
Norbert Hartl -
Sean P. DeNigris -
Sven Van Caekenberghe