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

NBMacShell

by Noury Bouraqadi

Hi, I came accross NBMacShell that looks like an alternative to OSProcess. However, I see no Window/Linux equivalent? Am I mistaken? Noury

Aug. 31, 2015

Re: [Pharo-dev] [Experiment] Automatic rewriting of sends to deprecated methods

by Peter UhnÃ¡k

On Mon, Aug 31, 2015 at 8:41 AM, stepharo <stepharo(a)free.fr> wrote: > But the tool of mark is a ui tool so why would you want to get a tool to > define a rule in your case? > You can use the UI to create the rule, but the application of the rule can be scripted. > Yes, it would be nice to have a tool for creating the rules. But then, one > can use Markâs tool as is > for this already now for creating the rewrite rule and then copy-and-paste > it. > An integration could make that even easier, but for me this is good enough > for now. RewriteTool creates classes with the rules, so I don't see the need for copy-pasting. Why not just self deprecated: anExplanationString rule: aRuleClassGeneratedByRewriteTool self

Aug. 31, 2015

Re: [Pharo-dev] [Experiment] Automatic rewriting of sends to deprecated methods

by Marcus Denker

> On 31 Aug 2015, at 08:52, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> >> The only problem is that it does a whole-method refactoring while it should only affect the node >> that triggered the deprecation. Else there could be wrong transformations if the same selector >> is used but only one of the implementations need to be rewritten, while if we are able to rewrite >> the exact sender, we can do it fully automatically. >> > > I think using #sourceNodeExecuted we could do it like this: > even simpler: deprecated: anExplanationString rule: aRule | rewriteRule method context node | context := thisContext sender sender. method := context method. node := context sourceNodeExecuted. rewriteRule := RBParseTreeRewriter new replace: aRule key with: aRule value. (rewriteRule executeTree: node) ifFalse: [ ^self ]. node replaceWith: rewriteRule tree. method methodClass compile: method ast formattedCode classified: method protocol. It seems to work but I have not tested it too much. Marcus

Aug. 31, 2015

Re: [Pharo-dev] [Pharo5] new feature: #sourceNodeExecuted on Context

by Marcus Denker

> On 31 Aug 2015, at 09:00, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Does it also work with Block contexts and optimized ones? > > Yes, I think so. But we should add tests. It uses the same mechanism that manages highlighting in the debugger. > Le 31 aoÃ»t 2015 08:45, "stepharo" <stepharo(a)free.fr <mailto:stepharo@free.fr>> a Ã©crit : > Nice :) > I hope you put this example as comment. > > > Le 31/8/15 08:37, Marcus Denker a Ã©crit : >> Hi, >> >> I added a method that returns the sub-tree of the AST that was executed by this context. >> (e.g. the message send node of the message that was send that is the reason why we >> are now executing thisContext). >> >> e.g. >> >> testSourceNodeExecuted >> | sourceNode | >> >> sourceNode := thisContext sender sender sourceNodeExecuted. >> self assert: sourceNode selector = #performTest. >> >> AST caching guarantees that this is a true subtree of the methodâs AST. >> >> Marcus >> >

Aug. 31, 2015

Re: [Pharo-dev] [Experiment] Automatic rewriting of sends to deprecated methods

by stepharo

Yes to create rules. I thought that when the rule was executed and I was confused. Le 31/8/15 08:46, Marcus Denker a Ã©crit : >> On 31 Aug 2015, at 08:41, stepharo <stepharo(a)free.fr> wrote: >> >> But the tool of mark is a ui tool so why would you want to get a tool to define a rule in your case? >> > Yes, it would be nice to have a tool for creating the rules. But then, one can use Markâs tool as is > for this already now for creating the rewrite rule and then copy-and-paste it. > An integration could make that even easier, but for me this is good enough for now. > >> In the future if mark and camille come up with a better rewrite engine then of course we will use it. >> > Yes. > > Marcus > > >

Aug. 31, 2015

Re: [Pharo-dev] [Pharo5] new feature: #sourceNodeExecuted on Context

