June 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Object>>#if:then:else:

by Goubier Thierry

Hi Camille, It's not bad as things goes, because it does look a bit like non-smalltalk code (i.e. the if then else structure) except that the precise meaning is very much Smalltalk : if: has a receiver, and there is a not so intuitive relationship between the bloc parameters and the receiver. Honestly, as far as code reviews goes, I'll prefer the temp refactoring. Understandable without having to search for the implementors of #if:then:else: Regards, Thierry Le 18/06/2013 10:51, Camille Teruel a Ã©crit : > Hello everyone. > > I see a lot of code that follows the following pattern: > > <a long expression> <aComplexTest> > ifTrue: [ <a long expression> <something> ] > ifFalse: [ <a long expression> <something else> ]. > > The classic refactoring is to store <a long expression> in a temp to > avoid repetition: > > | temp | > temp := <a long expression>. > temp <aComplexTest> > ifTrue: [ temp <something> ] > ifFalse: [ temp <something else> ]. > > Then <a long expression> is evaluated once and the name of the temp can > carry a meaningful name that helps reading the code. > But this is more verbose than the first version. > But if you add the following method in Object: > > if: conditionBlock then: trueBlock else: falseBlock > ^ (conditionBlock cull: self) > ifTrue: [ trueBlock cull: value ] > ifFalse: [ falseBlock cull: value ] > > You can then rewrite it like that: > > <a long expression> > if: [ :obj | obj <aComplexTest> ] > then: [ :obj | <something> ] > else: [ :obj | <something else> ] > > The names of the block args can give a meaningful name depending on the > result of the test (something like ... if: #notEmpty then: [ :collection > | ... ] else: [ :emptyCollection | ... ]). Using cull: for the three > block also enable a good flexibility: you can omit the arg when irrelevant. > > Likewise, we could also have Object>>#while:do: > > while: conditionBlock do: actionBlock > ^ [ conditionBlock cull: self ] whileTrue: [ actionBlock cull: self ] > > What do you think? > > Camille -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 18, 2013

Re: [Pharo-dev] There are still lots of Delay>>wait Processes

by Igor Stasenko

On 18 June 2013 11:11, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Once igor finishes the TxModel and Athens it was planned to address the Delay problem. > I don't think i am the only one who capable to fix it. :) Something broken in restoring Delay(s) after image restart (they hanging for too far in the future). That's my impression. >From other side, i do not see why Cookie should use [ Delay forEons wait] fork. Instead, i would just replace implementation with code which checks the time before giving answer of cookie value. So, if you won't use cookie value in heavy numerical-crunchy calculations, this is completely fine. > Stef -- Best regards, Igor Stasenko.

June 18, 2013

Re: [Pharo-dev] About validation

by StÃ©phane Ducasse

On Jun 17, 2013, at 2:08 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > StÃ©phane Ducasse wrote >> Are you interested to get your name with the one of Ze fabulous crazy >> french researcher? >> What a fame, isnt? > > Ha ha, I can see the paparazzi lining up now ;) I'd be happy to help. I'm > exploring and experimenting with validation, so my ideas are still > developing rapidly. I'd like to see how to integrate Andres' ideas with > Magritte's approachâ¦ Ok now my approch is divide and conquer. I would like to write a ***simple*** chapter on a simple SUNit extension so that people can see and use the idea. Then if one guy wnats to build a mega nuclear weapon it is possible :) Stef > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Pharo-dev-About-validation-tp4693434p4693704.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

June 18, 2013

Re: [Pharo-dev] There are still lots of Delay>>wait Processes

by StÃ©phane Ducasse

Once igor finishes the TxModel and Athens it was planned to address the Delay problem. Stef

June 18, 2013

Re: [Pharo-dev] Object>>#if:then:else:

by StÃ©phane Ducasse

