- Pharo-dev - lists.pharo.org

[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

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

by stepharo

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] Image used for 4.0 -> 5.0 (Build 50000) transition

by stepharo

yes may be a cleanup. Le 31/8/15 01:00, Nicolai Hess a Ã©crit : > Oh, thats funny. > > Maybe this comes from the release buidling process, (condense changes > / sources) anything that > resets some world state? > > 2015-08-30 22:29 GMT+02:00 Torsten Bergmann <astares(a)gmx.de > <mailto:astares@gmx.de>>: > > Nicolai Hess wrote: > >What does not work in 40608? > > What Julien describes in [1] when he uses Pharo 4 with > DesktopManager. I use Pharo 5 > and did not have this effect. > > To reproduce I used latest.zip from > http://files.pharo.org/vm/pharo/win/ > one time with #40608 and one time with #50000 > > Gofer new > smalltalkhubUser: 'TorstenBergmann' project: 'DesktopManager'; > configuration; > loadDevelopment. > > 1. Hit CTRL + D and then CTRL + A (which is "D"esktop "A"dd) > 2. Hit CTRL + D and then CTRL + P (which is "D"esktop "P"revious). > > Now the windows on the first desktop are not usable anymore in > 40608. They do > not repaint. > > In Pharo #50000 or any newer Pharo 5 image this works without a > problem. > > Bye > T. > > [1] > http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2015-August/02… > >

Aug. 31, 2015

[Pharo5] New Feature: persistent properties on temporary variables

by Marcus Denker

Hi, Since last week, TemporaryVariable meta-objects are made persistent if you put a property on them. (they are saved in the methodâs properties). This means we can annotate temps without having to keep the AST around. When not used all the machinery behind has no cost in terms of memory. testPropertyAtPutPersistent | testValue temp temp2 | testValue := Date today. temp := thisContext method temporaryVariableNamed: #temp. temp propertyAt: #testKeySelector put: testValue. self assert: (temp propertyAt: #testKeySelector) equals: testValue. temp2 := thisContext method temporaryVariableNamed: #temp. self assert: (temp2 propertyAt: #testKeySelector) equals: testValue. self assert: temp2 == temp. self deny: thisContext method savedTemps isNil. temp removeProperty: #testKeySelector. self assert: temp properties isNil. self assert: thisContext method savedTemps isNil.

Aug. 31, 2015

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

by stepharo

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? In the future if mark and camille come up with a better rewrite engine then of course we will use it. Le 30/8/15 18:31, Marcus Denker a Ã©crit : > No, just plain old ParseTreeRewriter.. but integrating Markâs tool > would be very nice as a next step. > > >> On 30 Aug 2015, at 14:34, Peter UhnÃ¡k <i.uhnak(a)gmail.com >> <mailto:i.uhnak@gmail.com>> wrote: >> >> Is this based on Mark's Rewrite Tool? >> >> On Sun, Aug 30, 2015 at 10:27 AM, Marcus Denker >> <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> Hi, >> >> Small experiment: >> >> 1) add this method to Object: >> >> deprecated: anExplanationString rule: aRule >> | builder ast rewriteRule method | >> builder := RBCompositeRefactoryChange named: 'deprecation'. >> method := thisContext sender sender method. >> ast := method ast copy. >> rewriteRule := RBParseTreeRewriter new replace: aRule key >> with: aRule value. >> >> (rewriteRule executeTree: ast) ifTrue: [ >> builder compile: rewriteRule tree formattedCode in: >> method methodClass classified: method protocol ]. >> builder execute. >> >> 2) to see it in action, add it to #ifNotNilDo: in UndefinedObject: >> >> ifNotNilDo: aBlock >> "Please use #ifNotNil: instead" >> self >> deprecated: 'Please use #ifNotNil: instead' >> rule: '`@receiver ifNotNilDo: `@statements'-> >> '`@receiver ifNotNil: `@statements'. >> ^ self >> >> >> â> open a browser and see how it fixes code magically. >> >> 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. >> >> Marcus >> >> >

Aug. 31, 2015

[Pharo5] new feature: #sourceNodeExecuted on Context

by Marcus Denker

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] Image used for 4.0 -> 5.0 (Build 50000) transition

by Nicolai Hess

Oh, thats funny. Maybe this comes from the release buidling process, (condense changes / sources) anything that resets some world state? 2015-08-30 22:29 GMT+02:00 Torsten Bergmann <astares(a)gmx.de>: > Nicolai Hess wrote: > >What does not work in 40608? > > What Julien describes in [1] when he uses Pharo 4 with DesktopManager. I > use Pharo 5 > and did not have this effect. > > To reproduce I used latest.zip from http://files.pharo.org/vm/pharo/win/ > one time with #40608 and one time with #50000 > > Gofer new > smalltalkhubUser: 'TorstenBergmann' project: 'DesktopManager'; > configuration; > loadDevelopment. > > 1. Hit CTRL + D and then CTRL + A (which is "D"esktop "A"dd) > 2. Hit CTRL + D and then CTRL + P (which is "D"esktop "P"revious). > > Now the windows on the first desktop are not usable anymore in 40608. They > do > not repaint. > > In Pharo #50000 or any newer Pharo 5 image this works without a problem. > > Bye > T. > > [1] > http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2015-August/02… > >

Aug. 30, 2015

Re: [Pharo-dev] Image used for 4.0 -> 5.0 (Build 50000) transition

by Torsten Bergmann

Nicolai Hess wrote: >What does not work in 40608? What Julien describes in [1] when he uses Pharo 4 with DesktopManager. I use Pharo 5 and did not have this effect. Â To reproduce I used latest.zip fromÂ http://files.pharo.org/vm/pharo/win/ Â one time with #40608 and one time with #50000 Â Gofer new Â Â smalltalkhubUser: 'TorstenBergmann' project: 'DesktopManager'; Â Â configuration; Â Â loadDevelopment. 1. Hit CTRL + D and then CTRL + A Â Â (which is "D"esktop "A"dd) 2. Hit CTRL + D and then CTRL + P Â Â (which is "D"esktop "P"revious). Â Now the windows on the first desktop are not usable anymore in 40608. They do not repaint. Â In Pharo #50000 or any newer Pharo 5 image this works without a problem. Bye T.Â Â [1]Â http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2015-August/02… Â

Aug. 30, 2015