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

Re: [Pharo-project] Issue 3720 in pharo: searching all source code: Comment Reference>>#asNode DNU

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3720 by marcus.d...(a)gmail.com: searching all source code: Comment Reference>>#asNode DNU http://code.google.com/p/pharo/issues/detail?id=3720 yes, that looks good.

Feb. 16, 2011

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

by StÃ©phane Ducasse

Ok this is my last mail on that topic. > 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 ] ])}. > 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

Feb. 16, 2011

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

by Marcus Denker

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? -- 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 StÃ©phane Ducasse

> > 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. Stef > > > Stef > > > On Feb 16, 2011, at 9:23 PM, Marcus Denker wrote: > > > 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] Issue 3720 in pharo: searching all source code: Comment Reference>>#asNode DNU

by pharo＠googlecode.com

Comment #2 on issue 3720 by stephane...(a)gmail.com: searching all source code: Comment Reference>>#asNode DNU http://code.google.com/p/pharo/issues/detail?id=3720 http://code.google.com/p/pharo/issues/detail?id=3589 marcus can you check if my fix fixes your problem.

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: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? 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. > Stef > > > On Feb 16, 2011, at 9:23 PM, Marcus Denker wrote: > > > 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] Issue 3720 in pharo: searching all source code: Comment Reference>>#asNode DNU

by pharo＠googlecode.com

Comment #1 on issue 3720 by stephane...(a)gmail.com: searching all source code: Comment Reference>>#asNode DNU http://code.google.com/p/pharo/issues/detail?id=3720 I fixed something in OB related to that. I thought it was integrated.

Feb. 16, 2011

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

by StÃ©phane Ducasse

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. Stef On Feb 16, 2011, at 9:23 PM, Marcus Denker wrote: > 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] Issue 3718 in pharo: Color class>>wheel: should be (back) on class side

by pharo＠googlecode.com

Updates: Status: accepted Labels: Milestone-1.3 Comment #2 on issue 3718 by stephane...(a)gmail.com: Color class>>wheel: should be (back) on class side http://code.google.com/p/pharo/issues/detail?id=3718 This may be just a bug due to MC packaging. We something lost methods in the past after a recategorization

Feb. 16, 2011

Re: [Pharo-project] Issue 3717 in pharo: Missing float array methods

by pharo＠googlecode.com

Comment #2 on issue 3717 by stephane...(a)gmail.com: Missing float array methods http://code.google.com/p/pharo/issues/detail?id=3717 oops I forget. so we should add this package in pharo-dev and sound UI is dependent on it.

Feb. 16, 2011