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

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

by Marcus Denker

Hi, What about postponing this dicussion to the week of the 7th of march? This will be far easier... (and I really did not have the energy to follow this discussion. Most of the emails in this thread I did not read). Marcus On Feb 16, 2011, at 12:12 PM, StÃ©phane Ducasse wrote: > > On Feb 16, 2011, at 6:12 PM, Eliot Miranda wrote: > >> >> >> On Tue, Feb 15, 2011 at 11:17 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> But it looks like a DSL to me. >> >> No its not. caseOf: is valid Smalltalk. It is another control structure defined in the library rather than by the language, just like do:, inject:into: et al. It is extremely useful in certain circumstances. It can be (and is) optimized. Functional languages support case statements that are conceptually similar. caseOf: (and those of functional languages) are *much* more powerful than the switch statement of C: caseOf: can dispatch on arbitrary values, not just integer indices; caseOf:'s selectors (the things on the left of the ->'s) can be expressions, not just constants. >> >> So caseOf: could be moved to Cog. >> >> Fine. Let me be equally pig-headed then. I'm not going to spend any more energy on this, and I'm not going to spend any more energy on Cog in Pharo. This is ridiculous. > > Then perfect be mad at me and take all the pharoers in prison. This is the only solution. > Since you have the power to do it and I cannot do anything about it. I let you choose if I'm a real assshole, a plain idiot > or just that I suggest something to ease our future. > what I suggest is to > - stop inlining caeOf so that the transition path to OPAL is easier > - let caseOf use for VMMaker. > > It would take 15 min to do that and probably 30 min to fix tools that are using caseOf: out of VMMaker. > > Stef > > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 16, 2011

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

by Eliot Miranda

On Wed, Feb 16, 2011 at 12:04 PM, StÃ©phane Ducasse < stephane.ducasse(a)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> 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. best regards, Eliot > > > > > > > Stef > > (if you think that I focus on details then I'm certainly an idiot). > > > > > > > > >

Feb. 16, 2011

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

by StÃ©phane Ducasse

Igor my point is how can we migrate from the old compiler to the new one that will probably not support inlining of caseOf: if we rely or have caseOf: in the old compiler. If we do not need case of inlining then we can remove it and we can also clean Object. Stef On Feb 16, 2011, at 6:42 PM, Igor Stasenko wrote: > On 16 February 2011 18:15, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> >> On Tue, Feb 15, 2011 at 11:50 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)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. > > And this was the question from the beginning of this thread :) > Except that not all realized that Stef were talking about new compiler (Opal), > not existing one. > I am perfectly fine with current state of Compiler.. and it is really > not worth adding/removing something from it, > because in Pharo plans to integrate new compiler infrastructure. > So, it is obvious that any work on old compiler is a waste of time and energy. > > >>> >>> Stef >>> (if you think that I focus on details then I'm certainly an idiot). >>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Feb. 16, 2011

Re: [Pharo-project] Call for Pharo Support **important**

by StÃ©phane Ducasse

Thanks miguel follow the process sign the letter and send it to me. On Feb 16, 2011, at 7:32 PM, Miguel CobÃ¡ wrote: > > Ok, I understand the goal. Count me in. > > El miÃ©, 16-02-2011 a las 13:52 +0100, StÃ©phane Ducasse escribiÃ³: >> On Feb 16, 2011, at 12:59 PM, Schwab,Wilhelm K wrote: >> >>> Stef, >>> >>> The revised language is much improved. >> >> tx >> >>> I too am curious about what you have in mind on the conditions. >> >> We do not know. :) just fuzzy ideas. >> We will decide with the community. Because the point is that this is not our stuff but a tool that should serve the community. >> We were thinking >> - individual memberships >> - company memberships >> - institution memberships >> or/and a moral license so that you can buy pharo and a guy like igor/esteban can get pay to improve the infrastructure. >> or a bounty (but a moral license is good since it does not bind the task). >> >> >>> Are you looking for support from institutions or individuals? I assume both, but the thresholds would be different for UF than for me by myself. >> >> Yes both. This would be excellent. >> >> Recently I was asking myself three essential questions beside having a market: ok we have a client so what >> - how do you control quality/process? >> - how do you control that your runtime engine is ok/safe/longlasting (else better take java vms there are plenty) >> - how do you reduce risk like truck factor in your community. >> >> Our main point is how can we minimize risk: I'm thinking to participate to a startup around a pharo software and here is a simple >> simple scenario: imagine that eliot gets hired by XXAS to do javascript/ruby whatever and andreas (which does not reply to my mails >> because I'm probably too insignificant) goes waco and that ian only shows up every three years instead of every year. >> do you think that it is wise for companies to invest in an open-source smalltalk? >> I would not. Now if we have a consortium, a build process, a quality process and one or two guys payed by the community >> to improve continously the system more than we can. Then this is a message I can understand as an investor. >> >> Since we want to make sure that you all can do business we want to reduce risk and provide a good case for process, quality and the >> rest. >> >> >> Stef >> >> >> >>> >>> Bill >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] >>> Sent: Wednesday, February 16, 2011 5:00 AM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] Call for Pharo Support **important** >>> >> >> > > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > >

Feb. 16, 2011

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

by StÃ©phane Ducasse

On Feb 16, 2011, at 6:12 PM, Eliot Miranda wrote: > > > On Tue, Feb 15, 2011 at 11:17 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > But it looks like a DSL to me. > > No its not. caseOf: is valid Smalltalk. It is another control structure defined in the library rather than by the language, just like do:, inject:into: et al. It is extremely useful in certain circumstances. It can be (and is) optimized. Functional languages support case statements that are conceptually similar. caseOf: (and those of functional languages) are *much* more powerful than the switch statement of C: caseOf: can dispatch on arbitrary values, not just integer indices; caseOf:'s selectors (the things on the left of the ->'s) can be expressions, not just constants. > > So caseOf: could be moved to Cog. > > Fine. Let me be equally pig-headed then. I'm not going to spend any more energy on this, and I'm not going to spend any more energy on Cog in Pharo. This is ridiculous. Then perfect be mad at me and take all the pharoers in prison. This is the only solution. Since you have the power to do it and I cannot do anything about it. I let you choose if I'm a real assshole, a plain idiot or just that I suggest something to ease our future. what I suggest is to - stop inlining caeOf so that the transition path to OPAL is easier - let caseOf use for VMMaker. It would take 15 min to do that and probably 30 min to fix tools that are using caseOf: out of VMMaker. Stef

Feb. 16, 2011

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

by StÃ©phane Ducasse

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> 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. > > > Stef > (if you think that I focus on details then I'm certainly an idiot). > > >

Feb. 16, 2011

Re: [Pharo-project] Soap and XML

by Guillermo Polito

Actually, I'm the admin of the repo :P. But I've granted global read and write access, so feel free to commit your contribution!! I'm not currently mantaining SoapOpera, but I expect I will be able to do it in the near future, hehe. Thank you! Guille On Wed, Feb 16, 2011 at 4:57 PM, Otto Behrens <otto(a)finworks.biz> wrote: > Hi, > > I would like to add to this that I'm getting an authentication failure > when trying to save to the squeaksource projects listed below. I > assumed that someone must add me to the list of developers on a > project. Am I following protocol here by posting this to the list or > should I send this to the admins? > > Thanks > Otto > > > ---------- Forwarded message ---------- > From: Otto Behrens <otto(a)finworks.biz> > Date: Wed, Feb 16, 2011 at 7:25 PM > Subject: Soap and XML > To: squeak-dev(a)lists.squeakfoundation.org > Cc: GemStone Seaside beta discussion <beta(a)seaside.gemstone.com> > > > Hello, > > I've made some changes to XML-Parser and SoapOpera and would like to > contribute them to http://www.squeaksource.com/SoapOpera/ and > http://www.squeaksource.com/XMLSupport. I've ported the most recent > XML-Parser to work in GemStone and also got SoapOpera to work with > this XML-Parser. My next step is to get SoapOpera to work in GemStone. > > HTH > Otto Behrens >

Feb. 16, 2011

Re: [Pharo-project] [COTDC] 13 - NullEncoder

by StÃ©phane Ducasse

Igor encoder was used for postcript encoding too. So this is not totally bad. Stef >>> >>> wrote: >>>> Today: NullEncoder >>>> >>> >>> I am a Canvas superclass with completely misleading name and purpose. >> >> >> yep. And not referenced. Should be merged with Canvas ? > > You kidding? > > If not, then give me an answer, what canvas should do for these messages: > > canvas contents > canvas writeDictionary: dict > canvas cr > canvas process: someObject > ? > > :) > > > And what is the canvas'es target ivar? what it suppose to represent? > >> Laurent. >> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Feb. 16, 2011

Re: [Pharo-project] Issue 3712 in pharo: Still CustomMenu references in Pharo 1.2 dev

by pharo＠googlecode.com

Updates: Status: Fixed Comment #3 on issue 3712 by stephane...(a)gmail.com: Still CustomMenu references in Pharo 1.2 dev http://code.google.com/p/pharo/issues/detail?id=3712 I will publish a new sound package Attachments: fixingCustomMenu.2.cs 7.6 KB

Feb. 16, 2011

Re: [Pharo-project] Pharo & LDAP

by StÃ©phane Ducasse

did you check what you got in attrs? Because may be the code is simply old and require fixes. 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. 16, 2011