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

Re: [Pharo-project] Pharo 1.2 broken on Hudson

by Benjamin

It;s because of FixWorkspaceMenu.2.cs Normally the cs PrepareFixWorkspaceMenu.2.cs have to be applied before to avoid this problem Ben On Feb 17, 2011, at 1:52 PM, Guillermo Polito wrote: > Ok, I fixed OB, but now is failing because: > > DuplicatedVariableError: stylingActive is already defined in Workspace > > > :( > > > On Wed, Feb 16, 2011 at 9:32 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Pharo 1.2. is broken on Hudson. > > The ConfigurationOfPharo is not loadable on a core image due > to changes on OmniBrowser. > > Reason: > ======= > ConfigurationOfOmniBrowser-GuillermoPolito.102.mcz in http://www.squeaksource.com/MetacelloRepository > references "OB-Shout-JohanBrichau.13" in spec for: #pharo in its > version 1.2.4 > > But OB-Shout-JohanBrichau.13 is not in http://www.squeaksource.com/PharoOB > Should we use "OB-Shout-GuillermoPolito.13.mcz" instead? > > Guillermo: can you give me access to PharoOB too? > > Thx > T. > > > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >

Feb. 17, 2011

Re: [Pharo-project] Pharo 1.2 broken on Hudson

by Guillermo Polito

Ok, I fixed OB, but now is failing because: DuplicatedVariableError: stylingActive is already defined in Workspace :( On Wed, Feb 16, 2011 at 9:32 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Pharo 1.2. is broken on Hudson. > > The ConfigurationOfPharo is not loadable on a core image due > to changes on OmniBrowser. > > Reason: > ======= > ConfigurationOfOmniBrowser-GuillermoPolito.102.mcz in > http://www.squeaksource.com/MetacelloRepository > references "OB-Shout-JohanBrichau.13" in spec for: #pharo in its > version 1.2.4 > > But OB-Shout-JohanBrichau.13 is not in http://www.squeaksource.com/PharoOB > Should we use "OB-Shout-GuillermoPolito.13.mcz" instead? > > Guillermo: can you give me access to PharoOB too? > > Thx > T. > > > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >

Feb. 17, 2011

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

by pharo＠googlecode.com

Comment #2 on 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 Apologies for the title of the issue. I realize you've put a lot of work into this tool. As to Selectors vs. Methods: If I open a "Method Finder" and type in "copy" I get the same results as I get if I open a "Finder",type in "copy" and choose "Selectors". "Each method has a name, called its selector," Pharo by Example, p. 80. IMHO Methods is more immediately recognizable and won't confuse anyone.

Feb. 17, 2011

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

by pharo＠googlecode.com

Updates: Status: Fixed Comment #1 on issue 3723 by Benjamin...(a)gmail.com: The Finder tool does not alphabetize methods. http://code.google.com/p/pharo/issues/detail?id=3723 3) Change the selection in box to the right from "Selectors" to "Classes" Here, search is automatically done ... 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. Now fixed Now it's alphabetized. See cs or Finder-BenjaminVanRyseghem.21 in PharoInbox Attachments: Issue3723.1.cs 547 bytes

Feb. 17, 2011

Re: [Pharo-project] Issue 3715 in pharo: Workspace shouting after switching between shout/unshout

by pharo＠googlecode.com

Updates: Status: Fixed Comment #1 on issue 3715 by Benjamin...(a)gmail.com: Workspace shouting after switching between shout/unshout http://code.google.com/p/pharo/issues/detail?id=3715 Done. Now, instead of creating a new instance of the styler class, I store them in two variables (nullStyler and shoutedStyler), and I switch when needed. It solves the problem, generate less garbage, and allow to keep styler changements Attachments: FixPluggableTextMorphForBetterShouting.1.cs 1.7 KB

Feb. 17, 2011

[Pharo-project] Issue 3724 in pharo: Finder updated

by pharo＠googlecode.com

Status: Fixed Owner: Benjamin...(a)gmail.com New issue 3724 by Benjamin...(a)gmail.com: Finder updated http://code.google.com/p/pharo/issues/detail?id=3724 Finder-BenjaminVanRyseghem.20 in PharoInbox Issue 3722: no comment I also added a 'Search' button that force the finder to perform the search :)

Feb. 17, 2011

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

by pharo＠googlecode.com

Updates: Status: Fixed Comment #1 on issue 3722 by Benjamin...(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 A method is a entity (a CompiledMethod instance) representing a method, while a selector represents the name of the method (it's an instance of Symbol). If you use the term "Method" some people will expect the search to be done in the source code of the method when others will expect the search to be done using the method's name. And you know, such a title is not really pleasant to read ... Attachments: Issue3722.1.cs 900 bytes

Feb. 17, 2011

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

by Douglas Brebner

On 16/02/2011 20:13, Eliot Miranda wrote: > > > On Wed, Feb 16, 2011 at 12:04 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: > > > On Feb 16, 2011, at 6:15 PM, Eliot Miranda wrote: > > > > > > > On Tue, Feb 15, 2011 at 11:50 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: > > Eliot a final question. > > So how will you handle OPAL compiler change in Cog? > > Do you require that marcus and jorge have to deal with > decompiler of caseOf: in addition to all the rest? > > Is it a strong requirement? Because then this is clear that Opal > will be delayed. But may be it is not that important after all. > > Just curious. > > > > OPAL is a Smalltalk compiler. I can therefore assume that it > will compile Smalltalk. caseOf: is valid Smalltalk and so will be > compiled by OPAL. Whether Marcus chooses to optimise caseOf: or > not is up to him. > > This is exactly my point. > > > No it's not. Your point was to raise two straw-=man arguments: > 1. that Marcus and Jorge would have to deal with the decompiler (not > an issue; the decompiler already deals with optimized caseOf: and the > new decompiler will deal with optimized caseOf: just as it'll deal > with optimized ifTrue: ifNotNil: et al). > 2. that supporting caseOf: in optimized form will delay Opal (not an > issue; Opal will optimize certain constructs, this is just one more > and won't add a lot of time). > > So your point appears to be to try and justify removing caseOf: on > spurious grounds by spreading FUD. > > This is so unlike you I'm having a hard time really understanding > what's going on. > > Correct me if I'm wrong but isn't Stephane essentially saying that Opal will just demote #caseOf: from inlined special form to normal method? (Possibly so it can be unloadable instead of being pinned in the system by the compiler support). It seems to me that this shouldn't affect caseOf: use in Cog since the inlining there is handled by the SLang translator. Or have I totally misunderstood? Of course, where caseOf: is kept afterwards another question :)

Feb. 17, 2011

Re: [Pharo-project] Pharo & LDAP

by Olivier Auverlot

Le 16/02/11 20:59, StÃ©phane Ducasse a Ã©crit : > did you check what you got in attrs? This is a dictionnary... this is why that i ask me the utility of the method asByteArray. > Because may be the code is simply old and require fixes. yes. it's possible. I already changed the code because it contains the deprecated method or:or: I will take time in the next day to evaluate LDAPlayer. I think it is critical for Pharo to have an LDAP network protocol. Many enterprises use it for user identification and data storage. Olivier ;-) www.auverlot.fr > Stef > >> Hi, >> >> For a project of REST services with Pharo and Seaside, I need to send requests to an LDAP server. I found a project named LDAPlayer on squeaksource. >> >> Now, I can create a connection and do a request to the LDAP server. >> >> But... my problem is to read an attribute in the result. In the LDAPSearchResultEntry object, the method to get a value is : >> >> attrAt: aKey >> | selected | >> selected := attrs at: (aKey asByteArray) ifAbsent: [ ^ nil ]. >> ^ selected first asString. >> >> The problem seems to be on the third line with the use of the asByteArray method. Why used this method ? >> >> For my tests, I remplaced it with : >> >> selected := attrs at: aKey ifAbsent: [ ^ nil ]. >> >> And now, it's ok but I don't know if my modification could introduce others problems. >> >> What do you think about that ? Someone has used LDAPlayer with Pharo ? >> >> Best regards >> >> Olivier ;-) >> >> www.auverlot.fr >> >

Feb. 17, 2011

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

by Igor Stasenko

On 17 February 2011 01:28, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > 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 ? > both. there is a bytecode which used for sends which bypassing lookup procedure. and compiler which generates them :) > Nicolas > >>> >>> Nicolas >>> >>>>> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> > > -- Best regards, Igor Stasenko AKA sig.

Feb. 17, 2011