by Guillermo Polito

Does it also work with Block contexts and optimized ones? Le 31 aoÃ»t 2015 08:45, "stepharo" <stepharo(a)free.fr> a Ã©crit : > Nice :) > I hope you put this example as comment. > > > Le 31/8/15 08:37, Marcus Denker a Ã©crit : > > Hi, > > I added a method that returns the sub-tree of the AST that was executed by > this context. > (e.g. the message send node of the message that was send that is the > reason why we > are now executing thisContext). > > e.g. > > testSourceNodeExecuted > | sourceNode | > > sourceNode := thisContext sender sender sourceNodeExecuted. > self assert: sourceNode selector = #performTest. > > AST caching guarantees that this is a true subtree of the methodâs AST. > > Marcus > > >

Aug. 31, 2015

[pharo-project/pharo-core]

by GitHub

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

Aug. 31, 2015

[pharo-project/pharo-core] 2e15c1: 50290

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 2e15c1662791017cdad4be9996bd915896242c89 https://github.com/pharo-project/pharo-core/commit/2e15c1662791017cdad4be99… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-08-31 (Mon, 31 Aug 2015) Changed paths: M ConfigurationOfOSWindow.package/ConfigurationOfOSWindow.class/instance/symbolic versions/stable_.st M ConfigurationOfOSWindow.package/ConfigurationOfOSWindow.class/instance/versions/version125_.st A ConfigurationOfOSWindow.package/ConfigurationOfOSWindow.class/instance/versions/version126_.st A KernelTests.package/MethodContextTest.class/instance/tests - ast mapping/testSourceNodeExecuted.st A OpalCompiler-Core.package/extension/Context/instance/previousPcWithCorrectMapping.st A OpalCompiler-Core.package/extension/Context/instance/sourceNodeExecuted.st M Refactoring-Critics.package/RBUnpackagedCodeRule.class/instance/running/checkMethod_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50289.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50290.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50289.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50290.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50290 16435 add Context>>#sourceNodeExecuted https://pharo.fogbugz.com/f/cases/16435 16434 can not inspect block methods (RBUnpackagedRule) https://pharo.fogbugz.com/f/cases/16434 16426 new OSWindow integration to clean up wrong merge https://pharo.fogbugz.com/f/cases/16426 http://files.pharo.org/image/50/50290.zip

Aug. 31, 2015

Re: [Pharo-dev] [Experiment] Automatic rewriting of sends to deprecated methods

by Marcus Denker

> > The only problem is that it does a whole-method refactoring while it should only affect the node > that triggered the deprecation. Else there could be wrong transformations if the same selector > is used but only one of the implementations need to be rewritten, while if we are able to rewrite > the exact sender, we can do it fully automatically. > I think using #sourceNodeExecuted we could do it like this: deprecated: anExplanationString rule: aRule | builder rewriteRule method context node | builder := RBCompositeRefactoryChange named: 'deprecation'. method := thisContext sender sender method. context := thisContext sender sender. node := context sourceNodeExecuted. rewriteRule := RBParseTreeRewriter new replace: aRule key with: aRule value. (rewriteRule executeTree: node copy) ifTrue: [ node replaceWith: rewriteRule tree. builder compile: method ast formattedCode in: method methodClass classified: method protocol ]. builder execute. And a question is if we need #formattedCodeâ¦ all refactoring normally try to update white-space information. Need to check. Marcus

Aug. 31, 2015

Re: [Pharo-dev] [Experiment] Automatic rewriting of sends to deprecated methods

by Marcus Denker

> On 31 Aug 2015, at 08:41, stepharo <stepharo(a)free.fr> wrote: > > But the tool of mark is a ui tool so why would you want to get a tool to define a rule in your case? > Yes, it would be nice to have a tool for creating the rules. But then, one can use Markâs tool as is for this already now for creating the rewrite rule and then copy-and-paste it. An integration could make that even easier, but for me this is good enough for now. > In the future if mark and camille come up with a better rewrite engine then of course we will use it. > Yes. Marcus

Aug. 31, 2015