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

[Pharo-project] remove some unimplemented calls

by Pavel Krivanek

Hi, I published a patch that removes 35 unimplemented calls from Pharo #11240. see http://code.google.com/p/pharo/issues/detail?id=2104 -- Pavel

March 2, 2010

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

by Levente Uzonyi

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. 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 2, 2010

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

by Lukas Renggli

> 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

March 2, 2010

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

by Alexandre Bergel

Hi Henrik, You're very right. I will fix this this evening. Cheers, Alexandre On 2 Mar 2010, at 16:47, 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 :) > 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...) > > 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 2, 2010

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

by Nicolas Cellier

2010/3/2 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > 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. > Hi Steph. It's not a question of preference. It's a question of cross-dialect compatibility and introducing future obscure bugs in Pharo. 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). 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 >

March 2, 2010

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

by StÃ©phane Ducasse

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. > 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

March 2, 2010

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

by Tudor Girba

I agree with these points. Especially with point number 1. Cheers, Doru On 2 Mar 2010, at 21:48, Lukas Renggli wrote: > 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. 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. > > 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 -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

March 2, 2010

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

by StÃ©phane Ducasse

On Mar 2, 2010, at 9:39 PM, 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 Yes I saw. I was confusing a workspace for the transcript. Start!Start!Finish! here too > > |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! > > yay > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 2, 2010

[Pharo-project] [update 1.1] #11240

by StÃ©phane Ducasse

11240 ----- - Issue 1793: Remove SqueakClipBoard. Thanks alain and pavel for fixing my mess. - Polymorph Fix for "compare to current version" in change sets having wrong left/right text. Micellaneous fixes, particularly layout issues. Themed menu item colours to help Hilaire with Sugar theme. - Obsolete reference in 11239. Thanks Pavel Stef

March 2, 2010

[Pharo-project] Undo compiler temporary variable handling

by Lukas Renggli

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. 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. 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

March 2, 2010