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

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

by Schwab,Wilhelm K

Nicolas, Sig, The problem is compiler inlining? That happens at compile time, right? :) Unless I am missing something, I see no reason to get upset about what you propose. The runtime cost from the added messages is decided when the code is compiled, and things that are currently inlined would go right on being that way, even after they are recompiled?? 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 9:06 AM To: The general-purpose Squeak developers list Cc: Pharo Development Subject: Re: [Pharo-project] [squeak-dev] Compiler pedantic about ifNotNil: argument On 10 October 2010 15:39, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. > Thus we cannot write this xtream sentence > > process ifNotNil: #terminate. > > When the argument is not a block, Compiler should avoid inlining and > just send a normal message. > +1 i am also missing: someThing ifTrue: 1 ifFalse: 0 > cheers > > Nicolas > > -- 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

Oct. 10, 2010

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

by Schwab,Wilhelm K

Nicolas, Have you thought about using another message, something like #terminateIfRunning that you put in both Process and UndefinedObject? Then you can just send it w/o the test and w/o a compiler change. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] Sent: Sunday, October 10, 2010 8:39 AM To: The general-purpose Squeak developers list; Pharo Development Subject: [Pharo-project] Compiler pedantic about ifNotNil: argument The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. Thus we cannot write this xtream sentence process ifNotNil: #terminate. When the argument is not a block, Compiler should avoid inlining and just send a normal message. cheers Nicolas _______________________________________________ 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

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

by Frederic Pluquet

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(a)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(a)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

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

by Levente Uzonyi

On Sun, 10 Oct 2010, Randal L. Schwartz 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? The implementation is staightforward IMHO. If the receiver expects a niladic block, then the argument is returned. If the receiver can accept a niladic or a monadic block, then #cull: is sent to the argument. If the receiver expects a monadic block, then #value: is sent to the argument. This works perfercly with blocks. Keyword selector symbols are equivalent with monadic blocks in this case, so Symbol >> #cull: can be implemented as ^argument perform: self. For other symbols #cull: is meaningless and #perform: will raise an error. Levente > > 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

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

by morod

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

Oct. 10, 2010

Re: [Pharo-project] Symbol>>cull:

by Levente Uzonyi

On Sun, 10 Oct 2010, Nicolas Cellier wrote: > We recently added #value: to Symbol to be able to use it in place of a > one arg block. > > (1 to: 10) select: #even. > > It would be logical to add #cull: too, xtreams tests use this for example: > output write: #[ 1 2 3 4 5 6 7 8 9 ]. > self assert: ((input rejecting: #even) read: 5) = #[ 1 3 5 7 9 ] > > Any objection to add it in core ? > (otherwise i will add it to Xtreams-VWCompatible) I prepared the necessary changes to Squeak a few months ago, but didn't push them to the Trunk. Henrik added them to Pharo 1.2 though. Levente > > Nicolas > > _______________________________________________ > 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

Re: [Pharo-project] 12186 image quit problem

by Schwab,Wilhelm K

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

Oct. 10, 2010

Re: [Pharo-project] [squeak-dev] Xtreams : first embryonary port on Squeak

by Schwab,Wilhelm K

