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&ty...

...

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

...

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

...

...

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

On Wednesday, 31 August 2011, Stéphane Ducasse <stephane.ducasse@inria.fr> 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