- Pharo-dev - lists.pharo.org

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

by Thierry Goubier

Le 25/09/2015 19:35, stepharo a Ã©crit : > I would keep ## if in the future we need a new syntactic sugaring construct. Why keep it if it is easy to add once you know you need it? For now, this code allows things like: RBParser parseExpression: '#####################################t' Note on all those funny symbol syntaxes: formatting will get rid of them. Another fun syntax example: RBParser parseExpression: '#" I am a quite long comment" t' Thierry > 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 >> <<mailto:i.uhnak@gmail.com>i.uhnak(a)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. 27, 2015

Re: [Pharo-dev] chunk file format (unrecoverable changes)

by stepharo

Hi Eliot Thanks for the discussion. I will archive it and reread it. Now I think that historically they missed several points I learned while working on the Moose file format: - having doit or expressions to be executed instead of a declaration puts the burden on the tools. - for example not having a class definition declaration and just a do it forces the tools to parse and guess. - relying on sequence is not good because if you file is cut then this impacts several entities instead of having just one impacted. - I do not get why each entity in the chunk format is not self contained because in any case no decent programmer would use it to write code. - Mixing annotation and essential information makes the format really verbose. - what we see is that if we want to exchange on mail about code in several method in different classes, the chunk format is a pain vs. Point >> signature [ code here ] - This is not by accident that in all the books we wrote we use Clas >> signature code This way is not good because we do not have the warranty that code is not cut. Hence the previous one is better. I will restart one of these days to work on an alternate file format for textual editor. I do not like the GNUSt syntax. Now indeed how to store metadata is a good question. Stef

Sept. 27, 2015

Re: [Pharo-dev] when:send:to: vs. subscribe:send:to:

by stepharo

Le 9/9/15 11:21, Nicolas Cellier a Ã©crit : > Note that when:send:to: already existed in VW before announcements (it > did work with a symbol like when: #someAspectChanged send: #someAction > to: self, and this was tiggered thru dependents mechanism - self > changed: #someAspectChanged...). yes > IMO, it is very expressive, whatever the underlying mechanism > (dependents or Announcement). + 1 > > 2015-09-09 8:49 GMT+02:00 Norbert Hartl <norbert(a)hartl.name > <mailto:norbert@hartl.name>>: > > > > > > > Am 08.09.2015 um 22:49 schrieb stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > > > > Me too :) > > I do not care that they is a registration mechanism behind. > > > But you get a subscription back. Und the user should be aware of > that there is no magical unsubscribe mechanism. So this no reason > for me but I still like when:send:to: better although it feels a > bit awkward. > > Norbert > > Stef > > > > Le 8/9/15 16:30, Ferlicot D. Cyril a Ã©crit : > >> Le 08/09/2015 10:13, Stephan Eggermont a Ã©crit : > >> > >>> When looking at the implementation, it looks as if we should > >>> replace all #when:send:to: by #subscribe:when:do:, not the > other way > >>> around. > >>> > >>> Where is this all coming from? > >>> > >>> Stephan > >> I think that #when:send:to: is more explicit and more > understandable, > >> but this is a personal opinion. > > > > > >

Sept. 27, 2015

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

by Thierry Goubier

Le 25/09/2015 13:01, Marcus Denker a Ã©crit : > >> 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 Reparsing the whole image shows 7 uses of # <space> something and #number. Thierry > Marcus > > >

Sept. 26, 2015

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

by stepharo

During the lecture I saw that {(10@20) . (30@40)} is printed as {(10@20). (30@40)} and I think that it would much nicer to have {(10@20) . (30@40)}

Sept. 26, 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 There is a competition AppTogo. People are learning C# and others. I hope that some students will compete with Pharo so I will be looking for potential mentors to help them. Giving them advices, pointing them to the right solution/framework and may be a bit of pair rogramming 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 love the Youtube videos folder I'm collecting. Yes internet is a pain there. Chloupis I put your great youtube tutorial! Thanks for it. some students watched it. Stef

Sept. 26, 2015

Some news from the growing pharo teacher front

by stepharo

Hi guys I want to let you 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. 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 build web app and other. There is a competition AppTogo. People are learning C# and others. I hope that some students will com

Sept. 26, 2015

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