- Pharo-dev - lists.pharo.org

[Issue Tracker] Help needed: 623 open issues

by Marcus Denker

Hello, We have 623 open issues on the issue tracker. We need more man power to get the number down. *ESPCECIALLY* please look at issues that you submitted or where you have been part of the discussion in the past. https://pharo.fogbugz.com/f/filters/57/All-newest-first <https://pharo.fogbugz.com/f/filters/57/All-newest-first> Every single issue closed is a step forward. We can only fix 623 issues if we start fixing one. Marcus

Aug. 31, 2015

[issue tracker] many issues marked "fixed upstream"

by Marcus Denker

Hi, We have again many issues that are in the state âfixed upstreamâ. it would be nice if maintainers of packages could make sure that changes get reviewed+integrated and the package updates in Pharo so we can close them. There is nothing gained by postponing this sync back. Marcus

Aug. 31, 2015

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

by Marcus Denker

> On 31 Aug 2015, at 10:18, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > On Mon, Aug 31, 2015 at 8:41 AM, stepharo <stepharo(a)free.fr <mailto:stepharo@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 > good idea, this way the rule is reusable for a code critique rule (for those cases where it makes sense, e.g. for ifNotNil: yes, as it is likely unique, but for #at: on SmalltalkImage, no ;-) Marcus

Aug. 31, 2015

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