February 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3723 in pharo: The Finder tool does not alphabetize methods.

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3723 by DougEdmu...(a)gmail.com: The Finder tool does not alphabetize methods. http://code.google.com/p/pharo/issues/detail?id=3723 Steps to reproduce: 1) Open Finder tool from World> Tools> Finder 2) In the top left box, type "Object" 3) Change the selection in box to the right from "Selectors" to "Classes" 4) There is no 'Go' button. Click back to the top left box, where you typed "Object", then go to the keyboard, and press enter. 5) Classes with "Object" in them will appear below. 6) Select "Object". 7) Click on the little arrowhead, to make it point downward, which will show the methods for "Object". 8) Scroll through the list until you find the method "needsWork" (it's in there). I'd also suggest considering grouping by class and instance, rather than just alphabetically.

Feb. 17, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Nicolas Cellier

2011/2/17 Igor Stasenko <siguctua(a)gmail.com>: > On 17 February 2011 00:51, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> 2011/2/17 Igor Stasenko <siguctua(a)gmail.com>: >>> On 16 February 2011 22:00, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> Ok this is my last mail on that topic. >>>> >>> >>> apparently not ;) >>> >>>> >>>>> yes now do not think that I'm implying that you are not able to implement a decompiler. >>>>> Now we have something else to do that dealing with the optimisation of a stupid method. >>>>> This is all my point. >>>>> Let us focus on the real problems. eliot is crying for caseOf: but we have 3 users. >>>>> >>>>> Did you know that there are several uses of caseOf: in the Opal compiler? >>>> >>>> >>>> (selector := aMessageNode selector) >>>> Â Â Â Â Â Â Â Â caseOf: >>>> Â Â Â Â Â Â Â Â Â Â Â Â {([ #ifNil: ] >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ self isValueTranslator ifTrue: [ methodBuilder pushDup ] ]). >>>> Â Â Â Â Â Â Â Â Â Â Â Â ([ #ifNil:ifNotNil: ] >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ args last arguments ifNotEmpty: [ args last arguments first binding emitStore: methodBuilder ] ]). >>>> Â Â Â Â Â Â Â Â Â Â Â Â ([ #ifNotNil: ] >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ args first arguments ifNotEmpty: [ args first arguments first binding emitStore: methodBuilder ] ]). >>>> Â Â Â Â Â Â Â Â Â Â Â Â ([ #ifNotNilDo: ] >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ args first arguments ifNotEmpty: [ args first arguments first binding emitStore: methodBuilder ] ]). >>>> Â Â Â Â Â Â Â Â Â Â Â Â ([ #ifNotNil:ifNil: ] >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ args first arguments ifNotEmpty: [ args first arguments first binding emitStore: methodBuilder ] ])}. >>>> >>>> >>> >>> yikes... so Opal already polluted (as being non-pure) by premature >>> optimizations :) >>> >>> You see the tendency: one premature optimization drags other after itself. >>> >>> I would suggest to make full & working compiler suite which doing no >>> any optimizations/inlining, >>> and only then, when everything works, add a code with inlining >>> optimizations as a plugin. >>> So, people will know, that this is _optional_ not mandatory and not >>> hardwired into smalltalk compiler. >>> This is the message a good compiler should pass to developers: >>> optimizations are useful but not essential. >>> But i am not analyzed Opal code deeply, maybe its already like that. >>> >>> >> >> Sure, if it's just a proof of concept.... but wasting 10x factor when >> Eliot spent so many efforts to gain 3x would sound like a denial of >> his own utility in this community. >> I can understand his reticence quite easily ;) > > I see it like following: > Â - VM gets faster so language side could drop hacky optimizations > > For instance, why #class or #== messages are early bound? What is a > tradeoff for having 0.005% faster system, > but unable to have good proxies? > > As Eliot said before: you can cheat, but don't get caught. Apparently > things like above didn't took that into account. So why we should not > attempt to fix that? > I see, pas de vache sacrÃ©e ;) But I thought you were speaking of Opal Compiler inlining hacks. Are above features Compiler optimizations or VM optimizations ? Nicolas >> >> Nicolas >> >>>> > > -- > Best regards, > Igor Stasenko AKA sig. > >

Feb. 17, 2011

[Pharo-project] Issue 3722 in pharo: The Finder tool's help screen is poorly written and has bad grammar

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3722 by DougEdmu...(a)gmail.com: The Finder tool's help screen is poorly written and has bad grammar http://code.google.com/p/pharo/issues/detail?id=3722 1) why does it use "Selectors" instead of "Methods"? What is a Selector? 2) class's names -> classes 3) all the method's sources -> the source code 4) "your research use" -> your research uses 5) "in this 4 modes" -> in these four modes =====below: the current text==== The Finder can be used in 4 different ways: - Selectors: your research is done among selectors - Classes : your research is done among class's names - Source : your research is done among all the method's sources - Examples : your research use the Method Finder behavior (for further informations, print 'FinderUI methodFinderExplanation') In this 4 modes, you can also tick the 'Use RegEx' checkbox. If you pick this box, your search will be done using regular expressions instead of just matching. The 'Select classes' button opened a dialog window to select which classes will be used for the search. The 'All classes' button is used to reset the classes selection.

Feb. 17, 2011

Re: [Pharo-project] XMLRPC server

by GermÃ¡n Arduino

A bit more of data: To install latest versions: ConfigurationOfXMLRPC project latestVersion load: 'All'. (Will install client,server and tests of both). I tried in Pharo 1.1.1 and I've still 2 failing tests on server. Now tried in Pharo 1.2 and seems that 3 tests are failing here. I will be working on these issues on the next days, focusing on Pharo 1.1.1. About Squeak, seems that in 4.2 the HttpSocket was redesigned and is to hook some other http client, then XMLRPC don't works anymore. By now XMLRPC is based on HTTPSocket and my goal is release a Beta version soon, with not failing tests. Later we can talk and decide about the HTTP client to use and/or the squeak compatibility. Cheers. GermÃ¡n. 2011/2/16 GermÃ¡n Arduino <garduino(a)gmail.com>: > Hi (again): > > With the new Alpha version of XMLRPC the server works. The error you > reported was by a missing method in Dictionary. > > Ask by any doubt, please. > > Cheers. > > > 2010/12/18 Sean P. DeNigris <sean(a)clipperadams.com>: >> >> >> Geoffroy Couprie wrote: >>> >>> The tests have some problems, but the server works fine. >>> >> >> server := XMLRPCHttpModule startOn: 8088. >> XMLRPCServerRequest >> Â Â Â Â registerService: 'echo.echoArray' >> Â Â Â Â class: XMLRPCStandardEcho >> Â Â Â Â selector: #echo:. >> >> proxy := XMLRPCProxy new url: 'http://localhost:8088/xmlrpc' asUrl. >> args := OrderedCollection new. >> args add: #('A' 1 3 2.525). >> r := proxy invokeMethod: 'echo.echoArray' withArgs: args. >> >> Server returns: >> <html><head><title>500 Internal Server >> Error</title></head><body><h1>Internal Server >> Error</h1>
MessageNotUnderstood: >> Dictionary>>asXMLRPCString<p><hr><address>KomHttpServer/7.1.3 (Mac OS) >> Server at 'localhost' Port 80</address></hr></p></body></html> >> -- >> View this message in context: http://forum.world.st/XMLRPC-server-tp3090251p3093978.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> >

Feb. 17, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Igor Stasenko

On 17 February 2011 00:51, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/2/17 Igor Stasenko <siguctua(a)gmail.com>: >> On 16 February 2011 22:00, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Ok this is my last mail on that topic. >>> >> >> apparently not ;) >> >>> >>>> yes now do not think that I'm implying that you are not able to implement a decompiler. >>>> Now we have something else to do that dealing with the optimisation of a stupid method. >>>> This is all my point. >>>> Let us focus on the real problems. eliot is crying for caseOf: but we have 3 users. >>>> >>>> Did you know that there are several uses of caseOf: in the Opal compiler? >>> >>> >>> (selector := aMessageNode selector) >>> Â Â Â Â Â Â Â Â caseOf: >>> Â Â Â Â Â Â Â Â Â Â Â Â {([ #ifNil: ] >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ self isValueTranslator ifTrue: [ methodBuilder pushDup ] ]). >>> Â Â Â Â Â Â Â Â Â Â Â Â ([ #ifNil:ifNotNil: ] >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ args last arguments ifNotEmpty: [ args last arguments first binding emitStore: methodBuilder ] ]). >>> Â Â Â Â Â Â Â Â Â Â Â Â ([ #ifNotNil: ] >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ args first arguments ifNotEmpty: [ args first arguments first binding emitStore: methodBuilder ] ]). >>> Â Â Â Â Â Â Â Â Â Â Â Â ([ #ifNotNilDo: ] >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ args first arguments ifNotEmpty: [ args first arguments first binding emitStore: methodBuilder ] ]). >>> Â Â Â Â Â Â Â Â Â Â Â Â ([ #ifNotNil:ifNil: ] >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ args first arguments ifNotEmpty: [ args first arguments first binding emitStore: methodBuilder ] ])}. >>> >>> >> >> yikes... so Opal already polluted (as being non-pure) by premature >> optimizations :) >> >> You see the tendency: one premature optimization drags other after itself. >> >> I would suggest to make full & working compiler suite which doing no >> any optimizations/inlining, >> and only then, when everything works, add a code with inlining >> optimizations as a plugin. >> So, people will know, that this is _optional_ not mandatory and not >> hardwired into smalltalk compiler. >> This is the message a good compiler should pass to developers: >> optimizations are useful but not essential. >> But i am not analyzed Opal code deeply, maybe its already like that. >> >> > > Sure, if it's just a proof of concept.... but wasting 10x factor when > Eliot spent so many efforts to gain 3x would sound like a denial of > his own utility in this community. > I can understand his reticence quite easily ;) I see it like following: - VM gets faster so language side could drop hacky optimizations For instance, why #class or #== messages are early bound? What is a tradeoff for having 0.005% faster system, but unable to have good proxies? As Eliot said before: you can cheat, but don't get caught. Apparently things like above didn't took that into account. So why we should not attempt to fix that? > > Nicolas > >>> -- Best regards, Igor Stasenko AKA sig.

