RB API

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

RB API

Sean P. DeNigris
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
Reply | Threaded
Open this post in threaded view
|

Re: RB API

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|

Re: RB API

Lukas Renggli
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

Reply | Threaded
Open this post in threaded view
|

Re: RB API

Stéphane Ducasse
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
>


Reply | Threaded
Open this post in threaded view
|

Re: RB API

Sean P. DeNigris
Administrator
In reply to this post by Lukas Renggli
Lukas Renggli wrote
Note that the classes contain actually excellent documentation.
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.

Lukas Renggli wrote
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 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
Reply | Threaded
Open this post in threaded view
|

RB API

Lukas Renggli
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: RB API

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|

Re: RB API

Lukas Renggli
>>> 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

Reply | Threaded
Open this post in threaded view
|

Re: RB API

Stéphane Ducasse
>>
>
> 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
>


Reply | Threaded
Open this post in threaded view
|

RB API

Lukas Renggli
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
Reply | Threaded
Open this post in threaded view
|

Re: RB API

Stéphane Ducasse
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: RB API

Sean P. DeNigris
Administrator
In reply to this post by Sean P. DeNigris
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
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: RB API

Stéphane Ducasse
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.
>