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

Re: [Pharo-project] 1.3 link downloads 1.4 image

by Marcus Denker

On Aug 11, 2011, at 10:35 PM, Max Leske wrote: > The "Pharo 1.3" link on the webpage (beneath "Pharo 1.3 image (unstable)") actually downloads the 1.4 image. So at the moment there is no way to get a 1.3 image from the webpage. > Thanks, I fixed it: http://www.pharo-project.org/pharo-download We really need to finish 1.3 and edit the website... -- Marcus Denker -- http://marcusdenker.de

Aug. 12, 2011

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

by Nicolas Cellier

Please don't blam Lukas, this rule was explicitely part of st-80, and changes are recent Some explanations about this change are there: http://bugs.squeak.org/view.php?id=3616 Nicolas 2011/8/12 Lukas Renggli <renggli(a)gmail.com>: > On 12 August 2011 01:52, Damien Pollet <damien.pollet(a)gmail.com> wrote: >> Again, while we're at itâ¦ >> >> The definition of PPSmalltalkGrammar>>#binary looks wrong. It would >> not parse -- (double dash) as a binary selector. Camillo and I added a >> few tests for this, and a quick fix, but the way that rule was written >> suggests it was voluntary to forbid dashes after the first character. >> >> I guess it should be scrutinized a bit more, especially since I think >> various dialects accept different lengths and characters for binary >> selectorsâ¦ > > I saw your change and committed some more fixes. > > Up until a few years ago no Smalltalk allowed a dash in the last place > of a binary selector. I fixed this a while ago in the refactoring > browser, but didn't adapt the PPSmalltalkGrammar. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > >

Aug. 12, 2011

Re: [Pharo-project] PPElementParser & a small PetitTests contribution

by Lukas Renggli

> While we're at it, I committed a tiny change to the assertions in > PPAbstractParserTest, so that assertions return the parse result. I > needed it for cases where I don't want to compare to an expected > result, but still make further assertions than just "yup, it parses". Thank you, this is a great change. > For Coral I also wrote a simple PPDelegateParser subclass that applies > its inner parser to the stream first element. > It's like: > > PPPredicateObjectParser>>matching: elementParser message: aString > Â Â Â Â ^ self > Â Â Â Â Â Â Â Â on: [ :each | elementParser matches: each ] > Â Â Â Â Â Â Â Â message: aString > > BUT: it will return the parse result of its inner parser, rather than > the accepted element as-is. > > I use it to parse the argument array in a Coral script, some arguments > are expected to be integers or other parseable. It allows me to > predefine a bunch of utility parsers for simple argument types, that > return a ready-to-use object. > > If you want to see the code, it's PPElementParser in the Coral package > http://www.squeaksource.com/Coral.html > but mostly it looks like this: > > parseOn: aStream > Â Â Â Â | result | > Â Â Â Â aStream atEnd ifTrue: [ ^ PPFailure message: 'element expected' at: > aStream position ]. > Â Â Â Â result := parser "end" parse: aStream uncheckedPeek. > Â Â Â Â ^ result isPetitFailure > Â Â Â Â Â Â Â Â ifFalse: [ > Â Â Â Â Â Â Â Â Â Â Â Â aStream next. > Â Â Â Â Â Â Â Â Â Â Â Â result ] > Â Â Â Â Â Â Â Â ifTrue: [ > Â Â Â Â Â Â Â Â Â Â Â Â PPFailure > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â message: (message ifNil: ['error: ' , result printString , ' in element']) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â at: aStream position ] > > What do you think? I'm still not sure what the best way is. I > hesitated between subclassing PPDelegateParser, PPLiteralParserâ¦ maybe > a factory method in PPPredicateObjectParser would work as well: Do you have a ready made-image somewhere? I don't understand it from reading your mail only. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 12, 2011

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

by Lukas Renggli

On 12 August 2011 01:52, Damien Pollet <damien.pollet(a)gmail.com> wrote: > Again, while we're at itâ¦ > > The definition of PPSmalltalkGrammar>>#binary looks wrong. It would > not parse -- (double dash) as a binary selector. Camillo and I added a > few tests for this, and a quick fix, but the way that rule was written > suggests it was voluntary to forbid dashes after the first character. > > I guess it should be scrutinized a bit more, especially since I think > various dialects accept different lengths and characters for binary > selectorsâ¦ I saw your change and committed some more fixes. Up until a few years ago no Smalltalk allowed a dash in the last place of a binary selector. I fixed this a while ago in the refactoring browser, but didn't adapt the PPSmalltalkGrammar. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 12, 2011

