April 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Stroke of genius

by Sven Van Caekenberghe

On 15 Apr 2013, at 15:54, "Sean P. DeNigris" <sean(a)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

April 15, 2013

Re: [Pharo-project] SelectPackageBrowser

by stephane ducasse

Indeed Merlin would be useful. I cleaned it a bit when migrating to smalltalkhub. Stef > I want to extract SelectPackageBrowser as a general PackagePicker widget. > It's part of the CriticsBrowser setup wizard, in which there is no wizard > object, but rather each page deletes itself and opens the next one in the > world. Could Merlin be helpful here? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/SelectPackageBrowser-tp4681590.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

April 15, 2013

Re: [Pharo-project] Monitor is DOWN: get.pharo.org (http://get.pharo.org)

by Marcus Denker

On Apr 15, 2013, at 4:01 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > > Begin forwarded message: > >> From: "Uptime Robot" <alert(a)uptimerobot.com> >> Subject: Monitor is DOWN: get.pharo.org (http://get.pharo.org) >> Date: 15. April 2013 16:00:23 MESZ >> To: camillobruni(a)gmail.com >> >> Hi, >> >> The monitor get.pharo.org (http://get.pharo.org) is currently DOWN (Connection Timeout). >> Yes, my watchdog said the sameâ¦ we need to get rid of the forward.

April 15, 2013

Re: [Pharo-project] Stroke of genius

by Igor Stasenko

On 15 April 2013 15:58, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 15.04.2013 um 15:46 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> >> On 15 Apr 2013, at 15:07, "Sean P. DeNigris" <sean(a)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.

April 15, 2013

[Pharo-project] Fwd: Monitor is DOWN: get.pharo.org (http://get.pharo.org)

by Camillo Bruni

Begin forwarded message: > From: "Uptime Robot" <alert(a)uptimerobot.com> > Subject: Monitor is DOWN: get.pharo.org (http://get.pharo.org) > Date: 15. April 2013 16:00:23 MESZ > To: camillobruni(a)gmail.com > > Hi, > > The monitor get.pharo.org (http://get.pharo.org) is currently DOWN (Connection Timeout). > > Uptime Robot will alert you when it is back up. > > > Cheers, > > Uptime Robot > http://www.uptimerobot.com > http://twitter.com/uptimerobot > (sent from new engine) >

April 15, 2013

[Pharo-project] SelectPackageBrowser

by Sean P. DeNigris

I want to extract SelectPackageBrowser as a general PackagePicker widget. It's part of the CriticsBrowser setup wizard, in which there is no wizard object, but rather each page deletes itself and opens the next one in the world. Could Merlin be helpful here? ----- Cheers, Sean -- View this message in context: http://forum.world.st/SelectPackageBrowser-tp4681590.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 15, 2013

Re: [Pharo-project] Stroke of genius

by Norbert Hartl

Am 15.04.2013 um 15:46 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 15 Apr 2013, at 15:07, "Sean P. DeNigris" <sean(a)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

April 15, 2013

Re: [Pharo-project] WhatsUp from: 2013-04-15 until: 2013-04-30

by Frank Shearar

On 15 April 2013 14:44, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 15/04/2013 15:30, stephane ducasse a Ã©crit : > >>>> >>> >>> Porting SmaCC on 2.0 >> >> nice. If you need an integration server. >> >>> Writing configurations for AltBrowser and Jejak. >> >> nice too >> >>> Started looking at Marpa >> >> what is it? > > > A nice, more general way of parsing Context Free Grammars with a better > algorithm not restricted to LR(k) grammars (see > http://jeffreykegler.github.io/Marpa-web-site/) > > I'd really like to make it a pure Smalltalk parser, to be able to study the > underlying algorithm. And SmaCC already has some infrastructure to handle > that, like a grammar parser (as well as the Scanner infrastructure). > > The promise of parsing with any CFG grammar (and all LR(k) grammars in > linear time) is convincing. There are several algorithms that can do this (handling all CFGs, including ambiguous grammars): Marpa uses a derivative of the Earley parser, and there's GLL [1] and parsing with derivatives [2][3]. frank [1] https://github.com/djspiewak/gll-combinators [2] http://matt.might.net/articles/parsing-with-derivatives/ [3] http://ss3.gemstone.com/ss/ParsingDerivatives.html (still a while to go before it's production ready!) frank > Thierry > > >>> Started the switch to 2.0 as professional platform. >> >> >> good. >>> >>> >>>> ### What's next, until 2013-04-30 (*): >>> >>> >>> Study and understand Marpa as an alternative to porting SmaCC-GLR to >>> Pharo. >>> Improve AltBrowser functionality as my only browser under Pharo 2.0. >>> >>> Thierry >>> -- >>> Thierry Goubier >>> CEA list >>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>> 91191 Gif sur Yvette Cedex >>> France >>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>> >> >> >> >> > > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

April 15, 2013

Re: [Pharo-project] Stroke of genius

by Sean P. DeNigris

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.

April 15, 2013

Re: [Pharo-project] Stroke of genius

by Camillo Bruni

On 2013-04-15, at 15:46, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 15 Apr 2013, at 15:07, "Sean P. DeNigris" <sean(a)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. ;)

April 15, 2013