Update stream transition
Locked
 
|
I would like to confirm my understanding of what will happen in the trunk
update stream as we make the transition to Spur image format in Squeak 5.0. We currently have the trunk update stream, which is governed by update maps called 'update' in the source.squeak.org/trunk repository. This update stream is applicable to Squeak images up to the initial release of the Squeak 4.6 image. These are images in the non-Spur image formats (6504 or 6505 for 32-bit images, and 68002 for a 64-bit image). During the development period leading up to Squeak 5.0, which uses the new Spur image (format number 6521 for the 32-bit Spur image), the update stream has been governed by update maps called 'update.spur' in source.squeak.org/trunk. For Squeak 5.0, the update stream will continue to be governed by update maps called 'update' in the source.squeak.org/trunk repository. Users of Squeak 5.0 will see a normal trunk update stream from that point forward, and will now be using the Spur image format. For Squeak 4.6, the update stream will continue to be called 'update', but will now be in the source.squeak.org/squeak46 repository. These update maps are not yet in the squeak46 repository, but will be added as required. The Squeak 4.6 release image points to this update stream. An effort will be made to keep the squeak46 update stream in sync with trunk through the next Squeak release cycle. For an existing trunk image, such as a Squeak 4.5 image that has been kept up to date with the trunk, it will be necessary to switch from source.squeak.org/trunk with update map name 'update', to a new setting of source.squeak.org/squeak46 with update map name 'update', This change must be made more or less concurrently with the Squeak 5.0 release. Questions: 1) Is the above summary correct? 2) Is it possible for the trunk update stream to force an existing trunk image (originating from Squeak 4.5 or earlier) to switch over to the squeak46 repository automatically, such that updates can proceed without loading Spur-specific changes into a non-Spur trunk image? 3) Previously, the release-specific repository (e.g. source.squeak.org/squeak45 for Squeak 4.5) was used for applying a few important fixes to a stable release. Assuming that this is also the intent for Squeak 4.6, and that we also want to make an effort to permit non-Spur images to stay in sync with trunk for some period of time (nominally one release cycle), then would it be helpful to consider providing a trunk-compatible update stream for non-Spur images during the transition period? I am not sure how that should work (possibly something involving an 'update.classic' update map), but I would like to know if conceptually it is something we should be trying to do. Thanks, Dave |
|
|
> We currently have the trunk update stream, which is governed by update maps
> called 'update' in the source.squeak.org/trunk repository. This update > stream is applicable to Squeak images up to the initial release of the > Squeak 4.6 image. These are images in the non-Spur image formats (6504 > or 6505 for 32-bit images, and 68002 for a 64-bit image). The .spur branch has already been collapsed onto trunk. There is no way to advance a non-spur image except through commits to the release repositories (e.g., 'squea46'). > During the development period leading up to Squeak 5.0, which uses the > new Spur image (format number 6521 for the 32-bit Spur image), the > update stream has been governed by update maps called 'update.spur' in > source.squeak.org/trunk. > > For Squeak 5.0, the update stream will continue to be governed by update > maps called 'update' in the source.squeak.org/trunk repository. Users of > Squeak 5.0 will see a normal trunk update stream from that point forward, > and will now be using the Spur image format. Yes. > For Squeak 4.6, the update stream will continue to be called 'update', > but will now be in the source.squeak.org/squeak46 repository. These update > maps are not yet in the squeak46 repository, I just made the first one in 'squeak46'. > but will be added as required. > The Squeak 4.6 release image points to this update stream. An effort will > be made to keep the squeak46 update stream in sync with trunk through the > next Squeak release cycle. Oh really, who is going to do that? > For an existing trunk image, such as a Squeak 4.5 image that has been kept > up to date with the trunk, it will be necessary to switch from > source.squeak.org/trunk with update map name 'update', to a new setting > of source.squeak.org/squeak46 with update map name 'update', This change > must be made more or less concurrently with the Squeak 5.0 release. > > Questions: > > 1) Is the above summary correct? > > 2) Is it possible for the trunk update stream to force an existing trunk > image (originating from Squeak 4.5 or earlier) to switch over to the squeak46 > repository automatically, such that updates can proceed without loading > Spur-specific changes into a non-Spur trunk image? You would need to make sure not to update past update-topa.322.mcm. Probably the code is not set up to do a limited updated. No, you have to update the updateURL in Preferences. > 3) Previously, the release-specific repository (e.g. source.squeak.org/squeak45 > for Squeak 4.5) was used for applying a few important fixes to a stable > release. Assuming that this is also the intent for Squeak 4.6, and that we > also want to make an effort to permit non-Spur images to stay in sync with > trunk for some period of time (nominally one release cycle), then would it > be helpful to consider providing a trunk-compatible update stream for non-Spur > images during the transition period? I am not sure how that should work > (possibly something involving an 'update.classic' update map), but I would > like to know if conceptually it is something we should be trying to do. Basically you are talking about a fork of Squeak. Unless someone has some kind of compatibility issue with their application, I don't know why anyone would want to expend resources maintaining an old fork.. |
|
|
2015-08-06 16:47 GMT+02:00 Chris Muller <[hidden email]>: > We currently have the trunk update stream, which is governed by update maps Hi, FYI, I advanced the non spur with attached snippet (nothing really clever). Cheers |
Update_up_to_spur.text (1K) |
|
In reply to this post by Chris Muller-3
On Thu, Aug 06, 2015 at 09:47:46AM -0500, Chris Muller wrote:
> > We currently have the trunk update stream, which is governed by update maps > > called 'update' in the source.squeak.org/trunk repository. This update > > stream is applicable to Squeak images up to the initial release of the > > Squeak 4.6 image. These are images in the non-Spur image formats (6504 > > or 6505 for 32-bit images, and 68002 for a 64-bit image). > > The .spur branch has already been collapsed onto trunk. There is no > way to advance a non-spur image except through commits to the release > repositories (e.g., 'squea46'). > > > During the development period leading up to Squeak 5.0, which uses the > > new Spur image (format number 6521 for the 32-bit Spur image), the > > update stream has been governed by update maps called 'update.spur' in > > source.squeak.org/trunk. > > > > For Squeak 5.0, the update stream will continue to be governed by update > > maps called 'update' in the source.squeak.org/trunk repository. Users of > > Squeak 5.0 will see a normal trunk update stream from that point forward, > > and will now be using the Spur image format. > > Yes. > > > For Squeak 4.6, the update stream will continue to be called 'update', > > but will now be in the source.squeak.org/squeak46 repository. These update > > maps are not yet in the squeak46 repository, > > I just made the first one in 'squeak46'. > > > but will be added as required. > > The Squeak 4.6 release image points to this update stream. An effort will > > be made to keep the squeak46 update stream in sync with trunk through the > > next Squeak release cycle. > > Oh really, who is going to do that? > I fully understand that nothing gets done unless someone actually puts in the effort to do it. Within reasonable limits, this is something that I am willing to work on through the course of the next release cycle. I am expecting that this means 6 to 12 months, depending on how long it takes to go through another release cycle. My assumptions were, and still are, as follows: 1) We are moving the main trunk development to the new Spur image format for Squeak 5.0. This is not a reversible change. Some things may break, but we are going to make it work and we are going to make it successful. 2) We will attempt to do this during a transition period of one release cycle (whatever that might turn out to be). This allows us to learn during the transition period, and to work out any unanticipated problems. During that time period, we will make an effort to keep the classic image format (Squeak 4.6) healthy. My own assumption is that this should include a working update stream. 3) We will not rely on Eliot to do all the work. Once we get to Squeak 5.0 with Spur, other people (such as me) need to step forward if any backward compatibility with non-Spur images is going to be maintained. If nobody does it, then it will not get done. Hopefully these are reasonable objectives, and from my point of view I will be happy to put some time and effort into objective #3 in the coming months. Having said that, I do not actually know *how* to maintain an update stream for 4.6 to track the main trunk 5.0 stream. Dave > > For an existing trunk image, such as a Squeak 4.5 image that has been kept > > up to date with the trunk, it will be necessary to switch from > > source.squeak.org/trunk with update map name 'update', to a new setting > > of source.squeak.org/squeak46 with update map name 'update', This change > > must be made more or less concurrently with the Squeak 5.0 release. > > > > Questions: > > > > 1) Is the above summary correct? > > > > 2) Is it possible for the trunk update stream to force an existing trunk > > image (originating from Squeak 4.5 or earlier) to switch over to the squeak46 > > repository automatically, such that updates can proceed without loading > > Spur-specific changes into a non-Spur trunk image? > > You would need to make sure not to update past update-topa.322.mcm. > Probably the code is not set up to do a limited updated. > > No, you have to update the updateURL in Preferences. > > > 3) Previously, the release-specific repository (e.g. source.squeak.org/squeak45 > > for Squeak 4.5) was used for applying a few important fixes to a stable > > release. Assuming that this is also the intent for Squeak 4.6, and that we > > also want to make an effort to permit non-Spur images to stay in sync with > > trunk for some period of time (nominally one release cycle), then would it > > be helpful to consider providing a trunk-compatible update stream for non-Spur > > images during the transition period? I am not sure how that should work > > (possibly something involving an 'update.classic' update map), but I would > > like to know if conceptually it is something we should be trying to do. > > Basically you are talking about a fork of Squeak. Unless someone has > some kind of compatibility issue with their application, I don't know > why anyone would want to expend resources maintaining an old fork.. |
Re: Update stream transition
|
|
Hi Dave,
I'm afraid it would be rather difficult to backport all changes to 4.6. The changes made by the Spur bootstrap would have to be reverted (Compiler, Collections, Kernel, System packages) along with all Spur-specific optimizations (e.g. #become:, immediate characters, etc) in future changes. Levente On Mon, 10 Aug 2015, David T. Lewis wrote: > On Thu, Aug 06, 2015 at 09:47:46AM -0500, Chris Muller wrote: >>> We currently have the trunk update stream, which is governed by update maps >>> called 'update' in the source.squeak.org/trunk repository. This update >>> stream is applicable to Squeak images up to the initial release of the >>> Squeak 4.6 image. These are images in the non-Spur image formats (6504 >>> or 6505 for 32-bit images, and 68002 for a 64-bit image). >> >> The .spur branch has already been collapsed onto trunk. There is no >> way to advance a non-spur image except through commits to the release >> repositories (e.g., 'squea46'). >> >>> During the development period leading up to Squeak 5.0, which uses the >>> new Spur image (format number 6521 for the 32-bit Spur image), the >>> update stream has been governed by update maps called 'update.spur' in >>> source.squeak.org/trunk. >>> >>> For Squeak 5.0, the update stream will continue to be governed by update >>> maps called 'update' in the source.squeak.org/trunk repository. Users of >>> Squeak 5.0 will see a normal trunk update stream from that point forward, >>> and will now be using the Spur image format. >> >> Yes. >> >>> For Squeak 4.6, the update stream will continue to be called 'update', >>> but will now be in the source.squeak.org/squeak46 repository. These update >>> maps are not yet in the squeak46 repository, >> >> I just made the first one in 'squeak46'. >> >>> but will be added as required. >>> The Squeak 4.6 release image points to this update stream. An effort will >>> be made to keep the squeak46 update stream in sync with trunk through the >>> next Squeak release cycle. >> >> Oh really, who is going to do that? >> > > I fully understand that nothing gets done unless someone actually puts > in the effort to do it. Within reasonable limits, this is something that > I am willing to work on through the course of the next release cycle. I > am expecting that this means 6 to 12 months, depending on how long it takes > to go through another release cycle. > > My assumptions were, and still are, as follows: > > 1) We are moving the main trunk development to the new Spur image format > for Squeak 5.0. This is not a reversible change. Some things may break, > but we are going to make it work and we are going to make it successful. > > 2) We will attempt to do this during a transition period of one release > cycle (whatever that might turn out to be). This allows us to learn > during the transition period, and to work out any unanticipated problems. > During that time period, we will make an effort to keep the classic image > format (Squeak 4.6) healthy. My own assumption is that this should include > a working update stream. > > 3) We will not rely on Eliot to do all the work. Once we get to Squeak > 5.0 with Spur, other people (such as me) need to step forward if any > backward compatibility with non-Spur images is going to be maintained. > If nobody does it, then it will not get done. > > Hopefully these are reasonable objectives, and from my point of view > I will be happy to put some time and effort into objective #3 in the > coming months. > > Having said that, I do not actually know *how* to maintain an update > stream for 4.6 to track the main trunk 5.0 stream. > > Dave > > > >>> For an existing trunk image, such as a Squeak 4.5 image that has been kept >>> up to date with the trunk, it will be necessary to switch from >>> source.squeak.org/trunk with update map name 'update', to a new setting >>> of source.squeak.org/squeak46 with update map name 'update', This change >>> must be made more or less concurrently with the Squeak 5.0 release. >>> >>> Questions: >>> >>> 1) Is the above summary correct? >>> >>> 2) Is it possible for the trunk update stream to force an existing trunk >>> image (originating from Squeak 4.5 or earlier) to switch over to the squeak46 >>> repository automatically, such that updates can proceed without loading >>> Spur-specific changes into a non-Spur trunk image? >> >> You would need to make sure not to update past update-topa.322.mcm. >> Probably the code is not set up to do a limited updated. >> >> No, you have to update the updateURL in Preferences. >> >>> 3) Previously, the release-specific repository (e.g. source.squeak.org/squeak45 >>> for Squeak 4.5) was used for applying a few important fixes to a stable >>> release. Assuming that this is also the intent for Squeak 4.6, and that we >>> also want to make an effort to permit non-Spur images to stay in sync with >>> trunk for some period of time (nominally one release cycle), then would it >>> be helpful to consider providing a trunk-compatible update stream for non-Spur >>> images during the transition period? I am not sure how that should work >>> (possibly something involving an 'update.classic' update map), but I would >>> like to know if conceptually it is something we should be trying to do. >> >> Basically you are talking about a fork of Squeak. Unless someone has >> some kind of compatibility issue with their application, I don't know >> why anyone would want to expend resources maintaining an old fork.. > > |
|
|
On Wed, Aug 12, 2015 at 11:11 AM, Levente Uzonyi <[hidden email]> wrote: Hi Dave, Right. Some of this can be automated as long as the differences between the two systems are trivial. But soon enough the gulf will be too far because the differences will be in larger semantic units (for example a rewriting of finalization support to use Ephemerons could cause significant changes to the way file streams are finalized) and at that point automatic back-port will be impossible. I think a much more fruitful direction is to work on developing an up-to-date Interpreter in VMMaker.oscog that can hence be mated to both the V3 memory manager and the Spur one.
_,,,^..^,,,_ best, Eliot |
|
|
In reply to this post by Nicolas Cellier
Currently we have the problem that an existing trunk image from prior
to the Squeak 4.6 release will lock up if the user does a normal "update from server". A knowledgeable user can work around this, as with the script that Nicolas provides. But a year from now our tribal knowledge is likely to dissipate, so I don't really like the idea of having the original trunk update stream end in a frozen image. I think I have come up with a way to have the update stream switch automatically from trunk to squeak46 for existing images, see attached change set. The idea is to add this class into a separate package "Temp-update-strean-migration" in the trunk repository, and add that package to the last update map that worked for V3 images (I think this is update-eem.321.mcm, is that right?). The package loads a class that checks to see if the image needs to be switched from trunk to squeak46, and changes the update preference accordingly. It then removes itself from the system. Does this seem reasonable? Dave On Thu, Aug 06, 2015 at 10:24:31PM +0200, Nicolas Cellier wrote: > 2015-08-06 16:47 GMT+02:00 Chris Muller <[hidden email]>: > > > > We currently have the trunk update stream, which is governed by update > > maps > > > called 'update' in the source.squeak.org/trunk repository. This update > > > stream is applicable to Squeak images up to the initial release of the > > > Squeak 4.6 image. These are images in the non-Spur image formats (6504 > > > or 6505 for 32-bit images, and 68002 for a 64-bit image). > > > > The .spur branch has already been collapsed onto trunk. There is no > > way to advance a non-spur image except through commits to the release > > repositories (e.g., 'squea46'). > > > > > Hi, > > FYI, I advanced the non spur with attached snippet (nothing really clever). > > Cheers > "update to latest cog version but not spur..." | url repository updateList updater lastUpdateMap config | url := MCMcmUpdater defaultUpdateURL. repository := MCRepositoryGroup default repositories detect:[:r| r description = url] ifNone:[ | r | r := MCHttpRepository location: url user: '' password: ''. MCRepositoryGroup default addRepository: r. r]. updater := [MCMcmUpdater default] ifError: [MCMcmUpdater]. lastUpdateMap := [updater lastUpdateMap] ifError: [MCMcmUpdater classPool at: #LastUpdateMap]. updateList := updater updateListFor: repository. updateList := updateList select: [:e | e key < 323]. updateList := updater refreshUpdateMapFor: repository with: updateList. updateList do:[:assoc| ProgressNotification signal: '' extra: 'Processing ', assoc value. config := repository versionNamed: assoc value. updater updateFromConfig: config. lastUpdateMap at: repository description put: assoc key. ] displayingProgress: 'Processing configurations'. config ifNil: [^updater inform: 'Unable to retrieve updates from remote repository.' translated]. config setSystemVersion. updater inform: ('Update completed. Current update number: ' translated, SystemVersion current highestUpdate). > |
|
|
Hi David,
Sent from my iPhone > On Aug 22, 2015, at 7:15 AM, David T. Lewis <[hidden email]> wrote: > > Currently we have the problem that an existing trunk image from prior > to the Squeak 4.6 release will lock up if the user does a normal > "update from server". A knowledgeable user can work around this, as > with the script that Nicolas provides. But a year from now our tribal > knowledge is likely to dissipate, so I don't really like the idea of > having the original trunk update stream end in a frozen image. > > I think I have come up with a way to have the update stream switch > automatically from trunk to squeak46 for existing images, see attached > change set. The idea is to add this class into a separate package > "Temp-update-strean-migration" in the trunk repository, and add that > package to the last update map that worked for V3 images (I think this > is update-eem.321.mcm, is that right?). The package loads a class that > checks to see if the image needs to be switched from trunk to squeak46, > and changes the update preference accordingly. It then removes itself > from the system. > > Does this seem reasonable? Oh yes! Looks a v good idea. The only thing I could think of was adding a preamble to trunk Kernel & System to have them error on non Sour. But your proposal above is /much/ better. > > Dave > > > >> On Thu, Aug 06, 2015 at 10:24:31PM +0200, Nicolas Cellier wrote: >> 2015-08-06 16:47 GMT+02:00 Chris Muller <[hidden email]>: >> >>>> We currently have the trunk update stream, which is governed by update >>> maps >>>> called 'update' in the source.squeak.org/trunk repository. This update >>>> stream is applicable to Squeak images up to the initial release of the >>>> Squeak 4.6 image. These are images in the non-Spur image formats (6504 >>>> or 6505 for 32-bit images, and 68002 for a 64-bit image). >>> >>> The .spur branch has already been collapsed onto trunk. There is no >>> way to advance a non-spur image except through commits to the release >>> repositories (e.g., 'squea46'). >> Hi, >> >> FYI, I advanced the non spur with attached snippet (nothing really clever). >> >> Cheers > >> "update to latest cog version but not spur..." > > | url repository updateList updater lastUpdateMap config | > url := MCMcmUpdater defaultUpdateURL. > repository := MCRepositoryGroup default repositories > detect:[:r| r description = url] > ifNone:[ | r | > r := MCHttpRepository location: url user: '' password: ''. > MCRepositoryGroup default addRepository: r. > r]. > updater := [MCMcmUpdater default] ifError: [MCMcmUpdater]. > lastUpdateMap := [updater lastUpdateMap] ifError: [MCMcmUpdater classPool at: #LastUpdateMap]. > updateList := updater updateListFor: repository. > updateList := updateList select: [:e | e key < 323]. > updateList := updater refreshUpdateMapFor: repository with: updateList. > updateList do:[:assoc| > ProgressNotification signal: '' extra: 'Processing ', assoc value. > config := repository versionNamed: assoc value. > updater updateFromConfig: config. > lastUpdateMap at: repository description put: assoc key. > ] displayingProgress: 'Processing configurations'. > config ifNil: [^updater inform: 'Unable to retrieve updates from remote repository.' translated]. > config setSystemVersion. > updater inform: ('Update completed. > Current update number: ' translated, SystemVersion current highestUpdate). > > <MoveTrunkEndToSqueak46RepoForV3Images-dtl.2.cs> > |
|
|
"Sour"- pre Spur Squeak ;-) Karl On Sat, Aug 22, 2015 at 5:12 PM, Eliot Miranda <[hidden email]> wrote: Hi David, |
|
|
On Sat, Aug 22, 2015 at 9:15 AM, karl ramberg <[hidden email]> wrote:
I know :-/. I make that typo all the time, o and p being right next to each other on my qwerty kbd. Forgive me!
_,,,^..^,,,_ best, Eliot |
|
|
I was just noticing the pun :-) On Sat, Aug 22, 2015 at 7:15 PM, Eliot Miranda <[hidden email]> wrote:
|
|
|
In reply to this post by Eliot Miranda-2
On Sat, Aug 22, 2015 at 08:12:40AM -0700, Eliot Miranda wrote:
> Hi David, > > Sent from my iPhone > > > On Aug 22, 2015, at 7:15 AM, David T. Lewis <[hidden email]> wrote: > > > > Currently we have the problem that an existing trunk image from prior > > to the Squeak 4.6 release will lock up if the user does a normal > > "update from server". A knowledgeable user can work around this, as > > with the script that Nicolas provides. But a year from now our tribal > > knowledge is likely to dissipate, so I don't really like the idea of > > having the original trunk update stream end in a frozen image. > > > > I think I have come up with a way to have the update stream switch > > automatically from trunk to squeak46 for existing images, see attached > > change set. The idea is to add this class into a separate package > > "Temp-update-strean-migration" in the trunk repository, and add that > > package to the last update map that worked for V3 images (I think this > > is update-eem.321.mcm, is that right?). The package loads a class that > > checks to see if the image needs to be switched from trunk to squeak46, > > and changes the update preference accordingly. It then removes itself > > from the system. > > > > Does this seem reasonable? > > Oh yes! Looks a v good idea. The only thing I could think of was adding a preamble to trunk Kernel & System to have them error on non Sour. But your proposal above is /much/ better. > This seemed like a good idea, but I tried it and unfortunately it does not work. There are two problems with this approach: 1) The updater does not load the new (temporary) package, because it will not load anything that does not already have a working copy in the image. So just adding the new package to the update map did not cause it to be loaded. 2) Changing the update preference is not sufficient to change an update that is already in progress, because it will already have loaded the list of updates that it expects to process (including the spur ones). So even if #1 had worked, it still would not have prevented the update from proceeding, which still would end in an error (32-bit image) or image freeze (64-bit image). So ... sorry for the noise. I will try to think of a better approach. I will also delete Temp-update-stream-migration-dtl.1 from trunk and remove the dependency for it that I had added to the update-topa.322.mcm configuration map. Back to the drawing board :-/ Dave |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |