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

Re: [Pharo-project] abput Ring package

by Veronica Isabel Uquillas Gomez

On 12 Aug 2011, at 14:03, StÃ©phane Ducasse wrote: > Hi veronica > > did you check the API of Rpackage when designing ring package api? I had it before RPackage.. I haven't seen how RPackage looks now (but the basic methods were the same some time ago) I will check that this weekend. > > BTW if we deprecate realClass we should probably deprecate realParent... > so we should check what we do with actualClass. keep realClass & realParent :) > > Stef > >

Aug. 12, 2011

[Pharo-project] abput Ring package

by StÃ©phane Ducasse

Hi veronica did you check the API of Rpackage when designing ring package api? BTW if we deprecate realClass we should probably deprecate realParent... so we should check what we do with actualClass. Stef

Aug. 12, 2011

Re: [Pharo-project] formatting style

by Lukas Renggli

Hmm, I don't get your example. What I changed is that the formatter does not enforce the useless parenthesis around the receiver of a cascade. Can be disabled though. Also note that there are settings to automatically format code on display and/or accept. I use the "on display" mode often to read ugly code :-) Lukas On 12 August 2011 13:29, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes > > Â Â Â Â Smalltalk tools > Â Â Â Â Â Â Â Â register: ;lkl;k;lk;l > Â Â Â Â Â Â Â Â in: lkl;k;lkl;kl; > > > stef > On Aug 12, 2011, at 1:20 PM, Lukas Renggli wrote: > >>> I always think of this a the Seaside style, but I am not sure if that is a correct attribution. >> >> Haha, thank you. >> >> Actually the refactoring browser formatter with the default settings >> is quite close to the Seaside style, I just recently submitted some >> fixes for cascades. The only thing that I don't like about the >> automatic formatter is how the brackets in multiline blocks are >> aligned. Anyway, the formatter would style #inject:into: as you >> suggest. >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > -- Lukas Renggli www.lukas-renggli.ch

Aug. 12, 2011

Re: [Pharo-project] Bug in parsing numbers in PPSmalltalkGrammar?

by Frank Shearar

