March 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] strange bevahiour between three dependent Metacello configurations

by Andrei Chis

Hi, We fixed this but we are not sure if the behaviour that we got was a result of a bug or a feature in Metacello. Again our setup is that we have three configurations with linear dependencies between them: -- ConfigurationOfGTInspectorCore (2.0-baseline) -- ConfigurationOfGlamourCore (3.1-baseline) -- ConfigurationOfRubric (0.2-baseline) In ConfigurationOfRubric we had version "1.2.8" that uses '0.2-baseline'. The development version is '0.2-baseline' and the stable version '1.2.8' [1] (ConfigurationOfGlamourCore project version: #development) record loadDirective [2] (ConfigurationOfGTInspectorCore project version: #development) record loadDirective. When performing [1] Metacello decides to load Rubric. This because "MetacelloNullRecordingMCSpecLoader" uses the operator "=" (since none was specified before) to figure out whether something should be loaded. At a certain point this is executed: compareCurrentVersion:targetVersionStatus:using: (from above) ... ... ... ... #allLoadedToSpec = #allLoadedToSpec ===> TRUE "1.2.8 [ConfigurationOfRubric]" = "<>0.2-baseline [ConfigurationOfRubric] (MetacelloMCVersion)" ===> FALSE ===> Rubric is not removed from the loader list When performing [2] Metacello decides not to load Rubric. In this case Metacello deals first with #ConfigurationOfGlamourCore. But after "GlamorCore" has been processed, the operator in the global mcLoader is set to ">=". All further specs-to-load (MetacelloNullRecordingMCSpecLoader) will be compared using "=>". So now rubric get's removed: compareCurrentVersion:targetVersionStatus:using: (from above) ... ... ... ... #allLoadedToSpec >= #allLoadedToSpec ===> TRUE "1.2.8 [ConfigurationOfRubric]" >= "<>0.2-baseline [ConfigurationOfRubric] (MetacelloMCVersion)" ===> TRUE ===> Rubric is removed from the loader list That's why "Rubric" doesn't show up in the final loader list. The second (inner/nested) spec-to-load will remove it (after it has been successfully resolved by the previous nested configuration ConfigurationOfGlamourCore) because of the operator. So there is a difference between #ConfigurationOfGlamourCore and #ConfigurationOfGTInspectorCore in how "Rubric" is resolved and loaded. Anybody else encountered this? Cheers, GT team On Tue, Mar 3, 2015 at 9:44 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Hi, > > We are having the following problem when trying to update GTolols to their > latest version in the latest Pharo 4 image: Rubric does not get updated. > We have: > > -- ConfigurationOfGTInspectorCore (2.0-baseline) > -- ConfigurationOfGlamourCore (3.1-baseline) > -- ConfigurationOfRubric (0.2-baseline) > > Performing [1] shows that rubric gets updated (atomic load : 0.2-baseline > [ConfigurationOfRubric]) > Performing [2] contains no trace of rubric. > > [1] (ConfigurationOfGlamourCore project version: #development) record > loadDirective > [2] (ConfigurationOfGTInspectorCore project version: #development) record > loadDirective. > > Loading then the inspector [3] does not update Rubric. > Loading just Glamour [4] updates it. > > [3] (ConfigurationOfGTInspectorCore project version: #development) load. > [4] (ConfigurationOfGlamourCore project version: #development) load > > Any ideas or sugestions? Maybe we are missing something trivial. > This updates the previous configurations to their latest versions: > > Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; > package: 'ConfigurationOfGTInspectorCore'; load. > Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; > package: 'ConfigurationOfGlamourCore'; load. > Gofer new smalltalkhubUser: 'AlainPlantec' project: 'Rubric'; > package: 'ConfigurationOfRubric'; load. > > > Cheers, > Andrei >

March 4, 2015

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

by Thierry Goubier

Le 04/03/2015 14:29, Marcus Denker a Ã©crit : > >> On 04 Mar 2015, at 14:19, phil(a)highoctane.be >> <mailto:phil@highoctane.be> wrote: >> >> On Wed, Mar 4, 2015 at 1:56 PM, Marcus Denker <marcus.denker(a)inria.fr >> <mailto:marcus.denker@inria.fr>> wrote: >>> >>>>> >>>>> >>>>> Ok, this is now in and the image is now 22.7MB. with all examples, >>>>> tests, tutorials, ConfigurationOf, >>>>> Metacello... >>>> >>>> Looks like we'll be able to start boasting about that... >>>> >>>> >>> It is a first step... There is still a lot of duplicated and dead >>> code, for >>> example. But aside from that: >>> >>> We should really have a look into sharing e.g. identical large strings >>> (using a copy-on-write proxy) and compression... >>> e.g. Forms are compressed (see #hibernate) on shutdown. Why no do >>> more like >>> that, but more late bound? >>> Most of the 22MB are not part of the working set... we could gain a >>> lot of >>> space by compressing once as the last state of the build. >>> >>> Another thing I would like to have is to compress the distribution images >>> and have the VM uncompress them on startup. LZ4 decompresses with >>> 2GB/second *per core*... and the resulting image would be 12MB. This >>> way we >>> could have .pharo images and just use those, no need to have >>> a zip on the build server. >> >> Interesting but not sure I'd like to have images going through >> decompression everytime I spin them up. >> Especially if there are a lot of the in a server > > As I said: it decompresses with 2GB/second. How much slower would the > startup > be for a 22MB image? > (The idea would be to only do that for small images) > > To quote https://code.google.com/p/lz4/ > > ââ¦. extremely fast decoder, with speed in multiple GB/s per core, > typically reaching RAM speed limits on multi-core systems." > > Marcus Are you sure it's worth the added complexity of a self-decoding image in lz4 (as well as a dependency on yet one more external item)? Thierry

March 4, 2015

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

by Norbert Hartl

> Am 04.03.2015 um 14:19 schrieb phil(a)highoctane.be: > > On Wed, Mar 4, 2015 at 1:56 PM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >>>> >>>> >>>> Ok, this is now in and the image is now 22.7MB. with all examples, >>>> tests, tutorials, ConfigurationOf, >>>> Metacello... >>> >>> Looks like we'll be able to start boasting about that... >>> >>> >> It is a first step... There is still a lot of duplicated and dead code, for >> example. But aside from that: >> >> We should really have a look into sharing e.g. identical large strings >> (using a copy-on-write proxy) and compression... >> e.g. Forms are compressed (see #hibernate) on shutdown. Why no do more like >> that, but more late bound? >> Most of the 22MB are not part of the working set... we could gain a lot of >> space by compressing once as the last state of the build. >> >> Another thing I would like to have is to compress the distribution images >> and have the VM uncompress them on startup. LZ4 decompresses with >> 2GB/second *per core*... and the resulting image would be 12MB. This way we >> could have .pharo images and just use those, no need to have >> a zip on the build server. > > Interesting but not sure I'd like to have images going through > decompression everytime I spin them up. > Especially if there are a lot of the in a server. > To be sure if you want that you have to test it. You have always take into account that a smaller file will have less I/O to read from disk. This could lead into a speed up because you spare slow disk I/O and compensate with fast memory operations. Even if there isn't a benefit you are always free to decompress the image and put it on disk. No need to use it like it was delivered. And btw. how often do you need to spin up a server?? ;) Norbert

March 4, 2015

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

by Marcus Denker

> On 04 Mar 2015, at 14:19, phil(a)highoctane.be wrote: > > On Wed, Mar 4, 2015 at 1:56 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>>> >>>> >>>> Ok, this is now in and the image is now 22.7MB. with all examples, >>>> tests, tutorials, ConfigurationOf, >>>> Metacello... >>> >>> Looks like we'll be able to start boasting about that... >>> >>> >> It is a first step... There is still a lot of duplicated and dead code, for >> example. But aside from that: >> >> We should really have a look into sharing e.g. identical large strings >> (using a copy-on-write proxy) and compression... >> e.g. Forms are compressed (see #hibernate) on shutdown. Why no do more like >> that, but more late bound? >> Most of the 22MB are not part of the working set... we could gain a lot of >> space by compressing once as the last state of the build. >> >> Another thing I would like to have is to compress the distribution images >> and have the VM uncompress them on startup. LZ4 decompresses with >> 2GB/second *per core*... and the resulting image would be 12MB. This way we >> could have .pharo images and just use those, no need to have >> a zip on the build server. > > Interesting but not sure I'd like to have images going through > decompression everytime I spin them up. > Especially if there are a lot of the in a server As I said: it decompresses with 2GB/second. How much slower would the startup be for a 22MB image? (The idea would be to only do that for small images) To quote https://code.google.com/p/lz4/ ââ¦. extremely fast decoder, with speed in multiple GB/s per core, typically reaching RAM speed limits on multi-core systems." Marcus

March 4, 2015

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

by phil＠highoctane.be

On Wed, Mar 4, 2015 at 1:56 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> > >> > >> > Ok, this is now in and the image is now 22.7MB. with all examples, >> > tests, tutorials, ConfigurationOf, >> > Metacello... >> >> Looks like we'll be able to start boasting about that... >> >> > It is a first step... There is still a lot of duplicated and dead code, for > example. But aside from that: > > We should really have a look into sharing e.g. identical large strings > (using a copy-on-write proxy) and compression... > e.g. Forms are compressed (see #hibernate) on shutdown. Why no do more like > that, but more late bound? > Most of the 22MB are not part of the working set... we could gain a lot of > space by compressing once as the last state of the build. > > Another thing I would like to have is to compress the distribution images > and have the VM uncompress them on startup. LZ4 decompresses with > 2GB/second *per core*... and the resulting image would be 12MB. This way we > could have .pharo images and just use those, no need to have > a zip on the build server. Interesting but not sure I'd like to have images going through decompression everytime I spin them up. Especially if there are a lot of the in a server. Phil > > Marcus

March 4, 2015

Update goes havoc

by Norbert Hartl

I got this emergency evaluator while doing "Software update" from the menu. Pretty harsh, no? :)