Nicolas, #fork in a test? Do you mean like the code below? The thread running the test waits on something signaled toward the end of the forked thread. If you want a watchdog timer, you could fork another thread that waits on a delay, sets an error flag (best to use a shared queue or a mutex to avoid weirdness) and then signals the test semaphore. You might also want to use #ifCurtailed: to set an error flag and wrap that with #ensure: to signal the semaphore. You don't necessarily need to be perfect about signaling the semaphore because failure to do so is not much different from your test going into an infinite loop (actually more benign because the stack isn't growing); you'll realize it, break, and figure out what didn't happen or at least "that it didn't" and try again forewarned. Does that help? Bill testLocalServerAndClient "11-09 - try a server and a client in the same image." | server port client serverSocket serverSocketStream text thread done read | port := 4900. done := Semaphore new. "11-09 - gag the prompter below" serverSocket := nil. server := ConnectionQueue portNumber:port queueLength:5. [ client := SocketStream openConnectionToHostNamed:'localhost' port:port. [ serverSocket isNil ] whileTrue:[ serverSocket := server getConnectionOrNil. ]. serverSocketStream := SocketStream on:serverSocket. text := 'Long live Tux!'. serverSocketStream nextPutAll:text; flush. "11-09 - this hung up w/o the thread. 11-09 - as you were; the problem was a lack of #flush on the send side, so there was nothing for the client side to read." thread := [ read := client nextMany:text size. done signal. ] forkAt:Processor userBackgroundPriority. thread name:'READ'. done wait. self should:[ read = text ]. Transcript nextPutAll:'Just to make the point, we read: '; nextPutAll:read; cr; flush. ] ensure:[ server destroy. serverSocketStream close. client close. ]. "11-09 - no prompts" serverSocket := serverSocket. client := client. serverSocketStream := serverSocketStream. thread := thread. " NetworkSmokeTestCase prod:#testLocalServerAndClient. " ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice(a)gmail.com] Sent: Sunday, October 10, 2010 7:05 AM To: The general-purpose Squeak developers list Cc: Pharo Development Subject: Re: [Pharo-project] [squeak-dev] Xtreams : first embryonary port on Squeak 2010/10/10 Levente Uzonyi <leves(a)elte.hu>: > On Sun, 10 Oct 2010, Nicolas Cellier wrote: > >> >> THE STATUS OF TESTS: >> >> Tests do not all pass. There seems to be a bug in Squeak >> #replace:from:to:with: when the replacement is the collection itself, >> moved to the right (this is with a COG VM). > > #replace:from:to:with: is not supposed to work for moves. IIRC the primitive > version uses memcpy (or strncpy), so moving to the left works just because > the undelying C function supports it. I used to (ab)use this feature though. > > > Levente > OK, since we use memcpy rather than memmove in Squeak VM, I implemented the trivial work around - move through a motionBuffer temporary copy. I now have a single test failing, XTCollectionWriteStream>>#testReadWriteLargeAmount and this must be due to my #after:do: simplistic implementation. Messing with #fork in SUnit TestCase is tricky, and I need help on this point. Nicolas _______________________________________________ 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

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

by merlyn＠stonehenge.com

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

Oct. 10, 2010

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

by Nicolas Cellier

2010/10/10 Igor Stasenko <siguctua(a)gmail.com>: > On 10 October 2010 16:13, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> personnally I do not like this form >> What does it do? >> >>> Â Â process ifNotNil: #terminate. >> > > here the test case for it: > > | process answer | > > process := Object new. > > answer := process ifNotNil: #terminate. > > self assert: answer == #terminate. > Ah, yes, I did not interpret it the same... I asked my son, which is not a Smalltalker, what he understood, and it was (process terminate) not (^#terminate). Nicolas > >> >> for me it means passes the symbol #terminate as argument to the method ifNotNil: >> If it has a more magical behavior then I do not know it. >> >> Stef >> >> >>> The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. >>> Thus we cannot write this xtream sentence >>> >>> Â Â process ifNotNil: #terminate. >>> >>> When the argument is not a block, Compiler should avoid inlining and >>> just send a normal message. >>> >>> cheers >>> >>> Nicolas >>> >>> _______________________________________________ >>> 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. > > _______________________________________________ > 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

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

by StÃ©phane Ducasse

On Oct 10, 2010, at 3:17 PM, Igor Stasenko wrote: > On 10 October 2010 16:13, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> personnally I do not like this form >> What does it do? >> >>> process ifNotNil: #terminate. >> > > here the test case for it: > > | process answer | > > process := Object new. > > answer := process ifNotNil: #terminate. > > self assert: answer == #terminate. all that to avoid to have ifNotNil: [#terminate] I would not change the ifNotNil: for that. But make the compiler smarter Stef > > >> >> for me it means passes the symbol #terminate as argument to the method ifNotNil: >> If it has a more magical behavior then I do not know it. >> >> Stef >> >> >>> The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. >>> Thus we cannot write this xtream sentence >>> >>> process ifNotNil: #terminate. >>> >>> When the argument is not a block, Compiler should avoid inlining and >>> just send a normal message. >>> >>> cheers >>> >>> Nicolas >>> >>> _______________________________________________ >>> 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. > > _______________________________________________ > 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

