- Pharo-dev - lists.pharo.org

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

[pharo-project/pharo-core] 21e3f6: 50339

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 21e3f65d612fc9ba47aff677682e9daed7b67b0d https://github.com/pharo-project/pharo-core/commit/21e3f65d612fc9ba47aff677… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-24 (Thu, 24 Sep 2015) Changed paths: A Refactoring-Critics.package/RBCompositeLintRule.class/class/default rules/pharoHardLintRules.st A Refactoring-Critics.package/RBCompositeLintRule.class/class/default rules/pharoSoftLintRules.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50338.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50339.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50338.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50339.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-CriticBrowser.package/SelectPackageBrowser.class/instance/private/removeAllItems.st M Tool-CriticBrowser.package/SelectPackageBrowser.class/instance/private/removeItems.st M Tool-CriticBrowser.package/SelectRuleBrowser.class/class/instance creation/openWithEnvironment_removeTestCase_.st A Tool-CriticBrowser.package/SelectRuleBrowser.class/class/instance creation/pharoIntegrationRules.st M Tool-CriticBrowser.package/SelectRuleBrowser.class/instance/accessing/items_.st M Tool-CriticBrowser.package/SelectRuleBrowser.class/instance/api/addItems.st M Tool-CriticBrowser.package/SelectRuleBrowser.class/instance/initialization/initialize.st Log Message: ----------- 50339 16620 Add a category "Pharo integration rules" to the critics browser https://pharo.fogbugz.com/f/cases/16620 http://files.pharo.org/image/50/50339.zip

Sept. 24, 2015

SHRBTextStyler and workspace/playground variables

by Andrei Chis

Hi, Currently SHRBTextStyler does not highlight variables in the playground. This could be added by extending SHRBTextStyler >>#resolveStyleFor: with workspace ifNotNil: [(workspace hasBindingOf: aVariableNode name) ifTrue: [^ #workspaceVar]]. Still this could cause some problems given how MorphicTextAdapter integrates Rubric. MorphicTextAdapter>>setEditingModeFor:withBehavior: can translate #beForCode from Spec to #beForSmalltalkScripting in Rubric. However for #beForSmalltalkScripting to work the model has to provide methods for managing bindings which MorphicTextAdapter does not. Maybe there is another way to highlight variables in the playground. Cheers, Andrei

Sept. 24, 2015

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

by Nicolas Cellier

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

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] [Reflectivity] Slides ESUG talk

by roberto.minelli＠usi.ch

Lovely Marcus, thank you. > On 24 Sep 2015, at 09:59, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 22 Sep 2015, at 17:23, roberto.minelli(a)usi.ch wrote: >> >> Hi Marcus, >> >> I am finally playing with Reflectivity. In the first place, thanks a lot for this contribution! >> >> I am wondering what is the âcorrectâ way to âremoveâ a MetaLink. Is it enough to call #uninstall on the MetaLink or should I also recompile the class/method where the link is installed? >> >> I spotted a problem with the control #after. If you try to pass #arguments to the meta, an error is returned. To reproduce: http://ws.stfx.eu/ONC4K9KQRTNQ >> >> Is this behavior somewhat desired, or is a bug? >> > Hello, I fixed it: > > https://pharo.fogbugz.com/f/cases/16629/fix-after-on-method-with-arguments > > You example is now working, I added it as this test: > > testReifyMethodArgsAfter > | methodNode link instance| > methodNode := (ReflectivityExamples>>#exampleWithArg:) ast. > link := MetaLink new > metaObject: self; > selector: #tagExec:; > control: #after; > arguments: #(arguments). > methodNode link: link. > self assert: methodNode hasMetalink. > self assert: (ReflectivityExamples>>#exampleWithArg:) class = ReflectiveMethod. > self assert: (tag isNil). > instance := ReflectivityExamples new . > self assert: ((instance exampleWithArg: 3) = 5). > self assert: (tag = #(3)). > link uninstall. > > > I will integrate this fix and then write more tests (e.g. I think there are still problems with an #after on a method that defines temps, > but it will be easy to fix). > > Marcus

Sept. 24, 2015

Re: [Pharo-dev] [Reflectivity] Slides ESUG talk

by Marcus Denker

> On 22 Sep 2015, at 17:23, roberto.minelli(a)usi.ch wrote: > > Hi Marcus, > > I am finally playing with Reflectivity. In the first place, thanks a lot for this contribution! > > I am wondering what is the âcorrectâ way to âremoveâ a MetaLink. Is it enough to call #uninstall on the MetaLink or should I also recompile the class/method where the link is installed? > > I spotted a problem with the control #after. If you try to pass #arguments to the meta, an error is returned. To reproduce: http://ws.stfx.eu/ONC4K9KQRTNQ > > Is this behavior somewhat desired, or is a bug? > Hello, I fixed it: https://pharo.fogbugz.com/f/cases/16629/fix-after-on-method-with-arguments <https://pharo.fogbugz.com/f/cases/16629/fix-after-on-method-with-arguments> You example is now working, I added it as this test: testReifyMethodArgsAfter | methodNode link instance| methodNode := (ReflectivityExamples>>#exampleWithArg:) ast. link := MetaLink new metaObject: self; selector: #tagExec:; control: #after; arguments: #(arguments). methodNode link: link. self assert: methodNode hasMetalink. self assert: (ReflectivityExamples>>#exampleWithArg:) class = ReflectiveMethod. self assert: (tag isNil). instance := ReflectivityExamples new . self assert: ((instance exampleWithArg: 3) = 5). self assert: (tag = #(3)). link uninstall. I will integrate this fix and then write more tests (e.g. I think there are still problems with an #after on a method that defines temps, but it will be easy to fix). Marcus

Sept. 24, 2015

Re: [Pharo-dev] Ctrl-b-m Ctrl-b-n and Ctrl-b-N should work in all code panes

by Peter UhnÃ¡k

I think the problem is that the code pane doesn't react to nautilus shortcuts http://forum.world.st/Nautilus-shortcuts-from-code-pane-td4839037.html On Thu, Sep 24, 2015 at 9:22 AM, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > I can understand that nautilus has its own shortcuts. > Now it would be good that have > Ctrl-b-m Ctrl-b-n and Ctrl-b-N should work in all code panes in addition > to Ctrl-m and Ctrl-n > > So that it is the same for students. > > Stef > >

Sept. 24, 2015