[Pharo-project] Feature Request: Strict Compiler / Monticello Mode
Hi It seems like we unintentionally introduced an override for Collection
#sorted in Grease. That puts in a hard place because we can't simply remove it from Grease. Because if you do that everybody who updates looses the method and potentially breaks his image. Yeah, I see that the real fix you be for Monticello to restore the old method but that hasn't happened in years.
Monticello / the compiler already warns about a lot of less important things. Now I know adding an additional preference for that is ugly and I'd welcome and better/nicer solution. Cheers Philippe
I suggest that we just remove the two methods (Collection>>#sorted and Colection>>#sorted:) from Grease. It doesn't look like the system itself is calling them on Collection, and most subclasses override them anyway. Lukas On 9 September 2010 11:10, Philippe Marschall <kustos@gmx.net> wrote:
Hi
It seems like we unintentionally introduced an override for Collection
#sorted in Grease. That puts in a hard place because we can't simply remove it from Grease. Because if you do that everybody who updates looses the method and potentially breaks his image. Yeah, I see that the real fix you be for Monticello to restore the old method but that hasn't happened in years.
Monticello / the compiler already warns about a lot of less important things. Now I know adding an additional preference for that is ugly and I'd welcome and better/nicer solution.
Cheers Philippe
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
Btw, same problem with WriteStream>>crlf. Lukas On 9 September 2010 12:10, Lukas Renggli <renggli@gmail.com> wrote:
I suggest that we just remove the two methods (Collection>>#sorted and Colection>>#sorted:) from Grease. It doesn't look like the system itself is calling them on Collection, and most subclasses override them anyway.
Lukas
On 9 September 2010 11:10, Philippe Marschall <kustos@gmx.net> wrote:
Hi
It seems like we unintentionally introduced an override for Collection
#sorted in Grease. That puts in a hard place because we can't simply remove it from Grease. Because if you do that everybody who updates looses the method and potentially breaks his image. Yeah, I see that the real fix you be for Monticello to restore the old method but that hasn't happened in years.
Monticello / the compiler already warns about a lot of less important things. Now I know adding an additional preference for that is ugly and I'd welcome and better/nicer solution.
Cheers Philippe
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
ok let us know how we can help. There are methods from grease that I would love to have in Pharo to get better libraries. Stef
I suggest that we just remove the two methods (Collection>>#sorted and Colection>>#sorted:) from Grease. It doesn't look like the system itself is calling them on Collection, and most subclasses override them anyway.
Lukas
On 9 September 2010 11:10, Philippe Marschall <kustos@gmx.net> wrote:
Hi
It seems like we unintentionally introduced an override for Collection
#sorted in Grease. That puts in a hard place because we can't simply remove it from Grease. Because if you do that everybody who updates looses the method and potentially breaks his image. Yeah, I see that the real fix you be for Monticello to restore the old method but that hasn't happened in years.
Monticello / the compiler already warns about a lot of less important things. Now I know adding an additional preference for that is ugly and I'd welcome and better/nicer solution.
Cheers Philippe
Isn't Grease dialect dependent by essence ? If Pharo and Squeak diverge, then there will naturally be two versions of Grease... However, for these two messages, I think Pharo core should integrate them and align with Squeak. The question is more whether you need to distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ... Nicolas 2010/9/9 Stéphane Ducasse <stephane.ducasse@inria.fr>:
ok let us know how we can help. There are methods from grease that I would love to have in Pharo to get better libraries.
Stef
I suggest that we just remove the two methods (Collection>>#sorted and Colection>>#sorted:) from Grease. It doesn't look like the system itself is calling them on Collection, and most subclasses override them anyway.
Lukas
On 9 September 2010 11:10, Philippe Marschall <kustos@gmx.net> wrote:
Hi
It seems like we unintentionally introduced an override for Collection
#sorted in Grease. That puts in a hard place because we can't simply remove it from Grease. Because if you do that everybody who updates looses the method and potentially breaks his image. Yeah, I see that the real fix you be for Monticello to restore the old method but that hasn't happened in years.
Monticello / the compiler already warns about a lot of less important things. Now I know adding an additional preference for that is ugly and I'd welcome and better/nicer solution.
Cheers Philippe
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Isn't Grease dialect dependent by essence ? If Pharo and Squeak diverge, then there will naturally be two versions of Grease... However, for these two messages, I think Pharo core should integrate them and align with Squeak. The question is more whether you need to distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ...
Probably else this means that Pharo and any system is bound to die because it does not change. This is why configurations are important. Stef
On Thu, 9 Sep 2010, Stéphane Ducasse wrote:
Isn't Grease dialect dependent by essence ? If Pharo and Squeak diverge, then there will naturally be two versions of Grease... However, for these two messages, I think Pharo core should integrate them and align with Squeak. The question is more whether you need to distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ...
Probably else this means that Pharo and any system is bound to die because it does not change.
The rapid changes and no-backwards-compatibility you prefer and advocate are not essential for a Smalltalk system to "stay alive". Just look at VSE, it didn't change in the last 10 years, and people are still using it. In constrast Pharo 1.0 was considered abandonware four months after it's release, which caused trouble for some users who didn't think that they'll have to patch their code and rebuild their images to "get" updates/fixes. Levente
This is why configurations are important.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
El jue, 09-09-2010 a las 16:01 +0200, Levente Uzonyi escribió:
On Thu, 9 Sep 2010, Stéphane Ducasse wrote:
Isn't Grease dialect dependent by essence ? If Pharo and Squeak diverge, then there will naturally be two versions of Grease... However, for these two messages, I think Pharo core should integrate them and align with Squeak. The question is more whether you need to distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ...
Probably else this means that Pharo and any system is bound to die because it does not change.
The rapid changes and no-backwards-compatibility you prefer and advocate are not essential for a Smalltalk system to "stay alive". Just look at VSE, it didn't change in the last 10 years, and people are still using it. In constrast Pharo 1.0 was considered abandonware four months after it's release, which caused trouble for some users who didn't think that they'll have to patch their code and rebuild their images to "get" updates/fixes.
Yes but they paid support to remain backwards compatible. If I paid support and not get my system running in new versions then I really would be a fool for paying. Now Squeak/Pharo comes with no warranties, as the license states. So don't complain because when migrating to a new version *you* must adapt your code to the new environment. That is expected and nothing to whine of. If you want that a system runs unchanged for decades, the use a environment that doesn't change for decades. And remain there, as the world lets you behind.
Levente
This is why configurations are important.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
On Thu, 9 Sep 2010, Miguel Enrique Cobá MartÃnez wrote:
El jue, 09-09-2010 a las 16:01 +0200, Levente Uzonyi escribió: On Thu, 9 Sep 2010, Stéphane Ducasse wrote:
Isn't Grease dialect dependent by essence ? If Pharo and Squeak diverge, then there will naturally be two versions of Grease... However, for these two messages, I think Pharo core should integrate them and align with Squeak. The question is more whether you need to distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ...
Probably else this means that Pharo and any system is bound to die because it does not change.
The rapid changes and no-backwards-compatibility you prefer and advocate are not essential for a Smalltalk system to "stay alive". Just look at VSE, it didn't change in the last 10 years, and people are still using it. In constrast Pharo 1.0 was considered abandonware four months after it's release, which caused trouble for some users who didn't think that they'll have to patch their code and rebuild their images to "get" updates/fixes.
"Yes but they paid support to remain backwards compatible. If I paid support and not get my system running in new versions then I really would be a fool for paying." I'm sure they didn't pay for this. "Now Squeak/Pharo comes with no warranties, as the license states. So don't complain because when migrating to a new version *you* must adapt your code to the new environment. That is expected and nothing to whine of. If you want that a system runs unchanged for decades, the use a environment that doesn't change for decades. And remain there, as the world lets you behind." When should one complain? Levente
Levente
This is why configurations are important.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I'm sure they didn't pay for this.
"Now Squeak/Pharo comes with no warranties, as the license states. So don't complain because when migrating to a new version *you* must adapt your code to the new environment. That is expected and nothing to whine of. If you want that a system runs unchanged for decades, the use a environment that doesn't change for decades. And remain there, as the world lets you behind."
When should one complain?
Of course people can complain. Now do you use pharo? And squeak is changing too so where is the difference. Stef
El jue, 09-09-2010 a las 18:01 +0200, Levente Uzonyi escribió:
When should one complain?
Never, they should ask for help, maybe file a bug, or better help to fix it and improve the system, but not complain. The contributors and people around Pharo are doing it in their free time for different reasons, but that doesn't means that they are somehow obliged or forced to make the system compatible for everyone and every situation and posible combination of factors, including, time, backward compatibility, API stability, technical support. The code as MIT says, is take it as it is: THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. So if works for you fine. If breaks your code, sorry. If works in this version and the next don't, I feel sorry for you. Of course this isn't what happens regularly in an FOSS project, as the developers are proud to have a system that works correctly in most reasonable situations and they are by their nature very helpful people. But that is just because the good faith of the developers, not their obligation. So, yes, Pharo 1.0 was released and inmediatly Pharo 1.1 was worked out, changing the focus to the new version. If that means that people will have a couple hitches when migrating in order to use the newest changes, then that is a little price to pay (not monetary, but a price nonetheless). The backwards compatibility could be a good thing, but in this little community, we don't have the energy and people to try to do it always. And even if we had them, we don't want to. Neither the big bucks companies. Else, we'll still have 5in drives in our gorgeous Macbook Pro. Cheers -- Miguel Cobá http://miguel.leugim.com.mx
Why are you so aggressive against us? Now if you want status quo why do you even commit in squeak? Now I'm not sure that this is the kind of
Isn't Grease dialect dependent by essence ? If Pharo and Squeak diverge, then there will naturally be two versions of Grease... However, for these two messages, I think Pharo core should integrate them and align with Squeak. The question is more whether you need to distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ...
Probably else this means that Pharo and any system is bound to die because it does not change.
The rapid changes and no-backwards-compatibility you prefer and advocate are not essential for a Smalltalk system to "stay alive". Just look at VSE, it didn't change in the last 10 years, and people are still using it. In constrast Pharo 1.0 was considered abandonware four months after it's release, which caused trouble for some users who didn't think that they'll have to patch their code and rebuild their images to "get" updates/fixes.
Pharo1.0 is not abandoned at all. Since 1.0 we got more than 1000 bugs closed. The versions are just a way to have milestones. Now there is no problem you think otherwise Stef
On Thu, 9 Sep 2010, Stéphane Ducasse wrote:
Why are you so aggressive against us?
I didn't mean to be aggressive, I just don't think your idea will work well.
Now if you want status quo why do you even commit in squeak?
I'm not against changes.
Now I'm not sure that this is the kind of
I think the end of the sentence got lost somewhere.
Isn't Grease dialect dependent by essence ? If Pharo and Squeak diverge, then there will naturally be two versions of Grease... However, for these two messages, I think Pharo core should integrate them and align with Squeak. The question is more whether you need to distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ...
Probably else this means that Pharo and any system is bound to die because it does not change.
The rapid changes and no-backwards-compatibility you prefer and advocate are not essential for a Smalltalk system to "stay alive". Just look at VSE, it didn't change in the last 10 years, and people are still using it. In constrast Pharo 1.0 was considered abandonware four months after it's release, which caused trouble for some users who didn't think that they'll have to patch their code and rebuild their images to "get" updates/fixes.
Pharo1.0 is not abandoned at all. Since 1.0 we got more than 1000 bugs closed. The versions are just a way to have milestones. Now there is no problem you think otherwise
So if I have a Pharo 1.0 image with my code and I don't want to rebuild the image, then how can I update it to 1.1? Levente
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
El jue, 09-09-2010 a las 21:02 +0200, Levente Uzonyi escribió:
On Thu, 9 Sep 2010, Stéphane Ducasse wrote:
Why are you so aggressive against us?
I didn't mean to be aggressive, I just don't think your idea will work well.
Now if you want status quo why do you even commit in squeak?
I'm not against changes.
Now I'm not sure that this is the kind of
I think the end of the sentence got lost somewhere.
Isn't Grease dialect dependent by essence ? If Pharo and Squeak diverge, then there will naturally be two versions of Grease... However, for these two messages, I think Pharo core should integrate them and align with Squeak. The question is more whether you need to distinguish Grease-Pharo1_1 from Grease-Pharo1_2 ...
Probably else this means that Pharo and any system is bound to die because it does not change.
The rapid changes and no-backwards-compatibility you prefer and advocate are not essential for a Smalltalk system to "stay alive". Just look at VSE, it didn't change in the last 10 years, and people are still using it. In constrast Pharo 1.0 was considered abandonware four months after it's release, which caused trouble for some users who didn't think that they'll have to patch their code and rebuild their images to "get" updates/fixes.
Pharo1.0 is not abandoned at all. Since 1.0 we got more than 1000 bugs closed. The versions are just a way to have milestones. Now there is no problem you think otherwise
So if I have a Pharo 1.0 image with my code and I don't want to rebuild the image, then how can I update it to 1.1?
You change the source for downloading updates from. Then in a workspace you fire up the updateFromServer code and voilá. This will apply the same patches that were applied to 1.0 since the freeze to reach the point where 1.1 is. Just the same as squeak. But given the multiple ways in that 1.1 is different that 1.0, if you do this in a production image of yours very likely your image will blow, because there won't be code that was in 1.0 and isn't in 1.1. That is the main reason that isn't a supported option. If enabled somehow (menu, code snippet, some wiki page instruction) a lot of users will blindly update a working image leaving them with a unfunctional one. As we don't have the time or the people to support incountable questions about why this happend, the best it to advise the users to put the code in monticello (a good thing, no matter the arguments about the monolithic, time-evolved image) and load their code in a new downloaded 1.1 image. If every works correctly then they can be sure that their package works on the new version. If not, well, they have still a running stable working image and can spend time making its package work in the new image. But this is effort for the user. No matter how good the developers of Pharo are, there is no possible way to guarantee that the update process will be flawless for every user and for each but the simplest cases. Cheers
Levente
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
Why are you so aggressive against us?
I didn't mean to be aggressive, I just don't think your idea will work well.
we will see.
Now if you want status quo why do you even commit in squeak?
I'm not against changes.
So I did not understand. Probably my english.
Pharo1.0 is not abandoned at all. Since 1.0 we got more than 1000 bugs closed. The versions are just a way to have milestones. Now there is no problem you think otherwise
So if I have a Pharo 1.0 image with my code and I don't want to rebuild the image, then how can I update it to 1.1?
- first I cannot reload code for you. - second you can simply look at Utilities and find the right invocation to get the next update stream. Something like that Utilities readServer: Utilities serverUrls updatesThrough: nil saveLocally: true updateImage: true. But you should set the version to 1.1. I'm sure that you can easily find how to do it. Of course in 1.2 this is way nicer UpdateStreamer new beVerbose; updateFromServer Then there are changes like closures that requires a brand new image so you cannot bash us if you cannot reload you code in another image. Moose people have a lot of packages with a lot of dependencies and code and they moved from 1.0 to 1.1 without any real problem. Probably a couple of deprecated messages. Stef
Indeed, we moved Moose from Pharo 1.0 to Pharo 1.1 in a couple of hours, and everything worked out perfectly. The coolest thing was that simply moving from one Pharo to the other basically improved the product performance with about 40% :). So, even from the point of view of a large project, change is not a problem. In fact, it is wanted. Addressing the question of how one should upgrade the code without changing the image ... I will say that at this point I do not want that. I want to be able to load my code in a new image at any time. So, from my point of view, I will upgrade my image by simply loading the code in the new image. Cheers, Doru On 9 Sep 2010, at 22:27, Stéphane Ducasse wrote:
Why are you so aggressive against us?
I didn't mean to be aggressive, I just don't think your idea will work well.
we will see.
Now if you want status quo why do you even commit in squeak?
I'm not against changes.
So I did not understand. Probably my english.
Pharo1.0 is not abandoned at all. Since 1.0 we got more than 1000 bugs closed. The versions are just a way to have milestones. Now there is no problem you think otherwise
So if I have a Pharo 1.0 image with my code and I don't want to rebuild the image, then how can I update it to 1.1?
- first I cannot reload code for you. - second you can simply look at Utilities and find the right invocation to get the next update stream.
Something like that Utilities readServer: Utilities serverUrls updatesThrough: nil saveLocally: true updateImage: true. But you should set the version to 1.1.
I'm sure that you can easily find how to do it.
Of course in 1.2 this is way nicer UpdateStreamer new beVerbose; updateFromServer
Then there are changes like closures that requires a brand new image so you cannot bash us if you cannot reload you code in another image. Moose people have a lot of packages with a lot of dependencies and code and they moved from 1.0 to 1.1 without any real problem. Probably a couple of deprecated messages.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "It's not what we do that matters most, it's how we do it."
On Thu, 9 Sep 2010, Stéphane Ducasse wrote:
Why are you so aggressive against us?
I didn't mean to be aggressive, I just don't think your idea will work well.
we will see.
Now if you want status quo why do you even commit in squeak?
I'm not against changes.
So I did not understand. Probably my english.
I like to keep stuff backwards compatible as long as it doesn't "cost" too much do it. And I like when my old code works with none or minimal changes in newer systems.
Pharo1.0 is not abandoned at all. Since 1.0 we got more than 1000 bugs closed. The versions are just a way to have milestones. Now there is no problem you think otherwise
So if I have a Pharo 1.0 image with my code and I don't want to rebuild the image, then how can I update it to 1.1?
- first I cannot reload code for you. - second you can simply look at Utilities and find the right invocation to get the next update stream.
Something like that Utilities readServer: Utilities serverUrls updatesThrough: nil saveLocally: true updateImage: true. But you should set the version to 1.1.
I'm sure that you can easily find how to do it.
I tried this in a PharoCore 1.0 image: ScriptLoader currentMajorVersionNumber: 1.1. SystemVersion current version: 'PharoCore1.1ALPHA'. Utilities readServerUpdatesThrough: nil saveLocally: false updateImage: true. But the image freezes (not interruptable by Alt+. (or Cmd+.)).
Of course in 1.2 this is way nicer UpdateStreamer new beVerbose; updateFromServer
Then there are changes like closures that requires a brand new image so you cannot bash us if you cannot reload you code in another image.
Um no. We have several images which were updated from Squeak 3.10 to the current Squeak 4.2 trunk. Levente
Moose people have a lot of packages with a lot of dependencies and code and they moved from 1.0 to 1.1 without any real problem. Probably a couple of deprecated messages.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Why are you so aggressive against us?
I didn't mean to be aggressive, I just don't think your idea will work well.
we will see.
Now if you want status quo why do you even commit in squeak?
I'm not against changes.
So I did not understand. Probably my english.
I like to keep stuff backwards compatible as long as it doesn't "cost" too much do it. And I like when my old code works with none or minimal changes in newer systems.
Us too.
Pharo1.0 is not abandoned at all. Since 1.0 we got more than 1000 bugs closed. The versions are just a way to have milestones. Now there is no problem you think otherwise
So if I have a Pharo 1.0 image with my code and I don't want to rebuild the image, then how can I update it to 1.1?
- first I cannot reload code for you. - second you can simply look at Utilities and find the right invocation to get the next update stream.
Something like that Utilities readServer: Utilities serverUrls updatesThrough: nil saveLocally: true updateImage: true. But you should set the version to 1.1.
I'm sure that you can easily find how to do it.
I tried this in a PharoCore 1.0 image:
ScriptLoader currentMajorVersionNumber: 1.1. SystemVersion current version: 'PharoCore1.1ALPHA'. Utilities readServerUpdatesThrough: nil saveLocally: false updateImage: true.
But the image freezes (not interruptable by Alt+. (or Cmd+.)).
I do not have the time to have a look since we haves ESUG organization now more than ever.
Levente A final word on this discussion. There is a difference between making sure that people cannot update and trying to make progress and sometimes facing problem. So this is not our goal that the update does not work but sometimes we could not do otherwise. We are sorry about that we are probably too stupid. Now do that on our free time. Stef On Sep 9, 2010, at 11:33 PM, Levente Uzonyi wrote:
On Thu, 9 Sep 2010, Stéphane Ducasse wrote:
Why are you so aggressive against us?
I didn't mean to be aggressive, I just don't think your idea will work well.
we will see.
Now if you want status quo why do you even commit in squeak?
I'm not against changes.
So I did not understand. Probably my english.
I like to keep stuff backwards compatible as long as it doesn't "cost" too much do it. And I like when my old code works with none or minimal changes in newer systems.
Pharo1.0 is not abandoned at all. Since 1.0 we got more than 1000 bugs closed. The versions are just a way to have milestones. Now there is no problem you think otherwise
So if I have a Pharo 1.0 image with my code and I don't want to rebuild the image, then how can I update it to 1.1?
- first I cannot reload code for you. - second you can simply look at Utilities and find the right invocation to get the next update stream.
Something like that Utilities readServer: Utilities serverUrls updatesThrough: nil saveLocally: true updateImage: true. But you should set the version to 1.1.
I'm sure that you can easily find how to do it.
I tried this in a PharoCore 1.0 image:
ScriptLoader currentMajorVersionNumber: 1.1. SystemVersion current version: 'PharoCore1.1ALPHA'. Utilities readServerUpdatesThrough: nil saveLocally: false updateImage: true.
But the image freezes (not interruptable by Alt+. (or Cmd+.)).
Of course in 1.2 this is way nicer UpdateStreamer new beVerbose; updateFromServer
Then there are changes like closures that requires a brand new image so you cannot bash us if you cannot reload you code in another image.
Um no. We have several images which were updated from Squeak 3.10 to the current Squeak 4.2 trunk.
Levente
Moose people have a lot of packages with a lot of dependencies and code and they moved from 1.0 to 1.1 without any real problem. Probably a couple of deprecated messages.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Isn't Grease dialect dependent by essence ?
Sure, not only dialect dependent but even version dependent. That's why I changed Grease to align with Pharo 1.1 (this is the stable Pharo supported by Grease). What Philippe only wanted to point out is that updating Grease might blow up your system (because of the methods that are missing afterwards). Lukas -- Lukas Renggli www.lukas-renggli.ch
participants (7)
-
Levente Uzonyi -
Lukas Renggli -
Miguel Enrique Cobá MartÃnez -
Nicolas Cellier -
Philippe Marschall -
Stéphane Ducasse -
Tudor Girba