- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Reflectivity] What are the #arguments?

by Marcus Denker

> On 25 Sep 2015, at 13:02, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Good idea, I will add #availableReifications > https://pharo.fogbugz.com/f/cases/16642/availableReifications-return-the-li… <https://pharo.fogbugz.com/f/cases/16642/availableReifications-return-the-li…> I decided to return the symbolic encoded that is used when setting up the links: testAvailableReifications self assert: (RBMessageNode new availableReifications includes: #receiver). self deny: (RBMessageNode new availableReifications includes: #value). self assert: ((ReflectivityExamples classVariableNamed: #ClassVar) availableReifications includes: #name). self deny: ((ReflectivityExamples classVariableNamed: #ClassVar) availableReifications includes: #selector). (ReflectivityExamples classVariableNamed: #ClassVar) availableReifications ==> "#(#value #name)â Marcus

Sept. 26, 2015

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

by Ben Coman

On Sat, Sep 26, 2015 at 4:17 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2015-09-25 21:16 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> Hi Nicolas, >> >> On Thu, Sep 24, 2015 at 5:01 AM, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>> >>> >>> 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)? >> >> >> We should keep #(1 - 2) provided it is interpreted as #(1 #'-' 2). The # >> tags are noisy (if not ugly) and have never been necessary for literal >> symbols inside arrays. -2 is quite different from - 2. >> > > Agree, that's one good reason to not accept - 2 as a valid literal, for me > it's different than -2. > Separators have one semantic: they separrate. > white spaces are separators. Indeed. With '-2' being the literal, its a consideration of whether whitespace is allowed within a literal. Otherwise '1 - - 1' should evaluate to 2 ?? Currently it errors, which seems correct. '1 - -1' evaluates correctly to 2. > > >> >> Also why do you think this means? >> >> 1.0 >> >> Given that this means two different statements >> >> nil.nil >> >> IMO, . as a statement separator should be followed by whitespace to >> eliminate this ambiguity. i.e. nil.nil would be a syntax error, and nil. >> nil would be acceptable. This opens up the use of . in selectors to do cool >> things like the old multiple inheritance syntax where one could do directed >> sends such as super Dictionary.at: key if in a subclass with multiple >> superclasses and wanting to disambiguate which of multiple superclass >> implementations one wanted to invoke. > > > Dan said that he didn't want to make the separator mandatory, but I guess he > meant to apply this rule to an expression. > Forcing a separator between sentences would not hurt IMO too. > In any case, I never saw code written without separators between sentences. This sounds reasonable to me. cheers -ben > >> >> >> >>> >>> >>>> >>>> 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 >>>>>>>>> >>> >>>>>>>>> >> >>>>>>>>> > >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot > >

Sept. 26, 2015

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

by Nicolas Cellier

2015-09-25 21:16 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Nicolas, > > On Thu, Sep 24, 2015 at 5:01 AM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> >> >> 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)? >> > > We should keep #(1 - 2) provided it is interpreted as #(1 #'-' 2). The # > tags are noisy (if not ugly) and have never been necessary for literal > symbols inside arrays. -2 is quite different from - 2. > > Agree, that's one good reason to not accept - 2 as a valid literal, for me it's different than -2. Separators have one semantic: they separrate. white spaces are separators. > Also why do you think this means? > > 1.0 > > Given that this means two different statements > > nil.nil > > IMO, . as a statement separator should be followed by whitespace to > eliminate this ambiguity. i.e. nil.nil would be a syntax error, and nil. > nil would be acceptable. This opens up the use of . in selectors to do > cool things like the old multiple inheritance syntax where one could do > directed sends such as super Dictionary.at: key if in a subclass with > multiple superclasses and wanting to disambiguate which of multiple > superclass implementations one wanted to invoke. > Dan said that he didn't want to make the separator mandatory, but I guess he meant to apply this rule to an expression. Forcing a separator between sentences would not hurt IMO too. In any case, I never saw code written without separators between sentences. > > >> >> >>> 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 >>>>>>>> >>> >>>>>>>> >> >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > > -- > _,,,^..^,,,_ > best, Eliot >

Sept. 25, 2015

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

by Eliot Miranda

