Re: [Pharo-project] .changes are now 37MBâ¦.
On Mar 6, 2012, at 7:30 PM, Max Leske wrote:
This may be a stupid question⦠(As far as I understand, condensing the changes is not the same) Why don't you increment the version number of the sources file to 1.1 and use a fresh changes file?
The sources file does not contain the sources and the changes just the changes. (even though one could think so taking the names into account.) The sources file containes the sources of ages ago (1.0), the .changes is "on top of that". This means that the .sources file contains a lot of code from classes and methods that have been removed (like the changes), as well as old versions. The .sources/.changes mechanism merges three responsabilties: 1) be a log of all edited code in case of a crash 2) store the current source of the methods (when you ask a method for code, it reads either from the .sources (method not changed since 1.0) or from the .changes (method was changed). 3) provide a history for all code And all that in 2 big files that one can only append to because? No idea, actually... I personally think that it is a mistake today to merge all these into one such basic mechanism. Especialy if you look at how complex the code is in the image... it's actually amazing. When you do a #condenseSources (which is sadly broken right now), then it generates a .sources file with just the code in the current image. It would be interesting to see how large that is. Marcus -- Marcus Denker -- http://marcusdenker.de
max, maybe you want to create a test git repos with all the sources back to 1.0 :D and then we should record all changes into a local git-repos :) if you want to got back some versions you simply start fetching the missing objects from a central repos somewhere... so far dreaming a bit best cami On 2012-03-06, at 20:01, Marcus Denker wrote:
On Mar 6, 2012, at 7:30 PM, Max Leske wrote:
This may be a stupid question⦠(As far as I understand, condensing the changes is not the same) Why don't you increment the version number of the sources file to 1.1 and use a fresh changes file?
The sources file does not contain the sources and the changes just the changes. (even though one could think so taking the names into account.)
The sources file containes the sources of ages ago (1.0), the .changes is "on top of that". This means that the .sources file contains a lot of code from classes and methods that have been removed (like the changes), as well as old versions.
The .sources/.changes mechanism merges three responsabilties:
1) be a log of all edited code in case of a crash 2) store the current source of the methods (when you ask a method for code, it reads either from the .sources (method not changed since 1.0) or from the .changes (method was changed). 3) provide a history for all code
And all that in 2 big files that one can only append to because? No idea, actually...
I personally think that it is a mistake today to merge all these into one such basic mechanism. Especialy if you look at how complex the code is in the image... it's actually amazing.
When you do a #condenseSources (which is sadly broken right now), then it generates a .sources file with just the code in the current image. It would be interesting to see how large that is.
Marcus
-- Marcus Denker -- http://marcusdenker.de
If it wouldn't take so bloody long to run (approx. 9 hours for all Squeak version up to and including Pharo 1.0) and didn't require me to port back all the changes we made to FSGit to Pharogenesis I'd happily do that. I just don't think the effort is worth it (I'll change my mind if people on the list start begging for it :) ) Ah yes, and the fetching⦠That would of course be missing too⦠:p Cheers, Max On 06.03.2012, at 20:05, Camillo Bruni wrote:
max,
maybe you want to create a test git repos with all the sources back to 1.0 :D and then we should record all changes into a local git-repos :) if you want to got back some versions you simply start fetching the missing objects from a central repos somewhere...
so far dreaming a bit
best cami
On 2012-03-06, at 20:01, Marcus Denker wrote:
On Mar 6, 2012, at 7:30 PM, Max Leske wrote:
This may be a stupid question⦠(As far as I understand, condensing the changes is not the same) Why don't you increment the version number of the sources file to 1.1 and use a fresh changes file?
The sources file does not contain the sources and the changes just the changes. (even though one could think so taking the names into account.)
The sources file containes the sources of ages ago (1.0), the .changes is "on top of that". This means that the .sources file contains a lot of code from classes and methods that have been removed (like the changes), as well as old versions.
The .sources/.changes mechanism merges three responsabilties:
1) be a log of all edited code in case of a crash 2) store the current source of the methods (when you ask a method for code, it reads either from the .sources (method not changed since 1.0) or from the .changes (method was changed). 3) provide a history for all code
And all that in 2 big files that one can only append to because? No idea, actually...
I personally think that it is a mistake today to merge all these into one such basic mechanism. Especialy if you look at how complex the code is in the image... it's actually amazing.
When you do a #condenseSources (which is sadly broken right now), then it generates a .sources file with just the code in the current image. It would be interesting to see how large that is.
Marcus
-- Marcus Denker -- http://marcusdenker.de
On Tue, Mar 6, 2012 at 11:01 AM, Marcus Denker <marcus.denker@inria.fr>wrote:
On Mar 6, 2012, at 7:30 PM, Max Leske wrote:
This may be a stupid question⦠(As far as I understand, condensing the changes is not the same) Why don't you increment the version number of the sources file to 1.1 and use a fresh changes file?
The sources file does not contain the sources and the changes just the changes. (even though one could think so taking the names into account.)
The sources file containes the sources of ages ago (1.0), the .changes is "on top of that". This means that the .sources file contains a lot of code from classes and methods that have been removed (like the changes), as well as old versions.
The .sources/.changes mechanism merges three responsabilties:
1) be a log of all edited code in case of a crash 2) store the current source of the methods (when you ask a method for code, it reads either from the .sources (method not changed since 1.0) or from the .changes (method was changed). 3) provide a history for all code
And all that in 2 big files that one can only append to because? No idea, actually...
I personally think that it is a mistake today to merge all these into one such basic mechanism. Especialy if you look at how complex the code is in the image... it's actually amazing.
When you do a #condenseSources (which is sadly broken right now), then it generates a .sources file with just the code in the current image. It would be interesting to see how large that is.
IMO it's also interesting to see how big a condense of only the valid history is, i.e. removing history for missing classes and methods, and only retaining history that is referenced from current methods (which eliminates branches that don't lead to the current definition). After all this is the history one wants, and I already provided code to compute the per-method history that leads to the current definition. Why not have your cake and compress it too?
Marcus
-- Marcus Denker -- http://marcusdenker.de
-- best, Eliot
That's what I meant⦠So that won't work⦠Thanks for the explanation Marcus. On 06.03.2012, at 20:01, Marcus Denker wrote:
When you do a #condenseSources (which is sadly broken right now), then it generates a .sources file with just the code in the current image. It would be interesting to see how large that is.
And all that in 2 big files that one can only append to because? No idea, actually...
I personally think that it is a mistake today to merge all these into one such basic mechanism. Especialy if you look at how complex the code is in the image... it's actually amazing.
Hear hear. I think it's insane to do it (only) this way at this point. Objects everywhere... -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547
On 6 March 2012 23:30, Craig Latta <craig@netjam.org> wrote:
And all that in 2 big files that one can only append to because? No idea, actually...
I personally think that it is a mistake today to merge all these into one such basic mechanism. Especialy if you look at how complex the code is in the image... it's actually amazing.
  Hear hear. I think it's insane to do it (only) this way at this point. Objects everywhere...
