August 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Videos ESUG2014

by Torsten Bergmann

Esteban A. Maringolo wrote > Can the esugboard YouTube administrator put the ESUG 2014 playlist in order? You mean like that: https://www.youtube.com/playlist?list=PLJ5nSnWzQXi_6yyRLsMMBqG8YlwfhvB0X

Aug. 22, 2014

Re: [Pharo-dev] Videos ESUG2014

by Esteban A. Maringolo

Can the esugboard YouTube administrator put the ESUG 2014 playlist in order? Most videos are in two or three parts, and in reverse order. It is... Part 2/2 and then Part 1/2. Etc. Thank you for making the videos available so soon. Esteban A. Maringolo 2014-08-22 16:05 GMT-03:00 milton mamani <akevalion(a)gmail.com>: > Hi guys, > > To see the videos from this ESUG, try: > > http://goo.gl/E1VF53 > > Best Regards, > Milton

Aug. 22, 2014

Re: [Pharo-dev] Stack size for compiled methods (issue 13854 Crash/hang on array access)

by Nicolas Cellier

2014-08-21 9:09 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > 2014-08-21 7:14 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > >> >> >> On Wed, Aug 20, 2014 at 10:15 PM, Nicolai Hess <nicolaihess(a)web.de> >> wrote: >> >>> >>> 2014-08-19 19:02 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> >>> Hi Nicolai, >>>> >>>> >>>> On Aug 19, 2014, at 11:58 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: >>>> >>>> Thank you eliot, >>>> >>>> >>>> 2014-08-19 7:29 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>> >>>>> Hi Nicolai, >>>>> >>>>> the stack starts as deep as the method's number of temporaries, >>>> >>>> >>>> ok, >>>> >>>> >>>>> which is the sum of the number of arguments >>>> >>>> >>>> ok, >>>> >>>> >>>>> plus the number of temporary variables that can exist in the stack >>>> >>>> >>>> ok (what does "can exist in the stack" mean? They always do?) >>>> >>>> >>>> Not necessarily. The closure implementation moves temps that need it >>>> into an indirect temp vector. See eg my blog on the closure compiler. >>>> >>>> http://www.mirandabanda.org/cogblog/2008/06/07/closures-part-i/ >>>> >>>> plus one if there are any closed-over temporary variables that need to >>>>> be in an indirection vector. Then as execution proceeds the receiver and >>>>> arguments are pushed on the stack, and are replaced by intermediate results >>>>> by sends it by the create array bytecode. >>>> >>>> >>>> So, for a method with no blocks, the stack is just the number of >>>> temporaries plus the number of args for the message send with the maximum >>>> number of args? >>>> >>>> >>>> >>>> No. What about this: >>>> >>>> ^Point x: 1 y: (self a: 1 b: 2 c: 3) >>>> >>>> >>>> Before sending a:b:c: the stack is >>>> >>>> Point >>>> 1 >>>> self >>>> 1 >>>> 2 >>>> 3 >>>> >>>> >>>> Any blocks within the method start with the sum of their number of >>>>> arguments, their number of copied values (temp values they access >>>>> read-only) plus their local temporaries. >>>>> >>>> >>>> But this is not just added to the stack size, right? >>>> I have a method with 9 local temporaris and a block in this method with >>>> 8 local temporaries and the frameSize is still 16, (with the old compiler/ >>>> 56 with the new compiler). >>>> So, method and block local temporaries not just sum up? >>>> I tried different variations >>>> - numberOfMethod temps smaller/equal/greater numberOfBlockTemp >>>> - no/some/all method temporaries are accessed in the block closure. >>>> >>>> But I can not see a pattern :) >>>> >>>> >>>> May be a bug in the old compiler. The stack size is the max of the >>>> separate sizes in the method and each block. >>>> >>>> >>>> >>>> >>>>> >>>>> In the method and each block scope stack depth is the hence the sum of >>>>> the number of temporaries plus the max execution depth. And the method's >>>>> depth is the max of the method and that of any blocks within it. >>>> >>>> >>>> What is the execution depth of a method ? The number of "nested blocks"? >>>> >>>> >>>> No, it is how many things it pushes in the stack at the deepest point. >>>> See my example above. >>>> >>>> >>>> >>>>> Then if that depth is 17 or greater it gets the LargeFrame flag set >>>>> which means the VM allocates a 56 slot context, the compiler raising an >>>>> error if the depth is greater than 56. >>>>> >>>>> HTH >>>>> Eliot (phone) >>>>> >>>> >>>> Here are two carefully handcrafted methods :) >>>> >>>> >>>> fooSmall >>>> |t1 t2 t3 t4 t5 t6 t7 t8| >>>> t1:=1. >>>> t2:=2. >>>> t3:=3. >>>> t4:=4. >>>> t5:=5. >>>> t6:=6. >>>> t7:=7. >>>> t8:= 8. >>>> t1:=[:i | |b1 b2 b3 b4 c1 c2 c3 c4 x| >>>> b1:=1. b2:=2. b3:=3. b4:=4. >>>> c1:=1. c2:=2. c3:=3. c4:=4. >>>> x:=1. >>>> x+t1 + b1+b2+b3+b4 + c1 + c2 + c3 + c4] value:1. >>>> ^ t1 + t2 + t3 + t4 + t5 + t6 + t7 + t8 >>>> >>>> >>>> fooLarge >>>> |t1 t2 t3 t4 t5 t6 t7| >>>> t1:=1. >>>> t2:=2. >>>> t3:=3. >>>> t4:=4. >>>> t5:=5. >>>> t6:=6. >>>> t7:=7. >>>> t1:=[:i | |b1 b2 b3 b4 c1 c2 c3 c4 x| >>>> b1:=1. b2:=2. b3:=3. b4:=4. >>>> c1:=1. c2:=2. c3:=3. c4:=4. >>>> x:=1. >>>> x+t1 +t2 + t3 + t4 + t5+ b1+b2+b3+b4 + c1 + c2 + c3 + c4] value:1. >>>> ^ t1 + t2 + t3 + t4 + t5 + t6 + t7 >>>> >>>> >>>> >>>> They differ only in the number of tempraries (t1-t8 / t1-t7) and the >>>> number of copied values for the block closure (1 / 5). >>>> >>>> with the old compiler: >>>> fooSmall frameSize -> 16 >>>> fooLarge frameSize -> 56 >>>> >>>> >>>> >>>> the opal compiler computes the opposite sizes >>>> fooSmall frameSize -> 56 >>>> fooLarge frameSize -> 16 >>>> >>>> >>>> >>>> Looks like a bug in the Opal compiler :-). Well found. >>>> >>>> >>>> >>>> I am confused. >>>> >>>> >>>> No you're not. You've found a bug. Now find its cause.... >>>> >>> >>> >>> No, I am still confused :) >>> >>> Maybe you can help me with, how the old compiler computes the stack >>> frame in this examples: >>> >>> I changed CompiledMethod>>#needsFrameSize: >>> to write the value for self numTemps and newFrameSize to the Transcript >>> and compiled some simple functions: >>> >>> foo >>> |a b| >>> a:=1. >>> b:=1. >>> ^ a+b >>> >>> numTemps:2 >>> frameSize: 2 >>> >>> ok, two temps and two pushes on the stack >>> >>> >>> foo >>> ^ [ 1+1 ] >>> >>> numTemps:0 >>> frameSize: 2 >>> >>> ok, no temps and two pushs (push constant:1/push constant:1) on the stack >>> >>> >>> >>> >>> >>> foo >>> ^ [|a b| a:=1. b:=1. a+b ] >>> >>> numTemps:0 >>> frameSize: 4 >>> >>> ok, no (method) temps, why is the stackframe 4? Two block local temps >>> and two pushs. >>> >>> >>> |x y| >>> x:=1. >>> y:=1. >>> ^ [|a b| a:=1. b:=1. a+b ] >>> >>> numTemps:2 >>> frameSize: 2 >>> >>> Now what? Adding method temps enlarges the number of temps, ok. But the >>> stackframe decreases? >>> >> >> Looks like a bug. The stack size needed in >> >> |x y| >> x:=1. >> y:=1. >> ^ [|a b| a:=1. b:=1. a+b ] >> >> is 4, unless the compiler is optimizing away the a+b and is replacing the >> block with [1] ? The stack size of the outer method is 3 (2 temps + 1 for >> the push of either 1 or the block). >> > > > No optimization, the bytecode is: > > 13 <76> pushConstant: 1 > 14 <68> popIntoTemp: 0 > 15 <76> pushConstant: 1 > 16 <69> popIntoTemp: 1 > 17 <8F 00 00 0A> closureNumCopied: 0 numArgs: 0 bytes 21 to 30 > 21 <73> pushConstant: nil > 22 <73> pushConstant: nil > 23 <76> pushConstant: 1 > 24 <68> popIntoTemp: 0 > 25 <76> pushConstant: 1 > 26 <69> popIntoTemp: 1 > 27 <10> pushTemp: 0 > 28 <11> pushTemp: 1 > 29 <B0> send: + > 30 <7D> blockReturn > 31 <7C> returnTop > > > The pushConstant: nil are here to initialize the local temps, so they should be followed by a popIntoTemp: 0 (resp. 1) If those pop have been optimized away, so should the push, otherwise this makes a depth 6 necessary (2 temps + 4 push), and an imbalanced stack - probably harmless, the blockReturn unwind correctly (?). > >> >> >> >>> Nicolai >>> >>> >>> >>>> >>>> >>>> >>>> >>>>> >>>>> On Aug 18, 2014, at 11:32 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >>>>> >>>>> > Hi, >>>>> > >>>>> > on what depends the stack size for a compiled method? >>>>> > I try to figure out, why the old compiler and the opal compile >>>>> generate different >>>>> > compiled method headers. >>>>> > I think this comes from a wrong stack size computed by opal, but I >>>>> can not figure >>>>> > out how the stack size is computed. >>>>> > >>>>> > Old Compiler >>>>> > PolygonMorph>>#lineSegmentsDo: >>>>> > header -> "primitive: 0 >>>>> > numArgs: 1 >>>>> > numTemps: 3 >>>>> > numLiterals: 23 >>>>> > frameSize: 56" >>>>> > >>>>> > Opal compiler: >>>>> > PolygonMorph>>#lineSegmentsDo: >>>>> > header -> "primitive: 0 >>>>> > numArgs: 1 >>>>> > numTemps: 3 >>>>> > numLiterals: 23 >>>>> > frameSize: 16" >>>>> > >>>>> >>>> >>>> >>>> Eliot (phone) >>>> >>> >>> >> >> >> -- >> best, >> Eliot >> > >

Aug. 22, 2014

Re: [Pharo-dev] Videos ESUG2014

by Yuriy Tymchuk

Where is mine? :) Uko On 22 Aug 2014, at 20:05, milton mamani <akevalion(a)gmail.com> wrote: > Hi guys, > > To see the videos from this ESUG, try: > > http://goo.gl/E1VF53 > > Best Regards, > Milton

Aug. 22, 2014

Videos ESUG2014

by milton mamani

Hi guys, To see the videos from this ESUG, try: http://goo.gl/E1VF53 Best Regards, Milton

Aug. 22, 2014

[pharo-project/pharo-core] d87a88: 40178

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: d87a88dc73c38601ccb3c1ca2ef3c13f6445fd2b https://github.com/pharo-project/pharo-core/commit/d87a88dc73c38601ccb3c1ca… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-08-22 (Fri, 22 Aug 2014) Changed paths: A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script177.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40177.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40178 http://files.pharo.org/image/40/40178.zip

Aug. 22, 2014

[pharo-project/pharo-core]

by GitHub

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

Aug. 22, 2014

Re: [Pharo-dev] Beacon and SystemLogger united

by Norbert Hartl

I'm glad we could get together and settle a few things. And it didn't take long. That is the advantage to meet in person. And the things we decided are a step forward. So thanks, Norbert Am 20.08.2014 um 18:42 schrieb stepharo <stepharo(a)free.fr>: > Hi > > what I like with conferences like ESUG is that we can meet other people. We got some great > discussions with Doru and Norbert about logging. And we will unite the two frameworks into a > a variation of Beacon. > > Thinking about it, I clearly overreacted when Doru announced Beacon and I'm clear with it. > I'm not an easy guy from that perspective but I have no problem to try to understand and recognize > other ideas. I think that this is partly the effect of mail communication. > Retrospectively I was so into wanted to remove all > these strings from everywhere that I received Beacon (which at the end was trying to help > defining a cool logger) as a sign that I lost my energy on building SystemLogger. Now > I think that if I would not have built SystemLogger, we would not have got Beacon and our discussions > would have been way poorer. > So we will start to migrate some of the SystemLogger code to Beacon, rename some Beacon class, > and write a new documentation and integrate all that into Pharo. > > Stef >

Aug. 22, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] 42e23d: 40177

by Marcus Denker

40177 ----- 13883 RBConfigurableFormatter retain blank lines between statements and comments https://pharo.fogbugz.com/f/cases/13883 13839 3 tests failing due to #stepGlobal call to Transcript https://pharo.fogbugz.com/f/cases/13839 13881 Refactoring to PSMCPatchMorph to allow dispatching https://pharo.fogbugz.com/f/cases/13881 On 22 Aug 2014, at 10:22, GitHub <noreply(a)github.com> wrote: > Branch: refs/heads/4.0 > Home: https://github.com/pharo-project/pharo-core > Commit: 42e23d3c0e2db5ca1adcf20dec6df3236c076368 > https://github.com/pharo-project/pharo-core/commit/42e23d3c0e2db5ca1adcf20d… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2014-08-22 (Fri, 22 Aug 2014) > > Changed paths: > A AST-Core.package/RBConfigurableFormatter.class/class/accessing/retainBlankLinesBeforeComments.st > A AST-Core.package/RBConfigurableFormatter.class/class/accessing/retainBlankLinesBeforeComments_.st > M AST-Core.package/RBConfigurableFormatter.class/class/initialization/initialize.st > M AST-Core.package/RBConfigurableFormatter.class/class/settings/settingsOn_.st > M AST-Core.package/RBConfigurableFormatter.class/definition.st > M AST-Core.package/RBConfigurableFormatter.class/instance/private-formatting/formatStatementCommentsFor_.st > M HelpSystem-Tests.package/CustomHelpTest.class/instance/testing/testOpenBrowserOnThisHelpType.st > M HelpSystem-Tests.package/WikiStyleHelpTest.class/instance/testing/testOpenBrowserOnThisHelpType.st > A Monticello.package/MCDefinition.class/instance/accessing/definition.st > A NonInteractiveTranscript.package/NonInteractiveTranscript.class/instance/private/stepGlobal.st > A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/README.md > A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/class/helper methods/group_.st > A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/definition.st > A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/grouping/ensureClassChangeWrapperNamed_.st > A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/grouping/group.st > A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/grouping/model_.st > A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/grouping/visit_.st > A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/initialization/initialize.st > A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/visitor/visitClassDefinition_.st > A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/visitor/visitDefaultDefinition_.st > A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/visitor/visitMetaclassDefinition_.st > A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/visitor/visitMethodDefinition_.st > A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/visitor/visitOrganizationDefinition_.st > A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/visitor/visitScriptDefinition_.st > A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/visitor/visitTraitDefinition_.st > M Polymorph-Tools-Diff.package/PSMCPatchMorph.class/instance/accessing/changes.st > A Polymorph-Tools-Diff.package/PSMCPatchMorph.class/instance/initialization/model.st > A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script176.st > A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40176.st > M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > > Log Message: > ----------- > 40177 > > http://files.pharo.org/image/40/40177.zip > >

Aug. 22, 2014

[pharo-project/pharo-core] 42e23d: 40177

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 42e23d3c0e2db5ca1adcf20dec6df3236c076368 https://github.com/pharo-project/pharo-core/commit/42e23d3c0e2db5ca1adcf20d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-08-22 (Fri, 22 Aug 2014) Changed paths: A AST-Core.package/RBConfigurableFormatter.class/class/accessing/retainBlankLinesBeforeComments.st A AST-Core.package/RBConfigurableFormatter.class/class/accessing/retainBlankLinesBeforeComments_.st M AST-Core.package/RBConfigurableFormatter.class/class/initialization/initialize.st M AST-Core.package/RBConfigurableFormatter.class/class/settings/settingsOn_.st M AST-Core.package/RBConfigurableFormatter.class/definition.st M AST-Core.package/RBConfigurableFormatter.class/instance/private-formatting/formatStatementCommentsFor_.st M HelpSystem-Tests.package/CustomHelpTest.class/instance/testing/testOpenBrowserOnThisHelpType.st M HelpSystem-Tests.package/WikiStyleHelpTest.class/instance/testing/testOpenBrowserOnThisHelpType.st A Monticello.package/MCDefinition.class/instance/accessing/definition.st A NonInteractiveTranscript.package/NonInteractiveTranscript.class/instance/private/stepGlobal.st A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/README.md A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/class/helper methods/group_.st A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/definition.st A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/grouping/ensureClassChangeWrapperNamed_.st A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/grouping/group.st A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/grouping/model_.st A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/grouping/visit_.st A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/initialization/initialize.st A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/visitor/visitClassDefinition_.st A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/visitor/visitDefaultDefinition_.st A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/visitor/visitMetaclassDefinition_.st A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/visitor/visitMethodDefinition_.st A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/visitor/visitOrganizationDefinition_.st A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/visitor/visitScriptDefinition_.st A Polymorph-Tools-Diff.package/PSMCChangesGrouper.class/instance/visitor/visitTraitDefinition_.st M Polymorph-Tools-Diff.package/PSMCPatchMorph.class/instance/accessing/changes.st A Polymorph-Tools-Diff.package/PSMCPatchMorph.class/instance/initialization/model.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script176.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40176.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40177 http://files.pharo.org/image/40/40177.zip

Aug. 22, 2014