[Pharo-project] About Monticello Meta Data...
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
On Feb 13, 2013, at 8:34 AM, Marcus Denker <marcus.denker@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
On 13 February 2013 07:39, Marcus Denker <marcus.denker@inria.fr> wrote:
On Feb 13, 2013, at 8:34 AM, Marcus Denker <marcus.denker@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
On Feb 13, 2013, at 8:49 AM, Frank Shearar <frank.shearar@gmail.com> wrote:
On 13 February 2013 07:39, Marcus Denker <marcus.denker@inria.fr> wrote:
On Feb 13, 2013, at 8:34 AM, Marcus Denker <marcus.denker@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
On 13 February 2013 07:51, Marcus Denker <marcus.denker@inria.fr> wrote:
On Feb 13, 2013, at 8:49 AM, Frank Shearar <frank.shearar@gmail.com> wrote:
On 13 February 2013 07:39, Marcus Denker <marcus.denker@inria.fr> wrote:
On Feb 13, 2013, at 8:34 AM, Marcus Denker <marcus.denker@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
On Feb 13, 2013, at 8:55 AM, Frank Shearar <frank.shearar@gmail.com> wrote:
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.
No, we need to get rid of all ways of doing things that makes us distinguish the release from any other image. Aka: .changes and .sources are evil. Evil, I say. Marcus
On 13 February 2013 07:59, Marcus Denker <marcus.denker@inria.fr> wrote:
On Feb 13, 2013, at 8:55 AM, Frank Shearar <frank.shearar@gmail.com> wrote:
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.
No, we need to get rid of all ways of doing things that makes us distinguish the release from any other image.
Yes - devs need to dogfood, and the dogfood's the released image. OH. Oh, right.
Aka: .changes and .sources are evil. Evil, I say.
No arguments here! So "fix condenseSources" actually means "remove the need to do so in the first place". Right! frank
Marcus
Hoi-- Marcus writes:
we need to get rid of all ways of doing things that makes us distinguish the release from any other image.
Aka: .changes and .sources are evil. Evil, I say.
Yes, evil and anachronistic. Buggy whips for a Tesla. Frank writes:
...devs need to dogfood, and the dogfood's the released image.
Indeed, you should eat your own cooking... but if you're making dogfood, something's wrong. :) -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
On Feb 13, 2013, at 8:51 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
* 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.
If "the release image" is different to what everyone downloads in the development phase for development and testing, we do something wrong. Marcus
So concretely what can we do? Let us try to condense sources and see if it is working. Stef
participants (4)
-
Craig Latta -
Frank Shearar -
Marcus Denker -
stephane ducasse