On 7 March 2012 19:31, Eliot Miranda <[email protected]> wrote: > > > On Wed, Mar 7, 2012 at 1:56 AM, Craig Latta <[email protected]> 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.
