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

Re: [Pharo-project] Undo compiler temporary variable handling

by StÃ©phane Ducasse

Thanks lukas I think that we will have to have a look at the changes made to the compiler in 1.0. ;-/ I will wait that marcus shows up but indeed we should fix that Stef >> Do you refer to the fact that we do not get this stupid pop-ups? >> there is preference for that I think. So we could set up by default. >> Did you see it? >> http://code.google.com/p/pharo/issues/detail?id=1224 >> >> Tell me if it helps you and sorry for the inconvenience incomplete progress is >> putting on you. > > I don't know why this was changed? Probably point 1 is an unintended > side-effect of point 2? > > I like the progress that Pharo 1.0 is doing. All in all it is a huge > progress every week. It is only this tiny detail that I find should be > undone :-) > >>> Before going to Pharo 1.0 final, could we please undo the compiler >>> changes that handle the temporary variables? >>> >>> 1) In various code bases I see an increasing number of temp variables >>> that shadow instance variables. >> >> Yes this can be annoying we should find a solution in 1.1. >> http://code.google.com/p/pharo/issues/detail?id=2102 > > I think this has to be changed as soon as possible, e.g. for Pharo 1.0 > final. If somebody pointed me to where this was changed I could even > assemble a fix. > > Point 2 could be a preference (or a lint rule). That doesn't hurry at > all and is fine for Pharo 1.1 (or later). > > Lukas > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 3, 2010

Re: [Pharo-project] Quickly getting the method call stack depth

by StÃ©phane Ducasse

On Mar 3, 2010, at 1:34 AM, Alexandre Bergel wrote: >> Well it seems rather special purpose. What are you using it for? >> Why is the cost impacting your work? > > There is an excellent paper at oopsla'09 that shows the method call > graph can be effectively inferred using the method call stack depth: can you explain it a bit? > http://www-plan.cs.colorado.edu/klipto/mytkowicz-oopsla09.pdf > > Executing "[ running sender notNil ] whileTrue: [ running := running > sender. depth := depth + 1]" before each method execution of my > application terribly slows it down. > > Cheers, > Alexandre > >> >> On 2010-03-02, at 4:06 PM, Alexandre Bergel wrote: >> >>> Will it be of any use for you? If yes, then I will do it. >>> >>> Alexandre >>> >>> >>> On 2 Mar 2010, at 21:00, John M McIntosh wrote: >>> >>>> Maybe you could write a plugin/primitive to do the work? >>>> >>>> On 2010-03-02, at 3:50 PM, Alexandre Bergel wrote: >>>> >>>>> Dear List, >>>>> >>>>> I was wondering whether there is a fast way to know the method call >>>>> stack depth. Something like what follows does the job: >>>>> >>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>> | depth running | >>>>> depth := 0. >>>>> running := thisContext. >>>>> [ running sender notNil ] whileTrue: [ running := running sender. >>>>> depth := depth + 1]. >>>>> depth >>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>> >>>>> But it is rather slow. Anyone has a suggestion? >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> -- >> = >> = >> = >> = >> = >> ====================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http:// >> www.smalltalkconsulting.com >> = >> = >> = >> = >> = >> ====================================================================== >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 3, 2010

Re: [Pharo-project] [ANN] ConfigurationOfTeachable

by StÃ©phane Ducasse

teachable is fun :) I know that adrian kuhn did a nice version handling recursive and others funky situations in VW. I always wanted to use that as an example for reflective programming. On Mar 3, 2010, at 1:19 AM, Torsten Bergmann wrote: > "Teachable" (see [1] and [2]) is now available via Metacello: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfTeachable'; > load. > > ((Smalltalk at: #ConfigurationOfTeachable) project version: '1.0') load: 'all' > > > Bye > T. > > [1] http://astares.blogspot.com/2005/04/teaching-behavior.html > [2] http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-April/038279.ht… > > -- > GMX DSL: Internet, Telefon und Entertainment fÃ¼r nur 19,99 EUR/mtl.! > http://portal.gmx.net/de/go/dsl02 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 3, 2010

Re: [Pharo-project] Undo compiler temporary variable handling

by StÃ©phane Ducasse