Hi Nicolas, On Thu, Sep 24, 2015 at 5:01 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 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)? > We should keep #(1 - 2) provided it is interpreted as #(1 #'-' 2). The # tags are noisy (if not ugly) and have never been necessary for literal symbols inside arrays. -2 is quite different from - 2. Also why do you think this means? 1.0 Given that this means two different statements nil.nil IMO, . as a statement separator should be followed by whitespace to eliminate this ambiguity. i.e. nil.nil would be a syntax error, and nil. nil would be acceptable. This opens up the use of . in selectors to do cool things like the old multiple inheritance syntax where one could do directed sends such as super Dictionary.at: key if in a subclass with multiple superclasses and wanting to disambiguate which of multiple superclass implementations one wanted to invoke. > > >> 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 >>>>>>> >>> >>>>>>> >> >>>>>>> > >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- _,,,^..^,,,_ best, Eliot

Sept. 25, 2015

Re: [Pharo-dev] System-Announcements: add a ProtocolRenamed announcement

by stepharo

Thanks thierry to look and discuss these points. I do not have enough calm time to get any concentration (of course I was teaching all day long). Stef Le 16/9/15 09:20, Thierry Goubier a Ã©crit : > > > 2015-09-16 11:05 GMT+02:00 Skip Lentz <skip.lentz(a)inria.fr > <mailto:skip.lentz@inria.fr>>: > ... > >> >> One more thing. I hope that when renaming the protocol, the >> relevant MethodRecategorized are sent, because many things depend >> on that one. > > Yes, those are already sent. ProtocolRenamed, if implemented, > should be announced in addition to those. > >> I need to check AltBrowser behavior on this one. Renaming a >> protocol is not what I expected. It looks harmless, but it has >> important consequences if the protocol is an extension or an >> override. > > Alright, let me know. > > > I think you can go forward. If the MethodRecategorized is sent, then > it should be OK. > > >> >> Thanks for your reply :) >> >> PS: Thereâs something else related to System-Announcements, >> namely that when I rename a category I get no CategoryRenamed >> announcement. >> I will send an e-mail about that later. >> >> >> Hum, SystemOrganizer>>#renameCategory:toBe: sends it (in Pharo4). > > Indeed it does, but RPackageTag>>#renameTo:category: suspends the > SystemAnnouncer while it sends SystemOrganizer>>#renameCategory:toBe:. > I donât know why, Iâm interested to know. Because > RPackageTag>>#renameTo:category: is used when you rename a > category (in Nautilus, at least). > > > I would heed Esteban advice on that. If the system announcer is > suspended, then this is probably because we may have some kind of > infinite loop and / or a incoherent state while renaming the system > category. > > I'll have a look too. > > Thierry > > > Skip > >

Sept. 25, 2015

Re: [Pharo-dev] Reflectivity: Links that de-install themselves (oneShot)

by stepharo

Tx this is I think a good idea (adding the setter) Le 20/9/15 14:17, Marcus Denker a Ã©crit : >> On 19 Sep 2015, at 01:10, stepharo <stepharo(a)free.fr> wrote: >> >> Marcus I have a API design question >> >> when you offer >> >> options: #(optionOneShot); >> >> versus >> >> optionOneShot >> >> Do you do a perform of the arrays selectors? >> What is the benefit of options: > I needed a mechanism for flags (stored not each in an ivar, as they normally > not active). As we have this mechanism in Opal already, I decided to use the > same pattern. > As in Opal, for all the pre-defined options we should not rely on perform: but > have explicit #optionOneShot getter/setter methods. I will add those later.. > > Marcus > > >

Sept. 25, 2015

Some news from the growing pharo teacher front

by stepharo

Hi guys I want to let you know that there will be a new pharo lecture in YaoundÃ©. I presented Pharo during a seminar and the previous minister of education was there and asked us to do a lecture. In June we did it with Damien C. by skype. And now there is an official lecture at YaoundÃ© given by Prof. Metalagia. This is an excellent news. I will give some lectures in december there. In Togo my first visit was quite successful: 120 participants to the conferences I gave (it was still vacation time there). There were 60 students following lectures from 8h to 17h during 4 days... Yes I'm exhausted ;) A new Pharo lecture will start in north Togo. I will go back in December. One of the idea is to help students to get good in Pharo and pharo web stack and build web apps and other. I hope that we can have within 2/3 year startups there. The gouverment in really pushing in that direction. There is a competition AppTogo. People are learning C# and other languages. So nothing is that easy :). I hope that some students will compete with Pharo so I will be looking for potential mentors to help them. Because I will be busy working on the mooc and other actions. Giving them advices, pointing them to the right solution/framework and may be a bit of pair programming if skype works. I distributed the Pharo Starter Kit (we will announce it officially now that I have 10 gb space on my server) People loved the Youtube videos folder I'm collecting. Yes internet is a pain there and avoiding to crawl on a slow internet is a plus. In addition the videos shows that our community is doing crazy stuff. Chloupis I put your great youtube tutorial! Thanks for it. some students watched it. Stef