On 12 August 2011 12:12, Lukas Renggli <renggli(a)gmail.com> wrote: > Yes, exactly. > > Ideally we should probably implement the number parsing in > PetitParser. Maybe as a separate parser that can be used in > PPSmalltalkGrammar? If you want to give it a try, I am happy to review > it. Yes, I'm happy to do that. I assume (I'll check later too...) that Pharo has a test suite describing number syntax? That'll give me something I can steal/copy for the number subgrammar. While I try figure out if Squeak actually meant to have Number readFrom: '1.' == 1.0, I'll work against Pharo's idea of what a number is. I can see dialect-specific subclassing parsers anyway, which can live in separate packages. (I've got a largely-working Gnu Smalltalk parser working, for instance (modulo my limited understanding of gst's grammar).) frank > Lukas > > On 12 August 2011 12:50, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> On 11 August 2011 23:30, Lukas Renggli <renggli(a)gmail.com> wrote: >>> >>> >>> On Friday, 12 August 2011, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>> On 11 August 2011 22:05, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>> Hi Frank, >>>>> >>>>>> I asked Lukas and he said that since others would be interested, I >>>>>> should repost the question here. So: >>>>> >>>>> Thanks! >>>>> >>>>>> Gnu Smalltalk's class variable declarations take the form of >>>>>> [<identifier> := <expression>.]* at the end of an object definition. >>>>>> To that end I wrote a #classVars production like so: >>>>>> >>>>>> Â classVars >>>>>> Â Â Â ^ (assignment , expression , $. asParser) star >>>>>> Â Â Â "Possibly I need to support the lack of a dot on the last >>>>>> expression. Not relevant at the moment" >>>>> >>>>> This seems to be indeed the same problem as the simpler case below ... >>>>> >>>>>> This didn't work as expected. Looking further, I found this oddity: >>>>>> >>>>>> Â p := PPSmalltalkParser new. >>>>>> Â p number end parse: '1.' "=> #(#(nil #($1) nil) 1.0)" >>>>>> >>>>>> I would expect this to fail, because "1." isn't a number (but see >>>>>> below). >>>>> >>>>> This fails in Pharo 1.3. In fact, in Pharo the following statements >>>>> return 'false': >>>>> >>>>> Â | s | >>>>> Â s := '1.' readStream. >>>>> Â Number readFrom: s. >>>>> Â s atEnd >>>>> >>>>> That is, #readFrom: really only consumes what it can. I don't know >>>>> what Smalltalk you use, but I guess your image consumes the $. and >>>>> returns 'true'. Not sure if this can be called a bug, but it is >>>>> definitely a bit strange. The definition of a valid number literal is >>>>> quite different among different Smalltalk dialects, thus I decided to >>>>> rely on the built-in implementation of Number class>>#readFrom:. >>>> >>>> I'm using Squeak (trunk), and there we have >>>> >>>> Â Â Number readFrom: '1.' readStream "=> 1.0" >>>> Â Â Number readFrom: '1' readStream "=> 1" >>>> >>>> So what might be happening is that the stream contains '1.' but >>>> Pharo's version doesn't care, and returns an Integer? >>>> >>>> Ah. Ahem. Indeed, that's what's happening. Number gets '1.', and in >>>> Pharo that means 1 while in Squeak it means 1.0. >>>> >>>> I find it a bit strange that PPSmalltalkGrammar sends off '1.', but I >>>> also think that Squeak's doing the wrong thing. >>> >>> PPSmalltalkGrammar doesn't send off anything, it just delegates to the >>> number reader by passing over its stream. In return PPSmalltalkGrammar >>> expects a number and that the number reader leaves the stream at the end of >>> the number. This is the same than the refactoring browser parser and the >>> standard compiler do in Pharo (I believe). >> >> OK. So when parsing '1.' readStream. PPSmalltalkGrammar will send off >> (a stream containing) '1.' to something (in this case Number class >> >> #readFrom:), which will eat the Number. Then PPSmalltalkGrammar picks >> up the stream with whatever's still left unparsed. >> >> In Pharo's case that means that 1 is returned, leaving '.' on the >> stream; in Squeak's case Number eats the '1.', returns 1.0 and then >> leaves the stream empty. >> >> Is that an accurate restatement of the issue? >> >> frank >> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > >

Aug. 12, 2011

Re: [Pharo-project] formatting style

by StÃ©phane Ducasse

Yes Smalltalk tools register: ;lkl;k;lk;l in: lkl;k;lkl;kl; stef On Aug 12, 2011, at 1:20 PM, Lukas Renggli wrote: >> I always think of this a the Seaside style, but I am not sure if that is a correct attribution. > > Haha, thank you. > > Actually the refactoring browser formatter with the default settings > is quite close to the Seaside style, I just recently submitted some > fixes for cascades. The only thing that I don't like about the > automatic formatter is how the brackets in multiline blocks are > aligned. Anyway, the formatter would style #inject:into: as you > suggest. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Aug. 12, 2011

Re: [Pharo-project] ring new version question

by StÃ©phane Ducasse

ok so let us keep it like that then :) >> >> = anotherMethodReference >> "Answer whether the receiver and the argument represent the >> same object." >> ^ self species == anotherMethodReference species >> and: [(self classSymbol = anotherMethodReference classSymbol) >> and: [(self classIsMeta = anotherMethodReference classIsMeta) >> and: [self methodSymbol = anotherMethodReference methodSymbol]]] >> > > The one in ring does exactly the same, the super call is checking the parentName and isMetaSide > >> >> On Aug 12, 2011, at 11:51 AM, StÃ©phane Ducasse wrote: >> >>> Another question >>> >>> >>> = aRGMethodDefinition >>> "This method look for equality of the key properties of the receiver" >>> >>> ^(super = aRGMethodDefinition) >>> and:[ self selector == aRGMethodDefinition selector ] >>> >>> why not category? and source pointer? >>> >>> S. >>> >> >> > >

Aug. 12, 2011

Re: [Pharo-project] formatting style

by Lukas Renggli

> I always think of this a the Seaside style, but I am not sure if that is a correct attribution. Haha, thank you. Actually the refactoring browser formatter with the default settings is quite close to the Seaside style, I just recently submitted some fixes for cascades. The only thing that I don't like about the automatic formatter is how the brackets in multiline blocks are aligned. Anyway, the formatter would style #inject:into: as you suggest. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 12, 2011

Re: [Pharo-project] Bug in parsing numbers in PPSmalltalkGrammar?

by Lukas Renggli