I did the following check. We should really get rid of this compiler. In 1.1 and I think that this is the wrong version of the changes that was introduced because the interface sucks ================= Parser warningAllowed: true Object subclass: #Zork instanceVariableNames: 't' zork | t | t := 1. I get t appears to beunused in this method.Ok to remove it? Really? Now indeed my changes (my responsibility of using hernan change) Parser warningAllowed: false Object subclass: #Zork instanceVariableNames: 't' zork | t | t := 1. gets the variable t shadows the instance variables. So for Pharo we get simply for now issue Parser warningAllowed: true to get it to the "normal" behavior In 1.0 ================= Parser warnUser but we have the same silly broken pop up. Now I checked and in 3.9 ================= we got 'Name is already defined.' so it seems that this is not the warning preference that are responsible of the problem. I will ask marcus if he remembers which compiler changes may have Stef

March 3, 2010

Re: [Pharo-project] Undo compiler temporary variable handling

by Lukas Renggli

> I introduced a preference based on hernan changes (for TDD) to avoid to have popup showing up > all the time and I was wondering if this is this change that introduces this bug. > > | a | > a + 1 That's a use of an 'undefined' temp. I haven't noticed that change yet, but indeed that could be problematic too (so we have a 3rd point). Lint already spots that issue today. > was not related to shadowing but to variable usage. So now it may have also cancel the identification > of shadow and this is what I asked lukas to check. When was this change done? Does anybody know? If so, I could look at the diff and propose a change. >> It's a question of cross-dialect compatibility and introducing future >> obscure bugs in Pharo. > > I do not see why this is cross dialect compatibility? Is shadowing variable is not allowed in Smalltalk? ANSI doesn't say anything, so shadowing is probably fine. Generally, I am all for shadowing variables and assignments to arguments, but then the tools should not break. Also it should be consistent, because currently in some cases shadowing is disallowed (instance variables cannot shadow other instance variables, temporary variables and arguments cannot shadow other temporaries and arguments) and in some it is allowed (temps can shadow instance variables, class variables can shadow globals). > In VisualWorks you get a pop up but you can define it. Now that the tool helps you to avoid them when you create them is different than the semantics level. Yes, that's cool (the user is always warned) and it is applied consistent across all types of variables (even instance variables that shadow other instance variables are possible). I think that's the ideal solution. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 3, 2010

Re: [Pharo-project] Pharo by Example vol 2: new chapter available

by StÃ©phane Ducasse

On Mar 2, 2010, at 8:47 PM, Henrik Sperre Johansen wrote: > On 02.03.2010 14:26, StÃ©phane Ducasse wrote: >> Hi guys >> >> We just released a new chapter for Pharo by Example Vol.2 on Exceptions >> http://pharobyexample.org/ >> >> Let us know what you think. >> >> Stef > On p4 there's an error, it says ensure: and ifCurtailed are implemented > as primitives, in fact they use the exact same implementation as > described of the exception handling in 15.1, the primitive is only used > as a marker, and the primitive is required to fail for them to work :) Yes this is more precise > In addition, I'm not too sure what sense it makes to show how to > implement one with the other (nor that the implementations are actually > correct, f.ex. ifCurtailed: block does not trigger on non-local returns...) I would be curious to see if your code is working in GNU Smalltalk. > > Other than that, very nice chapter! > Especially liked 1.9 - 1.13, with the thorough explanation of the > different ways an exception can be returned from. > > Cheers, > Henry > > PS. For the not-so-faint-of-heart, open a Transcript and try evaluating: > |proc| > proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: > 'Finish!' Processor yield.]] newProcess. > proc resume. > Processor yield. > proc suspend. > proc terminate. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 3, 2010

Re: [Pharo-project] [squeak-dev] #ensure: issues (was: Re: Pharo by Example vol 2: new chapter available)

by StÃ©phane Ducasse

