New Spur trunk image available
Hi All, finally the Spur Squeak trunk image is updateable. The image in http://www.mirandabanda.org/files/Cog/SpurImages/2014-10-16/ was created today and thanks to Bert Freudenberg's latest Monticello work can be updated independently of the non-Spur trunk. Spur VMs are available in http://www.mirandabanda.org/files/Cog/VM/VM.r3105/ (and later as they appear). Without wanting to appear too overconfident the Spur system looks to be ready for use apart from image segments (which I hope to have working some time next month). I'm really interested in having this stress tested by as many people as possible. Spur really does offer a significant performance and functionality improvement over the current system, but it needs testing to ensure its reliability. Esteban Lorenzano is hard at work on the Pharo bootstrap for Spur so I hope Pharo 4 Spur will be available soon. As far as trunk goes, using Spur alongside non-Spur trunk is going to be difficult to manage for the near future. Right now, Spur modifies the Collections, Compiler, Kernel and System packages, and this is done by auto-editing the non-Spur versions of those packages, something I do periodically as new versions arrive. I also auto-edit trunk configurations (the part of the image update scheme that ensures packages are loaded in the right order when there are dependencies between packages) from non-Spur "update" to Spur "update.spur" forms. This at east means that Spur can keep up with trunk. But it does /not/ provide a way of committing to Collections.spur, Compiler.spur, Kernel.spur or System.spur without getting out of sync with non-Spur trunk. Note that apart from these packages, one /can/ safely commit any other package from a Spur image to trunk. Right now the plan is to release both V3 (the pre-Spur format) and Spur versions of Squeak 4.6 (I hope it'll be called Squeak 5.0). This isn't my preference. I'd like to see just Spur released, once reliability is verified. But I understand the safety and backward-compatibility concerns (Spur won't be able to load V3 image segments, and vice verse). The issue is of course that we have this tricky package situation to manage where, to keep the two systems in sync, modifications to Collections, Compiler, Kernel and System need to be committed from V3 and auto-edited to Spur. I think that's too clumsy to be practicable. Perhaps allowing the two systems to fork and doing a manual merge will be acceptable, but it'll be work to keep them in sync. -- best, Eliot
On Thu, 16 Oct 2014, Eliot Miranda wrote:
Hi All,   finally the Spur Squeak trunk image is updateable. The image in http://www.mirandabanda.org/files/Cog/SpurImages/2014-10-16/ was created today and thanks to Bert Freudenberg's latest Monticello work can be updated independently of the non-Spur trunk. Spur VMs are available in http://www.mirandabanda.org/files/Cog/VM/VM.r3105/ (and later as they appear). Without wanting to appear too overconfident the Spur system looks to be ready for use apart from image segments (which I hope to have working some time next month). I'm really interested in having this stress tested by as many people as possible. Spur really does offer a significant performance and functionality improvement over the current system, but it needs testing to ensure its reliability.
Great news.
Esteban Lorenzano is hard at work on the Pharo bootstrap for Spur so I hope Pharo 4 Spur will be available soon.
As far as trunk goes, using Spur alongside non-Spur trunk is going to be difficult to manage for the near future. Right now, Spur modifies the Collections, Compiler, Kernel and System packages, and this is done by auto-editing the non-Spur versions of those packages, something I do periodically as new versions arrive. I also auto-edit trunk configurations (the part of the image update scheme that ensures packages are loaded in the right order when there are dependencies between packages) from non-Spur "update" to Spur "update.spur" forms. This at east means that Spur can keep up with trunk. But it does /not/ provide a way of committing to Collections.spur, Compiler.spur, Kernel.spur or System.spur without getting out of sync with non-Spur trunk. Note that apart from these packages, one /can/ safely commit any other package from a Spur image to trunk.
Right now the plan is to release both V3 (the pre-Spur format) and Spur versions of Squeak 4.6 (I hope it'll be called Squeak 5.0). This isn't my preference. I'd like to see just Spur released, once reliability is verified. But I understand the safety and backward-compatibility concerns (Spur won't be able to load V3 image segments, and vice verse). The issue is of course that we have this tricky package situation to manage where, to keep the two systems in sync, modifications to Collections, Compiler, Kernel and System need to be committed from V3 and auto-edited to Spur. I think that's too clumsy to be practicable. Perhaps allowing the two systems to fork and doing a manual merge will be acceptable, but it'll be work to keep them in sync.
How about releasing the V3 version as Squeak 4.6, and the Spur version as Squeak 5.0 at the same time? This way we could keep Trunk as is; pushing all changes to Trunk until 4.6 is released, then - leaving V3 behind - use the Trunk for Spur-only. Then any changes could be backported manually to the future squeak46 repository if needed. Levente
-- best,Eliot
Hi Levente, On Oct 17, 2014, at 5:40 AM, Levente Uzonyi <leves@elte.hu> wrote:
On Thu, 16 Oct 2014, Eliot Miranda wrote:
Hi All, finally the Spur Squeak trunk image is updateable. The image in http://www.mirandabanda.org/files/Cog/SpurImages/2014-10-16/ was created today and thanks to Bert Freudenberg's latest Monticello work can be updated independently of the non-Spur trunk. Spur VMs are available in http://www.mirandabanda.org/files/Cog/VM/VM.r3105/ (and later as they appear). Without wanting to appear too overconfident the Spur system looks to be ready for use apart from image segments (which I hope to have working some time next month). I'm really interested in having this stress tested by as many people as possible. Spur really does offer a significant performance and functionality improvement over the current system, but it needs testing to ensure its reliability.
Great news.
Esteban Lorenzano is hard at work on the Pharo bootstrap for Spur so I hope Pharo 4 Spur will be available soon. As far as trunk goes, using Spur alongside non-Spur trunk is going to be difficult to manage for the near future. Right now, Spur modifies the Collections, Compiler, Kernel and System packages, and this is done by auto-editing the non-Spur versions of those packages, something I do periodically as new versions arrive. I also auto-edit trunk configurations (the part of the image update scheme that ensures packages are loaded in the right order when there are dependencies between packages) from non-Spur "update" to Spur "update.spur" forms. This at east means that Spur can keep up with trunk. But it does /not/ provide a way of committing to Collections.spur, Compiler.spur, Kernel.spur or System.spur without getting out of sync with non-Spur trunk. Note that apart from these packages, one /can/ safely commit any other package from a Spur image to trunk. Right now the plan is to release both V3 (the pre-Spur format) and Spur versions of Squeak 4.6 (I hope it'll be called Squeak 5.0). This isn't my preference. I'd like to see just Spur released, once reliability is verified. But I understand the safety and backward-compatibility concerns (Spur won't be able to load V3 image segments, and vice verse). The issue is of course that we have this tricky package situation to manage where, to keep the two systems in sync, modifications to Collections, Compiler, Kernel and System need to be committed from V3 and auto-edited to Spur. I think that's too clumsy to be practicable. Perhaps allowing the two systems to fork and doing a manual merge will be acceptable, but it'll be work to keep them in sync.
How about releasing the V3 version as Squeak 4.6, and the Spur version as Squeak 5.0 at the same time? This way we could keep Trunk as is; pushing all changes to Trunk until 4.6 is released, then - leaving V3 behind - use the Trunk for Spur-only. Then any changes could be backported manually to the future squeak46 repository if needed.
Works for me. Good idea! Objections?
Levente
-- best,Eliot
Eliot (phone)
How about releasing the V3 version as Squeak 4.6, and the Spur version as Squeak 5.0 at the same time?
Yes, that's the way to go! They (4.6 and 5.0) should be "equivalent" with each other -- Everything other than the VM and new restrictions (i.e., 64K restriction) would be the same. That way external apps can "port" to being Spur-compatible without worrying about any other functionality gaps between the two images causing problems.
This way we could keep Trunk as is; pushing all changes to Trunk until 4.6 is released, then - leaving V3 behind - use the Trunk for Spur-only. Then any changes could be backported manually to the future squeak46 repository if needed.
Yip.
Levente
-- best,Eliot
Thanks to all of you Le 17/10/2014 08:51, Eliot Miranda a écrit :
finally the Spur Squeak trunk image is updateable. The image in http://www.mirandabanda.org/files/Cog/SpurImages/2014-10-16/ was created today and thanks to Bert Freudenberg's latest Monticello work can be updated independently of the non-Spur trunk. Spur VMs are available in http://www.mirandabanda.org/files/Cog/VM/VM.r3105/ (and
-- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
participants (4)
-
Chris Muller -
Eliot Miranda -
Hilaire -
Levente Uzonyi