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

Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument

by Schwab,Wilhelm K

It sounds like a double dispatch that, as that enables, gives the behavior one would want in either case: evaluate the block and return its value, just give the value of a magnitude (evaluating same is trivial), etc. The ambiguity argument got me, but with a dispatch along the way, I think that can be fixed. Two POTENTIAL concerns are that it might hurt performance (perhaps only if abused), and that it effectively creates more syntax. I am a little sensitive to the latter because I have been doing a lot with R, which is quite sugary and all the harder to learn as a result. Are we helping noobs by accepting blocks or objects that "magically" get evaluated? Loosely related, in areas in which inlining helps, people who have learned to deviate from optimizable constructs could end up writing slower code than they might have before the change?? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Sunday, October 10, 2010 1:21 PM To: The general-purpose Squeak developers list Cc: Pharo Development Subject: Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument On Sun, 10 Oct 2010, Igor Stasenko wrote: > On 10 October 2010 17:34, Randal L. Schwartz <merlyn(a)stonehenge.com> wrote: >>>>>>> "Igor" == Igor Stasenko <siguctua(a)gmail.com> writes: >> >> Igor> i am also missing: >> >> Igor> someThing ifTrue: 1 ifFalse: 0 >> >> Down that path lies ambiguity though. >> >> If you had >> >> actionSymbol := aBoolean ifTrue: #doThis else: #doThat. >> >> do you want the symbol assigned, or performed? >> >> Please don't add so much dwimmery here. I like it that Smalltalk is >> fairly strict with these basic forms. > > what dwimmery you talking about? > > b := [ 15 ]. > a := [ 16 ]. > > true ifTrue: a ifFalse: b > 16 > > as well as: > > b := 15 . > a := 16 . > > true ifTrue: a ifFalse: b > 16 > > works well. > > > In this way, > > answer := process ifNotNil: #terminate. > > should be equivalent to: > > answer := process notNil ifTrue: #terminate > > but not to: > > answer := process notNil ifTrue: [ process terminate ]. How would you implement #ifNotNil: to reflect this? Would you dispatch on the type of the argument? Levente > > >> >> -- >> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 >> <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> >> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. >> See http://methodsandmessages.posterous.com/ for Smalltalk discussion >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Oct. 10, 2010

Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument

by Levente Uzonyi

On Sun, 10 Oct 2010, Igor Stasenko wrote: > On 10 October 2010 17:34, Randal L. Schwartz <merlyn(a)stonehenge.com> wrote: >>>>>>> "Igor" == Igor Stasenko <siguctua(a)gmail.com> writes: >> >> Igor> i am also missing: >> >> Igor> someThing ifTrue: 1 ifFalse: 0 >> >> Down that path lies ambiguity though. >> >> If you had >> >> Â actionSymbol := aBoolean ifTrue: #doThis else: #doThat. >> >> do you want the symbol assigned, or performed? >> >> Please don't add so much dwimmery here. Â I like it that Smalltalk is >> fairly strict with these basic forms. > > what dwimmery you talking about? > > b := [ 15 ]. > a := [ 16 ]. > > true ifTrue: a ifFalse: b > 16 > > as well as: > > b := 15 . > a := 16 . > > true ifTrue: a ifFalse: b > 16 > > works well. > > > In this way, > > answer := process ifNotNil: #terminate. > > should be equivalent to: > > answer := process notNil ifTrue: #terminate > > but not to: > > answer := process notNil ifTrue: [ process terminate ]. How would you implement #ifNotNil: to reflect this? Would you dispatch on the type of the argument? Levente > > >> >> -- >> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 >> <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> >> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. >> See http://methodsandmessages.posterous.com/ for Smalltalk discussion >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Oct. 10, 2010

Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument

by Igor Stasenko

