- Pharo-dev - lists.pharo.org

[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