On Mar 2, 2010, at 10:33 PM, Levente Uzonyi wrote: > On Tue, 2 Mar 2010, Henrik Sperre Johansen wrote: > >> >>>> PS. For the not-so-faint-of-heart, open a Transcript and try evaluating: >>>> |proc| >>>> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: >>>> 'Finish!' Processor yield.]] newProcess. >>>> proc resume. >>>> Processor yield. >>>> proc suspend. >>>> proc terminate. >>> Why don't we get it printing? >> Forgot a . there, supposed to be >> >> |proc| >> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: >> 'Finish!'. Processor yield.]] newProcess. >> proc resume. >> Processor yield. >> proc suspend. >> proc terminate. >> >> on my machine it prints: >> *Start!Start!Finish! > > The problem occurs because Transcript >> #endEntry (sent from #show:) > takes a while to execute, so the process (proc) prints 'Start!', but > it gets terminated before execution reaches #resetContents (#reset in > Squeak). So 'Start!' is still in the stream. Then our process executes the > #ensure: block and it prints 'Start!' and 'Finish!' too. Thanks for the explanation levente! But I'm still dizzy :) why Transcript show: 'Finish' would also print 'start' ? > > There's worse problem with #ensure: and #terminate is that, a process executing an #ensure: block can be terminated. If you evaluate this code: > > | process stage1 stage2 stage3 counter | > stage1 := stage2 := stage3 := false. > counter := 0. > process := [ > [ stage1 := true ] ensure: [ > stage2 := true. > 1000000 timesRepeat: [ counter := counter + 1 ]. > stage3 := true ] ] newProcess. > process resume. > Processor yield. > process suspend. > process terminate. > 1000 milliSeconds asDelay wait. > { stage1. stage2. stage3. counter } explore > > you will find that stage1 and stage2 is reached as expected, but stage3 is not and counter is less than 1000000. That's because the forked process started evaluating the #ensure: block, but it was terminated by our process. > > Is this the expected behavior when sending #terminate to a process which is evaluating an #ensure: block? > > > Cheers, > BalÃ¡zs & Levente > > >> >> *yay >> Henry* >> * >

March 3, 2010

Re: [Pharo-project] Undo compiler temporary variable handling

by StÃ©phane Ducasse

> Hi Steph. > It's not a question of preference. you got me wrong. I introduced a preference based on hernan changes (for TDD) to avoid to have popup showing up all the time and I was wondering if this is this change that introduces this bug. | a | a + 1 was not related to shadowing but to variable usage. So now it may have also cancel the identification of shadow and this is what I asked lukas to check. > It's a question of cross-dialect compatibility and introducing future > obscure bugs in Pharo. I do not see why this is cross dialect compatibility? Is shadowing variable is not allowed in Smalltalk? In VisualWorks you get a pop up but you can define it. Now that the tool helps you to avoid them when you create them is different than the semantics level. > I'm in the process of debugging Compiler/Decompiler mismatch, and I > can tell you the code is complex enough without shadowed variable. > I'm quite sure you can get large breakage of debugger tool if you ever > allow shadowed tempVars (say as a copiedValue defined inan optimized > block). probably. > Cheers > >>> Before going to Pharo 1.0 final, could we please undo the compiler >>> changes that handle the temporary variables? >>> >>> 1) In various code bases I see an increasing number of temp variables >>> that shadow instance variables. >> >> Yes this can be annoying we should find a solution in 1.1. >> http://code.google.com/p/pharo/issues/detail?id=2102 >> >>> This can lead to subtle bugs in >>> various situations that are very hard to debug. Furthermore consider >>> that the code that shadows instance variables in unlikely to load into >>> any other Smalltalk. >>> >>> 2) In various code bases I see an increasing number of unused >>> temporary variables. Instead of just leaving them in there it would be >>> nice if the compiler removed them right away. >> >> http://code.google.com/p/pharo/issues/detail?id=2103 >>> >>> Point 1 is a *major* annoyance, I already lost hours for that reason. >>> >>> Point 2 is not that important, as it has no intermediate consequences >>> and can be deferred to code critics. I would need to write a new lint >>> rule though. >>> >>> If I knew where these compiler changes were done, I would propose a >>> fix for Pharo 1.0 and 1.1. Any pointers? >> >> >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> 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

March 3, 2010

Re: [Pharo-project] Quickly getting the method call stack depth

by Eliot Miranda

