- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Feature Request: Strict Compiler / Monticello Mode

by StÃ©phane Ducasse

>> 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

Sept. 9, 2010

Re: [Pharo-project] TimespanTest >> testEnd failing

by StÃ©phane Ducasse

Thanks! This is nice to get some help from the tests. Integrated in the next batch. Stef On Sep 9, 2010, at 8:43 PM, Pavel Krivanek wrote: > http://code.google.com/p/pharo/issues/detail?id=2937 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 9, 2010

Re: [Pharo-project] Feature Request: Strict Compiler / Monticello Mode

by Miguel Enrique CobÃ¡ MartÃnez

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(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Sept. 9, 2010

Re: [Pharo-project] Feature Request: Strict Compiler / Monticello Mode

by Levente Uzonyi

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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 9, 2010

Re: [Pharo-project] DateAndTimeTest failures

by StÃ©phane Ducasse

On Sep 9, 2010, at 8:28 PM, Pavel Krivanek wrote: > On Thu, Sep 9, 2010 at 7:25 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Thanks Pavel >> >> I have been thinking a lot about you recently. >> I started to create a lot of bug entries remodularisation (and I got trapped by time >> - today an obligatory meeting starting a 12h on account certification :) and ended up at 17h :) >> >> I will continue and I saw to nicolas and gabriel how they can help going over your issues and the new ones >> I'm creating. > > Don't worry, I'm still discovering new ones :-) Me too :) I'm confident that it will keep us busy. > > -- Pavel > >> >> On Sep 9, 2010, at 6:30 PM, Pavel Krivanek wrote: >> >>> Hi, >>> >>> I tried to fix DateAndTimeTest failures, see >>> http://code.google.com/p/pharo/issues/detail?id=2936 >>> >>> The patch adds methods clearOffset and withoutOffset to DateAndTime. >>> >>> Cheers, >>> -- Pavel >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 9, 2010

[Pharo-project] TimespanTest >> testEnd failing

by Pavel Krivanek

http://code.google.com/p/pharo/issues/detail?id=2937

Sept. 9, 2010

Re: [Pharo-project] DateAndTimeTest failures

by Pavel Krivanek

On Thu, Sep 9, 2010 at 7:25 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Thanks Pavel > > I have been thinking a lot about you recently. > I started to create a lot of bug entries remodularisation (and I got trapped by time > - today an obligatory meeting starting a 12h on account certification :) and ended up at 17h :) > > I will continue and I saw to nicolas and gabriel how they can help going over your issues and the new ones > I'm creating. Don't worry, I'm still discovering new ones :-) -- Pavel > > On Sep 9, 2010, at 6:30 PM, Pavel Krivanek wrote: > >> Hi, >> >> I tried to fix DateAndTimeTest failures, see >> http://code.google.com/p/pharo/issues/detail?id=2936 >> >> The patch adds methods clearOffset and withoutOffset to DateAndTime. >> >> Cheers, >> -- Pavel >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 9, 2010

Re: [Pharo-project] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b10

by StÃ©phane Ducasse

Thanks John Stef > I've stuck a version (5.8b10) of the cocoa based os-x squeak cog JIT based VM in my experimental folder. > > http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b10.app.zip > > Changes are: > > (a) Fix issue with timezone calculation on file creation and modification timestamps. > (b) Fix a crash with sqInt ioSetCursor() which calls ioSetCursorWithMask() with a NULL mask value which it did not handle correctly. > > Based on feedback I wil produce a non-cog VM 5.7x and push that as the approved for regular use os-x/iOS VM on the weekend. > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 9, 2010

[Pharo-project] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b10

by John M McIntosh

I've stuck a version (5.8b10) of the cocoa based os-x squeak cog JIT based VM in my experimental folder. http://homepage.mac.com/johnmci/.Public/experimental/Squeak%205.8b10.app.zip Changes are: (a) Fix issue with timezone calculation on file creation and modification timestamps. (b) Fix a crash with sqInt ioSetCursor() which calls ioSetCursorWithMask() with a NULL mask value which it did not handle correctly. Based on feedback I wil produce a non-cog VM 5.7x and push that as the approved for regular use os-x/iOS VM on the weekend. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Sept. 9, 2010

Re: [Pharo-project] Cog Segmentation Fault with Pharo 1.1

by StÃ©phane Ducasse

why should add some guards in the tests for that even if ObjectAsMethods is a cool feature to have for experimentation. There are some changes from squeak pending in the bug tracker. Now you should also pay that the coverage button is using wrapper and I guess also use test coverage. Stef > Hi: > > I was playing a bit with a stock Pharo 1.1 image, with the only adding > of the cs NecessaryImageChangesForCogToWork.Pharo1.1. > > Then I tried to run TestRunner new runAll (for comparing times against > the common vm) and get the attached segfault. > > I tried with my own compiled cog and also with the downloaded from > here http://www.mirandabanda.org/files/Cog/VM/VM.r2219/. > > My OS is Ubuntu 10.04 64 bits. > > Any hint will be appreciated. > > Cheers. > > -- > ================================================= > GermÃ¡n S. Arduino <gsa @ arsol.net> Twitter: garduino > Arduino Software & Web Hosting http://www.arduinosoftware.com > PasswordsPro http://www.passwordspro.com > ================================================= > <cogsegfault.txt>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 9, 2010