September 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Compiling the VM for MacOSX

by Henrik Sperre Johansen

On 09.09.2010 22:01, Alexandre Bergel wrote: > Thanks John for this explanation. > >> Ah, you'll need to explain which VM you built? Also when you build you get to pick between DEBUG and Deployment/Release in OS-X and I assure you the DEBUG version is 10x slower than the non-debug one. > I downloaded the platforms folder with "svn co http://squeakvm.org/svn/squeak/trunk/platforms/" > > Generating the last version of the VM Source raises some error: > - findLastOccurranceOfString:startingAt: does not exist. I had to replace it by findLastOccurrenceOfString:startingAt: > - fixTemps is sent many times. I had to remove the deprecation error message to proceed with the generation > > How long time does it take to generate the source? > My macbook pro has turned itself into a furnace about 30 minutes ago. Pass 18 is indicated, 50% of the progress bar. > > John, will you be at esug? > > Cheers, > Alexandre Search the vm-dev list (or this one) to find solutions to these issues when using VMMaker in a Pharo image. Cheers, Henry

Sept. 9, 2010

Re: [Pharo-project] Compiling the VM for MacOSX

by Alexandre Bergel

Thanks John for this explanation. > Ah, you'll need to explain which VM you built? Also when you build you get to pick between DEBUG and Deployment/Release in OS-X and I assure you the DEBUG version is 10x slower than the non-debug one. I downloaded the platforms folder with "svn co http://squeakvm.org/svn/squeak/trunk/platforms/" Generating the last version of the VM Source raises some error: - findLastOccurranceOfString:startingAt: does not exist. I had to replace it by findLastOccurrenceOfString:startingAt: - fixTemps is sent many times. I had to remove the deprecation error message to proceed with the generation How long time does it take to generate the source? My macbook pro has turned itself into a furnace about 30 minutes ago. Pass 18 is indicated, 50% of the progress bar. John, will you be at esug? Cheers, Alexandre > > Now. > > VMMaker translates a subset of Smalltalk known as Slang to C code. This is the core of the Virtual Machine and processes Smalltalk byte codes it reads from the Squeak Image to perform some obscure task... As Block Closures and Cog JIT work , UTC time, etc, have been added in the last year that has resulted in new versions of VMMaker since we are changing the functionality of the VM. > > However the VM is decoupled from the issue of the supporting platform, which progresses at a different rate. > > In order to run the VM on a particular hardware device/software platform the person wanting to port the VM has to follow documentation such as found as http://isqueak.org/PlatformVMAPI to create the platform specific API to enable a user of the device to enter UI input and have the VM produce some form of output (may or may not be visual). > > The 'Mac OS' folder contains platform code to build a carbon based OS-X system which has it's roots in Apple's OS 7.5.x from 1991. This evolved over the years to support OS-X as an 'OS-X legacy carbon application' and is known as the 3.x series before MacIntel machines, and 4.x after MacIntel with 4.2.5 being the last shipped version. > > In June of 2008 the ESUG board provided funding to assist in the development of the platform files for the iPhone, further funding granted in October of 2009 enabled us to rebuild a new set of platform files for OS-X and iOS that > > (a) Bring the macintosh os-x platform support code up to the latest version of API support using Cocoa. > (b) Enable the ability of the VM & API to run in 32 bit or 64 bit mode on MacIntel or PowerPC. * > (c) Enable the ability to run the VM in 64 bit mode working with a 32 bit image > (d) Enable the ability to run the VM in 64 bit mode working with a 64 bit image. > (e) Rewrite the Squeak in the Browser api to work with Apple's 64 bit requirements. *Cough* pending... > > This resulted in the current 5.x series, which support 32bit/64bit VM on os-x against a 32bit or 64bit image, > or a 32bit VM with 32bit image on iOS devices. Work from teleplace also offers a 32bit vm in stack or JIT implementation against a 32bit image. > > *Apple did not supply 64bit versions of the GUI for the PowerPC which makes it impossible to offer a 64bit compiled VM on the PowerPC because one lacks a Graphical User Interface. > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 9, 2010

[Pharo-project] [update 1.2] #12131

by StÃ©phane Ducasse

12131 ----- - Issue 2936: DateAndTimeTest has failures. Thanks Pavel Krivanek. - Issue 2937: TimespanTest >> testEnd failing. Thanks Pavel Krivanek. - Issue 2929: remove #tiny, #tinyDisplay and the class var Tiny. - Issue 2499: MaskedTextMorph class for masked input fields. Thanks Dionisiygod. Stef

Sept. 9, 2010

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