On Tue, Mar 2, 2010 at 4:34 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > > Well it seems rather special purpose. What are you using it for? > > Why is the cost impacting your work? > > There is an excellent paper at oopsla'09 that shows the method call > graph can be effectively inferred using the method call stack depth: > http://www-plan.cs.colorado.edu/klipto/mytkowicz-oopsla09.pdf > > Executing "[ running sender notNil ] whileTrue: [ running := running > sender. depth := depth + 1]" before each method execution of my > application terribly slows it down. > If you did your own VM you could do something like - add a stack depth counter incremented and decremented on each call/return, voided on each non-local return, terminateTo: etc - cache it in a per-process inst var and store/restore it on process switch But this will be difficult to get right (e.g. delimited continuations, coroutines). could you cache it in various activations? e.g. something like Notification subclass: StackDepthQuery defaultAction ^nil Object methodsFor: performance monitoring cachingStackDepthDo: aBlock | home cachedStackDepth | home := thisContext. ^aBlock on: StackDepthQuery do: [:ex| ex proceedWith: (cachedStackDepth ifNil: [cachedStackDepth := self computeStackDepthFrom: home)] and then have StackDepthQuery count the stack frames as it searches for a handler. This is tricky because the exception machinery defers to ContextPart to do the search. You'd have to override a few methods. But this way you'd be able to cut short the counting adding cachingStackDepthDo:'s at suitable points until profiling showed the overhead was acceptable. > Cheers, > Alexandre > > > > > On 2010-03-02, at 4:06 PM, Alexandre Bergel wrote: > > > >> Will it be of any use for you? If yes, then I will do it. > >> > >> Alexandre > >> > >> > >> On 2 Mar 2010, at 21:00, John M McIntosh wrote: > >> > >>> Maybe you could write a plugin/primitive to do the work? > >>> > >>> On 2010-03-02, at 3:50 PM, Alexandre Bergel wrote: > >>> > >>>> Dear List, > >>>> > >>>> I was wondering whether there is a fast way to know the method call > >>>> stack depth. Something like what follows does the job: > >>>> > >>>> -=-=-=-=-=-=-=-=-=-=-=-= > >>>> | depth running | > >>>> depth := 0. > >>>> running := thisContext. > >>>> [ running sender notNil ] whileTrue: [ running := running sender. > >>>> depth := depth + 1]. > >>>> depth > >>>> -=-=-=-=-=-=-=-=-=-=-=-= > >>>> > >>>> But it is rather slow. Anyone has a suggestion? > >>>> > >>>> Cheers, > >>>> Alexandre > >>>> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>>> Alexandre Bergel http://www.bergel.eu > >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- > > = > > = > > = > > = > > = > > ====================================================================== > > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > > squeaker68882 > > Corporate Smalltalk Consulting Ltd. http:// > > www.smalltalkconsulting.com > > = > > = > > = > > = > > = > > ====================================================================== > > > > > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 3, 2010

Re: [Pharo-project] Scamper revival

by Schwab,Wilhelm K

I have never bought into "make Smalltalk more like <insertBuzzword> and the world will like us" because things don't work that way. The analogies to US politics are biting - without going into details, it does not work there either. The most recent "do it or else" was .Net. Before that, Java was the answer. Remember Object Linking and Embedding - the entire world was going to be components. DCOM is the answer, what's wrong with you? Fat clients, thin clients, Lotus Notes, VBA or bust!!! Now it's "The Cloud." Some of these things are actually useful for many tasks; most are good for _something_. If HTML 5 proves itself, we'll end up embracing it, but not because it will make people like us. People who want to find fault with anything that is not the latest hype-compliant technology will never run out of complaints to wave in our faces. The trick is to separate the truly worthy points from the talking points taken from glossy ads. Bill -----Original Message----- From: Eagle Offshore [mailto:eagleoffshore@mac.com] Sent: Tuesday, March 02, 2010 8:42 PM To: Schwab,Wilhelm K Subject: Re: [Pharo-project] Scamper revival I meant to keep my last comment off list. My bad. This one is also off list. I'm not talking web apps. I think you missed that. I'm talking about a platform for writing desktop apps. It happens to use widgets implemented using html and css with logic in javascript, but its not terribly different from a smalltalk environment with its own widget kit. I think Dan was a little early with lively kernel, but I think if he updated it for HTML 5 he'd find the world quite a bit more receptive. On Mar 2, 2010, at 2:34 AM, Schwab,Wilhelm K wrote: > 'm not writing portable web apps, which is exactly my point: web technologies have their purposes and limitations, and attempts to use them as some type of intergalactic-fix-all is probably going to work out poorly.

March 3, 2010