On 10 October 2010 17:34, Randal L. Schwartz <merlyn(a)stonehenge.com> wrote: >>>>>> "Igor" == Igor Stasenko <siguctua(a)gmail.com> writes: > > Igor> i am also missing: > > Igor> someThing ifTrue: 1 ifFalse: 0 > > Down that path lies ambiguity though. > > If you had > > Â actionSymbol := aBoolean ifTrue: #doThis else: #doThat. > > do you want the symbol assigned, or performed? > > Please don't add so much dwimmery here. Â I like it that Smalltalk is > fairly strict with these basic forms. what dwimmery you talking about? b := [ 15 ]. a := [ 16 ]. true ifTrue: a ifFalse: b 16 as well as: b := 15 . a := 16 . true ifTrue: a ifFalse: b 16 works well. In this way, answer := process ifNotNil: #terminate. should be equivalent to: answer := process notNil ifTrue: #terminate but not to: answer := process notNil ifTrue: [ process terminate ]. > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > See http://methodsandmessages.posterous.com/ for Smalltalk discussion > -- Best regards, Igor Stasenko AKA sig.

Oct. 10, 2010

Re: [Pharo-project] 12186 image quit problem

by Igor Stasenko

On 10 October 2010 17:40, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Have you thought about using a Mutex? Â Maybe I'm missing something in life, but long ago I decided the #forMutualExclusion is *beyond* private. Â Semaphores are wonderful for #wait/#signal. Â But for #critical:, I use Mutex which won't deadlock a thread with itself. > yes, i thought about it. It wont help in this situation, because if you start modifying dictionary inside a loop, which scanning its elements (like #do:) you'll have very unpleasant results. All HostSystemMenusProxy doing during #finalize is removing itself from weakregistry (which is complete nonsense, since weak registry cleaning itself from dead stuff anyways). So, self protected: [ valueDictionary expiredValuesDo: [:finItem | finItem finalizeValues ]. ]. actually triggers a bug/mistake in HostSystemMenusProxy , which leads to deadlock. :) > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] > Sent: Sunday, October 10, 2010 7:56 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] 12186 image quit problem > > OKay, now i see what the problem: > > <weak registry protected> > Â <finalize items> > Â Â Â <HostSystemMenusProxy>>finalize> > Â Â Â Â Â Â .... > Â Â Â Â Â Â <HostSystemMenusProxy class>>unregister> > Â Â Â Â Â Â Â <weak registry protected> > > > In my WeakRegistry, a #finalize message sent while registry semaphore locked, > so, in case if object in #finalize trying to manipulate with registry > then it going to deadlock. > > Then following piece: > > WeakRegistry>>finalizeValues > > self protected: [ > Â Â Â Â valueDictionary expiredValuesDo: [:finItem | > Â Â Â Â Â Â Â Â finItem finalizeValues Â ]. > Â ]. > > should be rewritten as: > > | expired | > expired := OrderedCollection new. > self protected: [ > Â Â Â Â valueDictionary expiredValuesDo: [:finItem | expired add: finItem ] > Â ]. > expired do: #finalizeValues. > > > But either way, HostSystemMenusProxy should not attempt remove itself > from registry during #finalize (and causing a deadlock), > since its pointless. > > > -- > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 10, 2010

Re: [Pharo-project] another little OB "bug"

by Lukas Renggli

I am not sure if I understand your question correctly, but presumably your method is too long or you have too many methods in one class or protocol. OB punishes you for this :-) Lukas 2010/10/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi. Me again. Not sure if it is a bug but I don't like it. If you do, no > problem then ;) > > Suppose you are working with a method that it is in the half of the method > pane of OB. Once you save it or run test on it for example, the "scroll" and > the method pane is updated so that THAT method is first, above. And > sometimes this is quite annoying for me. > > Cheers > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Oct. 10, 2010

Re: [Pharo-project] little bug in OB running tests

by Lukas Renggli

Hard to do, because #debug on the test case does not return the test result and re-running the test somehow screws up the stack. I am happy to integrate if you find a good solution. Lukas 2010/10/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi Lukas. A lot of times, I run tests with cmd + t in OB and the test fails > (mostly becuase I like doing TDD). When I press proceed and the test passes > (green), the little point on the left of the method in OB, isn't painted > with green color as it does when the test directly passes (withput a failure > in the middle). > > Thanks > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Oct. 10, 2010