March 4, 2015

Re: [Pharo-dev] LabelModel>>#text: Deprecation

by Sean P. DeNigris

Sean P. DeNigris wrote > To me, "label label: aString" seems odd btw this fix broke LabelModel because #initialize still refers to the now non-existent textHolder instVar instead of labelHolder ----- Cheers, Sean -- View this message in context: http://forum.world.st/LabelModel-text-Deprecation-tp4809424p4809426.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 4, 2015

LabelModel>>#text: Deprecation

by Sean P. DeNigris

What is the reason for this? I searched the lists & fogbugz for "labelmodel text" to no avail. To me, "label label: aString" seems odd. Why is this better than "label text: aString"? In general, for refactors like this, where the purpose is not obvious as it would be for a bug fix or new feature, it would be good to somehow link somewhere for more info. Maybe the deprecation message, since by definition will be deleted in the next verison, would be a good place to put an issue number or url to a discussion. Also, might I humbly suggest having a native English speaker review changes where the intent is to increase "clarity" so we don't have another #ensureCreateDirectory incident ;) j/k... But a grammar/idiom review would be super quick/easy. Maybe a tag or status in fogbugz would help? ----- Cheers, Sean -- View this message in context: http://forum.world.st/LabelModel-text-Deprecation-tp4809424.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 4, 2015

Re: [Pharo-dev] [Pharo4] Image size now 23.2MB

by Marcus Denker

> > > > > > Ok, this is now in and the image is now 22.7MB. with all examples, > tests, tutorials, ConfigurationOf, > > Metacello... > > Looks like we'll be able to start boasting about that... > > > It is a first step... There is still a lot of duplicated and dead code, for example. But aside from that: We should really have a look into sharing e.g. identical large strings (using a copy-on-write proxy) and compression... e.g. Forms are compressed (see #hibernate) on shutdown. Why no do more like that, but more late bound? Most of the 22MB are not part of the working set... we could gain a lot of space by compressing once as the last state of the build. Another thing I would like to have is to compress the distribution images and have the VM uncompress them on startup. LZ4 decompresses with 2GB/second *per core*... and the resulting image would be 12MB. This way we could have .pharo images and just use those, no need to have a zip on the build server. Marcus

March 4, 2015

Re: [Pharo-dev] Slots?

by Sean P. DeNigris

Hey Jeff! As Marcus said, we're all in a similar position regarding slots, figuring them out as we go. A question like this is better for the users mailing list so it doesn't get lost in the flood of development-related posts, and also to save our devs' mailboxes ;) Thanks. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Slots-tp4809344p4809418.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 4, 2015