can you elaborate? do what at which point?
-C
-- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547
-- Best regards, Igor Stasenko.
And all that in 2 big files that one can only append to because? No idea, actually...
I personally think that it is a mistake today to merge all these into one such basic mechanism. Especialy if you look at how complex the code is in the image... it's actually amazing.
Hear hear. I think it's insane to do it (only) this way at this point. Objects everywhere...
can you elaborate? do what at which point?
To use source code written on files to record history information, at this point in history where we have more than enough processor, network, and disk to just use live distributed object memories. I can see keeping the old stuff around for a while as a redundancy mechanism, but we needn't rely on it alone. -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547
On Wed, Mar 7, 2012 at 1:56 AM, Craig Latta <craig@netjam.org> wrote:
And all that in 2 big files that one can only append to because? No idea, actually...
I personally think that it is a mistake today to merge all these into one such basic mechanism. Especialy if you look at how complex the code is in the image... it's actually amazing.
Hear hear. I think it's insane to do it (only) this way at this point. Objects everywhere...
can you elaborate? do what at which point?
To use source code written on files to record history information, at this point in history where we have more than enough processor, network, and disk to just use live distributed object memories. I can see keeping the old stuff around for a while as a redundancy mechanism, but we needn't rely on it alone.
But both Occam's razor and IIABDFI (if-it-aint-broke-dont-fix-it) say we should keep with it. It has worked extremely well with Squeak/Pharo, is robust, persistent, and simple. Realistically we're not going to move to Spoon over night, so what to do about a 37Mb changes file is a pressing issue. Being able to compress with history and/or write a new sources file with compressed history makes sense. It's not being unimaginitive or regressive, or anti-innovation; merely pragmatic.
-C
-- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547
-- best, Eliot
On 7 March 2012 19:31, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Wed, Mar 7, 2012 at 1:56 AM, Craig Latta <craig@netjam.org> wrote:
And all that in 2 big files that one can only append to because? No idea, actually...
I personally think that it is a mistake today to merge all these into one such basic mechanism. Especialy if you look at how complex the code is in the image... it's actually amazing.
  Hear hear. I think it's insane to do it (only) this way at this point. Objects everywhere...
can you elaborate? do what at which point?
  To use source code written on files to record history information, at this point in history where we have more than enough processor, network, and disk to just use live distributed object memories. I can see keeping the old stuff around for a while as a redundancy mechanism, but we needn't rely on it alone.
But both Occam's razor and IIABDFI (if-it-aint-broke-dont-fix-it) say we should keep with it. Â It has worked extremely well with Squeak/Pharo, is robust, persistent, and simple. Â Realistically we're not going to move to Spoon over night, so what to do about a 37Mb changes file is a pressing issue. Â Being able to compress with history and/or write a new sources file with compressed history makes sense. Â It's not being unimaginitive or regressive, or anti-innovation; merely pragmatic.
Well, it IS broken. I cannot say something else about direct uses of 'SourceFiles at: 1'/'SourceFiles at: 2' at random places in image. But we didn't yet found time to fix that, not saying about binding to something else like spoon, so yes, a pragmatic way would be to just do the same thing as we did before: condense/compres changes and source. -- Best regards, Igor Stasenko.
participants (6)
-
Camillo Bruni -
Craig Latta -
Eliot Miranda -
Igor Stasenko -
Marcus Denker -
Max Leske