Feb. 17, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Nicolas Cellier

2011/2/17 Igor Stasenko <siguctua(a)gmail.com>: > On 16 February 2011 22:00, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Ok this is my last mail on that topic. >> > > apparently not ;) > >> >>> yes now do not think that I'm implying that you are not able to implement a decompiler. >>> Now we have something else to do that dealing with the optimisation of a stupid method. >>> This is all my point. >>> Let us focus on the real problems. eliot is crying for caseOf: but we have 3 users. >>> >>> Did you know that there are several uses of caseOf: in the Opal compiler? >> >> >> (selector := aMessageNode selector) >> Â Â Â Â Â Â Â Â caseOf: >> Â Â Â Â Â Â Â Â Â Â Â Â {([ #ifNil: ] >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ self isValueTranslator ifTrue: [ methodBuilder pushDup ] ]). >> Â Â Â Â Â Â Â Â Â Â Â Â ([ #ifNil:ifNotNil: ] >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ args last arguments ifNotEmpty: [ args last arguments first binding emitStore: methodBuilder ] ]). >> Â Â Â Â Â Â Â Â Â Â Â Â ([ #ifNotNil: ] >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ args first arguments ifNotEmpty: [ args first arguments first binding emitStore: methodBuilder ] ]). >> Â Â Â Â Â Â Â Â Â Â Â Â ([ #ifNotNilDo: ] >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ args first arguments ifNotEmpty: [ args first arguments first binding emitStore: methodBuilder ] ]). >> Â Â Â Â Â Â Â Â Â Â Â Â ([ #ifNotNil:ifNil: ] >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ args first arguments ifNotEmpty: [ args first arguments first binding emitStore: methodBuilder ] ])}. >> >> > > yikes... so Opal already polluted (as being non-pure) by premature > optimizations :) > > You see the tendency: one premature optimization drags other after itself. > > I would suggest to make full & working compiler suite which doing no > any optimizations/inlining, > and only then, when everything works, add a code with inlining > optimizations as a plugin. > So, people will know, that this is _optional_ not mandatory and not > hardwired into smalltalk compiler. > This is the message a good compiler should pass to developers: > optimizations are useful but not essential. > But i am not analyzed Opal code deeply, maybe its already like that. > > Sure, if it's just a proof of concept.... but wasting 10x factor when Eliot spent so many efforts to gain 3x would sound like a denial of his own utility in this community. I can understand his reticence quite easily ;) Nicolas >> >>> Â Do you have such an encyclopaedic knowledge of all the packages ever written in Pharo and Squeak that you know* you have only 3 users? Â Of course you don't. Â You are being ridiculous. >> >> Now when opal will arrive people should be prepared that probably caseOf: will not be inlined. >> >> Stef >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Feb. 16, 2011

Re: [Pharo-project] [Metacello] Metacello tests failing in 1.2

by Dale Henrichs

On 02/15/2011 05:46 PM, Guillermo Polito wrote: > Hi Dale! > > There are 13 failing tests on the 1.2 dev build since a week ago ( > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/141/testReport/ > ). Do we have the right version? Do you have any clue so I don't dive > in the code blindly? :) > > Cheers, > Guille Ahhhh, It looks the Gofer changes for Issue 3660 have been integrated, which means that the sorting order for mcz files has been changed, which means that the Metacello tests that are sensitive (or validating) the sort order have broken ... It will be at least a couple of days before I can get these issues fixed I have to propogate the gofer fixes to GemStone and Squeak... the normal operation of Metacello shouldn't be affected by these failing tests ... the test cases involved include examples of mcz files with "incorrect" branch naming scheme... I've created Metacello Issue 108: "Need to update Metacello (tests and Gofer config) to integrate changes from Pharo Issue 3660"[1] to track progress. [1] http://code.google.com/p/metacello/issues/detail?id=108 Dale

Feb. 16, 2011

Re: [Pharo-project] XMLRPC server

by GermÃ¡n Arduino

