- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] X11 window manager in Pharo

by Guillermo Polito

On Thu, Jul 25, 2013 at 1:54 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Hi, > > I will have one full week dedicated to Pharo, now I must decide what to > do. One fun thing would be to write a X11 window manager (based on > TilingWindowManager), so I could run Emacs, shells and all stuff in Pharo, > even Pharo in Pharo :) > You mean implementing a native interface using X11? > > I've tried some months ago to translate this example > https://github.com/mackstann/tinywm/blob/master/annotated.c but I lack > of NativeBoost knowledge (I suppose it's the right tool to use). > I think so too :) > > Has anyone tried this before ? Hints ? > The only thing I know is that Carla Griggio is working on Mars for Gsoc, and for that she is working on Gtk bindings in linux... But I cannot tell more because I really do not understand what you want to do with X11 :). > > > Laurent >

July 25, 2013

X11 window manager in Pharo

by laurent laffont

Hi, I will have one full week dedicated to Pharo, now I must decide what to do. One fun thing would be to write a X11 window manager (based on TilingWindowManager), so I could run Emacs, shells and all stuff in Pharo, even Pharo in Pharo :) I've tried some months ago to translate this example https://github.com/mackstann/tinywm/blob/master/annotated.c but I lack of NativeBoost knowledge (I suppose it's the right tool to use). Has anyone tried this before ? Hints ? Laurent

July 25, 2013

Pharo: thanks!

by Torsten Bergmann