is it not slower? and I would remove as much as method as possible from Object. why > | temp | > temp := <a long expression>. > temp <aComplexTest> > ifTrue: [ temp <something> ] > ifFalse: [ temp <something else> ]. is not good enough? And finally we should kill as much as possible of these ifâ¦. so > Hello everyone. > > I see a lot of code that follows the following pattern: > > <a long expression> <aComplexTest> > ifTrue: [ <a long expression> <something> ] > ifFalse: [ <a long expression> <something else> ]. > > The classic refactoring is to store <a long expression> in a temp to avoid repetition: > > | temp | > temp := <a long expression>. > temp <aComplexTest> > ifTrue: [ temp <something> ] > ifFalse: [ temp <something else> ]. > > Then <a long expression> is evaluated once and the name of the temp can carry a meaningful name that helps reading the code. > But this is more verbose than the first version. > But if you add the following method in Object: > > if: conditionBlock then: trueBlock else: falseBlock > ^ (conditionBlock cull: self) > ifTrue: [ trueBlock cull: value ] > ifFalse: [ falseBlock cull: value ] > > You can then rewrite it like that: > > <a long expression> > if: [ :obj | obj <aComplexTest> ] > then: [ :obj | <something> ] > else: [ :obj | <something else> ] > > The names of the block args can give a meaningful name depending on the result of the test (something like ... if: #notEmpty then: [ :collection | ... ] else: [ :emptyCollection | ... ]). Using cull: for the three block also enable a good flexibility: you can omit the arg when irrelevant. > > Likewise, we could also have Object>>#while:do: > > while: conditionBlock do: actionBlock > ^ [ conditionBlock cull: self ] whileTrue: [ actionBlock cull: self ] > > What do you think? > > Camille

June 18, 2013

Re: [Pharo-dev] Changing ConfigurationOfCog

by StÃ©phane Ducasse

I would simplify :) Stef On Jun 18, 2013, at 10:26 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi guys! > > I worked yesterday on making VMMaker load and work in Pharo2.0 with filesystem. Now, I want to push my changes in a new development version of ConfigurationOfCog. But I have some questions: > > Is ConfigurationOfCog used by other people besides Pharo? > > Because so far I see: > - there are two different groups in the conf: #common and #pharo. > - In #common, there is CMakeVMMaker (which in turn loads cairo from files.pharo.org :)) and the oscog branch of VMMaker. Both have only as latest committers Igor and Esteban :P. And I > - in #pharo there are nativeboost and some compatibility packages. > > So there are pharo specific stuff in both groups, or am I mistaken? Should we keep both groups, or make them one and simplify? And how should I push my changes related with filesystem (pharo-specific) then? > > Guille

June 18, 2013

Re: [Pharo-dev] There are still lots of Delay>>wait Processes

by Sven Van Caekenberghe

On 18 Jun 2013, at 10:38, Camillo Bruni <camillobruni(a)gmail.com> wrote: > the original issue you posted was closed because it is a duplicate of this one > https://pharo.fogbugz.com/default.asp?7526 I saw that, but the title is too restrictive I think. > where you will fine a proper script to kill hanging processesâ¦ OK, but it is not good to keep on producing images with all this shit in them. Maybe we need some QA type unit test that checks for unexpected processes. > On 2013-06-18, at 10:05, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> On 18 Jun 2013, at 09:47, Camille Teruel <camille.teruel(a)gmail.com> wrote: >> >>> >>> On 18 juin 2013, at 09:32, Sven Van Caekenberghe wrote: >>> >>>> Hi, >>>> >>>> It seems that https://pharo.fogbugz.com/f/cases/10760/Lots-and-Lots-of-Delay-wait-process… is closed, but the problem remains. >>>> >>>> Yesterday I test deployed a brand new 3.0 image. It has more than 800 bogus delay related processes. >>>> >>>> â¦ >>>> >>>> <Screen Shot 2013-06-18 at 09.30.30.png> >>>> >>>> This is not good ;-) >>>> >>>> The least we should do is add some script in the release/build process to kill them. >>> >>> I added the following to my startup preferences: >>> >>> Process allInstances do: [ :process | >>> process suspendedContext ifNotNil: [ :context | >>> context method = (Delay>>#wait) ifTrue: [ process terminate ] ] ] >> >> OK, thanks. >> But are we sure that no legitimate ones are killed ? >> I am not sure, but I believe Igor's script had more testsâ¦. >> >>>> >>>> Sven >>>> >>>> >>>> -- >>>> Sven Van Caekenberghe >>>> Proudly supporting Pharo >>>> http://pharo.org >>>> http://association.pharo.org >>>> http://consortium.pharo.org >>>> >>>> >>>> >>>> >>> >> >> > >

