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

Re: [Pharo-project] About Monticello Meta Data...

by Frank Shearar

On 13 February 2013 07:51, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Feb 13, 2013, at 8:49 AM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > >> On 13 February 2013 07:39, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> On Feb 13, 2013, at 8:34 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>>> Hi, >>>> >>>> The current image has a size of 28.7MB (#20540). >>>> >>>> Now execute this expression: >>>> >>>> MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. >>>> >>>> save the image. >>>> >>>> Result: 20MB >>>> >>>> â¦ this means that MC is wasting 8MB of memory with data that should live in the >>>> repository. And the problem is that is gets larger with every commitâ¦ >>>> >>>> The other offender is ScriptLoader. Unload that, do a #cleanUpForRelease >>>> >>>> ==> 15.6MB >>>> >>>> Then .changes. Now it is at 32MB, plus 16MB sources. >>>> >>>> We really need to condense the sources for 2.0â¦ of course the problem is >>>> that it's broken (as it should be, because it is not tested). >>>> >>> >>> Ah, and in general, we need to move to a more incremental process. >>> Every mechanism that of the kind "We do this once before the release" >>> is *WRONG*. >>> Every commit needs to lead to a releasable artefact. Without *any* human >>> intervention. >> >> Yes. That's exactly what I did for the Squeak 4.4 release (don't hit >> me! :) ). Pharo's process will probably differ a bit but we now >> > So you make a new .sources after every commit? > > >> * take an old image (somewhere early in 4.4's history) >> * update it >> * store that as one artifact, A >> * run tests on a copy to get the test results >> * a second job takes A and runs the necessary ReleaseBuilder to get B, >> a release candidate. >> > > This is what we do, too. > > What I mean are things like condensing the sources and changes. > Or Monticello meta dataâ¦ something that grows with every commit > is not something that is sustainable. Ah, good. I'll get up to speed with Pharo's infrastructure eventually. So you're saying that it's just that ReleaseBuilder needs to actually do these things - condense sources etc. - and then run some tests to show that condensing's actually broken. frank > Marcus

Feb. 13, 2013

Re: [Pharo-project] About Monticello Meta Data...

by Marcus Denker

On Feb 13, 2013, at 8:49 AM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 13 February 2013 07:39, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Feb 13, 2013, at 8:34 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >>> Hi, >>> >>> The current image has a size of 28.7MB (#20540). >>> >>> Now execute this expression: >>> >>> MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. >>> >>> save the image. >>> >>> Result: 20MB >>> >>> â¦ this means that MC is wasting 8MB of memory with data that should live in the >>> repository. And the problem is that is gets larger with every commitâ¦ >>> >>> The other offender is ScriptLoader. Unload that, do a #cleanUpForRelease >>> >>> ==> 15.6MB >>> >>> Then .changes. Now it is at 32MB, plus 16MB sources. >>> >>> We really need to condense the sources for 2.0â¦ of course the problem is >>> that it's broken (as it should be, because it is not tested). >>> >> >> Ah, and in general, we need to move to a more incremental process. >> Every mechanism that of the kind "We do this once before the release" >> is *WRONG*. >> Every commit needs to lead to a releasable artefact. Without *any* human >> intervention. > > Yes. That's exactly what I did for the Squeak 4.4 release (don't hit > me! :) ). Pharo's process will probably differ a bit but we now > So you make a new .sources after every commit? > * take an old image (somewhere early in 4.4's history) > * update it > * store that as one artifact, A > * run tests on a copy to get the test results > * a second job takes A and runs the necessary ReleaseBuilder to get B, > a release candidate. > This is what we do, too. What I mean are things like condensing the sources and changes. Or Monticello meta dataâ¦ something that grows with every commit is not something that is sustainable. Marcus

Feb. 13, 2013

Re: [Pharo-project] About Monticello Meta Data...

by Frank Shearar

On 13 February 2013 07:39, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Feb 13, 2013, at 8:34 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> Hi, >> >> The current image has a size of 28.7MB (#20540). >> >> Now execute this expression: >> >> MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. >> >> save the image. >> >> Result: 20MB >> >> â¦ this means that MC is wasting 8MB of memory with data that should live in the >> repository. And the problem is that is gets larger with every commitâ¦ >> >> The other offender is ScriptLoader. Unload that, do a #cleanUpForRelease >> >> ==> 15.6MB >> >> Then .changes. Now it is at 32MB, plus 16MB sources. >> >> We really need to condense the sources for 2.0â¦ of course the problem is >> that it's broken (as it should be, because it is not tested). >> > > Ah, and in general, we need to move to a more incremental process. > Every mechanism that of the kind "We do this once before the release" > is *WRONG*. > Every commit needs to lead to a releasable artefact. Without *any* human > intervention. Yes. That's exactly what I did for the Squeak 4.4 release (don't hit me! :) ). Pharo's process will probably differ a bit but we now * take an old image (somewhere early in 4.4's history) * update it * store that as one artifact, A * run tests on a copy to get the test results * a second job takes A and runs the necessary ReleaseBuilder to get B, a release candidate. I don't know how to do the next logical step, which is to reject slices that break tests. Well, I guess the monkey could do it: * take the most recently released image * load the slice * run the tests * reject any slice that causes any regressions * _monkey_merges_ a slice that passes. That means the monkey becomes a gatekeeper in the workflow, ensuring the master branch never breaks. frank > Marcus > >

Feb. 13, 2013

Re: [Pharo-project] Failing Tests 2.0

by Marcus Denker

On Feb 13, 2013, at 8:45 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > Here is a list of the failing tests for 2.0: > > https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/130/testReport/ > > Most of them are results of bug fixes we did last weekâ¦ sadly. > Ah, and it would be nice if the people who wrote the change that makes those tests fail have a look. I am sure they can find the cause *much* *much* faster then the anyone else. And, yes, the Monkey needs to run *ALL* tests. Marcus

Feb. 13, 2013

[Pharo-project] Failing Tests 2.0

by Marcus Denker

Hi, Here is a list of the failing tests for 2.0: https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/130/testReport/ Most of them are results of bug fixes we did last weekâ¦ sadly. Marcus

Feb. 13, 2013

Re: [Pharo-project] About Monticello Meta Data...

by Marcus Denker

On Feb 13, 2013, at 8:34 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > The current image has a size of 28.7MB (#20540). > > Now execute this expression: > > MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. > > save the image. > > Result: 20MB > > â¦ this means that MC is wasting 8MB of memory with data that should live in the > repository. And the problem is that is gets larger with every commitâ¦ > > The other offender is ScriptLoader. Unload that, do a #cleanUpForRelease > > ==> 15.6MB > > Then .changes. Now it is at 32MB, plus 16MB sources. > > We really need to condense the sources for 2.0â¦ of course the problem is > that it's broken (as it should be, because it is not tested). > Ah, and in general, we need to move to a more incremental process. Every mechanism that of the kind "We do this once before the release" is *WRONG*. Every commit needs to lead to a releasable artefact. Without *any* human intervention. Marcus

Feb. 13, 2013

[Pharo-project] Open Issues 2.0: Down to 15

by Marcus Denker

Hi, http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D2.0 15 issuesâ¦ it would be nice if everyone would have a look so we can close them soon. Marcus

Feb. 13, 2013

[Pharo-project] About Monticello Meta Data...

by Marcus Denker

Hi, The current image has a size of 28.7MB (#20540). Now execute this expression: MCVersionInfo allInstances do: [ :each | each instVarNamed: 'ancestors' put: nil ]. save the image. Result: 20MB â¦ this means that MC is wasting 8MB of memory with data that should live in the repository. And the problem is that is gets larger with every commitâ¦ The other offender is ScriptLoader. Unload that, do a #cleanUpForRelease ==> 15.6MB Then .changes. Now it is at 32MB, plus 16MB sources. We really need to condense the sources for 2.0â¦ of course the problem is that it's broken (as it should be, because it is not tested). Marcus

Feb. 13, 2013

[Pharo-project] [update 2.0] #20542

by Marcus Denker

20542 ----- Issue 7496: MethodClassifier should ignore as yet unclassified when looking for other implementors http://code.google.com/p/pharo/issues/detail?id=7496 Issue 7429: FileReferences have a confusing/wrong external representation http://code.google.com/p/pharo/issues/detail?id=7429 Diff information: http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.784.diff http://ss3.gemstone.com/ss/Pharo20/FileSystem-Disk-MarcusDenker.48.diff

Feb. 13, 2013

Re: [Pharo-project] CommandShell and OSProcess updated for Pharo 2.0

by stephane ducasse

normally On Feb 12, 2013, at 5:59 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Tue, Feb 12, 2013 at 08:13:39AM -0800, Sean P. DeNigris wrote: >> stephane ducasse wrote >>> I will update their configurations and publish them in the squeaksource >>> repository >>> and the MetaRepoForPharo20. >> >> I fixed the configs to work on Pharo 1.4 and Pharo 2.0 and uploaded to >> sqs/MetaRepo... and ss3/MetaFor20â¦ @sean what was the problem because I tested it several time on 1.4 and 2.0 >> There are still some issues (like tests >> are failing because ReferenceStream doesn't exist, and scattered references >> to FileDirectory), but the core functionality seems to work. @David I took the latest version normally of all command and os packages.

Feb. 13, 2013