Administrator
|
Is there any documentation on using AST & RB?
I didn't find anything enlightening via google, the tests, or the class/method comments. In trying to replace all calls to #deprecate: and #deprecate:in: to #deprecate:on:in: (Issue 4718), it took me hours to step through OB's refactoring and learn the syntax. In case anyone else can benefit, I eventually ended up with: RBParseTreeRewriter new replace: '``@object deprecated: ``@arg1 ' with: '``@object deprecated: ``@arg1 on:(''', dateString, ''') in:(''Pharo', versionNumber asString, ''')'. Sean
Cheers,
Sean |
isn't it should be
deprecare[d] ... instead of deprecate... (i.e. names should be with 'd' at the end) ? On 31 August 2011 15:48, Sean P. DeNigris <[hidden email]> wrote: > Is there any documentation on using AST & RB? > > I didn't find anything enlightening via google, the tests, or the > class/method comments. In trying to replace all calls to #deprecate: and > #deprecate:in: to #deprecate:on:in: (Issue 4718), it took me hours to step > through OB's refactoring and learn the syntax. > > In case anyone else can benefit, I eventually ended up with: > RBParseTreeRewriter new > replace: '``@object deprecated: ``@arg1 ' > with: '``@object deprecated: ``@arg1 on:(''', dateString, ''') > in:(''Pharo', versionNumber asString, ''')'. > > Sean > > -- > View this message in context: http://forum.world.st/RB-API-tp3781019p3781019.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Sean P. DeNigris
> Is there any documentation on using AST & RB?
http://www.refactory.com/RefactoringBrowser/index.html http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.9246&rep=rep1&type=pdf > I didn't find anything enlightening via google, the tests, or the > class/method comments. Note that the classes contain actually excellent documentation. > In trying to replace all calls to #deprecate: and > #deprecate:in: to #deprecate:on:in: (Issue 4718), it took me hours to step > through OB's refactoring and learn the syntax. > > In case anyone else can benefit, I eventually ended up with: > RBParseTreeRewriter new > replace: '``@object deprecated: ``@arg1 ' > with: '``@object deprecated: ``@arg1 on:(''', dateString, ''') > in:(''Pharo', versionNumber asString, ''')'. Actually you can do it with a few clicks: Select #deprecated:, click on "Refactor method > Add parameter" and follow the instructions. The rewrite engine takes a while to master. It is the infrastructure that runs most of the refactorings and it is typically not necessary for basic refactorings like this one. Lukas -- Lukas Renggli www.lukas-renggli.ch |
I would love to have a real and nice documentation/tutorial because this is a great tool.
Stef On Aug 31, 2011, at 4:17 PM, Lukas Renggli wrote: >> Is there any documentation on using AST & RB? > > http://www.refactory.com/RefactoringBrowser/index.html > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.9246&rep=rep1&type=pdf > >> I didn't find anything enlightening via google, the tests, or the >> class/method comments. > > Note that the classes contain actually excellent documentation. > >> In trying to replace all calls to #deprecate: and >> #deprecate:in: to #deprecate:on:in: (Issue 4718), it took me hours to step >> through OB's refactoring and learn the syntax. >> >> In case anyone else can benefit, I eventually ended up with: >> RBParseTreeRewriter new >> replace: '``@object deprecated: ``@arg1 ' >> with: '``@object deprecated: ``@arg1 on:(''', dateString, ''') >> in:(''Pharo', versionNumber asString, ''')'. > > Actually you can do it with a few clicks: Select #deprecated:, click > on "Refactor method > Add parameter" and follow the instructions. > > The rewrite engine takes a while to master. It is the infrastructure > that runs most of the refactorings and it is typically not necessary > for basic refactorings like this one. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > |
Administrator
|
In reply to this post by Lukas Renggli
Do you have any particular one in mind? I traced OB's execution to RBStringReplaceRule and then looked up the hierarchy finding basic few-sentence descriptions, but nothing in-depth about how to search and replace. Notice I asked about the API, not about the OB GUI. I needed to programmatically change each one depending on the sender's timeStamp and the collections of what was deprecated in which version. Also, there are already methods in the system with the name I'm changing to, so OB just mentions that and fails. Let me ask maybe a better question - how would you do the following programmatically? For each method that sends #deprecated: (except for certain excluded ones) change the send to #deprecated:on:in: where the second argument is the calling method's timeStamp and the third is 'Pharo1.3' or 'Pharo1.4' depending on which pre-made list it appears on. Cheers, Sean
Cheers,
Sean |
>> Note that the classes contain actually excellent documentation.
>> > Do you have any particular one in mind? You asked about the AST nodes. > I traced OB's execution to > RBStringReplaceRule and then looked up the hierarchy finding basic > few-sentence descriptions, but nothing in-depth about how to search and > replace. That's a private internal class, you are not supposed to instantiate it. You find documentation about the rewrite engine in the first link I sent you. >> Actually you can do it with a few clicks: Select #deprecated:, click >> on "Refactor method > Add parameter" and follow the instructions. >> > Notice I asked about the API, not about the OB GUI. I couldn't guess that. > I needed to > programmatically change each one depending on the sender's timeStamp and the > collections of what was deprecated in which version. Also, there are already > methods in the system with the name I'm changing to, so OB just mentions > that and fails. A few more clicks and you have a refactoring scope on any method set you want. > Let me ask maybe a better question - how would you do the following > programmatically? I would crete a rewriter for each case, instantiate a RBNamespace, iterate over all methods within, and apply the rewriters if necessary, then review the changeset, and apply it. Cheers, Lukas -- Lukas Renggli www.lukas-renggli.ch |
On 31 August 2011 18:34, Lukas Renggli <[hidden email]> wrote:
>>> Note that the classes contain actually excellent documentation. >>> >> Do you have any particular one in mind? > > You asked about the AST nodes. > >> I traced OB's execution to >> RBStringReplaceRule and then looked up the hierarchy finding basic >> few-sentence descriptions, but nothing in-depth about how to search and >> replace. > > That's a private internal class, you are not supposed to instantiate it. You > find documentation about the rewrite engine in the first link I sent you. > >>> Actually you can do it with a few clicks: Select #deprecated:, click >>> on "Refactor method > Add parameter" and follow the instructions. >>> >> Notice I asked about the API, not about the OB GUI. > > I couldn't guess that. > >> I needed to >> programmatically change each one depending on the sender's timeStamp and >> the >> collections of what was deprecated in which version. Also, there are >> already >> methods in the system with the name I'm changing to, so OB just mentions >> that and fails. > > A few more clicks and you have a refactoring scope on any method set you > want. > >> Let me ask maybe a better question - how would you do the following >> programmatically? > > I would crete a rewriter for each case, instantiate a RBNamespace, iterate > over all methods within, and apply the rewriters if necessary, then review > the changeset, and apply it. > This is one of the best things which i seen in OB. But even by watching your screencasts i found it hard to use. I remember i tried to rewrite some code using it but then i failed and lost in space (too much windows open, no clear visibility in what context they might work and why it fails for me, but works for you etc etc), so i abandoned attempts to master refactoring-fu using OB. And of course, since most of the times i hunting bugs in core image(s) of past , OB was not there and these features was not available to me, as developer (that's again, another reason to have single image for everyone). I would really like to have it in our _default_ images to empower developers. And with nice documentation (HelpSystem maybe?) because you know, for you , as an author (and/or maintainer) of it things look pretty straightforward, but for people who only get started they apparently not. > Cheers, > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Best regards, Igor Stasenko AKA sig. |
>>> Let me ask maybe a better question - how would you do the following
>>> programmatically? >> >> I would crete a rewriter for each case, instantiate a RBNamespace, iterate >> over all methods within, and apply the rewriters if necessary, then review >> the changeset, and apply it. > > This is one of the best things which i seen in OB. But even by > watching your screencasts i found it hard to use. > I remember i tried to rewrite some code using it but then i failed and > lost in space (too much windows open, no clear visibility in what > context they might work and > why it fails for me, but works for you etc etc), so i abandoned > attempts to master refactoring-fu using OB. It is complicated to expose the complete refactoring engine API through an UI and in many cases it is not even easily usable, in fact the original Refactoring Browser only supported a much smaller sub-set. Now what I think is quite simple is: (1) open a scoped browser, (2) trigger a refactoring, and (3) edit the proposed change-list. That fact that the change-list is editable might not be obvious, but in fact any proposed change can be removed (ctrl+x) and outside diff mode you can even edit proposed change. Furthermore there is full multi-level undo-redo support in OB with the refactoring engine loaded, *any* refactoring (as well as any class/method deletion/redefinition/addition in OB) can be undone. > And of course, since most of the times i hunting bugs in core image(s) > of past , OB was not there and these features was not available to me, > as developer > (that's again, another reason to have single image for everyone). It is really easy to load refactoring engine into a core image, perform the refactoring, commit the changes, and load the refactored code into a core image again. This is especially true if Hudson always provides up-to-date images. > I would really like to have it in our _default_ images to empower > developers. I think it is a very bad idea to integrate the refactoring engine into the system, but I guess we don't have to discuss that again. > because you know, for you , as an author (and/or maintainer) of it > things look pretty straightforward, but for people who only get > started they apparently not. No, the refactoring engine is not an easy piece of software. It took me many years to fully understand it before I could start to fix and improve it. Lukas -- Lukas Renggli www.lukas-renggli.ch |
>>
> > I think it is a very bad idea to integrate the refactoring engine into > the system, but I guess we don't have to discuss that again. This is simple. If nobody maintains the Configuration then it means that this is impossible to load it automatically We do not want a script we want a metacello spec for obvious reason. And it means that we are always confused and we do not know what is the latest version and on which repository it is. Then we do not want it to take 20 min to load because in that case it means that we will never be able to load it to integrate and work on core. Because when we work on core and integrate and fix things we generate images sometimes every 5 minutes so a jenkins server does not help at all. We want powerful tools to work on core so the only solution is to load it in core for now. The situation could be better if everybody would help but this is not the case so we will live with that and see if fuel can help us speeding up all the process. But right now we should close other efforts. Stef >> because you know, for you , as an author (and/or maintainer) of it >> things look pretty straightforward, but for people who only get >> started they apparently not. > > No, the refactoring engine is not an easy piece of software. It took > me many years to fully understand it before I could start to fix and > improve it. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > |
On Wednesday, 31 August 2011, Stéphane Ducasse <[hidden email]> wrote:
>> I think it is a very bad idea to integrate the refactoring engine into >> the system, but I guess we don't have to discuss that again. > > This is simple. If nobody maintains the Configuration then it means that this is impossible to load it automatically > We do not want a script we want a metacello spec for obvious reason. > And it means that we are always confused and we do not know what is the latest version and on which repository it > is. I never said Metacello configs are evil. A configuration management is definitely needed. It is just too complex for me, given that I don't gain anything myself. > Then we do not want it to take 20 min to load because in that case it means that we will never be able > to load it to integrate and work on core. Because when we work on core and integrate and fix things we generate images sometimes > every 5 minutes so a jenkins server does not help at all. On my dead slow single-core server from the year 2000 it takes 5 minutes to load RB, OB and run all test and lint rules (if no other builds run at the same time). I assume that it is possible to load the necessary packages on a modern machine in under 1 min right after each commit. Also note that with builder.sh one can do incremental builds, that is to update the image from the previous build. I am not currently using this trick anywhere, but it makes builds even on my slow machines almost instantanious. Lukas -- Lukas Renggli www.lukas-renggli.ch |
>
> On my dead slow single-core server from the year 2000 it takes 5 minutes to load RB, OB and run all test and lint rules (if no other builds run at the same time). I assume that it is possible to load the necessary packages on a modern machine in under 1 min right after each commit. > > Also note that with builder.sh one can do incremental builds, that is to update the image from the previous build. I am not currently using this trick anywhere, but it makes builds even on my slow machines almost instantanious. We will see but right now we do have the resources to think and build more infrastructure. Stef |
Administrator
|
In reply to this post by Sean P. DeNigris
I added this example to the online book until we have some better ones http://book.pharo-project.org/book/PharoTools/Refactoring-Browser/ProgrammaticallyRefactorMethodExample
Cheers,
Sean |
Great!
We were starting to write a chapter on that but the person changed job. Stef On Nov 26, 2011, at 3:36 PM, Sean P. DeNigris wrote: > > Sean P. DeNigris wrote >> >> In case anyone else can benefit, I eventually ended up with: >> RBParseTreeRewriter new >> replace: '``@object deprecated: ``@arg1 ' >> with: '``@object deprecated: ``@arg1 on:(''', dateString, ''') >> in:(''Pharo', versionNumber asString, ''')'. >> > > I added this example to the online book until we have some better ones > http://book.pharo-project.org/book/PharoTools/Refactoring-Browser/ProgrammaticallyRefactorMethodExample > > -- > View this message in context: http://forum.world.st/RB-API-tp3781019p4110478.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > |
Free forum by Nabble | Edit this page |