Feature Request: Strict Compiler / Monticello Mode
Locked
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Feature Request: Strict Compiler / Monticello Mode
|
|
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 <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Feature Request: Strict Compiler / Monticello Mode
|
|
Btw, same problem with WriteStream>>crlf.
Lukas On 9 September 2010 12:10, Lukas Renggli <[hidden email]> 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 <[hidden email]> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Feature Request: Strict Compiler / Monticello Mode
|
|
In reply to this post by Lukas Renggli
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 <[hidden email]> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Feature Request: Strict Compiler / Monticello Mode
|
|
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 <[hidden email]>: > 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 <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Feature Request: Strict Compiler / Monticello Mode
|
|
> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Feature Request: Strict Compiler / Monticello Mode
|
|
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. 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Feature Request: Strict Compiler / Monticello Mode
|
|
In reply to this post by Nicolas Cellier
> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Feature Request: Strict Compiler / Monticello Mode
|
|
In reply to this post by Levente Uzonyi-2
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 > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Feature Request: Strict Compiler / Monticello Mode
|
|
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. 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 > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Feature Request: Strict Compiler / Monticello Mode
|
|
In reply to this post by Levente Uzonyi-2
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Feature Request: Strict Compiler / Monticello Mode
|
|
In reply to this post by Levente Uzonyi-2
>
> > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Feature Request: Strict Compiler / Monticello Mode
|
|
In reply to this post by Levente Uzonyi-2
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Feature Request: Strict Compiler / Monticello Mode
|
|
In reply to this post by Stéphane Ducasse
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 the image, then how can I update it to 1.1? Levente > > Stef > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Feature Request: Strict Compiler / Monticello Mode
|
|
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 > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Feature Request: Strict Compiler / Monticello Mode
|
|
In reply to this post by Levente Uzonyi-2
>> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Feature Request: Strict Compiler / Monticello Mode
|
|
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 > [hidden email] > 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." _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Feature Request: Strict Compiler / Monticello Mode
|
|
In reply to this post by Stéphane Ducasse
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. 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. 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Feature Request: Strict Compiler / Monticello Mode
|
|
>>>> 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. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Feature Request: Strict Compiler / Monticello Mode
|
|
In reply to this post by Levente Uzonyi-2
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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |