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

Re: [Pharo-dev] ConfigurationOfNastyJokes

by Ben Coman

stepharo wrote: > :) > > indeed this is tricky program. > > Stef I wouldn't smile :) I'd take this as notice that as Pharo becomes more popular, it becomes more of a target - the rewards are greater and therhave a wider pool from which . You can't really trust that the Author is as shown attached to the packages. Perhaps a feature to consider for Pharo 5 is some infrastructure for the Author to be by digital certificate rather than just typing text when prompted. Maybe we'll get this anyway with git integration. >> ConfigurationOfNastyJokes in MetaRepoForPharo30 looks like the >> first Pharo based virus. >> >> Havent loaded it as advised but from the MC Snapshot browser it looks >> like the code is doing some image saving, process removing, ... >> >> While I understand the fun side of it I would: >> - recommend not to load it ;) >> - recommend that we delete this config from MetaRepoForPharo30 >> >> Thx >> T. >> >> > > >

Aug. 21, 2014

Smalltalk Hub Slooooowdown

by Sean P. DeNigris

"Loading. Please wait." indefinitely on both Chrome and Safari (Mac 10.9.3) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Smalltalk-Hub-Slooooowdown-tp4773992.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 21, 2014

Re: [Pharo-dev] Beacon and SystemLogger united

by stepharo

:) Some guys like me and (camillo) for example are more in straight line thinking but you are so right. Stef On 20/8/14 18:53, Sean P. DeNigris wrote: > stepharo wrote >> 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. > This is real wisdom. I too struggle with what appears to be duplication of > efforts, but I'm reminded of two related themes which Alan Kay talks about a > lot: > - evolution is closer to a random walk with a slight bias than a straight > line > - in biology, what often appears in human illustration/simulation as > components interacting in lock-step as if on a track is actually fortuitous, > made possible by the tremendous speed and energy of everything going on in > the cell > > So, as you discovered, and I need to be repeatedly reminded of, there is no > perfect world where the stars align and each piece moves with speed and > precision into its predestined place in the whole. There is only a sloppy, > often frustrating, two-steps-forward-one-step-back frenzy where what comes > out on the other side is hopefully better than what we started with. Said > more simply: "this is what winning looks like" > > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Beacon-and-SystemLogger-united-tp4773973p4773975.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Aug. 20, 2014

Re: [Pharo-dev] ConfigurationOfNastyJokes

by stepharo

:) indeed this is tricky program. Stef > ConfigurationOfNastyJokes in MetaRepoForPharo30 looks like the > first Pharo based virus. > > Havent loaded it as advised but from the MC Snapshot browser it looks > like the code is doing some image saving, process removing, ... > > While I understand the fun side of it I would: > - recommend not to load it ;) > - recommend that we delete this config from MetaRepoForPharo30 > > Thx > T. > >

Aug. 20, 2014

ConfigurationOfNastyJokes

by Torsten Bergmann

ConfigurationOfNastyJokes in MetaRepoForPharo30 looks like the first Pharo based virus. Havent loaded it as advised but from the MC Snapshot browser it looks like the code is doing some image saving, process removing, ... While I understand the fun side of it I would: - recommend not to load it ;) - recommend that we delete this config from MetaRepoForPharo30 Thx T.

Aug. 20, 2014

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

by Nicolai Hess

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

Aug. 20, 2014

Re: [Pharo-dev] Beacon and SystemLogger united

by Sean P. DeNigris

stepharo wrote > 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. This is real wisdom. I too struggle with what appears to be duplication of efforts, but I'm reminded of two related themes which Alan Kay talks about a lot: - evolution is closer to a random walk with a slight bias than a straight line - in biology, what often appears in human illustration/simulation as components interacting in lock-step as if on a track is actually fortuitous, made possible by the tremendous speed and energy of everything going on in the cell So, as you discovered, and I need to be repeatedly reminded of, there is no perfect world where the stars align and each piece moves with speed and precision into its predestined place in the whole. There is only a sloppy, often frustrating, two-steps-forward-one-step-back frenzy where what comes out on the other side is hopefully better than what we started with. Said more simply: "this is what winning looks like" ----- Cheers, Sean -- View this message in context: http://forum.world.st/Beacon-and-SystemLogger-united-tp4773973p4773975.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 20, 2014

Re: [Pharo-dev] Looking for suggestions for extended Pharo/Smalltalk intro demo

by stepharo

Oscar have a look at my DSL chapter (in PFTE) https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/724/artifa… and video http://stephane.ducasse.free.fr/Videos/2013-04-20-Dice-v3.mov it shows tests class extensions loops DSL I use it for my lectures and it was fun to do live. In Lviv the other students explained to my black jack on the fly and I developed test first. But I do not remember the game :) You can build it live and after you have the exercises that they can do. Look into the git repo because you get the exercises in skeleton mode. So they have to build step by step the exercises On 20/8/14 16:07, Oscar Nierstrasz (gmail) wrote: > Hi Folks, > > I will be teaching a Software Design and Evolution course this Fall in which we use a lot of Smalltalk. For the introduction to Smalltalk lecture I wanted to give an extended demo with some slides in between rather than mainly showing slideware. > > Does anyone have a good recommendation for an application to build with the students while showing off most of the important features of the language and the environment? Ideally something you have used before in precisely this way. > > Some things I have used in the past: > - Post Office example (small and boring) > - Snakes and Ladders (a bit too big) > > Thanks for suggestions. > > Oscar >

Aug. 20, 2014

Beacon and SystemLogger united

by stepharo

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. 20, 2014

Re: [Pharo-dev] Transcript class allInstances does not list all instances

by Camille Teruel

Hi Oscar, It's because Transcript is only one instance of ThreadSafeTranscript. 'Transcript open' doesn't create a new instance but opens a new window on that instance. Camille On 20 aoÃ»t 2014, at 17:30, Oscar Nierstrasz (gmail) <oscar.nierstrasz(a)gmail.com> wrote: > > In the latest Pharo 3 for Mac: > > Transcript open. > Transcript open. > Transcript class allInstances inspect > > only shows one instance, not two. > > Why? > > Oscar >

Aug. 20, 2014