- Pharo-dev - lists.pharo.org

Post on how to install pharo

by Guillermo Polito

Hi guys, I've written a small post on the current mechanisms for download and deploy pharo images and vms. Of course it may not be complete, just wanted to make noise :). So, feedback and retweets are welcome ;). http://playingwithobjects.wordpress.com/2013/07/23/installing-pharo-in-many… Guille

July 23, 2013

Re: [Pharo-dev] thisContext and block

by StÃ©phane Ducasse

thanks! It makes a lot of sense. I will play with another example because I want to really understand the outerContext of closure vs the home context. Stef On Jul 23, 2013, at 6:58 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > This is because of compilation optimization. > > 2013/7/22 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Hi > > when I execute the following > > first > "Bexp new first" > | temp | > temp := 2. > [ temp. > thisContext inspect.] value. > ^ temp > > tmp in the inspector is nil and does not hold 2 and I was wondering why. > I thought that thisContext was returning the blockContext > In the outercontext of thisContext blockClosure, tmp is also nil. > > > This is because here 'temp.' is evaluated for effect (the value is not stored anywhere) and it has no side effect (reading a variable cannot lead to a modification of state of another object). So the compiler removes it. As it is removed, it is the same as if it was not in the block. So the block cannot access temp. Now write 'temp:= #foo' or 'temp foo' you will get it. > > first > "Bexp new first" > | temp | > temp := 2. > [ temp. > temp traceCr. > thisContext inspect.] value. > ^ temp > > output 2 on the transcript. > > In this case 'temp.' is still removed, but the value of temp still need to be copied in the block for ' temp traceCr.'.'temp traceCr' is also evaluated for effect, but has the side effect to output the transcript, so the compiler cannot remove it. > > Basically the is very few things that the compiler removes, and one of them is variable read for effect, because you are sure it cannot lead to any issue. > > Stef > >

July 23, 2013

Re: [Pharo-dev] unwinding the stack

by ClÃ©ment Bera

2013/7/23 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > On Jul 23, 2013, at 12:25 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > On Mon, Jul 22, 2013 at 1:58 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Hi guys >> >> I'm trying to explain the following sentence (I wrote long time ago) and >> now I'm stuck >> >> "escaping blocks jump to their home contexts but do not unwind the stack >> after this point" >> > > Seems wrong to me. ^-returns in blocks return to the sender of the home > context. > > > Yes I thought so too. I will remove this sentence because it is blurry and > wrong. I thought I was wrong. > > > >> especially I'm not clear anymore on the unwind the stack. >> > > The stack is unwound either by the VM executing the ^-return or by > MethodCOntext>>#return:, sent from #aboutToReturn:to: if the ^-return found > an intervening unwind context. (The VM sends aboutToReturn:to:). > > > Thanks > what is a intervening unwind context? > I'm not sure I understood the question but: Unwind a context means when you return from a context to an outer one far in the stack you need to check for unwind context (= context with 'ensure:'), and execute the unwind block (= ensure: argument). For ex: context 1 context 2 context 3 (marked with primitive as unwind context) context 4 context 5 Non local return to context 1 Here the non local return in context 5 goes back to context 1 skipping the rest of the execution of the context 2 - 3 - 4. While going back to context 1 it checks every context (2, 3, 4), detects context 3 as unwindcontext and executes the unwind block of context 3 before continuing the execution in context 1. > > > > HTH > Eliot > > >> Stef >> > > > > -- > best, > Eliot > > >

July 23, 2013

Re: [Pharo-dev] thisContext and block

by ClÃ©ment Bera

This is because of compilation optimization. 2013/7/22 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Hi > > when I execute the following > > first > "Bexp new first" > | temp | > temp := 2. > [ temp. > thisContext inspect.] value. > ^ temp > > tmp in the inspector is nil and does not hold 2 and I was wondering why. > I thought that thisContext was returning the blockContext > In the outercontext of thisContext blockClosure, tmp is also nil. > > This is because here 'temp.' is evaluated for effect (the value is not stored anywhere) and it has no side effect (reading a variable cannot lead to a modification of state of another object). So the compiler removes it. As it is removed, it is the same as if it was not in the block. So the block cannot access temp. Now write 'temp:= #foo' or 'temp foo' you will get it. > first > "Bexp new first" > | temp | > temp := 2. > [ temp. > temp traceCr. > thisContext inspect.] value. > ^ temp > > output 2 on the transcript. > > In this case 'temp.' is still removed, but the value of temp still need to be copied in the block for ' temp traceCr.'.'temp traceCr' is also evaluated for effect, but has the side effect to output the transcript, so the compiler cannot remove it. Basically the is very few things that the compiler removes, and one of them is variable read for effect, because you are sure it cannot lead to any issue. > Stef > >