Sept. 25, 2015

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

by stepharo

I would keep ## if in the future we need a new syntactic sugaring construct. Le 25/9/15 09:01, Nicolai Hess a Ã©crit : > > > 2015-09-24 22:39 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>>: > > Le 24/09/2015 09:11, Nicolai Hess a Ã©crit : > > > > 2015-09-24 8:19 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com > <mailto:i.uhnak@gmail.com> > <mailto:i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>>>: > > > - 250 * 1.5 returns -2.25 > > why is this valid syntax? > > > > I don't know if this is valid syntax (I always wondered that > there is > one place in PointTest, that is not compilable with old > compiler but > compiles > fine with opal). > But the error happens in > RBParser>>#parseNegatedNumber. > If a #- is recognized, it tests if a literalnumber follows > (but from the > token stream, that is, the spaces are ignored). > Now the real bug is, that we do two "steps" and concstruct a new > literalvaluenode from the now following tokens. > RBParser parseExpression:'- 2' -> throws an error, because no > following > tokens > RBParser parseExpression:'- 2 * 3' -> works but actually > duplicates the > two last tokens "*3 *3. > and some funny other things '- 2@1' -> '-1@1' > > > Another one I found in the tests: would you expect > > RBParser parseExpression: '# > > 1 = 1' > > To be the same thing as '#1 = 1' ? > > > > And another one: > #t = ##t "-> true" > > I thnk ##t should be allowed. > > > Thierry > >

Sept. 25, 2015

Re: [Pharo-dev] World.st has a new admin

by stepharo

thanks Sean this is great! Le 24/9/15 19:35, phil(a)highoctane.be a Ã©crit : > Sean, King of the World.st > > Thx for this!!!!! > > Phil > > On Thu, Sep 24, 2015 at 8:55 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > > I have always found the world.st <http://world.st> very very > useful. Thank you very much Geert. > And thanks Sean, you will do a great job as always. > > On Thu, Sep 24, 2015 at 3:09 PM, Sven Van Caekenberghe > <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > > > > On 24 Sep 2015, at 19:47, Stephan Eggermont > <stephan(a)stack.nl <mailto:stephan@stack.nl>> wrote: > > > > On 24/09/15 16:27, Geert Claes wrote: > >> The admin duties have now been handed over to Sean DeNigris > who kindly > >> volunteered to look after the www.world.st > <http://www.world.st> web presence as well as the > >> Nabble archived mailing list forums on forum.world.st > <http://forum.world.st>. > > > > Thank you Geert, for taking care of this important community > resource for us for so long, and Sean for stepping in and > taking over. > > +10 > > > Stephan > > > > > > -- > Mariano > http://marianopeck.wordpress.com > >

Sept. 25, 2015

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

by Thierry Goubier

2015-09-25 13:01 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > > On 25 Sep 2015, at 09:53, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > > > > Note for ref on the original point: > > > > ANSI Smalltalk allow for space between - and the number token. Squeak is > then non A > > > > For the new point: > > > > ANSI Smalltalk does not allow for space between # and the selector, or > between # and the quoted string. > > > > Should be an easy fix. > > > > Marcus, how do we should validate RBParser changes? Reparse all the code > in the image and compares ASTs? > > > Yes, I think soâ¦ it would of course be better to have a larger scale > regression test suite, but for now ârecompiling the imageâ > is the thing we do to check the compiler > Ok. My issue was a kind of versionning effect on the parser, and a process like: - recover and store all asts for all methods - apply a change to RBParser - reparse all methods one by one and compare ASTs with previous We have good GUI tools for manipulating packages, but sometimes I'd like to have a branch concept inside the image which says: - revert to master, - do something, - switch to branch (and load your changes), - continue something to validate Thierry > > Marcus > > >

Sept. 25, 2015