- Pharo-dev - lists.pharo.org

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

by Schwab,Wilhelm K

There might be not guarantee that it *can* run the code (an exception might be raised ending the block, it might find itself waiting on an unsignaled semaphore, etc.), but it should be **guaranteed** an opportunity to begin. IIRC, Dolphin provides special handling to temporarily restart processes in order to get this right. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Tuesday, March 02, 2010 4:57 PM To: The general-purpose Squeak developers list Cc: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] #ensure: issues (was: Re: Pharo by Example vol 2: new chapter available) 2010/3/2 Levente Uzonyi <leves(a)elte.hu>: > 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? > > What you think is expected behavior here: a) process termination should start (be triggered) only when process is outside of any #ensure: closure? b) #ensure: block should always run to the end, despite anything? Since you can't predict, what code will run inside ensure block, the only guarantee that you having is actually that your process will always enters such blocks during the normal flow, or exception handling. But there is no guarantees that it will be able to run the code inside it, when you terminating it. > Cheers, > BalÃ¡zs & Levente > > >> >> *yay >> Henry* >> * > > > > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ 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] [squeak-dev] #ensure: issues (was: Re: Pharo by Example vol 2: new chapter available)

by Igor Stasenko

2010/3/2 Levente Uzonyi <leves(a)elte.hu>: > 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? > > What you think is expected behavior here: a) process termination should start (be triggered) only when process is outside of any #ensure: closure? b) #ensure: block should always run to the end, despite anything? Since you can't predict, what code will run inside ensure block, the only guarantee that you having is actually that your process will always enters such blocks during the normal flow, or exception handling. But there is no guarantees that it will be able to run the code inside it, when you terminating it. > Cheers, > BalÃ¡zs & Levente > > >> >> *yay >> Henry* >> * > > > > -- Best regards, Igor Stasenko AKA sig.

March 2, 2010

[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