Re: [Pharo-project] WeakRegistry>>remove: - when you'll be in trouble

by Igor Stasenko

Moreover, i personally don't understand, why WeakRegistry have to be a subclass of Collection. What registry copy reject, select etc means to weak registry? My gut feeling that this is conceptually wrong. One should not use any kind of copying on weak registry. I think, that more intention revealing , one should send: registry discardFinalization: anObject instead of: registry remove: anObject On 10 October 2010 15:59, Igor Stasenko <siguctua(a)gmail.com> wrote: > A current implementation of this method > > remove: oldObject ifAbsent: exceptionBlock > Â Â Â Â "Remove oldObject as one of the receiver's elements." > > Â Â Â Â oldObject ifNil: [ ^nil ]. > Â Â Â Â ^(self protected: [ valueDictionary removeKey: oldObject ifAbsent: nil ]) > Â Â Â Â Â Â Â Â ifNil: [ exceptionBlock value ] > > simply removes a previously registered object from registry and voila. > > Now lets get back to our discussion about multiple finalizers per > object and using them in weak subscriptions etc. > > Suppose i am added a socket to weak registry, > and suppose i am added a weak subscription to it. > > Now, if i do 'socket close' , it tells weak registry to remove it from list. > And what we'll have: > Â - socket handle is closed > Â - socket is wiped from weak registry > Â - but weak subscription still listed somewhere in a list of subscriptions > > > My suggestion is, that upon #remove:, > a weak registry should notify all executors that object of interest > are no longer takes part in finalization scheme, > so they should not count on receiving #finalize eventually. > > In other words: > > remove: oldObject ifAbsent: exceptionBlock > Â Â Â Â "Remove oldObject as one of the receiver's elements." > > Â Â Â Â oldObject ifNil: [ ^nil ]. > Â Â Â Â ^(self protected: [ | executor | > Â Â Â Â Â Â executor := valueDictionary removeKey: oldObject ifAbsent: nil. > Â Â Â Â Â Â executor discardFinalization. > Â Â Â Â ]) > Â Â Â Â ifNil: [ exceptionBlock value ] > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Oct. 10, 2010

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

by Nicolas Cellier

Yes, this can be surprising at first. But I think this is because you read it with a preformated Smalltalk mind, rather than just english. it's just like: (1 to: 10) select: #even. Nicolas 2010/10/10 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > personnally I do not like this form > What does it do? > >> Â Â process ifNotNil: #terminate. > > > for me it means passes the symbol #terminate as argument to the method ifNotNil: > If it has a more magical behavior then I do not know it. > > Stef > > >> The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. >> Thus we cannot write this xtream sentence >> >> Â Â process ifNotNil: #terminate. >> >> When the argument is not a block, Compiler should avoid inlining and >> just send a normal message. >> >> cheers >> >> Nicolas >> >> _______________________________________________ >> 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

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

by Igor Stasenko

On 10 October 2010 16:13, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > personnally I do not like this form > What does it do? > >> Â Â process ifNotNil: #terminate. > here the test case for it: | process answer | process := Object new. answer := process ifNotNil: #terminate. self assert: answer == #terminate. > > for me it means passes the symbol #terminate as argument to the method ifNotNil: > If it has a more magical behavior then I do not know it. > > Stef > > >> The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. >> Thus we cannot write this xtream sentence >> >> Â Â process ifNotNil: #terminate. >> >> When the argument is not a block, Compiler should avoid inlining and >> just send a normal message. >> >> cheers >> >> Nicolas >> >> _______________________________________________ >> 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] Compiler pedantic about ifNotNil: argument

by StÃ©phane Ducasse

personnally I do not like this form What does it do? > process ifNotNil: #terminate. for me it means passes the symbol #terminate as argument to the method ifNotNil: If it has a more magical behavior then I do not know it. Stef > The compiler uselessly insist on #ifNotNil: argument being a zero/one arg block. > Thus we cannot write this xtream sentence > > process ifNotNil: #terminate. > > When the argument is not a block, Compiler should avoid inlining and > just send a normal message. > > cheers > > Nicolas > > _______________________________________________ > 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