September 2015 - Pharo-dev - lists.pharo.org

World.st has a new admin

by Geert Claes

The admin duties have now been handed over to Sean DeNigris who kindly volunteered to look after the www.world.st web presence as well as the Nabble archived mailing list forums on forum.world.st. As mentioned in a previous post, I did establish The World of Smalltalk some years ago I have now unfortunately too many other things on my plate. So I feel a person who is closer to the Smalltalk action will be better suited to take over the reins and I wish Sean all the best to continue! -- View this message in context: http://forum.world.st/World-st-has-a-new-admin-tp4851811.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 24, 2015

Re: [Pharo-dev] Some references to transcript should be changed into File stdout

by Sven Van Caekenberghe

> On 24 Sep 2015, at 15:38, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Stef, > > Transcript in Smalltalk-80 systems and in Squeak and earlier Pharo versions is a variable. So when the system is running headless or on the command line Transcript can be assigned something that writes to stdout (eg an instance of NonInteractiveTranscript). This is nice and simple. Eliminating the variable and replacing it by a class might be a mistake because it obscures the idea that Transcript may be different in different system states. Exactly, and that is what we have with NonInteractiveTranscript (and in Pharo 5, DailyNonInteractiveTranscript and TTranscript). > _,,,^..^,,,_ (phone) > >> On Sep 23, 2015, at 4:16 AM, stepharo <stepharo(a)free.fr> wrote: >> >> Hi >> >> I have the impression that some references to Transcript should be rewritten as File stdout >> >> For example >> >> DummyUIManager>>unhandledErrorDefaultAction: anException >> >> Transcript show: '*** EXCEPTION ***'; cr. >> Transcript show: anException; cr. >> Transcript show: (thisContext stack first: (20 min: thisContext stack size)); cr. >> anException isResumable ifTrue: [ anException resume ] >> >> Stef >> >

Sept. 24, 2015

Re: [Pharo-dev] Some references to transcript should be changed into File stdout

by Eliot Miranda

Hi Stef, Transcript in Smalltalk-80 systems and in Squeak and earlier Pharo versions is a variable. So when the system is running headless or on the command line Transcript can be assigned something that writes to stdout (eg an instance of NonInteractiveTranscript). This is nice and simple. Eliminating the variable and replacing it by a class might be a mistake because it obscures the idea that Transcript may be different in different system states. _,,,^..^,,,_ (phone) > On Sep 23, 2015, at 4:16 AM, stepharo <stepharo(a)free.fr> wrote: > > Hi > > I have the impression that some references to Transcript should be rewritten as File stdout > > For example > > DummyUIManager>>unhandledErrorDefaultAction: anException > > Transcript show: '*** EXCEPTION ***'; cr. > Transcript show: anException; cr. > Transcript show: (thisContext stack first: (20 min: thisContext stack size)); cr. > anException isResumable ifTrue: [ anException resume ] > > Stef >

Sept. 24, 2015

Re: [Pharo-dev] Question on AST

by Gustavo Santos

Thanks, it works. And I understand the process now On Thu, Sep 24, 2015 at 2:47 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 24 Sep 2015, at 14:40, Gustavo Santos <gugajansen(a)gmail.com> wrote: > > > > Hello, > > > > I'm working on code manipulation on Pharo using the AST. > > Recently, I ported my code to Pharo 5 and some of my tests are not > running anymore. > > Specifically, if I have a method as follows: > > > > method > > | variable | > > variable := 'String'. > > > > In Pharo 4, when I get the tree, I have a RBTemporaryNode representing > the declaration of the variable, and a RBVariableNode for the assignment at > the third line. > > > > In Pharo 5, I have two RBVariableNode's for both cases. And when I call > #isTemp I get a MNU because the return of #binding is nil. > > > > How can I now differentiate these two nodes in the example? Is this a > bug or a feature? :-P > > You need to do semantic analysis first. The idea that the parser does that > is just wrong, it was a mistake to add that. > So in Pharo5 I removed the hack in the parser. > > -> Parser parses, it knows nothing about semantics > -> Semantic analysis looks at variables and decides what they mean. > > The #binding is set by the semantic analysis. > (and, as it was nice, actually specialises the classes of variables) > > Right now you have to call #doSemanticAnalysis on the MethodNode. I am > planning to add some lazy init so this is done automaticaly > when accessing #binding of a variableâ¦ > > Marcus > > > -- Gustavo Santos

Sept. 24, 2015

Re: [Pharo-dev] Question on AST

by Marcus Denker

> On 24 Sep 2015, at 14:40, Gustavo Santos <gugajansen(a)gmail.com> wrote: > > Hello, > > I'm working on code manipulation on Pharo using the AST. > Recently, I ported my code to Pharo 5 and some of my tests are not running anymore. > Specifically, if I have a method as follows: > > method > | variable | > variable := 'String'. > > In Pharo 4, when I get the tree, I have a RBTemporaryNode representing the declaration of the variable, and a RBVariableNode for the assignment at the third line. > > In Pharo 5, I have two RBVariableNode's for both cases. And when I call #isTemp I get a MNU because the return of #binding is nil. > > How can I now differentiate these two nodes in the example? Is this a bug or a feature? :-P You need to do semantic analysis first. The idea that the parser does that is just wrong, it was a mistake to add that. So in Pharo5 I removed the hack in the parser. -> Parser parses, it knows nothing about semantics -> Semantic analysis looks at variables and decides what they mean. The #binding is set by the semantic analysis. (and, as it was nice, actually specialises the classes of variables) Right now you have to call #doSemanticAnalysis on the MethodNode. I am planning to add some lazy init so this is done automaticaly when accessing #binding of a variableâ¦ Marcus

Sept. 24, 2015

Question on AST

by Gustavo Santos

Hello, I'm working on code manipulation on Pharo using the AST. Recently, I ported my code to Pharo 5 and some of my tests are not running anymore. Specifically, if I have a method as follows: method | variable | variable := 'String'. In Pharo 4, when I get the tree, I have a RBTemporaryNode representing the declaration of the variable, and a RBVariableNode for the assignment at the third line. In Pharo 5, I have two RBVariableNode's for both cases. And when I call #isTemp I get a MNU because the return of #binding is nil. How can I now differentiate these two nodes in the example? Is this a bug or a feature? :-P Cheers, -- Gustavo Santos

Sept. 24, 2015

Re: [Pharo-dev] - 250 * 1.5 is not the same as 250 * 1.5

by Thierry Goubier

2015-09-24 14:01 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2015-09-24 13:23 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> Then, given that negative numbers are correctly tokenified by the >> RBParser, I would remove that logic in Pharo's RBParser. >> >> (From a front-end implementor point of view, I also would have no issue >> with someone specifying a negative literal as - (\s)* [0-9]+ either. There >> is so much silliness in your average language front-end anyway). >> >> > My grief was the interpretation of literal arrays: #(1 - 2) is currently > not #(1 -2), so if space is gobbled at tokenization, that's a semantic > shift... > Do we want to keep #(1 - 2) or shall we force some more pedantic #(1 #- 2)? > Fair point. I'd guess that, on average, people have a good chance of guessing #(1 - 2) wrong ;) but I'd keep the no space between - and the number, just for the fact it makes documentation clearer. > > >> What is the state of RBParser in Squeak about that? >> > > RBParser is not in trunk, it's an add-on. > No idea which/where is the latest Squeak-compatible version... > Oh, I would have expected RB to be included in Squeak trunk. Good to know :) Thierry > > >> >> Thierry >> >> >> 2015-09-24 12:03 GMT+02:00 Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com>: >> >>> Oh, and I suspect an instability in the numbering of squeak-dev >>> archive... >>> The reference thread is (today) >>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-May/103684.html >>> >>> 2015-09-24 11:39 GMT+02:00 Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com>: >>> >>>> A space used to be accepted between minus sign and number in old >>>> versions of Squeak compiler (before 2010) >>>> But I doubt this was decided on purpose. >>>> IMO it was more a side effect of the implementation, which had messy >>>> corners >>>> (the fact that the tokenizer did produce two tokens $- and positive >>>> number) >>>> >>>> I would add that this was undocumented, dialect specific, and a false >>>> good idea letting newbies think that they can use unary prefixed >>>> operators... >>>> There is no such thing in the language. >>>> >>>> Oh, and this even has changed in Squeak a few years ago: >>>> >>>> ------------------------------------------------------- >>>> >>>> http://source.squeak.org/trunk/Compiler-nice.120.mcz >>>> >>>> ==================== Summary ==================== >>>> >>>> Name: Compiler-nice.120 >>>> Author: nice >>>> Time: 23 February 2010, 5:14:44.049 pm >>>> UUID: 9429cc05-281b-484e-94c2-bd0baf4f5230 >>>> Ancestors: Compiler-nice.119 >>>> >>>> Authorize - at any position in binary selectors (like VW 7.7) >>>> See http://bugs.squeak.org/view.php?id=3616 >>>> Address the problem of compiling 1@-2 with following strategy: >>>> >>>> If compiler is non interactive, then compile with backward >>>> compatibility 1 @ (-2). >>>> If compiler is interactive, propose a menu to disambiguate and insert >>>> a proper space. >>>> 1@ -2 -> MessageSend receiver: 1 selector: #'@' argument: -2 >>>> 1@- 2 -> MessageSend receiver: 1 selector: #'@-' argument: 2 >>>> >>>> Warning: Squeak did understand (1@- 2) as (1 @ (-2)).... >>>> I didn't do anything to support this vicious Squeakism, and by now the >>>> semantics are change. >>>> >>>> >>>> 2015-09-24 9:25 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >>>> >>>>> >>>>> >>>>> 2015-09-24 8:19 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >>>>> >>>>>> > - 250 * 1.5 returns -2.25 >>>>>> >>>>>> why is this valid syntax? >>>>>> >>>>> >>>>> It should not. RBParser bug. This is not valid Smalltalk syntax. As >>>>> Ben showed similar cases raise an error but this one generate incorrect >>>>> compiledMethod instead. >>>>> >>>>> >>>>>> >>>>>> On Thu, Sep 24, 2015 at 5:35 AM, Ben Coman <btc(a)openinworld.com> >>>>>> wrote: >>>>>> >>>>>>> RBParser parseExpression: '-250 * 1.5' => "RBMessageNode(-250 * 1.5)" >>>>>>> RBParser parseExpression: '- 250 * 1.5' => "RBMessageNode(*1.5 * >>>>>>> 1.5)" >>>>>>> >>>>>>> RBParser parseExpression: '250 * -1.5' => "RBMessageNode(250 * >>>>>>> -1.5)" >>>>>>> RBParser parseExpression: '250 * - 1.5' => MNU >>>>>>> RBToken>>realvalue. >>>>>>> >>>>>>> RBParser parseExpression: '-250' => "RBLiteralValueNode(-250)" >>>>>>> RBParser parseExpression: '- 250' => MNU RBToken>>realvalue. >>>>>>> >>>>>>> So how significant should be the space between the negative sign and >>>>>>> its number? >>>>>>> >>>>>>> cheers -ben >>>>>>> >>>>>>> On Thu, Sep 24, 2015 at 6:34 AM, ClÃ©ment Bera < >>>>>>> bera.clement(a)gmail.com> wrote: >>>>>>> > RBParser parseExpression: '- 250 * 1.5' => Answers >>>>>>> RBMessageNode(*1.5 * >>>>>>> > 1.5) >>>>>>> > >>>>>>> > Second expression looks correct. >>>>>>> > >>>>>>> > Hence RBParser bug. >>>>>>> > >>>>>>> > 2015-09-23 23:42 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be >>>>>>> >: >>>>>>> >> >>>>>>> >> debug it on the first one gives "MNU: receiver of >>>>>>> "doSemanticAnalyisIn:" >>>>>>> >> is nil. >>>>>>> >> >>>>>>> >> Weird. >>>>>>> >> >>>>>>> >> On Wed, Sep 23, 2015 at 8:40 AM, stepharo <stepharo(a)free.fr> >>>>>>> wrote: >>>>>>> >>> >>>>>>> >>> Hi guys >>>>>>> >>> >>>>>>> >>> I think that this is quite bad that >>>>>>> >>> - 250 * 1.5 returns -2.25 >>>>>>> >>> >>>>>>> >>> while >>>>>>> >>> >>>>>>> >>> -250 * 1.5 return 375 >>>>>>> >>> >>>>>>> >>> stef >>>>>>> >>> >>>>>>> >> >>>>>>> > >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >

Sept. 24, 2015

Re: [Pharo-dev] - 250 * 1.5 is not the same as 250 * 1.5

by Nicolas Cellier

2015-09-24 13:23 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Then, given that negative numbers are correctly tokenified by the > RBParser, I would remove that logic in Pharo's RBParser. > > (From a front-end implementor point of view, I also would have no issue > with someone specifying a negative literal as - (\s)* [0-9]+ either. There > is so much silliness in your average language front-end anyway). > > My grief was the interpretation of literal arrays: #(1 - 2) is currently not #(1 -2), so if space is gobbled at tokenization, that's a semantic shift... Do we want to keep #(1 - 2) or shall we force some more pedantic #(1 #- 2)? > What is the state of RBParser in Squeak about that? > RBParser is not in trunk, it's an add-on. No idea which/where is the latest Squeak-compatible version... > > Thierry > > > 2015-09-24 12:03 GMT+02:00 Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com>: > >> Oh, and I suspect an instability in the numbering of squeak-dev archive... >> The reference thread is (today) >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-May/103684.html >> >> 2015-09-24 11:39 GMT+02:00 Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com>: >> >>> A space used to be accepted between minus sign and number in old >>> versions of Squeak compiler (before 2010) >>> But I doubt this was decided on purpose. >>> IMO it was more a side effect of the implementation, which had messy >>> corners >>> (the fact that the tokenizer did produce two tokens $- and positive >>> number) >>> >>> I would add that this was undocumented, dialect specific, and a false >>> good idea letting newbies think that they can use unary prefixed >>> operators... >>> There is no such thing in the language. >>> >>> Oh, and this even has changed in Squeak a few years ago: >>> >>> ------------------------------------------------------- >>> >>> http://source.squeak.org/trunk/Compiler-nice.120.mcz >>> >>> ==================== Summary ==================== >>> >>> Name: Compiler-nice.120 >>> Author: nice >>> Time: 23 February 2010, 5:14:44.049 pm >>> UUID: 9429cc05-281b-484e-94c2-bd0baf4f5230 >>> Ancestors: Compiler-nice.119 >>> >>> Authorize - at any position in binary selectors (like VW 7.7) >>> See http://bugs.squeak.org/view.php?id=3616 >>> Address the problem of compiling 1@-2 with following strategy: >>> >>> If compiler is non interactive, then compile with backward >>> compatibility 1 @ (-2). >>> If compiler is interactive, propose a menu to disambiguate and insert a >>> proper space. >>> 1@ -2 -> MessageSend receiver: 1 selector: #'@' argument: -2 >>> 1@- 2 -> MessageSend receiver: 1 selector: #'@-' argument: 2 >>> >>> Warning: Squeak did understand (1@- 2) as (1 @ (-2)).... >>> I didn't do anything to support this vicious Squeakism, and by now the >>> semantics are change. >>> >>> >>> 2015-09-24 9:25 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >>> >>>> >>>> >>>> 2015-09-24 8:19 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >>>> >>>>> > - 250 * 1.5 returns -2.25 >>>>> >>>>> why is this valid syntax? >>>>> >>>> >>>> It should not. RBParser bug. This is not valid Smalltalk syntax. As Ben >>>> showed similar cases raise an error but this one generate incorrect >>>> compiledMethod instead. >>>> >>>> >>>>> >>>>> On Thu, Sep 24, 2015 at 5:35 AM, Ben Coman <btc(a)openinworld.com> >>>>> wrote: >>>>> >>>>>> RBParser parseExpression: '-250 * 1.5' => "RBMessageNode(-250 * 1.5)" >>>>>> RBParser parseExpression: '- 250 * 1.5' => "RBMessageNode(*1.5 * >>>>>> 1.5)" >>>>>> >>>>>> RBParser parseExpression: '250 * -1.5' => "RBMessageNode(250 * >>>>>> -1.5)" >>>>>> RBParser parseExpression: '250 * - 1.5' => MNU RBToken>>realvalue. >>>>>> >>>>>> RBParser parseExpression: '-250' => "RBLiteralValueNode(-250)" >>>>>> RBParser parseExpression: '- 250' => MNU RBToken>>realvalue. >>>>>> >>>>>> So how significant should be the space between the negative sign and >>>>>> its number? >>>>>> >>>>>> cheers -ben >>>>>> >>>>>> On Thu, Sep 24, 2015 at 6:34 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> >>>>>> wrote: >>>>>> > RBParser parseExpression: '- 250 * 1.5' => Answers >>>>>> RBMessageNode(*1.5 * >>>>>> > 1.5) >>>>>> > >>>>>> > Second expression looks correct. >>>>>> > >>>>>> > Hence RBParser bug. >>>>>> > >>>>>> > 2015-09-23 23:42 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >>>>>> >> >>>>>> >> debug it on the first one gives "MNU: receiver of >>>>>> "doSemanticAnalyisIn:" >>>>>> >> is nil. >>>>>> >> >>>>>> >> Weird. >>>>>> >> >>>>>> >> On Wed, Sep 23, 2015 at 8:40 AM, stepharo <stepharo(a)free.fr> >>>>>> wrote: >>>>>> >>> >>>>>> >>> Hi guys >>>>>> >>> >>>>>> >>> I think that this is quite bad that >>>>>> >>> - 250 * 1.5 returns -2.25 >>>>>> >>> >>>>>> >>> while >>>>>> >>> >>>>>> >>> -250 * 1.5 return 375 >>>>>> >>> >>>>>> >>> stef >>>>>> >>> >>>>>> >> >>>>>> > >>>>>> >>>>>> >>>>> >>>> >>> >> >

