Help with RBTransformationRule needed!

Hi everyone,

I need someone who knows how RBParseTreeRewriter & co. work. May of quality rules are implemented as rewrite rules which is cool. But they don’t report the interval in source code which can be highlighted to help with understanding of the issue.

Now… the check happens in RBTransformationRule>>#checkMethod:. Is it possible to obtain the matched string there? Because in that case we can get highlighting working which will be very useful.

Cheers!
Uko

Le 22/09/2015 17:56, Yuriy Tymchuk a écrit :
Hi Uko,

it seems all the information is in the context of the
RBParseTreeRewriter instance, but I'm not finding how to get the
top-level node (the root of the tree which will be replaced), knowing
that you may have multiple matches in a method (i.e. that there is
multiple nodes).

Thierry

Yeah, I remember this is a pain. When I did years ago what
you're doing now with QA, I ended up practicing black magic,
sacrificing chickens and other things you'd better not to know.

IIRC, the trick is to turn rewrite rules in ParseTreeEnvironment
into search rules and then run the searches. Now this is tricky
as these rules quite often refers to blocks, which then refers to outer
contexts and you need these blocks do something different now (report
nodes rather then transform stuff). This is the main problem.

If you have the guts, you may find the code here:

https://bitbucket.org/janvrany/stx-goodies-smallsense
and here:
http://swing.fit.cvut.cz/hg/stx.goodies.refactoryBrowser/

(alternatively, downlaod https://swing.fit.cvut.cz/projects/stx-jv/
 and browse the code in Smalltalk browser).

You may want to trace the code starting from
ParseTreeEnvironment>>selectionIntervalsForSource:tree:do:
RBParseTreeRule>>copyMatchDo: and implementors is also
worth mentioning.

After doing this, I concluded that SmallLint as it's now is not
well designed for this task and it would need a significant
refactoring. However, as always, I was never given time to do it.

HTH, Jan


On Tue, 2015-09-22 at 17:56 +0200, Yuriy Tymchuk wrote:

Le 22/09/2015 18:26, Jan Vrany a écrit :
> Yeah, I remember this is a pain. When I did years ago what
> you're doing now with QA, I ended up practicing black magic,
> sacrificing chickens and other things you'd better not to know.
>
> IIRC, the trick is to turn rewrite rules in ParseTreeEnvironment
> into search rules and then run the searches. Now this is tricky
> as these rules quite often refers to blocks, which then refers to outer
> contexts and you need these blocks do something different now (report
> nodes rather then transform stuff). This is the main problem.

I think what you can simply do is trap the place where the rewrites are
done, in RBStringReplaceRule. There is a verificationBlock instance
variable which sees every match node, as far as I can read through the
code, and this would change a bit the interface to call the rewrites in
RBTransformationRule (you need to activate that verificationBlock when
you create your rewriter).

As far as I can see, if verificationBlock print its argument to the
Transcript and returns false, your rewriter becomes a searcher which
print every match to the transcript.

Thierry

Le 22/09/2015 17:56, Yuriy Tymchuk a écrit :
Silly me. It's so simple:

| rw |
rw := RBParseTreeRewriter new.
rw
        replace: ' `#a `{:aNode | aNode value isCharacter}'
        with: '`#a newMessage'
        when: [:n | n logCr. false].

Use the when: block argument to trace all the matched nodes. Once you
have the nodes, you can highlight them.

Thierry

> Cheers! Uko
>

> RBTransformationRule (you need to activate that verificationBlock
> when
> you create your rewriter).

Yes, and this is the tricky bit :-) Because there's no guarantee that
this block is functional. For example, it may access context ivar
which, by the time UI is retrieving intervals is already nilled out
or even filled again with some other unrelated context if you're
reusing rule instances (but if not, you may run into performance
problems...)

Le 22/09/2015 19:14, Jan Vrany a écrit :
I'm not sure I see the issue. That block is evaluated just when you
match, before the rewrite. So, at that point, everything is valid.

You're right, the node may not be valid anymore after the rewrite if I
record the node. But if I record a copy of that source and the index
(you ask complete source to that node and startPosition / stopPosition)
then you're set for highlighting.

Thierry