[Pharo-project] another little OB "bug"

by Mariano Martinez Peck

Hi. Me again. Not sure if it is a bug but I don't like it. If you do, no problem then ;) Suppose you are working with a method that it is in the half of the method pane of OB. Once you save it or run test on it for example, the "scroll" and the method pane is updated so that THAT method is first, above. And sometimes this is quite annoying for me. Cheers Mariano

Oct. 10, 2010

[Pharo-project] R: R: R: Problem with inspector

by morod

Thanks for your interest, I have done what was suggested, but nothing has changed. Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Frederic Pluquet Inviato: domenica 10 ottobre 2010 17:00 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] R: R: Problem with inspector If you load the last version of NewInspector (posted this morning), you go to the Settings Browser (System > Settings in the World menu), expand "Debugging" > "NewInspector" and check the options you want. FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2010/10/10 morod <morod(a)tiscali.it> Hello, How can I switch from the two different versions of tool ÂInspectorÂ Best regards Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Frederic Pluquet Inviato: sabato 9 ottobre 2010 14:08 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] R: Problem with inspector Hello, It's the NewInspector on both pictures but two different versions of this tool. In the old version, the class and the methods were displayed for each inspected object. In the current version, there are not displayed (because the community prefers less children for each object). FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet 2010/10/8 morod <morod(a)tiscali.it> Hi Mariano I tried it with multiple images and the behavior is the same with all the images. Sent the sample is made with: Pharo-1.1-11411 Latest update: #11411 The first one is my image and the second is taken from the book ÂPharo by ExampleÂ Thanks again Morod Da: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] Per conto di Mariano Martinez Peck Inviato: venerdÃ¬ 8 ottobre 2010 21:43 A: Pharo-project(a)lists.gforge.inria.fr Oggetto: Re: [Pharo-project] Problem with inspector Hi morod, and welcome to Pharo! Which Pharo image are you exactly using? (the name of the zip, the image file or go to System -> About) The first one is your image, right ? and the second one? where is it from ? The difference is that the first image is using the "old" traditional inspector, while the second picture is using another inspector, which is called "NewInspector", which provides more information. Cheers Mariano 2010/10/8 morod <morod(a)tiscali.it> Hi iÂm new to smalltalk and Pharo and my inspector show Errore. Il nome file non Ã¨ specificato. instead of Errore. Il nome file non Ã¨ specificato. Why? Thanks _______________________________________________ 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

Oct. 10, 2010

[Pharo-project] little bug in OB running tests

by Mariano Martinez Peck

Hi Lukas. A lot of times, I run tests with cmd + t in OB and the test fails (mostly becuase I like doing TDD). When I press proceed and the test passes (green), the little point on the left of the method in OB, isn't painted with green color as it does when the test directly passes (withput a failure in the middle). Thanks Mariano

Oct. 10, 2010

Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument

by Schwab,Wilhelm K

An excellent point about ambiguity. The two examples process ifNotNil:#terminate and something ifTrue:1 ifFlalse:0 appear to ask for perform and assign, respectively. Writing the brackets for the latter is not a big chore, and the first example is solved with a new message (#terminateMe) understood by both Process (self #terminate) and UndefinedObject (noop). Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Randal L. Schwartz [merlyn(a)stonehenge.com] Sent: Sunday, October 10, 2010 10:34 AM To: Igor Stasenko Cc: Pharo Development; The general-purpose Squeak developers list Subject: Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument >>>>> "Igor" == Igor Stasenko <siguctua(a)gmail.com> writes: Igor> i am also missing: Igor> someThing ifTrue: 1 ifFalse: 0 Down that path lies ambiguity though. If you had actionSymbol := aBoolean ifTrue: #doThis else: #doThat. do you want the symbol assigned, or performed? Please don't add so much dwimmery here. I like it that Smalltalk is fairly strict with these basic forms. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 10, 2010