June 18, 2013

Object>>#if:then:else:

by Camille Teruel

Hello everyone. I see a lot of code that follows the following pattern: <a long expression> <aComplexTest> ifTrue: [ <a long expression> <something> ] ifFalse: [ <a long expression> <something else> ]. The classic refactoring is to store <a long expression> in a temp to avoid repetition: | temp | temp := <a long expression>. temp <aComplexTest> ifTrue: [ temp <something> ] ifFalse: [ temp <something else> ]. Then <a long expression> is evaluated once and the name of the temp can carry a meaningful name that helps reading the code. But this is more verbose than the first version. But if you add the following method in Object: if: conditionBlock then: trueBlock else: falseBlock ^ (conditionBlock cull: self) ifTrue: [ trueBlock cull: value ] ifFalse: [ falseBlock cull: value ] You can then rewrite it like that: <a long expression> if: [ :obj | obj <aComplexTest> ] then: [ :obj | <something> ] else: [ :obj | <something else> ] The names of the block args can give a meaningful name depending on the result of the test (something like ... if: #notEmpty then: [ :collection | ... ] else: [ :emptyCollection | ... ]). Using cull: for the three block also enable a good flexibility: you can omit the arg when irrelevant. Likewise, we could also have Object>>#while:do: while: conditionBlock do: actionBlock ^ [ conditionBlock cull: self ] whileTrue: [ actionBlock cull: self ] What do you think? Camille

June 18, 2013

Re: [Pharo-dev] Zinc problem with PUT requests

by Nicolas Petton

Hi Sven, This is not merged on purpose, as Camillo's patch needs some review and thinking :) Nico On Jun 17, 2013, at 3:29 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > BTW: there is even code in StHub, namely Hub-CamilloBruni.119, that was not merged properly AFAICT. -- Nicolas Petton http://www.nicolas-petton.fr

June 18, 2013

Re: [Pharo-dev] There are still lots of Delay>>wait Processes

by Camille Teruel

On 18 juin 2013, at 10:05, Sven Van Caekenberghe wrote: > > On 18 Jun 2013, at 09:47, Camille Teruel <camille.teruel(a)gmail.com> wrote: > >> >> On 18 juin 2013, at 09:32, Sven Van Caekenberghe wrote: >> >>> Hi, >>> >>> It seems that https://pharo.fogbugz.com/f/cases/10760/Lots-and-Lots-of-Delay-wait-process… is closed, but the problem remains. >>> >>> Yesterday I test deployed a brand new 3.0 image. It has more than 800 bogus delay related processes. >>> >>> â¦ >>> >>> <Screen Shot 2013-06-18 at 09.30.30.png> >>> >>> This is not good ;-) >>> >>> The least we should do is add some script in the release/build process to kill them. >> >> I added the following to my startup preferences: >> >> Process allInstances do: [ :process | >> process suspendedContext ifNotNil: [ :context | >> context method = (Delay>>#wait) ifTrue: [ process terminate ] ] ] > > OK, thanks. > But are we sure that no legitimate ones are killed ? > I am not sure, but I believe Igor's script had more testsâ¦. Ok I did't saw Igor's one. Indeed mine doesn't check context sender sender sender method selector == #contents: >>> >>> Sven >>> >>> >>> -- >>> Sven Van Caekenberghe >>> Proudly supporting Pharo >>> http://pharo.org >>> http://association.pharo.org >>> http://consortium.pharo.org >>> >>> >>> >>> >> > >

June 18, 2013