Hi -
I just wanted to float an idea that Eliot came up with over lunch. He pointed out that it would be good if we could preserve the method history from 4.0 but that it also would be good if we could ship with an empty changes file. Both of which can be achieved if we'd be condensing the changes file *to the end of* the sources file, i.e,
SqueakV41.source = SqueakV4.sources + Squeak4.1.changes
This has some advantages besides the empty changes file. It allows us to keep up with the intermediate stages during the RCs. In other words, for the next RC I can make a SqueakV41.sources and the image will be "compatible" with later versions of the sources file. In fact, SqueakV41.sources would be compatible with with SqueakV40.sources, too, so you could link the old sources file to the new one to save space if desired.
What do people think? Sounds like a plan?
Cheers, - Andreas
2010/3/29 Andreas Raab andreas.raab@gmx.de:
Hi -
I just wanted to float an idea that Eliot came up with over lunch. He pointed out that it would be good if we could preserve the method history from 4.0 but that it also would be good if we could ship with an empty changes file. Both of which can be achieved if we'd be condensing the changes file *to the end of* the sources file, i.e,
SqueakV41.source = SqueakV4.sources + Squeak4.1.changes
This has some advantages besides the empty changes file. It allows us to keep up with the intermediate stages during the RCs. In other words, for the next RC I can make a SqueakV41.sources and the image will be "compatible" with later versions of the sources file. In fact, SqueakV41.sources would be compatible with with SqueakV40.sources, too, so you could link the old sources file to the new one to save space if desired.
What do people think? Sounds like a plan?
I like the compatibility feature
Cheers, - Andreas
MMm, so is the source/changes then UTF8? If so then let me assume any UTF8 character encoding issues were addressed in the changes/sources logic as found in Pharo last year, otherwise a condense will/might trash your sources, assuming anyone notices...
On 2010-03-29, at 1:59 PM, Andreas Raab wrote:
Hi -
I just wanted to float an idea that Eliot came up with over lunch. He pointed out that it would be good if we could preserve the method history from 4.0 but that it also would be good if we could ship with an empty changes file. Both of which can be achieved if we'd be condensing the changes file *to the end of* the sources file, i.e,
SqueakV41.source = SqueakV4.sources + Squeak4.1.changes
This has some advantages besides the empty changes file. It allows us to keep up with the intermediate stages during the RCs. In other words, for the next RC I can make a SqueakV41.sources and the image will be "compatible" with later versions of the sources file. In fact, SqueakV41.sources would be compatible with with SqueakV40.sources, too, so you could link the old sources file to the new one to save space if desired.
What do people think? Sounds like a plan?
Cheers,
- Andreas
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On 3/29/2010 2:31 PM, John M McIntosh wrote:
MMm, so is the source/changes then UTF8? If so then let me assume any UTF8 character encoding issues were addressed in the changes/sources logic as found in Pharo last year, otherwise a condense will/might trash your sources, assuming anyone notices...
Can you point me to the discussion in question? I don't recall any issues here but it's better to be safe than sorry :-)
Thanks, - Andreas
On 2010-03-29, at 1:59 PM, Andreas Raab wrote:
Hi -
I just wanted to float an idea that Eliot came up with over lunch. He pointed out that it would be good if we could preserve the method history from 4.0 but that it also would be good if we could ship with an empty changes file. Both of which can be achieved if we'd be condensing the changes file *to the end of* the sources file, i.e,
SqueakV41.source = SqueakV4.sources + Squeak4.1.changes
This has some advantages besides the empty changes file. It allows us to keep up with the intermediate stages during the RCs. In other words, for the next RC I can make a SqueakV41.sources and the image will be "compatible" with later versions of the sources file. In fact, SqueakV41.sources would be compatible with with SqueakV40.sources, too, so you could link the old sources file to the new one to save space if desired.
What do people think? Sounds like a plan?
Cheers,
- Andreas
--
John M. McIntoshjohnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
I think it's http://code.google.com/p/pharo/issues/detail?id=830
but there were other issues
http://bugs.squeak.org/view.php?id=4267 http://bugs.squeak.org/view.php?id=6478
http://code.google.com/p/pharo/issues/detail?id=466 http://code.google.com/p/pharo/issues/detail?id=1423
On 2010-03-29, at 2:42 PM, Andreas Raab wrote:
On 3/29/2010 2:31 PM, John M McIntosh wrote:
MMm, so is the source/changes then UTF8? If so then let me assume any UTF8 character encoding issues were addressed in the changes/sources logic as found in Pharo last year, otherwise a condense will/might trash your sources, assuming anyone notices...
Can you point me to the discussion in question? I don't recall any issues here but it's better to be safe than sorry :-)
Thanks,
- Andreas
On 2010-03-29, at 1:59 PM, Andreas Raab wrote:
Hi -
I just wanted to float an idea that Eliot came up with over lunch. He pointed out that it would be good if we could preserve the method history from 4.0 but that it also would be good if we could ship with an empty changes file. Both of which can be achieved if we'd be condensing the changes file *to the end of* the sources file, i.e,
SqueakV41.source = SqueakV4.sources + Squeak4.1.changes
This has some advantages besides the empty changes file. It allows us to keep up with the intermediate stages during the RCs. In other words, for the next RC I can make a SqueakV41.sources and the image will be "compatible" with later versions of the sources file. In fact, SqueakV41.sources would be compatible with with SqueakV40.sources, too, so you could link the old sources file to the new one to save space if desired.
What do people think? Sounds like a plan?
Cheers,
- Andreas
--
John M. McIntoshjohnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Thanks John! All of these are *hugely* helpful. I fixed the issues that we didn't address yet (one resulting from the change to traits not to share compiled method and one issue that just went unnoticed on Mantis for too long). If you have other issues worth looking at please add them to the "4.1 master bug list" at:
http://bugs.squeak.org/view.php?id=7480
Cheers, - Andreas
On 3/29/2010 3:02 PM, John M McIntosh wrote:
I think it's http://code.google.com/p/pharo/issues/detail?id=830
but there were other issues
http://bugs.squeak.org/view.php?id=4267 http://bugs.squeak.org/view.php?id=6478
http://code.google.com/p/pharo/issues/detail?id=466 http://code.google.com/p/pharo/issues/detail?id=1423
On 2010-03-29, at 2:42 PM, Andreas Raab wrote:
On 3/29/2010 2:31 PM, John M McIntosh wrote:
MMm, so is the source/changes then UTF8? If so then let me assume any UTF8 character encoding issues were addressed in the changes/sources logic as found in Pharo last year, otherwise a condense will/might trash your sources, assuming anyone notices...
Can you point me to the discussion in question? I don't recall any issues here but it's better to be safe than sorry :-)
Thanks,
- Andreas
On 2010-03-29, at 1:59 PM, Andreas Raab wrote:
Hi -
I just wanted to float an idea that Eliot came up with over lunch. He pointed out that it would be good if we could preserve the method history from 4.0 but that it also would be good if we could ship with an empty changes file. Both of which can be achieved if we'd be condensing the changes file *to the end of* the sources file, i.e,
SqueakV41.source = SqueakV4.sources + Squeak4.1.changes
This has some advantages besides the empty changes file. It allows us to keep up with the intermediate stages during the RCs. In other words, for the next RC I can make a SqueakV41.sources and the image will be "compatible" with later versions of the sources file. In fact, SqueakV41.sources would be compatible with with SqueakV40.sources, too, so you could link the old sources file to the new one to save space if desired.
What do people think? Sounds like a plan?
Cheers,
- Andreas
--
John M. McIntoshjohnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
--
John M. McIntoshjohnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On 29.03.2010, at 22:59, Andreas Raab wrote:
Hi -
I just wanted to float an idea that Eliot came up with over lunch. He pointed out that it would be good if we could preserve the method history from 4.0 but that it also would be good if we could ship with an empty changes file. Both of which can be achieved if we'd be condensing the changes file *to the end of* the sources file, i.e,
SqueakV41.source = SqueakV4.sources + Squeak4.1.changes
This has some advantages besides the empty changes file. It allows us to keep up with the intermediate stages during the RCs. In other words, for the next RC I can make a SqueakV41.sources and the image will be "compatible" with later versions of the sources file. In fact, SqueakV41.sources would be compatible with with SqueakV40.sources, too, so you could link the old sources file to the new one to save space if desired.
What do people think? Sounds like a plan?
Cheers,
- Andreas
Sounds good, let's try.
- Bert -
On Mon, Mar 29, 2010 at 01:59:05PM -0700, Andreas Raab wrote:
Hi -
I just wanted to float an idea that Eliot came up with over lunch. He pointed out that it would be good if we could preserve the method history from 4.0 but that it also would be good if we could ship with an empty changes file. Both of which can be achieved if we'd be condensing the changes file *to the end of* the sources file, i.e,
SqueakV41.source = SqueakV4.sources + Squeak4.1.changes
Yes! That sounds great.
Dave
Great idea. It even sounds like it would provide an explicit "definition" of what 4.1 is, that is, 4.0 plus these "changes" (isolated in the changes file). Excellent..
On Mon, Mar 29, 2010 at 3:59 PM, Andreas Raab andreas.raab@gmx.de wrote:
Hi -
I just wanted to float an idea that Eliot came up with over lunch. He pointed out that it would be good if we could preserve the method history from 4.0 but that it also would be good if we could ship with an empty changes file. Both of which can be achieved if we'd be condensing the changes file *to the end of* the sources file, i.e,
SqueakV41.source = SqueakV4.sources + Squeak4.1.changes
This has some advantages besides the empty changes file. It allows us to keep up with the intermediate stages during the RCs. In other words, for the next RC I can make a SqueakV41.sources and the image will be "compatible" with later versions of the sources file. In fact, SqueakV41.sources would be compatible with with SqueakV40.sources, too, so you could link the old sources file to the new one to save space if desired.
What do people think? Sounds like a plan?
Cheers, - Andreas
Hi -
I just posted the code condensing sources in 4.1. It looks like it works fine; if anyone wants to try it (in a throwaway image please!) run it via:
Smalltalk appendChangesTo: 'mytest.sources'.
This will copy the old sources, append the condensed changes and run the image with the new sources file. Everything should continue to work as is, but method histories should show both, the latest 4.1 version and the original 4.0 version (but not the intermediates).
Cheers, - Andreas
On 3/29/2010 1:59 PM, Andreas Raab wrote:
Hi -
I just wanted to float an idea that Eliot came up with over lunch. He pointed out that it would be good if we could preserve the method history from 4.0 but that it also would be good if we could ship with an empty changes file. Both of which can be achieved if we'd be condensing the changes file *to the end of* the sources file, i.e,
SqueakV41.source = SqueakV4.sources + Squeak4.1.changes
This has some advantages besides the empty changes file. It allows us to keep up with the intermediate stages during the RCs. In other words, for the next RC I can make a SqueakV41.sources and the image will be "compatible" with later versions of the sources file. In fact, SqueakV41.sources would be compatible with with SqueakV40.sources, too, so you could link the old sources file to the new one to save space if desired.
What do people think? Sounds like a plan?
Cheers,
- Andreas
Hi All,
I'm a bit late to this party but I just had cause to condense changes in an image but wanted to retain most version history. By most I mean I want to retain the linear history (a method's direct ancestor versions), not the full history including reversions. So if one has a set of stamps like eem 7/7/2009 20:06 7 July 2009 8:06 pm eem 6/18/2009 19:21 18 June 2009 7:21 pm eem 5/5/2009 12:16 5 May 2009 12:16 pm eem 6/18/2009 19:19 18 June 2009 7:19 pm eem 6/18/2009 18:57 18 June 2009 6:57 pm eem 5/5/2009 12:16 5 May 2009 12:16 pm eem 6/18/2009 18:17 18 June 2009 6:17 pm eem 6/18/2009 18:14 18 June 2009 6:14 pm eem 6/18/2009 18:06 18 June 2009 6:06 pm eem 5/5/2009 12:16 5 May 2009 12:16 pm eem 5/4/2009 19:19 4 May 2009 7:19 pm the direct ancestry is eem 7/7/2009 20:06 7 July 2009 8:06 pm eem 6/18/2009 19:21 18 June 2009 7:21 pm eem 5/5/2009 12:16 5 May 2009 12:16 pm eem 5/4/2009 19:19 4 May 2009 7:19 pm
This probably isn't useful as the default condense changes mechanism but its probably useful to a few of you, so here it is. The first change set provides shared read-only copies of the sources files for faster version scanning. The second change set provides the code to extract the direct ancestry and a hack in ClassDescription>>fileOutChangedMessages:on:moveSource:toFile: to force use of ClassDescription>>printMethodChunkHistorically:on:moveSource:toFile: when condensing. If y'all think this is generally useful we can make "condense preserving history" an option alongside condenseChanges, condenseSources et al.
HTH Eliot
On Wed, Mar 31, 2010 at 11:34 PM, Andreas Raab andreas.raab@gmx.de wrote:
Hi -
I just posted the code condensing sources in 4.1. It looks like it works fine; if anyone wants to try it (in a throwaway image please!) run it via:
Smalltalk appendChangesTo: 'mytest.sources'.This will copy the old sources, append the condensed changes and run the image with the new sources file. Everything should continue to work as is, but method histories should show both, the latest 4.1 version and the original 4.0 version (but not the intermediates).
Cheers,
- Andreas
On 3/29/2010 1:59 PM, Andreas Raab wrote:
Hi -
I just wanted to float an idea that Eliot came up with over lunch. He pointed out that it would be good if we could preserve the method history from 4.0 but that it also would be good if we could ship with an empty changes file. Both of which can be achieved if we'd be condensing the changes file *to the end of* the sources file, i.e,
SqueakV41.source = SqueakV4.sources + Squeak4.1.changes
This has some advantages besides the empty changes file. It allows us to keep up with the intermediate stages during the RCs. In other words, for the next RC I can make a SqueakV41.sources and the image will be "compatible" with later versions of the sources file. In fact, SqueakV41.sources would be compatible with with SqueakV40.sources, too, so you could link the old sources file to the new one to save space if desired.
What do people think? Sounds like a plan?
Cheers,
- Andreas
Eek. *don't* file in the last two methods in SourceFileReadOnlyCopy.1.cs as they screw up version scanning during condensation.
On Wed, May 19, 2010 at 12:05 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
Hi All,
I'm a bit late to this party but I just had cause to condense changesin an image but wanted to retain most version history. By most I mean I want to retain the linear history (a method's direct ancestor versions), not the full history including reversions. So if one has a set of stamps like eem 7/7/2009 20:06 7 July 2009 8:06 pm eem 6/18/2009 19:21 18 June 2009 7:21 pm eem 5/5/2009 12:16 5 May 2009 12:16 pm eem 6/18/2009 19:19 18 June 2009 7:19 pm eem 6/18/2009 18:57 18 June 2009 6:57 pm eem 5/5/2009 12:16 5 May 2009 12:16 pm eem 6/18/2009 18:17 18 June 2009 6:17 pm eem 6/18/2009 18:14 18 June 2009 6:14 pm eem 6/18/2009 18:06 18 June 2009 6:06 pm eem 5/5/2009 12:16 5 May 2009 12:16 pm eem 5/4/2009 19:19 4 May 2009 7:19 pm the direct ancestry is eem 7/7/2009 20:06 7 July 2009 8:06 pm eem 6/18/2009 19:21 18 June 2009 7:21 pm eem 5/5/2009 12:16 5 May 2009 12:16 pm eem 5/4/2009 19:19 4 May 2009 7:19 pm
This probably isn't useful as the default condense changes mechanism but its probably useful to a few of you, so here it is. The first change set provides shared read-only copies of the sources files for faster version scanning. The second change set provides the code to extract the direct ancestry and a hack in ClassDescription>>fileOutChangedMessages:on:moveSource:toFile: to force use of ClassDescription>>printMethodChunkHistorically:on:moveSource:toFile: when condensing. If y'all think this is generally useful we can make "condense preserving history" an option alongside condenseChanges, condenseSources et al.
HTH Eliot
On Wed, Mar 31, 2010 at 11:34 PM, Andreas Raab andreas.raab@gmx.dewrote:
Hi -
I just posted the code condensing sources in 4.1. It looks like it works fine; if anyone wants to try it (in a throwaway image please!) run it via:
Smalltalk appendChangesTo: 'mytest.sources'.This will copy the old sources, append the condensed changes and run the image with the new sources file. Everything should continue to work as is, but method histories should show both, the latest 4.1 version and the original 4.0 version (but not the intermediates).
Cheers,
- Andreas
On 3/29/2010 1:59 PM, Andreas Raab wrote:
Hi -
I just wanted to float an idea that Eliot came up with over lunch. He pointed out that it would be good if we could preserve the method history from 4.0 but that it also would be good if we could ship with an empty changes file. Both of which can be achieved if we'd be condensing the changes file *to the end of* the sources file, i.e,
SqueakV41.source = SqueakV4.sources + Squeak4.1.changes
This has some advantages besides the empty changes file. It allows us to keep up with the intermediate stages during the RCs. In other words, for the next RC I can make a SqueakV41.sources and the image will be "compatible" with later versions of the sources file. In fact, SqueakV41.sources would be compatible with with SqueakV40.sources, too, so you could link the old sources file to the new one to save space if desired.
What do people think? Sounds like a plan?
Cheers,
- Andreas
Eek part 2. Squeak 4.1 has ExpandedSourceFileArray so I need to substitute the read-only copy code.
On Wed, May 19, 2010 at 12:05 PM, Eliot Miranda eliot.miranda@gmail.comwrote:
Hi All,
I'm a bit late to this party but I just had cause to condense changesin an image but wanted to retain most version history. By most I mean I want to retain the linear history (a method's direct ancestor versions), not the full history including reversions. So if one has a set of stamps like eem 7/7/2009 20:06 7 July 2009 8:06 pm eem 6/18/2009 19:21 18 June 2009 7:21 pm eem 5/5/2009 12:16 5 May 2009 12:16 pm eem 6/18/2009 19:19 18 June 2009 7:19 pm eem 6/18/2009 18:57 18 June 2009 6:57 pm eem 5/5/2009 12:16 5 May 2009 12:16 pm eem 6/18/2009 18:17 18 June 2009 6:17 pm eem 6/18/2009 18:14 18 June 2009 6:14 pm eem 6/18/2009 18:06 18 June 2009 6:06 pm eem 5/5/2009 12:16 5 May 2009 12:16 pm eem 5/4/2009 19:19 4 May 2009 7:19 pm the direct ancestry is eem 7/7/2009 20:06 7 July 2009 8:06 pm eem 6/18/2009 19:21 18 June 2009 7:21 pm eem 5/5/2009 12:16 5 May 2009 12:16 pm eem 5/4/2009 19:19 4 May 2009 7:19 pm
This probably isn't useful as the default condense changes mechanism but its probably useful to a few of you, so here it is. The first change set provides shared read-only copies of the sources files for faster version scanning. The second change set provides the code to extract the direct ancestry and a hack in ClassDescription>>fileOutChangedMessages:on:moveSource:toFile: to force use of ClassDescription>>printMethodChunkHistorically:on:moveSource:toFile: when condensing. If y'all think this is generally useful we can make "condense preserving history" an option alongside condenseChanges, condenseSources et al.
HTH Eliot
On Wed, Mar 31, 2010 at 11:34 PM, Andreas Raab andreas.raab@gmx.dewrote:
Hi -
I just posted the code condensing sources in 4.1. It looks like it works fine; if anyone wants to try it (in a throwaway image please!) run it via:
Smalltalk appendChangesTo: 'mytest.sources'.This will copy the old sources, append the condensed changes and run the image with the new sources file. Everything should continue to work as is, but method histories should show both, the latest 4.1 version and the original 4.0 version (but not the intermediates).
Cheers,
- Andreas
On 3/29/2010 1:59 PM, Andreas Raab wrote:
Hi -
I just wanted to float an idea that Eliot came up with over lunch. He pointed out that it would be good if we could preserve the method history from 4.0 but that it also would be good if we could ship with an empty changes file. Both of which can be achieved if we'd be condensing the changes file *to the end of* the sources file, i.e,
SqueakV41.source = SqueakV4.sources + Squeak4.1.changes
This has some advantages besides the empty changes file. It allows us to keep up with the intermediate stages during the RCs. In other words, for the next RC I can make a SqueakV41.sources and the image will be "compatible" with later versions of the sources file. In fact, SqueakV41.sources would be compatible with with SqueakV40.sources, too, so you could link the old sources file to the new one to save space if desired.
What do people think? Sounds like a plan?
Cheers,
- Andreas
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Chris Muller -
David T. Lewis -
Eliot Miranda -
John M McIntosh -
Nicolas Cellier