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

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

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

by Nicolai Hess

2015-08-30 21:38 GMT+02:00 Torsten Bergmann <astares(a)gmx.de>: > Which Pharo 4 image was used to create Build initial Pharo 5 image > (build 5000)? According to the mailinglist archive from April [1] > it seems to be build 40608. > > I wonder since in build 50000 the desktop manager works and in the > Pharo 4 image 40608 it is not working. Was there anything applied > special during the release process? > What does not work in 40608? > > Thanks > T. > > [1] > http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-April/date.… > >

Aug. 30, 2015

Image used for 4.0 -> 5.0 (Build 50000) transition

by Torsten Bergmann

Which Pharo 4 image was used to create Build initial Pharo 5 image (build 5000)? According to the mailinglist archive from April [1] it seems to be build 40608. I wonder since in build 50000 the desktop manager works and in the Pharo 4 image 40608 it is not working. Was there anything applied special during the release process? Thanks T. [1] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2015-April/date.…

Aug. 30, 2015

what is the protocol between a data source and a FTlist?

by stepharo

Hi esteban I'm wondering how the list is updated when the data source change. What is the protocol. I was looking at the examples but I could not see it. Stef

Aug. 30, 2015