July 23, 2013

Re: [Pharo-dev] unwinding the stack

by StÃ©phane Ducasse

On Jul 23, 2013, at 12:25 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Mon, Jul 22, 2013 at 1:58 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > I'm trying to explain the following sentence (I wrote long time ago) and now I'm stuck > > "escaping blocks jump to their home contexts but do not unwind the stack after this point" > > Seems wrong to me. ^-returns in blocks return to the sender of the home context. Yes I thought so too. I will remove this sentence because it is blurry and wrong. I thought I was wrong. > > especially I'm not clear anymore on the unwind the stack. > > The stack is unwound either by the VM executing the ^-return or by MethodCOntext>>#return:, sent from #aboutToReturn:to: if the ^-return found an intervening unwind context. (The VM sends aboutToReturn:to:). Thanks what is a intervening unwind context? > > > HTH > Eliot > > > Stef > > > > -- > best, > Eliot

July 22, 2013

Re: [Pharo-dev] unwinding the stack

by Eliot Miranda

On Mon, Jul 22, 2013 at 1:58 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Hi guys > > I'm trying to explain the following sentence (I wrote long time ago) and > now I'm stuck > > "escaping blocks jump to their home contexts but do not unwind the stack > after this point" > Seems wrong to me. ^-returns in blocks return to the sender of the home context. > especially I'm not clear anymore on the unwind the stack. > The stack is unwound either by the VM executing the ^-return or by MethodCOntext>>#return:, sent from #aboutToReturn:to: if the ^-return found an intervening unwind context. (The VM sends aboutToReturn:to:). HTH Eliot > Stef > -- best, Eliot

July 22, 2013

Re: [Pharo-dev] unwinding the stack

by Camille Teruel

On 22 juil. 2013, at 22:58, StÃ©phane Ducasse wrote: > Hi guys > > I'm trying to explain the following sentence (I wrote long time ago) and now I'm stuck > > "escaping blocks jump to their home contexts but do not unwind the stack after this point" > > especially I'm not clear anymore on the unwind the stack. Maybe you meant that escaping blocks unwind the stack *up to* their home context. > > Stef

July 22, 2013

thisContext and block

by StÃ©phane Ducasse

Hi when I execute the following first "Bexp new first" | temp | temp := 2. [ temp. thisContext inspect.] value. ^ temp tmp in the inspector is nil and does not hold 2 and I was wondering why. I thought that thisContext was returning the blockContext In the outercontext of thisContext blockClosure, tmp is also nil. first "Bexp new first" | temp | temp := 2. [ temp. temp traceCr. thisContext inspect.] value. ^ temp output 2 on the transcript. Stef

July 22, 2013

Re: [Pharo-dev] Metacello doubt

by Guido Chari