Hi (again): With the new Alpha version of XMLRPC the server works. The error you reported was by a missing method in Dictionary. Ask by any doubt, please. Cheers. 2010/12/18 Sean P. DeNigris <sean(a)clipperadams.com>: > > > Geoffroy Couprie wrote: >> >> The tests have some problems, but the server works fine. >> > > server := XMLRPCHttpModule startOn: 8088. > XMLRPCServerRequest > Â Â Â Â registerService: 'echo.echoArray' > Â Â Â Â class: XMLRPCStandardEcho > Â Â Â Â selector: #echo:. > > proxy := XMLRPCProxy new url: 'http://localhost:8088/xmlrpc' asUrl. > args := OrderedCollection new. > args add: #('A' 1 3 2.525). > r := proxy invokeMethod: 'echo.echoArray' withArgs: args. > > Server returns: > <html><head><title>500 Internal Server > Error</title></head><body><h1>Internal Server > Error</h1>
MessageNotUnderstood: > Dictionary>>asXMLRPCString<p><hr><address>KomHttpServer/7.1.3 (Mac OS) > Server at 'localhost' Port 80</address></hr></p></body></html> > -- > View this message in context: http://forum.world.st/XMLRPC-server-tp3090251p3093978.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Feb. 16, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Igor Stasenko

On 16 February 2011 22:00, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Ok this is my last mail on that topic. > apparently not ;) > >> yes now do not think that I'm implying that you are not able to implement a decompiler. >> Now we have something else to do that dealing with the optimisation of a stupid method. >> This is all my point. >> Let us focus on the real problems. eliot is crying for caseOf: but we have 3 users. >> >> Did you know that there are several uses of caseOf: in the Opal compiler? > > > (selector := aMessageNode selector) > Â Â Â Â Â Â Â Â caseOf: > Â Â Â Â Â Â Â Â Â Â Â Â {([ #ifNil: ] > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ self isValueTranslator ifTrue: [ methodBuilder pushDup ] ]). > Â Â Â Â Â Â Â Â Â Â Â Â ([ #ifNil:ifNotNil: ] > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ args last arguments ifNotEmpty: [ args last arguments first binding emitStore: methodBuilder ] ]). > Â Â Â Â Â Â Â Â Â Â Â Â ([ #ifNotNil: ] > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ args first arguments ifNotEmpty: [ args first arguments first binding emitStore: methodBuilder ] ]). > Â Â Â Â Â Â Â Â Â Â Â Â ([ #ifNotNilDo: ] > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ args first arguments ifNotEmpty: [ args first arguments first binding emitStore: methodBuilder ] ]). > Â Â Â Â Â Â Â Â Â Â Â Â ([ #ifNotNil:ifNil: ] > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> [ args first arguments ifNotEmpty: [ args first arguments first binding emitStore: methodBuilder ] ])}. > > yikes... so Opal already polluted (as being non-pure) by premature optimizations :) You see the tendency: one premature optimization drags other after itself. I would suggest to make full & working compiler suite which doing no any optimizations/inlining, and only then, when everything works, add a code with inlining optimizations as a plugin. So, people will know, that this is _optional_ not mandatory and not hardwired into smalltalk compiler. This is the message a good compiler should pass to developers: optimizations are useful but not essential. But i am not analyzed Opal code deeply, maybe its already like that. > >> Â Do you have such an encyclopaedic knowledge of all the packages ever written in Pharo and Squeak that you know* you have only 3 users? Â Of course you don't. Â You are being ridiculous. > > Now when opal will arrive people should be prepared that probably caseOf: will not be inlined. > > Stef > -- Best regards, Igor Stasenko AKA sig.

Feb. 16, 2011

Re: [Pharo-project] could we agree to remove caseOf: and caseOf:otherwise:

by Igor Stasenko

On 16 February 2011 21:59, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Feb 16, 2011, at 12:57 PM, StÃ©phane Ducasse wrote: > >> >>> >>> On Wed, Feb 16, 2011 at 12:31 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> yes now do not think that I'm implying that you are not able to implement a decompiler. >>> Now we have something else to do that dealing with the optimisation of a stupid method. >>> This is all my point. >>> Let us focus on the real problems. eliot is crying for caseOf: but we have 3 users. >>> >>> Did you know that there are several uses of caseOf: in the Opal compiler? >> >> yes >> >>> Do you have such an encyclopaedic knowledge of all the packages ever written in Pharo and Squeak that you know* you have only 3 users? Â Of course you don't. Â You are being ridiculous. >> >> eliot the statistics are against you. > > Can we postpone this discussion? > yeah guys.. lower the level of emotions. No need to become mad and make new enemies. Because most of the times people regret about it after, but its too late to fix what was broken. I am really surprised that such minor issue attracted so much attention.. (yes yes, i am guilty for pouring oil to flames.. ) > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > -- Best regards, Igor Stasenko AKA sig.

Feb. 16, 2011