------------------------------------------------------------------------------------ In April 2008 "Sapphire" was started as a fork of Squeak (see [1]) when Stef wrote: "Ideally in 3 years from now we would like to have a small kernel and some cool packages that we can load on top." Initially fixes of Squeak 3.10 were harvested from Mantis, then in May 21 2008 Sapphire smalltalk has been renamed into Pharo. Pharo, PharoInbox and PharoTreeted have been opened at SqueakSource. The first image "pharo0.1-10028dev08.05.1.zip" was published in May 2008, it is still available [2]. Attached is a screenshot. You can compare it to the current Pharo release - still it will not show you the many fixes, contributions, changes and the time invested by the community that went into cleaning and bringing the project on the right track. Thanks to all who help(ed) shaping it! [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-April/127815.ht… [2] https://gforge.inria.fr/frs/?group_id=1299. ------------------------------------------------------------------------------------

July 25, 2013

Re: [Pharo-dev] thisContext and block

by Guillermo Polito

On Thu, Jul 25, 2013 at 1:17 PM, Camille Teruel <camille.teruel(a)gmail.com>wrote: > > On 25 juil. 2013, at 13:12, ClÃ©ment Bera wrote: > > Perhaps you should add some value message so that the assertions are > actually run, shouldn't you ? > > > I always felt that e-mails lack an unsend command :D > Or gmail quotes should work properly :P > > 2013/7/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> For the people following I added a test to show the homeContext of a block >> >> >> | homeContext b1 | >> homeContext := thisContext. >> b1 := [| b2 | >> self assert: thisContext closure == b1. >> self assert: b1 outerContext == homeContext. >> self assert: b1 home = homeContext. >> b2 := [self assert: thisContext closure == b2. >> self assert: b2 outerContext closure outerContext == >> homeContext]. >> self assert: b2 home = homeContext. >> b2 value]. >> b1 value >> >> >> >> >> >> >> On Tue, Jul 23, 2013 at 2:02 AM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> 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. >>> >> >> The outerContext is a link in the static chain. Each block is created >> inside some context. This is the block's outerContext. If the block is >> not nested then the outerCOntext will also be the home context But if the >> block is nested inside another block activation, then the outerContext >> refers to that block activation, and the block activation's block's >> outerContext is the home context. So there are as many outerContext steps >> as there are nesting levels. >> >> | homeContext b1 | >> homeContext := thisContext. >> b1 := [| b2 | >> self assert: thisContext closure == b1. >> self assert: b1 outerContext == homeContext. >> b2 := [self assert: thisContext closure == b2. >> self assert: b2 outerContext closure outerContext == >> homeContext]. >> b2 value]. >> b1 value >> >> Ignore the "bN appears to be undefined at this point" and evaluate the >> above. No assert fails. >> >> Draw a picture. >> >> >>> 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 >>>> >>>> >>> >>> >> >> >> -- >> best, >> Eliot >> >> >> > >

July 25, 2013

Re: [Pharo-dev] thisContext and block

by Camille Teruel

On 25 juil. 2013, at 13:12, ClÃ©ment Bera wrote: > Perhaps you should add some value message so that the assertions are actually run, shouldn't you ? I always felt that e-mails lack an unsend command :D > 2013/7/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > For the people following I added a test to show the homeContext of a block > > > | homeContext b1 | > homeContext := thisContext. > b1 := [| b2 | > self assert: thisContext closure == b1. > self assert: b1 outerContext == homeContext. > self assert: b1 home = homeContext. > b2 := [self assert: thisContext closure == b2. > self assert: b2 outerContext closure outerContext == homeContext]. > self assert: b2 home = homeContext. > b2 value]. > b1 value > > > > >> >> >> On Tue, Jul 23, 2013 at 2:02 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> 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. >> >> The outerContext is a link in the static chain. Each block is created inside some context. This is the block's outerContext. If the block is not nested then the outerCOntext will also be the home context But if the block is nested inside another block activation, then the outerContext refers to that block activation, and the block activation's block's outerContext is the home context. So there are as many outerContext steps as there are nesting levels. >> >> | homeContext b1 | >> homeContext := thisContext. >> b1 := [| b2 | >> self assert: thisContext closure == b1. >> self assert: b1 outerContext == homeContext. >> b2 := [self assert: thisContext closure == b2. >> self assert: b2 outerContext closure outerContext == homeContext]. >> b2 value]. >> b1 value >> >> Ignore the "bN appears to be undefined at this point" and evaluate the above. No assert fails. >> >> Draw a picture. >> >> >> 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 >>> >>> >> >> >> >> >> -- >> best, >> Eliot > >

July 25, 2013

Re: [Pharo-dev] thisContext and block

by ClÃ©ment Bera

Perhaps you should add some value message so that the assertions are actually run, shouldn't you ? 2013/7/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > For the people following I added a test to show the homeContext of a block > > > | homeContext b1 | > homeContext := thisContext. > b1 := [| b2 | > self assert: thisContext closure == b1. > self assert: b1 outerContext == homeContext. > self assert: b1 home = homeContext. > b2 := [self assert: thisContext closure == b2. > self assert: b2 outerContext closure outerContext == > homeContext]. > self assert: b2 home = homeContext. > b2 value]. > b1 value > > > > > > > On Tue, Jul 23, 2013 at 2:02 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> 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. >> > > The outerContext is a link in the static chain. Each block is created > inside some context. This is the block's outerContext. If the block is > not nested then the outerCOntext will also be the home context But if the > block is nested inside another block activation, then the outerContext > refers to that block activation, and the block activation's block's > outerContext is the home context. So there are as many outerContext steps > as there are nesting levels. > > | homeContext b1 | > homeContext := thisContext. > b1 := [| b2 | > self assert: thisContext closure == b1. > self assert: b1 outerContext == homeContext. > b2 := [self assert: thisContext closure == b2. > self assert: b2 outerContext closure outerContext == > homeContext]. > b2 value]. > b1 value > > Ignore the "bN appears to be undefined at this point" and evaluate the > above. No assert fails. > > Draw a picture. > > >> 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 >>> >>> >> >> > > > -- > best, > Eliot > > >

July 25, 2013

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30299 Home: https://github.com/pharo-project/pharo-core

July 25, 2013

[pharo-project/pharo-core] e8dc17: 30299

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: e8dc17cb1e2f94c6f9802d25be5f5d539505777f https://github.com/pharo-project/pharo-core/commit/e8dc17cb1e2f94c6f9802d25… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-07-25 (Thu, 25 Jul 2013) Changed paths: A FuelTools-Debugger/extension/DebugSession/class/encodeDebugInformationOn_.st A FuelTools-Debugger/extension/DebugSession/class/serializeTestFailureContext_toFileNamed_.st A FuelTools-Debugger/extension/DebugSession/instance/serializeStack.st M FuelTools-Debugger/extension/Debugger/class/encodeDebugInformationOn_.st A FuelTools-Debugger/extension/SpecDebugger/class/menuFuelStackAction_.st A FuelTools-Debugger/extension/SpecDebuggerToolbar/instance/serializeStack.st M Kernel-Methods/ContextPart.cls/instance/debugger access/errorReportOn_.st A ScriptLoader30/ScriptLoader.cls/instance/pharo - scripts/script134.st A ScriptLoader30/ScriptLoader.cls/instance/pharo - updates/update30299.st M ScriptLoader30/ScriptLoader.cls/instance/public/commentForCurrentUpdate.st M Spec-Debugger/SpecDebugger.cls/class/menu/menuStackAction_.st M Spec-Debugger/SpecDebugger.cls/class/menu/menuStack_.st Log Message: ----------- 30299 11239 ContextPart>>errorReportOn: uses deprecated methods https://pharo.fogbugz.com/f/cases/11239 11232 Fuel out stack menu entry is missing https://pharo.fogbugz.com/f/cases/11232

July 25, 2013

[update 3.0] #30299

by Marcus Denker

30299 ----- 11239 ContextPart>>errorReportOn: uses deprecated methods https://pharo.fogbugz.com/f/cases/11239 11232 Fuel out stack menu entry is missing https://pharo.fogbugz.com/f/cases/11232 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Debugger-MarcusDenker.10… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1534.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/FuelTools-Debugger-MarcusDenk…

July 25, 2013

Re: [Pharo-dev] thisContext and block

by StÃ©phane Ducasse

For the people following I added a test to show the homeContext of a block | homeContext b1 | homeContext := thisContext. b1 := [| b2 | self assert: thisContext closure == b1. self assert: b1 outerContext == homeContext. self assert: b1 home = homeContext. b2 := [self assert: thisContext closure == b2. self assert: b2 outerContext closure outerContext == homeContext]. self assert: b2 home = homeContext. b2 value]. b1 value > > > On Tue, Jul 23, 2013 at 2:02 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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. > > The outerContext is a link in the static chain. Each block is created inside some context. This is the block's outerContext. If the block is not nested then the outerCOntext will also be the home context But if the block is nested inside another block activation, then the outerContext refers to that block activation, and the block activation's block's outerContext is the home context. So there are as many outerContext steps as there are nesting levels. > > | homeContext b1 | > homeContext := thisContext. > b1 := [| b2 | > self assert: thisContext closure == b1. > self assert: b1 outerContext == homeContext. > b2 := [self assert: thisContext closure == b2. > self assert: b2 outerContext closure outerContext == homeContext]. > b2 value]. > b1 value > > Ignore the "bN appears to be undefined at this point" and evaluate the above. No assert fails. > > Draw a picture. > > > 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 >> >> > > > > > -- > best, > Eliot

July 25, 2013