Re: [Pharo-project] Pharo Kernel OSProcess evaluator

by David T. Lewis

On Thu, Aug 11, 2011 at 01:19:05PM +0200, Pavel Krivanek wrote: > On Thu, Aug 11, 2011 at 1:06 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > On Thu, Aug 11, 2011 at 12:23:51PM +0200, Pavel Krivanek wrote: > >> Hi, > >> > >> the main task of this build is to ensure that we can load OSProcess > >> and provide a pattern for the user jobs that want to use OSProcess. > >> > >> https://gitorious.org/pharo-build/pharo-build/blobs/master/scripts/pharo/Ke… > >> > >> The next purpose of this image is to enable an interactive > >> communication with the image and make the development of headless > >> images easier. What you get is something similar to irb or interactive > >> python interpreter. > >> > >> And of course it may be used for simple Smalltalk scripts. For example > >> the command: > >> > >> squeakvm -headless PharoKernel-OSProcessEvaluator.image < script > out.txt > >> > >> where the script file looks like this: > >> > >> 20000 factorial > >> Smalltalk snapshot: false andQuit: true > >> > >> (ending with lf) > >> > >> Cheers, > >> -- Pavel > > > > Cool :)) > > > > Here is another read-eval interpreter that you may want to look at > > just for fun: > > > > ?http://wiki.squeak.org/squeak/6023 > > > > I think your simple interpreter is better for what what you are doing > > here, but it's interesting to experiment with Squeak/Pharo as a /bin/sh > > replacement too. > > > > Dave > > Hi Dave, > > I know about it and I looked at it to see if it could be used for > Pharo Kernel. Currently it has many Morphic dependencies and it was > easier to write the simple evaluator loop ;-) Hi Pavel, Yes, you did the right thing :) Dave

Aug. 12, 2011

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

by Damien Pollet

Again, while we're at itâ¦ The definition of PPSmalltalkGrammar>>#binary looks wrong. It would not parse -- (double dash) as a binary selector. Camillo and I added a few tests for this, and a quick fix, but the way that rule was written suggests it was voluntary to forbid dashes after the first character. I guess it should be scrutinized a bit more, especially since I think various dialects accept different lengths and characters for binary selectorsâ¦ On 12 August 2011 00: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). > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 11, 2011

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

by Lukas Renggli

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). Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 11, 2011

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

by Frank Shearar

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. frank > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > >

Aug. 11, 2011

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

by Frank Shearar

Hi Stef, I'm reporting a bug in PetitSmalltalk, so why don't we concentrate on that? frank On 11 August 2011 21:56, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > frank > Â Â Â Â just to be clear, we do not like the GNU syntax for Coral, else we would have done it before. > Â Â Â Â See my reply to your question in the coral mailing-lits > > Â Â Â Â I think that > Â Â Â Â Â Â Â Â Eval [] > Â Â Â Â Â Â Â Â Class [] > Â Â Â Â Â Â Â Â Import [] > > > but I do not want nested definition nor class extension or class definition as in GNU. So if you want a GNU syntax > then make sure that it is optional and that we can get coral without it. > > Stef > > On Aug 11, 2011, at 10:48 PM, Frank Shearar wrote: > >> I'm extending Coral to support Gnu Smalltalk syntax, and ran into >> something strange. >> >> I asked Lukas and he said that since others would be interested, I >> should repost the question here. So: >> >> 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 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). >> >> Indeed, ripping out the parser of #number: >> >> Â n := ($- asParser optional , #digit asParser plus , ($. asParser , >> #digit asParser plus) optional) end. >> Â n parse: '1.' "=> end of input expected at 1" >> >> So I experimented a bit, and it seems like#number is being overly >> eager in consuming that $. character, and Number >> #readFrom:'s >> reading '1.': >> >> Â Number readFrom: '1.' readStream "=> 1.0" >> >> Â p := PPSmalltalkParser new. >> Â p number end parse: '1' "=> #(#(nil #($1) nil) 1)" >> >> Â p := PPSmalltalkParser new. >> Â p number end parse: '1.0' "=> #(#(nil #($1) #($. #($0))) 1.0)" >> >> Â p := PPSmalltalkParser new. >> Â p number end parse: '1. ' "=> end of input expected at 2" >> >> Or am I being silly? >> >> frank >> > >

Aug. 11, 2011

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

by Lukas Renggli

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:. Lukas -- Lukas Renggli www.lukas-renggli.ch

Aug. 11, 2011