Yes, exactly. Ideally we should probably implement the number parsing in PetitParser. Maybe as a separate parser that can be used in PPSmalltalkGrammar? If you want to give it a try, I am happy to review it. Lukas On 12 August 2011 12:50, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 11 August 2011 23:30, Lukas Renggli <renggli(a)gmail.com> wrote: >> >> >> On Friday, 12 August 2011, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>> On 11 August 2011 22:05, Lukas Renggli <renggli(a)gmail.com> wrote: >>>> Hi Frank, >>>> >>>>> I asked Lukas and he said that since others would be interested, I >>>>> should repost the question here. So: >>>> >>>> Thanks! >>>> >>>>> Gnu Smalltalk's class variable declarations take the form of >>>>> [<identifier> := <expression>.]* at the end of an object definition. >>>>> To that end I wrote a #classVars production like so: >>>>> >>>>> Â classVars >>>>> Â Â Â ^ (assignment , expression , $. asParser) star >>>>> Â Â Â "Possibly I need to support the lack of a dot on the last >>>>> expression. Not relevant at the moment" >>>> >>>> This seems to be indeed the same problem as the simpler case below ... >>>> >>>>> This didn't work as expected. Looking further, I found this oddity: >>>>> >>>>> Â p := PPSmalltalkParser new. >>>>> Â p number end parse: '1.' "=> #(#(nil #($1) nil) 1.0)" >>>>> >>>>> I would expect this to fail, because "1." isn't a number (but see >>>>> below). >>>> >>>> This fails in Pharo 1.3. In fact, in Pharo the following statements >>>> return 'false': >>>> >>>> Â | s | >>>> Â s := '1.' readStream. >>>> Â Number readFrom: s. >>>> Â s atEnd >>>> >>>> That is, #readFrom: really only consumes what it can. I don't know >>>> what Smalltalk you use, but I guess your image consumes the $. and >>>> returns 'true'. Not sure if this can be called a bug, but it is >>>> definitely a bit strange. The definition of a valid number literal is >>>> quite different among different Smalltalk dialects, thus I decided to >>>> rely on the built-in implementation of Number class>>#readFrom:. >>> >>> I'm using Squeak (trunk), and there we have >>> >>> Â Â Number readFrom: '1.' readStream "=> 1.0" >>> Â Â Number readFrom: '1' readStream "=> 1" >>> >>> So what might be happening is that the stream contains '1.' but >>> Pharo's version doesn't care, and returns an Integer? >>> >>> Ah. Ahem. Indeed, that's what's happening. Number gets '1.', and in >>> Pharo that means 1 while in Squeak it means 1.0. >>> >>> I find it a bit strange that PPSmalltalkGrammar sends off '1.', but I >>> also think that Squeak's doing the wrong thing. >> >> PPSmalltalkGrammar doesn't send off anything, it just delegates to the >> number reader by passing over its stream. In return PPSmalltalkGrammar >> expects a number and that the number reader leaves the stream at the end of >> the number. This is the same than the refactoring browser parser and the >> standard compiler do in Pharo (I believe). > > OK. So when parsing '1.' readStream. PPSmalltalkGrammar will send off > (a stream containing) '1.' to something (in this case Number class >> > #readFrom:), which will eat the Number. Then PPSmalltalkGrammar picks > up the stream with whatever's still left unparsed. > > In Pharo's case that means that 1 is returned, leaving '.' on the > stream; in Squeak's case Number eats the '1.', returns 1.0 and then > leaves the stream empty. > > Is that an accurate restatement of the issue? > > frank > >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > -- Lukas Renggli www.lukas-renggli.ch

Aug. 12, 2011

Re: [Pharo-project] Bug in parsing numbers in PPSmalltalkGrammar?

by Frank Shearar

On 11 August 2011 23:30, Lukas Renggli <renggli(a)gmail.com> wrote: > > > On Friday, 12 August 2011, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> On 11 August 2011 22:05, Lukas Renggli <renggli(a)gmail.com> wrote: >>> Hi Frank, >>> >>>> I asked Lukas and he said that since others would be interested, I >>>> should repost the question here. So: >>> >>> Thanks! >>> >>>> Gnu Smalltalk's class variable declarations take the form of >>>> [<identifier> := <expression>.]* at the end of an object definition. >>>> To that end I wrote a #classVars production like so: >>>> >>>> Â classVars >>>> Â Â Â ^ (assignment , expression , $. asParser) star >>>> Â Â Â "Possibly I need to support the lack of a dot on the last >>>> expression. Not relevant at the moment" >>> >>> This seems to be indeed the same problem as the simpler case below ... >>> >>>> This didn't work as expected. Looking further, I found this oddity: >>>> >>>> Â p := PPSmalltalkParser new. >>>> Â p number end parse: '1.' "=> #(#(nil #($1) nil) 1.0)" >>>> >>>> I would expect this to fail, because "1." isn't a number (but see >>>> below). >>> >>> This fails in Pharo 1.3. In fact, in Pharo the following statements >>> return 'false': >>> >>> Â | s | >>> Â s := '1.' readStream. >>> Â Number readFrom: s. >>> Â s atEnd >>> >>> That is, #readFrom: really only consumes what it can. I don't know >>> what Smalltalk you use, but I guess your image consumes the $. and >>> returns 'true'. Not sure if this can be called a bug, but it is >>> definitely a bit strange. The definition of a valid number literal is >>> quite different among different Smalltalk dialects, thus I decided to >>> rely on the built-in implementation of Number class>>#readFrom:. >> >> I'm using Squeak (trunk), and there we have >> >> Â Â Number readFrom: '1.' readStream "=> 1.0" >> Â Â Number readFrom: '1' readStream "=> 1" >> >> So what might be happening is that the stream contains '1.' but >> Pharo's version doesn't care, and returns an Integer? >> >> Ah. Ahem. Indeed, that's what's happening. Number gets '1.', and in >> Pharo that means 1 while in Squeak it means 1.0. >> >> I find it a bit strange that PPSmalltalkGrammar sends off '1.', but I >> also think that Squeak's doing the wrong thing. > > PPSmalltalkGrammar doesn't send off anything, it just delegates to the > number reader by passing over its stream. In return PPSmalltalkGrammar > expects a number and that the number reader leaves the stream at the end of > the number. This is the same than the refactoring browser parser and the > standard compiler do in Pharo (I believe). OK. So when parsing '1.' readStream. PPSmalltalkGrammar will send off (a stream containing) '1.' to something (in this case Number class >> #readFrom:), which will eat the Number. Then PPSmalltalkGrammar picks up the stream with whatever's still left unparsed. In Pharo's case that means that 1 is returned, leaving '.' on the stream; in Squeak's case Number eats the '1.', returns 1.0 and then leaves the stream empty. Is that an accurate restatement of the issue? frank > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch >

Aug. 12, 2011

Re: [Pharo-project] formatting style

by Sven Van Caekenberghe

+1 It is of course a delicate subject matter, but I also like spaces inside blocks, inside temporary declarations and after a return, this gives the code more space to breath (hmm ;-), so not inject: thisValue into: binaryBlock "Accumulate a running value associated with evaluating the argument, binaryBlock, with the current value of the argument, thisValue, and the receiver as block arguments. For instance, to sum the numeric elements of a collection, aCollection inject: 0 into: [:subTotal :next | subTotal + next]." |nextValue| nextValue := thisValue. self do: [:each | nextValue := binaryBlock value: nextValue value: each]. ^nextValue but inject: thisValue into: binaryBlock "Accumulate a running value associated with evaluating the argument, binaryBlock, with the current value of the argument, thisValue, and the receiver as block arguments. For instance, to sum the numeric elements of a collection, aCollection inject: 0 into: [:subTotal :next | subTotal + next]." | nextValue | nextValue := thisValue. self do: [ :each | nextValue := binaryBlock value: nextValue value: each ]. ^ nextValue I always think of this a the Seaside style, but I am not sure if that is a correct attribution. Sven On 12 Aug 2011, at 12:04, StÃ©phane Ducasse wrote: > I know that you all have your own hyper cool view on formatting. > > > =========================================== > Now I would really like that we agree on the minimum > > > put a space after a variable and before := > > stamp: anObject > "stores an author alias and a timestamp" > > stamp := anObject > > instead of > > stamp: anObject > "stores an author alias and a timestamp" > > stamp:= anObject > > > =========================================== > Put a space before method argument > > stamp: anObject > "stores an author alias and a timestamp" > > stamp := anObject > > instead of > > stamp:anObject > "stores an author alias and a timestamp" > > stamp := anObject > > > =========================================== > Put a space after ifNil: ifTrue: .... > > >

Aug. 12, 2011