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.
Hi Eliot. I will make time to install Spur (assuming it's presently working on the Mac.) I'll use it as my primary VM unless I run into problems, in which case I will report them.
I think I understood you, but I want to be clear; you're saying that (like Cog) changes needed to be made to the image to support the new VM.
Query: can the Interpreter (either that or Stack) VM be modified to support images which run above Spur? Or is this necessarily a forking event? (CC Cuis folks.)
Query: should incorporating the changes to the image that you have outlined below into Cuis allow Cuis to make use of the new VM? (I perhaps am digging very vaguely into what those changes are. Sorry I'm not presently equipped to ask smarter questions: I'm probably just beside myself with enthusiasm for your work and perchance "jumping the gun" a bit.)
TIA,
Casey
P.S.
Please forgive the pun, if you noticed it! :D
On Oct 16, 2014, at 11:51 PM, Eliot Miranda eliot.miranda@gmail.com 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.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
Hi Casey,
On Oct 17, 2014, at 12:37 AM, Casey Ransberger casey.obrien.r@gmail.com wrote:
Hi Eliot. I will make time to install Spur (assuming it's presently working on the Mac.) I'll use it as my primary VM unless I run into problems, in which case I will report them.
Yes, I build Spur VMs alongside Cog VMs, so they're available for Mac, x86 Windows and x86 linux. (and soon stack VMs for ARM linux).
And thank you, both for using it and for these great questions.
I think I understood you, but I want to be clear; you're saying that (like Cog) changes needed to be made to the image to support the new VM.
In this case more like to exploit the new VM. So 32-bit Spur has immediate characters alongside immediate SmallIntegers, and 64-bit Spur will add immediate floats. Spur has a 64k literal limit in methods vs 256 in V3 (pre-Spur). There are slightly different versions of Behavior>>new, new:, basicNew & basicNew: to marry with the new GC and segmented heap, and there are primitives for allInstances and allObjects. These are all benefits that could have been done without, but are clearly good and indeed the 64k literal limit exists in V3 Newspeak.
In fact, the 64k limit is also associated with support for two bytecode sets. And that leads to support for Sista, the adaptive optimizer we hope will be available later next year.
The necessary change is to add Behavior>>identityHash to ensure a class's identityHash is its index in the VM's class table. This is what keeps Spur objects relatively compact, and keeps their header uniform. i.e. every object's header contains its class's index in a 22-bit field instead of a direct reference to its class object.
Query: can the Interpreter (either that or Stack) VM be modified to support images which run above Spur? Or is this necessarily a forking event? (CC Cuis folks.)
Yes. Stack Spur VMs are easily generable from a VMMaker image. In fact Stack Spur was the first working version. But porting the context Interpreter means finishing the merge with trunk VMMaker for which the community (in the person of David Lewis and myself) have so few cycles (volunteers welcome, but they must be prepared to merge the Interpreter into the Cog branch, not the other way).
Query: should incorporating the changes to the image that you have outlined below into Cuis allow Cuis to make use of the new VM? (I perhaps am digging very vaguely into what those changes are. Sorry I'm not presently equipped to ask smarter questions: I'm probably just beside myself with enthusiasm for your work and perchance "jumping the gun" a bit.)
Yes. The bootstrap is written as an image editor. Adding support for Cuis should be straightforward, provided Cuis's compiler is brought close to trunk's (to support and exploit the 64k literal limit and multiple bytecode sets).
Anyone motivated to port Cuis should contact me to discuss and for me to show you around the code.
TIA,
Thanks. These questions have allowed me to clarify. But do you (or anyone else) have any opinions or concerns about the parallel development model for trunk I outlined?
Casey
P.S.
Please forgive the pun, if you noticed it! :D
I missed it :-/
Eliot (phone)
On Oct 16, 2014, at 11:51 PM, Eliot Miranda eliot.miranda@gmail.com 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.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
Hi Eliot, Casey,
Quoting Eliot Miranda eliot.miranda@gmail.com:
Hi Casey,
On Oct 17, 2014, at 12:37 AM, Casey Ransberger casey.obrien.r@gmail.com wrote:
Hi Eliot. I will make time to install Spur (assuming it's presently working on the Mac.) I'll use it as my primary VM unless I run into problems, in which case I will report them.
Yes, I build Spur VMs alongside Cog VMs, so they're available for Mac, x86 Windows and x86 linux. (and soon stack VMs for ARM linux). And thank you, both for using it and for these great questions.
I think I understood you, but I want to be clear; you're saying that (like Cog) changes needed to be made to the image to support the new VM.
In this case more like to exploit the new VM. So 32-bit Spur has immediate characters alongside immediate SmallIntegers, and 64-bit Spur will add immediate floats. Spur has a 64k literal limit in methods vs 256 in V3 (pre-Spur). There are slightly different versions of Behavior>>new, new:, basicNew & basicNew: to marry with the new GC and segmented heap, and there are primitives for allInstances and allObjects. These are all benefits that could have been done without, but are clearly good and indeed the 64k literal limit exists in V3 Newspeak. In fact, the 64k limit is also associated with support for two bytecode sets. And that leads to support for Sista, the adaptive optimizer we hope will be available later next year. The necessary change is to add Behavior>>identityHash to ensure a class's identityHash is its index in the VM's class table. This is what keeps Spur objects relatively compact, and keeps their header uniform. i.e. every object's header contains its class's index in a 22-bit field instead of a direct reference to its class object.
Thanks for all this detail. It will be really useful.
Query: can the Interpreter (either that or Stack) VM be modified to support images which run above Spur? Or is this necessarily a forking event? (CC Cuis folks.)
Yes. Stack Spur VMs are easily generable from a VMMaker image. In
fact
Stack Spur was the first working version. But porting the context Interpreter means finishing the merge with trunk VMMaker for which the community (in the person of David Lewis and myself) have so few cycles (volunteers welcome, but they must be prepared to merge the Interpreter into the Cog branch, not the other way).
WRT Stack Spur VM, this is indeed great news! It means that Cuis can adopt the Spur image format and continue to be fully multi-platform, without needing to maintain two active branchs. Yay!
WRT the context Interpreter, it would be nice to merge it, essentially to ease the landscape to contributors.
Query: should incorporating the changes to the image that you have outlined below into Cuis allow Cuis to make use of the new VM? (I perhaps am digging very vaguely into what those changes are. Sorry I'm not presently equipped to ask smarter questions: I'm probably just beside myself with enthusiasm for your work and perchance "jumping the gun" a bit.)
Yes. The bootstrap is written as an image editor. Adding support for Cuis should be straightforward, provided Cuis's compiler is brought close to trunk's (to support and exploit the 64k literal limit and multiple bytecode sets).
The Cuis compiler has always been close to Squeak's, especially after Cuis adopted Cog. (For the record, AFAIK, I was the only person, besides Eliot, to migrate a context Interpreter image to Cog. That was Cuis, of course.)
Eliot, after taking a look at the Spur bootstrap some months ago (haven't found time yet to make it work on Cuis), and reading this message of yours, I wonder, wouldn't it make sense to do just the essential (i.e. mandatory) changes (like Behavior>>identityHash, rehashing, image header, etc) in the bootstrap? Then do all the rest afterwards, after starting the image with a Spur VM. This should ease significantly adapting this second part to various Squeak images, and would encourage wider adoption by other projects. It would also ease keeing the Spur bootstrap updated, as the target images keep changing.
Anyone motivated to port Cuis should contact me to discuss and for me to show you around the code.
Thanks for the offer, Eliot. If nobody else in the Cuis community beats me to it (folks, you are welcome to do it!), I will. Right now all my spare cycles are devoted to advancing Morphic 3 (the pre-alpha code was released MIT recently). But I will have time to do this in maybe a month, and I will really appreciate your help.
TIA,
Thanks. These questions have allowed me to clarify. But do you (or anyone else) have any opinions or concerns about the parallel development model for trunk I outlined?
Casey P.S. Please forgive the pun, if you noticed it! :D
I missed it :-/Eliot (phone)
Thanks Eliot for the thoughtful answer, and thanks Casey for asking the questions.
Cheers, Juan Vuletich
On Oct 16, 2014, at 11:51 PM, Eliot Miranda eliot.miranda@gmail.com 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. 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
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 imagein 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
On Thu, Oct 16, 2014 at 11:51:20PM -0700, Eliot Miranda wrote:
Hi All,
finally the Spur Squeak trunk image is updateable.
Yay!
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.
When I look at the Spur related changes to these four large packages, it seems to me that we might be able to reduce the scope of the problem by moving the parts that require changes into separate packages or sub-packages. The portions of these packages that need to change are not insignificant, but if they were contained within well defined package boundaries, they might become simpler to manage.
To illustrate: The changes in the Collections package are almost entirely related to class Character, whose instances are immediate in the Spur format. It might make very good sense if the methods directly related to immediateness of a character were localized in a package where they can be maintained independently of all the other Collections classes and methods.
Looking at it from another angle, the Kernel package is arguably too large, and if I want to make changes to Kernel-Chronology (as I have recently been doing with UTCDateAndTime http://wiki.squeak.org/squeak/6197 just as an example), then I have problems if I want to coordinate that external package with Squeak trunk. If I also want to coordinate my little project with all the updates required for both Kernel and Kernel.spur, the situation becomes impossible.
I apologize in advance because I have not really thought this through in detail, but it seems to me that a bit of pragmatic reorganization of our package structure might make the Spur transition a lot easier to manage.
I note that in the past we have put energy into reorganizing our package structures in the interest of making the image more modular. That is important, but managing the transition to Spur is even more important. If improving the package structure could make this easier, then we should make it a priority.
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.
I agree. I also think that this kind of maintenance work is not enjoyable, and is not likely to be kept up on an ongoing basis. So we need to think of ways for the path forward to be A) enjoyable or B) not too much work or C) all of the above :-)
Dave
Hi David,
On Mon, Oct 20, 2014 at 6:35 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Oct 16, 2014 at 11:51:20PM -0700, Eliot Miranda wrote:
Hi All,
finally the Spur Squeak trunk image is updateable.Yay!
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.
When I look at the Spur related changes to these four large packages, it seems to me that we might be able to reduce the scope of the problem by moving the parts that require changes into separate packages or sub-packages. The portions of these packages that need to change are not insignificant, but if they were contained within well defined package boundaries, they might become simpler to manage.
To illustrate: The changes in the Collections package are almost entirely related to class Character, whose instances are immediate in the Spur format. It might make very good sense if the methods directly related to immediateness of a character were localized in a package where they can be maintained independently of all the other Collections classes and methods.
Looking at it from another angle, the Kernel package is arguably too large, and if I want to make changes to Kernel-Chronology (as I have recently been doing with UTCDateAndTime http://wiki.squeak.org/squeak/6197 just as an example), then I have problems if I want to coordinate that external package with Squeak trunk. If I also want to coordinate my little project with all the updates required for both Kernel and Kernel.spur, the situation becomes impossible.
I apologize in advance because I have not really thought this through in detail, but it seems to me that a bit of pragmatic reorganization of our package structure might make the Spur transition a lot easier to manage.
I note that in the past we have put energy into reorganizing our package structures in the interest of making the image more modular. That is important, but managing the transition to Spur is even more important. If improving the package structure could make this easier, then we should make it a priority.
While I'm happy to see packages decomposed I've chosen the approach to changing the four relevant packages Spur modifies for good reason. Essentially once we move to Spur I don't want there to be artifacts present which are simply to do with the change to Spur. So keeping Collections, Compiler, Kernel and System whole but in Spur-specific branches allows us to keep the system looking the same once we release it. Further, all the support for branching and editing these packages is now working and I'm really not keep on putting more effort into it to complicate it further. I've got lots of other things to do. So now that Spur works and is nearly ready for release can we let it be?
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.
I agree. I also think that this kind of maintenance work is not enjoyable, and is not likely to be kept up on an ongoing basis. So we need to think of ways for the path forward to be A) enjoyable or B) not too much work or C) all of the above :-)
Well, we should discuss what the release criteria are at the next board meeting. We may be able to release before the end of the year, which would be great.
On Mon, Oct 20, 2014 at 07:18:14PM -0700, Eliot Miranda wrote:
Hi David,
On Mon, Oct 20, 2014 at 6:35 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Oct 16, 2014 at 11:51:20PM -0700, Eliot Miranda wrote:
Hi All,
finally the Spur Squeak trunk image is updateable.Yay!
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.
When I look at the Spur related changes to these four large packages, it seems to me that we might be able to reduce the scope of the problem by moving the parts that require changes into separate packages or sub-packages. The portions of these packages that need to change are not insignificant, but if they were contained within well defined package boundaries, they might become simpler to manage.
To illustrate: The changes in the Collections package are almost entirely related to class Character, whose instances are immediate in the Spur format. It might make very good sense if the methods directly related to immediateness of a character were localized in a package where they can be maintained independently of all the other Collections classes and methods.
Looking at it from another angle, the Kernel package is arguably too large, and if I want to make changes to Kernel-Chronology (as I have recently been doing with UTCDateAndTime http://wiki.squeak.org/squeak/6197 just as an example), then I have problems if I want to coordinate that external package with Squeak trunk. If I also want to coordinate my little project with all the updates required for both Kernel and Kernel.spur, the situation becomes impossible.
I apologize in advance because I have not really thought this through in detail, but it seems to me that a bit of pragmatic reorganization of our package structure might make the Spur transition a lot easier to manage.
I note that in the past we have put energy into reorganizing our package structures in the interest of making the image more modular. That is important, but managing the transition to Spur is even more important. If improving the package structure could make this easier, then we should make it a priority.
While I'm happy to see packages decomposed I've chosen the approach to changing the four relevant packages Spur modifies for good reason. Essentially once we move to Spur I don't want there to be artifacts present which are simply to do with the change to Spur. So keeping Collections, Compiler, Kernel and System whole but in Spur-specific branches allows us to keep the system looking the same once we release it. Further, all the support for branching and editing these packages is now working and I'm really not keep on putting more effort into it to complicate it further. I've got lots of other things to do. So now that Spur works and is nearly ready for release can we let it be?
Yes, for sure. If it does not make things easier, let's not do it.
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.
I agree. I also think that this kind of maintenance work is not enjoyable, and is not likely to be kept up on an ongoing basis. So we need to think of ways for the path forward to be A) enjoyable or B) not too much work or C) all of the above :-)
Well, we should discuss what the release criteria are at the next board meeting. We may be able to release before the end of the year, which would be great.
Ok, good.
Dave
This is really great news. I tried it out with the latest CogSpur VM 3114 and the latest image from October 17th. When I update Squeak it runs into Merging Collections.spur-nice.583. I wonder what to do now? All Newer and Merge?
Cheers, Bernhard
Am 17.10.2014 um 08:51 schrieb Eliot Miranda eliot.miranda@gmail.com:
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 Sun, Oct 26, 2014 at 1:46 PM, Bernhard Pieber bernhard@pieber.com wrote:
This is really great news. I tried it out with the latest CogSpur VM 3114 and the latest image from October 17th. When I update Squeak it runs into Merging Collections.spur-nice.583. I wonder what to do now? All Newer and Merge?
Yes, and afterwards, if the dirty package bothers you, resolve the dirty package by manually loading the latest Spur version. This crap should be temporary. Once we release things will work out (no patching and multiple parents any more).
Cheers, Bernhard
Am 17.10.2014 um 08:51 schrieb Eliot Miranda eliot.miranda@gmail.com:
Hi All,
finally the Spur Squeak trunk image is updateable. The image inhttp://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
Hi Eliot,
Thanks for the tip. You are right, I like my Monticello packages clean. ;-) I loaded Collections.spur-cmm.585. All clean now. I am looking forward to the release.
Cheers, Bernhard
Am 26.10.2014 um 21:49 schrieb Eliot Miranda eliot.miranda@gmail.com:
On Sun, Oct 26, 2014 at 1:46 PM, Bernhard Pieber bernhard@pieber.com wrote: This is really great news. I tried it out with the latest CogSpur VM 3114 and the latest image from October 17th. When I update Squeak it runs into Merging Collections.spur-nice.583. I wonder what to do now? All Newer and Merge?
Yes, and afterwards, if the dirty package bothers you, resolve the dirty package by manually loading the latest Spur version. This crap should be temporary. Once we release things will work out (no patching and multiple parents any more).
Cheers, Bernhard
Am 17.10.2014 um 08:51 schrieb Eliot Miranda eliot.miranda@gmail.com:
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
-- best, Eliot
squeak-dev@lists.squeakfoundation.org
-
Bernhard Pieber -
Casey Ransberger -
Chris Muller -
David T. Lewis -
Eliot Miranda -
Hilaire -
J. Vuletich (mail lists) -
Levente Uzonyi