Sept. 24, 2015

Re: [Pharo-dev] - 250 * 1.5 is not the same as 250 * 1.5

by Thierry Goubier

Then, given that negative numbers are correctly tokenified by the RBParser, I would remove that logic in Pharo's RBParser. (From a front-end implementor point of view, I also would have no issue with someone specifying a negative literal as - (\s)* [0-9]+ either. There is so much silliness in your average language front-end anyway). What is the state of RBParser in Squeak about that? Thierry 2015-09-24 12:03 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > Oh, and I suspect an instability in the numbering of squeak-dev archive... > The reference thread is (today) > http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-May/103684.html > > 2015-09-24 11:39 GMT+02:00 Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com>: > >> A space used to be accepted between minus sign and number in old versions >> of Squeak compiler (before 2010) >> But I doubt this was decided on purpose. >> IMO it was more a side effect of the implementation, which had messy >> corners >> (the fact that the tokenizer did produce two tokens $- and positive >> number) >> >> I would add that this was undocumented, dialect specific, and a false >> good idea letting newbies think that they can use unary prefixed >> operators... >> There is no such thing in the language. >> >> Oh, and this even has changed in Squeak a few years ago: >> >> ------------------------------------------------------- >> >> http://source.squeak.org/trunk/Compiler-nice.120.mcz >> >> ==================== Summary ==================== >> >> Name: Compiler-nice.120 >> Author: nice >> Time: 23 February 2010, 5:14:44.049 pm >> UUID: 9429cc05-281b-484e-94c2-bd0baf4f5230 >> Ancestors: Compiler-nice.119 >> >> Authorize - at any position in binary selectors (like VW 7.7) >> See http://bugs.squeak.org/view.php?id=3616 >> Address the problem of compiling 1@-2 with following strategy: >> >> If compiler is non interactive, then compile with backward compatibility >> 1 @ (-2). >> If compiler is interactive, propose a menu to disambiguate and insert a >> proper space. >> 1@ -2 -> MessageSend receiver: 1 selector: #'@' argument: -2 >> 1@- 2 -> MessageSend receiver: 1 selector: #'@-' argument: 2 >> >> Warning: Squeak did understand (1@- 2) as (1 @ (-2)).... >> I didn't do anything to support this vicious Squeakism, and by now the >> semantics are change. >> >> >> 2015-09-24 9:25 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >>> >>> >>> 2015-09-24 8:19 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >>> >>>> > - 250 * 1.5 returns -2.25 >>>> >>>> why is this valid syntax? >>>> >>> >>> It should not. RBParser bug. This is not valid Smalltalk syntax. As Ben >>> showed similar cases raise an error but this one generate incorrect >>> compiledMethod instead. >>> >>> >>>> >>>> On Thu, Sep 24, 2015 at 5:35 AM, Ben Coman <btc(a)openinworld.com> wrote: >>>> >>>>> RBParser parseExpression: '-250 * 1.5' => "RBMessageNode(-250 * 1.5)" >>>>> RBParser parseExpression: '- 250 * 1.5' => "RBMessageNode(*1.5 * >>>>> 1.5)" >>>>> >>>>> RBParser parseExpression: '250 * -1.5' => "RBMessageNode(250 * >>>>> -1.5)" >>>>> RBParser parseExpression: '250 * - 1.5' => MNU RBToken>>realvalue. >>>>> >>>>> RBParser parseExpression: '-250' => "RBLiteralValueNode(-250)" >>>>> RBParser parseExpression: '- 250' => MNU RBToken>>realvalue. >>>>> >>>>> So how significant should be the space between the negative sign and >>>>> its number? >>>>> >>>>> cheers -ben >>>>> >>>>> On Thu, Sep 24, 2015 at 6:34 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> >>>>> wrote: >>>>> > RBParser parseExpression: '- 250 * 1.5' => Answers >>>>> RBMessageNode(*1.5 * >>>>> > 1.5) >>>>> > >>>>> > Second expression looks correct. >>>>> > >>>>> > Hence RBParser bug. >>>>> > >>>>> > 2015-09-23 23:42 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: >>>>> >> >>>>> >> debug it on the first one gives "MNU: receiver of >>>>> "doSemanticAnalyisIn:" >>>>> >> is nil. >>>>> >> >>>>> >> Weird. >>>>> >> >>>>> >> On Wed, Sep 23, 2015 at 8:40 AM, stepharo <stepharo(a)free.fr> wrote: >>>>> >>> >>>>> >>> Hi guys >>>>> >>> >>>>> >>> I think that this is quite bad that >>>>> >>> - 250 * 1.5 returns -2.25 >>>>> >>> >>>>> >>> while >>>>> >>> >>>>> >>> -250 * 1.5 return 375 >>>>> >>> >>>>> >>> stef >>>>> >>> >>>>> >> >>>>> > >>>>> >>>>> >>>> >>> >> >

Sept. 24, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50339 Home: https://github.com/pharo-project/pharo-core

Sept. 24, 2015