Thanks, i have some deadlines this week but i will have a look and give you feedback asap. 2013/7/17 Dale K. Henrichs <dale.henrichs(a)gemtalksystems.com> > Guido, > > I've just released Metacello Preview 1.0.0-beta.32.8[1] that includes a > bugfix for your issue. Let me know if you need more information. > > Dale > > [1] > http://gemstonesoup.wordpress.com/2013/07/17/metacello-preview-1-0-0-beta-3… > > ------------------------------ > > *From: *"Guido Chari" <charig(a)gmail.com> > *To: *"Pharo Development List" <pharo-dev(a)lists.pharo.org> > *Sent: *Tuesday, July 2, 2013 12:42:40 PM > > *Subject: *Re: [Pharo-dev] Metacello doubt > > Ok, i will follow the issue on github. Thanks! > > > 2013/7/1 Dale K. Henrichs <dale.henrichs(a)gemtalksystems.com> > >> Guido, >> >> I created a test case and it turns out that there _is_ a bug in the >> bypass lock logic[1] . I'm going to push out a new version of the Metacello >> Preview (1.0.0-beta.32.8) in the next day or so and the bugfix for Issue >> #174 will _not_ be included in that release ... >> >> Dale >> >> [1] https://github.com/dalehenrich/metacello-work/issues/174 >> >> ------------------------------ >> >> *From: *"Guido Chari" <charig(a)gmail.com> >> *To: *"Pharo Development List" <pharo-dev(a)lists.pharo.org> >> *Sent: *Thursday, June 27, 2013 10:23:33 AM >> *Subject: *Re: [Pharo-dev] Metacello doubt >> >> I'm in. >> >> >> 2013/6/26 Dale K. Henrichs <dale.henrichs(a)gemtalksystems.com> >> >>> >>> >>> ------------------------------ >>> >>> *From: *"Guido Chari" <charig(a)gmail.com> >>> *To: *"Pharo Development List" <pharo-dev(a)lists.pharo.org> >>> *Sent: *Wednesday, June 26, 2013 2:49:09 PM >>> >>> *Subject: *Re: [Pharo-dev] Metacello doubt >>> >>> I understood. Thanks for the answer Dale. The drawback in this case is >>> to specify a particular dependency to AsmJit in my configuration. Also, >>> perhaps is the right way since i realized i have a particular dependency on >>> it. >>> >>> But this discussion makes me thing a little and so i have a new question. >>> >>> Form what I (mis) undestand from Metacello, when asking for a >>> bleedingEdge version it loads only the baseline that specifies packages and >>> then last version of every package specified there. >>> >>> As in the projects referenced on the baseline there is no need for >>> specifying a version, and that's the case of nativeBoost configuration, >>> wouldn't it be interesting to have some behavior (i mean i new method for >>> loading like loadDeepSymbolic:) that not only load the symbolicVersion of >>> the package asked, but also propagate that symbolicVersion (bleedingEdge in >>> this case) to all the dependencies that don't specify a concrete version? >>> >>> Guido. >>> >>> Guido, >>> >>> With the Metacello Scripting API[1] I've taken a slightly different >>> tack, but I think that it gets you to the same place. >>> >>> I am a big fan of deterministic loads, but I know that from a practical >>> point of view developers need to have a certain amount of control over >>> exactly what gets loaded into their DEVELOPMENT environments and they need >>> to be able to exert this control without having to resort to editing >>> configurations to match their specific requirements. >>> >>> I have accomplished this by arranging for a Notification to be signalled >>> whenever a project is referenced during a load. The developer can use one >>> or more of the onUpgrade:, onDowngrade: and onConflict: clauses in their >>> load scripts to exert fine control over what happens on a project by >>> project basis ... >>> >>> For your specific use case, I would think that you would want to use the >>> `lock` command[2] and specify that you want to `lock` the projects >>> (NativeBoost and AsmJit) to the #bleedingEdge version. I don't recall if >>> I've got test cases for symbolic versions, but if you are seriously >>> interested in taking the Scripting API for a spin, I'd be willing to write >>> some additional tests using the #bleedingEdge symbolic version (if not >>> already covered) and validate this use case... >>> >>> I am entering a phase where I will be doing some work on getting >>> FileTree and Metacello up to snuff for Pharo3.0 so this would be a good >>> time for me to add some test cases in anticipation of having some >>> interested users ... >>> >>> I haven't released the Scripting API, because I need to have real users >>> with real use cases take the API for a spin and validate the API. The >>> Scripting API can be loaded into any version of Pharo/Squeak/GemStone and I >>> think the Scripting API is (or will be) available in Pharo3.0. >>> >>> I'm looking forward to getting feedback as to how the API stands up to >>> real use ... >>> >>> So let me know if you are interested in being another Scripting API >>> guinea pig:) >>> >>> Dale >>> >>> [1] >>> https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… >>> [2] >>> https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… >>> >>> >> >> > >

July 22, 2013

unwinding the stack

by StÃ©phane Ducasse

Hi guys I'm trying to explain the following sentence (I wrote long time ago) and now I'm stuck "escaping blocks jump to their home contexts but do not unwind the stack after this point" especially I'm not clear anymore on the unwind the stack. Stef

July 22, 2013